vinta-ai-workflows 0.7.0-alpha19 → 0.7.0-alpha20

package/CHANGELOG.md

@@ -7,6 +7,7 @@ the project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## [0.7.0] — YYYY-MM-DD
 
+<!-- pre-release: 0.7.0-alpha20 on 2026-09-24 -->
 <!-- pre-release: 0.7.0-alpha19 on 2026-09-19 -->
 <!-- pre-release: 0.7.0-alpha18 on 2026-09-17 -->
 <!-- pre-release: 0.7.0-alpha17 on 2026-09-17 -->
@@ -29,6 +30,17 @@ the project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Added
 
+- **A timed-out gate says whether it hung or was slow.** A `gate_result` with
+  `status: timed_out` used to carry only the status, so a run with nine
+  timeouts could not say whether any of them was a stuck suite or a host too
+  busy to finish one. It now carries `timeout`: `quiet_ms` (how long the gate
+  had gone without writing anything when it was killed), `output_bytes`, and
+  the host's `load_1m` beside `cpus`. `quiet_ms` near the timeout is a gate
+  waiting on something; a small one with `load_1m` well above `cpus` is
+  contention. Numbers only, as before: nothing the gate printed reaches the
+  row. The monitor's brief points at the new field. Older rows have no
+  `timeout`.
+
 - **Gate durations are now kept, not just displayed.** Every `gate_result` has
   carried the runner's own `duration_ms` since gates were journalled, and
   nothing read it back: the figure went to a live panel and was afterwards
@@ -564,6 +576,84 @@ the project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Changed
 
+- **Updated the OpenAI and Anthropic models to their latest version.**
+
+- **Updated the generated skills to have `disable-model-invocation: true` set.**
+
+- **An expanded panel reads in a centred column.** Full page used to mean
+  full width too, so on a large monitor a transcript or gate log ran in lines
+  too long to follow. The overlay still covers the window; its header and
+  content now sit in a centred column capped at `max-w-6xl`.
+
+- **The node view reads like a chat.** The transcript now sits above the
+  steering box instead of below it, so the conversation comes first and the
+  box you answer it in is under its newest turn. A terminal opened by *Take
+  over* still appears under the steering box.
+
+- **`--retry-after` backs off when attempts fail faster than it.** An
+  unanswered failure question used to answer itself on a flat interval
+  forever, so a phase whose attempts died within seconds was retried every
+  fifteen minutes for hours, against the same failure, at the price of a cold
+  lane each time. Each attempt that fails in less time than the interval now
+  doubles the next wait, up to 8× (15m becomes 2h); one attempt that runs at
+  least the interval long puts it back. It still never stops on its own: a
+  run whose cause goes away overnight is moving again before morning. The
+  `node.unattended_retry` log line reports the actual wait and the streak.
+
+- **Notifications have an inbox, and are heard from every view.** The UI's
+  notifications used to be a row of banners in the top bar, shown only when
+  browser notifications were refused. They piled up there and could be read
+  only one at a time, by dismissing whichever was in front. Every notification
+  now lands in an inbox behind a bell with an unread count: newest first,
+  filterable by unread and by still-waiting pauses, marked read one at a time
+  or all at once, dismissed singly or cleared. A pause that gets answered stays
+  listed and says *Answered*. The inbox is kept in `localStorage` and shared by
+  every tab, so a reload no longer loses it. It stores what a notification
+  body already carries — a run id, a node id, a reason and the journal's
+  timestamp — and no question text, output or diff. Browser notifications also
+  reach the operator more often now. They used to fire only for the run open
+  on screen; the UI now follows every running run in the background, and a run
+  view takes over that run's stream instead of opening a second one. They also
+  depended on a permission prompt raised by the first pause, which Firefox and
+  Safari ignore when no click raised it, so on those browsers they could never
+  turn on. An *Enable notifications* button now sits in the top bar until the
+  browser has been asked (and in the inbox too), and confirms with one test
+  notification. It also says why the channel is off
+  when it is: blocked in the browser's site settings, or served over plain
+  HTTP on a remote `--host`, which browsers do not allow notifications from.
+  The reminder interval moved into the inbox.
+
+- **The run view's Nodes table names a lane by what distinguishes it.**
+  Every lane in a run is named `${runId}-...`, so the column spelled them in
+  full as `2026-09-11-graphql-aggregations-mubou9ar-crew-3-tier4` on every
+  row, phase after phase — the same forty characters of prefix repeated down
+  the table, wide enough to push the whole table into a horizontal scroll for
+  the sake of a string that was identical everywhere it appeared. The cell now
+  shows the tail that actually differs (`crew-3-tier4`, `lane-2`, `integ`) and
+  keeps the full name in its `title`, because that is what the worktree
+  directory and the branch are called. The phase description beside the node
+  id is bounded and wraps for the same reason — table cells are
+  `whitespace-nowrap`, so one long phase name was setting the width of the
+  whole table.
+
+- **A dispatched phase agent does the work itself, instead of spawning an
+  implementer under it.** claude-code sessions run by the orchestrator were
+  handing their phase to a sub-agent and reporting its summary back, and the
+  pull was not laziness — `implement-phase` ships into the same repositories,
+  its description matches "you are implementing P3 of plan X", and its content
+  is "spawn exactly one implementer subagent". So a session was loading a
+  conductor skill on its own and correctly following it, one level below the
+  conductor that had already spawned it. The cost is the whole point of session
+  reuse: a sub-agent's reading of the codebase ends with the sub-agent, so the
+  warm session that every cross-phase turn greets with "everything you learned
+  still holds" was left holding a paragraph, and each phase paid a cold agent's
+  first turn again. Both halves are now closed. Every `vinta-ai-maestro` role
+  prompt (implementer, reviewer, fixer, chore — cold and continued) carries a
+  no-delegation section that names those skills and says what delegating costs,
+  and the plan-execution unit grows a `dispatched-agent` partial: a guard at the
+  top of all four conductors refusing entry to an agent that was itself handed
+  one phase, plus the same rule inside every composed implementer prompt.
+
 - **The node view's gate panel is a list of verdicts you can open, not a stack
   of scrolling boxes.** Every gate used to render its whole log at once, each
   in its own fixed-height box with its own scrollbar — so three gates in a
