git:20260903.6fdbab1 to git:20260905.9143be2

- Chain fable-validate → (conditional) update issue → fableplan → work-on-issue-loop into one autonomous run: Fable 5.1 validates the issue, the main agent fixes the issue description if needed, Fable 5.1 plans the implementation (plan posted to the issue), and work-on-issue-loop implements the plan and drives the PR through review to convergence. This is fable-validate's interactive handoff made unattended — the loop reads its own verdicts and proceeds, instead of waiting for the user to reply.

- **Do not skip or reorder the chain.** Validation gates planning (a plan built on refuted claims is wrong), and the plan gates implementation (that's the point of routing through fableplan). The only sanctioned skip is the step-4 score gate (a verdict signal of `fableplan: no`, which means both the title score and the recomputed score are below 71, bypasses fableplan). Every other step of each skill still runs; only the "wait for the user's reply" moments are replaced by the decision rules below.

- Same defaults as fable-validate: issue URL, `#<N>` / `<N>` / `owner/repo#N`, or nothing (defaults to the latest open issue in the current repo).

- Optional `targetBranch` (orchestration form `{ issue, targetBranch }` or a prose "target branch <name>"): passed unchanged to every validate, plan, and build step in the chain, so the baseline and the PR base are that branch instead of the repo default. `work-on-issue` step 1 ("Target") owns its validation.

- Invoke the `fable-validate` skill for the target issue (Skill tool, `skill: fable-validate`). Let it run fully — Fable 5.1 subagent validation, spot-check, verdict — producing the standard verdict block:

- Treat the verdict as structured output to parse yourself, not a prompt to wait on. Record the resolved issue number — every later step targets exactly this issue.

- ### 2. Scope gate — stop if the issue is unsafe to auto-implement

- Check the verdict's **Scope** field, **Architecture** section, and **Concerns** (for an already-addressing PR) before doing anything else:

- | `Scope: too large` (split / umbrella / narrow flagged) | **STOP.** Report the disposition and proposed parts. Implementing a multi-part issue as one PR reproduces the scope problem in the diff — splitting is a human call. |

- | Architecture marked ❌ **Infeasible** | **STOP.** Report the infeasibility and the "Optimal direction" note; planning and implementing a design the validation rejected would ship the wrong fix. |

- | A **merged** PR already implements the fix | **STOP.** Report the PR and the close/repurpose recommendation — nothing left to implement. |

- Otherwise (Scope: OK; architecture ✅/⚠️ or not applicable; no PR already addressing it), continue.

- If the verdict says **Update issue description? Yes**, apply the suggested title/body edits now per fable-validate step 5 / validate-issue step 11 — claim-verification gate, final consistency pass, and the stacked attribution line (`Validated with LLM: Fable 5.1 | high | Harness: <harness> | fable-validate-loop`, `<harness>` per `fable-dispatch` section 6) — from the current checkout (no worktree for issue edits).

-

- If **No**, skip straight to step 4.

-

- **Order matters:** the edits land before fableplan runs, so the Fable 5.1 planner fetches and plans against the corrected issue, not the flawed original.

-

- ### 4. Run fableplan — planning phase only (skip when the verdict's fableplan signal is no)

-

- **Score gate:** a verdict signal of `fableplan: no`, which validate-issue step 8 emits only when the title score and the recomputed score are both **below 71**, skips fableplan — go straight to step 5, because work-on-issue-loop plans adequately for lower-band changes on its own. Never read the raw `Complexity:` value for this gate: a validator recompute can land below the title score, and the title score is the floor for every routing decision. **Safety carve-out (overrides the gate):** if the validation flags money, data integrity, security, or an auto-protective mechanism anywhere in its findings, run fableplan regardless of score. (If the user wants a plan unconditionally, that's `fable-validate-fableplan-loop` — this same chain with the gate removed.)

- **Top-band note:** this gate runs fableplan for band-5 issues (score ≥ 81), and their verdict line reads `fableplan: yes` — the signal is `yes` for all of score ≥ 71. This loop implements via work-on-issue-loop on the session model, so the posted Fable plan is the only guaranteed Fable 5.1 involvement for a top-band issue here — skipping it would drop Fable from the hardest issues entirely.

- Otherwise, invoke the `fableplan` skill for the same issue number (Skill tool, `skill: fableplan`) and follow **fableplan's "Planning-phase-only invocation" section**: run fableplan steps 1 through 5 only, and do not execute its steps 7–8. Implementation belongs to work-on-issue-loop in step 5 of this skill. Instruct fableplan to use the harness suffix `fable-validate-loop` in the posted comment's attribution footer, so the comment records the actual entry point (a delta skill that reuses this step overrides the suffix with its own name).

- Give the planning subagent the validation verdict (the scratchpad copy from step 1) alongside the issue — the plan must respect what validation established (verified/refuted claims, the Optimal-direction note when architecture was ⚠️, 5c concerns).

- Keep the vetted plan's scratchpad file — step 5 passes it through. On a structurally wrong plan or a fableplan failure after its internal retry, stop and report per that section; don't implement unplanned.

- Invoke the `work-on-issue-loop` skill for the same issue number (Skill tool, `skill: work-on-issue-loop`). Pass the issue number through explicitly — don't let it re-resolve "latest issue" — and instruct it that the implementation must follow the Fable 5.1 plan: point it at the plan's scratchpad file and the posted issue comment (`## Implementation plan (Fable 5.1)`), and tell it deviations follow `work-on-issue` step 2's plan-deviation policy — the traced code, anything posted on the issue after the plan, then correctness and safety — and must each be named in the PR body. Don't narrow that policy here. (If step 4 was skipped by the score gate, there is no plan — hand off the issue alone and note the skip.)

-

- It runs its full loop: work-on-issue implements in a worktree and opens the PR, the loop triggers `@claude` review, and fix-pr-review cycles until convergence.

- Relay work-on-issue-loop's final summary (PR URL, review cycles, final verdict), prefixed with one line covering the head of the chain: scope gate passed, issue updated or not, plan posted (comment URL) or skipped by the score gate.

- **Cap the whole report at 55 words, plain simple English in ASD-STE100** — apply the Response Style rules in CLAUDE.md/AGENTS.md, written for a reader with no context on this codebase.

- | Tempted to skip validation or planning and jump to implementation | Never reorder — validate-then-plan-then-build is the point of this skill; the only sanctioned skip is the step-4 score gate (the verdict's title-floored signal reads `fableplan: no`, so the title score and the recomputed score are both below 71, with no safety flags) |

- | `Scope: too large`, Architecture ❌ Infeasible, or a PR already addressing the issue | Stop and report per step 2 — the cases the loop can't safely auto-resolve |

- | Verdict says Update issue description? Yes | Apply the edits **before** fableplan runs, so the plan targets the corrected issue |

- | fableplan about to enter its build steps (7–8) | Don't — stop it at step 5; work-on-issue-loop owns implementation |

- | fableplan's sanity-check finds the plan structurally wrong | Stop and report — don't hand a broken plan to work-on-issue-loop, and don't silently re-plan |