Remove outdated documentation and update file structure for feature organization. Deleted AGENTS.md and related feature workflow files. Updated paths in agent documentation to include ISO date prefixes for better chronological sorting. Adjusted README.md to reflect new directory structure and usage guidelines for agents.

Author: jaruesink

.devagent/AGENTS.md

@@ -4,16 +4,17 @@
 - Primary goal: Deliver sourced insights that reduce ambiguity for product discovery, spec drafting, and task execution across three operating modes (general, spec, task) while keeping the executing developer in control.
 - Boundaries / non-goals: Do not draft specs, task plans, or code; avoid committing to delivery dates or tool selections beyond research recommendations; never publish unverified claims.
 - Success signals: Requests return concise findings with citations, downstream agents receive mode-appropriate artifacts without rework, and open questions plus freshness notes are logged for follow-up.
+- Invocation assumption: The executing developer has standing approval to trigger ResearchAgent immediately; note any exceptional approval requirements in the response or follow-up log rather than blocking the run.
 
 ## Inputs
 - Required: Problem statement, desired mode (`general`, `spec`, or `task`), urgency or review date, known constraints (technical, compliance, review), and approval scope for external research.
 - Optional: Prior research notes, telemetry or user feedback, competitive intel, preferred citation style, existing spec or task references.
-- Request missing info by sending a mode-specific checklist (e.g., "Provide feature slug and target spec file" for spec, "Link the task plan entry" for task) and pausing until confirmation.
+- Request missing info by sending a mode-specific checklist (e.g., "Provide feature slug and target spec file" for spec, "Link the task plan entry" for task); if core inputs are still missing, record them as open questions and proceed with the available context.
 
 ## Resource Strategy
 - `.devagent/templates/research-packet-template.md` — base outline for spec- and task-mode packets; duplicate and prune optional sections.
-- `.devagent/features/<feature-slug>/research/` — canonical storage for feature-spec research artifacts (one folder per feature).
-- `.devagent/tasks/<feature-slug>/<task-id>/research/` — storage for task-level research; create subfolders per task when first used.
+- `.devagent/features/YYYY-MM-DD_feature-slug/research/` — canonical storage for feature-spec research artifacts (one folder per feature).
+- `.devagent/features/YYYY-MM-DD_feature-slug/tasks/<task-id>/research/` — storage for task-level research; create subfolders per task when first used.
 - `.devagent/research/drafts/` — scratch space for in-progress packets before filing.
 - Internal retrieval connectors over `.devagent/product`, existing specs, task plans, and decision logs.
 - External research stack (Exa, Context7, approved APIs) — run freshness sweeps when internal sources lack recency; capture timestamps.
@@ -23,8 +24,8 @@
 
 ## Operating Modes
 - **General Research:** Triggered by exploratory questions or early discovery. Provide findings inline in chat (summary + key bullets + citations). Log notable open questions in `guiding-questions.md` when future work is implied. No filesystem artifact unless explicitly requested.
-- **Spec Research:** Supports feature-level specs. Produce a dated packet at `.devagent/features/<feature-slug>/research/YYYY-MM-DD_<descriptor>.md` using the research packet template. Cross-link to the related spec and mission artifacts.
-- **Task Research:** Informs a specific backlog item. Create a packet at `.devagent/tasks/<feature-slug>/<task-id>/research/YYYY-MM-DD_<descriptor>.md`. Include task context (plan excerpt, acceptance criteria, code entry points) so Executor can act with full detail.
+- **Spec Research:** Supports feature-level specs. Produce a dated packet at `.devagent/features/YYYY-MM-DD_feature-slug/research/YYYY-MM-DD_<descriptor>.md` using the research packet template. Cross-link to the related spec and mission artifacts.
+- **Task Research:** Informs a specific backlog item. Create a packet at `.devagent/features/YYYY-MM-DD_feature-slug/tasks/<task-id>/research/YYYY-MM-DD_<descriptor>.md`. Include task context (plan excerpt, acceptance criteria, code entry points) so Executor can act with full detail.
 
 ## Knowledge Sources
 - Internal: `.devagent/memory/constitution.md`, `.devagent/product/mission.md`, `.devagent/product/guiding-questions.md`, feature hubs, specs, task plans, ADRs, repository docs.

