allye-opencode 1.2.3 → 1.2.5

package/README.md

@@ -0,0 +1,28 @@
+# allye-opencode
+
+An [OpenCode](https://opencode.ai) plugin that registers 6 specialized Allye agents for the guided delivery workflow:
+
+- **Allye — Router** — initializes context, detects the workflow phase, and delegates to the agent below
+- **Allye Plan** — product planning (epics/features/stories) and technical planning (discussion phase, trade-offs, tasks)
+- **Allye Orchestrator** — coordinates delivery of an already-planned feature: assigns work, tracks status, drives review
+- **Allye Build** — TDD implementation of tasks
+- **Allye Review** — code review with full context
+- **Allye Deliver** — finalizes delivery, closes stories, updates docs
+
+It also injects live Allye account/session context into every conversation via a system-prompt transform hook.
+
+## Installation
+
+This package is not typically installed standalone. It's installed automatically as part of the main [`allye-plugin`](https://github.com/allye-app/allye-plugin) install flow (`install.sh`), which detects OpenCode and adds `allye-opencode` to the `plugin` array in your `opencode.json` alongside the Allye MCP server configuration.
+
+If you do need to add it manually, add it to the `plugin` array in your OpenCode config:
+
+```json
+{
+  "plugin": ["allye-opencode"]
+}
+```
+
+## Documentation
+
+For full workflow documentation — the guided delivery methodology, the phase skills, and the handover protocol this plugin implements — see the main repo: [github.com/allye-app/allye-plugin](https://github.com/allye-app/allye-plugin).

package/dist/index.js

@@ -149,6 +149,7 @@ Detect what the user needs and delegate to the right agent using the \`task\` to
 
 | User intent | Delegate to |
 |-------------|-------------|
+| Explore ideas, research before committing to scope, think out loud | **allye-plan** (exploration only \u2014 do NOT create work items yet) |
 | Define requirements, plan features, create epics/stories, break stories into tasks | **allye-plan** |
 | Coordinate delivery of an already-planned feature \u2014 assign work, track status, drive review | **allye-orchestrator** |
 | Implement code, write tests, fix bugs, develop features | **allye-build** |
@@ -157,6 +158,7 @@ Detect what the user needs and delegate to the right agent using the \`task\` to
 
 ### How to detect the phase
 
+- **Exploring** \u2014 User wants to: think out loud, explore ideas, research a problem space, weigh directions before committing to scope. Nothing should be created yet \u2014 no epics, features, or stories. Delegate to allye-plan but tell it explicitly this is open-ended exploration, not work-item creation.
 - **Planning** \u2014 User talks about: requirements, business needs, features, epics, user stories, scope, MVP, tasks, approach, options, trade-offs
 - **Orchestrating** \u2014 User wants to: coordinate delivery, assign work items, track story/task status, drive review for an already-planned feature
 - **Building** \u2014 User wants to: write code, implement a task, fix a bug, add functionality, write tests
@@ -179,8 +181,8 @@ If the user's request is simple and doesn't match any phase (general questions,
 `.trim();
 var allyeAgent = {
   ...SHARED_CONFIG,
-  description: "Allye orchestrator \u2014 initializes context, detects workflow phase, and delegates to specialized Allye agents (Plan, Build, Review, Deliver)",
-  prompt: buildPrompt("Allye \u2014 Orchestrator", [
+  description: "Allye router \u2014 initializes context, detects workflow phase, and delegates to specialized Allye agents (Plan, Orchestrator, Build, Review, Deliver)",
+  prompt: buildPrompt("Allye \u2014 Router", [
     LANGUAGE_DETECTION,
     ALLYE_INIT_PROTOCOL,
     MEMORY_SEARCH_PROTOCOL,
@@ -333,9 +335,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 +347,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 +360,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 +368,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": "..."
   }
@@ -479,13 +482,13 @@ The steps below plan **one story at a time** \u2014 but the unit Technical Plann
 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}")
 \`\`\`
 
 ---
@@ -666,12 +669,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}"
   },
@@ -679,7 +682,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}"
   }
@@ -777,13 +780,14 @@ 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 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 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.
 
 <!-- adapted from bmad-code-org/BMAD-METHOD correct-course (MIT) \u2014 structured change-impact analysis for corrections that ripple beyond one task -->
@@ -810,7 +814,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 \`allye-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, 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.
@@ -834,7 +838,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:
@@ -913,12 +917,14 @@ This is not optional. Writing code without reading the context leads to:
 ### Analysis Paralysis Guard
 
 <HARD-GATE>
-If you have read 5+ files without writing any code, STOP and ask yourself:
+This checkpoint applies to exploratory reads beyond what the task already named \u2014 reading every file the task itself points you to (see "What to read" above) is still mandatory, not capped by this count.
+
+If you have read 5+ files *beyond those named/implied by the task* without writing any code, STOP and ask yourself:
 
 1. **Do I have enough context to start?** \u2192 If yes, start writing. Perfect understanding is not required.
 2. **Am I blocked by missing information?** \u2192 If yes, tell the user what's blocking you.
 
-Do not read endlessly. Reading is preparation, not implementation.
+Do not read endlessly in search of additional context. Reading is preparation, not implementation.
 </HARD-GATE>
 
 ---
@@ -1060,16 +1066,14 @@ Only save if there's genuinely useful context. Don't save trivial implementation
 
 ## Step 9: Pick Next Task
 
-After completing a task, check what's next:
+After completing a task, pick the next one from the **handover's own wave-ordered task list** \u2014 not from a live API call. The \`story-execution\` handover already contains every task across every wave for the whole story, so it's the authoritative scope; going back to the API for *new* tasks would risk pulling in tasks added to the story after the handover was dispatched, which are out of scope (see line ~14).
 
-\`\`\`
-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 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
 
+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 ("D\xFAvidas em aberto") in the \`execution-report\` handover so the Orchestrator can decide whether to bring it into scope.
+
 ---
 
 ## Workflow Checklist
@@ -1113,7 +1117,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}")
 \`\`\`
 
@@ -1639,11 +1643,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 |
@@ -1654,7 +1669,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).
 
 ---
 
@@ -1746,7 +1761,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.
 
 ---
 
@@ -2026,9 +2041,9 @@ After generating the handoff, say:
 > 3. The Orchestrator will coordinate implementation and review from here"
 
 ### Important:
-- ALWAYS generate the handoff prompt \u2014 don't just say "switch to Build"
-- The prompt must be COMPLETE \u2014 the Build agent starts from zero, it has no memory of this conversation
-- Include ALL locked decisions \u2014 Build must respect them
+- ALWAYS generate the handoff prompt \u2014 don't just say "switch to Orchestrator"
+- The prompt must be COMPLETE \u2014 the Orchestrator agent starts from zero, it has no memory of this conversation
+- Include ALL locked decisions \u2014 Orchestrator must respect them
 - Include the specific task key to start with \u2014 don't leave it vague
 `.trim();
 var allyePlanAgent = {

package/package.json

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