status returns rc=0 and an empty table in a non-holder split-root workspace, which is indistinguishable from an empty workflow

[iamcxa]

spacedock 0.26.0 (contract 3), split-root workflow, Conductor running several workspaces against one repository.

What happens

In a workspace where the state checkout was never created, status reports success and an empty entity list. That reads identically to a healthy workflow with no tasks yet.

Reproduced just now, against a workflow that has 79 archived entities:

$ ls -d <workspace>/docs/dev/.spacedock-state
ls: ...: No such file or directory          # this workspace is a non-holder

$ spacedock status --workflow-dir <workspace>/docs/dev
ID     SLUG     STATUS     TITLE     SCORE
--     ----     ------     -----     -----
$ echo $?
0

$ git ls-tree -r --name-only origin/spacedock-state/dev | grep -c '\.md$'
79                                           # the holder's entities

The holder for the same workflow is a different workspace of the same repository.

Why it matters

The degradation is silent all the way to the end of the useful window. new reports created, status reads the entity back, and only state commit fails — git refusing to add an ignored path. An entity filed in that window exists nowhere but that workspace's untracked directory.

status returning 0 is what makes it silent. A first officer that checks its workflow before filing gets a clean answer and proceeds.

Suggested shape

status (and new) can already tell these apart — the state path either resolves to a checkout on the state branch or it does not. Options, in the order I would prefer them:

1. status exits non-zero, or prints a distinguishable line, when the workflow is split-root and this workspace holds no state checkout. "No entities" and "no state checkout" are different answers and currently share an exit code and an empty table.
2. new refuses in a non-holder workspace rather than reporting created. This is where the loss actually occurs.
3. A state status / state doctor subcommand that answers "is this workspace the holder" as its whole job. state init exists; the read-side equivalent does not.

Any one of the three removes the silence. (1) is the smallest.

What adopters are doing instead

At least two repositories carry the workaround in their workflow README as prose: run git -C docs/dev/.spacedock-state rev-parse --abbrev-ref HEAD before filing and branch on the result, plus a detached-worktree append-and-push recipe for the non-holder case. In one of them that guidance is ~109 lines of shell living in a Markdown document, where it cannot be tested and cannot fail.

That is the cost of the current behaviour: every adopter reimplements a guard the binary is better placed to hold, and each copy is prose rather than a control.