feedback-rejection-flow

Files (1)

• SKILL.md

SKILL.md (first lines)

# Feedback Rejection Flow

This skill loads at the rejection-handling point; rejection detection, correction-record write scope, reuse conditions, and the budget probe stay always-on in the FO contract.

## Feedback Rejection Flow

When a feedback stage recommends REJECTED, run these five steps in order. Each is one action with one completion condition, and is unfinished until that condition holds: never treat a step's first command as its completion.

1. **Deliver the authorized correction.** Read the rejected stage's `feedback-to` target — the stage that receives the fix request, not the reviewer — and the already-authorized workflow package: rejected snapshot, finding evidence, existing workflow classifications, FO-authorized dispositions, and concrete revise assignment. If the distinct authorization or assignment is missing, hold at the active workflow's review-finding checkpoint; routing is ineligible. Route the package unchanged to the target stage in the same worktree, carrying the concrete assignment, not an acknowledgment request or a new classification request. Reuse the existing handle through `«addressable-worker»` only when it is addressable, reuse conditions pass, and `«context-budget»()` reports it under budget; otherwise shut down and fresh-dispatch. If no probe is declared, proceed to reuse.
   **Done when** the correction is complete in durable workflow state: the target worker's own entries closing this round's review log where the workflow keeps one, otherwise its `«completion-signal»` attributed by mailbox content, task path, or durable state. The immediate routing response is never completion.

2. **Record this round, once.** Append the authorized `### Feedback Cycles` line for this round when the active workflow declares that projection, then invoke the neutral recorder exactly once for the whole rejection cycle: `${SPACEDOCK_BIN:-spacedock} gate record ENTITY --round STAGE/CYCLE --briefing PATH/briefing.json --log PATH/briefing.review.jsonl`. ENTITY is the entity operand the recorder requires; omitting it is a usage error, not a recording. CYCLE is this rejection cycle's number and the only round id this cycle publishes; there is no second publication after the reviewer re-run. Do not define, normalize, or interpret the Cycle line's category labels, fields, tolerance, estimate, or drift grammar. The recorder retains the canonical two-file room and advances `review-round`, without receiving or interpreting the Cycle line.
   **Done when** the recorder exits successfully reporting the complete round summary, counting every entry this round accumulated. A usage error — the invocation itself was malformed — is not a round failure: correct the invocation and run it again, which completes this one publication rather than adding a second. If the recorder instead refuses the round, produces no result, or reports an incomplete round, hold the flow: do not claim that the round was recorded, re-run the reviewer, or prepare the next gate.

3. **Commit the recorded round.** Invoke `«state.commit»(slug)`.
   **Done when** the recorded round is durably committed and the tree is clean for that entity. Until it is, the entity is absent from `status --next` and refused by `gate prepare`: an empty scheduler here means this step is unfinished, never that the run is over.

4. **Re-run the reviewer on the corrected state.** Ask that reviewer to re-review the updated entity state, never to validate its own fix work. Re-run the kept-alive reviewer through the `«addressable-worker»` capability step 1 used, when it remains addressable and reuse conditions pass; fresh-dispatch a reviewer only when it is not. On cycle 3 run no reviewer: escalate to the human instead of a fourth round.
   **Done when** this cycle has a reviewer verdict — or, on cycle 3, the escalation to the human is recorded and the flow has stopped here.

5. **Re-enter the gate.** Invoke `Skill(skill="spacedock:fo-gate-lifecycle")` and run `«gate.lifecycle»` for the updated stage. A `needs-preparation` row is work to perform, not a stopping condition. This step is reached only from step 4's verdict: a `needs-preparation` row observed before that is step 3's commit landing, not a gate to prepare. The rejected report alone can surface one, and preparing on it would hand the captain a gate over work no reviewer has seen since the rejection.
   **Done when** exactly one fresh open gate has been prepared and presented, and the flow stops — without resolving or applying it, changing terminal state, or dispatching a successor.

The FO owns the shared correction-round section and writes it under `«write.classify»`: worktree-side when `worktree:` is set, main-side otherwise. The generic recorder owns only the immutable room and pointer bytes.

## Workflow-defined correction-round projection

The active workflow owns whether a projection exists and its exact grammar. This skill transports the selected projection without supplying defaults or interpreting its contents.

From spacedock-dev/spacedock, Apache-2.0.

More from spacedock-dev/spacedock