@winton979/task-cli 1.6.0 → 1.6.1

package/README.md

@@ -121,6 +121,10 @@ archive automatically
 /task-explore  →  TASK_READY  →  /task-implement  →  optional /task-audit
 ```
 
+`task-explore` writes the brief for a fresh-session handoff. Briefs should stay within 500 words; they may extend to 1000 only when a shorter contract would omit execution-critical information. Requirements that still do not fit should be split before implementation.
+
+When more than one active brief could match, identify the intended brief when invoking `task-implement`. The implementing agent rechecks repository facts and resolves local, reversible choices from existing conventions. It asks the user only for unresolved decisions that materially affect the contract, records confirmed narrow clarifications in the active brief, and returns material goal, scope, or acceptance changes to `task-explore`.
+
 ### Bug Fix
 
 ```text

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@winton979/task-cli",
-  "version": "1.6.0",
+  "version": "1.6.1",
   "description": "Lightweight task workflow CLI for AI-assisted development",
   "license": "MIT",
   "repository": {

package/src/init.js

@@ -278,6 +278,15 @@ ${DECISIONS_READ_GUIDANCE}
 
 ${COMPLEXITY_ASSESSMENT_GUIDANCE}
 
+Cross-session Readiness
+
+Before finalizing the brief, assume implementation will start in a fresh session without the exploration conversation.
+
+* Record every confirmed user decision that materially constrains behavior, scope, compatibility, security, data handling, or acceptance.
+* Record material exclusions when omitting them could cause plausible scope expansion.
+* Do not copy repository facts the implementing agent can discover. Include only context needed to interpret the contract.
+* Do not output TASK_READY while a material user-owned decision remains unresolved.
+
 Task Brief Format
 
 # Goal
@@ -306,7 +315,9 @@ Clear success conditions.
 
 Requirements
 
-* Maximum 500 words
+* Aim for 500 words or fewer
+* Extend to at most 1000 words only when required to preserve execution-critical scope, constraints, risks, or acceptance criteria
+* If a coherent contract cannot fit within 1000 words, split the requirement and complete exploration for one independently executable task at a time
 * No code
 * No architecture design
 * Stay implementation-agnostic; describe constraints, not solutions
@@ -320,27 +331,39 @@ TASK_READY
 
   'task-implement': {
     name: 'task-implement',
-    description: 'Implement the latest active task brief and validate it. Archive automatically when complete.',
+    description: 'Implement a selected active task brief and validate it. Archive automatically when complete.',
     content: `---
 name: task-implement
-description: Implement the latest active task brief and validate it. Archive automatically when complete.
+description: Implement a selected active task brief and validate it. Archive automatically when complete.
 user-invocable: true
 ---
 
 Purpose
 
-Implement a task from the latest file in .ai/tasks/active/.
+Implement the intended task from .ai/tasks/active/.
 
 Rules
 
-1. Read the latest relevant brief from .ai/tasks/active/.
-2. Follow the acceptance criteria strictly.
-3. Prefer minimal changes.
-4. Respect existing project conventions.
-5. Avoid unnecessary refactoring.
-6. State assumptions explicitly.
-7. Validate the result before stopping.
-8. If the work is complete, archive the brief automatically by moving it to .ai/tasks/archive/.
+1. Identify the intended brief in .ai/tasks/active/. Use a user-specified name or path when provided. Without one, proceed only when a single brief is the clear match. Ask the user when multiple briefs are plausible; do not choose by recency alone.
+2. Read the selected brief and inspect the relevant current code before planning.
+3. Follow the acceptance criteria strictly.
+4. Prefer minimal changes.
+5. Respect existing project conventions.
+6. Avoid unnecessary refactoring.
+7. State assumptions explicitly.
+8. Validate the result before stopping.
+9. If the work is complete, archive the selected brief automatically by moving it to .ai/tasks/archive/.
+
+Brief Sufficiency
+
+Before changing code, and whenever implementation reveals an ambiguity, determine whether the selected brief remains executable against the current project state.
+
+* Investigate facts available from the repository or environment instead of asking the user.
+* For a local, reversible implementation choice that does not materially affect behavior, scope, compatibility, security, data, or acceptance, follow existing conventions and choose the simplest option.
+* Do not infer an unresolved user decision that materially affects those concerns. Ask one focused question at a time, include a recommended answer, and wait.
+* After explicit confirmation of a narrow clarification, record it in the selected active brief before continuing implementation.
+* If clarification materially changes the Goal, accepted scope, or Acceptance Criteria, or the unresolved decisions collectively require material contract revision, stop and require renewed task-explore. Do not implement against an outdated brief.
+* If current project state materially contradicts the brief's context, surface the conflict and resolve it under the same rules.
 
 When making implementation decisions