feedback-rejection-flow

# Feedback Rejection Flow This skill loads at the rejection-handling point; the rejection DETECTION, the `### Feedback Cycles` write-scope rules, the reuse conditions, and the budget probe stay always-on in the FO contract, and this procedure references them by name. ## Feedback Rejection Flow When a feedback stage recommends REJECTED: 1. Read the rejected stage's `feedback-to` target — the stage that receives the fix request, not the reviewer. 2. Append this round's entry to `### Feedback Cycles` in the entity body, in the format below. 3. Read the deviation and the AC-drift note from the two most recent entries. Past the declared tolerance — 2× unless the entity declares its own — or on a narrowed AC, record a design-reset decision (reconfirm, re-scope, park, or escalate) before any further round; no automatic re-dispatch while that decision is absent. On cycle 3, escalate to the human instead of another round. 4. Invoke `«context-budget»()`. If the old ensign is over budget or the source is unavailable, shut down and fresh-dispatch; if no probe is declared, proceed to reuse below. 5. Route findings back to the target stage in the same worktree using `«addressable-worker»` when the existing handle is addressable and reuse conditions pass; otherwise shut down and fresh-dispatch. The routed message must carry the concrete next-stage assignment and fix work, not just an acknowledgment request. Do not treat the immediate routing response as the new completion result: if the...