GeezerVison

Three defects, one shape: a rule applied to one path and not its sibling. Two were found by probing the live surface after #6681 deployed; the third by reading for the pattern. Each was reproduced before any code changed, and each fix is verified red-then-green.

Create validated almost nothing update validates

createTableGroupUseCase — what POST /api/v2/tables/{tableId}/groups calls — never received the registry checks #6681 added to updateTableGroupUseCase. Confirmed live on a self-created table:

Each 201 stores a column no run can ever write — the runner fills a cell from result[out.outputId] and skips an output with none. The caller discovers it only when a later edit returns the 400 create should have given.

Create now runs the same requireEnrichment / requireKnownEnrichmentOutputIds helpers and the same validateRequestedOutputs check as update. No third validator.

The discriminator is workflowId, not type — load-bearing. workflow-sidebar.tsx creates enrichment-template groups labelled type: 'enrichment' while backed by a real workflowId and carrying no enrichmentId. Keying on the label would have sent that straight into requireEnrichment(undefined) and 400'd the first-party create path. Pinned by a regression test.

A group's producer type could be relabelled into a state create forbids

refineGroupSource enforces "enrichmentId required when type is enrichment" on create; the v2 update body has no such refine, declares type as a "replacement producer type", and declares no enrichmentId — so PATCH {groupId, type:"enrichment"} on a manual group reached the writer, which applies it unconditionally. Unrepairable: the strict body has no field that would make it valid.

The harmful direction is the reverse flip. Relabelling an enrichment group as manual keeps enrichmentId while moving it onto the workflow branch with workflowId === '', so every cell run fails. (The forward flip is survivable — workflowId persists and the runner falls through.) An update may now only restate the type the group already has; re-sending the stored value stays a no-op, so a caller echoing the whole group back is unaffected.

Option (b) — accepting enrichmentId on update and validating the merged state — was rejected: it needs the writer to persist enrichmentId and clear workflowId, i.e. a producer-swap feature nobody asked for.

The last two unbound cursors

GET /workflows/{id}/versions and GET /workspaces/{workspaceId}/members were the only paged reads still minting bare tokens — literally {"version":2} and {"email":"..."} base64'd. Confirmed live: a versions cursor from workflow A is accepted by workflow B, and a hand-crafted {"version":99} is accepted verbatim. The keyset still applies within the authorized parent, so it is a silently-wrong start position, not a leak.

Both now wrap their domain token with the same {scope,inner} binding used everywhere else. No new mechanism.

Guardrail closed too: CURSOR_BINDINGS recorded only query/body params, so [] could not distinguish "no filters" from "parent forgotten" — which is exactly what hid these two. CURSOR_BOUND_PATH_PARAMS now declares the parent path param for all six nested paged lists, with tests that fail actionably if an entry is dropped. The cursor tests were also reworked to mint through the route, so a route that stops binding cannot pass.

In-flight tokens for these two lists are invalidated. They are single-walk and unpersisted, and the refusal message is accurate.

Not fixed, flagged for follow-up

• The same relabelling hole via workflowId: PATCH {workflowId} on a registry-enrichment group makes it workflow-backed while enrichmentId stays set, so the runner still takes the enrichment branch and ignores the workflow. No first-party caller does this.
• v2 create refuses a shape the first-party surface produces (type:'enrichment' + workflowId + no enrichmentId), so a public caller cannot create a group the UI can.

Verification

• Full suite: 1,863 files / 24,939 tests passed, 0 failed
• type-check 23/23, biome, check:audits 26/26, check:api-validation:strict, check:openapi — all clean
• One-line OpenAPI description diff regenerated for the type field