allye-opencode 1.2.2 → 1.2.4

package/dist/index.js

@@ -333,9 +333,10 @@ Create the top-level epic first:
 
 \`\`\`
 work_create(
-  title: "User Authentication System",
-  item_type: "epic",
-  description: "## Goal\\n{business goal}\\n\\n## Scope\\n{what's included}\\n\\n## Out of scope\\n{what's excluded}\\n\\n## Success criteria\\n{how we know it's done}"
+  work_title: "User Authentication System",
+  work_type: "epic",
+  work_category: "product",
+  work_description: "## Goal\\n{business goal}\\n\\n## Scope\\n{what's included}\\n\\n## Out of scope\\n{what's excluded}\\n\\n## Success criteria\\n{how we know it's done}"
 )
 \`\`\`
 
@@ -344,12 +345,12 @@ work_create(
 Use \`work_bulk_create\` to create the full hierarchy in one call:
 
 \`\`\`
-work_bulk_create(items: [
+work_bulk_create(work_items: [
   {
     "temp_id": "feat-1",
     "title": "Email/Password Auth",
     "item_type": "feature",
-    "work_category": "feature",
+    "work_category": "product",
     "parent_key": "PROJ-100",          // existing epic key
     "description": "..."
   },
@@ -357,7 +358,7 @@ work_bulk_create(items: [
     "temp_id": "story-1",
     "title": "User can register with email and password",
     "item_type": "story",
-    "work_category": "story",
+    "work_category": "product",
     "parent_temp_id": "feat-1",        // references the feature above
     "description": "..."
   },
@@ -365,7 +366,7 @@ work_bulk_create(items: [
     "temp_id": "story-2",
     "title": "User can log in with email and password",
     "item_type": "story",
-    "work_category": "story",
+    "work_category": "product",
     "parent_temp_id": "feat-1",
     "description": "..."
   }
@@ -447,7 +448,7 @@ Before considering product planning complete, verify:
 
 ## What Comes Next
 
-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. Include the doc reference (if any) and every created **and** reused key \u2014 Technical Planning has no other way to know which items are which.`;
+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.
@@ -466,18 +467,26 @@ Get story \u2192 Search context \u2192 Discussion Phase \u2192 Create tasks \u21
 
 ---
 