.devagent/agents/ResearchAgent.md

@@ -12,8 +12,8 @@
 
 ## Resource Strategy
 - `.devagent/templates/spec-document-template.md` (Spec Document Template) — duplicate per engagement and treat as the authoritative outline.
-- `.devagent/features/<feature-slug>/research/` — upstream research artifacts to cite for problem, user, or market context.
-- `.devagent/features/<feature-slug>/spec/` — canonical location for active specs and change history.
+- `.devagent/features/YYYY-MM-DD_feature-slug/research/` — upstream research artifacts to cite for problem, user, or market context.
+- `.devagent/features/YYYY-MM-DD_feature-slug/spec/` — canonical location for active specs and change history.
 - #ResearchAgent — validate assumptions or source additional data before finalizing solution or metrics sections.
 - #ProductMissionPartner — confirm mission alignment, business framing, and cross-initiative dependencies when scope shifts.
 - #TaskPlanner — sanity-check acceptance criteria format before hand-off when expectations are ambiguous.
@@ -29,7 +29,7 @@
 3. **Outline creation:** Copy the spec template into the feature spec directory, fill metadata, mark each section with planned evidence, remove optional sections that are irrelevant, and flag gaps for follow-up.
 4. **Drafting:** Populate sections (Context, Objectives, Users, Solution Principles, Scope, Functional Narrative, Experience references, Technical notes, Risks, Delivery plan, Approval) with concise prose, linking to supporting artifacts and capturing assumptions with owners.
 5. **Validation:** Run a self-check against the template checklist, confirm success metrics map to objectives, ensure acceptance criteria cover primary flows, and request targeted reviews when required.
-6. **Output packaging:** Save the spec to `.devagent/features/<feature-slug>/spec/YYYY-MM-DD_<descriptor>.md`, update change log, and summarize key updates plus open questions in the feature hub or status channel.
+6. **Output packaging:** Save the spec to `.devagent/features/YYYY-MM-DD_feature-slug/spec/YYYY-MM-DD_<descriptor>.md`, update change log, and summarize key updates plus open questions in the feature hub or status channel.
 7. **Post-run logging:** Record final decisions and unresolved risks in per-feature memory or decision logs, and note follow-up tasks for downstream agents.
 
 ## Adaptation Notes

.devagent/agents/SpecArchitect.md

@@ -12,8 +12,8 @@
 
 ## Resource Strategy
 - Source repository tooling (`repo_tools`, project-specific scripts) — use for branch management, formatting, linting, testing, and static analysis before hand-off.
-- `.devagent/tasks/<feature-slug>/` — canonical task packet; mirror status updates and reference IDs in execution notes.
-- `.devagent/execution/<feature-slug>/` — store implementation logs, test transcripts, and decision records per run using ISO-dated filenames.
+- `.devagent/features/YYYY-MM-DD_feature-slug/tasks/` — canonical task packet; mirror status updates and reference IDs in execution notes.
+- `.devagent/execution/YYYY-MM-DD_feature-slug/` — store implementation logs, test transcripts, and decision records per run using ISO-dated filenames.
 - Reviewer (if required) — coordinate for pairing sessions, code reviews, and approval gates before merging.
 - Observability & staging environments — deploy feature branches when acceptance criteria call for integrated validation; capture links in the execution log.
 
@@ -41,7 +41,7 @@
 - Failing regression tests unrelated to the packet: bisect to confirm origin, log findings, and coordinate with maintainers to prevent blocking delivery.
 
 ## Expected Output
-- Artifacts: Feature branch (or PR) aligned with the task packet, updated execution log stored under `.devagent/execution/<feature-slug>/`, validation evidence (test results, deployment links), and any generated documentation updates.
+- Artifacts: Feature branch (or PR) aligned with the task packet, updated execution log stored under `.devagent/execution/YYYY-MM-DD_feature-slug/`, validation evidence (test results, deployment links), and any generated documentation updates.
 - Communication: Implementation summary referencing task IDs and acceptance criteria, plus explicit next steps for reviewers or other recipients when required.
 - Guardrails: Never merge without required approval, ensure all mandatory checks pass, and document any scope deviations or technical debt follow-ups.
 

