allye-opencode 1.2.7 → 1.3.0

package/dist/index.js

@@ -228,8 +228,7 @@ Before creating anything, have a conversation with the user to understand:
 5. **Are there constraints?** \u2014 Timeline, tech stack, dependencies, compliance
 
 <EXTREMELY_IMPORTANT>
-Do NOT jump to creating work items before you understand the business context.
-Ask questions. Clarify ambiguities. The quality of planning depends on the quality of understanding.
+Reach full understanding of the business context before creating any work item \u2014 ask questions and clarify ambiguities. The quality of planning depends on the quality of understanding.
 </EXTREMELY_IMPORTANT>
 
 <!-- adapted from bmad-code-org/BMAD-METHOD create-epics-and-stories (MIT) -->
@@ -311,19 +310,12 @@ Wait for the user to approve, modify, or add to this structure before proceeding
 
 ## Step 4: Check Board and Statuses
 
-Before creating items, understand the available statuses:
-
 \`\`\`
 work_statuses()
 board_columns()
 \`\`\`
 
-This ensures you know:
-- What status categories exist (backlog, todo, in_progress, etc.)
-- Which board columns are available
-- The correct status to assign to new items
-
-New items should typically be created in **backlog** or **todo** status.
+This surfaces the available status categories and board columns, so you know the correct status for new items \u2014 typically **backlog** or **todo**.
 
 ---
 
@@ -428,7 +420,7 @@ memory_save(
   title: "Planning \u2014 {Epic name} scope and decisions",
   content: "## Scope\\n{what was included/excluded and why}\\n\\n## Key decisions\\n- {decision 1}: {rationale}\\n- {decision 2}: {rationale}\\n\\n## Hierarchy\\n{the approved structure}\\n\\n## Open questions\\n{anything deferred}",
   tags: ["planning", "decision", "{epic-key}"],
-  work_item_id: "{epic uuid}"
+  sector: "decisions"
 )
 \`\`\`
 
@@ -453,9 +445,7 @@ Before considering product planning complete, verify:
 After items are approved and created, ask the user whether to generate a **\`planning-to-technical\`** handover (see the \`handover-protocol\` skill) for Technical Planning. Fill the template's \`Doc:\` line with the Discovery Doc reference if one exists upstream (or "Nenhum doc adicional" if not), and list every created **and** reused key \u2014 Technical Planning has no other way to know which items are which.`;
 var TECHNICAL_PLANNING = `# Technical Planning Workflow
 
-This skill guides you through taking a story and turning it into actionable tasks through a **Discussion Phase** \u2014 identifying gray areas, capturing decisions, and creating tasks with verifiable acceptance criteria.
-
-Use this when the user has a story and wants to: plan tasks, discuss approach, evaluate technical options, or break down implementation work.
+Turns a story into actionable tasks through a **Discussion Phase** \u2014 surfacing gray areas, capturing decisions, and writing tasks with verifiable acceptance criteria and a runnable verification command.
 
 **Never assume \u2014 always ask.** The user knows the direction they want, sometimes only after researching further. Your job is to surface the gray areas and present real options, not to quietly pick one and present it as the plan.
 
@@ -521,9 +511,9 @@ If tasks already exist, review them instead of creating new ones. The user may w
 ## Step 3: Discussion Phase
 
 <EXTREMELY_IMPORTANT>
-Do NOT create tasks before completing the discussion phase.
-The purpose of discussion is to surface ambiguity BEFORE committing to a plan.
-Skipping this leads to rework, wrong assumptions, and wasted effort.
+Complete the discussion phase \u2014 surfacing ambiguity before committing to a plan \u2014
+before creating any task. Skipping it leads to rework, wrong assumptions, and
+wasted effort.
 </EXTREMELY_IMPORTANT>
 
 ### 3.1 Identify Gray Areas
@@ -582,7 +572,7 @@ memory_save(
   title: "Decision \u2014 {short description}",
   content: "## Decision\\n{what was decided}\\n\\n## Classification\\n{locked | agent-discretion}\\n\\n## Why\\n{rationale}\\n\\n## Context\\nStory: {story key}\\nGray area: {what was ambiguous}",
   tags: ["decision", "{story-key}", "{topic}"],
-  work_item_id: "{story uuid}"
+  sector: "decisions"
 )
 \`\`\`
 
@@ -597,6 +587,11 @@ Before moving to task creation, confirm with the user:
 >
 > Are we good to proceed with task creation?"
 
+Also state the story's derived dispatch label: **AFK** if every task got a runnable
+verification command, **HITL** if any task declared \`verification: manual\`. The
+Orchestrator reads this rather than guessing, so a wrong label here becomes a story
+dispatched to an unattended pane that then sits waiting for a human who is not watching.
+
 ---
 
 ## Step 4: Create Tasks
@@ -606,7 +601,6 @@ Before moving to task creation, confirm with the user:
 Design tasks that are:
 
 - **Atomic** \u2014 Each task produces a single, verifiable outcome
-- **Ordered by dependency** \u2014 Independent tasks first, dependent tasks after
 - **Concrete** \u2014 No vague tasks like "set up the project" or "implement the feature"
 
 **Split by concern when a story spans them.** A story touching frontend, backend, and data modeling is usually 3+ tasks, not one \u2014 the Wave mechanic below (4.4) handles the ordering (e.g., data modeling before frontend when the payload shape is a hard dependency). These are illustrative categories, not a fixed taxonomy: decide the actual split with the user, scenario by scenario.
@@ -617,9 +611,42 @@ Design tasks that are:
 ### 4.2 Deep Work Rule
 
 <HARD-GATE>
-Every task MUST have verifiable acceptance criteria in its description.
-A task without acceptance criteria is not a task \u2014 it's a wish.
-Do not create tasks that cannot be objectively verified as complete.
+Every task carries verifiable acceptance criteria in its description \u2014 a task
+without them is not a task, it's a wish.
+</HARD-GATE>
+
+### 4.2.1 Verification Rule
+
+<HARD-GATE>
+Every task carries a \`## Verification\` block: either a command that runs as
+written, or \`verification: manual\` with the procedure. A task with neither
+is not a task \u2014 a criterion nobody can check is a criterion nobody will.
+
+Write the command while you still have the design in your head. Deferring it
+to the Executor means it gets written by someone reconstructing your intent
+from a description.
+
+\`verification: manual\` is a legitimate answer for visual, infrastructure, and
+one-off work \u2014 see \`verification-loop\` \xA74. It is not a shortcut for "I did not
+want to think of a command": declaring it makes the whole story HITL, which
+costs the Orchestrator its ability to dispatch that story unattended.
+</HARD-GATE>
+
+### 4.2.2 No Placeholders
+
+<HARD-GATE>
+A task description contains what someone needs to do the work, not a promise to supply it
+later. These are defects in a task, not shorthand:
+
+- "TBD", "TODO", "details to follow"
+- "Add appropriate error handling" \u2014 which errors, handled how?
+- "Handle edge cases" \u2014 which ones? An edge case nobody named is an edge case nobody covers.
+- "Similar to {other task}" \u2014 say it again here. Tasks are read in isolation and out of order.
+- A criterion naming a type, function, or file that no task defines and no \`Interfaces\`
+  block produces.
+
+Each of these reads as complete and defers the actual decision to whoever implements \u2014 who
+has less context than you do right now, and no way to ask you.
 </HARD-GATE>
 
 ### 4.3 Task Description Template
@@ -633,8 +660,13 @@ Do not create tasks that cannot be objectively verified as complete.
 - [ ] {Criterion 2}
 - [ ] {Criterion 3}
 
-## How to Verify
-{How to confirm this task is done \u2014 e.g., run tests, check endpoint, verify UI}
+## Verification
+{The exact command, runnable as written. It must be red-capable, deterministic,
+fast, and agent-runnable \u2014 see the \`verification-loop\` skill \xA71.}
+
+{or, when no such command exists:}
+verification: manual
+{the exact procedure a human follows, and what they should observe}
 
 ## Files Likely Involved
 - {file/path/1}
@@ -643,10 +675,21 @@ Do not create tasks that cannot be objectively verified as complete.
 ## Dependencies
 - {Depends on TASK-XX} or "None \u2014 can be done independently"
 
+## Interfaces
+**Consumes:** {names, types, and signatures this task calls that another task in this story
+produces \u2014 or "Nothing from other tasks"}
+**Produces:** {names, types, and signatures other tasks will call. Exact, not descriptive:
+\`createSession(userId: string): Session\`, not "a session creator".}
+
 ## Decisions Applied
 - {Reference locked/agent-discretion decisions from discussion phase}
 \`\`\`
 
+The \`Interfaces\` block exists because whoever implements a task sees **only that task**.
+Dependencies tell them what must finish first; interfaces tell them what to call when it
+has. Writing "a session creator" instead of the signature moves the naming decision to
+whoever implements second, and they will name it something else.
+
 ### 4.4 Analyze Dependencies
 
 Group tasks into **waves** based on dependencies:
@@ -695,13 +738,12 @@ work_bulk_create(work_items: [
 
 ## Step 5: Move Story to In Progress
 
-Once tasks are created and the plan is approved:
-
 \`\`\`
 work_status_next(id: "{story uuid}")
 \`\`\`
 
-This moves the story forward in the board progression (typically from backlog/todo to in_progress).
+Once tasks are created and the plan is approved, this moves the story forward in the
+board progression (typically backlog/todo \u2192 in_progress).
 
 ---
 
@@ -714,8 +756,7 @@ memory_save(
   title: "Technical Plan \u2014 {STORY-KEY} {story title}",
   content: "## Story\\n{story key and title}\\n\\n## Decisions\\n{list of locked and agent-discretion decisions}\\n\\n## Task Breakdown\\n{wave structure with task keys}\\n\\n## Execution Order\\n{which tasks first, which depend on what}\\n\\n## Risks\\n{identified risks or uncertainties}",
   tags: ["planning", "technical-plan", "{story-key}"],
-  work_item_id: "{story uuid}",
-  sprint_id: "{sprint uuid if applicable}"
+  sector: "plans"
 )
 \`\`\`
 
@@ -730,6 +771,10 @@ Before considering technical planning complete, verify:
 - [ ] Gray areas were identified and discussed with the user
 - [ ] All decisions are classified (locked vs agent-discretion) and saved as memories
 - [ ] Tasks have verifiable acceptance criteria
+- [ ] Every task has a \`## Verification\` block \u2014 a runnable command, or \`verification: manual\` with a procedure
+- [ ] Every task's \`Interfaces\` block names exact signatures, not descriptions
+- [ ] No task description contains a placeholder or an unnamed edge case
+- [ ] The story's AFK/HITL label is derived and stated
 - [ ] Dependencies are mapped and wave structure is defined
 - [ ] Tasks are created in Allye with proper parent relationship
 - [ ] Story is moved to in_progress
@@ -786,28 +831,102 @@ Before dispatching, do a quick completeness check on the story's tasks: does eac
 <!-- adapted from EveryInc/compound-engineering-plugin lfg (MIT) \u2014 verify the previous step's artifact before proceeding -->
 When the execution report comes back, don't take "done" at face value \u2014 check the report actually contains what it should before acting on it: files changed listed, tasks reported per acceptance criterion, not just a blanket "finished." An incomplete report is itself a signal to ask for more detail, not something to wave through.
 
-Once the report is genuinely complete, dispatch the \`reviewer\` subagent \u2014 in parallel, automatically, no need to ask the user first. Review never needs to pause and ask anyone anything, which is what makes it always dispatch-appropriate. Pass it: the active team (id and name), the story key, the task keys, and the files changed from the execution report.
+Once the report is genuinely complete, dispatch **both** \`reviewer-standards\` and
+\`reviewer-spec\` \u2014 in parallel, in the same turn, automatically, without asking the user
+first. Review never needs to pause and ask anyone anything, which is what makes it always
+dispatch-appropriate.
+
+Pass each the same fields: the active team (id and name), the story key, the task keys,
+and the files changed from the execution report. \`reviewer-spec\` additionally gets the
+per-criterion verification evidence the report carried \u2014 it reviews against that evidence,
+so a report that omits it produces a review that cannot confirm anything.
 
 ## 6. React to review
 
-Reviewer returns its standard \u2705/\u26A0\uFE0F/\u274C-per-task output (unchanged from the \`review\` skill \u2014 no new format to learn).
+Two reports arrive, one per axis. **Record both verbatim.** Never merge them, never
+rerank findings across them, never resolve a disagreement between them \u2014 each axis
+reviewed something the other deliberately ignored, so a disagreement is not a conflict
+to settle.
+
+The *findings* stay separate. The *decision* is single, and combines them:
+
+| Standards | Spec | Outcome |
+|---|---|---|
+| \u2705 | \u2705 | Advance the task through the team's pipeline per \xA77 \u2014 one status at a time, stopping at the first gate you cannot satisfy |
+| \u26A0\uFE0F only | \u2705 | Advance as above; record the warnings as a note so they are not lost |
+| \u2705 | \u26A0\uFE0F only | Advance as above; record the warnings as a note |
+| \u274C | any | Correction round |
+| any | \u274C | Correction round |
 
-- **All \u2705** \u2192 move each approved task the rest of the way to \`done\` yourself \u2014 the Executor only advanced it as far as \`review\` \u2014 then proceed to the status cascade (\xA77).
-- **\u26A0\uFE0F warnings only, no \u274C** \u2192 a warning isn't a blocker: proceed to the status cascade (\xA77) the same as All \u2705. Don't silently discard the warnings and don't force an unnecessary correction round either \u2014 record them as a note (in the task's context, or as a memory) so they're not lost.
-- **Any \u274C** \u2192 the failed task simply stays at \`review\` while the correction round runs. No backward move is needed (or possible \u2014 \`work_status_next\` only moves forward, per \`allye-board-progression\`): the task never reached \`done\`, because reaching \`done\` requires your move after Reviewer \u2705. Send corrections back using \`references/correction.md\`'s exact fields (only the failed findings, the correction-round count, the story reference \u2014 never a full re-brief of the story): emit it as a \`correction\` handover. Loop back to \xA75 once the next execution report arrives.
+A \u274C on either axis triggers a correction round on its own. **One axis passing never offsets the other failing** \u2014 that offsetting is exactly the masking the split exists to
+prevent. The failed task simply stays at \`review\` while the correction round runs: no
+backward move is needed (or possible \u2014 \`work_status_next\` only moves forward, per
+\`allye-board-progression\`), because reaching \`done\` requires your move after both axes
+pass. Loop back to \xA75 once the next execution report arrives.
 
 <!-- adapted from bmad-code-org/BMAD-METHOD correct-course (MIT) \u2014 structured change-impact analysis for corrections that ripple beyond one task -->
 **Before emitting a routine correction, check whether the finding is actually local.** Most \u274C findings are narrow \u2014 a missed edge case, a broken test. But if a finding suggests something baked into the technical plan itself was wrong (a data model assumption, an architecture choice that doesn't hold), don't just patch around it silently in a correction handover \u2014 that ripples into other tasks and stories that assumed the same thing. Surface it to the user explicitly before continuing; a silent local patch over a wrong foundational assumption just relocates the bug.
 
-**Decided (spec review, 2026-07-12): at most 2 correction handovers are ever emitted for the same task.** Track how many correction handovers this task has already received. If a task that has already received 2 correction handovers comes back \u274C again \u2014 i.e., this is the 3rd review failure on that task \u2014 do not emit a 3rd correction handover: stop and escalate to the user instead. Two correction rounds failing for different specific reasons is normal; a third failure usually means something deeper is being missed, and it's worth a human look before burning another round.
+The correction handover carries only the failing axis's \u274C findings, quoted literally, using \`references/correction.md\`'s exact fields (only the failed findings, the correction-round count, the story reference \u2014 never a full re-brief of the story).
+
+**Decided (spec review, 2026-07-12): at most 2 correction handovers are ever emitted for the same task.** The existing two-correction maximum counts rounds **per task**, regardless of which axis produced them: a task corrected once for standards and once for spec has used
+both rounds, and a third failure escalates to the human. Two correction rounds failing for
+different specific reasons is normal; a third failure usually means something deeper is
+being missed, and it's worth a human look before burning another round.
 
 ## 7. Status cascade \u2014 continuous, not just at the end
 
-Apply this at every level, as work actually completes \u2014 not once at the tail end of the whole feature:
+Both review axes clear (\xA76) \u2192 the task is ready to leave the review gate. **Where it goes next
+depends on the team's pipeline, not on a status this skill can name.**
+
+1. **Advance one status.** \`work_status_next(id)\`. Then **read the item back** \u2014 \`work_get\` \u2014
+   and see where you actually landed. Do not predict: \`work_statuses()\` does not return
+   position or pipeline, and \`board_columns()\` does not map statuses to columns, so the next
+   status is not computable from the MCP surface (see \`board-progression\` \xA71).
+
+2. **Did you land on a done-category status?** Then the task is finished; go to step 5.
+
+3. **Otherwise, consult the pipeline handoff table** in the \`Allye Delivery Configuration\`
+   Core Document (\`user_config\`, loaded by \`initialize\`).
+
+   - **\`agent\`** \u2014 satisfy it, then return to step 1. Satisfying means running the command the
+     table names and reading its output, under the bound in \`verification-loop\` \xA73. Red at the
+     bound is a correction round, not a pass.
+   - **\`ci\`** \u2014 you do not act. Report that the task is waiting on the named external signal
+     and move to the next story; revisit when the signal arrives.
+   - **\`human\`**, or **any status not in the table** \u2014 stop. Name the status, say who owns it,
+     and leave the task exactly where it is.
 
-1. Reviewer returns \u2705 on a task (criteria met, tests pass) \u2192 **you** move it from \`review\` to \`done\` via \`work_status_done\` (which also records \`completed_at\`) \u2014 the Executor deliberately left it at \`review\`, and this last move is exclusively yours, made only after Reviewer \u2705 \u2192 \`work_children\` on the parent story \u2192 all done? \u2192 \`work_status_done\` the story.
-2. Story done \u2192 \`work_children\` on the parent feature \u2192 all done? \u2192 \`work_status_done\` the feature.
-3. Feature done \u2192 \`work_children\` on the parent epic \u2192 all done? \u2192 \`work_status_done\` the epic.
+4. **A status you do not recognise and the table does not cover** is a stop, and also a
+   question: ask the user once who satisfies it, record the answer in the delivery
+   configuration, and continue. Never ask twice.
+
+5. **Cascade upward, and only upward.** \`work_children\` the parent; if **every** child is in
+   the done category, advance the parent the same way \u2014 one step, read back, consult the table.
+   A parent stops for the same reasons a child does.
+
+<HARD-GATE>
+**Never call \`work_status_done\` to leave a pipeline you cannot finish.** From four statuses
+away it records "done" for work that never passed the gates between \u2014 which is exactly how a
+story came to be closed with seven of its fifteen tasks still at the review gate.
+
+Use it only when the item's next status **is** the done status. When you cannot finish, stopping
+is the correct outcome, not a failure to report.
+</HARD-GATE>
+
+## 7.2 Announce where delivery stopped
+
+When a story's tasks are all parked at the same gate, say so once, plainly: which gate, who
+owns it, and what unblocks it. Repeat it in the session-state memory (\xA710) so a resumed
+Orchestrator does not rediscover the boundary by trying to cross it.
+
+A story left open at a gate is **not** an incomplete delivery. It is delivery reporting its
+true position. The failure mode this replaces \u2014 closing the story to make the board look
+finished \u2014 cost a real board seven tasks' worth of untracked work.
+
+When delivery stops at a gate, the branch stops with it \u2014 see \`branch-landing\` \xA71. Say that
+explicitly in the announcement: the story is parked, and so is its code. A human reading only
+the board would otherwise assume the branch already landed.
 
 ## 8. Epic completion is manual
 
@@ -823,9 +942,8 @@ Unclear assignee, no active sprint to assign into, conflicting or unexpected sta
 Search at start (\xA71). Save session state before ending \u2014 current position in the feature (which story/wave), what's been dispatched, what's pending review, any escalations raised, correction-round count per task (so the 2-correction-max escalation rule survives a resumed session). If a correction round revealed something worth remembering beyond this session (a wrong assumption, a pattern), save it as its own memory in the appropriate sector, per the \`allye-memory-protocol\` skill \u2014 don't let it live only in this session's state snapshot.`;
 var TECHNICAL_DEVELOPMENT = `# Technical Development Workflow
 
-This skill guides you through implementing a task with discipline: read existing code first, write tests, implement, refactor, and track progress in Allye.
-
-Use this when the user wants to: write code, implement a task, fix a bug, add functionality, or develop features.
+Implements one task with discipline: read the existing code first, drive it with TDD,
+verify it actually works, and track progress in Allye.
 
 **Scope, if you arrived via a \`story-execution\` or \`correction\` handover (see \`handover-protocol\`):** read only the one story and its tasks named in the handover \u2014 nothing else. A \`correction\` handover carries only the failed findings, not the whole story again; fix exactly what it lists.
 
@@ -935,6 +1053,70 @@ Do not read endlessly in search of additional context. Reading is preparation, n
 
 ---
 
+## Step 4.5: Plan the Implementation
+
+You have read the code and written none. This is where you state *how* you will build it,
+and check that statement against what was asked for \u2014 while being wrong still costs a
+paragraph rather than a branch.
+
+### Write the plan
+
+Per task in this story:
+
+- **Approach** \u2014 the shape of the change, in a sentence or two.
+- **Files** \u2014 what you will create or modify. Names, never line numbers; the tree moves.
+- **Interfaces produced** \u2014 the names, types, and signatures other tasks in this story will
+  call. Whoever implements a neighbouring task sees only their own task description, so
+  this is the only place they learn what to call.
+- **How each criterion goes green** \u2014 for every acceptance criterion, which step makes its
+  \`## Verification\` command pass. A criterion with no step against it is the finding this
+  whole exercise exists to produce.
+
+Save it:
+
+\`\`\`
+memory_save(
+  title: "Implementation Plan \u2014 {STORY-KEY} {story title}",
+  content: "## Per task\\n{approach, files, interfaces produced, criterion \u2192 step}\\n\\n## Order\\n{which task first, and why}\\n\\n## Open questions\\n{anything planning did not settle, or 'None'}",
+  tags: ["plan", "implementation", "{story-key}"],
+  sector: "plans"
+)
+\`\`\`
+
+It outlives the session. A resumed Executor reads what was intended rather than inferring
+it from half-written code, and \`reviewer-spec\` can compare the implementation against the
+plan and not only against the criteria.
+
+### Validate it
+
+<HARD-GATE>
+Three checks, run every time, before writing any code:
+
+1. **Coverage** \u2014 every acceptance criterion, in every task, has a step that produces it.
+2. **Decisions** \u2014 every locked decision from planning is respected. A locked decision was
+   chosen by the human. A plan that quietly departs from one is a defect whether or not the
+   resulting code works.
+3. **Closure** \u2014 no step depends on something the plan never defines. If a type, function,
+   file, or value appears as a dependency and never as an output, the plan has a hole in it.
+
+A failure is reported as \`\u274C blocked\` **before any code exists**, naming which criterion or
+decision has nothing behind it. This is the same halt-and-report contract you already carry,
+fired at the cheapest possible moment.
+</HARD-GATE>
+
+### Whether the approach is right
+
+The three checks above are mechanical. Whether the approach is a *good* one is judgement,
+and who supplies it follows the story's dispatch label (see \`verification-loop\` \xA74):
+
+- **AFK** \u2014 self-validation is enough. Run the three checks and proceed.
+- **HITL** \u2014 put the plan in front of the user and wait before writing anything.
+- **Either label**, if planning surfaced a decision the discussion phase never covered \u2014
+  stop and raise it regardless. A decision discovered while planning is precisely the case
+  the label could not have anticipated.
+
+---
+
 ## Step 5: TDD \u2014 Test-Driven Development
 
 <!-- full discipline lives in the tdd-workflow skill, aligned with superpowers:test-driven-development (MIT) -->
@@ -986,6 +1168,21 @@ With green tests as your safety net, improve the code:
 
 Run tests after every change. If a test fails, you broke something \u2014 fix it before continuing.
 
+### Verification Phase \u2014 run the task's loop
+
+TDD proved each behaviour as you built it. This proves the **task's acceptance
+criteria**, which is a different claim.
+
+Run the command from the task's \`## Verification\` block. Read its actual output.
+If it is red, fix and run it again, under the bound in \`verification-loop\` \xA73:
+three attempts on one failure, or two byte-identical outputs, whichever comes
+first. On hitting the bound, stop and carry the command and its literal output
+into your report \u2014 do not summarise the output.
+
+If the task declares \`verification: manual\`, follow its procedure and record what
+you observed. You have not run a loop; say so plainly in the report rather than
+implying one passed.
+
 ### Repeat
 
 Write the next test for the next behavior. Continue the cycle until all acceptance criteria are met.
@@ -1042,6 +1239,10 @@ Examples of things that need human action:
 <!-- adapted from superpowers:verification-before-completion (MIT) \u2014 evidence before assertions -->
 **Evidence before assertions.** Don't advance a task because it looks right \u2014 run the tests, read the actual output, and confirm each acceptance criterion against that output before proceeding. "Should work" is not the same as "ran and passed."
 
+The task's verification command is what supplies that evidence. Advancing a task to
+\`review\` without having run it green \u2014 or without having recorded a \`verification:
+manual\` observation \u2014 is the assertion this rule exists to forbid.
+
 Once all acceptance criteria are verifiably met and tests pass:
 
 \`\`\`
@@ -1061,8 +1262,7 @@ memory_save(
   title: "Implementation \u2014 {TASK-KEY} {short description}",
   content: "## What was done\\n{summary of changes}\\n\\n## Key decisions during implementation\\n{any new decisions made}\\n\\n## Files changed\\n- {file 1}\\n- {file 2}\\n\\n## Gotchas\\n{anything surprising or non-obvious encountered}\\n\\n## Tests\\n{what was tested, any notable test patterns}",
   tags: ["development", "implementation", "{story-key}", "{task-key}"],
-  work_item_id: "{task uuid}",
-  sprint_id: "{sprint uuid if applicable}"
+  sector: "knowledge"
 )
 \`\`\`
 
@@ -1076,7 +1276,16 @@ After completing a task, pick the next one from the **handover's own wave-ordere
 
 - If there are more tasks in the current wave (per the handover's list) \u2192 pick one
 - If the current wave is done \u2192 move to the next wave (per the handover's list)
-- If every task in the story has reached \`review\` (implementation complete, awaiting Reviewer) \u2192 emit an **\`execution-report\`** handover (see the \`handover-protocol\` skill) back to the Orchestrator
+- If every task in the story has reached \`review\` (implementation complete, awaiting Reviewer) \u2192 **run the story loop, then** emit an **\`execution-report\`** handover (see the \`handover-protocol\` skill) back to the Orchestrator.
+
+  The story loop runs the story's own acceptance criteria end to end, under the same
+  bound as the task loop. Every task green does not mean the story works \u2014 nothing
+  else checks this, which is exactly why it runs here.
+
+  A red story loop is reported as red **even when every task is green**. That
+  combination is a finding, not a contradiction to resolve: it usually means the task
+  breakdown missed an integration, and the Orchestrator needs to see it rather than
+  receive a clean report.
 
 Use \`work_children(id: "{story uuid}")\` only to **verify/check the status** of tasks already in the handover's list (e.g. confirming a dependency reached \`review\`) \u2014 never to discover new tasks to work on. If \`work_children\` reveals a task under this story that is **not** in the handover's task list, do not execute it \u2014 it wasn't in scope when the handover was dispatched. Instead, note it as an open question ("Open questions") in the \`execution-report\` handover so the Orchestrator can decide whether to bring it into scope.
 
@@ -1091,9 +1300,13 @@ For each task, verify:
 - [ ] Dependencies are complete
 - [ ] Task moved to in_progress
 - [ ] Existing code was read before writing new code
+- [ ] An implementation plan was written and saved to the \`plans\` sector before any code
+- [ ] Coverage, decisions, and closure all checked against that plan
 - [ ] TDD cycle completed (or tests written after for non-TDD-suitable tasks)
 - [ ] All acceptance criteria are met
 - [ ] Tests pass
+- [ ] The task's verification command ran green, or its manual procedure was observed and recorded
+- [ ] The story loop ran green before the report was emitted
 - [ ] Task moved to review (never directly to done \u2014 that's the Orchestrator's move after Reviewer \u2705)
 - [ ] Implementation memory saved (if non-trivial)
 
@@ -1101,13 +1314,19 @@ For each task, verify:
 
 ## What Comes Next
 
-Emit the \`execution-report\` handover: files changed, tests added, status per acceptance criterion (not a blanket "done"), any new decisions made along the way, and any open questions. The Orchestrator decides from there whether to dispatch Reviewer or, if this is a \`correction\` round, loop back with more specific findings.`;
+Emit the \`execution-report\` handover: files changed, tests added, status per acceptance criterion (not a blanket "done"), any new decisions made along the way, and any open questions. The Orchestrator decides from there whether to dispatch Reviewer or, if this is a \`correction\` round, loop back with more specific findings.
+
+**If you are working in a git worktree**, the Orchestrator that dispatched you owns landing
+the branch \u2014 do not merge, do not remove the worktree, do not close your own pane. Name the
+branch in your \`execution-report\` so it knows what to land.
+
+**If you are working directly in the main checkout** and no Orchestrator is coordinating, the
+branch is yours to finish: load the \`branch-landing\` skill once the story's tasks are through
+review.`;
 var TECHNICAL_REVIEW = `# Technical Review Workflow
 
 This skill guides you through reviewing implemented code with full context \u2014 the decisions made during planning, the acceptance criteria defined for each task, and the architectural constraints captured in memories.
 
-Use this when the user wants to: review code, check implementation quality, validate against requirements, or prepare for delivery.
-
 ---
 
 ## Workflow Overview
@@ -1143,47 +1362,41 @@ This gives you:
 
 ---
 
-## Step 2: Review Each Task
-
-For each completed task, verify:
+## Step 2: Review Each Task \u2014 Two Axes
 
-### 2.1 Acceptance Criteria
+<!-- adapted from mattpocock/skills code-review (MIT) -->
 
-Check the task description's acceptance criteria one by one:
+Review runs as two independent passes. Keep them separate on the page and separate in
+your head, and **do not reconcile them**: a change can pass one and fail the other, and
+reporting them together is what lets one hide the other.
 
-- [ ] Is each criterion met?
-- [ ] Can each criterion be verified (test, endpoint, UI)?
-- [ ] Are there criteria that were silently skipped?
+> Code that follows every standard but implements the wrong thing \u2192 **Standards pass,
+> Spec fail.**
+> Code that does exactly what was asked but breaks the project's conventions \u2192 **Spec
+> pass, Standards fail.**
 
-### 2.2 Code Quality
+### Axis 1 \u2014 Standards: how it is written
 
-Review the actual code changes against these standards:
+Load team standards first (\`skill_list\` \u2192 \`skill_get\`); they override everything below.
+Then: consistency with existing patterns, security, error handling, naming, and test
+quality \u2014 do the tests assert behaviour rather than implementation, cover edge cases,
+and break for the right reasons?
 
-| Check | What to look for |
-|-------|-----------------|
-| **Correctness** | Does it do what the acceptance criteria say? |
-| **Consistency** | Does it follow existing patterns in the codebase? |
-| **Simplicity** | Is it the simplest solution that works? No over-engineering? |
-| **Test coverage** | Are there tests? Do they test behavior, not implementation details? |
-| **Security** | No injection vulnerabilities, no exposed secrets, proper auth checks? |
-| **Error handling** | Are failure cases handled? Are errors informative? |
-| **Naming** | Are variables, functions, and files named clearly? |
+Full checklist and the baseline smells: \`agents/reviewer-standards.md\`.
 
-### 2.3 Decision Compliance
+### Axis 2 \u2014 Spec: whether it is what was asked for
 
-Check that the implementation respects the decisions from the planning phase:
+Every acceptance criterion, one at a time, against the verification evidence the
+execution report carried. A criterion reported met with no command output or observed
+procedure behind it is **unverified**, and gets reported as unverified rather than met.
+Then locked-decision compliance \u2014 any deviation is a defect \u2014 and unrequested scope.
 
-- **Locked decisions** \u2014 Were they followed exactly? Any deviation is a defect.
-- **Agent-discretion decisions** \u2014 Were they reasonable? Is the rationale documented?
+Full checklist: \`agents/reviewer-spec.md\`.
 
-### 2.4 Test Quality
+### Reporting
 
-Review the tests themselves:
-
-- Do tests describe behavior (what), not implementation (how)?
-- Are edge cases covered?
-- Can tests break for the right reasons (behavior changed) and not for the wrong ones (refactoring)?
-- Are there tests that test nothing meaningful (e.g., testing that a mock returns what you told it to)?
+Two reports, never merged, never reranked. The decision that combines them belongs to
+the Orchestrator \u2014 see \`orchestrator\` \xA76.
 
 ---
 
@@ -1196,7 +1409,7 @@ memory_save(
   title: "Review \u2014 {STORY-KEY} approved",
   content: "## Review Summary\\nAll tasks reviewed and approved.\\n\\n## Tasks Reviewed\\n- {TASK-1}: \u2705 Criteria met, tests pass\\n- {TASK-2}: \u2705 Criteria met, tests pass\\n\\n## Notes\\n{any observations for future reference}",
   tags: ["review", "approved", "{story-key}"],
-  work_item_id: "{story uuid}"
+  sector: "knowledge"
 )
 \`\`\`
 
@@ -1227,7 +1440,7 @@ memory_save(
   title: "Review \u2014 {STORY-KEY} changes requested",
   content: "## Findings\\n{detailed findings per task}\\n\\n## Required Changes\\n- {change 1}\\n- {change 2}\\n\\n## Approved Tasks\\n- {list of tasks that passed}",
   tags: ["review", "changes-requested", "{story-key}"],
-  work_item_id: "{story uuid}"
+  sector: "knowledge"
 )
 \`\`\`
 
@@ -1254,11 +1467,11 @@ If you can run the test suite, do it:
 
 - [ ] Story and all tasks loaded
 - [ ] Planning decisions and implementation memories retrieved
-- [ ] Each task reviewed against acceptance criteria
-- [ ] Code quality checked (correctness, consistency, simplicity, security)
-- [ ] Locked decisions verified as respected
-- [ ] Tests reviewed for quality and coverage
-- [ ] Findings documented and saved as memory
+- [ ] Axis 2: each task's acceptance criteria checked against its verification evidence
+- [ ] Axis 2: locked decisions verified as respected
+- [ ] Axis 1: consistency, security, error handling, and naming checked
+- [ ] Axis 1: tests reviewed for quality and coverage
+- [ ] Findings documented and saved as memory, two axes kept separate
 - [ ] Tests run and passing
 
 ---
@@ -1270,7 +1483,7 @@ If the review passes, transition to **Delivery** \u2014 load the \`delivery\` sk
 If changes are needed, the developer addresses the findings (back to **Technical Development**), then returns here for re-review.`;
 var TECHNICAL_DELIVERY = `# Technical Delivery Workflow
 
-This skill guides you through the final steps of delivering a story: verifying all tasks are complete, closing the story, updating documentation, and saving a final delivery memory.
+This skill finalizes a story after every task has passed review \u2014 closing it out, documenting what shipped, and clearing loose ends.
 
 Use this when: all tasks for a story are implemented and reviewed, and the user is ready to finalize delivery.
 
@@ -1293,9 +1506,15 @@ work_children(id: "{story uuid}")
 \`\`\`
 
 <HARD-GATE>
-Do NOT close the story if any task is not in "done" status.
-Every task must be completed and verified before the story can be delivered.
-If tasks are incomplete, go back to Technical Development or Technical Review.
+Close the story only once every task is completed, verified, and in "done" status.
+If any task is incomplete, route back to Technical Development or Technical Review instead of closing.
+
+"Done" means the **done category**, not the last status an agent could reach. On a pipeline
+with stages after review, a task parked at a gate the team satisfies by hand is not done \u2014 it
+is waiting, and the story waits with it.
+
+If tasks are parked, close-out is not blocked by an oversight. It is **not yet due**. Say which
+gate they are waiting at and stop; do not close the story to tidy the board.
 </HARD-GATE>
 
 ### Verification checklist
@@ -1332,6 +1551,25 @@ work_status_done(id: "{feature uuid}")
 
 ---
 
+## Step 2.5: Land the Code
+
+The story is closed in Allye. The code is still on a branch.
+
+Load the \`branch-landing\` skill and follow it. It asks how the work should land \u2014 pull
+request, local merge, or left alone \u2014 and carries the sequence that gets it there without
+losing anything.
+
+<HARD-GATE>
+Do not skip this because the story is already closed. Closing the item and landing the code
+are different acts, and doing the first without the second produces the worst available
+state: a board that says delivered and a base branch that does not have the work.
+
+If the story reached this skill while still parked at a pipeline gate, it should not have \u2014
+see Step 1. The branch stays where it is.
+</HARD-GATE>
+
+---
+
 ## Step 3: Update Documentation
 
 If the delivered work introduced or changed functionality that should be documented:
@@ -1397,10 +1635,9 @@ Save a final summary of what was delivered:
 \`\`\`
 memory_save(
   title: "Delivered \u2014 {STORY-KEY} {story title}",
-  content: "## What was delivered\\n{summary of the feature/change}\\n\\n## Tasks completed\\n- {TASK-1}: {title}\\n- {TASK-2}: {title}\\n- {TASK-3}: {title}\\n\\n## Key decisions\\n{important decisions from planning and implementation}\\n\\n## Documentation\\n{what was documented, or 'No documentation needed'}\\n\\n## Lessons learned\\n{anything worth remembering for similar work in the future}",
+  content: "## What was delivered\\n{summary of the feature/change}\\n\\n## Tasks completed\\n- {TASK-1}: {title}\\n- {TASK-2}: {title}\\n- {TASK-3}: {title}\\n\\n## Key decisions\\n{important decisions from planning and implementation}\\n\\n## Documentation\\n{what was documented, or 'No documentation needed'}\\n\\n## Where the code landed\\n{branch name, and the merge commit or PR reference, and the base it landed on \u2014 or \\"not yet landed: {reason}\\"}\\n\\n## Lessons learned\\n{anything worth remembering for similar work in the future}",
   tags: ["delivery", "completed", "{story-key}", "{feature-key}"],
-  work_item_id: "{story uuid}",
-  sprint_id: "{sprint uuid if applicable}"
+  sector: "knowledge"
 )
 \`\`\`
 
@@ -1410,6 +1647,7 @@ memory_save(
 
 - [ ] All tasks verified as done
 - [ ] Story moved to done
+- [ ] The code landed, or the reason it has not is recorded
 - [ ] Feature moved to done (if all stories complete)
 - [ ] Documentation created or updated (if applicable)
 - [ ] Related TODOs cleaned up
@@ -1425,13 +1663,13 @@ The story is delivered. The user can:
 - **Start a new initiative** \u2192 Back to Product Planning from scratch`;
 var TDD_WORKFLOW = `# TDD Workflow
 
-This skill defines the Test-Driven Development discipline for implementing code with Allye workflows. TDD is not about writing tests \u2014 it's about **designing code through tests**.
+TDD is not about writing tests \u2014 it's about **designing code through tests**.
 
 ---
 
 ## 1. TDD Detection Heuristic
 
-Before implementing anything, ask yourself:
+Before implementing anything, ask:
 
 > **Can I write \`expect(fn(input)).toBe(output)\` before writing \`fn\`?**
 
@@ -1468,12 +1706,11 @@ The only question is whether the test comes before or after the implementation.
 
 ## 2. The Red-Green-Refactor Cycle
 
-### Red \u2014 Write a Failing Test
+### Red \u2014 write a failing test
 
-Write a test that describes the behavior you want:
+Write a test that describes the target behavior, not the implementation:
 
 \`\`\`javascript
-// Good: tests WHAT, not HOW
 test("should return 404 when user not found", async () => {
   const response = await request(app).get("/users/nonexistent");
   expect(response.status).toBe(404);
@@ -1481,19 +1718,9 @@ test("should return 404 when user not found", async () => {
 });
 \`\`\`
 
-\`\`\`python
-# Good: tests behavior, not implementation
-def test_calculate_discount_for_premium_user():
-    user = User(tier="premium")
-    order = Order(total=100.00)
-    assert calculate_discount(user, order) == 15.00
-\`\`\`
-
-**Run the test. It MUST fail.** If it passes:
-- The functionality already exists \u2014 don't reimplement it
-- The test is wrong \u2014 it's not testing what you think
+**Run the test. It MUST fail.** If it passes, either the functionality already exists (don't reimplement it) or the test is wrong (it's not testing what you think).
 
-### Green \u2014 Make It Pass
+### Green \u2014 make it pass
 
 Write the **minimum code** to make the test pass:
 
@@ -1508,17 +1735,11 @@ Rules for the Green phase:
 
 **Run the test. It MUST pass.**
 
-### Refactor \u2014 Clean Up
+### Refactor \u2014 clean up
 
-With green tests as your safety net:
+With green tests as your safety net: remove duplication, improve naming, simplify logic, extract functions where the code is too long, apply patterns where they genuinely help.
 
-- Remove duplication
-- Improve naming
-- Simplify logic
-- Extract functions if the code is too long
-- Apply patterns where they genuinely help
-
-**Run tests after EVERY change.** If a test fails, you broke something \u2014 undo and try again.
+**Run tests after EVERY change.** A failing test means you broke something \u2014 undo and try again.
 
 ### Repeat
 
@@ -1526,55 +1747,12 @@ Write the next test for the next behavior. Continue the cycle until all acceptan
 
 ---
 
-## 3. Test Quality Guidelines
-
-### Write tests that describe behavior
-
-\`\`\`javascript
-// Bad: tests implementation details
-test("should call userRepository.findById", () => { ... });
-
-// Good: tests observable behavior
-test("should return user profile for valid ID", () => { ... });
-\`\`\`
-
-### One assertion per concept
-
-\`\`\`python
-# Bad: testing multiple unrelated things
-def test_user_creation():
-    user = create_user("alice", "alice@example.com")
-    assert user.name == "alice"
-    assert user.email == "alice@example.com"
-    assert user.created_at is not None
-    assert send_welcome_email.called  # different concern!
-
-# Good: separate tests for separate concepts
-def test_user_created_with_correct_fields():
-    user = create_user("alice", "alice@example.com")
-    assert user.name == "alice"
-    assert user.email == "alice@example.com"
-
-def test_welcome_email_sent_on_creation():
-    create_user("alice", "alice@example.com")
-    assert send_welcome_email.called
-\`\`\`
-
-### Test edge cases
+## 3. Test Quality
 
-After the happy path passes, add tests for:
-- Empty inputs
-- Invalid inputs
-- Boundary values
-- Error conditions
-- Concurrent access (if applicable)
-
-### Name tests clearly
-
-The test name should read like a specification:
-- \`should return empty list when no users match filter\`
-- \`should throw validation error when email is invalid\`
-- \`should retry request up to 3 times on timeout\`
+- **Assert on behavior, not implementation** \u2014 \`should return user profile for valid ID\`, not \`should call userRepository.findById\`. Tests coupled to implementation break on every refactor.
+- **One assertion per concept.** A test that checks unrelated things (fields set *and* an email was sent) hides which concept broke when it fails \u2014 split into separate tests.
+- **Cover the edges** after the happy path passes: empty inputs, invalid inputs, boundary values, error conditions, concurrent access where applicable.
+- **Name tests as specifications** \u2014 \`should throw validation error when email is invalid\`, \`should retry request up to 3 times on timeout\`.
 
 ---
 
@@ -1596,24 +1774,9 @@ The test name should read like a specification:
 
 ## 5. Testing Patterns
 
-### Arrange-Act-Assert (AAA)
-
-\`\`\`javascript
-test("should apply discount to order total", () => {
-  // Arrange
-  const order = createOrder({ total: 100, coupon: "SAVE10" });
-
-  // Act
-  const result = applyDiscount(order);
+Structure each test **Arrange-Act-Assert**: set up state, perform the one action under test, assert the result.
 
-  // Assert
-  expect(result.total).toBe(90);
-});
-\`\`\`
-
-### Test doubles hierarchy
-
-Use the simplest double that works:
+Use the simplest test double that works:
 
 | Double | When to use |
 |--------|-------------|
@@ -1622,15 +1785,7 @@ Use the simplest double that works:
 | **Mock** | Set expectations upfront. Use sparingly \u2014 prefer stubs + assertions. |
 | **Fake** | Lightweight implementation (e.g., in-memory DB). Use for integration tests. |
 
-### Boundary testing
-
-Test at the edges of your system, not in the middle:
-
-\`\`\`
-[External Input] \u2192 [Your Boundary] \u2192 [Your Logic] \u2192 [Your Boundary] \u2192 [External Output]
-     \u2191                    \u2191                                  \u2191
-  Validate here     Test here                          Test here
-\`\`\`
+Test at your system's boundaries \u2014 validate at the input boundary, assert at the output boundary \u2014 rather than reaching into the middle.
 
 ---
 
@@ -1645,7 +1800,7 @@ Test at the edges of your system, not in the middle:
 | "Tests break when I refactor" | Tests are coupled to implementation | Rewrite tests to assert on behavior, not implementation details. |`;
 var BOARD_PROGRESSION = `# Board Progression
 
-This skill defines how to correctly move work items between statuses using Allye boards. Understanding board progression prevents incorrect status transitions and ensures accurate project tracking.
+How to move work items between statuses on Allye boards, correctly.
 
 ---
 
@@ -1660,22 +1815,51 @@ The MCP client can only **confirm** 4 status categories \u2014 \`work_statuses()
 | \`done\` | Completed and verified |
 | \`cancelled\` | Will not be done |
 
-That's the only taxonomy the MCP client source guarantees. Specific status **names** (e.g. "Backlog", "Todo", "In Progress", "Testing", "Review", "Deploying", "Done") are team-configurable \`WorkflowStatus\` records mapped onto those 4 categories via board columns \u2014 they are not enumerable or guaranteed from the client code alone, and a given team's board may use different names or skip some of them.
+That's the only taxonomy the MCP client source guarantees. Specific status **names** are team-configurable \`WorkflowStatus\` records mapped onto those 4 categories via board columns \u2014 not enumerable or guaranteed from the client code alone, and a given team's board may use different names or skip some of them.
 
-With that caveat, the finer-grained progression below is a common, practical convention (not something the client confirms) that this skill assumes as its default working model, because most teams do configure something like it:
+### The team's pipeline is data. Read it.
 
-| Status name (convention) | Meaning |
-|----------|---------|
-| \`backlog\` | Not yet planned \u2014 sitting in the backlog |
-| \`todo\` | Planned and ready to start |
-| \`in_progress\` | Actively being worked on |
-| \`testing\` | Implementation done, being tested |
-| \`review\` | Code review in progress |
-| \`deploying\` | Being deployed to an environment |
-| \`done\` | Completed and verified |
-| \`cancelled\` | Will not be done |
+Allye is multi-tenant. Four presets ship \u2014 Solo, Startup, Standard, Enterprise \u2014 and every
+team customises from there, so **there is no status list to memorise and no ordering to
+assume.** A skill that names a status has guessed about somebody else's board.
+
+Only three things are stable enough to build a rule on:
+
+| Stable | Why |
+|---|---|
+| The four categories: \`proposed\`, \`in_progress\`, \`done\`, \`cancelled\` | A schema enum. Every status maps to exactly one. |
+| The three pipelines: \`product\`, \`engineering\`, \`shared\` | A schema enum. \`product\` carries epics and features; \`engineering\` carries stories and below; \`shared\` holds the terminal states. |
+| The board's own ordering | Whatever it is, it is what \`work_status_next\` walks. |
 
-Each team can customize their board with different columns and map statuses to columns as they see fit. Before relying on any specific status name, check \`work_statuses()\` (categories + actual names for the team) and \`board_columns()\` (which columns exist on the board in question).
+Discover the rest:
+
+\`\`\`
+work_statuses()    \u2192 every status the team has, grouped by category, in position order
+board_columns()    \u2192 the columns of a specific board
+\`\`\`
+
+**Two things \`work_statuses()\` does not tell you today**, and planning around them is the
+difference between a working transition and a surprised one:
+
+- **\`position\`, \`pipeline\`, and \`description\` are not returned.** They exist on the record \u2014
+  the seed writes all three \u2014 but the MCP formatter emits only name, key, id, and colour.
+- **\`board_columns()\` returns names and ids only** \u2014 no status-to-column mapping and no
+  ordering. The visible subset a given board shows cannot be reconstructed from it.
+
+Together these mean **you cannot reliably predict the next status.** So do not:
+
+<HARD-GATE>
+Move one status at a time, then **read back** the status you actually landed on. Never
+assume a transition took you where you expected, and never chain several moves on a
+prediction. One extra read per transition costs nothing next to a cascade that silently
+skipped four gates.
+</HARD-GATE>
+
+For reference only, these are the eighteen statuses the presets seed \u2014 **an example of one
+tenant's configuration, not a list to code against**: \`idea\`, \`researching\`, \`designing\`,
+\`specifying\`, \`backlog\`, \`todo\`, \`in_progress\`, \`code_review\`, \`security_scan\`, \`qa_testing\`,
+\`doc_review\`, \`deploy_staging\`, \`qa_staging\`, \`deploy_preprod\`, \`qa_preprod\`, \`deploy_prod\`,
+\`done\`, \`cancelled\`.
 
 ---
 
@@ -1705,12 +1889,7 @@ Each team can customize their board with different columns and map statuses to c
 work_status_next(id: "{work item uuid}")
 \`\`\`
 
-Use this for **forward progression** through the workflow:
-- Backlog \u2192 Todo (item is planned)
-- Todo \u2192 In Progress (work starts)
-- In Progress \u2192 Testing (implementation done)
-- Testing \u2192 Review (tests pass)
-- Review \u2192 Done (review approved)
+Use it for **forward progression**, one status at a time, as each step's work actually finishes \u2014 how progression differs by pipeline and item type is in \xA75.
 
 ### When NOT to use
 
@@ -1749,6 +1928,32 @@ Verify all acceptance criteria before marking an item as done.
 
 ---
 
+## 3.1 Where an agent's authority ends
+
+> **An agent drives everything that is verification. It stops at the first gate that changes
+> the world outside the repository.**
+
+Deploying does that. Verifying does not. The rule survives renaming because it describes what
+a gate *is*, not what it is called \u2014 which is the only kind of rule that works when every
+team configures its own statuses.
+
+In practice, on the seeded presets: reviewing, scanning, testing, and updating docs are all
+verification and all satisfiable by an agent. Every deploy stage, and any validation
+performed in a deployed environment, is not.
+
+<HARD-GATE>
+\`work_status_done\` is **not** the exit from a pipeline an agent cannot finish. Calling it
+from four statuses away records "done" for work that never passed the gates in between.
+
+Use it only when the item's next status **is** the done status. Otherwise stop at the last
+gate you satisfied and say plainly which gate is next and who owns it.
+</HARD-GATE>
+
+An unrecognised status is treated as a stop, not a pass. Ask once who satisfies it, record
+the answer in the team's delivery configuration, and never ask again.
+
+---
+
 ## 4. Checking Available Statuses
 
 Before moving items, understand what statuses exist:
@@ -1773,52 +1978,20 @@ Returns the board's columns for the given \`board_id\` \u2014 each rendered as \
 
 ## 5. Progression Patterns by Item Type
 
-### Epic
-
-Epics typically move through few statuses:
-\`\`\`
-backlog \u2192 in_progress \u2192 done
-\`\`\`
-- Move to \`in_progress\` when the first feature starts
-- Move to \`done\` when ALL features are complete
-
-### Feature
+Progression differs by pipeline, not only by type. **Epics and features live on the \`product\`
+pipeline; stories, bugs, hotfixes, tasks, spikes, and subtasks live on \`engineering\`.** A
+cascade from task to epic therefore crosses pipelines, and the statuses available on each side
+are different sets.
 
-Features follow the epic pattern:
-\`\`\`
-backlog \u2192 in_progress \u2192 done
-\`\`\`
-- Move to \`in_progress\` when the first story starts
-- Move to \`done\` when ALL stories are complete
+What holds regardless of the team's configuration:
 
-### Story
-
-Stories follow the full progression:
-\`\`\`
-backlog \u2192 todo \u2192 in_progress \u2192 review \u2192 done
-\`\`\`
-- \`todo\`: planned and ready to start (tasks created)
-- \`in_progress\`: at least one task is being worked on
-- \`review\`: all tasks done, story-level review in progress
-- \`done\`: review passed, delivered
-
-### Task
-
-Tasks are the most granular:
-\`\`\`
-todo \u2192 in_progress \u2192 review \u2192 done
-\`\`\`
-- \`in_progress\`: actively being implemented
-- \`review\`: acceptance criteria met, tests pass \u2014 the Executor advances the task here (\`work_status_next\`) and no further; the task now awaits the Reviewer
-- \`done\`: Reviewer returned \u2705 \u2014 the **Orchestrator** makes this final move (\`work_status_done\`), never the Executor. If the Reviewer returns \u274C, the task simply stays at \`review\` while a correction round runs (no backward move exists or is needed)
-
-### Bug
-
-Bugs follow a similar path to tasks:
-\`\`\`
-todo \u2192 in_progress \u2192 testing \u2192 done
-\`\`\`
-- \`testing\`: fix implemented, verifying it resolves the issue
+- **Parents move because children moved.** A story advances when its tasks do; a feature when
+  its stories do; an epic when its features do. Never the other way round.
+- **A parent never reaches the done category while any child is outside it.** This is the one
+  rule that failed in practice: a story closed with seven of fifteen tasks still mid-pipeline,
+  because closing it was the only exit the flow offered. Stopping is the exit.
+- **The Executor advances a task only to the first review gate.** The move past that is the
+  Orchestrator's, after review clears \u2014 see \`orchestrator\` \xA76.
 
 ---
 
@@ -1827,7 +2000,7 @@ todo \u2192 in_progress \u2192 testing \u2192 done
 | Mistake | Why it's wrong | Do this instead |
 |---------|---------------|-----------------|
 | Moving story to done before all tasks are done | Misrepresents progress | Check \`work_children\` first \u2014 all tasks must be done |
-| Marking a task done as soon as its own tests pass | Done requires Reviewer approval, not just green tests | \`work_status_next\` to \`review\`; the Orchestrator moves it to done after Reviewer \u2705 |
+| Marking a task done as soon as its own tests pass | Done requires review approval, not just green tests | \`work_status_next\` once, to the first review gate, and stop; the Orchestrator carries it from there \u2014 see \xA73.1 |
 | Skipping statuses with repeated \`work_status_next\` | Loses tracking fidelity | Only advance when the work for that status is actually complete |
 | Moving to in_progress without planning | No tasks = no accountability | Run Technical Planning first, create tasks, then advance |
 | Forgetting to check board structure | Different teams may have different progressions | Always check \`board_columns\` if unsure about available statuses |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "allye-opencode",
-  "version": "1.2.7",
+  "version": "1.3.0",
   "description": "Allye multi-agent plugin for OpenCode — planning, building, reviewing, and delivering with structured workflows",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",