@codedrifters/configulator 0.0.217 → 0.0.218

package/lib/index.js

@@ -236,6 +236,7 @@ __export(index_exports, {
   prReviewBundle: () => prReviewBundle,
   projenBundle: () => projenBundle,
   requirementsAnalystBundle: () => requirementsAnalystBundle,
+  requirementsWriterBundle: () => requirementsWriterBundle,
   researchPipelineBundle: () => researchPipelineBundle,
   resolveModelAlias: () => resolveModelAlias,
   resolveTemplateVariables: () => resolveTemplateVariables,
@@ -6026,8 +6027,8 @@ var requirementsAnalystSubAgent = {
     "Dedicated agent loop for discovering requirement gaps from BCM (Business",
     "Capability Model) documents, product docs, and competitive analysis \u2014 then",
     "creating well-formed requirement issues for the downstream",
-    "requirements-writer (BCM writer) agent to draft. Designed for scheduled",
-    "execution downstream of the BCM writer and company research agents.",
+    "`requirements-writer` agent to draft. Designed for scheduled execution",
+    "downstream of the BCM writer and company research agents.",
     "",
     "Follow your project's shared agent conventions (`AGENTS.md`,",
     "`CLAUDE.md`, or equivalent) for all commit, branch, and PR rules.",
@@ -6038,8 +6039,9 @@ var requirementsAnalystSubAgent = {
     "## Design Principles",
     "",
     "1. **Discover, don't write.** This agent identifies *what requirements are",
-    "   missing*. The requirements-writer skill writes the actual documents. The",
-    "   boundary keeps this agent fast and the requirements-writer authoritative.",
+    "   missing*. The `requirements-writer` agent writes the actual documents.",
+    "   The boundary keeps this agent fast and the `requirements-writer`",
+    "   authoritative.",
     "2. **Trace everything.** Every discovered gap links to the source that",
     "   revealed it (a BCM model doc, competitive analysis, product doc, or",
     "   meeting extract).",
@@ -6297,12 +6299,14 @@ var requirementsAnalystSubAgent = {
     "2. **Create requirement issues.** For each proposal:",
     "",
     "   All `type:requirement` issues default to `priority:medium` (override",
-    "   only if the proposal's priority was explicitly High or Low).",
+    "   only if the proposal's priority was explicitly High or Low). Each",
+    "   issue must also carry the `req:write` phase label so the downstream",
+    "   `requirements-writer` bundle picks it up.",
     "",
     "   ```bash",
     "   gh issue create \\",
     '     --title "docs(<category>): <PREFIX>-<NNN> \u2014 <title>" \\',
-    '     --label "type:requirement" --label "status:ready" --label "priority:medium" \\',
+    '     --label "type:requirement" --label "req:write" --label "status:ready" --label "priority:medium" \\',
     '     --body "## Objective',
     "   Write <PREFIX>-<NNN> \u2014 <title>.",
     "",
@@ -6351,7 +6355,7 @@ var requirementsAnalystSubAgent = {
     "| Upstream | BCM Writer | Scans capability-model docs for project-relevance gaps (judged against `docs/project-context.md`) |",
     "| Upstream | Company Research | Scans competitive analysis for feature comparison gaps |",
     "| Upstream | Meeting Analyst | Scans meeting extracts for requirement proposals |",
-    "| Downstream | Requirements Writer (BCM Writer) | Creates `type:requirement` issues for the skill to draft |",
+    "| Downstream | `requirements-writer` | Picks up the `type:requirement` + `req:write` issues this agent creates and drafts the actual requirement document |",
     "",
     "**File boundaries:** Writes to `<RESEARCH_REQUIREMENTS_ROOT>/req-*.md` and",
     "minor traceability edits to `<BCM_DOCS_ROOT>` and `<COMPETITIVE_ROOT>`.",
@@ -6372,7 +6376,8 @@ var requirementsAnalystSubAgent = {
     "## Rules",
     "",
     "- **Discover, don't write requirements.** Create issues for the",
-    "  requirements-writer \u2014 don't write requirement documents directly.",
+    "  `requirements-writer` agent \u2014 don't write requirement documents",
+    "  directly.",
     "- **Deduplicate rigorously.** Check both existing docs and open issues",
     "  before flagging a gap.",
     "- **Respect decision authority.** Mark ADR/TR proposals as needing human",
@@ -6444,10 +6449,12 @@ var requirementsAnalystBundle = {
         "or `req:trace`. All issues carry `type:requirement`.",
         "",
         "The requirements-analyst *discovers gaps and drafts proposals*; it",
-        "does **not** write final requirement documents. Writing is the job of",
-        "the downstream requirements-writer (BCM writer) agent. Keep that",
-        "boundary clean: proposals land under the research requirements",
-        "directory, not under the authoritative requirements tree.",
+        "does **not** write final requirement documents. Writing is the job",
+        "of the downstream `requirements-writer` agent (a separate bundle).",
+        "Keep that boundary clean: proposals land under the research",
+        "requirements directory, not under the authoritative requirements",
+        "tree. The trace phase tags new issues with `req:write` so the",
+        "writer bundle picks them up automatically.",
         "",
         "See the `requirements-analyst` agent definition for full workflow",
         "details and phase-by-phase instructions."
@@ -6484,6 +6491,2633 @@ var requirementsAnalystBundle = {
   ]
 };
 
+// src/agent/bundles/requirements-writer.ts
+var TEMPLATE_BR = `---
+title: "BR-NNN: [Business Requirement Title]"
+---
+
+# BR-NNN: [Business Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | BR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Priority** | [Critical / High / Medium / Low] |
+| **Owner** | [Name or role responsible for this requirement] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Business Need
+
+A clear statement of the business problem or opportunity this requirement addresses. Focus on the "why" \u2014 what pain point exists, what opportunity we're capturing, or what strategic goal this supports.
+
+## Stakeholders
+
+| Stakeholder | Role | Interest |
+|---|---|---|
+| [Name/Group] | [Their role] | [What they care about regarding this requirement] |
+
+## Success Metrics
+
+Define how we'll know this requirement has been successfully met. Metrics should be specific and measurable.
+
+| Metric | Target | Measurement Method |
+|---|---|---|
+| [e.g., Onboarding completion rate] | [e.g., > 80% within 7 days] | [e.g., Analytics funnel tracking] |
+
+## Scope
+
+### In Scope
+
+What is explicitly included in this business requirement.
+
+### Out of Scope
+
+What is explicitly excluded \u2014 important for preventing scope creep and setting expectations.
+
+## Assumptions
+
+List assumptions that underpin this requirement. Flag any that carry risk if they turn out to be wrong.
+
+- [Assumption 1]
+- [Assumption 2]
+
+## Constraints
+
+Business-level constraints that bound this requirement (budget, timeline, regulatory, organizational).
+
+- [Constraint 1]
+- [Constraint 2]
+
+## Dependencies
+
+Other business requirements, external factors, or organizational decisions this requirement depends on.
+
+- [Dependency 1]
+- [Dependency 2]
+
+## Traceability
+
+- **Decomposes into:** [FR-NNN](../functional/FR-NNN-slug.md), [FR-NNN](../functional/FR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Related:** [SEC-NNN](../security/SEC-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_FR = `---
+title: "FR-NNN: [Functional Requirement Title]"
+---
+
+# FR-NNN: [Functional Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | FR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Priority** | [Must Have / Should Have / Could Have / Won't Have] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## User Story
+
+**As a** [actor/role],
+**I want to** [action/capability],
+**So that** [business value/outcome].
+
+## Description
+
+A narrative description of this feature or behavior. Include enough context that someone unfamiliar with the project can understand what the system does and why it matters.
+
+## Actors
+
+| Actor | Description |
+|---|---|
+| [e.g., Registered User] | [Who they are and what access level they have] |
+
+## Preconditions
+
+Conditions that must be true before this functionality can be used.
+
+- [Precondition 1]
+- [Precondition 2]
+
+## Main Flow
+
+The primary happy-path sequence of interactions.
+
+1. [Step 1]
+2. [Step 2]
+3. [Step 3]
+
+## Alternative Flows
+
+### AF-1: [Alternative Flow Name]
+
+**Trigger:** [What causes this alternative path]
+
+1. [Step 1]
+2. [Step 2]
+
+### AF-2: [Alternative Flow Name]
+
+**Trigger:** [What causes this alternative path]
+
+1. [Step 1]
+2. [Step 2]
+
+## Exception Flows
+
+### EF-1: [Exception Flow Name]
+
+**Trigger:** [What error condition causes this]
+
+1. [Step 1 \u2014 how the system responds]
+2. [Step 2]
+
+## Acceptance Criteria
+
+Specific, testable conditions that must be met for this requirement to be considered complete.
+
+- [ ] [Criterion 1 \u2014 stated as a concrete, verifiable condition]
+- [ ] [Criterion 2]
+- [ ] [Criterion 3]
+
+## Business Rules
+
+Rules that govern the behavior described in this requirement.
+
+| Rule ID | Description |
+|---|---|
+| BIZ-01 | [e.g., Email addresses must be unique across the system] |
+| BIZ-02 | [e.g., Passwords must be at least 12 characters] |
+
+## UI/UX Considerations
+
+Notes on how this feature should present to the user. Reference UX requirements where applicable.
+
+## Data Requirements
+
+What data is created, read, updated, or deleted by this feature. Reference DR documents where applicable.
+
+## Traceability
+
+- **Implements:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Related:** [INT-NNN](../integration/INT-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_NFR = `---
+title: "NFR-NNN: [Non-Functional Requirement Title]"
+---
+
+# NFR-NNN: [Non-Functional Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | NFR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Quality Attribute** | [Performance / Reliability / Scalability / Maintainability / Portability / Availability] |
+| **Priority** | [Critical / High / Medium / Low] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What quality attribute this requirement addresses and why it matters for the system.
+
+## Measurable Targets
+
+Non-functional requirements must have numeric, measurable targets \u2014 vague statements like "the system should be fast" are not acceptable.
+
+| Metric | Target | Measurement Method | Measurement Frequency |
+|---|---|---|---|
+| [e.g., API response time (p99)] | [e.g., < 200ms] | [e.g., Datadog APM percentile tracking] | [e.g., Continuous] |
+| [e.g., System availability] | [e.g., 99.9% monthly] | [e.g., Uptime monitoring (Pingdom/UptimeRobot)] | [e.g., Monthly] |
+
+## Current Baseline
+
+If this is being applied to an existing system, document the current measured values so improvement can be tracked.
+
+| Metric | Current Value | Date Measured |
+|---|---|---|
+| [Metric] | [Current value or "Not yet measured"] | [Date] |
+
+## Rationale
+
+Why this target was chosen. What business need or user expectation drives this number? What are the consequences of not meeting it?
+
+## Applicable Scope
+
+Which parts of the system does this requirement apply to? Be specific \u2014 "all API endpoints" or "the checkout flow" rather than "the system."
+
+## Approach
+
+High-level approach for meeting this target. Reference ADRs and TRs for implementation details.
+
+## Monitoring & Alerting
+
+How compliance with this requirement will be monitored in production. Reference OPS requirements where applicable.
+
+| Alert Condition | Threshold | Action |
+|---|---|---|
+| [e.g., p99 latency exceeds target] | [e.g., > 200ms for 5 minutes] | [e.g., Page on-call engineer] |
+
+## Traceability
+
+- **Supports:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Constrains:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Monitored by:** [OPS-NNN](../operational/OPS-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_TR = `---
+title: "TR-NNN: [Technical Requirement Title]"
+---
+
+# TR-NNN: [Technical Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | TR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Category** | [Language / Framework / Database / Infrastructure / Library / Tool] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Technology Choice
+
+When **Accepted**: Fill in the selected technology.
+
+When **Proposed**: Write "Pending human review. See Recommendation below." and leave Version/License/Vendor as TBD.
+
+| Field | Value |
+|---|---|
+| **Technology** | [e.g., PostgreSQL] |
+| **Version** | [e.g., 16+ (observed: 16-alpine at time of documentation). Version will naturally drift upward through routine maintenance.] |
+| **License** | [e.g., PostgreSQL License (permissive, OSI-approved)] |
+| **Vendor/Maintainer** | [e.g., PostgreSQL Global Development Group] |
+
+## Alternatives Considered
+
+List every viable technology option, including the recommended one. Each alternative gets the same level of analysis.
+
+### Option 1: [Technology Name]
+
+**Description:** [What this technology is and how it would be used]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+**License:** [License type]
+**Maturity:** [Established / Growing / Emerging]
+
+### Option 2: [Technology Name]
+
+**Description:** [What this technology is and how it would be used]
+
+**Pros:**
+- [Pro 1]
+
+**Cons:**
+- [Con 1]
+
+**License:** [License type]
+**Maturity:** [Established / Growing / Emerging]
+
+## Recommendation
+
+**Recommended option:** [Name of the recommended technology]
+
+**Why this option:** [A well-reasoned explanation of why this technology best fits the context, constraints, and goals. Address the key trade-offs honestly \u2014 explain why the cons are acceptable and why other options were not preferred.]
+
+**Key trade-offs accepted:** [What you're giving up by choosing this option over others]
+
+When the status is \`Proposed\`, this section frames the decision for the human reviewer. When \`Accepted\`, this section documents the reasoning behind the choice.
+
+## Rationale
+
+When **Accepted**: Summarize why this technology was selected. Reference the ADR that records the decision process if one exists.
+
+When **Proposed**: Write "See Recommendation above. Awaiting human decision."
+
+## Usage Context
+
+How and where this technology is used in the system. Be specific about which components or layers depend on it.
+
+## Version Constraints
+
+Any version pinning, upgrade policies, or compatibility requirements. Assume versions will drift upward over time through routine maintenance unless there is a specific reason to pin.
+
+- **Minimum version:** [version \u2014 the floor below which compatibility is not guaranteed]
+- **Observed version:** [version at time of documentation]
+- **Maximum version:** [version or "latest stable" \u2014 only specify if there's a known ceiling]
+- **Upgrade policy:** [e.g., "Track latest minor releases within 30 days; major version upgrades require ADR"]
+- **Version-sensitive notes:** [Any specific features or APIs used that depend on this version floor \u2014 helps future developers understand what might break if they don't meet the minimum]
+
+## Configuration Standards
+
+Key configuration decisions, defaults, or standards that apply to this technology across the project.
+
+## Dependencies & Compatibility
+
+Other technologies this choice interacts with, and any known compatibility constraints.
+
+| Dependency | Relationship | Constraint |
+|---|---|---|
+| [e.g., Node.js runtime] | [Required by] | [e.g., v18 LTS or later] |
+
+## Risks & Mitigations
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| [e.g., Vendor discontinues support] | [Low/Medium/High] | [Low/Medium/High] | [e.g., Open-source, community-maintained] |
+
+## Traceability
+
+- **Justified by:** [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md)
+- **Supports:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_ADR = `---
+title: "ADR-NNN: [Decision Title]"
+---
+
+# ADR-NNN: [Decision Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | ADR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Decision Date** | YYYY-MM-DD |
+| **Decision Makers** | [Names or roles involved in the decision] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Context
+
+What is the issue that we're seeing that motivates this decision or change? What forces are at play \u2014 technical constraints, business pressures, team capabilities, timeline?
+
+## Decision
+
+When **Accepted**: State the architectural decision clearly and concisely. Start with "We will..." or "We have decided to..."
+
+When **Proposed**: Write "Pending human review. See Recommendation below." Do not make the decision \u2014 present the analysis so a human can decide.
+
+## Alternatives Considered
+
+List every viable option, including the recommended one. Each alternative gets the same level of analysis \u2014 do not shortchange options you don't prefer.
+
+### Alternative 1: [Name]
+
+**Description:** [What this alternative entails \u2014 enough detail to evaluate it]
+
+**Pros:**
+- [Pro 1]
+- [Pro 2]
+
+**Cons:**
+- [Con 1]
+- [Con 2]
+
+### Alternative 2: [Name]
+
+**Description:** [What this alternative entails]
+
+**Pros:**
+- [Pro 1]
+
+**Cons:**
+- [Con 1]
+
+## Recommendation
+
+**Recommended option:** [Name of the recommended alternative]
+
+**Why this option:** [A well-reasoned explanation of why this alternative best fits the context, constraints, and goals. Address the key trade-offs honestly \u2014 explain why the cons of the recommended option are acceptable and why the pros of rejected alternatives don't outweigh their cons in this context.]
+
+**Key trade-offs accepted:** [What you're giving up by choosing this option over others]
+
+When the status is \`Proposed\`, this section frames the decision for the human reviewer. When \`Accepted\`, this section documents the reasoning behind the choice.
+
+## Consequences
+
+### Positive
+
+- [Positive consequence 1]
+- [Positive consequence 2]
+
+### Negative
+
+- [Negative consequence 1 \u2014 every decision has trade-offs; document them honestly]
+- [Negative consequence 2]
+
+### Neutral
+
+- [Neutral observation about what changes as a result of this decision]
+
+## Compliance & Constraints
+
+Any regulatory, security, or organizational constraints that influenced this decision.
+
+## Implementation Notes
+
+High-level guidance for implementing this decision. Detailed implementation goes in TR and FR documents.
+
+## Traceability
+
+- **Supports:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Implemented by:** [TR-NNN](../technical/TR-NNN-slug.md)
+- **Related:** [ADR-NNN](ADR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_SEC = `---
+title: "SEC-NNN: [Security Requirement Title]"
+---
+
+# SEC-NNN: [Security Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | SEC-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Security Domain** | [Authentication / Authorization / Data Protection / Audit / Compliance / Network / Input Validation] |
+| **Priority** | [Critical / High / Medium / Low] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What security concern this requirement addresses and why it matters.
+
+## Threat Model Reference
+
+What threats does this requirement mitigate? Reference any formal threat modeling artifacts if they exist.
+
+| Threat | STRIDE Category | Severity | This Requirement Mitigates |
+|---|---|---|---|
+| [e.g., Unauthorized access to tenant data] | [e.g., Elevation of Privilege] | [Critical/High/Medium/Low] | [How] |
+
+## Requirements
+
+### Controls
+
+Specific security controls that must be implemented.
+
+| Control ID | Description | OWASP ASVS Ref | NIST 800-53 Ref |
+|---|---|---|---|
+| [e.g., SEC-001-C1] | [e.g., All passwords hashed with bcrypt, cost factor \u2265 12] | [e.g., V2.4.1] | [e.g., IA-5(1)] |
+
+### Policies
+
+Organizational or procedural security policies this requirement enforces.
+
+- [Policy 1]
+- [Policy 2]
+
+## Applicable Regulations
+
+| Regulation | Requirement | How We Comply |
+|---|---|---|
+| [e.g., SOC 2 Type II] | [e.g., Access controls and audit logging] | [e.g., RBAC + immutable audit log] |
+| [e.g., GDPR] | [e.g., Data encryption at rest] | [e.g., AES-256 via AWS KMS] |
+
+## Validation Approach
+
+How compliance with this security requirement will be verified.
+
+| Method | Frequency | Responsible Party |
+|---|---|---|
+| [e.g., Automated security scan] | [e.g., Every CI build] | [e.g., DevOps] |
+| [e.g., Penetration test] | [e.g., Annually] | [e.g., External vendor] |
+
+## Acceptance Criteria
+
+- [ ] [Specific, verifiable security condition]
+- [ ] [e.g., No passwords stored in plaintext anywhere in the system]
+- [ ] [e.g., All API endpoints require authentication except explicitly whitelisted public routes]
+
+## Traceability
+
+- **Protects:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Implements:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Related data:** [DR-NNN](../data/DR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_DR = `---
+title: "DR-NNN: [Data Requirement Title]"
+---
+
+# DR-NNN: [Data Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | DR-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Data Domain** | [e.g., User Data / Transaction Data / Configuration / Audit Logs / Media Assets] |
+| **Classification** | [Public / Internal / Confidential / Restricted] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What data this requirement governs, why it exists, and its significance to the system.
+
+## Data Model
+
+Describe the key entities, their attributes, and relationships. Include an entity-relationship summary or reference a diagram.
+
+| Entity | Key Attributes | Relationships |
+|---|---|---|
+| [e.g., User] | [e.g., id, email, name, created_at] | [e.g., Has many Organizations (via membership)] |
+
+## Data Lifecycle
+
+| Phase | Description | Duration |
+|---|---|---|
+| Creation | [How and when this data is created] | \u2014 |
+| Active Use | [How this data is used during normal operations] | [e.g., Indefinite while account active] |
+| Archival | [If/how data is archived after active use] | [e.g., After 12 months of inactivity] |
+| Deletion | [When and how data is permanently removed] | [e.g., 90 days after account closure] |
+
+## Retention Policy
+
+| Data Type | Retention Period | Legal Basis | Deletion Method |
+|---|---|---|---|
+| [e.g., User profile data] | [e.g., Account lifetime + 90 days] | [e.g., Contractual obligation] | [e.g., Soft delete \u2192 hard delete after retention] |
+| [e.g., Audit logs] | [e.g., 7 years] | [e.g., SOC 2 compliance] | [e.g., Automated purge] |
+
+## Backup & Recovery
+
+| Parameter | Value |
+|---|---|
+| **RPO (Recovery Point Objective)** | [e.g., < 1 hour \u2014 maximum acceptable data loss] |
+| **RTO (Recovery Time Objective)** | [e.g., < 4 hours \u2014 maximum acceptable downtime] |
+| **Backup Frequency** | [e.g., Continuous WAL archiving + daily snapshots] |
+| **Backup Location** | [e.g., Cross-region S3 with encryption] |
+| **Recovery Testing** | [e.g., Quarterly restore test] |
+
+## Data Quality Rules
+
+| Rule | Description | Enforcement |
+|---|---|---|
+| [e.g., Email uniqueness] | [e.g., No two active users may share an email] | [e.g., Database unique constraint] |
+
+## Privacy & Classification
+
+How this data is classified and what handling rules apply based on that classification.
+
+| Classification Level | Handling Rules |
+|---|---|
+| Public | No restrictions |
+| Internal | Access controlled, not shared externally |
+| Confidential | Encrypted at rest, access logged, need-to-know basis |
+| Restricted | All of Confidential + additional controls per regulation |
+
+## Traceability
+
+- **Supports:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Protected by:** [SEC-NNN](../security/SEC-NNN-slug.md)
+- **Stored per:** [TR-NNN](../technical/TR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_INT = `---
+title: "INT-NNN: [Integration Requirement Title]"
+---
+
+# INT-NNN: [Integration Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | INT-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Integration Type** | [REST API / GraphQL / Webhook / Message Queue / File Transfer / SDK] |
+| **Direction** | [Inbound / Outbound / Bidirectional] |
+| **External System** | [Name of the third-party or internal system] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What this integration does, why it's needed, and what business capability it enables.
+
+## External System Overview
+
+| Field | Value |
+|---|---|
+| **System** | [e.g., Stripe] |
+| **Purpose** | [e.g., Payment processing and subscription management] |
+| **API Documentation** | [URL to official docs] |
+| **API Version** | [e.g., 2023-10-16] |
+| **Authentication** | [e.g., API key (secret key in header)] |
+
+## Integration Points
+
+### [Endpoint/Event 1]: [Name]
+
+| Field | Value |
+|---|---|
+| **Direction** | [Inbound/Outbound] |
+| **Protocol** | [e.g., HTTPS REST] |
+| **Endpoint** | [e.g., POST /v1/customers] |
+| **Authentication** | [e.g., Bearer token] |
+| **Rate Limit** | [e.g., 100 requests/second] |
+
+**Request/Payload:**
+\`\`\`
+[Brief description or schema reference]
+\`\`\`
+
+**Response/Output:**
+\`\`\`
+[Brief description or schema reference]
+\`\`\`
+
+## Error Handling
+
+| Error Scenario | Strategy | Retry Policy |
+|---|---|---|
+| [e.g., 429 Rate Limited] | [e.g., Exponential backoff] | [e.g., 3 retries, max 30s] |
+| [e.g., 500 Server Error] | [e.g., Retry with circuit breaker] | [e.g., 3 retries, then circuit open for 60s] |
+| [e.g., Timeout] | [e.g., Retry once, then dead letter queue] | [e.g., 30s timeout, 1 retry] |
+
+## Data Mapping
+
+How data maps between our system and the external system.
+
+| Our Field | External Field | Transformation |
+|---|---|---|
+| [e.g., user.email] | [e.g., customer.email] | [e.g., Direct mapping] |
+
+## SLA & Availability
+
+| Parameter | Our Expectation | External System's Published SLA |
+|---|---|---|
+| Availability | [e.g., 99.9%] | [e.g., 99.99%] |
+| Response Time | [e.g., < 500ms p99] | [e.g., < 200ms typical] |
+
+## Fallback Behavior
+
+What happens when this integration is unavailable. How does the system degrade gracefully?
+
+## Testing Strategy
+
+| Environment | Approach |
+|---|---|
+| Development | [e.g., Mock server / sandbox environment] |
+| Staging | [e.g., Sandbox API with test credentials] |
+| Production | [e.g., Live API with monitoring] |
+
+## Traceability
+
+- **Enables:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Secured by:** [SEC-NNN](../security/SEC-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_OPS = `---
+title: "OPS-NNN: [Operational Requirement Title]"
+---
+
+# OPS-NNN: [Operational Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | OPS-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **Operations Domain** | [Deployment / Monitoring / Alerting / Logging / Incident Response / Backup] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What operational concern this requirement addresses and why it matters for system reliability.
+
+## Current State
+
+If this applies to an existing system, document the current operational posture.
+
+## Requirements
+
+### Deployment
+
+| Parameter | Requirement |
+|---|---|
+| **Strategy** | [e.g., Blue-green / Rolling / Canary] |
+| **Frequency** | [e.g., On-demand, multiple times per day] |
+| **Rollback** | [e.g., Automated rollback on health check failure within 5 minutes] |
+| **Downtime** | [e.g., Zero-downtime required] |
+
+### Monitoring & Observability
+
+| Signal Type | What to Monitor | Tool | Retention |
+|---|---|---|---|
+| **Metrics** | [e.g., Request rate, error rate, latency p50/p95/p99] | [e.g., Datadog] | [e.g., 15 months] |
+| **Logs** | [e.g., Application logs, access logs, audit logs] | [e.g., CloudWatch \u2192 S3] | [e.g., 90 days hot, 1 year cold] |
+| **Traces** | [e.g., Distributed request traces] | [e.g., Datadog APM] | [e.g., 30 days] |
+
+### Alerting
+
+| Alert | Condition | Severity | Notification Channel | Escalation |
+|---|---|---|---|---|
+| [e.g., High error rate] | [e.g., 5xx rate > 1% for 5 min] | [e.g., P1 / Critical] | [e.g., PagerDuty \u2192 on-call] | [e.g., If unack'd in 15 min \u2192 engineering lead] |
+
+### Incident Response
+
+| Severity | Response Time | Resolution Target | Communication |
+|---|---|---|---|
+| P1 (Critical) | [e.g., 15 minutes] | [e.g., 1 hour] | [e.g., Status page + stakeholder notification] |
+| P2 (Major) | [e.g., 30 minutes] | [e.g., 4 hours] | [e.g., Status page if customer-facing] |
+| P3 (Minor) | [e.g., Next business day] | [e.g., 5 business days] | [e.g., Internal tracking only] |
+
+## Runbook References
+
+| Scenario | Runbook Location |
+|---|---|
+| [e.g., Database failover] | [Link or path] |
+| [e.g., High memory usage] | [Link or path] |
+
+## Environments
+
+| Environment | Purpose | Infrastructure | Access |
+|---|---|---|---|
+| Development | [Local development] | [e.g., Docker Compose] | [e.g., All developers] |
+| Staging | [Pre-production testing] | [e.g., AWS, scaled down] | [e.g., Engineering team] |
+| Production | [Live system] | [e.g., AWS, full scale] | [e.g., Restricted, via bastion] |
+
+## Traceability
+
+- **Monitors:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Supports:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Uses:** [TR-NNN](../technical/TR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_UX = `---
+title: "UX-NNN: [UX Requirement Title]"
+---
+
+# UX-NNN: [UX Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | UX-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **UX Domain** | [Accessibility / Responsiveness / Internationalization / Interaction Design / Information Architecture] |
+| **Priority** | [Critical / High / Medium / Low] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What user experience concern this requirement addresses and why it matters.
+
+## Target Users
+
+| User Segment | Characteristics | Key Needs |
+|---|---|---|
+| [e.g., Power users] | [e.g., Daily usage, keyboard-heavy workflow] | [e.g., Keyboard shortcuts, bulk actions] |
+
+## Accessibility
+
+| Parameter | Requirement |
+|---|---|
+| **WCAG Level** | [e.g., 2.1 Level AA] |
+| **Screen Reader Support** | [e.g., ARIA labels on all interactive elements] |
+| **Keyboard Navigation** | [e.g., All functionality accessible via keyboard] |
+| **Color Contrast** | [e.g., Minimum 4.5:1 for normal text, 3:1 for large text] |
+| **Motion** | [e.g., Respect prefers-reduced-motion; no auto-playing animations] |
+
+## Responsive Design
+
+| Breakpoint | Target Devices | Layout Behavior |
+|---|---|---|
+| [e.g., < 375px] | [e.g., Small phones] | [e.g., Single column, stacked navigation] |
+| [e.g., 375\u2013768px] | [e.g., Phones, small tablets] | [e.g., Single column, hamburger menu] |
+| [e.g., 768\u20131024px] | [e.g., Tablets] | [e.g., Two-column where appropriate] |
+| [e.g., > 1024px] | [e.g., Desktop] | [e.g., Full layout with sidebar navigation] |
+
+## Internationalization (i18n)
+
+| Parameter | Requirement |
+|---|---|
+| **Supported Languages** | [e.g., English (launch), Spanish, French (Phase 2)] |
+| **Text Direction** | [e.g., LTR only at launch; RTL support in backlog] |
+| **Date/Time Formats** | [e.g., Locale-aware formatting] |
+| **Currency** | [e.g., Display in user's locale, store in USD] |
+
+## Interaction Patterns
+
+Key interaction patterns and principles that apply to this requirement.
+
+| Pattern | Standard | Notes |
+|---|---|---|
+| [e.g., Form validation] | [e.g., Inline validation on blur, summary on submit] | [e.g., Error messages adjacent to field] |
+| [e.g., Loading states] | [e.g., Skeleton screens for content, spinners for actions] | [e.g., No blank screens during loads] |
+
+## Design System Reference
+
+Reference to the project's design system, component library, or style guide if one exists.
+
+## Acceptance Criteria
+
+- [ ] [Specific, verifiable UX condition]
+- [ ] [e.g., All pages score \u2265 90 on Lighthouse accessibility audit]
+- [ ] [e.g., All interactive elements have visible focus indicators]
+
+## Traceability
+
+- **Enhances:** [FR-NNN](../functional/FR-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Supports:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_MT = `---
+title: "MT-NNN: [Multi-Tenancy Requirement Title]"
+---
+
+# MT-NNN: [Multi-Tenancy Requirement Title]
+
+## Metadata
+
+| Field | Value |
+|---|---|
+| **ID** | MT-NNN |
+| **Status** | Draft |
+| **Tier** | [Platform \xB7 Industry \xB7 Customer Workflow \xB7 Consumer Application] |
+| **Implementor** | [Consortium Member \xB7 Customer \xB7 TBD \u2014 required for Customer Workflow and Consumer Application tiers. When Consortium Member, link to org profile] |
+| **Customer** | [Link to customer org profile if this requirement originated from or applies to a specific customer. Optional for Platform/Industry tiers, expected for Customer Workflow/Consumer Application tiers] |
+| **MT Domain** | [Tenant Isolation / Feature Gating / Usage Metering / Billing / Provisioning / Licensing] |
+| **Priority** | [Critical / High / Medium / Low] |
+| **Owner** | [Name or role] |
+| **Created** | YYYY-MM-DD |
+| **Last Updated** | YYYY-MM-DD |
+
+## Description
+
+What multi-tenancy concern this requirement addresses and why it matters for the SaaS product.
+
+## Tenant Isolation Model
+
+| Layer | Isolation Strategy | Details |
+|---|---|---|
+| **Database** | [e.g., Row-level / Schema-per-tenant / Database-per-tenant] | [e.g., tenant_id column on all tenant-scoped tables, enforced by RLS] |
+| **Application** | [e.g., Shared application, tenant context from auth token] | [e.g., Middleware extracts tenant from JWT, injects into query context] |
+| **Infrastructure** | [e.g., Shared infrastructure / Dedicated compute per tenant] | [e.g., Shared at launch, dedicated option for enterprise tier] |
+| **Storage** | [e.g., Shared bucket with tenant prefix / Separate buckets] | [e.g., S3 bucket with tenant-id/ prefix, IAM policies per tenant] |
+
+## Feature Gating
+
+| Feature | Free Tier | Pro Tier | Enterprise Tier |
+|---|---|---|---|
+| [e.g., Number of users] | [e.g., Up to 5] | [e.g., Up to 50] | [e.g., Unlimited] |
+| [e.g., API access] | [e.g., No] | [e.g., Yes, 1000 calls/day] | [e.g., Yes, unlimited] |
+
+### Gating Mechanism
+
+How feature gates are implemented and managed (e.g., feature flag service, plan-based checks, entitlement system).
+
+## Usage Metering
+
+| Dimension | Unit | Collection Method | Billing Cycle |
+|---|---|---|---|
+| [e.g., API calls] | [e.g., Per request] | [e.g., API gateway counter] | [e.g., Monthly] |
+| [e.g., Storage] | [e.g., GB-month] | [e.g., Nightly calculation] | [e.g., Monthly] |
+
+## Tenant Provisioning
+
+| Step | Action | Duration | Automated? |
+|---|---|---|---|
+| 1 | [e.g., Create tenant record] | [e.g., < 1s] | [e.g., Yes] |
+| 2 | [e.g., Provision database schema/rows] | [e.g., < 5s] | [e.g., Yes] |
+| 3 | [e.g., Configure DNS/subdomain] | [e.g., < 1 min] | [e.g., Yes] |
+
+## Tenant Offboarding
+
+What happens when a tenant leaves \u2014 data retention, export, cleanup procedures.
+
+## Noisy Neighbor Prevention
+
+How the system prevents one tenant from degrading the experience of others.
+
+| Strategy | Implementation |
+|---|---|
+| [e.g., Rate limiting] | [e.g., Per-tenant rate limits at API gateway] |
+| [e.g., Resource quotas] | [e.g., Max storage per tenant per tier] |
+
+## Acceptance Criteria
+
+- [ ] [e.g., Tenant A cannot access Tenant B's data under any circumstances]
+- [ ] [e.g., Feature gate changes take effect within 60 seconds]
+- [ ] [e.g., New tenant provisioning completes in under 30 seconds]
+
+## Traceability
+
+- **Implements:** [BR-NNN](../business/BR-NNN-slug.md)
+- **Secured by:** [SEC-NNN](../security/SEC-NNN-slug.md)
+- **Constrained by:** [NFR-NNN](../non-functional/NFR-NNN-slug.md)
+- **Depends on (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [platform/industry requirement this depends on]
+- **Enables (cross-tier):** [XX-NNN](../category/XX-NNN-slug.md) \u2014 [customer-workflow/consumer-app requirement this enables]
+
+## Open Items
+
+### Identified Gaps
+
+[Document any missing functionality, unhandled edge cases, or incomplete aspects. Number each item and assign a priority (P0/P1/P2/P3). Call out interdependencies with other open items. If none, write "None identified."]
+
+1. **[Gap title]** \`[P0-P3]\`
+   [Description of what's missing and why it matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Follow-up Questions
+
+[Document anything ambiguous or where the motivation/reasoning cannot be confidently inferred. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Question title]** \`[P0-P3]\`
+   [The question, with context on why the answer matters.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+### Contradictions & Inconsistencies
+
+[Document any conflicts with other requirements, code behavior, or documentation. Number each item and assign a priority. If none, write "None identified."]
+
+1. **[Contradiction title]** \`[P0-P3]\`
+   [Description of the conflict and what needs to be resolved.]
+   \u2192 [Depends on / Blocks]: [XX-NNN Open Item #N](../category/XX-NNN-slug.md#open-items) (if applicable)
+
+## Revision History
+
+| Date | Author | Change |
+|---|---|---|
+| YYYY-MM-DD | [Name] | Initial draft |
+`;
+var TEMPLATE_CATEGORY_README = `# [Category Name] Requirements
+
+## Purpose
+
+[One-paragraph description of what belongs in this category and the question it answers.]
+
+## What Belongs Here
+
+- [Type of requirement 1]
+- [Type of requirement 2]
+- [Type of requirement 3]
+
+## What Does NOT Belong Here
+
+| If your requirement looks like... | It probably belongs in... | Why |
+|---|---|---|
+| [e.g., "The system must respond in < 200ms"] | [e.g., NFR (Non-Functional)] | [e.g., That's a quality/performance target, not a feature description] |
+
+## Template
+
+Use [\`_template-{PREFIX}.md\`](../templates/_template-{PREFIX}.md) for all new documents in this category.
+
+## Current Documents
+
+| ID | Title | Status | Last Updated |
+|---|---|---|---|
+| [{PREFIX}-001](/{PREFIX}-001-slug.md) | [Title] | [Status] | [Date] |
+
+## Conventions
+
+- File naming: \`{PREFIX}-NNN-descriptive-slug.md\`
+- Number sequentially \u2014 check the table above for the next available number
+- Every document must include YAML frontmatter with a \`title\` field
+- Every document must include a \`## Traceability\` section
+`;
+var TEMPLATE_REQUIREMENTS_README = `---
+title: "[Project Name] \u2014 Requirements Documentation"
+---
+
+# [Project Name] \u2014 Requirements Documentation
+
+This directory contains the structured requirements taxonomy for [Project Name]. It covers the full lifecycle from business intent through operational concerns, providing traceability between strategic goals and implementation work.
+
+## Taxonomy Overview
+
+| Category | Prefix | Directory | Purpose |
+|---|---|---|---|
+| Business Requirements | BR | [\`business/\`](business/README.md) | Strategic intent, stakeholders, success metrics |
+| Functional Requirements | FR | [\`functional/\`](functional/README.md) | User stories, flows, acceptance criteria |
+| Non-Functional Requirements | NFR | [\`non-functional/\`](non-functional/README.md) | Performance, scalability, availability targets |
+| Technical Requirements | TR | [\`technical/\`](technical/README.md) | Technology choices, framework decisions |
+| Architectural Decisions | ADR | [\`architectural-decisions/\`](architectural-decisions/README.md) | Context, decision, consequences (standard ADR format) |
+| Security & Compliance | SEC | [\`security/\`](security/README.md) | Auth, encryption, audit, regulatory |
+| Data Requirements | DR | [\`data/\`](data/README.md) | Data models, retention, classification, RPO/RTO |
+| Integration Requirements | INT | [\`integration/\`](integration/README.md) | APIs, third-party systems, protocols |
+| Operational Requirements | OPS | [\`operational/\`](operational/README.md) | Deployment, monitoring, alerting, logging |
+| UX Requirements | UX | [\`ux/\`](ux/README.md) | Accessibility, responsiveness, i18n |
+| Multi-Tenancy & Licensing | MT | [\`multi-tenancy/\`](multi-tenancy/README.md) | Tenant isolation, feature gating, billing |
+
+Each directory contains a \`README.md\` with detailed guidance on what belongs in that category (and what doesn't), common disambiguation tips, and project-specific context. When unsure where a requirement belongs, start with the category README.
+
+## Which Category Do I Use?
+
+When capturing or decomposing a requirement, use the question it answers to determine the correct category:
+
+| Question | Category | Example |
+|---|---|---|
+| **Why** do we need this? What business value does it deliver? | BR | "We need self-service registration to reduce sales-assisted onboarding costs" |
+| **What** does the system do? What is the user-visible behavior? | FR | "A user can register with email and password and receive a verification link" |
+| **How well** must the system perform? What quality bar must it meet? | NFR | "Registration API must respond within 200ms at p99" |
+| **What technology** are we choosing, and why that one? | TR | "PostgreSQL 16+ for the primary datastore" |
+| **What structural decision** are we making, and what are the trade-offs? | ADR | "Use row-level tenant isolation rather than schema-per-tenant" |
+| **What must we protect**, and what rules govern that protection? | SEC | "All PII must be encrypted at rest; SOC 2 Type II compliance required" |
+| **What data** do we store, for how long, and how do we recover it? | DR | "Tenant data retained for 90 days after account closure, RPO < 1 hour" |
+| **What external systems** do we connect to, and how? | INT | "Stripe Billing API for subscription management via REST" |
+| **How do we deploy, monitor, and respond** to incidents? | OPS | "Blue-green deployments with PagerDuty alerting on error rate > 1%" |
+| **How must the interface look, feel, and behave** for users? | UX | "WCAG 2.1 AA compliance; responsive down to 375px width" |
+| **How do we isolate tenants, gate features, and meter usage?** | MT | "Logical tenant isolation at row level; API call metering per plan tier" |
+
+### Common Disambiguation
+
+- **SEC vs NFR:** If it's about protecting data, enforcing access control, or meeting a regulation \u2192 SEC. If it's about system performance, uptime, or scalability \u2192 NFR. A requirement like "99.9% uptime" is an NFR; "audit logs for all admin actions" is SEC.
+- **TR vs ADR:** A TR specifies a concrete technology choice ("use PostgreSQL"). An ADR records a structural decision with context, trade-offs, and alternatives considered ("why row-level isolation over schema-per-tenant"). TRs often follow from ADRs.
+- **FR vs INT:** If it describes what the user experiences \u2192 FR. If it describes how two systems communicate \u2192 INT. "User can pay with a credit card" is FR; "Stripe Checkout API integration for payment processing" is INT.
+- **DR vs SEC:** If it's about what data exists, how long we keep it, and how we recover it \u2192 DR. If it's about who can access it and how it's protected \u2192 SEC. These often cross-reference each other.
+- **NFR vs OPS:** If it's a measurable target the system must meet \u2192 NFR. If it's about the tooling and processes to run the system \u2192 OPS. "p99 latency < 200ms" is NFR; "Datadog APM for latency monitoring" is OPS.
+
+## File Naming Convention
+
+\`\`\`
+{PREFIX}-{NNN}-{slug}.md
+\`\`\`
+
+- **PREFIX** \u2014 category abbreviation from the table above
+- **NNN** \u2014 three-digit sequential number (e.g., \`001\`, \`012\`)
+- **slug** \u2014 lowercase kebab-case descriptive name
+
+Examples:
+- \`FR-001-user-registration.md\`
+- \`SEC-001-multi-tenant-auth.md\`
+- \`ADR-001-database-selection.md\`
+
+## Status Definitions
+
+All requirements use a universal status lifecycle:
+
+| Status | Meaning |
+|---|---|
+| \`Draft\` | Initial capture, under discussion |
+| \`Proposed\` | Formally proposed, awaiting review |
+| \`Accepted\` | Approved and active |
+| \`Implemented\` | Fully delivered |
+| \`Deprecated\` | No longer applicable |
+| \`Superseded\` | Replaced by another requirement (link to successor) |
+
+## Cross-Referencing Guide
+
+Every requirement document should include a \`## Traceability\` section. Use relative markdown links with the requirement ID as link text.
+
+Example:
+\`\`\`markdown
+## Traceability
+
+- **Implements:** [FR-001](../functional/FR-001-user-registration.md)
+- **Constrained by:** [NFR-001](../non-functional/NFR-001-uptime-sla.md)
+- **Related:** [SEC-001](../security/SEC-001-multi-tenant-auth.md)
+\`\`\`
+
+### Link Types
+
+| Link Type | Meaning |
+|---|---|
+| **Implements** | This requirement realizes a higher-level requirement |
+| **Constrained by** | This requirement is bounded by another requirement |
+| **Supports** | This requirement contributes to but does not fully realize another |
+| **Supersedes** | This requirement replaces a deprecated one |
+| **Related** | Informational relationship |
+
+## Connecting Requirements to Code
+
+- **GitHub issues:** Use the Requirements Traceability section of the issue template to reference requirement IDs
+- **PR descriptions:** Include a Requirements section with links to relevant requirement documents
+- **Commit footers:** Optionally add \`Implements BR-001\` or \`Supports NFR-003\` lines
+
+## Dependency Flow
+
+Requirements relate to each other in a layered hierarchy:
+
+\`\`\`
+Business Requirements (BR)
+    \u2192 justify epics and initiatives
+
+Functional (FR), Integration (INT), Multi-Tenancy (MT)
+    \u2192 decompose into feature issues
+
+NFRs, Security (SEC), UX
+    \u2192 appear as acceptance criteria AND as standalone issues
+
+Architectural Decisions (ADR)
+    \u2192 spawn implementation issues and serve as context
+
+Technical (TR), Data (DR), Operational (OPS)
+    \u2192 drive infrastructure and platform issues
+\`\`\`
+`;
+var STANDARDS_AND_FRAMEWORKS = `# Standards & Frameworks Reference
+
+This reference provides detailed guidance on the standards and frameworks that inform each requirement category. Consult this when you're uncertain about how to structure a requirement, what level of detail is appropriate, or how to handle an edge case within a specific category.
+
+## Table of Contents
+
+1. [BR \u2014 BABOK Guide v3](#br--babok-guide-v3)
+2. [FR \u2014 BABOK v3 + IEEE 830](#fr--babok-v3--ieee-830)
+3. [NFR \u2014 ISO/IEC 25010:2023](#nfr--isoiec-250102023)
+4. [ADR \u2014 Nygard ADR + MADR](#adr--nygard-adr--madr)
+5. [TR \u2014 BABOK v3 Transition Requirements](#tr--babok-v3-transition-requirements)
+6. [SEC \u2014 OWASP ASVS + NIST SP 800-53](#sec--owasp-asvs--nist-sp-800-53)
+7. [DR \u2014 DAMA-DMBOK](#dr--dama-dmbok)
+8. [INT \u2014 Enterprise Integration Patterns + OpenAPI](#int--enterprise-integration-patterns--openapi)
+9. [OPS \u2014 Google SRE Book + ITIL 4](#ops--google-sre-book--itil-4)
+10. [UX \u2014 WCAG 2.1 + Nielsen Norman Heuristics](#ux--wcag-21--nielsen-norman-heuristics)
+11. [MT \u2014 Azure Well-Architected Framework](#mt--azure-well-architected-framework)
+12. [Cross-Cutting References](#cross-cutting-references)
+
+---
+
+## BR \u2014 BABOK Guide v3
+
+**Standard:** [BABOK Guide v3 \u2014 Requirements Classification Schema](https://www.iiba.org/business-analysis-certifications/iiba-certifications/ecba-certification/babok-guide-v3/)
+
+**What it is:** The International Institute of Business Analysis (IIBA) defines business requirements as the highest level of the requirements hierarchy \u2014 statements of goals, objectives, and outcomes that describe why a change is being undertaken.
+
+**How it informs BR documents:**
+- Business requirements sit at the top of the requirements hierarchy. Every other requirement should eventually trace back to one.
+- Stakeholder identification follows BABOK's guidance: identify who cares about this requirement, what their role is, and what their interest is.
+- Success metrics should be specific and measurable \u2014 BABOK emphasizes that business requirements without measurable success criteria are aspirational statements, not requirements.
+- Traceability: BABOK's model flows from Business Requirements \u2192 Stakeholder Requirements \u2192 Solution Requirements (functional + non-functional) \u2192 Transition Requirements. Our taxonomy maps to this: BR \u2192 FR/NFR \u2192 TR.
+
+**When to consult this:** When you're struggling to articulate *why* something is being built (especially when reverse-engineering from code), when defining stakeholders, or when writing success metrics.
+
+---
+
+## FR \u2014 BABOK v3 + IEEE 830
+
+**Standards:**
+- [BABOK Guide v3 \u2014 Solution Requirements](https://www.iiba.org/business-analysis-certifications/iiba-certifications/ecba-certification/babok-guide-v3/)
+- [IEEE 830 (SRS) \u2014 Recommended Practice for Software Requirements Specifications](https://standards.ieee.org/ieee/830/1222/)
+
+**What they are:** BABOK defines functional requirements as "solution requirements" that describe user-visible behavior. IEEE 830 provides the classic structure for Software Requirements Specifications, including the concept of structured flows.
+
+**How they inform FR documents:**
+- The user story format ("As a... I want... so that...") captures the actor, action, and business value in a single sentence. This comes from agile practice but aligns with BABOK's emphasis on stakeholder-centric requirements.
+- Structured flows (main flow, alternative flows, exception flows) come from IEEE 830's recommended practices. The main flow is the happy path. Alternative flows are valid variations. Exception flows handle errors.
+- MoSCoW prioritization (Must Have / Should Have / Could Have / Won't Have) comes from the DSDM Agile Project Framework and is used for the Priority field in FR documents.
+- Acceptance criteria should be specific, testable, and binary (pass/fail). Each criterion describes one verifiable condition.
+
+**When to consult this:** When structuring a complex feature into flows, when deciding how to decompose a large feature into multiple FRs, when writing acceptance criteria, or when prioritizing requirements.
+
+---
+
+## NFR \u2014 ISO/IEC 25010:2023
+
+**Standard:** [ISO/IEC 25010:2023 \u2014 Systems and Software Quality Requirements and Evaluation](https://www.iso.org/standard/35733.html)
+
+**What it is:** ISO 25010 defines a product quality model with characteristics and sub-characteristics. It's the international standard for thinking about software quality attributes.
+
+**Quality characteristics defined by ISO 25010:**
+- **Functional suitability** \u2014 Does it do what it's supposed to? (correctness, completeness, appropriateness)
+- **Performance efficiency** \u2014 Time behavior, resource utilization, capacity
+- **Compatibility** \u2014 Co-existence, interoperability
+- **Usability** \u2014 Recognizability, learnability, operability, error protection, aesthetics, accessibility
+- **Reliability** \u2014 Maturity, availability, fault tolerance, recoverability
+- **Security** \u2014 Confidentiality, integrity, non-repudiation, accountability, authenticity (note: in our taxonomy, security gets its own SEC category)
+- **Maintainability** \u2014 Modularity, reusability, analysability, modifiability, testability
+- **Portability** \u2014 Adaptability, installability, replaceability
+
+**How it informs NFR documents:**
+- Every NFR must have a numeric, measurable target. "The system should be fast" is not an NFR. "API response time must be < 200ms at p99" is.
+- The Quality Attribute field in the NFR template maps to ISO 25010's characteristics. Use this to categorize what kind of quality the NFR addresses.
+- Measurement methods must be specified \u2014 how will you know if the target is being met?
+
+**When to consult this:** When you're not sure if something is an NFR (use the quality characteristics as a checklist), when a stated quality target is vague and needs to be made measurable, or when you need to categorize what type of quality attribute an NFR addresses.
+
+---
+
+## ADR \u2014 Nygard ADR + MADR
+
+**Standards:**
+- [Nygard ADR Format](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) \u2014 The original lightweight ADR format
+- [MADR \u2014 Markdown Architectural Decision Records](https://adr.github.io/madr/) \u2014 Extended format with structured alternatives
+
+**What they are:** Michael Nygard's original ADR format (Context \u2192 Decision \u2192 Consequences) established the standard for documenting architecture decisions as lightweight, immutable records. MADR extends this with explicit alternatives and structured consequences.
+
+**How they inform ADR documents:**
+- **Context:** What forces are at play? Technical constraints, business pressures, team capabilities, timeline. This is the "why now" of the decision.
+- **Decision:** State it clearly: "We will use X." Not "We are considering X."
+- **Alternatives considered:** For each alternative, document what it is, its pros and cons, and why it was rejected. This is crucial \u2014 future readers need to know not just what was decided, but what was considered and why other options lost.
+- **Consequences:** Every decision has positive, negative, and neutral consequences. Documenting negative consequences honestly is essential \u2014 it prevents future developers from relitigating decisions without understanding the trade-offs.
+- **Immutability:** ADRs are not edited once accepted \u2014 they are superseded by new ADRs. This preserves the decision history.
+
+**When to consult this:** When deciding whether something is an ADR vs. a TR (ADR = structural decision with trade-offs; TR = specific technology choice), when structuring the alternatives section, or when documenting consequences honestly (resist the temptation to only list positives).
+
+---
+
+## TR \u2014 BABOK v3 Transition Requirements
+
+**Standard:** [BABOK Guide v3 \u2014 Transition Requirements](https://www.iiba.org/business-analysis-certifications/iiba-certifications/ecba-certification/babok-guide-v3/)
+
+**What it is:** BABOK defines transition requirements as capabilities the solution must have to facilitate the transition from the current state to the desired state. In our taxonomy, TRs pin down specific technology, framework, and version choices.
+
+**How it informs TR documents:**
+- TRs are concrete and specific: "PostgreSQL 16+", "Express 4.x", "Redis 7". Not "a relational database" (that's an ADR-level decision).
+- Every TR should be traceable to an ADR that justifies the choice. If no ADR exists, the rationale should be included in the TR itself.
+- Version constraints, licensing, and vendor/maintainer information help with long-term planning and risk assessment.
+- Remember the version drift principle: cite observed versions but treat them as floors, not pins.
+
+**When to consult this:** When deciding the granularity of a TR (one per technology, not one per library), when linking TRs to their justifying ADRs, or when documenting version constraints.
+
+---
+
+## SEC \u2014 OWASP ASVS + NIST SP 800-53
+
+**Standards:**
+- [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) \u2014 A framework of security requirements organized by domain
+- [NIST SP 800-53 Rev 5](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) \u2014 Security and Privacy Controls for Information Systems
+
+**What they are:** OWASP ASVS provides a practical, developer-friendly framework for security requirements organized into chapters: authentication, session management, access control, validation, cryptography, error handling, data protection, communications, malicious code, business logic, files, and API security. NIST 800-53 provides a comprehensive control catalog used for compliance frameworks like FedRAMP and SOC 2.
+
+**How they inform SEC documents:**
+- OWASP ASVS chapter references help categorize security requirements. For example:
+  - V2: Authentication (password policies, multi-factor, credential storage)
+  - V3: Session Management (token generation, timeout, revocation)
+  - V4: Access Control (RBAC, least privilege, path traversal)
+  - V5: Validation, Sanitization, and Encoding
+  - V6: Stored Cryptography
+  - V7: Error Handling and Logging
+  - V8: Data Protection
+  - V13: API and Web Service Security
+- NIST 800-53 control families map to compliance requirements (e.g., AC = Access Control, AU = Audit and Accountability, IA = Identification and Authentication)
+- STRIDE threat categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) help structure threat model references
+- Validation approaches should include both automated (CI security scans, SAST, DAST) and manual (penetration testing, code review) methods
+
+**When to consult this:** When categorizing a security requirement, when linking to specific OWASP ASVS or NIST 800-53 controls, when writing threat model references, when distinguishing between SEC and NFR (security protects; NFR measures quality), or when specifying validation approaches.
+
+---
+
+## DR \u2014 DAMA-DMBOK
+
+**Standard:** [DAMA-DMBOK \u2014 Data Management Body of Knowledge](https://www.dama.org/cpages/body-of-knowledge)
+
+**What it is:** DAMA-DMBOK covers data governance, data quality, data lifecycle management, data architecture, and related disciplines. It provides frameworks for thinking about data classification, retention, and recovery.
+
+**How it informs DR documents:**
+- **Data classification levels:** Public \u2192 Internal \u2192 Confidential \u2192 Restricted. Each level has corresponding handling rules (encryption, access logging, need-to-know).
+- **Retention policies:** Every data type needs a retention period, legal basis for retention, and deletion method. DAMA emphasizes that retention is not just "how long" but also "why that long" and "what triggers deletion."
+- **RPO/RTO framework:**
+  - RPO (Recovery Point Objective): Maximum acceptable data loss measured in time. RPO < 1 hour means you can't lose more than 1 hour of data.
+  - RTO (Recovery Time Objective): Maximum acceptable downtime. RTO < 4 hours means the system must be back up within 4 hours.
+- **Data lifecycle:** Creation \u2192 Active Use \u2192 Archival \u2192 Deletion. Each phase has different storage, access, and protection requirements.
+
+**When to consult this:** When classifying data sensitivity, when defining retention policies (especially the legal basis), when setting RPO/RTO targets, or when documenting the data lifecycle for a new entity.
+
+---
+
+## INT \u2014 Enterprise Integration Patterns + OpenAPI
+
+**Standards:**
+- [Enterprise Integration Patterns (Hohpe & Woolf)](https://www.enterpriseintegrationpatterns.com/) \u2014 Canonical patterns for system integration
+- [OpenAPI Specification](https://www.openapis.org/) \u2014 Standard for describing REST APIs
+
+**What they are:** Hohpe & Woolf's Enterprise Integration Patterns define the vocabulary for how systems communicate: messaging, routing, transformation, endpoints. OpenAPI provides the standard for documenting REST API contracts.
+
+**How they inform INT documents:**
+- **Direction labels:** Inbound (external system calls us), Outbound (we call external system), Bidirectional
+- **Error handling strategies from EIP:**
+  - Retry with exponential backoff \u2014 for transient failures
+  - Circuit breaker \u2014 stop calling a failing service to prevent cascade failures
+  - Dead letter queue (DLQ) \u2014 capture messages that can't be processed for later investigation
+  - Idempotency \u2014 ensure repeated calls don't cause duplicate effects
+- **SLA expectations:** Document both what we expect from the external system and what they expect from us. Include availability, response time, and rate limits.
+- **API contracts:** Follow OpenAPI conventions for documenting endpoints, request/response schemas, authentication methods, and error codes.
+
+**When to consult this:** When documenting error handling for an integration (use the EIP vocabulary), when specifying fallback behavior, when distinguishing between FR (what the user experiences) and INT (how systems communicate), or when documenting API contracts.
+
+---
+
+## OPS \u2014 Google SRE Book + ITIL 4
+
+**Standards:**
+- [Google SRE Book \u2014 Site Reliability Engineering](https://sre.google/sre-book/table-of-contents/) \u2014 Engineering approach to operations
+- [ITIL 4](https://www.axelos.com/certifications/itil-service-management) \u2014 IT service management framework
+
+**What they are:** The Google SRE book defines principles for running reliable production systems: SLIs, SLOs, error budgets, toil reduction, incident response. ITIL 4 provides the broader service management framework for change management, incident management, and service operations.
+
+**How they inform OPS documents:**
+- **SLIs (Service Level Indicators):** The metrics that measure service health. Examples: request latency, error rate, throughput, availability.
+- **SLOs (Service Level Objectives):** Targets for SLIs. Example: "99.9% of requests complete within 200ms." SLOs belong in NFR documents, but OPS documents describe how they're monitored.
+- **Observability:** The three pillars \u2014 metrics, logs, traces. OPS documents should specify all three: what metrics are collected, what's logged, and whether distributed tracing is in place.
+- **Incident response:** Severity levels, response times, escalation paths, communication plans. The SRE book emphasizes blameless postmortems and clear runbooks.
+- **Deployment strategies:** Blue-green, canary, rolling, feature flags. Each has different rollback characteristics and risk profiles.
+
+**When to consult this:** When defining monitoring and alerting rules, when structuring incident response procedures, when choosing deployment strategies, or when distinguishing between NFR (the target) and OPS (the machinery that monitors and maintains the target).
+
+---
+
+## UX \u2014 WCAG 2.1 + Nielsen Norman Heuristics
+
+**Standards:**
+- [WCAG 2.1 \u2014 Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) \u2014 W3C accessibility standard
+- [Nielsen Norman Group \u2014 10 Usability Heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/) \u2014 Foundational usability principles
+
+**What they are:** WCAG 2.1 defines three levels of accessibility conformance (A, AA, AAA) across four principles: Perceivable, Operable, Understandable, Robust (POUR). Nielsen's heuristics provide a framework for evaluating usability beyond accessibility.
+
+**How they inform UX documents:**
+- **WCAG conformance levels:**
+  - Level A: Minimum accessibility. Removes the most serious barriers.
+  - Level AA: The accepted standard for most applications. Addresses the majority of barriers.
+  - Level AAA: The highest level. Often impractical for entire sites but useful for specific features.
+- **POUR principles:**
+  - Perceivable: Can users perceive the content? (text alternatives, captions, contrast)
+  - Operable: Can users operate the interface? (keyboard navigation, timing, seizure prevention)
+  - Understandable: Can users understand the content and interface? (readability, predictability, error prevention)
+  - Robust: Can the content be interpreted by assistive technologies? (valid markup, ARIA)
+- **Nielsen's 10 heuristics:**
+  1. Visibility of system status
+  2. Match between system and the real world
+  3. User control and freedom
+  4. Consistency and standards
+  5. Error prevention
+  6. Recognition rather than recall
+  7. Flexibility and efficiency of use
+  8. Aesthetic and minimalist design
+  9. Help users recognize, diagnose, and recover from errors
+  10. Help and documentation
+- **Responsive design:** Document specific breakpoints and layout behavior changes, not just "it should be responsive."
+
+**When to consult this:** When specifying accessibility requirements (use WCAG success criteria references like "WCAG 2.1 SC 1.4.3 \u2014 Contrast Minimum"), when evaluating an interface against usability heuristics, or when defining responsive breakpoints.
+
+---
+
+## MT \u2014 Azure Well-Architected Framework
+
+**Standard:** [Azure Well-Architected Framework \u2014 Multi-Tenancy](https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview)
+
+**What it is:** Microsoft's comprehensive guidance on building multi-tenant SaaS applications, covering tenant isolation models, feature gating, metering, billing, and provisioning. While it's Azure-branded, the architectural patterns are cloud-agnostic.
+
+**How it informs MT documents:**
+- **Isolation models:**
+  - Row-level isolation: Single database, tenant_id column, enforced by RLS policies. Cheapest, hardest to guarantee isolation.
+  - Schema-per-tenant: Single database, separate schema per tenant. Middle ground.
+  - Database-per-tenant: Full isolation. Most expensive, easiest to guarantee.
+  - The framework helps evaluate trade-offs between cost, isolation guarantees, and operational complexity.
+- **Feature gating:** Mechanisms for enabling/disabling features per tenant or plan tier. Consider: feature flags, entitlement systems, plan-based checks.
+- **Metering dimensions:** What to meter (API calls, storage, users, compute), how to collect (real-time counters, batch aggregation), and how to bill (per-unit, tiered, flat-rate).
+- **Provisioning:** Tenant onboarding workflow \u2014 creating the tenant record, provisioning resources, configuring DNS/routing. Speed matters for self-service.
+- **Noisy neighbor prevention:** Rate limiting, resource quotas, fair scheduling \u2014 how to prevent one tenant from degrading the experience of others.
+
+**When to consult this:** When choosing a tenant isolation model, when designing feature gating, when defining metering and billing dimensions, when planning tenant provisioning flows, or when addressing noisy-neighbor concerns.
+
+---
+
+## Tier-Specific Standards Guidance
+
+The four architectural tiers (Platform, Industry, Customer Workflow, Consumer Application) influence which standards are most relevant when writing requirements. The tier names below are the bundle defaults \u2014 consuming projects may rename or reduce the tier set in their own \`docs/project-context.md\`.
+
+### Platform Tier
+All category-specific standards apply at their full depth. Platform requirements define the core infrastructure that all other tiers depend on. Pay particular attention to:
+- **INT** \u2014 Enterprise Integration Patterns and OpenAPI for the headless API surface
+- **MT** \u2014 Azure Well-Architected Framework for tenant isolation (this is inherently platform-tier)
+- **SEC** \u2014 OWASP ASVS for the authentication/authorization framework
+- **NFR** \u2014 ISO 25010 quality targets for the shared infrastructure
+
+### Industry Tier
+Regulatory and compliance standards dominate. Industry requirements translate external mandates into platform capabilities:
+- **SEC** \u2014 NIST SP 800-53 controls mapped to industry-specific regulations
+- **INT** \u2014 Industry-specific interoperability standards
+- **DR** \u2014 DAMA-DMBOK data classification applied to industry-specific data sensitivity levels
+
+### Customer Workflow Tier
+Focus on configurability and business rules. Standards inform what the platform's workflow engine must support:
+- **FR** \u2014 BABOK/IEEE 830 for capturing the configurable business logic \u2014 emphasis on parameterization (what can the tenant change?) vs. fixed behavior
+- **BR** \u2014 BABOK stakeholder analysis, noting that the stakeholder is the tenant administrator who configures the workflow, not the end user
+
+### Consumer Application Tier
+Front-end and UX standards become primary. These requirements describe what consortium members or customers build on top of the platform:
+- **UX** \u2014 WCAG 2.1 accessibility requirements, Nielsen Norman heuristics for front-end usability
+- **FR** \u2014 IEEE 830 structured flows for user-facing interactions in the consuming application
+- **INT** \u2014 OpenAPI specifications for the API contracts the consumer application consumes (trace back to Platform INT requirements)
+
+Note: Consumer Application requirements follow the same rigor as Platform requirements. The tier distinction is architectural, not qualitative.
+
+---
+
+## Cross-Cutting References
+
+These resources inform the overall taxonomy structure, traceability approach, and cross-referencing conventions across all categories:
+
+### BABOK Guide v3
+[IIBA BABOK Guide v3](https://www.iiba.org/business-analysis-certifications/iiba-certifications/ecba-certification/babok-guide-v3/)
+
+The requirements classification schema (Business \u2192 Stakeholder \u2192 Solution \u2192 Transition) is the backbone of the taxonomy hierarchy. BABOK's traceability guidance directly informs the cross-referencing conventions used throughout.
+
+### IEEE 29148:2018
+[IEEE 29148:2018 \u2014 Systems and Software Engineering \u2014 Life Cycle Processes \u2014 Requirements Engineering](https://standards.ieee.org/ieee/29148/6937/)
+
+The international standard for requirements engineering processes, covering elicitation, analysis, specification, and validation. Useful when thinking about the overall requirements process, not just individual document structure.
+
+### arc42
+[arc42 \u2014 Software Architecture Documentation](https://arc42.org/overview)
+
+A practical template for software architecture documentation. Influenced the separation between architectural decisions (ADR) and technical specifications (TR) and operational concerns (OPS) in this taxonomy.
+
+### C4 Model
+[C4 Model \u2014 Software Architecture Visualization](https://c4model.com/)
+
+Simon Brown's approach to visualizing software architecture at four levels of abstraction: Context, Container, Component, Code. Useful context for understanding how ADRs and TRs relate to system design at different levels.
+`;
+var REQUIREMENTS_WRITER_REFERENCE_FILES = [
+  { path: "_references/templates/_template-BR.md", content: TEMPLATE_BR },
+  { path: "_references/templates/_template-FR.md", content: TEMPLATE_FR },
+  { path: "_references/templates/_template-NFR.md", content: TEMPLATE_NFR },
+  { path: "_references/templates/_template-TR.md", content: TEMPLATE_TR },
+  { path: "_references/templates/_template-ADR.md", content: TEMPLATE_ADR },
+  { path: "_references/templates/_template-SEC.md", content: TEMPLATE_SEC },
+  { path: "_references/templates/_template-DR.md", content: TEMPLATE_DR },
+  { path: "_references/templates/_template-INT.md", content: TEMPLATE_INT },
+  { path: "_references/templates/_template-OPS.md", content: TEMPLATE_OPS },
+  { path: "_references/templates/_template-UX.md", content: TEMPLATE_UX },
+  { path: "_references/templates/_template-MT.md", content: TEMPLATE_MT },
+  {
+    path: "_references/templates/_template-category-README.md",
+    content: TEMPLATE_CATEGORY_README
+  },
+  {
+    path: "_references/templates/_template-requirements-README.md",
+    content: TEMPLATE_REQUIREMENTS_README
+  },
+  {
+    path: "_references/standards-and-frameworks.md",
+    content: STANDARDS_AND_FRAMEWORKS
+  }
+];
+var requirementsWriterSubAgent = {
+  name: "requirements-writer",
+  description: "Writes formal requirement documents (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) from upstream proposals using the 11-category taxonomy, the four-tier classification, and the decision-authority rules (direct-write vs. propose-only ADR/TR). Handles one req:write issue per session. Produces requirement documents \u2014 not capability models or gap reports.",
+  model: AGENT_MODEL.POWERFUL,
+  maxTurns: 80,
+  platforms: { cursor: { exclude: true } },
+  prompt: [
+    "# Requirements Writer Agent",
+    "",
+    "You author formal requirement documents using the 11-category",
+    "taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
+    "four-tier architectural classification (Platform, Industry, Customer",
+    "Workflow, Consumer Application). Each session handles exactly **one**",
+    "`req:write` issue and writes exactly **one** requirement document.",
+    "",
+    "This agent produces **requirement documents only** \u2014 capability",
+    "models are written by the `bcm-writer` agent and requirement-gap",
+    "discovery is the responsibility of the `requirements-analyst` agent.",
+    "Keep this boundary clean: never open `req:scan`, `req:draft`, or",
+    "`bcm:*` issues from this pipeline.",
+    "",
+    "Follow your project's shared agent conventions (`AGENTS.md`,",
+    "`CLAUDE.md`, or equivalent) for all commit, branch, and PR rules.",
+    "",
+    "---",
+    "",
+    ...PROJECT_CONTEXT_READER_SECTION,
+    "## Design Principles",
+    "",
+    "1. **One requirement per session.** Each `req:write` issue maps to a",
+    "   single requirement document. Never write two documents in one",
+    "   session and never start a second issue.",
+    "2. **Templates are authoritative.** Every category has a template",
+    "   under `<TEMPLATES_ROOT>`. Use it verbatim \u2014 do not invent new",
+    "   sections or reorder existing ones. A section that does not apply",
+    "   gets `Not applicable \u2014 <reason>` rather than being omitted.",
+    "3. **Decision authority is non-negotiable.** Direct-write categories",
+    "   ship as `Status: Draft`. ADR and TR documents ship as",
+    "   `Status: Proposed` with a Recommendation that frames a human",
+    "   decision \u2014 never decide for the human.",
+    "4. **Trace upstream.** Every requirement links back to the proposal",
+    "   that produced it, the source document(s) cited in that proposal,",
+    "   and the upstream BCM capability or business need it serves.",
+    "5. **Cite, don't invent.** When the proposal does not supply a",
+    "   stakeholder, metric, threat model entry, or technology option,",
+    "   write `TODO:` and flag the issue with `status:needs-attention`",
+    "   rather than fabricating content.",
+    "",
+    "---",
+    "",
+    "## Configurable Paths",
+    "",
+    "The pipeline uses these placeholders. Consuming projects override the",
+    "defaults by passing paths in the `/write-requirement` skill",
+    "invocation, by recording overrides in `docs/project-context.md`, or",
+    "by extending this rule in their own `agentConfig.rules`.",
+    "",
+    "| Placeholder | Meaning | Default |",
+    "|-------------|---------|---------|",
+    "| `<REQUIREMENTS_ROOT>` | Root folder for final requirement documents | `docs/requirements/` |",
+    "| `<RESEARCH_REQUIREMENTS_ROOT>` | Where the upstream `requirements-analyst` writes proposals | `docs/research/requirements/` |",
+    "| `<TEMPLATES_ROOT>` | Where the category templates ship (set automatically by this bundle) | `.claude/skills/write-requirement/_references/templates/` |",
+    "| `<STANDARDS_REF>` | Standards & frameworks reference document | `.claude/skills/write-requirement/_references/standards-and-frameworks.md` |",
+    "| `<PREFIX>` | Project-specific requirement ID prefix | none \u2014 requirement IDs use the category prefix (`BR`, `FR`, \u2026) unless `docs/project-context.md` defines a project prefix |",
+    "",
+    "If `docs/project-context.md` specifies a different requirements tree,",
+    "prefer that. Otherwise fall back to the defaults above.",
+    "",
+    "---",
+    "",
+    "## The 11-Category Taxonomy",
+    "",
+    "All requirements follow the BIZBOK-aligned 11-category taxonomy",
+    "below. Getting requirements into the right category matters because",
+    "it determines which template applies, which standards inform it, and",
+    "how it traces to other requirements.",
+    "",
+    "| Category | Prefix | Directory (default) | Question it answers |",
+    "|----------|--------|---------------------|---------------------|",
+    "| Business Requirements | BR | `business/` | **Why** are we building this? What business value does it deliver? |",
+    "| Functional Requirements | FR | `functional/` | **What** does the system do? What is the user-visible behavior? |",
+    "| Non-Functional Requirements | NFR | `non-functional/` | **How well** must the system perform? What quality bar must it meet? |",
+    "| Technical Requirements | TR | `technical/` | **What technology** are we using, and why that one? |",
+    "| Architectural Decisions | ADR | `architectural-decisions/` | **What structural decision** are we making, and what are the trade-offs? |",
+    "| Security & Compliance | SEC | `security/` | **What must we protect**, and what rules govern that protection? |",
+    "| Data Requirements | DR | `data/` | **What data** do we store, how long, and how do we recover it? |",
+    "| Integration Requirements | INT | `integration/` | **What external systems** do we connect to, and how? |",
+    "| Operational Requirements | OPS | `operational/` | **How do we deploy, monitor, and respond** to incidents? |",
+    "| UX Requirements | UX | `ux/` | **How must the interface look, feel, and behave** for users? |",
+    "| Multi-Tenancy & Licensing | MT | `multi-tenancy/` | **How do we isolate tenants, gate features, and meter usage?** |",
+    "",
+    "All requirement documents live under `<REQUIREMENTS_ROOT>` in the",
+    "category directory shown above. Directory names are defaults \u2014",
+    "consuming projects may rename them, but the prefixes are universal.",
+    "",
+    "### Disambiguation Rules",
+    "",
+    "Apply these rules when deciding where a requirement belongs:",
+    "",
+    "- **SEC vs NFR:** Protecting data, enforcing access control, or",
+    "  meeting a regulation \u2192 SEC. System performance, uptime, or",
+    '  scalability \u2192 NFR. "99.9% uptime" is NFR; "audit logs for all',
+    '  admin actions" is SEC.',
+    '- **TR vs ADR:** A TR pins down a specific technology choice ("use',
+    '  PostgreSQL 16+"). An ADR records a structural decision with',
+    '  context, trade-offs, and alternatives ("why row-level isolation',
+    '  over schema-per-tenant"). TRs often follow from ADRs.',
+    "- **FR vs INT:** What the user experiences \u2192 FR. How two systems",
+    '  communicate \u2192 INT. "User can pay with a credit card" is FR;',
+    '  "Stripe Checkout API integration for payment processing" is INT.',
+    "- **DR vs SEC:** What data exists, how long we keep it, and how we",
+    "  recover it \u2192 DR. Who can access it and how it's protected \u2192 SEC.",
+    "  These often cross-reference each other.",
+    "- **NFR vs OPS:** A measurable target the system must meet \u2192 NFR.",
+    '  The tooling and processes to run the system \u2192 OPS. "p99 latency',
+    '  < 200ms" is NFR; "Datadog APM for latency monitoring" is OPS.',
+    "",
+    "---",
+    "",
+    "## Architectural Tiers",
+    "",
+    "Every requirement also belongs to one of four architectural tiers.",
+    'Tier is **orthogonal** to category \u2014 category answers "what kind"',
+    'while tier answers "where in the architecture." The tier names below',
+    "are the bundle defaults; consuming projects may rename or reduce the",
+    "tier set in their own `docs/project-context.md`.",
+    "",
+    "| Tier | Slug | When to use |",
+    "|------|------|-------------|",
+    "| **Platform** | `platform` | Core platform services \u2014 APIs, tenant isolation, auth, event bus, shared infrastructure |",
+    "| **Industry** | `industry` | Vertical-specific capabilities not every tenant needs |",
+    "| **Customer Workflow** | `customer-workflow` | Business logic tenants configure within the platform \u2014 approval chains, notification rules, intake processes |",
+    "| **Consumer Application** | `consumer-app` | UI/UX and integrations in external front-ends/systems consuming the platform's APIs |",
+    "",
+    "Tier is a **required metadata field**. Set it in the Metadata table",
+    "of every requirement document and apply the matching `tier:*` issue",
+    "label (`tier:platform`, `tier:industry`, `tier:customer-workflow`,",
+    "or `tier:consumer-app`).",
+    "",
+    "**Customer field (optional).** When the proposal originated from or",
+    "applies to a specific customer, set the `Customer` field in the",
+    "Metadata table. Optional for Platform/Industry tiers, expected for",
+    "Customer Workflow / Consumer Application tiers when the project",
+    "tracks customer profiles.",
+    "",
+    "**Implementor field (tier-specific).** For Customer Workflow and",
+    "Consumer Application tiers, set the `Implementor` field (Consortium",
+    "Member / Customer / TBD) when the project tracks that distinction.",
+    "Skip the field entirely if it does not apply to your project.",
+    "",
+    "**Cross-tier traceability.** Higher-tier requirements must link to",
+    "lower-tier requirements they depend on using `Depends on (cross-tier)`",
+    "links in the Traceability section. For example, a Consumer",
+    "Application FR for an intake portal must trace to the Platform INT",
+    "for the API it consumes.",
+    "",
+    "---",
+    "",
+    "## Decision Authority Rules",
+    "",
+    "**This is the most important section.** Not all categories are",
+    "treated equally. The core principle is: **requirements that describe",
+    "*what* and *why* get written directly; decisions about *how* and",
+    "*with what* are deferred to humans.**",
+    "",
+    "### Write Directly (status: `Draft`)",
+    "",
+    "These categories describe business needs, user behavior, quality",
+    "targets, security posture, and user experience. The writer has full",
+    "authority to produce these documents:",
+    "",
+    "- **BR** \u2014 Business Requirements",
+    "- **FR** \u2014 Functional Requirements",
+    "- **NFR** \u2014 Non-Functional Requirements",
+    "- **SEC** \u2014 Security & Compliance",
+    "- **UX** \u2014 UX Requirements",
+    "",
+    "### Write with Partial Deferral",
+    "",
+    "These categories contain a mix of *what* (write directly) and *how*",
+    "(defer). Write the requirement portions directly but defer",
+    "technology/tooling selections:",
+    "",
+    "- **DR** \u2014 Write data models, retention policies, and classification",
+    "  directly. When backup strategy or storage technology must be",
+    "  specified, create a `Proposed` ADR or TR instead of choosing.",
+    "- **MT** \u2014 Write tenant isolation requirements and metering",
+    "  dimensions directly. When the isolation *model* must be chosen",
+    "  (row-level vs schema-per-tenant vs database-per-tenant), create a",
+    "  `Proposed` ADR instead of choosing.",
+    "- **INT** \u2014 Write the integration shape, direction, error handling",
+    "  strategy, and SLA expectations directly. When the specific",
+    "  provider must be selected, create a `Proposed` TR/ADR instead.",
+    "- **OPS** \u2014 Write operational requirements (monitoring needs,",
+    "  incident response, deployment strategy) directly. When specific",
+    "  tooling must be selected, create a `Proposed` TR/ADR instead.",
+    "",
+    "### Propose Only (status: `Proposed`, pending human decision)",
+    "",
+    "These categories represent technology and architecture decisions",
+    "that humans must make. Produce complete documents with all the",
+    "information needed for the decision, but **do not make the decision",
+    "itself**.",
+    "",
+    "- **ADR** \u2014 Write the full document following the ADR template:",
+    "  1. **Context** \u2014 forces at play, constraints, what prompted the",
+    "     decision",
+    '  2. **Decision** \u2014 set to: *"Pending human review. See',
+    '     Recommendation below."*',
+    "  3. **Alternatives Considered** \u2014 every viable option with",
+    "     equal-depth analysis. Each gets a description, pros, and cons.",
+    "     Do not shortchange options you don't prefer.",
+    "  4. **Recommendation** \u2014 state which option you recommend, *why*",
+    "     it's the best fit for the context, and what trade-offs are",
+    "     accepted. The reasoning must be specific to this project's",
+    "     situation \u2014 not generic.",
+    "  5. **Consequences** \u2014 positive, negative, and neutral consequences",
+    "     of the recommended option",
+    "  6. Set status to `Proposed`. Add an open item flagging that a",
+    "     human decision is required before dependent requirements can",
+    "     proceed.",
+    "",
+    "- **TR** \u2014 Write the full document following the TR template:",
+    '  1. **Technology Choice** \u2014 set to: *"Pending human review. See',
+    '     Recommendation below."*',
+    "  2. **Alternatives Considered** \u2014 every viable technology option",
+    "     with description, pros, cons, license, and maturity assessment",
+    "     for each",
+    "  3. **Recommendation** \u2014 state which technology you recommend,",
+    "     *why*, and what trade-offs are accepted",
+    '  4. **Rationale** \u2014 set to: *"See Recommendation above. Awaiting',
+    '     human decision."*',
+    "  5. Set status to `Proposed`. Add an open item flagging that a",
+    "     human decision is required.",
+    "",
+    "### How Deferral Works in Practice",
+    "",
+    "When writing a requirement that implies a technology choice:",
+    "",
+    "1. Write the requirement itself (FR, DR, INT, OPS, etc.) with full",
+    "   detail.",
+    "2. Where the requirement needs a technology decision, add a note:",
+    '   *"Technology selection pending \u2014 see [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md)"*.',
+    "3. Create the corresponding ADR or TR as `Proposed` with options,",
+    "   pros/cons, and recommendation.",
+    '4. In the ADR/TR open items, add: *"Human decision required.',
+    '   Dependent requirements: [list]"*.',
+    "5. In the original requirement's open items, add a cross-reference:",
+    '   *"Blocked by [ADR-NNN](../architectural-decisions/ADR-NNN-slug.md) \u2014',
+    '   technology selection pending human review."*',
+    "",
+    "This creates a clear chain: the requirement is understood, the",
+    "decision is framed with all necessary information, and the",
+    "dependency is tracked in both directions.",
+    "",
+    "---",
+    "",
+    "## File Naming Convention",
+    "",
+    "Every requirement file follows this pattern:",
+    "",
+    "```",
+    "{PREFIX}-{NNN}-{slug}.md",
+    "```",
+    "",
+    "- **PREFIX** \u2014 category abbreviation (`BR`, `FR`, `NFR`, `TR`,",
+    "  `ADR`, `SEC`, `DR`, `INT`, `OPS`, `UX`, `MT`). If the project",
+    "  declares a project-wide prefix in `docs/project-context.md`, use",
+    "  it instead.",
+    "- **NNN** \u2014 three-digit sequential number (001, 002, 012). Always",
+    "  check the target category directory under `<REQUIREMENTS_ROOT>`",
+    "  for the next available number before writing.",
+    "- **slug** \u2014 lowercase kebab-case descriptive name.",
+    "",
+    "Examples: `FR-001-user-registration.md`,",
+    "`ADR-003-database-selection.md`,",
+    "`SEC-001-authentication-framework.md`.",
+    "",
+    "---",
+    "",
+    "## Frontmatter",
+    "",
+    "Every `.md` requirement file must begin with a YAML frontmatter",
+    "block. The minimum required fields are `title` and `description`:",
+    "",
+    "```markdown",
+    "---",
+    'title: "FR-001: User Registration"',
+    'description: "Functional requirement for the user registration workflow."',
+    "tier: platform",
+    "---",
+    "",
+    "# FR-001: User Registration",
+    "",
+    "...",
+    "```",
+    "",
+    "The `title` value must match the document's `# Heading` line.",
+    "Titles containing colons must be wrapped in double quotes. The",
+    "`tier` field must be one of `platform`, `industry`,",
+    "`customer-workflow`, or `consumer-app` (use whatever tier slugs the",
+    "project declares).",
+    "",
+    "### Optional traceability extensions",
+    "",
+    "Projects that publish requirements through Starlight, Astro, or a",
+    "similar static-site generator may add structured traceability fields",
+    "to frontmatter. One example: a `referencedIn.meetings[]` block that",
+    "links the requirement back to a meeting transcript that informed it.",
+    "These conventions are **optional** \u2014 adopt them only if your project",
+    "already maintains the matching reverse-link structures.",
+    "",
+    "---",
+    "",
+    "## Status Lifecycle",
+    "",
+    "Every requirement has a status that tracks where it is in its",
+    "lifecycle:",
+    "",
+    "| Status | Meaning |",
+    "|---|---|",
+    "| `Draft` | Initial capture, under discussion |",
+    "| `Proposed` | Formally proposed, awaiting review \u2014 **used for ADR and TR documents pending human decision** |",
+    "| `Accepted` | Approved and active |",
+    "| `Implemented` | Fully delivered |",
+    "| `Deprecated` | No longer applicable |",
+    "| `Superseded` | Replaced by another requirement (link to successor) |",
+    "",
+    "---",
+    "",
+    "## Traceability",
+    "",
+    "Every requirement document must include a `## Traceability` section.",
+    "Use relative markdown links with the requirement ID as link text.",
+    "",
+    "```markdown",
+    "## Traceability",
+    "",
+    "- **Implements:** [BR-001](../business/BR-001-self-service-onboarding.md)",
+    "- **Constrained by:** [NFR-001](../non-functional/NFR-001-api-response-times.md)",
+    "- **Related:** [SEC-001](../security/SEC-001-authentication-framework.md)",
+    "```",
+    "",
+    "### Link Types",
+    "",
+    "| Link Type | Meaning |",
+    "|---|---|",
+    "| **Implements** | This requirement realizes a higher-level requirement |",
+    "| **Constrained by** | This requirement is bounded by another requirement |",
+    "| **Supports** | This requirement contributes to but does not fully realize another |",
+    "| **Supersedes** | This requirement replaces a deprecated one |",
+    "| **Related** | Informational relationship |",
+    "",
+    "### Dependency Flow",
+    "",
+    "```",
+    "Business Requirements (BR)",
+    "    -> justify epics and initiatives",
+    "",
+    "Functional (FR), Integration (INT), Multi-Tenancy (MT)",
+    "    -> decompose into feature work",
+    "",
+    "NFRs, Security (SEC), UX",
+    "    -> appear as acceptance criteria AND as standalone requirements",
+    "",
+    "Architectural Decisions (ADR)",
+    "    -> spawn implementation tasks and serve as context for TRs",
+    "",
+    "Technical (TR), Data (DR), Operational (OPS)",
+    "    -> drive infrastructure and platform work",
+    "```",
+    "",
+    "---",
+    "",
+    "## Open Items",
+    "",
+    "Every requirement document must end with a `## Open Items` section",
+    "(placed just above `## Revision History`). This section surfaces",
+    "things that need human attention.",
+    "",
+    "### Priority Levels",
+    "",
+    "| Priority | Meaning |",
+    "|---|---|",
+    "| **P0 \u2014 Blocker** | Cannot proceed with implementation until resolved |",
+    "| **P1 \u2014 High** | Significantly affects scope, security, or architecture |",
+    "| **P2 \u2014 Medium** | Affects quality or completeness but doesn't block progress |",
+    "| **P3 \u2014 Low** | Minor clarification, can be resolved asynchronously |",
+    "",
+    "### Subsection Types",
+    "",
+    "- **Identified Gaps** \u2014 Missing functionality, unhandled edge cases,",
+    "  incomplete aspects",
+    "- **Follow-up Questions** \u2014 Ambiguities where intent cannot be",
+    "  confidently inferred",
+    "- **Contradictions & Inconsistencies** \u2014 Conflicts between",
+    "  requirements, documentation, or stated goals",
+    "",
+    "Number each item within its subsection. Assign a priority. Call out",
+    "interdependencies with open items in other documents using the",
+    "format: `-> Depends on: [FR-001 Open Item #2](../functional/FR-001-slug.md#open-items)`.",
+    "",
+    "The `## Open Items` section is **not optional** \u2014 it appears in every",
+    'document, even if a subsection is empty (write "None identified.").',
+    "",
+    "---",
+    "",
+    "## Reading the Templates and Standards Reference",
+    "",
+    "Before writing any requirement document:",
+    "",
+    "1. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
+    "   category specified in the issue (`_template-FR.md`,",
+    "   `_template-ADR.md`, etc.). Templates are named",
+    "   `_template-{PREFIX}.md`. Every section in the template must",
+    "   appear in the final document.",
+    "",
+    "2. **Read `<STANDARDS_REF>`** if the category requires it (especially",
+    "   SEC, NFR, INT, ADR, TR). The reference covers OWASP ASVS, ISO",
+    "   25010, BABOK, MADR, Enterprise Integration Patterns, WCAG, and",
+    "   related standards that ground the templates.",
+    "",
+    "Templates and the standards reference ship with this skill \u2014 they",
+    "are the same files for every project that adopts the bundle.",
+    "",
+    "---",
+    "",
+    "## Maintaining the Registry Index",
+    "",
+    "Each category directory contains a `README.md` (or `_index.md`,",
+    "depending on project convention) that lists every requirement in",
+    "that category. **After writing any new requirement document, update",
+    "the category index:**",
+    "",
+    "1. Read the index file in the same directory as the new requirement.",
+    "2. Add a row to the requirements table with: ID (linked to the",
+    "   file), Title, Status, Priority, Last Updated date.",
+    "3. Insert the row in sequence-number order.",
+    "4. If the index contains a placeholder message, remove it.",
+    "",
+    "If the project has not seeded category READMEs yet, generate one",
+    "from `_template-category-README.md` (shipped with this skill) and",
+    "commit it alongside the requirement document.",
+    "",
+    "---",
+    "",
+    "## Agent Loop",
+    "",
+    "Run this loop exactly once per session. Never start a second issue.",
+    "",
+    "1. Claim one open `req:write` issue (also carries `type:requirement`",
+    "   and a `tier:*` label).",
+    "2. Transition `status:ready` \u2192 `status:in-progress` and create the",
+    "   branch per your project's branch-naming convention.",
+    "3. Execute the write phase below.",
+    "4. Commit, push, open a PR, and close the issue per your project's",
+    "   PR workflow. Closing the PR transitions the issue to",
+    "   `status:done` per the standard label conventions.",
+    "",
+    "---",
+    "",
+    "## The `req:write` Phase",
+    "",
+    "**Goal:** Read the proposal that produced this issue, write a single",
+    "requirement document under `<REQUIREMENTS_ROOT>`, and update the",
+    "category index.",
+    "",
+    "**Budget:** Read the issue body, the named proposal file under",
+    "`<RESEARCH_REQUIREMENTS_ROOT>`, the matching category template under",
+    "`<TEMPLATES_ROOT>`, and `<STANDARDS_REF>` if the category needs it.",
+    "Write one requirement document and one category-index update. No web",
+    "searches.",
+    "",
+    "### Steps",
+    "",
+    "1. **Parse the issue.** The `req:write` issue body must include:",
+    "   - **Category** (`BR`/`FR`/`NFR`/`TR`/`ADR`/`SEC`/`DR`/`INT`/`OPS`/`UX`/`MT`)",
+    "   - **Tier** (`platform`/`industry`/`customer-workflow`/`consumer-app`)",
+    "   - **Output Path** under `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
+    "   - **Inputs / Read** \u2014 the upstream proposals file and any source",
+    "     documents",
+    "   If any of these are missing or contradictory, comment on the",
+    "   issue, add `status:needs-attention`, and stop without writing.",
+    "",
+    "2. **Read the proposal.** Open the proposals file referenced in the",
+    "   issue inputs (under `<RESEARCH_REQUIREMENTS_ROOT>`). Find the",
+    "   specific proposal entry that matches this requirement's title and",
+    "   category. Treat the proposal as the authoritative source \u2014 do not",
+    "   invent fields it omits.",
+    "",
+    "3. **Read the matching template** under `<TEMPLATES_ROOT>` for the",
+    "   category. Read `<STANDARDS_REF>` if the category is SEC, NFR,",
+    "   INT, ADR, or TR \u2014 these depend on the standards reference for",
+    "   correct framing.",
+    "",
+    "4. **Pick the next sequence number.** Scan the target category",
+    "   directory under `<REQUIREMENTS_ROOT>` for existing files matching",
+    "   `{PREFIX}-NNN-*.md`. Use the next unused three-digit number.",
+    "",
+    "5. **Apply the decision-authority rules.** Default to `Status:",
+    "   Draft` for direct-write categories (BR, FR, NFR, SEC, UX). Set",
+    "   `Status: Proposed` for ADR and TR documents and frame the",
+    "   Recommendation section as a human decision. For DR/MT/INT/OPS",
+    "   categories that imply a technology choice, write the requirement",
+    "   directly but spin the technology decision off into a separate",
+    "   `Proposed` ADR or TR \u2014 record the cross-link in the Open Items",
+    "   section of both documents.",
+    "",
+    "6. **Write the document.** Fill every section in the template. For",
+    "   sections the proposal does not supply, write `TODO:` plus a brief",
+    "   note describing what input is needed, and add a corresponding",
+    "   `## Open Items` entry. Never leave a template section out.",
+    "",
+    "7. **Set frontmatter.** At minimum: `title`, `description`, `tier`.",
+    "   If the project declares optional frontmatter conventions in",
+    "   `docs/project-context.md` (such as `referencedIn.meetings[]`),",
+    "   honor them. Otherwise stop at the minimum.",
+    "",
+    "8. **Update the category index.** If the category directory has a",
+    "   `README.md` or `_index.md` registry, add a row for the new",
+    "   document in sequence order. If no index exists yet, generate one",
+    "   from `_template-category-README.md`.",
+    "",
+    "9. **Cross-link upstream.** Add `## Traceability` entries pointing",
+    "   to the proposals file (under `<RESEARCH_REQUIREMENTS_ROOT>`),",
+    "   the source documents the proposal cited, and any BCM capability",
+    "   the requirement supports.",
+    "",
+    "10. **Quality checks.** Before committing, verify:",
+    "    - [ ] Frontmatter has `title` and `description` (and `tier` if",
+    "          the project uses tier classification)",
+    "    - [ ] Title matches the `# Heading` line",
+    "    - [ ] File name follows `{PREFIX}-{NNN}-{slug}.md`",
+    "    - [ ] Status is `Draft` for direct-write categories or `Proposed`",
+    "          for ADR/TR",
+    "    - [ ] Every template section is present (use `TODO:` or `Not",
+    "          applicable \u2014 <reason>` for unfilled sections)",
+    "    - [ ] `## Traceability` exists with at least one upstream link",
+    "    - [ ] No technology decisions made in direct-write categories \u2014",
+    "          deferred to `Proposed` ADR/TR with cross-links in Open",
+    "          Items",
+    "    - [ ] `## Open Items` is present with Identified Gaps,",
+    "          Follow-up Questions, and Contradictions subsections",
+    "    - [ ] ADR/TR documents include a Recommendation section and an",
+    "          Open Item flagging the human decision required",
+    "    - [ ] Category index updated with a row for the new document",
+    "    - [ ] Tier value matches the issue's `tier:*` label",
+    "    - [ ] Cross-tier traceability entries exist where the document",
+    "          depends on or enables a different tier",
+    "",
+    "11. **Commit and push.** Use a `docs(<category>):` conventional",
+    "    commit message. The PR closes the `req:write` issue.",
+    "",
+    "---",
+    "",
+    "## Output Boundaries",
+    "",
+    "This agent writes **only** to:",
+    "",
+    "- `<REQUIREMENTS_ROOT>/<category-dir>/<PREFIX>-<NNN>-<slug>.md` \u2014 one",
+    "  requirement document per session",
+    "- `<REQUIREMENTS_ROOT>/<category-dir>/README.md` (or `_index.md`) \u2014",
+    "  category index, one row appended per session",
+    "- `<REQUIREMENTS_ROOT>/README.md` (or `_index.md`) \u2014 only if the",
+    "  top-level requirements README does not yet exist; generate from",
+    "  `_template-requirements-README.md` and stop",
+    "",
+    "The pipeline produces **requirement documents**. It does not write",
+    "BCM capability models, people profiles, company profiles, software",
+    "profiles, scan reports, or proposal files \u2014 those belong to",
+    "specialized upstream/downstream agents.",
+    "",
+    "**Do NOT create:**",
+    "- `req:scan`, `req:draft`, or `req:trace` issues \u2014 those belong to",
+    "  the `requirements-analyst` bundle",
+    "- `bcm:*` issues \u2014 those belong to the `bcm-writer` bundle",
+    "- `people:*`, `company:*`, `software:*`, `research:*`, or",
+    "  `industry:*` issues \u2014 those belong to their respective bundles",
+    "",
+    "If the proposal surfaces work that needs one of the above, comment",
+    "on the `req:write` issue with the suggested follow-up and let a",
+    "human route it.",
+    "",
+    "---",
+    "",
+    "## Coordination with Other Agents",
+    "",
+    "| Direction | Agent | What |",
+    "|-----------|-------|------|",
+    "| Upstream | `requirements-analyst` | Discovers gaps, drafts proposals, and creates `req:write` issues that this agent picks up |",
+    "| Upstream | `bcm-writer` | Provides BCM capability documents that requirements trace back to via `## Traceability` links |",
+    "| Peer | `meeting-analyst` | Provides meeting transcripts that may inform a requirement's traceability extensions (optional) |",
+    "",
+    "**File boundaries:** Reads `<RESEARCH_REQUIREMENTS_ROOT>` (proposals)",
+    "and the source documents the proposals cite. Writes",
+    "`<REQUIREMENTS_ROOT>` and the category index files. Never edits",
+    "proposals, scan reports, BCM documents, or profiles.",
+    "",
+    "---",
+    "",
+    "## Rules",
+    "",
+    "- **One requirement per session.** Never write two documents in one",
+    "  session and never start a second issue.",
+    "- **Templates are authoritative.** Use the shipped template verbatim",
+    "  for the category. Every template section must appear in the final",
+    "  document.",
+    "- **Decision authority is non-negotiable.** Direct-write categories",
+    "  ship as `Draft`. ADR and TR ship as `Proposed` with a Recommendation",
+    "  framed for human decision. Mixed-deferral categories spin",
+    "  technology choices off into separate `Proposed` documents.",
+    "- **Cite, don't invent.** When the proposal omits a stakeholder,",
+    "  metric, threat model entry, or technology option, write `TODO:` and",
+    "  flag the issue with `status:needs-attention`.",
+    "- **Trace upstream.** Every requirement links back to its proposal,",
+    "  the source documents the proposal cited, and the BCM capability",
+    "  it supports (when applicable).",
+    "- **Update the category index every time.** A requirement that",
+    "  exists as a file but is missing from its category index is",
+    "  invisible to anyone browsing the documentation tree.",
+    "- **Write requirements, not capability models or gap reports.**",
+    "  Never open `req:scan`, `req:draft`, `req:trace`, or `bcm:*` issues",
+    "  from this pipeline."
+  ].join("\n")
+};
+var writeRequirementSkill = {
+  name: "write-requirement",
+  description: "Write one formal requirement document (BR / FR / NFR / TR / ADR / SEC / DR / INT / OPS / UX / MT) using the shipped category template and decision-authority rules. Picks up a req:write issue created by the upstream requirements-analyst pipeline (or kicked off ad hoc) and dispatches the requirements-writer agent.",
+  disableModelInvocation: true,
+  userInvocable: true,
+  context: "fork",
+  agent: "requirements-writer",
+  platforms: { cursor: { exclude: true } },
+  referenceFiles: REQUIREMENTS_WRITER_REFERENCE_FILES,
+  instructions: [
+    "# Write Requirement",
+    "",
+    "Write one formal requirement document using the 11-category taxonomy",
+    "(BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT) and the",
+    "decision-authority rules (direct-write vs. propose-only ADR/TR).",
+    "Dispatches the `requirements-writer` agent.",
+    "",
+    "## Usage",
+    "",
+    "/write-requirement <category> <short-title>",
+    "",
+    "Where `<category>` is one of `BR`, `FR`, `NFR`, `TR`, `ADR`, `SEC`,",
+    "`DR`, `INT`, `OPS`, `UX`, `MT`.",
+    "",
+    "Optional extensions in the issue body:",
+    "- `tier: platform | industry | customer-workflow | consumer-app` \u2014",
+    "  the architectural tier (default: `platform`)",
+    "- `prefix: <PROJECT_PREFIX>` \u2014 override the default category prefix",
+    "  with a project-specific one declared in `docs/project-context.md`",
+    "- `customer: <link-or-slug>` \u2014 link the requirement to a customer",
+    "  profile (expected for Customer Workflow / Consumer Application",
+    "  tiers in projects that track customer profiles)",
+    "- `proposal: <path>` \u2014 pin the upstream proposal file under",
+    "  `<RESEARCH_REQUIREMENTS_ROOT>` (default: derived from the issue",
+    "  context)",
+    "- `output: <path>` \u2014 override the default Output Path",
+    "",
+    "## Default Paths",
+    "",
+    "If the project has no override in `docs/project-context.md` or",
+    "`agentConfig.rules`, outputs land under:",
+    "",
+    "- `docs/requirements/<category-dir>/<PREFIX>-<NNN>-<slug>.md`",
+    "- `docs/requirements/<category-dir>/README.md` (registry update)",
+    "- `docs/requirements/README.md` (top-level README, generated on",
+    "  first use only)",
+    "",
+    "Templates and the standards reference ship with this skill under",
+    "`_references/templates/` and `_references/standards-and-frameworks.md`.",
+    "",
+    "## Steps",
+    "",
+    "1. Create a `req:write` issue with `type:requirement`,",
+    "   `priority:medium`, `status:ready`, and the matching `tier:*` label.",
+    "   Body must include the category, tier, output path, and a pointer",
+    "   to the upstream proposal (or a direct user description if no",
+    "   proposals file exists).",
+    "2. Execute the write phase of the requirements-writer agent.",
+    "3. The agent writes one requirement document, updates the category",
+    "   index, opens a PR, and closes the issue.",
+    "",
+    "## Output",
+    "",
+    "- One requirement document under `<REQUIREMENTS_ROOT>` following the",
+    "  shipped category template, with `Status: Draft` for direct-write",
+    "  categories or `Status: Proposed` for ADR/TR",
+    "- A category-index row pointing at the new document",
+    "- (First-time only) a top-level requirements README derived from",
+    "  `_template-requirements-README.md`"
+  ].join("\n")
+};
+var requirementsWriterBundle = {
+  name: "requirements-writer",
+  description: "Requirements writer agent bundle. Authors formal requirement documents from upstream proposals using the 11-category taxonomy (BR, FR, NFR, TR, ADR, SEC, DR, INT, OPS, UX, MT), the four-tier classification, and decision-authority rules (direct-write vs. propose-only). Ships 13 templates plus a standards-and-frameworks reference.",
+  appliesWhen: () => true,
+  rules: [
+    {
+      name: "requirements-writer-workflow",
+      description: "Describes the requirements-writer pipeline, the req:write phase label, the four tier:* labels, and the boundary with the upstream requirements-analyst and bcm-writer bundles.",
+      scope: AGENT_RULE_SCOPE.ALWAYS,
+      content: [
+        "# Requirements Writer Workflow",
+        "",
+        "Use `/write-requirement <category> <short-title>` to author one",
+        "formal requirement document. The writer runs in a single phase",
+        "tracked by a GitHub issue labeled `req:write` plus the matching",
+        "`tier:*` label. Issues also carry `type:requirement` (declared",
+        "by the upstream `requirements-analyst` bundle).",
+        "",
+        "The pipeline produces **requirement documents only** \u2014 capability",
+        "models are written by the `bcm-writer` agent and gap discovery is",
+        "the responsibility of the `requirements-analyst` agent. The",
+        "writer never opens `req:scan`, `req:draft`, `req:trace`, or",
+        "`bcm:*` issues.",
+        "",
+        "Documents follow the 11-category taxonomy (BR, FR, NFR, TR, ADR,",
+        "SEC, DR, INT, OPS, UX, MT) and the four-tier classification",
+        "(Platform, Industry, Customer Workflow, Consumer Application).",
+        "Templates and a standards-and-frameworks reference ship with the",
+        "skill \u2014 they are the same files for every project that adopts",
+        "the bundle.",
+        "",
+        "Decision-authority rules are non-negotiable: BR / FR / NFR /",
+        "SEC / UX ship as `Status: Draft`; ADR and TR ship as",
+        "`Status: Proposed` with a Recommendation framed for human",
+        "decision; DR / MT / INT / OPS spin technology choices off into",
+        "separate `Proposed` ADR or TR documents.",
+        "",
+        "See the `requirements-writer` agent definition for full workflow",
+        "details, configurable paths, decision-authority rules, and",
+        "phase-by-phase instructions."
+      ].join("\n"),
+      platforms: {
+        cursor: { exclude: true }
+      },
+      tags: ["workflow"]
+    }
+  ],
+  skills: [writeRequirementSkill],
+  subAgents: [requirementsWriterSubAgent],
+  labels: [
+    {
+      name: "req:write",
+      color: "FEF2C0",
+      description: "Phase: write a formal requirement document using the requirements-writer skill"
+    },
+    {
+      name: "tier:platform",
+      color: "EDEDED",
+      description: "Architectural tier: core platform (shared infrastructure, APIs, auth, tenant isolation)"
+    },
+    {
+      name: "tier:industry",
+      color: "EDEDED",
+      description: "Architectural tier: industry vertical (capabilities not every tenant needs)"
+    },
+    {
+      name: "tier:customer-workflow",
+      color: "EDEDED",
+      description: "Architectural tier: customer-configured workflow (business logic tenants configure within the platform)"
+    },
+    {
+      name: "tier:consumer-app",
+      color: "EDEDED",
+      description: "Architectural tier: consumer application (UI/UX and integrations in external front-ends/systems)"
+    }
+  ]
+};
+
 // src/agent/bundles/research-pipeline.ts
 var researchAnalystSubAgent = {
   name: "research-analyst",
@@ -8326,6 +10960,7 @@ var BUILT_IN_BUNDLES = [
   orchestratorBundle,
   prReviewBundle,
   requirementsAnalystBundle,
+  requirementsWriterBundle,
   researchPipelineBundle,
   companyProfileBundle,
   peopleProfileBundle,
@@ -11805,6 +14440,7 @@ var TypeScriptConfig = class extends import_projen22.Component {
   prReviewBundle,
   projenBundle,
   requirementsAnalystBundle,
+  requirementsWriterBundle,
   researchPipelineBundle,
   resolveModelAlias,
   resolveTemplateVariables,