@winton979/task-cli 1.6.0 → 1.6.2

package/README.md

@@ -121,6 +121,10 @@ archive automatically
 /task-explore  →  TASK_READY  →  /task-implement  →  optional /task-audit
 ```
 
+`task-explore` writes a brief that supports a fresh-session handoff when needed. Before `TASK_READY`, it checks that a new implementation session could determine the goal, acceptance criteria, material constraints, and exclusions from the brief alone. This is a readiness check, not a requirement to start implementation in a new session. The brief preserves confirmed execution-critical context without becoming a repository snapshot; the implementing agent revalidates current repository facts. 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.2",
   "description": "Lightweight task workflow CLI for AI-assisted development",
   "license": "MIT",
   "repository": {

package/src/init.js

@@ -278,6 +278,18 @@ ${DECISIONS_READ_GUIDANCE}
 
 ${COMPLEXITY_ASSESSMENT_GUIDANCE}
 
+Cross-session Readiness
+
+Before finalizing the brief, verify that it would be sufficient if implementation later began in a fresh session without the exploration conversation. This is a readiness check; implementation may proceed in the current session.
+
+Complete this self-check before outputting TASK_READY:
+
+* A fresh implementation session can determine the Goal, Acceptance Criteria, material constraints, and material exclusions from the brief alone.
+* Record every confirmed user decision and other confirmed execution-critical context when omitting it could materially change implementation or validation. This includes material constraints on behavior, scope, compatibility, security, data handling, acceptance, or delivery.
+* Record material exclusions when omitting them could cause plausible scope expansion.
+* Do not turn the brief into a repository snapshot. Record repository facts only when needed to interpret a confirmed constraint; the implementing agent revalidates current facts.
+* Do not output TASK_READY while a material user-owned decision remains unresolved.
+
 Task Brief Format
 
 # Goal
@@ -306,7 +318,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 +334,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