Adopt standard docs/ spec structure (docs/specs + docs/designs), retire tasks/ convention

.github/agents/dev-loop.agent.md

@@ -162,27 +162,27 @@ Break the approved design into bite-sized tasks (2-5 minutes each). Each task in
 - Exact test commands with expected output
 - Commit message
 
-The file format, slug convention, and lifecycle for `tasks/<issue#>-<slug>-plan.md`
+The file format, slug convention, and lifecycle for `docs/designs/<issue#>-<slug>-plan.md`
 are defined authoritatively in **`plan.agent.md` § Saving the Plan to
-`tasks/`**. Do not duplicate that spec here.
+`docs/designs/`**. Do not duplicate that spec here.
 
 `@plan` creates the file at issue-creation time with design + acceptance
 criteria + a skeleton implementation checklist. This phase **resumes /
 updates the existing file in place** -- expand each skeleton checklist
 item into the bite-sized tasks described above. Treat unchecked items as
 the next tasks to execute.
 
-If `tasks/<issue#>-<slug>-prd.md` exists (written by `@prd`), ingest it as
+If `docs/specs/<issue#>-<slug>-prd.md` exists (written by `@prd`), ingest it as
 authoritative requirements input alongside the GitHub issue.
 
-If `tasks/<issue#>-<slug>-plan.md` does not exist (e.g., the issue was
+If `docs/designs/<issue#>-<slug>-plan.md` does not exist (e.g., the issue was
 filed manually, bypassing `@plan`), create it now using the format from
-`plan.agent.md` § Saving the Plan to `tasks/`.
+`plan.agent.md` § Saving the Plan to `docs/designs/`.
 
 After expansion, get user approval and update the GitHub issue with the
 expanded task checklist.
 
-**Exit criteria:** Plan saved/updated in `tasks/<issue#>-<slug>-plan.md`,
+**Exit criteria:** Plan saved/updated in `docs/designs/<issue#>-<slug>-plan.md`,
 user approved, issue updated.
 
 ### Phase 3 -- TDD (Red -> Green)

.github/agents/plan.agent.md

@@ -35,13 +35,13 @@ MUST present it and get approval.
 
 You MUST complete these steps in order:
 
-1. **Explore project context** — check files, docs, recent commits; **scan `tasks/`** for prior PRDs or plans on the same feature (`tasks/<issue#>-<slug>-prd.md`, `tasks/<issue#>-<slug>-plan.md`; fall back to a glob `tasks/*-<slug>-*.md` when the issue number is unknown). If found, surface them and offer to refine the existing design rather than propose a brand-new one.
+1. **Explore project context** — check files, docs, recent commits; **scan `docs/specs/` and `docs/designs/`** for prior PRDs or plans on the same feature (`docs/specs/<issue#>-<slug>-prd.md`, `docs/designs/<issue#>-<slug>-plan.md`; fall back to a glob `docs/specs/*-<slug>-*.md` / `docs/designs/*-<slug>-*.md` when the issue number is unknown). If found, surface them and offer to refine the existing design rather than propose a brand-new one.
 2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
 3. **Propose 2-3 approaches** — with trade-offs and your recommendation
 4. **Present design** — in sections scaled to complexity, get user approval after each section
 5. **Declare the Evidence Plan** — every plan must name the change type, the artifact format, the exact capture command, and the entry-point file the reviewer will open (see "Evidence Plan" below). The dev-loop's Phase 5b verifies the produced artifact matches this declaration.
 6. **Create GitHub issue** — save the approved design as a GitHub issue (the primary output)
-7. **Save the plan to `tasks/<issue#>-<slug>-plan.md`** — durable, in-repo artifact mirroring the issue body. Format defined in **Saving the Plan to `tasks/`** below. This is the single authoritative spec for the `tasks/<issue#>-<slug>-plan.md` file -- `@dev-loop` Phase 2 *resumes / expands* this file, it does not redefine the format.
+7. **Save the plan to `docs/designs/<issue#>-<slug>-plan.md`** — durable, in-repo artifact mirroring the issue body. Format defined in **Saving the Plan to `docs/designs/`** below. This is the single authoritative spec for the `docs/designs/<issue#>-<slug>-plan.md` file -- `@dev-loop` Phase 2 *resumes / expands* this file, it does not redefine the format.
 8. **Transition to implementation** — hand off to `@dev-loop` for the full quality cycle
 
 ## The Process
@@ -137,29 +137,29 @@ For pure-internal refactors (no observable behavior change), the artifact
 format is `attestation` and the capture command is the test runner; the
 attestation markdown still serves as the entry-point file.
 
-## Saving the Plan to `tasks/`
+## Saving the Plan to `docs/designs/`
 
-**This section is the authoritative spec for `tasks/<issue#>-<slug>-plan.md`.**
+**This section is the authoritative spec for `docs/designs/<issue#>-<slug>-plan.md`.**
 `@dev-loop` Phase 2 references this section by name -- it does not redefine
 the file format.
 
 After the GitHub issue is created, save the same approved plan to a
-companion file in the consumer's `tasks/` directory. The file is durable,
+companion file in the consumer's `docs/designs/` directory. The file is durable,
 in-repo, and survives session/scratch loss; `@dev-loop` Phase 2 resumes
 and expands it.
 
 ### Path and Slug Convention
 
-- Path: `tasks/<issue#>-<slug>-plan.md` at the repo root.
+- Path: `docs/designs/<issue#>-<slug>-plan.md` at the repo root.
 - `<issue#>` = the GitHub issue number; `<slug>` = a short kebab-case
   description. Together `<issue#>-<slug>` is the shared identifier carried by
   the GitHub issue, the feature branch (`feat/<issue#>-<slug>`), and the PR.
   Derive both from the current branch name.
-- Look up an existing plan by the exact `tasks/<issue#>-<slug>-plan.md` first,
-  then fall back to a glob `tasks/*-<slug>-plan.md`, then to a bare
-  `tasks/<slug>-plan.md` for legacy files predating the issue-number prefix.
-- Create the `tasks/` directory if it does not yet exist.
-- See `tasks/README.md` (consumer-owned) for the project's local
+- Look up an existing plan by the exact `docs/designs/<issue#>-<slug>-plan.md` first,
+  then fall back to a glob `docs/designs/*-<slug>-plan.md`, then to a bare
+  `docs/designs/<slug>-plan.md` for legacy files predating the issue-number prefix.
+- Create the `docs/designs/` directory if it does not yet exist.
+- See `docs/README.md` (consumer-owned) for the project's local
   conventions; do not contradict it.
 
 ### Required File Structure

.github/agents/prd.agent.md

@@ -12,13 +12,13 @@ This agent uses the default model. No specific model override is required.
 
 Your task is to create a clear, structured, and comprehensive PRD for the project or feature requested by the user.
 
-Save the PRD to `tasks/<issue#>-<slug>-prd.md` at the repo root, where `<issue#>` is the GitHub issue number and `<slug>` is a short kebab-case description -- the same `<issue#>-<slug>` identifier used by the feature branch (`feat/<issue#>-<slug>`). Derive both from the current branch name when one exists. If no issue has been filed yet (a PRD spike), save to the bare `tasks/<slug>-prd.md` and rename it to add the `<issue#>-` prefix once the issue is created. Create the `tasks/` directory first if it does not yet exist (`mkdir tasks` or `New-Item -ItemType Directory -Path tasks -Force`). If the user specifies a different location, use that instead.
+Save the PRD to `docs/specs/<issue#>-<slug>-prd.md` at the repo root, where `<issue#>` is the GitHub issue number and `<slug>` is a short kebab-case description -- the same `<issue#>-<slug>` identifier used by the feature branch (`feat/<issue#>-<slug>`). Derive both from the current branch name when one exists. If no issue has been filed yet (a PRD spike), save to the bare `docs/specs/<slug>-prd.md` and rename it to add the `<issue#>-` prefix once the issue is created. Create the `docs/specs/` directory first if it does not yet exist (`mkdir docs/specs` or `New-Item -ItemType Directory -Path docs/specs -Force`). If the user specifies a different location, use that instead.
 
 Your output should ONLY be the complete PRD in Markdown format unless explicitly confirmed by the user to create GitHub issues from the documented requirements.
 
 ## Instructions for Creating the PRD
 
-0. **Check for an existing PRD**: At the start of the workflow, look for an existing PRD before writing a new one. Derive `<issue#>` and `<slug>` from the current branch (`feat/<issue#>-<slug>`) and check `tasks/<issue#>-<slug>-prd.md` first. If not found, fall back to a glob `tasks/*-<slug>-prd.md` (issue number differs or is unknown), then to the bare `tasks/<slug>-prd.md` for legacy files predating the issue-number prefix. If a PRD already exists for this feature, read it and offer to **update** it rather than overwrite. Surface the existing content to the user and ask whether to revise sections in place, append new sections, or start fresh.
+0. **Check for an existing PRD**: At the start of the workflow, look for an existing PRD before writing a new one. Derive `<issue#>` and `<slug>` from the current branch (`feat/<issue#>-<slug>`) and check `docs/specs/<issue#>-<slug>-prd.md` first. If not found, fall back to a glob `docs/specs/*-<slug>-prd.md` (issue number differs or is unknown), then to the bare `docs/specs/<slug>-prd.md` for legacy files predating the issue-number prefix. If a PRD already exists for this feature, read it and offer to **update** it rather than overwrite. Surface the existing content to the user and ask whether to revise sections in place, append new sections, or start fresh.
 
 1. **Ask clarifying questions**: Before creating the PRD, ask questions to better understand the user's needs.
 

.gitignore

@@ -23,14 +23,4 @@ testResults.xml
 # paths list so
 # this entry would be pure noise in consumer .gitignore files.
 .dogfood-output/
-
-# Upstream-only: this repo is the source of truth for the tasks/ convention
-# but should never contain consumer-style spec artifacts. The tasks/
-# directory is consumer-owned everywhere downstream (see
-# script:AlwaysLocalPaths in Pull-SDLC.ai.ps1); here we ship only the
-# template and a .gitkeep so the directory exists post-clone. Real PRDs
-# and plans should never land in this repo's tasks/ tree.
-tasks/*
-!tasks/README.md
-!tasks/.gitkeep
 # <<< upstream-only <<<