.devagent/agents/TaskExecutor.md

@@ -12,9 +12,9 @@
 
 ## Resource Strategy
 - `.devagent/templates/task-plan-template.md` — duplicate per feature to structure backlog slices and validation notes.
-- `.devagent/features/<feature-slug>/spec/` — source spec, change log, and risks; link relevant sections within task rationales.
-- `.devagent/features/<feature-slug>/research/` — pull user or evidence context that informs prioritization.
-- `.devagent/tasks/<feature-slug>/` — canonical location for active task plans and updates.
+- `.devagent/features/YYYY-MM-DD_feature-slug/spec/` — source spec, change log, and risks; link relevant sections within task rationales.
+- `.devagent/features/YYYY-MM-DD_feature-slug/research/` — pull user or evidence context that informs prioritization.
+- `.devagent/features/YYYY-MM-DD_feature-slug/tasks/` — canonical location for active task plans and updates inside the feature hub.
 - repository search — capture code references, impacted modules, and existing tests.
 - #SpecArchitect — confirm interpretation of ambiguous requirements or phased delivery assumptions.
 - #TaskExecutor — pressure-test task granularity or test expectations when uncertainty remains.
@@ -31,7 +31,7 @@
 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/tasks/<feature-slug>/YYYY-MM-DD_<descriptor>.md`, update the feature hub summary, and communicate key decisions plus asks to the requester.
+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.
 
 ## Adaptation Notes

.devagent/agents/TaskPlanner.md

@@ -6,7 +6,7 @@ Organize discovery, specs, and downstream planning artifacts by feature so cross
 
 ```
 .devagent/features/
-  <feature-slug>/
+  YYYY-MM-DD_feature-slug/
     README.md                # short description, owners, status
     research/
       YYYY-MM-DD_<slug>-research.md
