allye-opencode 1.5.1 → 1.6.0

package/dist/index.js

@@ -206,9 +206,11 @@ Use this when the user talks about: requirements, business needs, product scope,
 ## Workflow Overview
 
 \`\`\`
-Understand context \u2192 Search memories \u2192 Define hierarchy \u2192 Create items \u2192 Save decisions
+Understand intent \u2192 Search context when useful \u2192 Propose hierarchy when traceability helps \u2192 Get approval \u2192 Create items \u2192 Save decisions
 \`\`\`
 
+Product Planning is recommended for durable product scope, not a mandatory prerequisite for every local implementation. Never create items without explicit approval.
+
 ---
 
 ## Step 0: Check for a Discovery Doc
@@ -219,7 +221,7 @@ If you arrived via a \`discovery-to-planning\` handover (see the \`handover-prot
 
 ## Step 1: Understand the Business Context
 
-Before creating anything, have a conversation with the user to understand:
+Before proposing or creating anything, have a conversation with the user to understand:
 
 1. **What problem are we solving?** \u2014 The business need or opportunity
 2. **Who is it for?** \u2014 Target users or stakeholders
@@ -304,7 +306,7 @@ Epic: User Authentication System
     \u2514\u2500\u2500 Story: User can log out from all devices
 \`\`\`
 
-Wait for the user to approve, modify, or add to this structure before proceeding.
+Wait for the user to approve, modify, or add to this structure before proceeding. If the user explicitly chooses a no-work-item path for a small or local change, do not create a hierarchy; keep the scope and verification visible instead.
 
 ---
 
@@ -445,7 +447,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
 
-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.
+Turns an approved, meaningful 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. It is recommended for durable, multi-step, shared, or review-heavy work, not mandatory for every local change.
 
 **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.
 
@@ -461,6 +463,8 @@ Get story \u2192 Search context \u2192 Discussion Phase \u2192 Create tasks \u21
 
 ## 0. Scope: one feature, story by story
 
+If the user explicitly chooses a no-task path, do not enter this workflow or create tasks. State the local scope, assumptions, and verification plan instead.
+
 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.
@@ -511,9 +515,9 @@ If tasks already exist, review them instead of creating new ones. The user may w
 ## Step 3: Discussion Phase
 
 <EXTREMELY_IMPORTANT>
-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.
+For tracked work, complete the discussion phase \u2014 surfacing ambiguity before committing
+to a plan \u2014 before creating any task. A user-approved no-task path may skip task creation,
+but must still surface scope-changing ambiguity and define proportional verification.
 </EXTREMELY_IMPORTANT>
 
 ### 3.1 Identify Gray Areas
@@ -528,7 +532,7 @@ Examples of gray areas:
 - Should we optimize for read speed or write speed?
 - How much backward compatibility do we need?
 
-**Mandatory:** whenever a story implies infrastructure, stack, or architecture choices, that is always a gray area to raise explicitly \u2014 never left to chance or agent discretion by default.
+Whenever tracked work implies infrastructure, stack, or architecture choices, raise them explicitly as gray areas. For a small no-task change, use established defaults only when the choice is low-risk and reversible; otherwise ask before acting.
 
 **Need more than a hunch to evaluate an option?** Dispatch the \`deep-search\` agent (web research) or the \`code-analyzer\` agent (analyze a public repo), both via the \`Agent\` tool \u2014 research is available here, not only in Sandbox. Bring findings back into the discussion before locking a decision.
 
@@ -790,10 +794,12 @@ Before considering technical planning complete, verify:
 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.
+You coordinate delivery when the user chooses a durable, multi-step work-item workflow. You don't have to be invoked for every change, and you don't plan or implement when coordinating \u2014 Technical Planning and Executor playbooks remain available as needed. You coordinate: who owns what, what's in progress, whether a story is genuinely done, and when to bring in review. If the user chooses a local no-task path, stop coordinating rather than creating work items to justify this skill.
 
 ## 1. On start
 
+If no approved work item or handover exists, do not invent one. Explain the available lightweight local path or ask whether the user wants to opt into tracked delivery.
+
 If you arrived via a \`technical-to-orchestration\` handover (see \`handover-protocol\`), read it in full \u2014 it's your only context, there is no prior conversation to fall back on.
 
 Then load the actual work. **The handover's list is an index to verify against, not a substitute for reading:**
@@ -942,8 +948,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
 
-Implements one task with discipline: read the existing code first, drive it with TDD,
-verify it actually works, and track progress in Allye.
+Implements a scoped change with discipline: read the existing code first, drive it with TDD when applicable,
+verify it actually works, and use Allye task tracking when a task exists or the user approves creating one. A small or explicitly approved no-task change still follows the same read, test, and verification discipline.
 
 **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.
 
@@ -959,6 +965,8 @@ Get task \u2192 Search context \u2192 Move to in_progress \u2192 Read code \u219
 
 ## Step 1: Get the Task and Context
 
+If a task or handover exists, fetch it and treat its acceptance criteria and locked decisions as authoritative. If no task exists, confirm that the user approved the no-task path, define the scope and verification command locally, and continue without inventing a work item.
+
 Fetch the task you're about to implement:
 
 \`\`\`
@@ -1009,6 +1017,8 @@ If there are multiple independent tasks (same wave), they can be done in any ord
 
 ## Step 3: Move Task to In Progress
 
+If a task exists, signal that work has started. If no task exists, record the local scope in the implementation plan and do not make a status call.
+
 Signal that work has started:
 
 \`\`\`
@@ -1236,6 +1246,8 @@ Examples of things that need human action:
 
 ## Step 7: Move Task to Review
 
+For a tracked task, advance it to review only after the verification evidence is green. For an approved no-task change, report the same evidence directly and do not create or advance a status.
+
 <!-- 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."
 
@@ -1243,13 +1255,13 @@ The task's verification command is what supplies that evidence. Advancing a task
 \`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:
+Once all acceptance criteria are verifiably met and tests pass for a tracked task:
 
 \`\`\`
 work_status_next(id: "{task uuid}")
 \`\`\`
 
-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).
+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. For a no-task change, completion means the agreed scope and verification are reported; no status transition is implied.
 
 ---
 

package/package.json

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