@legioncodeinc/rflectr 0.1.0 → 0.1.1

package/library/knowledge/private/standards/documentation-framework.md

@@ -1,154 +1,154 @@
-# Documentation Framework
-
-> Category: Standards | Version: 1.0 | Date: (fill in on init) | Status: Canonical
-
-The single source of truth for how documentation is written in this repository. Every document — feature PRDs, issue PRDs, QA reports, architecture docs, API references, guides — must conform to the standards defined here. If a document type is not covered, add a new section to this file rather than inventing a local convention.
-
----
-
-## 1. Document Types
-
-| Type | Purpose | Location | Primary audience |
-|---|---|---|---|
-| **Issue IRD** | Implementation plan for a specific GitHub issue | `library/requirements/issues/issue-<###>-<title>/ird-issue-<###>-<title>.md` | Implementation engineer |
-| **Feature PRD** | Planned feature spec (forward or retroactive) | `library/requirements/features/feature-<###>-<title>/prd-feature-<###>-<title>.md` (or `prd-feature-<###>-<title>-ck-<clickupId>.md` if from ClickUp) | Implementation engineer |
-| **QA Report (tied)** | Audit of an implementation against its plan | The plan's own `reports/<date>-qa-report.md` subfolder | Team lead, author of the feature |
-| **QA Report (standalone)** | Audit not tied to a single plan | `library/qa/<domain>/<date>-qa-report.md` | Team lead, audit reviewer |
-| **Architecture Doc** | System design, data flows, component relationships | `library/knowledge-base/architecture/` | Senior engineers, architects |
-| **API Reference** | Endpoint-by-endpoint documentation with schemas | `library/knowledge-base/api/` | Frontend devs, API consumers |
-| **How-to Guide** | Runbooks for setup, testing, deploying, adding features | `library/knowledge-base/how-to-guides/` | New engineers, DevOps |
-| **Integration Doc** | Third-party service configuration and error handling | `library/knowledge-base/integrations/` | DevOps, engineers wiring services |
-| **UX/UI Standard** | Visual design language — tokens, components, patterns | `library/knowledge-base/design/` | Designers, frontend devs |
-| **Feature Doc** | Completed feature reference (post-ship) | `library/knowledge-base/features/` | Any engineer joining the project |
-| **Spec** | Feature-level handoff spec for a UI flow | `library/knowledge-base/specs/` | Frontend engineers |
-| **Product Brief** | Product vision, scope, roadmap | `library/knowledge-base/product/` | Team, stakeholders |
-| **Standards Doc** | Rules for writing documentation itself | `library/knowledge-base/standards/` | All contributors |
-| **Release Notes** | What changed in each release | `library/knowledge-base/releases/` | All team members |
-
----
-
-## 2. Universal Document Header
-
-Every markdown file under `library/knowledge-base/` starts with:
-
-```markdown
-# <Document Title>
-
-> Category: <Type> | Version: <X.Y> | Date: <Month YYYY> | Status: <Active | Draft | Archived>
-
-<One-sentence description of what this document covers and who should read it.>
-
-**Related:**
-- [Link to related doc]
-- [Link to source code: `src/path/to/file.ts`]
-```
-
-- **Version** — starts at `1.0`; patch bumps (`1.0` → `1.1`) for additions, minor bumps (`1.x` → `2.0`) for reorganizations.
-- **Date** — current month/year on the last meaningful edit.
-- **Status** values:
-  - `Active` — current, should be kept up to date
-  - `Draft` — work in progress, not authoritative
-  - `Archived` — historical, no longer maintained
-  - `Canonical` — (for standards docs only) highest authority; overrides ad-hoc conventions
-
-Requirements-type docs (issue IRDs, feature PRDs, QA reports) use a different header format documented in their respective guides.
-
----
-
-## 3. Filename Conventions
-
-| Document type | Folder + filename pattern | Example |
-|---|---|---|
-| Issue IRD | `issue-<###>-<title>/ird-issue-<###>-<title>.md` (with sibling `reports/`) | `issue-046-stale-cached-responses/ird-issue-046-stale-cached-responses.md` |
-| Feature PRD | `feature-<###>-<title>/prd-feature-<###>-<title>.md` (with sibling `reports/`) | `feature-007-user-profile-export/prd-feature-007-user-profile-export.md` |
-| Feature PRD (from ClickUp) | `feature-<###>-<title>/prd-feature-<###>-<title>-ck-<clickupId>.md` | `feature-007-user-profile-export/prd-feature-007-user-profile-export-ck-86c8wq2k1.md` |
-| QA report (tied to plan) | `<plan-folder>/reports/<date>-qa-report.md` | `feature-007-user-profile-export/reports/2026-04-26-qa-report.md` |
-| QA report (standalone) | `library/qa/<domain>/<date>-qa-report.md` | `library/qa/auth/2026-04-26-qa-report.md` |
-| Knowledge-base | `<domain>/<kebab-slug>.md` (no numeric prefix) | `architecture/authentication-flow.md` |
-
-**Numbering rules:**
-- `<###>` is **3-digit zero-padded** (`006`, `046`, `093`, `100`). 4+ digit natural width.
-- Issue numbers follow the GitHub issue number.
-- Feature numbers are repo-local sequential; take `max + 1` from existing folders (open + `completed/`).
-- Titles are lowercase kebab-case, ≤60 chars.
-- The optional ClickUp suffix `-ck-<clickupId>` goes on the **main file only**, never on the folder name.
-
----
-
-## 4. Folder Location Rules
-
-| Folder | Meaning |
-|---|---|
-| `library/requirements/features/feature-<###>-<title>/` | Feature work in progress. |
-| `library/requirements/features/completed/feature-<###>-<title>/` | Feature has shipped. Move the entire folder (PRD + `reports/`). |
-| `library/requirements/issues/issue-<###>-<title>/` | Issue work in progress (GitHub issue OPEN). |
-| `library/requirements/issues/completed/issue-<###>-<title>/` | Issue has been resolved (GitHub issue CLOSED). Move the entire folder (IRD + `reports/`). Symmetric to features. |
-| `<plan-folder>/reports/` | QA reports tied to that specific feature/issue. Travel with the folder when it moves. |
-| `library/qa/<domain>/` | Standalone QA reports — broad audits not tied to a single plan. |
-
-Move folders when status changes. Never edit lifecycle state in frontmatter alone.
-
----
-
-## 5. Writing Rules (all doc types)
-
-1. **Ground every claim in code.** Quote source with file path + line range; never paraphrase signatures.
-2. **One topic per document.** Split if a doc exceeds ~500 lines.
-3. **Progressive disclosure.** Open with "why this exists" and "who should read it"; deep details below.
-4. **Link out, don't duplicate.** If another doc covers a subtopic, link to it.
-5. **Diagrams use mermaid.** Prefer `flowchart TD` or `sequenceDiagram`. No explicit colors.
-6. **No time-sensitive language.** Avoid "currently", "recently", "as of". Use explicit dates.
-7. **No personal opinions.** Docs describe decisions and rationale, not preferences.
-
----
-
-## 6. Cross-Linking Conventions
-
-- Use relative paths: `[title](../relative/path.md)`.
-- Link to code with file paths (and line numbers where useful): `` `src/routes/users.ts:42-80` ``.
-- PRDs and IRDs link to their related issues, features, and QA reports in a **Related** section at the end.
-- Knowledge-base docs link to the PRDs that drove them (when applicable) and to source code.
-
----
-
-## 7. Diagram Rules
-
-- Mermaid preferred (renders everywhere GitHub does).
-- Use `flowchart TD` (top-down) for process flows; `sequenceDiagram` for temporal flows; `erDiagram` for data models.
-- Node IDs: no spaces (use `camelCase` or `under_scores`).
-- No explicit colors (breaks dark mode).
-- No `click` events.
-- Quote labels containing parentheses, brackets, or colons.
-
----
-
-## 8. Versioning + Dates
-
-- **Versioning** is per-document, not repo-wide. Bump on meaningful content change.
-- **Dates** use the current month/year (from the system clock), not arbitrary timestamps.
-- Each document optionally ends with a **Changelog** section listing version bumps.
-
----
-
-## 9. Ownership
-
-- Requirements docs (issue IRDs, feature PRDs) are owned by the implementation author. QA reports are owned by `quality-guardian`.
-- Knowledge-base docs are owned by the team collectively — anyone may edit with a PR.
-- Standards docs (this file included) require team consensus before changing.
-
----
-
-## 10. Bootstrap — After `initialize`
-
-When `library-guardian initialize` seeds a repo:
-
-1. Replace the placeholder "(fill in on init)" in the header above with the current month/year.
-2. Replace any project-name placeholders in the seeded README files with your repo's actual name.
-3. Edit any section of this framework that doesn't match your team's conventions — then commit.
-4. Start using the agent: ingest issues, plan features, document architecture.
-
----
-
-## Changelog
-
-- v1.0 — Initial template seeded by `library-guardian`. Customize per repo.
+# Documentation Framework
+
+> Category: Standards | Version: 1.0 | Date: (fill in on init) | Status: Canonical
+
+The single source of truth for how documentation is written in this repository. Every document — feature PRDs, issue PRDs, QA reports, architecture docs, API references, guides — must conform to the standards defined here. If a document type is not covered, add a new section to this file rather than inventing a local convention.
+
+---
+
+## 1. Document Types
+
+| Type | Purpose | Location | Primary audience |
+|---|---|---|---|
+| **Issue IRD** | Implementation plan for a specific GitHub issue | `library/requirements/issues/issue-<###>-<title>/ird-issue-<###>-<title>.md` | Implementation engineer |
+| **Feature PRD** | Planned feature spec (forward or retroactive) | `library/requirements/features/feature-<###>-<title>/prd-feature-<###>-<title>.md` (or `prd-feature-<###>-<title>-ck-<clickupId>.md` if from ClickUp) | Implementation engineer |
+| **QA Report (tied)** | Audit of an implementation against its plan | The plan's own `reports/<date>-qa-report.md` subfolder | Team lead, author of the feature |
+| **QA Report (standalone)** | Audit not tied to a single plan | `library/qa/<domain>/<date>-qa-report.md` | Team lead, audit reviewer |
+| **Architecture Doc** | System design, data flows, component relationships | `library/knowledge-base/architecture/` | Senior engineers, architects |
+| **API Reference** | Endpoint-by-endpoint documentation with schemas | `library/knowledge-base/api/` | Frontend devs, API consumers |
+| **How-to Guide** | Runbooks for setup, testing, deploying, adding features | `library/knowledge-base/how-to-guides/` | New engineers, DevOps |
+| **Integration Doc** | Third-party service configuration and error handling | `library/knowledge-base/integrations/` | DevOps, engineers wiring services |
+| **UX/UI Standard** | Visual design language — tokens, components, patterns | `library/knowledge-base/design/` | Designers, frontend devs |
+| **Feature Doc** | Completed feature reference (post-ship) | `library/knowledge-base/features/` | Any engineer joining the project |
+| **Spec** | Feature-level handoff spec for a UI flow | `library/knowledge-base/specs/` | Frontend engineers |
+| **Product Brief** | Product vision, scope, roadmap | `library/knowledge-base/product/` | Team, stakeholders |
+| **Standards Doc** | Rules for writing documentation itself | `library/knowledge-base/standards/` | All contributors |
+| **Release Notes** | What changed in each release | `library/knowledge-base/releases/` | All team members |
+
+---
+
+## 2. Universal Document Header
+
+Every markdown file under `library/knowledge-base/` starts with:
+
+```markdown
+# <Document Title>
+
+> Category: <Type> | Version: <X.Y> | Date: <Month YYYY> | Status: <Active | Draft | Archived>
+
+<One-sentence description of what this document covers and who should read it.>
+
+**Related:**
+- [Link to related doc]
+- [Link to source code: `src/path/to/file.ts`]
+```
+
+- **Version** — starts at `1.0`; patch bumps (`1.0` → `1.1`) for additions, minor bumps (`1.x` → `2.0`) for reorganizations.
+- **Date** — current month/year on the last meaningful edit.
+- **Status** values:
+  - `Active` — current, should be kept up to date
+  - `Draft` — work in progress, not authoritative
+  - `Archived` — historical, no longer maintained
+  - `Canonical` — (for standards docs only) highest authority; overrides ad-hoc conventions
+
+Requirements-type docs (issue IRDs, feature PRDs, QA reports) use a different header format documented in their respective guides.
+
+---
+
+## 3. Filename Conventions
+
+| Document type | Folder + filename pattern | Example |
+|---|---|---|
+| Issue IRD | `issue-<###>-<title>/ird-issue-<###>-<title>.md` (with sibling `reports/`) | `issue-046-stale-cached-responses/ird-issue-046-stale-cached-responses.md` |
+| Feature PRD | `feature-<###>-<title>/prd-feature-<###>-<title>.md` (with sibling `reports/`) | `feature-007-user-profile-export/prd-feature-007-user-profile-export.md` |
+| Feature PRD (from ClickUp) | `feature-<###>-<title>/prd-feature-<###>-<title>-ck-<clickupId>.md` | `feature-007-user-profile-export/prd-feature-007-user-profile-export-ck-86c8wq2k1.md` |
+| QA report (tied to plan) | `<plan-folder>/reports/<date>-qa-report.md` | `feature-007-user-profile-export/reports/2026-04-26-qa-report.md` |
+| QA report (standalone) | `library/qa/<domain>/<date>-qa-report.md` | `library/qa/auth/2026-04-26-qa-report.md` |
+| Knowledge-base | `<domain>/<kebab-slug>.md` (no numeric prefix) | `architecture/authentication-flow.md` |
+
+**Numbering rules:**
+- `<###>` is **3-digit zero-padded** (`006`, `046`, `093`, `100`). 4+ digit natural width.
+- Issue numbers follow the GitHub issue number.
+- Feature numbers are repo-local sequential; take `max + 1` from existing folders (open + `completed/`).
+- Titles are lowercase kebab-case, ≤60 chars.
+- The optional ClickUp suffix `-ck-<clickupId>` goes on the **main file only**, never on the folder name.
+
+---
+
+## 4. Folder Location Rules
+
+| Folder | Meaning |
+|---|---|
+| `library/requirements/features/feature-<###>-<title>/` | Feature work in progress. |
+| `library/requirements/features/completed/feature-<###>-<title>/` | Feature has shipped. Move the entire folder (PRD + `reports/`). |
+| `library/requirements/issues/issue-<###>-<title>/` | Issue work in progress (GitHub issue OPEN). |
+| `library/requirements/issues/completed/issue-<###>-<title>/` | Issue has been resolved (GitHub issue CLOSED). Move the entire folder (IRD + `reports/`). Symmetric to features. |
+| `<plan-folder>/reports/` | QA reports tied to that specific feature/issue. Travel with the folder when it moves. |
+| `library/qa/<domain>/` | Standalone QA reports — broad audits not tied to a single plan. |
+
+Move folders when status changes. Never edit lifecycle state in frontmatter alone.
+
+---
+
+## 5. Writing Rules (all doc types)
+
+1. **Ground every claim in code.** Quote source with file path + line range; never paraphrase signatures.
+2. **One topic per document.** Split if a doc exceeds ~500 lines.
+3. **Progressive disclosure.** Open with "why this exists" and "who should read it"; deep details below.
+4. **Link out, don't duplicate.** If another doc covers a subtopic, link to it.
+5. **Diagrams use mermaid.** Prefer `flowchart TD` or `sequenceDiagram`. No explicit colors.
+6. **No time-sensitive language.** Avoid "currently", "recently", "as of". Use explicit dates.
+7. **No personal opinions.** Docs describe decisions and rationale, not preferences.
+
+---
+
+## 6. Cross-Linking Conventions
+
+- Use relative paths: `[title](../relative/path.md)`.
+- Link to code with file paths (and line numbers where useful): `` `src/routes/users.ts:42-80` ``.
+- PRDs and IRDs link to their related issues, features, and QA reports in a **Related** section at the end.
+- Knowledge-base docs link to the PRDs that drove them (when applicable) and to source code.
+
+---
+
+## 7. Diagram Rules
+
+- Mermaid preferred (renders everywhere GitHub does).
+- Use `flowchart TD` (top-down) for process flows; `sequenceDiagram` for temporal flows; `erDiagram` for data models.
+- Node IDs: no spaces (use `camelCase` or `under_scores`).
+- No explicit colors (breaks dark mode).
+- No `click` events.
+- Quote labels containing parentheses, brackets, or colons.
+
+---
+
+## 8. Versioning + Dates
+
+- **Versioning** is per-document, not repo-wide. Bump on meaningful content change.
+- **Dates** use the current month/year (from the system clock), not arbitrary timestamps.
+- Each document optionally ends with a **Changelog** section listing version bumps.
+
+---
+
+## 9. Ownership
+
+- Requirements docs (issue IRDs, feature PRDs) are owned by the implementation author. QA reports are owned by `quality-guardian`.
+- Knowledge-base docs are owned by the team collectively — anyone may edit with a PR.
+- Standards docs (this file included) require team consensus before changing.
+
+---
+
+## 10. Bootstrap — After `initialize`
+
+When `library-guardian initialize` seeds a repo:
+
+1. Replace the placeholder "(fill in on init)" in the header above with the current month/year.
+2. Replace any project-name placeholders in the seeded README files with your repo's actual name.
+3. Edit any section of this framework that doesn't match your team's conventions — then commit.
+4. Start using the agent: ingest issues, plan features, document architecture.
+
+---
+
+## Changelog
+
+- v1.0 — Initial template seeded by `library-guardian`. Customize per repo.