@@ -16,13 +16,14 @@ Organize discovery, specs, and downstream planning artifacts by feature so cross
     delivery/                # optional: launch notes, metrics snapshots
 ```
 
+- **Feature folder:** prefix the slug with the kickoff date in ISO format (`YYYY-MM-DD_my-feature`). This keeps active work sorted chronologically while retaining readable slugs.
 - **Feature slug:** lower-case, hyphenated version of the initiative name (e.g. `mission-alignment-dashboard`).
 - **Chronological filenames:** prefix with ISO date (`YYYY-MM-DD`) followed by a concise suffix. Use the same slug for related artifacts across research/spec/planning to keep lists sorted.
 - **README.md:** summarize the feature, decision status (idea, discovery, in progress, shipped), key stakeholders, and links to live dashboards if any.
 
 ## How to Add a New Feature Hub
 
-1. Copy `_template` to a new slugged folder: `cp -R .devagent/features/_template .devagent/features/<feature-slug>`.
+1. Copy `_template` to a new dated, slugged folder: `cp -R .devagent/features/_template .devagent/features/$(date +%F)_<feature-slug>`.
 2. Update the new `README.md` with feature context, owners, and status.
 3. Author research packets under `research/` using date-prefixed filenames (e.g. `2025-09-29_initial-research.md`).
 4. Publish specs under `spec/` following the same date convention; include a short suffix such as `-v1` or `-revA` when multiple drafts exist on the same day.

.devagent/features/README.md

@@ -16,7 +16,7 @@ Every feature request currently routes through the full complex workflow, regard
 - Reduce median cycle time for features classified as Simple by at least 30% versus today (baseline to be captured).
 - Maintain or improve rework rate (<5% of Simple lane work requiring reclassification post-start).
 - Achieve 100% clarity for the executing developer on when to involve ProductMissionPartner, ResearchAgent, and SpecArchitect (self-reported survey after first month).
-- Track governance decisions for every Complex classification in the spec change log.
+- Capture classification decisions and rationale for Complex work in the spec change log.
 
 ## Users & Insights
 Primary users are developers initiating feature work and directly coordinating downstream agents. Early insights (informal execution debriefs) show developers want the ability to move fast on low-risk updates while trusting that larger changes will still be shepherded through a rigorous process. A quick follow-up with whoever owns compliance ensures Simple changes stay within guardrails.
@@ -30,8 +30,7 @@ Primary users are developers initiating feature work and directly coordinating d
 - Make minimal assumptions about delivery rituals; when workflows depend on sprints, QA roles, or stakeholder cadences, document the assumption and point to the source agent guide for confirmation.
 
 ## Scope Definition
-- **In Scope:** Classification rules, workflows for Simple and Complex lanes, agent invocation guidelines, governance model, success metrics, and rollout plan for adoption.
-- **In Scope:** Classification rules, workflows for Simple and Complex lanes, agent invocation guidelines, governance model, success metrics, rollout plan for adoption, and audit requirements for agent guides to default to single-developer execution.
+- **In Scope:** Classification rules, workflows for Simple and Complex lanes, agent invocation guidelines, success metrics, rollout plan for adoption, and audit requirements for agent guides to default to single-developer execution.
 - **Out of Scope / Future:** Automated tooling changes, analytics dashboard implementation beyond definition, integration with external ticketing systems, and retrospective process updates after launch.
 
 ## Functional Narrative
@@ -77,11 +76,6 @@ Primary users are developers initiating feature work and directly coordinating d
 - Ensure automation or scripts (if any) reference existing agent invocation patterns.
 - Confirm compatibility with current DevAgent CLI prompts.
 
-## Governance & Auditing
-- Maintain an audit log of assumptions and their status in `.devagent/governance/assumptions.md` (create if missing).
-- Review AGENTS.md and each agent guide every two months for implicit team-structure assumptions; default recommendations must support a solo developer, with any extra roles documented as explicit exceptions.
-- Document deviations from the single-developer default alongside the relevant agent guide and link back here.
-
 ## Risks & Open Questions
 | Item | Type (Risk / Question) | Owner | Mitigation / Next Step | Due |
 | --- | --- | --- | --- | --- |
@@ -91,17 +85,6 @@ Primary users are developers initiating feature work and directly coordinating d
 | Tooling support for classification logging | Risk | Execution Owner | Evaluate if current tracking tools suffice; propose lightweight log | 2025-10-05 |
 | Delivery assumptions tied to agile sprints and specific roles | Risk | SpecArchitect | Audit agent docs for implicit assumptions; update spec and guides with neutral language | 2025-10-06 |
 
-## Delivery Plan (Optional)
-- Within 3 days of spec approval: Finalize classification rules and gather missing data.
-- Within 1 week of the first production use: Review draft spec against real usage feedback and capture adjustments.
-- After two Simple-lane executions: Pilot retro to confirm metrics collection and lane clarity.
-- Before fourth Complex-lane engagement: Publish documentation update and optional walkthrough.
-
-## Approval & Ops Readiness (Optional)
-- Default approval rests with the executing developer.
-- If additional approvals are needed, capture the confirmations alongside the change log.
-- Update onboarding docs and AGENTS.md references to new workflow before rollout.
-
 ## Appendices & References (Optional)
 - TBD: add link to execution feedback summary once compiled.
 - TBD: include checklist template path.

.devagent/features/simple-vs-complex-feature-workflows/README.md

@@ -3,8 +3,8 @@
 - Mode: <Spec | Task>
 - Requested By: <Name>
 - Last Updated: <YYYY-MM-DD>
-- Related Spec: `.devagent/features/<feature-slug>/spec/<file>.md` (remove if Mode = Task and spec not yet created)
-- Related Task Plan (Optional): `.devagent/tasks/<feature-slug>/<task-id>/<plan-file>.md`
+- Related Spec: `.devagent/features/YYYY-MM-DD_feature-slug/spec/<file>.md` (remove if Mode = Task and spec not yet created)
+- Related Task Plan (Optional): `.devagent/features/YYYY-MM-DD_feature-slug/tasks/<task-id>/<plan-file>.md`
 - Storage Path: <Paste final file path>
 - Stakeholders: <Name (Role)>
 - Notes: Remove sections marked `(Optional)` if not relevant.