+## 0. Scope: one feature, story by story
+
+The steps below plan **one story at a time** \u2014 but the unit Technical Planning hands to the Orchestrator is the **feature**. When the target feature has multiple stories (a \`planning-to-technical\` handover usually lists several), work through every story under that feature in sequence, one at a time, running the full workflow (Steps 1\u20136) for each before starting the next.
+
+**Emit only ONE \`technical-to-orchestration\` handover, at the very end \u2014 after the last story in the feature is planned, never after each individual story.** That handover must cover every story and every task, grouped by wave, which is only honest once all of the feature's stories have actually been planned. If the session ends before all stories are planned, save session state (Step 6) and resume in a fresh chat \u2014 don't emit a partial feature-level handover.
+
+---
+
 ## Step 1: Get the Story
 
 Fetch the story the user wants to plan:
 
 \`\`\`
-work_get(id: "{story uuid}" or key: "{PROJ-123}")
+work_get(id: "{story uuid}" or work_key: "{PROJ-123}")
 \`\`\`
 
 Read the story's description, acceptance criteria, and parent context. If the story is part of a feature/epic, understand the broader scope:
 
 \`\`\`
-work_get(key: "{parent feature key}")
+work_get(work_key: "{parent feature key}")
 \`\`\`
 
 ---
@@ -658,12 +667,12 @@ Present the wave structure to the user so they understand the execution order.
 ### 4.5 Create Tasks via Bulk Create
 
 \`\`\`
-work_bulk_create(items: [
+work_bulk_create(work_items: [
   {
     "temp_id": "task-1",
     "title": "Set up database schema for {feature}",
     "item_type": "task",
-    "work_category": "task",
+    "work_category": "backend",
     "parent_key": "{STORY-KEY}",
     "description": "{full description with acceptance criteria}"
   },
@@ -671,7 +680,7 @@ work_bulk_create(items: [
     "temp_id": "task-2",
     "title": "Create API route structure for {feature}",
     "item_type": "task",
-    "work_category": "task",
+    "work_category": "backend",
     "parent_key": "{STORY-KEY}",
     "description": "{full description with acceptance criteria}"
   }
@@ -723,12 +732,15 @@ Before considering technical planning complete, verify:
 - [ ] Tasks are created in Allye with proper parent relationship
 - [ ] Story is moved to in_progress
 - [ ] Planning summary is saved as memory
+- [ ] All of the feature's stories are planned before the \`technical-to-orchestration\` handover is emitted (see \xA70)
 
 ---
 
 ## What Comes Next
 
-Emit a **\`technical-to-orchestration\`** handover (see the \`handover-protocol\` skill) for the Orchestrator. Spell out the full reading list \u2014 doc, epic, feature, every story, every task, grouped by wave \u2014 and every locked architecture decision. The Orchestrator has no other context; a vague pointer here becomes its problem later.`;
+**If the feature has more stories still unplanned, go back to Step 1 for the next story \u2014 no handover yet (see \xA70).**
+
+Once the last story in the feature is planned, emit a **\`technical-to-orchestration\`** handover (see the \`handover-protocol\` skill) for the Orchestrator. Spell out the full reading list \u2014 doc, epic, feature, every story, every task, grouped by wave \u2014 and every locked architecture decision, across all the stories planned in this cycle. The Orchestrator has no other context; a vague pointer here becomes its problem later.`;
 var ORCHESTRATOR = `# Orchestrator
 
 You drive delivery. You don't plan \u2014 that already happened in Technical Planning \u2014 and you don't implement \u2014 that's Executor's job, one fresh chat at a time. You coordinate: who owns what, what's in progress, whether a story is genuinely done, and when to bring in review.
@@ -755,45 +767,36 @@ Move claimed items to \`in_progress\` (\`work_status_next\`) as work on them act
 
 ## 4. Dispatch Executor \u2014 one story at a time
 
-Before dispatching, do a quick completeness check on the story's tasks: does each one have concrete, verifiable acceptance criteria \u2014 something you could actually judge as met or not-met? A task like "data modeling" with no defined schema, or "handle errors" with no defined error cases, is not execution-ready. If a task looks underspecified, say so to the user now and resolve it (or route back to \`technical-planning\`) before dispatching \u2014 don't let an obviously vague task go to Executor and discover that the hard way, in either mode below.
-
-**Ask the user: automatic or manual?**
-
-- **Manual** (the original flow \u2014 default when unsure): emit a \`story-execution\` handover (\`handover-protocol\` \u2192 \`references/story-execution.md\`) scoped to exactly one story and its tasks. The user runs it in a fresh Executor chat.
-- **Automatic**: dispatch the \`executor\` subagent directly via the \`Agent\` tool, in this same conversation. Fill out the exact same fields \`references/story-execution.md\` defines \u2014 story, tasks with acceptance criteria copied in full, locked decisions, applicable code standards, TDD expectation \u2014 and use that filled-out content as the dispatch prompt, instead of a handover the user pastes. **Same information, same template, different transport** \u2014 automatic mode is not a lighter briefing than manual, it's the identical one delivered a different way.
-
-Either way, the scope is identical: **exactly one story and its tasks, never a whole feature.** Too much scope in one dispatch means it starts making its own planning decisions, which isn't its job in either mode.
+Before dispatching, do a quick completeness check on the story's tasks: does each one have concrete, verifiable acceptance criteria \u2014 something you could actually judge as met or not-met? A task like "data modeling" with no defined schema, or "handle errors" with no defined error cases, is not execution-ready. If a task looks underspecified, say so to the user now and resolve it (or route back to \`technical-planning\`) before dispatching \u2014 don't let an obviously vague task go to Executor and discover that the hard way.
 
-<!-- flagged for override: this is a genuinely new capability, not yet battle-tested against the manual flow's track record -->
-**Automatic mode's limit \u2014 the reason this is a choice, not a silent default:** the \`executor\` subagent cannot pause and ask a question, unlike the interactive \`execution\` skill. It follows a halt-and-report contract instead of an ask-a-question one: if a task turns out to be underspecified once it's actually being implemented (the pre-flight check above catches the obvious cases, not all of them), it reports that task back as \`\u274C blocked\` with the specific question, rather than guessing a design to fill the gap. When a dispatch comes back with a blocked task:
+- emit a \`story-execution\` handover (\`handover-protocol\` \u2192 \`references/story-execution.md\`) scoped to exactly one story and its tasks. The user runs it in a fresh Executor chat.
 
-1. Put the exact question in front of the user yourself \u2014 you can ask, even though the subagent couldn't.
-2. Once answered, re-dispatch the \`executor\` subagent for just that task with the clarification included, or offer to switch that one story to manual mode if the gap turns out to be bigger than a quick answer.
+**exactly one story and its tasks, never a whole feature.** Too much scope in one dispatch means it starts making its own planning decisions, which isn't its job.
 
 ## 5. Dispatch Reviewer \u2014 automatic and parallel
 
 <!-- adapted from EveryInc/compound-engineering-plugin lfg (MIT) \u2014 verify the previous step's artifact before proceeding -->
-When the execution report comes back (handover, in manual mode; direct return value, in automatic mode), 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.
+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 via the \`Agent\` tool \u2014 in parallel, automatically, no need to ask the user first, regardless of which mode Executor ran in. Review never needs to pause and ask anyone anything, which is what makes it always dispatch-appropriate. Pass it: the story key, the task keys, and the files changed from the execution report.
+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.
 
 ## 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).
 
-- **All \u2705** \u2192 proceed to the status cascade (\xA77).
-- **Any \u274C** \u2192 send corrections back, in whichever mode the story is running, using \`references/correction.md\`'s exact fields either way (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 for manual mode, or use the same filled-out fields as the dispatch prompt for a re-dispatch of the \`executor\` subagent for automatic mode. Loop back to \xA75 once the next execution report arrives.
+- **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).
+- **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.
 
 <!-- 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): escalate after 3 failed review rounds on the same task.** Track how many correction handovers this task has already received. On the 3rd \u274C for the same task, do not emit a 4th correction handover \u2014 stop and tell the user. Two rounds of the same task failing review for different specific reasons is normal; three rounds usually means something deeper is being missed, and it's worth a human look before burning a fourth round.
+**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.
 
 ## 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:
 
-1. Task reaches done (criteria met, tests pass, Reviewer \u2705) \u2192 \`work_children\` on the parent story \u2192 all done? \u2192 \`work_status_done\` the story.
+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.
 
@@ -808,7 +811,7 @@ Unclear assignee, no active sprint to assign into, conflicting or unexpected sta
 
 ## 10. Memory
 
-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. 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 \`memory-protocol\` skill \u2014 don't let it live only in this session's state snapshot.`;
+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. 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.
@@ -822,7 +825,7 @@ Use this when the user wants to: write code, implement a task, fix a bug, add fu
 ## Workflow Overview
 
 \`\`\`
-Get task \u2192 Search context \u2192 Move to in_progress \u2192 Read code \u2192 TDD (Red \u2192 Green \u2192 Refactor) \u2192 Verify \u2192 Move to done \u2192 Save memory
+Get task \u2192 Search context \u2192 Move to in_progress \u2192 Read code \u2192 TDD (Red \u2192 Green \u2192 Refactor) \u2192 Verify \u2192 Move to review \u2192 Save memory
 \`\`\`
 
 ---
@@ -832,7 +835,7 @@ Get task \u2192 Search context \u2192 Move to in_progress \u2192 Read code \u219
 Fetch the task you're about to implement:
 
 \`\`\`
-work_get(key: "{TASK-KEY}")
+work_get(work_key: "{TASK-KEY}")
 \`\`\`
 
 Read its description carefully \u2014 it should contain:
@@ -867,7 +870,7 @@ If the task has dependencies (noted in its description), verify they're complete
 work_children(id: "{story uuid}")
 \`\`\`
 
-Check that prerequisite tasks are in "done" status. If they're not done, either:
+Check that prerequisite tasks are in "review" or "done" status \u2014 either means their implementation is complete (tasks you finished earlier in this story sit at \`review\` until the Reviewer approves them). If a prerequisite hasn't reached at least \`review\`, either:
 - Pick a different task from the same wave (if available)
 - Inform the user that this task is blocked
 
@@ -1023,18 +1026,18 @@ Examples of things that need human action:
 
 ---
 
-## Step 7: Mark Task as Done
+## Step 7: Move Task to Review
 
 <!-- adapted from superpowers:verification-before-completion (MIT) \u2014 evidence before assertions -->
-**Evidence before assertions.** Don't mark a task done 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."
+**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."
 
 Once all acceptance criteria are verifiably met and tests pass:
 
 \`\`\`
-work_status_done(id: "{task uuid}")
+work_status_next(id: "{task uuid}")
 \`\`\`
 
-This sets the task to the "done" status and records \`completed_at\`.
+This advances the task forward to the "review" status. **Do NOT call \`work_status_done\` here** \u2014 passing its own tests makes a task ready for review, not done. "Done" only happens after the Reviewer returns \u2705, and that final move (\`review\` \u2192 \`done\`) is the Orchestrator's, not yours (see the \`orchestrator\` skill \xA77).
 
 ---
 
@@ -1066,7 +1069,7 @@ work_children(id: "{story uuid}")
 
 - If there are more tasks in the current wave \u2192 pick one
 - If the current wave is done \u2192 move to the next wave
-- If all tasks in the story are done \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 emit an **\`execution-report\`** handover (see the \`handover-protocol\` skill) back to the Orchestrator
 
 ---
 
@@ -1082,7 +1085,7 @@ For each task, verify:
 - [ ] TDD cycle completed (or tests written after for non-TDD-suitable tasks)
 - [ ] All acceptance criteria are met
 - [ ] Tests pass
-- [ ] Task moved to done
+- [ ] Task moved to review (never directly to done \u2014 that's the Orchestrator's move after Reviewer \u2705)
 - [ ] Implementation memory saved (if non-trivial)
 
 ---
@@ -1111,7 +1114,7 @@ Get story context \u2192 Load decisions \u2192 Review each task \u2192 Document
 ### Get the story and its tasks
 
 \`\`\`
-work_get(key: "{STORY-KEY}")
+work_get(work_key: "{STORY-KEY}")
 work_children(id: "{story uuid}")
 \`\`\`
 
@@ -1219,10 +1222,11 @@ memory_save(
 )
 \`\`\`
 
-If tasks need rework, move them back:
+If tasks need rework, set their status back explicitly. \`work_status_next\` only moves **forward** (there is no \`work_status_prev\`), so a backward move goes through \`work_update\` with an explicit status id:
 
 \`\`\`
-work_status_next(id: "{task uuid}")  // back to in_progress if applicable
+work_statuses()                                        // find the id of the target status (e.g. "In Progress")
+work_update(id: "{task uuid}", work_status: "{status uuid}")
 \`\`\`
 
 ---
@@ -1252,7 +1256,7 @@ If you can run the test suite, do it:
 
 ## What Comes Next
 
-If the review passes, transition to **Technical Delivery** \u2014 load the \`allye-technical-delivery\` skill.
+If the review passes, transition to **Delivery** \u2014 load the \`delivery\` skill (backend slug: \`allye-technical-delivery\`).
 
 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
@@ -1371,7 +1375,7 @@ todo_list()
 \`\`\`
 
 For each TODO related to this story:
-- If it's done \u2192 mark as complete: \`todo_update(id: "{todo uuid}", todo_completed: true)\`
+- If it's done \u2192 mark as complete: \`todo_update(id: "{todo uuid}", status: "completed")\`
 - If it's no longer relevant \u2192 delete: \`todo_delete(id: "{todo uuid}")\`
 - If it's a future task \u2192 leave it, but make sure it's not blocking delivery
 
@@ -1636,11 +1640,22 @@ This skill defines how to correctly move work items between statuses using Allye
 
 ---
 
-## 1. Status Categories
+## 1. Status Categories vs. Status Names
+
+The MCP client can only **confirm** 4 status categories \u2014 \`work_statuses()\` (\`work_items.py\`) groups every status under a hardcoded \`category_order\`:
+
+| Category (confirmed) | Meaning |
+|----------|---------|
+| \`proposed\` | Not yet started (backlog/todo-like) |
+| \`in_progress\` | Actively being worked on |
+| \`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.
 
-Allye uses these status categories, in typical progression order:
+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:
 
-| Category | Meaning |
+| Status name (convention) | Meaning |
 |----------|---------|
 | \`backlog\` | Not yet planned \u2014 sitting in the backlog |
 | \`todo\` | Planned and ready to start |
@@ -1651,7 +1666,7 @@ Allye uses these status categories, in typical progression order:
 | \`done\` | Completed and verified |
 | \`cancelled\` | Will not be done |
 
-Each team can customize their board with different columns and map statuses to columns as they see fit. The categories above are the semantic meaning \u2014 the actual status names may vary.
+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).
 
 ---
 
@@ -1743,7 +1758,7 @@ Returns all available statuses with their categories and names.
 board_columns()
 \`\`\`
 
-Returns the board structure showing which statuses are in which columns and their order. This is the source of truth for \`work_status_next\` progression.
+Returns the board's columns for the given \`board_id\` \u2014 each rendered as \`- {column name} (ID: {column id})\`. Note: this tool's text output does not surface which statuses map to which column, nor an explicit ordering field (\`boards.py\`'s \`board_columns\` action only formats \`name\` and \`id\` per column) \u2014 that richer structure may exist in the underlying API but isn't exposed here. Use it to confirm which columns exist on a board; pair it with \`work_statuses()\` for status names/categories.
 
 ---
 
@@ -1782,10 +1797,11 @@ backlog \u2192 todo \u2192 in_progress \u2192 review \u2192 done
 
 Tasks are the most granular:
 \`\`\`
-todo \u2192 in_progress \u2192 done
+todo \u2192 in_progress \u2192 review \u2192 done
 \`\`\`
 - \`in_progress\`: actively being implemented
-- \`done\`: acceptance criteria met, tests pass
+- \`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
 
@@ -1802,6 +1818,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 |
 | 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 |
@@ -1986,7 +2003,7 @@ Generate a complete handoff using the shared marker format \u2014 same shape Cla
 
 \`\`\`
 ## \uD83D\uDD04 Allye Handover \u2014 technical-to-orchestration
-**Skill a carregar:** allye-orchestrator
+**Skill a carregar:** orchestrator
 
 ### Objetivo
 Conduzir a entrega de {FEATURE-KEY} \u2014 {feature title}
@@ -2070,7 +2087,7 @@ Generate a handoff scoped to exactly ONE story and its tasks \u2014 never a whol
 
 \`\`\`
 ## \uD83D\uDD04 Allye Handover \u2014 story-execution
-**Skill a carregar:** allye-build
+**Skill a carregar:** execution
 
 ### Story
 {STORY-KEY} \u2014 {title}, with acceptance criteria copied in full
@@ -2104,7 +2121,7 @@ Review returns its standard \u2705/\u26A0\uFE0F/\u274C-per-task output.
 
 \`\`\`
 ## \uD83D\uDD04 Allye Handover \u2014 correction
-**Skill a carregar:** allye-build
+**Skill a carregar:** execution
 
 ### Achados a corrigir (\u274C apenas)
 - {TASK-KEY}: "{finding, quoted literally}"
@@ -2205,7 +2222,7 @@ When all tasks in the current story are done \u2014 or you've hit a genuine bloc
 
 \`\`\`
 ## \uD83D\uDD04 Allye Handover \u2014 execution-report
-**Skill a carregar:** allye-orchestrator
+**Skill a carregar:** orchestrator
 
 ### Story implementada
 {STORY-KEY} \u2014 {title}

package/package.json

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