package/library/knowledge/public/README.md

@@ -1,49 +1,49 @@
----
-ai_description: |
-  This folder contains customer-facing / end-user documentation.
-  Approved sub-folders: overview/, guides/, faqs/, and any domain
-  folder explicitly designated public by the team.
-  Do NOT file internal engineering docs, ADRs, pricing strategy, or
-  security-sensitive material here.
-  Write path: library/knowledge/public/<domain>/<kebab-slug>.md.
-  All files here may eventually be surfaced in the public help center
-  (Phase 2). Mark each doc with the standard knowledge-base header:
-  Category / Version / Date / Status.
-human_description: |
-  Customer-facing documentation. Content here may be published externally.
-  - overview/: what this product is, glossary, elevator pitch
-  - guides/: how-to guides written for users, not developers
-  - faqs/: frequently asked questions
-  Only add content here that you are comfortable sharing publicly.
-  Internal notes, pricing strategy, and architecture docs belong in
-  knowledge/private/ instead.
----
-
-# Knowledge — Public
-
-Customer-facing documentation for **rflectr** by [Legion Code Inc.](https://github.com/legioncodeinc) Anything in this folder may eventually be published to the help center.
-
-## Documentation map
-
-**Start here:** [What is rflectr?](overview/what-is-rflectr.md)
-
-| Section | Docs |
-|---|---|
-| [Overview](overview/) | [What is rflectr?](overview/what-is-rflectr.md) |
-| [Guides](guides/) | [Providers](guides/providers.md) · [Claude Desktop](guides/claude-desktop.md) · [Codex](guides/codex.md) · [Gemini CLI](guides/gemini-cli.md) · [API Server](guides/api-server.md) · [AI Agents](guides/ai-agents.md) · [Model Compatibility](guides/model-compatibility.md) |
-| [FAQs](faqs/) | [Troubleshooting](faqs/troubleshooting.md) |
-
-## Approved sub-folders
-
-| Folder | Contents |
-|---|---|
-| `overview/` | What this product is, glossary, elevator pitch, high-level FAQs |
-| `guides/` | Step-by-step user guides (written for customers, not developers) |
-| `faqs/` | Frequently asked questions from customers |
-
-## What does NOT belong here
-
-- Internal architecture docs or ADRs
-- Pricing strategy or competitive analysis
-- Engineering standards
-- Anything you would not want a customer to read
+---
+ai_description: |
+  This folder contains customer-facing / end-user documentation.
+  Approved sub-folders: overview/, guides/, faqs/, and any domain
+  folder explicitly designated public by the team.
+  Do NOT file internal engineering docs, ADRs, pricing strategy, or
+  security-sensitive material here.
+  Write path: library/knowledge/public/<domain>/<kebab-slug>.md.
+  All files here may eventually be surfaced in the public help center
+  (Phase 2). Mark each doc with the standard knowledge-base header:
+  Category / Version / Date / Status.
+human_description: |
+  Customer-facing documentation. Content here may be published externally.
+  - overview/: what this product is, glossary, elevator pitch
+  - guides/: how-to guides written for users, not developers
+  - faqs/: frequently asked questions
+  Only add content here that you are comfortable sharing publicly.
+  Internal notes, pricing strategy, and architecture docs belong in
+  knowledge/private/ instead.
+---
+
+# Knowledge — Public
+
+Customer-facing documentation for **rflectr** by [Legion Code Inc.](https://github.com/legioncodeinc) Anything in this folder may eventually be published to the help center.
+
+## Documentation map
+
+**Start here:** [What is rflectr?](overview/what-is-rflectr.md)
+
+| Section | Docs |
+|---|---|
+| [Overview](overview/) | [What is rflectr?](overview/what-is-rflectr.md) |
+| [Guides](guides/) | [Providers](guides/providers.md) · [Claude Desktop](guides/claude-desktop.md) · [Codex](guides/codex.md) · [Gemini CLI](guides/gemini-cli.md) · [API Server](guides/api-server.md) · [AI Agents](guides/ai-agents.md) · [Model Compatibility](guides/model-compatibility.md) |
+| [FAQs](faqs/) | [Troubleshooting](faqs/troubleshooting.md) |
+
+## Approved sub-folders
+
+| Folder | Contents |
+|---|---|
+| `overview/` | What this product is, glossary, elevator pitch, high-level FAQs |
+| `guides/` | Step-by-step user guides (written for customers, not developers) |
+| `faqs/` | Frequently asked questions from customers |
+
+## What does NOT belong here
+
+- Internal architecture docs or ADRs
+- Pricing strategy or competitive analysis
+- Engineering standards
+- Anything you would not want a customer to read

package/library/notes/README.md

@@ -1,21 +1,21 @@
----
-ai_description: |
-  HUMAN-ONLY junk drawer. Agents MUST NOT read from, write to, create
-  files in, or reference files in this folder for any purpose.
-  If you want to capture something persistent, write to
-  library/knowledge/private/<domain>/<slug>.md instead.
-  This invariant is absolute and has no exceptions.
-human_description: |
-  Unstructured scratch space for humans. Agents do not touch this folder.
-  Put anything here: rough notes, links, half-formed ideas, meeting notes.
-  Nothing in notes/ is authoritative or maintained.
-  For persistent reference, move content to knowledge/private/ when it matures.
----
-
-# Notes
-
-Human-only scratch space. Agents never read or write here.
-
-Put rough notes, links, and half-formed ideas here. Nothing here is authoritative.
-
-When a note matures into reference material, move it to `knowledge/private/<domain>/`.
+---
+ai_description: |
+  HUMAN-ONLY junk drawer. Agents MUST NOT read from, write to, create
+  files in, or reference files in this folder for any purpose.
+  If you want to capture something persistent, write to
+  library/knowledge/private/<domain>/<slug>.md instead.
+  This invariant is absolute and has no exceptions.
+human_description: |
+  Unstructured scratch space for humans. Agents do not touch this folder.
+  Put anything here: rough notes, links, half-formed ideas, meeting notes.
+  Nothing in notes/ is authoritative or maintained.
+  For persistent reference, move content to knowledge/private/ when it matures.
+---
+
+# Notes
+
+Human-only scratch space. Agents never read or write here.
+
+Put rough notes, links, and half-formed ideas here. Nothing here is authoritative.
+
+When a note matures into reference material, move it to `knowledge/private/<domain>/`.

package/library/requirements/README.md

@@ -1,51 +1,51 @@
----
-ai_description: |
-  This folder contains all planned product and feature work (PRDs).
-  Sub-folders: backlog/ (queued, not started), in-work/ (actively
-  being implemented), completed/ (shipped), reports/ (routine code scans).
-  Lifecycle = location: move entire PRD folders between states.
-  PRD folder naming: prd-<###>-<kebab-slug>/
-  PRD numbers are repo-local sequential. Take max+1 from all prd-* folders
-  across backlog/, in-work/, and completed/.
-  Never write PRD content outside of a prd-<###>-<slug>/ folder.
-  Do NOT put IRDs here — those go in issues/ (peer of requirements/).
-human_description: |
-  Product and feature work (PRDs) organized by lifecycle stage.
-  - backlog/: planned work not yet started
-  - in-work/: currently being implemented
-  - completed/: shipped work (move entire folder here when done)
-  - reports/: routine code-scan and QA reports not tied to a specific PRD
-  To start a new PRD: create prd-<###>-<slug>/ in backlog/ with an index.md.
-  To move lifecycle: move the entire prd-<###>-<slug>/ folder.
----
-
-# Requirements
-
-Product and feature work, organized by lifecycle state.
-
-## Sub-folders
-
-| Folder | State | Description |
-|---|---|---|
-| `backlog/` | Queued | PRDs planned but not yet started |
-| `in-work/` | Active | PRDs currently being implemented |
-| `completed/` | Shipped | Entire PRD folder moves here when work ships |
-| `reports/` | Evergreen | Routine code-scan and QA reports not tied to a PRD |
-
-## PRD folder structure
-
-```
-prd-007-user-export/
-  prd-007-user-export-index.md         module overview + feature list
-  prd-007a-user-export-backend.md      sub-feature a
-  prd-007b-user-export-ui.md           sub-feature b
-  qa/
-    prd-007-user-export-qa.md          QA audit (written by quality-guardian)
-```
-
-## Naming
-
-- Folder: `prd-<###>-<kebab-slug>/` (3-digit zero-padded)
-- Index: `prd-<###>-<kebab-slug>-index.md`
-- Sub-PRDs: `prd-<###><letter>-<kebab-slug>-<feature>.md`
-- PRD numbers are **repo-local sequential** — not GitHub issue numbers.
+---
+ai_description: |
+  This folder contains all planned product and feature work (PRDs).
+  Sub-folders: backlog/ (queued, not started), in-work/ (actively
+  being implemented), completed/ (shipped), reports/ (routine code scans).
+  Lifecycle = location: move entire PRD folders between states.
+  PRD folder naming: prd-<###>-<kebab-slug>/
+  PRD numbers are repo-local sequential. Take max+1 from all prd-* folders
+  across backlog/, in-work/, and completed/.
+  Never write PRD content outside of a prd-<###>-<slug>/ folder.
+  Do NOT put IRDs here — those go in issues/ (peer of requirements/).
+human_description: |
+  Product and feature work (PRDs) organized by lifecycle stage.
+  - backlog/: planned work not yet started
+  - in-work/: currently being implemented
+  - completed/: shipped work (move entire folder here when done)
+  - reports/: routine code-scan and QA reports not tied to a specific PRD
+  To start a new PRD: create prd-<###>-<slug>/ in backlog/ with an index.md.
+  To move lifecycle: move the entire prd-<###>-<slug>/ folder.
+---
+
+# Requirements
+
+Product and feature work, organized by lifecycle state.
+
+## Sub-folders
+
+| Folder | State | Description |
+|---|---|---|
+| `backlog/` | Queued | PRDs planned but not yet started |
+| `in-work/` | Active | PRDs currently being implemented |
+| `completed/` | Shipped | Entire PRD folder moves here when work ships |
+| `reports/` | Evergreen | Routine code-scan and QA reports not tied to a PRD |
+
+## PRD folder structure
+
+```
+prd-007-user-export/
+  prd-007-user-export-index.md         module overview + feature list
+  prd-007a-user-export-backend.md      sub-feature a
+  prd-007b-user-export-ui.md           sub-feature b
+  qa/
+    prd-007-user-export-qa.md          QA audit (written by quality-guardian)
+```
+
+## Naming
+
+- Folder: `prd-<###>-<kebab-slug>/` (3-digit zero-padded)
+- Index: `prd-<###>-<kebab-slug>-index.md`
+- Sub-PRDs: `prd-<###><letter>-<kebab-slug>-<feature>.md`
+- PRD numbers are **repo-local sequential** — not GitHub issue numbers.

package/library/requirements/backlog/README.md

@@ -1,30 +1,30 @@
----
-ai_description: |
-  Contains PRD folders planned but not yet started. This is where
-  library-guardian creates new PRD folders on "write a PRD for X".
-  PRD folder naming: prd-<###>-<kebab-slug>/ (3-digit zero-padded).
-  PRD number: take max+1 from all prd-* folders across backlog/,
-  in-work/, and completed/ in this repo.
-  Each PRD folder must contain: prd-<###>-<slug>-index.md (always),
-  prd-<###><letter>-<slug>-<feature>.md (one per sub-feature, optional),
-  qa/ subfolder (empty on creation; quality-guardian writes QA reports here).
-  Move entire folder to in-work/ when implementation begins.
-human_description: |
-  PRDs planned but not yet started. Create new PRDs here.
-  - Naming: prd-007-feature-name/ with prd-007-feature-name-index.md inside
-  - Sub-features: prd-007a-feature-name-backend.md, prd-007b-feature-name-ui.md
-  - QA folder: qa/prd-007-feature-name-qa.md (created by quality-guardian)
-  Move to in-work/ when implementation begins.
----
-
-# Requirements — Backlog
-
-Planned PRDs not yet in implementation. All new PRD folders are created here.
-
-## Creating a new PRD
-
-1. Find `max_n` across `backlog/prd-*/`, `in-work/prd-*/`, `completed/prd-*/`.
-2. Create `prd-<max_n + 1>-<kebab-slug>/`.
-3. Create `prd-<###>-<slug>-index.md` (module overview + feature list).
-4. Create `qa/` subfolder (empty; `quality-guardian` writes reports here).
-5. Add sub-PRDs `prd-<###>a-<slug>-<feature>.md` etc. as needed.
+---
+ai_description: |
+  Contains PRD folders planned but not yet started. This is where
+  library-guardian creates new PRD folders on "write a PRD for X".
+  PRD folder naming: prd-<###>-<kebab-slug>/ (3-digit zero-padded).
+  PRD number: take max+1 from all prd-* folders across backlog/,
+  in-work/, and completed/ in this repo.
+  Each PRD folder must contain: prd-<###>-<slug>-index.md (always),
+  prd-<###><letter>-<slug>-<feature>.md (one per sub-feature, optional),
+  qa/ subfolder (empty on creation; quality-guardian writes QA reports here).
+  Move entire folder to in-work/ when implementation begins.
+human_description: |
+  PRDs planned but not yet started. Create new PRDs here.
+  - Naming: prd-007-feature-name/ with prd-007-feature-name-index.md inside
+  - Sub-features: prd-007a-feature-name-backend.md, prd-007b-feature-name-ui.md
+  - QA folder: qa/prd-007-feature-name-qa.md (created by quality-guardian)
+  Move to in-work/ when implementation begins.
+---
+
+# Requirements — Backlog
+
+Planned PRDs not yet in implementation. All new PRD folders are created here.
+
+## Creating a new PRD
+
+1. Find `max_n` across `backlog/prd-*/`, `in-work/prd-*/`, `completed/prd-*/`.
+2. Create `prd-<max_n + 1>-<kebab-slug>/`.
+3. Create `prd-<###>-<slug>-index.md` (module overview + feature list).
+4. Create `qa/` subfolder (empty; `quality-guardian` writes reports here).
+5. Add sub-PRDs `prd-<###>a-<slug>-<feature>.md` etc. as needed.