git:20261006.0a1d34f to git:20261006.4c6da76

- Show the target branch (repo default, or the user's `targetBranch`, which also means no release), numbered tracks with titles (1-based display number beside each 0-based index), hard `after` edges separate from `runsAfter` edges, inferred edges, each issue's model/effort/plan (plan model: stamped, else Opus 5.5; plan effort: stamped, else high), whether `keepStamps` is on, the `skipValidate` set when the user gives one (per listed issue: the evidence source, session record or footer, and the predicted outcome: skip, or validates with the fallback reason from `run-plan.md` Preflight; for each footer issue, state that the prior validation's base branch and hard constraints are unknown and not carried), naming the harness on every Codex or Cursor CLI build or Codex CLI validate (`cli-dispatch` under an Opus 5.5 driver, never a substituted Claude run), the readiness boundary, and merge order. **Do not invoke the Workflow tool until the user approves**; approval is the multi-agent opt-in, and step 2 is never skipped.

- Add a **Run size** line: baseline `1 prep + per issue (1 validate + (plan ? 1 plan : 0) + 1 implement + (subagent review ? 1 reviewer : 0))`, ceiling `baseline + 3 × issues`. With `skipValidate`, a listed issue counts 1 skip-check agent in place of the validate when its skip is predicted, a skip-check plus the validate when the evidence predicts the fallback, and only the validate when rule 1, rule 2, or the branch rule predicts it (that refusal dispatches no skip-check); the ceiling adds 1 validate for every listed issue, because any skip can still fall back at run time. Compare both with the session's Dynamic workflow size guideline (else Claude Code's default of more than 25 scheduled agents), name the source, and recommend a split when either crosses it or projected tokens exceed 1.5 million (review-loop agents excluded). With a token target, an issue starting with under `budgetFloor` tokens (default 80k) left returns `budget_deferred`. **External CLI spend is outside every number above**: each pass and retry of a Codex or Cursor CLI build or Codex CLI validate bills that CLI's account; say so on any plan with a CLI stamp.

- **`skipValidate` records.** Pass a session record only for a validation this session completed with `Scope: OK`, no `Validation blocked`, and no `Infeasible` disposition: `validatedAt` is its step 1 `updatedAt` (`fable-validate`: its `Issue updatedAt` line; a `cli-dispatch` section 9 session pass: the driver's read time of record), `branch` the baseline branch it traced, `baseSha` the full commit (expand the short SHA its verdict states with `git rev-parse`), and `edited` is `false` for verdict `Update issue description? No`, or `true` only after its `update issue` edit landed and was read back. Never record a validation whose corrections were not applied. A bare number asks for footer evidence. Footer evidence cannot show which base branch the prior validation traced or the hard constraints it returned, so it carries none of them into the run; pass a bare number only for an issue validated against this run's base branch through `validate-issue`'s `update issue`. The run refuses a footer whose validating line names a pipeline build harness (`milestone-pipeline`, `Codex`, or `Cursor`) or no harness, because a pipeline validation never writes its constraints to the issue. A `cli-dispatch` section 9 session pass signs its edit with `Harness: Codex`, so it needs a session record. Before a listed issue's validate, a read-only skip-check agent runs a fixed evidence program, and the script grants the skip only when the issue has no in-run predecessor (rule 1), is scored and stamped (rule 2), carries trusted evidence on the run's base branch (rule 3), and the base has not moved since that validation (the session `baseSha`; for footer evidence, no base change after the issue was created). Every body edit, title rename, and comment after the baseline must also be trusted and change only metadata (rule 4); a trusted `## Implementation plan` comment is allowed. A footer-only issue in a `targetBranch` run always validates. A granted skip runs no validate agent, keeps every stamped route (no rescore), passes the baseline to `work-on-issue` as `validatedAt`, and still plans on `plan first: Yes`. A refused skip validates normally, logs why, and never blocks. Pass `skipValidate` unchanged on every resume.

- On each `awaiting_merge`, merge that PR in-session, then resume. Merge one PR at a time, finishing sub-steps 1 to 6 before the next, so each remaining PR is recomputed on the new base. A PR merges on the `fix-pr-review-loop` stop rule (`docs/contract-inventory.md`, review-cycle stop row): the standing verdict at the verified head is `LGTM` with no `### Needs Fixing` or `### Requires Human Review` section, and it lists no findings or the review count is above the cap of 5. Review count: github mode, `review_count` from the PR's round history (`skills/fix-pr-review/rereview-routing.md`); subagent mode, the run record's `review.reviews_run`, as the round history never counts in-session subagent reviews. `lgtm_with_nonblocking` arrives on review `maxReviewCycles + 1` in both modes, so it qualifies only when that count is above 5, as always at the default `maxReviewCycles: 5`. Any LGTM listing items at a count of 5 or less, `lgtm_with_nonblocking` from a lower `maxReviewCycles` included, is never merge-eligible; it returns to `fix-pr-review-loop`, whose step 1 rebuilds `review_count` from the PR history.

- 4. **Github mode LGTM recency gate**, run last and again after every CI wait or branch update: re-fetch the live head and comment history; find the newest one-line `@<bot> [model] review [effort]` trigger and the newest `github-actions[bot]` output linking `/actions/runs/<run-id>`. That run must be `completed` with `success`, and the output later than the trigger with exactly one standalone `LGTM` line (the verdict-line check; listed non-blocking items pass only under the merge criterion above). A newer trigger or no matching output blocks; never fall back to an older LGTM. Never compare the run's `head_sha` to the PR head (an `issue_comment` run reports the default branch); require the output's `created_at` later than the head became visible: the earliest check-suite `created_at` on `<verified-sha>`, else its committer date. One exemption: when sub-step 3 decided the conflict-case diff from `<reviewed-sha>` to `<verified-sha>` is prose only, visibility time is the reviewed SHA's, so the standing LGTM passes on `<verified-sha>`. Any other commit after the LGTM, author pushes included, blocks. Run sub-step 5 immediately after.

- Close out: on `release.deferred: true`, run `sync-docs-release` in-session and report the tag and URL, unless `target_branch` differs from the repo default branch (`create-release` cuts only from the default); then the release stays manual until the target merges into the default. Issues that never reached `merged`: merge stragglers in-session and resume, or run `sync-docs-release` yourself. Branch protection blocking squash merges means `merge: false` with successors stacking on unmerged heads; an Actions outage means `reviewMode: 'subagent'` on the next invocation.