Refactor TaskPlanner documentation to enhance clarity and focus on execution. Key updates include redefining the primary goal to emphasize concrete implementation tasks, refining workflow steps to prioritize execution-focused outputs, and clarifying boundaries to exclude process tasks. This ensures that developers can implement plans with minimal clarification and that validation is embedded within tasks.

Author: jaruesink

.devagent/agents/TaskPlanner.md

@@ -1,9 +1,9 @@
 # TaskPlanner
 
 ## Mission
-- Primary goal: Translate approved specs into ordered, test-aware work packets that the executing developer can implement with minimal clarification.
-- Boundaries / non-goals: Do not write production code, promise delivery dates, or reprioritize roadmap scope; escalate scope tension back to #SpecArchitect or the requester.
-- Success signals: Executor can implement using the plan without requesting major clarifications, reviewers (if any) see clear rationale and validation hooks per task, and downstream dependencies are surfaced before hand-off.
+- Primary goal: Translate approved specs into ordered, execution-focused work packets covering concrete code changes, file operations, and technical implementation that developers can execute with minimal clarification.
+- Boundaries / non-goals: Do not write production code, include rollout/process tasks (announcements, support windows, adoption tracking), promise delivery dates, or reprioritize roadmap scope; focus strictly on what needs to be built or changed in the codebase.
+- Success signals: Executor can implement using the plan without requesting major clarifications, each task specifies concrete files/modules to modify, and technical validation (tests, linting) is included as part of implementation tasks rather than separate process steps.
 
 ## Inputs
 - Required: Approved spec path and status, feature slug and repository entry points, known technical constraints or dependencies, and target planning review date.
@@ -25,14 +25,14 @@
 - Retrieval etiquette: Cite file paths and spec anchors within each task, note assumptions explicitly, and log new references in the feature hub when discovered.
 
 ## Workflow
-1. **Kickoff / readiness checks:** Verify spec approval status, confirm planning scope (full feature vs phase), align on review deadline, and note outstanding risks from the spec.
-2. **Context gathering:** Read the spec, mission metrics, and relevant research; capture impacted systems, dependencies, and success metrics in working notes.
-3. **Outline creation:** Copy the task plan template into the feature's task directory, fill metadata, and map spec sections to potential work streams and validation needs.
-4. **Task drafting:** Break work into ordered slices (<=5 items per review batch), provide rationale tied to spec passages, list code entry points, and describe acceptance tests or instrumentation per task.
-5. **Dependency & risk mapping:** Highlight blockers, cross-team touchpoints, or sequencing constraints; log them in the plan and escalate where ownership is unclear.
-6. **Validation:** Self-check that every spec objective has traceable tasks, tests cover primary flows, and effort is grouped for progressive review; request additional review only when specific approvals are required.
-7. **Output packaging:** Save the task plan to `.devagent/features/YYYY-MM-DD_feature-slug/tasks/YYYY-MM-DD_<descriptor>.md`, update the feature hub summary, and communicate key decisions plus asks to the requester.
-8. **Post-run logging:** Track resolved vs open risks, note approved deviations, and hand off open questions to the appropriate agent.
+1. **Kickoff / readiness checks:** Verify spec approval status, confirm planning scope (full feature vs phase), and note outstanding technical risks from the spec.
+2. **Context gathering:** Read the spec and relevant research; capture impacted files/modules, code dependencies, and technical implementation requirements in working notes.
+3. **Outline creation:** Copy the task plan template into the feature's task directory, fill metadata, and map spec sections to concrete implementation work (file creation, modifications, deletions, config changes).
+4. **Task drafting:** Break work into ordered, execution-focused tasks with concrete deliverables (files changed, functions added, tests written). Each task should specify: what to build/change, which files/modules are affected, and how to validate the change (tests, manual verification). Avoid process tasks like "announce feature" or "monitor adoption"—focus on code changes only.
+5. **Dependency & risk mapping:** Highlight technical blockers (missing APIs, unclear requirements, system dependencies); log them in the plan and escalate where ownership is unclear.
+6. **Validation:** Self-check that every spec objective has traceable implementation tasks, technical validation (tests/linting) is embedded in implementation tasks, and no pure-process tasks remain (rollout, support, announcements should be handled outside task planning).
+7. **Output packaging:** Save the task plan to `.devagent/features/YYYY-MM-DD_feature-slug/tasks/YYYY-MM-DD_<descriptor>.md`, update the feature hub summary, and communicate key technical decisions plus asks to the requester.
+8. **Post-run logging:** Track resolved vs open technical risks, note approved deviations, and hand off open questions to the appropriate agent.
 
 ## Adaptation Notes
 - For quick fixes or small deltas, leverage the template's lightweight view (single backlog group) and focus on regression risks.
