allye-opencode 1.2.3 → 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": "..."
   }
@@ -479,13 +480,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 +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}"
   },
@@ -679,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}"
   }
@@ -777,7 +778,7 @@ 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
 
@@ -834,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:
@@ -1113,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}")
 \`\`\`
 
@@ -1639,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
 
-Allye uses these status categories, in typical progression order:
+The MCP client can only **confirm** 4 status categories \u2014 \`work_statuses()\` (\`work_items.py\`) groups every status under a hardcoded \`category_order\`:
 
-| Category | Meaning |
+| 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.
+
+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:
+
+| Status name (convention) | Meaning |
 |----------|---------|
 | \`backlog\` | Not yet planned \u2014 sitting in the backlog |
 | \`todo\` | Planned and ready to start |
@@ -1654,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).
 
 ---
 
@@ -1746,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.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "allye-opencode",
-  "version": "1.2.3",
+  "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",