ListedStep models no failure reason, and no captured queryGeneratedImages payload exists to say whether it should (residual of #367/#372)

[ZacxDev]

Residual left open by #372 (the #367 fix), found while sweeping for disclaimers the parsed payload contradicts.

What #372 fixed, and where it stops

#367 was: the orchestrator records why a run failed in steps[].output.errors, and the CLI had no field for it, so every failure read identically. #372 fixes that on the raw shape — stepOutput / Step / Workflow in internal/genapi/status.go, which is what orchestrator.getWorkflow returns and what civitai workflows get and civitai generate render.

It does not touch the normalized shape in internal/genapi/workflows.go:

type ListedStep struct {
	Type     string       `json:"$type"`
	Name     string       `json:"name"`
	Status   string       `json:"status"`
	Metadata stepMetadata `json:"metadata"`
	Output   []Blob       `json:"output"`
	Images   []Blob       `json:"images"`
}

No error, failure or diagnostic field of any kind. So civitai workflows list can show a run as failed and has nothing to say about why, and its own help still routes the user to workflows get for the reason.

🔴 Why this is filed and not fixed

There is no captured queryGeneratedImages payload anywhere in this repo, so nobody can currently answer whether the normalized shape even carries errors.

Both list-endpoint fixtures are hand-written, and both give themselves away with a synthetic marker key:

• internal/genapi/workflows_test.go:78-92
• internal/cmd/workflows_list_test.go:36-49

"nextCursor":"cur_2",
"serverOnlyField":"kept"}

serverOnlyField exists only so TestQueryWorkflows_DecodesPageAndCounts can assert the raw --json passthrough survives. A fixture written from the struct cannot reveal a key the struct is missing — which is the same blind spot that let #367 survive every green suite.

And the list shape is genuinely a different shape, not an assumption: ListedWorkflow's own doc comment records that queryGeneratedImages runs its items through formatGenerationResponse2 while getWorkflow hands the orchestrator's workflow straight back, and that a shared struct would read zero values for whichever fields the other shape names differently.

Adding Errors to ListedStep on the strength of the raw shape carrying it would be guessing at a wire format — the fail-closed rule #346 and #372 both followed. So the work is: get the payload first.

What would settle it

1. Capture one real orchestrator.queryGeneratedImages response containing a failed workflow and commit it as internal/genapi/testdata/, redacted like fix(generate): the orchestrator recorded WHY the run failed and the CLI threw it away at unmarshal (#367) #372's failed_workflow_redacted.json. This is a read and spends nothing.
2. If it carries a reason, model it on ListedStep and surface it in workflows list (reusing FailureReasons' join/de-dupe rule, not a second one).
3. If it does not, say so in ListedStep's doc comment and keep the pointer to workflows get — a measured negative is worth recording, so the next reader does not re-open this.

While the corpus is this thin

ListedWorkflow also models no startedAt, completedAt, metadata or transactions, all of which the raw Workflow does model. In particular a metadata-carried modelSubstitutions record — the thing Workflow.Substitutions() recovers on workflows get — would be invisible on the list surface. Same missing evidence, same capture would answer it.