@@ -46,8 +46,8 @@
 
 ## Expected Output
 - Artifacts: Markdown task plan derived from the template, stored under the feature's `tasks/` directory with ISO date prefix and linked from the feature hub.
-- Communication: Planning summary covering backlog slices, critical risks, validation strategy, and unresolved questions.
-- Guardrails: Keep each backlog slice reviewable in isolation, avoid embedding delivery commitments, and ensure every task references supporting evidence.
+- Communication: Planning summary covering implementation tasks, critical technical risks, and unresolved questions.
+- Guardrails: Keep tasks execution-focused (concrete code changes only), avoid process tasks (rollouts, announcements, external validation, support windows), ensure every task specifies affected files/modules, and embed validation as part of implementation (not separate tasks).
 
 ## Follow-up Hooks
 - Downstream agents: #TaskExecutor consumes the task plan; #ResearchAgent may follow up on outstanding validation tasks.

.devagent/features/2025-10-01_core-workspace-split/spec/2025-10-01_core-workspace-split-spec.md

@@ -66,23 +66,21 @@ The mission targets "30 days: Daily coding in DevAgent prompts feels natural for
 1. **Maximize portability:** `core/` must work in any project without modification
 2. **Preserve tool-agnosticism:** No vendor lock-in (aligns with C4)
 3. **Support incremental adoption:** Projects can use a subset of agents without breaking references
-4. **Maintain backwards compatibility during migration:** Existing `.devagent/` projects should continue working
-5. **Optimize for onboarding clarity:** New developers should immediately grasp the structure
+4. **Optimize for onboarding clarity:** New developers should immediately grasp the structure
 
 ## Scope Definition
 
 ### In Scope
 - Reorganize `.devagent/` into `core/` and `workspace/` subdirectories
 - Update all agent instruction sheets to reference new paths (`.devagent/core/templates/...`, `.devagent/workspace/features/...`)
 - Update AGENTS.md and create a new `core/README.md` with setup instructions
-- Create a migration guide for existing DevAgent projects
-- Test the new structure against at least one real Lambda Curry project
+- Validate the new structure works with all agent workflows
 
 ### Out of Scope / Future
+- Migration guides for existing DevAgent projects (clean break, no backwards compatibility)
 - Automated sync tools to pull `core/` updates from a central repo (future: DevAgent CLI)
 - Versioning or release tagging for `core/` kit snapshots (defer until multi-project usage confirms need)
 - Tool-specific implementations under `.devagent/tools/` (separate future work per C4)
-- Migration of existing feature hubs' historical artifacts (preserve in place, new work uses new paths)
 
 ## Functional Narrative
 
@@ -133,22 +131,6 @@ The mission targets "30 days: Daily coding in DevAgent prompts feels natural for
 - [ ] No hardcoded assumptions about directory depth or project name
 - [ ] Agent workflows function identically to pre-restructure behavior
 
-### Flow 4: Migrate Existing DevAgent Project
-
-**Trigger:** Existing DevAgent project wants to adopt new structure
-
-**Experience Narrative:**
-1. Developer reads migration guide in `core/README.md`
-2. Developer creates `core/` and `workspace/` directories
-3. Developer moves agents and templates to `core/`, features and memory to `workspace/`
-4. Developer updates custom agent extensions (if any) to reference new paths
-5. Developer validates by running one agent workflow end-to-end
-
-**Acceptance Criteria:**
-- [ ] Migration guide provides file-by-file move instructions
-- [ ] Migration preserves all existing feature hub history and decision logs
-- [ ] Agent invocations work after migration without syntax changes
-- [ ] Migration time under 15 minutes for a standard DevAgent setup
 
 ## Technical Notes & Dependencies
 
@@ -179,7 +161,11 @@ The mission targets "30 days: Daily coding in DevAgent prompts feels natural for
 │   │   ├── spec-document-template.md
 │   │   ├── task-plan-template.md
 │   │   ├── task-prompt-template.md
-│   │   └── tech-stack-template.md
+│   │   ├── tech-stack-template.md
+│   │   └── feature-hub-template/      # Template for new feature hubs
+│   │       ├── README.md
+│   │       ├── research/
+│   │       └── spec/
 │   ├── AGENTS.md                      # Agent roster documentation
 │   └── README.md                      # Core kit usage & setup instructions
 │