@@ -736,6 +826,157 @@ the project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Fixed
 
+- **A failed Claude Code turn no longer reads as `claude-code result:
+  success`.** When the CLI ends a turn with `is_error: true` beside
+  `subtype: "success"` (how a plan limit arrives, for one), the recorded
+  error printed the subtype and said "success" — 189 times in one observed
+  run. It now reads `claude-code result: is_error`. Other subtypes
+  (`error_max_turns`, …) are unchanged.
+
+- **The monitor's conversation was mostly unformatted JSON.** Not its answers —
+  its *watchdog's*. An intervention turn must reply with one document matching
+  `intervention.v1.schema.json`, which is what makes the monitor's authority
+  over a live run a closed set of verbs rather than an editor over
+  `workflow.json`; and that turn is journalled into the conversation a person
+  reads, because a run that retuned itself should say so where somebody is
+  already looking. Both of those are right. Rendering the document verbatim was
+  not, and the summary paragraph the operator wanted arrived a thousand
+  characters into one unwrapped line of braces. A proposal now renders as what
+  it says: the summary, then one line per proposed change with its evidence
+  under it, and a tone dot only when something was actually proposed — a turn
+  that looked and changed nothing is the expected outcome and should not shout.
+  The verb table is keyed on the daemon's own union, so a fifth verb fails the
+  UI build rather than shipping as a bare identifier. The journal still holds
+  the bytes the model wrote — only the row changed, so conversations already on
+  disk read as well as new ones. Any other whole-JSON answer is at least
+  indented.
+
+- **The monitor's conversation opened at its oldest entry and never scrolled.**
+  It followed the newest row *only while a turn was running*, on the reasoning
+  that the list is short and the operator is watching the answer they just
+  asked for. Neither half held: the conversation is the journal's, so it holds
+  every question ever asked about the run plus every proposal the run's own
+  watchdog made with nobody asking anything — a hundred entries is ordinary.
+  Opening the panel therefore put the reader at the oldest of them. It now
+  follows the way a phase's transcript does: stuck to the newest row, letting
+  go the moment the reader scrolls up to read, with a "Jump to latest" as the
+  way back. That rule is one module now rather than a well-tested copy in the
+  transcript and none in the monitor, which is how the panel came to be missing
+  three of its parts — including the one that survives a panel being expanded
+  to full page, where the portal hands the view a brand new list scrolled to
+  the top.
+
+- **Hitting the plan's session or weekly limit failed the node instead of
+  waiting for the window to end.** `claude-code`'s refusal table recognised
+  "usage limit reached" and nothing else, and the classifier's default is
+  `fatal` — correctly, since an unrecognised failure must not become an
+  unbounded wait. But the CLI announces a plan window in its own words:
+  "You've hit your session limit", "Session limit reached · resets 3am",
+  "5-hour limit reached", "You've reached your weekly limit". None of those
+  contain "usage limit", so every one of them fell past the table to `fatal`,
+  which fails the node and blocks its whole dependent subtree — for a window
+  that ends by itself in a few hours. The machinery to do the right thing was
+  already there and simply never reached: a `quota` refusal parks the harness,
+  not the node, so every later node joins one wait instead of discovering the
+  limit for itself; the wake time is journalled and survives a daemon restart;
+  and the AIMD ceiling is left alone, because a plan window says nothing about
+  how many agents may run at once. Those wordings are now `quota`. The new row
+  sits *below* `concurrency` and `rate_limit` so that "concurrent session limit
+  reached" keeps the kind that halves the ceiling, and "approaching session
+  limit" — a warning from a harness that is still working — matches nothing.
+
+- **A window that closed *under* a running turn was an ordinary turn failure.**
+  §6.1 is written about a spawn, because that is where a vendor usually says
+  "not right now" — and everything that follows from it, parking the harness so
+  every later node joins one wait, journalling the wake time so a daemon
+  restart does not forget it, leaving the AIMD ceiling alone for a window that
+  says nothing about concurrency, hung off `admit`. So the other arrival of the
+  same fact had none of it: a plan window that closes while an agent is twenty
+  minutes into a phase ends the turn, and the node then burnt its retries
+  against a closed window and failed, blocking its whole dependent subtree —
+  the exact outcome §6.1 exists to prevent, reached by the one path that did not
+  go through admission control. A session now reports a `TurnRefusal`, and the
+  caller answers it with the `CapacityRetry` a refused spawn raises: the lane
+  goes back, the harness parks until the stated reset, and the node re-drives
+  when the window opens.
+
+  Each adapter reads it where its own failure prose is, which is not where its
+  events are: `claude-code`'s terminal `result` frame carries the sentence in
+  the `result` string that `mapResult` deliberately drops (it is agent output,
+  §11), `codex` states a failure as prose on three different frames, and
+  `opencode`'s `session.error` carries it under `data`, which `#errorName`
+  refuses to put in an event. All three read that prose, match it against the
+  table they already had, and drop it — what reaches the caller is a kind, a
+  fixed reason token and a reset time, and what reaches the transcript is one
+  token-only line so the record says why the turn stopped. The stderr-and-exit
+  shape of the same event is read too, from the diagnostics buffer that is the
+  only place that sentence exists.
+
+  The re-drive is a full one, and that is deliberate: the session the turn was
+  using is gone, and resuming from a memory of files a recycle has removed is
+  worse than redoing the work. Nothing is destroyed by it — `recycle` sets
+  aside whatever the turn left uncommitted as a WIP ref first. What it costs is
+  the turn. What it used to cost was the node.
+
+- **A stated reset time was only read when it was an hour on the same day.**
+  `parseRetryAfter` prefers a reset the vendor reported over a guessed backoff,
+  and its wall-clock pattern wanted `am`/`pm` immediately after "reset", so
+  "resets at 15:00", "resets tomorrow at 2am" and the weekly window's "resets
+  on Monday at 12am" all reported nothing — falling back to the five-minute
+  re-probe interval, which across a week-long window is two thousand spawns to
+  discover what the first sentence said. It now reads 24-hour times, `today`,
+  `tomorrow` and a named weekday (the next occurrence of it, which is today
+  only while the hour is still ahead). A reset named by date, "resets Nov 3 at
+  9am", still reports nothing on purpose: a month with no year is a guess, and
+  the re-probe is a better answer than a wait that is wrong by a year. So are
+  "reset 3", "resets at 25:00" and "resets at 13pm" — an hour with neither
+  minutes nor a meridiem is as likely to be a version or a retry count, and
+  everything this function returns becomes a wait.
+
+- **`run --resume` could not provision a pool at all on a project that
+  disables hooks.** `#configureHooks` enables `extensions.worktreeConfig`
+  before it can set `core.hooksPath --worktree`, and that first key is
+  repository-wide: the write lands in the shared `.git/config`, which git takes
+  `.git/config.lock` to edit. Called once per lane out of the provisioning
+  `Promise.all`, the lanes collided on that lock — `could not lock config file
+  …: File exists`. A fresh provision never showed it, because `worktree add`
+  goes through the pool's serialized git turn and staggered the lanes apart by
+  the time they reached the shared write; `adopt` skips `worktree add`, so every
+  lane arrived in the same tick and **every** resume of a `hooks: false` project
+  failed, reproducibly, before a single phase was scheduled. The extension now
+  goes through the same serialized turn. The `--worktree` write stays parallel:
+  it lands in `.git/worktrees/<name>/config.worktree`, one file per lane.
+
+- **A provision failure that was not one of three enumerated kinds said nothing
+  about itself.** `refusal` detailed `DiskProbeError`, `LaneSetupError` and
+  `LaneEnvFileError`; everything else — including the lock collision above and
+  `LaneAdoptError`, the one error a resume is most likely to hit — collapsed to
+  "could not provision the lane pool under …", and the daemon log recorded that
+  same sentence as `run.provision_failed`'s `reason` with no `error` field and
+  no stack. So the run that could not start left behind no record of why, in
+  either place an operator looks. The exclusion was a §11 reading
+  `LaneSetupError` had already revised for this exact reason: §11 keeps
+  repository *contents* out of the record — diffs, file bodies, gate output —
+  and an error's own complaint about a lock file or a ref is not that. An
+  unenumerated error's message is now carried, capped at 500 characters and run
+  through the log's redaction set; `LaneAdoptError` speaks for itself like the
+  other lane errors; and the failure is logged with its kind and stack frames.
+
+- **`doctor` reported the resumed run's own lanes as leftovers blocking it, and
+  offered to destroy them.** The held-branch check fails a run whose phase
+  branches are checked out in another worktree, which is right for a fresh run
+  and exactly wrong for a resume: the integrator puts a lane on
+  `plan/<id>/phase-<n>` for the duration of a phase, so a run killed mid-phase
+  — the kill a resume is *for* — leaves its own lanes holding precisely those
+  branches. Every `run --resume` therefore refused preflight with one failure
+  per phase in flight, each remedied by `git worktree remove --force <lane>`,
+  which deletes the uncommitted work the resume existed to adopt. The check now
+  takes the run being resumed and excludes lanes belonging to it, identified by
+  reading the lane root and asking each worktree which branch it holds — never
+  by comparing git's printed paths with this process's, the platform trap
+  `reap` and `LanePool` both document. `doctor` takes `--resume <run-id>` to ask
+  the same question before a resume, and a lane of *another* run still fails.
+
 - **`vinta-ai-maestro gate` gave up on the slowest gate after five minutes and
   called it a daemon it could not reach.** The command awaited one `fetch`, on
   the stated reasoning that a gate is slow for reasons the client cannot shorten

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vinta-ai-workflows",
-  "version": "0.7.0-alpha19",
+  "version": "0.7.0-alpha20",
   "description": "Bootstrap AI tooling (AGENTS.md, skills, sub-agents) across Claude Code, Codex, Cursor, and VS Code + GitHub Copilot.",
   "type": "module",
   "bin": {

package/skills/vinta-derive-skills/SKILL.md

@@ -138,6 +138,8 @@ Shells under `plan-execution/shell/` are thin — most content lives in `plan-ex
 
 **The parallel-lanes seam.** `partials/parallel-lanes.md` carries the DAG scheduler: the graph parse (`DAG_PARSE`), the worktree pool (`LANE_WORKTREE_POOL`), the dependency-derived branch topology (`LANE_TOPOLOGY`), the dispatch loop (`LANE_SCHEDULER`), the tracking-directory schema (`TRACKING_DIR`), and the sibling-lane write guard (`SIBLING_LANE_ISOLATION`, included by `worktree-seam.md#STRAY_WRITE_CHECK`). All six blocks are project-agnostic and carry no new `{{...}}` placeholders of their own beyond ones the shells already substitute (`{{PLAN_DIR}}`, `{{BUILD_CMD}}`, `{{E2E_RUN_OPTION_TRACKING}}`, `{{TRACKING_BRANCH_FIELD}}`, `{{TRACKING_PHASE_BRANCH_FIELD}}`).
 
+**The dispatched-agent seam.** `partials/dispatched-agent.md` carries the one rule that spans both directions of the unit: the agent doing a phase never dispatches. `CONDUCTOR_ENTRY_GUARD` goes near the top of all four conductors (`implement-plan`, `implement-phase`, `review-phase`, `amend-plan`) and stops an agent that was itself handed one phase — by another conductor, or by [vinta-ai-maestro](https://github.com/vintasoftware/vinta-ai-workflows/tree/main/packages/vinta-ai-maestro) — from re-entering the orchestrator one level down. `NO_NESTED_DISPATCH` is prompt text, spliced into `implementer-prompt.md#INNER_OUTER_LOOP`, so every composed implementer prompt (forward and amend) carries it. Both blocks are project-agnostic and take no `{{...}}` placeholders.
+
 **When `foundation_skills.prepare-worktree` is `disabled`**, parallel execution is impossible (several agents cannot share one working tree). Render the plan-execution unit sequential-only: strip the Step 0 (e) question and the `{If run_options.parallel_phases = true:}` gate from the implementer prompt, and keep the `parallel-lanes` blocks — the scheduler with `max_parallel_lanes = 1` **is** the sequential path, and the DAG still orders the phases correctly. Only the pool provisioning collapses to the single-worktree branch of `WORKROOT_RESOLUTION`.
 
 **`ask` → two `integrate-phase` variants, no dual-render.** When `policies.commit_strategy = ask`, render `integrate-phase-template.md` **twice**:

package/skills/vinta-derive-skills/resources/foundation-skills/plan-feature/resources/ai-models.yaml

@@ -37,7 +37,7 @@ tiers:
       anthropic:
         - id: claude-haiku-4-5
       openai:
-        - id: gpt-5.6-luna
+        - id: gpt-6-luna
           note: optimized for cost-sensitive workloads
       google:
         - id: gemini-3.1-flash-lite
@@ -50,11 +50,10 @@ tiers:
       fixtures, simple HStore/ArrayField additions.
     models:
       anthropic:
-        - id: claude-haiku-4-5
         - id: claude-sonnet-5
           note: step-up target when phase touches >3 files
       openai:
-        - id: gpt-5-mini
+        - id: gpt-6-luna
       google:
         - id: gemini-3.8-flash
 
@@ -67,9 +66,9 @@ tiers:
       covering concurrency edges.
     models:
       anthropic:
-        - id: claude-sonnet-5
+        - id: claude-opus-5-5
       openai:
-        - id: gpt-5.6-terra
+        - id: gpt-6-sol
       google:
         - id: gemini-3-pro
           note: stronger code recall
@@ -82,12 +81,10 @@ tiers:
       tuning slow query against partitioned hot table, debugging heisenbug.
     models:
       anthropic:
-        - id: claude-opus-5
+        - id: claude-fable-5-1
       openai:
         - id: gpt-6-astra
           note: frontier model; roughly twice sol's price, so reserve it for tier 4
-        - id: gpt-5.6-sol
-          note: cheaper frontier option when astra's step up is not warranted
       google:
         - id: gemini-3-pro
           note: with thinking

package/skills/vinta-derive-skills/resources/plan-execution/README.md

@@ -41,6 +41,17 @@ The conductor resolves three values **once per lane** (see `partials/worktree-se
 
 Every `git` / lint / test / build call in every sub-skill uses `git -C <WORKROOT>` **uniformly** — no `if use_worktree` inside them. Only two genuine conditionals remain, each local and data-driven: the `SANDBOX_TIER`-gated spawn wrap in `implement-phase`, and the `WORKROOT != main_checkout`-gated stray-write check in `review-phase`.
 
+## The dispatched-agent seam (`partials/dispatched-agent.md`)
+
+One rule, two shapes, because it has to hold at both ends of the unit: **the agent doing a phase never dispatches.**
+
+| Block | Consumed by | What it owns |
+|---|---|---|
+| `CONDUCTOR_ENTRY_GUARD` | `implement-plan`, `implement-phase`, `review-phase`, `amend-plan` | Refuses entry to an agent that was itself handed one phase — by another conductor, or by an external orchestrator such as [vinta-ai-maestro](https://github.com/vintasoftware/vinta-ai-workflows/tree/main/packages/vinta-ai-maestro). The conductor is already running; it is what spawned the reader. |
+| `NO_NESTED_DISPATCH` | `implementer-prompt.md#INNER_OUTER_LOOP` → the composed prompt in `implement-phase` and `amend-plan` 4b | Tells the spawned implementer to do the work in its own session. |
+
+The cost this prevents is not duplicated orchestration — it is lost context. A phase agent is reused (review findings, a chore over its own diff, often the next phase), and that reuse only buys anything because the session that read the codebase is the session that gets the next turn. A sub-agent's reading dies with the sub-agent, leaving the parent holding a summary and every later turn starting cold.
+
 ## The parallel-lanes seam (`partials/parallel-lanes.md`)
 
 The plan gives every phase a `**Depends on**:` line. The conductor turns those into a DAG and dispatches a phase the moment its dependencies are green and a lane is free. Six blocks:

package/skills/vinta-derive-skills/resources/plan-execution/partials/dispatched-agent.md

@@ -0,0 +1,31 @@
+<!-- Partial: dispatched-agent — the two halves of "the agent doing one phase does not dispatch". CONDUCTOR_ENTRY_GUARD stops a dispatched phase agent from re-entering a conductor skill one level down (implement-plan / implement-phase / review-phase / amend-plan). NO_NESTED_DISPATCH is prompt text: it goes inside the composed implementer prompt, via implementer-prompt.md#INNER_OUTER_LOOP, so both implement-phase's prompt and amend-plan's 4b rewrite prompt carry it. Project-agnostic — no `{{...}}` placeholders of its own. -->
+
+<!-- block-begin: CONDUCTOR_ENTRY_GUARD -->
+## Not for an agent that was handed one phase
+
+This skill **orchestrates**: it composes prompts, picks models and spawns other agents. Run it only when you are the session a user or a scheduler invoked to drive a plan.
+
+If you are reading it because something handed you a single phase — a prompt naming your phase id, a branch already cut for you, a worktree you were told to stay inside, or an orchestrator such as [vinta-ai-maestro](https://github.com/vintasoftware/vinta-ai-workflows/tree/main/packages/vinta-ai-maestro) that spawned you — then the conductor this skill describes **is already running, and it is what spawned you**. Do not start a second one underneath it. Do the work in your own session, report back the way your prompt asked, and take from here only what it says about this repository's conventions, gates and commit rules.
+
+The duplication is the smaller cost. A dispatched agent is deliberately reused — the same session takes the review findings, the chore over its own diff, and often the next phase — and that reuse is worth something only because the session that read the codebase is the session that gets the next turn. Hand your phase to a sub-agent and its reading of the code dies with it: you are left holding a summary, and every turn after yours starts cold.
+<!-- block-end: CONDUCTOR_ENTRY_GUARD -->
+
+<!-- block-begin: NO_NESTED_DISPATCH -->
+## Do this work yourself
+
+You are the agent that implements this phase, not an orchestrator for one. Do not spawn,
+dispatch or delegate to a sub-agent (claude-code's Task/Agent tool, or whatever your
+runtime calls the same thing) for any part of it: not the implementation, not a search of
+the codebase, not a second opinion on your own output. Read, run and write yourself.
+
+The orchestrator reuses this session — for the review findings, for a chore over your own
+diff, often for the next phase — precisely because by then you know where this codebase
+keeps things and how its suite is run. A sub-agent's reading of the code ends when the
+sub-agent does, so a delegated phase leaves you holding its summary and nothing else, and
+every turn after this one starts cold.
+
+A project skill that tells you to spawn an implementer, reviewer or fixer —
+`implement-plan`, `implement-phase`, `review-phase`, `amend-plan`, anything shaped like
+them — is written for the orchestrator that dispatched you, not for you. Take what it says
+about conventions, gates and commit rules; never follow its spawn steps.
+<!-- block-end: NO_NESTED_DISPATCH -->

package/skills/vinta-derive-skills/resources/plan-execution/partials/implementer-prompt.md

@@ -85,4 +85,6 @@ Project skills available: {{PROJECT_SKILLS_LIST}}
       {If run_options.full_test_suite = true:} run the **full test suite** `{{TEST_CMD}}` instead of the scoped suite — this phase guards against regressions in untouched code too.
    {{E2E_OUTER_GATE_LINE}}
 6. Outer gate fails → return step 2 (fix regression), re-run inner loop, then 5a/5b/5c. **Never** commit, push, or proceed while any gate is red.
+
+<!-- include: partials/dispatched-agent.md#NO_NESTED_DISPATCH -->
 <!-- block-end: INNER_OUTER_LOOP -->

package/skills/vinta-derive-skills/resources/plan-execution/shell/amend-plan-template.md

@@ -1,6 +1,7 @@
 ---
 name: amend-plan
 description: Adjust an existing implementation plan in `{{PLAN_DIR}}/` after implementation has started or finished. Updates the plan file (revising existing phases or appending new ones), then for each affected phase that was already implemented adjusts its commits (`git commit --amend` or new commits) on the phase branch, force-pushes the rewritten branch, rebases every phase branch in the rewritten phase's dependency closure, force-pushes each, and refreshes the PR-context files. Use when the user says "amend the plan", "update phase N", "add a phase to plan X", "the spec changed, fix the plan", or "rewrite the implementation for phase N". NOT for one-off changes to a single file unrelated to a plan; use the regular implement skill for that. {{PR_POLICY_DESCRIPTION}}
+disable-model-invocation: true
 ---
 
 # Amend Plan
@@ -9,6 +10,8 @@ Revise a plan in [`{{PLAN_DIR}}/`]({{PLAN_DIR}}/) after work has begun. Companio
 
 The flow is destructive (force-push). Every modification is gated on user confirmation. Default disposition for any ambiguous case is "stop and ask" — never force-push without an explicit per-branch `Confirm` from the user.{{COMMIT_STRATEGY_REFUSAL_BLOCK}}
 
+<!-- include: partials/dispatched-agent.md#CONDUCTOR_ENTRY_GUARD -->
+
 ## Working assumptions
 
 - Repo: {{PROJECT_NAME}} ({{STACK_SUMMARY}}). Conventions: [AGENTS.md](../../../AGENTS.md).

package/skills/vinta-derive-skills/resources/plan-execution/shell/implement-phase-template.md

@@ -1,12 +1,15 @@
 ---
 name: implement-phase
 description: Internal execution step of [implement-plan] / [amend-plan] — NOT a standalone entry point. Given one already-classified plan phase plus the resolved `WORKROOT` / `BASE_BRANCH` / `SANDBOX_TIER`, it composes a token-efficient implementer prompt, picks the model from the phase's own suggestion, and spawns exactly one implementer subagent, returning that agent's report. Do not invoke directly for ad-hoc edits or in response to a user's raw feature request; the conductor invokes it once per executable phase in {{PROJECT_NAME}}.
+disable-model-invocation: true
 ---
 
 # Implement one phase
 
 Execution unit invoked by [implement-plan](../implement-plan/SKILL.md) (and by [amend-plan](../amend-plan/SKILL.md) for `amend-existing` rewrites). One phase in → one implementer report out. This skill does **not** review, branch, push, or open PRs — those are [review-phase](../review-phase/SKILL.md) and [integrate-phase](../integrate-phase/SKILL.md). It also does **not** decide whether a phase runs — the conductor already filtered cross-repo / flag-removal phases.
 
+<!-- include: partials/dispatched-agent.md#CONDUCTOR_ENTRY_GUARD -->
+
 ## Inputs (passed by the conductor as data — this skill re-derives none of them)
 
 - `phase` record: `{ id, title, goal, body, spec_use_case, depends_on, wave, base_branch, crew_member, crew_tier, suggested_model_tier, reusable_skills, has_e2e, acceptance }`. `crew_member` / `crew_tier` come from the phase's `**Assigned to**:` line and the plan's **Crew** table; `suggested_model_tier` is the legacy path and is set only on a plan with no roster. Exactly one of the two is populated.

package/skills/vinta-derive-skills/resources/plan-execution/shell/implement-plan-template.md

@@ -1,6 +1,7 @@
 ---
 name: implement-plan
 description: Execute a phased implementation plan from `{{PLAN_DIR}}/` in {{PROJECT_NAME}} by orchestrating one subagent per phase (using whatever model the plan suggests and the runtime supports), running independent phases concurrently in their own worktree lanes when the plan's dependency graph allows it, pushing one branch per phase to {{CODE_HOST}}, and tracking progress. Use when the user says "implement the plan", "execute plan X", "start implementation", "run phase N of plan Y", "implement {feature} plan", or asks to drive a `*_IMPLEMENTATION_PLAN.md` file phase-by-phase. NOT for one-off changes, single-file edits, or work that doesn't have an existing plan. {{PR_POLICY_DESCRIPTION}}
+disable-model-invocation: true
 ---
 
 # Implement Plan
@@ -17,6 +18,8 @@ The conductor itself owns only: plan parsing, the dependency graph, phase classi
 
 Execution counterpart to [plan-feature](../plan-feature/SKILL.md). Plan = contract; this skill = build pipeline.
 
+<!-- include: partials/dispatched-agent.md#CONDUCTOR_ENTRY_GUARD -->
+
 ## Working assumptions
 
 - Repo: {{PROJECT_NAME}} ({{STACK_SUMMARY}}). Conventions: [AGENTS.md](../../../AGENTS.md).

package/skills/vinta-derive-skills/resources/plan-execution/shell/integrate-phase-template.md

@@ -1,6 +1,7 @@
 ---
 name: {{INTEGRATE_PHASE_NAME}}
 description: Internal integration step of [implement-plan] — NOT a standalone entry point. Pushes one reviewed phase along {{PROJECT_NAME}}'s commit strategy and opens (or updates) its PR through the prs-context file + bundled open-pr.sh — the only PR-creation path. The conductor passes the resolved `WORKROOT` / `BASE_BRANCH` and the PR / inline-comment policy; do not invoke directly to push arbitrary work.
+disable-model-invocation: true
 ---
 
 # Integrate one phase

package/skills/vinta-derive-skills/resources/plan-execution/shell/review-phase-template.md

@@ -1,12 +1,15 @@
 ---
 name: review-phase
 description: Internal review gate of [implement-plan] / [amend-plan] / [systematic-debugging] — NOT a standalone entry point. Runs the mandatory three-layer review (mechanical checks, plan-compliance walkthrough, independent reviewer subagent) plus the fix loop against one phase's diff in {{PROJECT_NAME}}, spawning an independent reviewer, sending findings back to the phase's own implementer to fix, and looping until all three layers are clean. The invoking conductor passes the diff, the phase body to walk against, and the resolved `WORKROOT`; do not invoke directly to "review my code" — use the project's standard code-review path for that.
+disable-model-invocation: true
 ---
 
 # Review one phase
 
 The single review implementation shared by every plan-execution conductor: [implement-plan](../implement-plan/SKILL.md) (after an implementer runs), [amend-plan](../amend-plan/SKILL.md) (after a rewrite), and [systematic-debugging](../systematic-debugging/SKILL.md) (against the fix diff). Read-only orchestration: this skill **never edits code** — every issue becomes a fix-up subagent task.
 
+<!-- include: partials/dispatched-agent.md#CONDUCTOR_ENTRY_GUARD -->
+
 ## Inputs (passed by the conductor)
 
 - The phase diff (on the current branch inside `WORKROOT`).