@@ -196,8 +182,6 @@ The mission targets "30 days: Daily coding in DevAgent prompts feels natural for
     │   └── _archive/                  # Historical constitution snapshots
     ├── features/                      # Feature hubs with research & specs
     │   ├── README.md
-    │   ├── _template/
-    │   │   └── README.md
     │   └── YYYY-MM-DD_feature-slug/
     │       ├── README.md
     │       ├── research/
@@ -234,68 +218,49 @@ All agent instruction sheets must be updated to use new path conventions:
 
 ### Data Migration
 
-Existing DevAgent projects have artifacts at legacy paths. Migration options:
-
-1. **Big-bang reorg:** Move files atomically, update all references at once
-2. **Symlink bridge:** Create symlinks at old paths pointing to new locations during transition
-3. **Dual-path support:** Agents check both old and new paths with deprecation warnings
-
-**Recommendation:** Big-bang reorg for DevAgent repo itself (dogfooding), symlink bridge for external adopters.
+**Approach:** Clean cut - implement new structure directly in DevAgent repository. No backwards compatibility or migration tooling needed.
 
 ## Risks & Open Questions
 
 | Item | Type | Owner | Mitigation / Next Step | Due |
 | --- | --- | --- | --- | --- |
-| Existing projects break if they pull updates without migrating | Risk | @jaruesink | Provide clear migration guide + changelog in README | Before merge |
 | Agents reference old paths in examples or error messages | Risk | @jaruesink | Audit all agent `.md` files for hardcoded paths | During implementation |
 | Teams may want different `workspace/` layouts per project type | Question | @jaruesink | Start with opinionated default, document customization in FAQ | Post-launch |
 | Should `core/README.md` include setup script or just manual steps? | Question | @jaruesink | Manual steps for v1, script if 3+ projects adopt | Post-validation |
-| Do we version `core/` (e.g., `core-v1.0/`) or rely on git tags? | Question | @jaruesink | Defer until multi-project usage reveals need | Post-validation |
 
 ## Delivery Plan
 
 ### Milestones
 
-**Phase 1: Structure & Documentation (Week 1)**
+**Phase 1: Structure Creation**
 - Create `core/` and `workspace/` directories in DevAgent repo
 - Move files to new locations
-- Update `AGENTS.md` and create `core/README.md` with setup guide
-- Draft migration guide
 
-**Phase 2: Agent Reference Updates (Week 1)**
+**Phase 2: Path Reference Updates**
 - Audit all agent instruction sheets for path references
 - Update agent `.md` files to use new paths
 - Update templates to reference new structure
-- Test agent invocations end-to-end
 
-**Phase 3: Validation & Documentation (Week 2)**
-- Apply new structure to one Lambda Curry project
-- Time setup process and iterate on friction points
-- Document edge cases and FAQs
-- Update constitution (C2) if needed
+**Phase 3: Documentation**
+- Update `AGENTS.md` with new paths
+- Create `core/README.md` with setup guide
+- Update root README
 
-**Phase 4: Rollout & Iteration (Week 3+)**
-- Merge changes to DevAgent main branch
-- Announce to Lambda Curry team with migration guide
-- Support early adopters through migration
-- Collect feedback for v2 improvements
+**Phase 4: Validation**
+- Test agent invocations end-to-end
+- Verify all workflows function correctly
 
 ### Review Gates
 
 - **Pre-implementation:** Design review with @jaruesink (this spec)
-- **Post-migration:** Validation with one real project (sign-off: successful agent run)
-- **Pre-announce:** Documentation completeness check (setup guide, migration guide, FAQ)
+- **Post-implementation:** All agent workflows tested successfully
 
 ### Analytics & QA Requirements
 
 **Validation Signals:**
-- Setup time measured via stopwatch during test runs
-- Zero clarification questions needed during setup by unfamiliar developer
-- All agents execute successfully in migrated structure
-- At least one Lambda Curry project adopts within 30 days
-
-**Rollback Plan:**
-If validation fails, revert to flat `.devagent/` structure and document lessons learned in feature hub.
+- All agents execute successfully in new structure
+- Path references correctly use `core/` and `workspace/` conventions
+- Documentation complete and accurate
 
 ## Approval & Ops Readiness
 
@@ -306,9 +271,7 @@ If validation fails, revert to flat `.devagent/` structure and document lessons
 ### Operational Checklist
 - [ ] Update onboarding documentation with new structure
 - [ ] Add setup instructions to DevAgent repository README
-- [ ] Create migration guide for existing projects
-- [ ] Announce change in Lambda Curry team channel
-- [ ] Monitor adoption and address blockers within 48 hours
+- [ ] Create `core/README.md` with usage guide
 
 ## Appendices & References