@rqml/schema 0.1.1 → 0.1.3

package/dist/index.js

@@ -1,5 +1,5 @@
 // templates/AGENTS.md
-var AGENTS_default = '# RQML Agent Guidelines\n\n## Strictness: `standard`\n\n| Level | Description |\n|-------|-------------|\n| `relaxed` | Prototyping. Spec is advisory. Quick iteration allowed. |\n| `standard` | Production default. Spec-first for features. Core traces. |\n| `strict` | Full traceability. All behavior specified. No ghost features. |\n| `certified` | Regulated/safety-critical. Audit-grade traces with metadata. |\n\n---\n\nThis project uses **RQML** as the single source of truth for system intent. Familiarize yourself with the documentation at https://rqml.org/docs/user-guide/\n\n**Specification file:** Specification lives in a single .rqml file in the root of the project - convention is `requirements.rqml`. Multiple .rqml files may be employed in multirepo projects, in such cases a .rqml spec applies to everything that is higher in the project tree, unless overridden by another .rqml file.\n\n**Schema file:**\nThe RQML XSD schema is at https://rqml.org/schema/rqml-2.1.0.xsd (insert correct version number). Make sure to adhere to the schema at all times and follow guidelines in schema comments. Use as much of the RQML tagset as is necessary to capture and describe high quality requirements.\n\n---\n\n## Toolchain\n\nThe spec-first loop is enforced by the `rqml` CLI (npm: `@rqml/cli`; the `@rqml/mcp` server exposes the same engine as agent tools):\n\n```bash\nrqml check                 # deterministic gate: validation + coverage + drift (exit 0 = pass)\nrqml status                # re-anchor: spec, coverage, and drift state\nrqml show <REQ-ID>         # one requirement: statement, acceptance criteria, trace neighborhood\nrqml impact <ID>           # what is affected, transitively, if this artifact changes\nrqml link <REQ-ID> <path>  # record an implements edge + drift baseline (--type verifiedBy for tests)\nrqml skeleton <kind>       # schema-valid snippet: req | edge | testCase | stateMachine\n```\n\nRun `rqml status` when you start a session to re-anchor on the spec. Run `rqml check` before finishing any task \u2014 it must exit 0.\n\n---\n\n## Core Principle: Spec-First Development\n\n```\n[Elicit] \u2192 [Specify] \u2192 [Implement] \u2192 [Verify] \u2192 [Trace]\n    \u2191____________________\u2190______________________|\n```\n\nCode follows specification, not the reverse. If code and spec diverge, the spec is authoritative\u2014update the code or negotiate a spec change with the developer.\n\n---\n\n## Workflow\n\n### 1. Elicit\nAsk clarifying questions until you understand the goal, scope, acceptance criteria, and constraints. Don\'t assume\u2014capture assumptions as `<notes>` or `<issue>` elements.\n\n### 2. Specify\n**Never implement unspecified behavior.** Update the `.rqml` file before coding:\n- Add a `<req>` with statement and acceptance criteria\n- Set appropriate `type`, `priority`, and `status="draft"`\n- Get developer confirmation before proceeding\n\n### 3. Implement\nRead the requirement first: `rqml show REQ-XXX`. Check blast radius before changing existing artifacts: `rqml impact REQ-XXX`. If you discover missing requirements, stop and add them to the spec first. After implementing, record the trace link:\n\n```bash\nrqml link REQ-XXX src/path/to/implementation.ts\n```\n\n### 4. Verify\nAdd tests that reference requirement IDs, then record verification:\n\n```bash\nrqml link REQ-XXX test/path/to/test.ts --type verifiedBy\nrqml check   # must exit 0 before you are done\n```\n\n---\n\n## When Code and Spec Diverge\n\n1. **Spec gap** (code has behavior not in spec): Propose adding the requirement, mark as `status="review"`\n2. **Code bug** (code doesn\'t match spec): Fix the code\n3. **Spec bug** (spec is wrong): Propose correction, wait for developer confirmation\n\n**Never silently change the spec to match code.**\n\n---\n\n## Strictness Reference\n\n| Aspect | relaxed | standard | strict | certified |\n|--------|---------|----------|--------|-----------|\n| Elicitation | Major features | Testable reqs | Edge cases | Formal |\n| Spec-first | Recommended | Required | Required | Approved first |\n| Code traces | Optional | New features | All changes | With metadata |\n| Test traces | Optional | New reqs | All reqs | Full matrix |\n| Ghost features | Allowed | Blocked | Blocked | Blocked |\n\n---\n\n## Change Summary Template\n\nFor PRs and commits:\n\n```\n## RQML Trace Summary\n\n**Requirements:** REQ-xxx (added/modified/implemented)\n**Implementation:** `path/to/file` \u2014 what changed\n**Verification:** `path/to/test` \u2014 what it verifies\n**Open items:** gaps, assumptions, follow-ups\n```\n\n---\n\n## Schema Validation\n\nThe `.rqml` file must remain valid XML conforming to the version of RQML referenced in the version attribute in the spec document.\n\n**To validate:** Use the toolchain \u2014 it validates offline against the bundled schema and also checks referential integrity the XSD alone cannot enforce:\n```bash\nrqml validate\n```\n\nIf the `rqml` CLI is not installed, `npx @rqml/cli validate` works without installation. As a last resort, xmllint (pre-installed on macOS/Linux) checks XSD validity only:\n```bash\nxmllint --schema https://rqml.org/schema/rqml-2.1.0.xsd <rqml-file-name> --noout\n```\n\n**IDE validation:** If the `.rqml` file includes `xsi:schemaLocation`, XML-aware editors (VS Code with XML extension, IntelliJ) validate automatically.\n\nThe schema comments contain detailed guidance on document structure, ID conventions, and requirement quality criteria.\n\n**If unsure:** Ask the developer before making structural changes to the spec.\n';
+var AGENTS_default = '# RQML Agent Guidelines\n\n## Strictness: `standard`\n\n| Level | Description |\n|-------|-------------|\n| `relaxed` | Prototyping. Spec is advisory. Quick iteration allowed. |\n| `standard` | Production default. Spec-first for features. Core traces. |\n| `strict` | Full traceability. All behavior specified. No ghost features. |\n| `certified` | Regulated/safety-critical. Audit-grade traces with metadata. |\n\n---\n\nThis project uses **RQML** as the single source of truth for system intent. Familiarize yourself with the documentation at https://rqml.org/docs/user-guide/ and the development process at https://rqml.org/docs/development-process/\n\n**Specification file:** Specification lives in a single .rqml file in the root of the project - convention is `requirements.rqml`. Multiple .rqml files may be employed in multirepo projects, in such cases a .rqml spec applies to everything that is higher in the project tree, unless overridden by another .rqml file.\n\n**Schema file:**\nThe RQML XSD schema is at https://rqml.org/schema/rqml-2.1.0.xsd (insert correct version number). Make sure to adhere to the schema at all times and follow guidelines in schema comments. Use as much of the RQML tagset as is necessary to capture and describe high quality requirements.\n\n---\n\n## Toolchain\n\nThe spec-first loop is enforced by the `rqml` CLI (npm: `@rqml/cli`; the `@rqml/mcp` server exposes the same engine as agent tools):\n\n```bash\nrqml check                 # deterministic gate: validation + coverage + drift (exit 0 = pass)\nrqml status                # re-anchor: spec, coverage, and drift state\nrqml show <REQ-ID>         # one requirement: statement, acceptance criteria, trace neighborhood\nrqml impact <ID>           # what is affected, transitively, if this artifact changes\nrqml overview              # readable projection of the spec (--section/--id to scope)\nrqml matrix                # traceability matrix: status, goals, code, tests, coverage gaps\nrqml link <REQ-ID> <path>  # record an implements edge + drift baseline (--type verifiedBy for tests)\nrqml approve <REQ-ID>      # transition a requirement\'s status (default approved)\nrqml gate                  # block implementation of non-approved requirements\nrqml skeleton <kind>       # schema-valid snippet: req | edge | testCase | stateMachine\n```\n\nRun `rqml status` when you start a session to re-anchor on the spec. Run `rqml check` before finishing any task \u2014 it must exit 0.\n\n---\n\n## Core Principle: Spec-First Development\n\nCode follows specification, not the reverse. If code and spec diverge, the spec is authoritative\u2014update the code or negotiate a spec change with the developer.\n\nRQML organizes work into a **five-stage process** (https://rqml.org/docs/development-process/). Each stage produces a durable artifact in version control; verification feeds back to the spec, so it is a loop:\n\n| Stage | Task | Output |\n|-------|------|--------|\n| **Spec** | Capture intent as requirements | `requirements.rqml` |\n| **Design** | Decide architecture, record decisions | ADRs in `.rqml/adr/` |\n| **Plan** | Break work into agent-sized stages | `.rqml/plan.md` |\n| **Code** | Implement specified behavior, keep traces current | code + tests |\n| **Verify** | Prove coverage and catch drift | trace graph + `rqml check` |\n\nNever skip ahead: do not implement behavior that is not specified, and do not make a significant architectural choice without recording it as an ADR.\n\n---\n\n## Workflow\n\n### 1. Spec\nAsk clarifying questions until you understand the goal, scope, acceptance criteria, and constraints. Don\'t assume\u2014capture assumptions as `<notes>` or `<issue>` elements. **Never implement unspecified behavior.** Update the `.rqml` file before coding:\n- Add a `<req>` with statement and acceptance criteria\n- Set appropriate `type`, `priority`, and `status="draft"`\n- Get developer confirmation; only `status="approved"` requirements drive implementation\n\n### 2. Design\nBefore building, decide *how*. Record each significant architectural decision as an **Architecture Decision Record (ADR)** in `.rqml/adr/`, following the canonical format (https://rqml.org/docs/development-process/design): `NNNN-kebab-case-slug.md`, with Status, Classification, Context, Options considered, Decision, and Consequences. A decision is ADR-worthy when there are real alternatives or the choice constrains future work; skip ADRs for low-level implementation details. ADRs are immutable once accepted\u2014supersede, don\'t edit.\n\n### 3. Plan\nBreak approved requirements into a staged implementation plan at `.rqml/plan.md`, framed for coding agents: each stage names its goal, the requirement IDs it addresses, the files it touches, and how to verify it.\n\n### 4. Code (Implement)\nRead the requirement first: `rqml show REQ-XXX`. Check blast radius before changing existing artifacts: `rqml impact REQ-XXX`. Honor the ADRs. If you discover missing requirements, stop and add them to the spec first. After implementing, record the trace link:\n\n```bash\nrqml link REQ-XXX src/path/to/implementation.ts\n```\n\n### 5. Verify\nAdd tests that reference requirement IDs, then record verification and run the gate:\n\n```bash\nrqml link REQ-XXX test/path/to/test.ts --type verifiedBy\nrqml check   # must exit 0 before you are done\n```\n\n---\n\n## When Code and Spec Diverge\n\n1. **Spec gap** (code has behavior not in spec): Propose adding the requirement, mark as `status="review"`\n2. **Code bug** (code doesn\'t match spec): Fix the code\n3. **Spec bug** (spec is wrong): Propose correction, wait for developer confirmation\n\n**Never silently change the spec to match code.**\n\n---\n\n## Strictness Reference\n\n| Aspect | relaxed | standard | strict | certified |\n|--------|---------|----------|--------|-----------|\n| Spec (elicitation) | Major features | Testable reqs | Edge cases | Formal |\n| Spec-first | Recommended | Required | Required | Approved first |\n| Design (ADRs) | Optional | Significant choices | All architectural choices | With approval |\n| Plan | Optional | For multi-stage work | Required | Required |\n| Code traces | Optional | New features | All changes | With metadata |\n| Verify (test traces) | Optional | New reqs | All reqs | Full matrix |\n| Ghost features | Allowed | Blocked | Blocked | Blocked |\n\n---\n\n## Change Summary Template\n\nFor PRs and commits:\n\n```\n## RQML Trace Summary\n\n**Requirements:** REQ-xxx (added/modified/implemented)\n**Design:** ADR-xxxx \u2014 decision recorded (if any)\n**Implementation:** `path/to/file` \u2014 what changed\n**Verification:** `path/to/test` \u2014 what it verifies\n**Open items:** gaps, assumptions, follow-ups\n```\n\n---\n\n## Schema Validation\n\nThe `.rqml` file must remain valid XML conforming to the version of RQML referenced in the version attribute in the spec document.\n\n**To validate:** Use the toolchain \u2014 it validates offline against the bundled schema and also checks referential integrity the XSD alone cannot enforce:\n```bash\nrqml validate\n```\n\nIf the `rqml` CLI is not installed, `npx @rqml/cli validate` works without installation. As a last resort, xmllint (pre-installed on macOS/Linux) checks XSD validity only:\n```bash\nxmllint --schema https://rqml.org/schema/rqml-2.1.0.xsd <rqml-file-name> --noout\n```\n\n**IDE validation:** If the `.rqml` file includes `xsi:schemaLocation`, XML-aware editors (VS Code with XML extension, IntelliJ) validate automatically.\n\nThe schema comments contain detailed guidance on document structure, ID conventions, and requirement quality criteria.\n\n**If unsure:** Ask the developer before making structural changes to the spec.\n';
 
 // versions/2.0.1/rqml-2.0.1.xsd
 var rqml_2_0_1_default = '<!--\n  RQML (Requirements Markup Language) Schema v2.0.1\n  =================================================\n\n  PURPOSE\n  =======\n  RQML is an XML-based format for capturing software requirements in a structured,\n  machine-readable way. It is designed for LLM-native workflows where:\n\n  1. Requirements are the primary artifact (not code)\n  2. LLMs use requirements to generate and validate implementations\n  3. Traceability from goals to tests is explicit and queryable\n  4. Human collaboration happens on intent; implementation is derived\n\n  FOR LLMs: REQUIREMENTS ELICITATION\n  ==================================\n  When helping users write RQML documents:\n\n  - Start with `meta` (required): capture document identity, ownership, and conventions\n  - Add `catalogs` early: define glossary terms, actors, stakeholders, constraints, and\n    risks to establish shared vocabulary and reduce ambiguity in requirements\n  - Use `domain` to model key entities and business rules that requirements reference\n  - Capture `goals` to document WHY the system exists (business objectives, quality goals)\n  - Write `scenarios` to describe HOW users interact with the system (use cases, misuse cases)\n  - Derive `requirements` from goals and scenarios - each requirement should be:\n    * Necessary (traces to a goal or stakeholder need)\n    * Verifiable (has acceptance criteria or can be tested)\n    * Unambiguous (single interpretation)\n    * Feasible (technically achievable)\n  - Use `behavior` to formalize entity lifecycles as state machines (derived from requirements)\n  - Document `interfaces` for system boundaries (APIs, events)\n  - Add `verification` to define how requirements are tested\n  - Create `trace` edges to link artifacts for impact analysis\n  - Use `governance` for approval workflows and open issues\n\n  FOR LLMs: CODE GENERATION\n  =========================\n  When generating code from RQML documents:\n\n  - Read `domain/entities` for data models (classes, database schemas, types)\n  - Read `domain/businessRules` for validation logic and constraints\n  - Read `behavior/stateMachine` for state enums, transition logic, and lifecycle validation\n  - Read `requirements` with type="FR" for features to implement\n  - Read `requirements` with type="NFR" for quality attributes (performance, reliability)\n  - Read `requirements` with type="IR" for API contracts and integrations\n  - Read `requirements` with type="DR" for data validation rules\n  - Read `requirements` with type="SR" for security controls\n  - Read `interfaces/api/endpoint` for REST/HTTP endpoint implementations\n  - Read `interfaces/event` for event handlers and message schemas\n  - Use `acceptance/criterion` (given/when/then) for test case generation\n  - Check `trace` edges with type="implements" for code-to-requirement mapping\n\n  DOCUMENT STRUCTURE (in order)\n  =============================\n  1. meta (REQUIRED) - Document identity and metadata\n  2. catalogs - Shared definitions: glossary, actors, stakeholders, constraints, policies, decisions, risks\n  3. domain - Problem space: entities, attributes, business rules\n  4. goals - Objectives: business goals, quality goals, obstacles, goal links\n  5. scenarios - User journeys: use cases, misuse cases, edge cases\n  6. requirements (REQUIRED) - Normative statements: packages and individual requirements\n  7. behavior - State machines: formalized entity lifecycles derived from requirements\n  8. interfaces - System boundaries: APIs, endpoints, events\n  9. verification - Testing: test suites and test cases\n  10. trace - Traceability: edges linking all artifacts\n  11. governance - Change control: issues and approvals\n\n  ID CONVENTIONS\n  ==============\n  All IDs must be unique within the document. Recommended patterns:\n  - Requirements: REQ-<AREA>-NNN (e.g., REQ-AUTH-001)\n  - Goals: GOAL-<AREA>-NNN (e.g., GOAL-AVAIL-001)\n  - Quality Goals: QGOAL-<NAME> (e.g., QGOAL-LATENCY)\n  - Test Cases: TC-<NAME>-NNN (e.g., TC-AUTH-001)\n  - Entities: ENT-<NAME> (e.g., ENT-PAYMENT)\n  - Actors: ACT-<NAME> (e.g., ACT-USER)\n  - Stakeholders: STK-<NAME> (e.g., STK-RISK)\n  - Scenarios: SCN-<NAME> (e.g., SCN-CHECKOUT)\n  - Risks: RISK-<NAME> (e.g., RISK-FRAUD)\n  - Decisions: DEC-<NAME> (e.g., DEC-IDEMPOTENCY)\n  - State Machines: SM-<NAME> (e.g., SM-ORDER)\n  - States: ST-<NAME> (e.g., ST-PENDING, ST-CONFIRMED)\n  - Transitions: TR-<NAME> (e.g., TR-CONFIRM, TR-SHIP)\n\n  STANDARDS ALIGNMENT\n  ===================\n  RQML aligns with requirements engineering best practices from:\n  - IEEE 29148-2018: Systems and software engineering - Life cycle processes - Requirements engineering\n  - ISO/IEC 25010: Systems and software quality models\n  - KAOS/i* goal-oriented RE frameworks\n  - Volere requirements template\n  - BDD/Gherkin for acceptance criteria\n\n  NAMESPACE: https://rqml.org/schema/2.0.1\n-->\n<xs:schema\n  xmlns:xs="http://www.w3.org/2001/XMLSchema"\n  targetNamespace="https://rqml.org/schema/2.0.1"\n  xmlns="https://rqml.org/schema/2.0.1"\n  elementFormDefault="qualified"\n  attributeFormDefault="unqualified"\n  version="2.0.1">\n\n  <!-- =========================\n       Simple types\n\n       These define the controlled vocabularies and value constraints\n       used throughout RQML. LLMs should use these exact values.\n       ========================= -->\n\n  <!--\n    IdType: Identifier format for all referenceable elements\n\n    Pattern: Start with letter, followed by letters, digits, dots, underscores, or hyphens\n    Length: 2-80 characters\n\n    EXAMPLES:\n    - REQ-AUTH-001 (requirement)\n    - GOAL-AVAIL (goal)\n    - ENT-PAYMENT (entity)\n    - ACT-USER (actor)\n    - TC-LOGIN-001 (test case)\n\n    FOR LLMs: When creating IDs, use descriptive prefixes that indicate the element type,\n    followed by a meaningful name or area, optionally with a sequence number.\n    Keep IDs stable across document revisions for traceability.\n  -->\n  <xs:simpleType name="IdType">\n    <xs:restriction base="xs:token">\n      <!-- Human-friendly IDs like REQ-LOGIN-001, GOAL_AUTH_01, TC-001 -->\n      <xs:pattern value="[A-Za-z][A-Za-z0-9._-]*"/>\n      <xs:minLength value="2"/>\n      <xs:maxLength value="80"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    StatusType: Lifecycle state of requirements, goals, decisions, and other artifacts\n\n    VALUES:\n    - draft: Initial state; content is incomplete or unreviewed\n    - review: Under stakeholder review; awaiting feedback or approval\n    - approved: Formally accepted; ready for implementation\n    - deprecated: No longer active; kept for historical reference\n\n    FOR LLMs:\n    - When eliciting requirements, start with status="draft"\n    - Only requirements with status="approved" should drive implementation\n    - Deprecated items should not be implemented but may explain historical decisions\n  -->\n  <xs:simpleType name="StatusType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="draft"/>\n      <xs:enumeration value="review"/>\n      <xs:enumeration value="approved"/>\n      <xs:enumeration value="deprecated"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    PriorityType: MoSCoW-style priority for requirements and goals\n\n    VALUES (from RFC 2119 / IEEE 29148):\n    - must: Mandatory; system is unacceptable without this. Non-negotiable for MVP.\n    - should: Important; system is diminished without this. Include if feasible.\n    - may: Optional; nice to have. Include if time/budget permits.\n\n    FOR LLMs:\n    - When generating code, implement all "must" requirements first\n    - "should" requirements are strong candidates for the implementation\n    - "may" requirements can be deferred or simplified\n    - When eliciting, ask stakeholders to prioritize ruthlessly - too many "must" items\n      indicates poor prioritization\n  -->\n  <xs:simpleType name="PriorityType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="must"/>\n      <xs:enumeration value="should"/>\n      <xs:enumeration value="may"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    ReqType: Classification of requirement types\n\n    This taxonomy helps organize requirements and determines how they should be\n    implemented and verified. Each type has distinct characteristics:\n\n    VALUES:\n    - FR (Functional Requirement): What the system must DO\n      * Features, behaviors, business functions, use case realizations\n      * Example: "The system SHALL allow users to reset their password via email"\n      * Code: Application logic, controllers, services, business rules\n\n    - NFR (Non-Functional Requirement): How WELL the system must perform\n      * Quality attributes: performance, reliability, scalability, usability, maintainability\n      * Example: "The API SHALL respond within 200ms for 95th percentile requests"\n      * Code: Caching, indexing, async processing, architecture decisions\n\n    - IR (Interface Requirement): Contracts with external systems\n      * APIs, protocols, message formats, integration points\n      * Example: "The system SHALL expose a REST API conforming to OpenAPI 3.0"\n      * Code: API controllers, serializers, protocol handlers, SDK clients\n\n    - DR (Data Requirement): Data structure and handling rules\n      * Data models, validation, retention, privacy classification\n      * Example: "Payment card numbers SHALL be stored encrypted using AES-256"\n      * Code: Database schemas, models, validators, data access layers\n\n    - SR (Security Requirement): Security controls and protections\n      * Authentication, authorization, encryption, audit logging, threat mitigations\n      * Example: "The system SHALL enforce MFA for administrative operations"\n      * Code: Auth middleware, encryption utilities, audit loggers, security filters\n\n    - CR (Constraint Requirement): Hard limits on the solution space\n      * Technology mandates, platform requirements, standards compliance\n      * Example: "The system SHALL run on Kubernetes 1.28+"\n      * Code: Deployment configurations, technology choices, compatibility layers\n\n    - PR (Policy/Compliance Requirement): Regulatory and policy obligations\n      * GDPR, HIPAA, PCI-DSS, SOX, internal policies\n      * Example: "The system SHALL retain audit logs for 7 years per SOX requirements"\n      * Code: Compliance features, audit trails, data retention, reporting\n\n    - UXR (User Experience Requirement): UI and interaction expectations\n      * Accessibility, internationalization, content, visual design, user flows\n      * Example: "The application SHALL meet WCAG 2.1 Level AA accessibility"\n      * Code: UI components, accessibility attributes, i18n, responsive design\n\n    - OR (Operational Requirement): Run and maintain the system\n      * Monitoring, logging, alerting, backups, disaster recovery, runbooks\n      * Example: "The system SHALL emit structured logs to the central logging platform"\n      * Code: Logging configuration, metrics endpoints, health checks, backup scripts\n\n    FOR LLMs:\n    - When eliciting requirements, ensure coverage across relevant types\n    - FR requirements are the primary drivers of application code\n    - NFR requirements shape architecture and infrastructure\n    - Use the type to determine which team or component owns implementation\n  -->\n  <xs:simpleType name="ReqType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="FR"/>\n      <xs:enumeration value="NFR"/>\n      <xs:enumeration value="IR"/>\n      <xs:enumeration value="DR"/>\n      <xs:enumeration value="SR"/>\n      <xs:enumeration value="CR"/>\n      <xs:enumeration value="PR"/>\n      <xs:enumeration value="UXR"/>\n      <xs:enumeration value="OR"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    TraceType: Relationship types for traceability links between artifacts\n\n    Traceability enables impact analysis ("what breaks if this changes?") and\n    coverage analysis ("is this goal satisfied?"). Choose the most specific type.\n\n    VALUES:\n    - refines: Source provides more detail for target (goal decomposition)\n      * Example: Sub-goal refines parent goal; detailed req refines high-level req\n      * Direction: child -> parent (more specific refines less specific)\n\n    - satisfies: Source fulfills or achieves the target\n      * Example: Requirement satisfies goal; implementation satisfies requirement\n      * Direction: solution -> need (what satisfies why)\n\n    - dependsOn: Source requires target to function\n      * Example: Feature depends on infrastructure; requirement depends on constraint\n      * Direction: dependent -> dependency (what needs what)\n\n    - conflictsWith: Source and target cannot both be fully achieved\n      * Example: Performance goal conflicts with detailed logging goal\n      * Direction: bidirectional (both conflict with each other)\n\n    - threatens: Source poses risk to achieving target\n      * Example: Obstacle threatens goal; risk threatens requirement\n      * Direction: threat -> threatened (what endangers what)\n\n    - mitigates: Source reduces the impact or likelihood of target threat\n      * Example: Requirement mitigates risk; control mitigates obstacle\n      * Direction: mitigation -> threat (what addresses what)\n\n    - verifiedBy: Source is validated by target test/inspection\n      * Example: Requirement verifiedBy test case\n      * Direction: requirement -> verification (what is proven by what)\n\n    - covers: Source test addresses target requirement/scenario\n      * Example: Test case covers requirement; test suite covers scenario\n      * Direction: test -> requirement (what validates what)\n\n    - implements: Source code/component realizes target requirement\n      * Example: Module implements requirement (reserved for tooling)\n      * Direction: implementation -> requirement\n      * NOTE: This type is primarily for downstream tools that track code-to-requirement mapping\n\n    - supersedes: Source replaces target (for deprecation/versioning)\n      * Example: REQ-AUTH-002 supersedes REQ-AUTH-001 after security audit\n      * Direction: replacement -> deprecated (new replaces old)\n      * Use when archiving requirements: mark old as deprecated, link new via supersedes\n\n    FOR LLMs:\n    - Use trace edges to answer "why does this exist?" (follow satisfies/refines up)\n    - Use trace edges to answer "what depends on this?" (follow dependsOn/implements down)\n    - When generating code, create implements edges to maintain traceability\n    - When writing tests, create verifiedBy/covers edges to requirements\n  -->\n  <xs:simpleType name="TraceType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="refines"/>\n      <xs:enumeration value="satisfies"/>\n      <xs:enumeration value="dependsOn"/>\n      <xs:enumeration value="conflictsWith"/>\n      <xs:enumeration value="threatens"/>\n      <xs:enumeration value="mitigates"/>\n      <xs:enumeration value="verifiedBy"/>\n      <xs:enumeration value="covers"/>\n      <!-- reserved for downstream tooling -->\n      <xs:enumeration value="implements"/>\n      <!-- lifecycle management -->\n      <xs:enumeration value="supersedes"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    TestType: Classification of verification activities\n\n    Different test types validate different aspects of the system and run at\n    different phases of development.\n\n    VALUES:\n    - acceptance: Validates business requirements from user perspective\n      * Typically derived from acceptance criteria (given/when/then)\n      * Stakeholder-facing; often automated as end-to-end tests\n      * Example: "User can complete checkout flow"\n\n    - integration: Validates interactions between components/systems\n      * Tests API contracts, database interactions, external service calls\n      * Example: "Payment service correctly calls bank API"\n\n    - unit: Validates individual functions/methods/classes in isolation\n      * Fast, numerous, developer-facing\n      * Example: "calculateTotal returns correct sum with discounts"\n\n    - security: Validates security controls and identifies vulnerabilities\n      * Penetration testing, vulnerability scanning, auth testing\n      * Example: "SQL injection attempts are blocked"\n\n    - performance: Validates speed, throughput, and resource usage\n      * Load testing, stress testing, benchmarking\n      * Example: "System handles 1000 concurrent users with <500ms response"\n\n    - inspection: Manual review or audit (non-automated verification)\n      * Code review, design review, compliance audit\n      * Example: "Security architect reviews authentication design"\n\n    FOR LLMs:\n    - Generate acceptance tests from requirement acceptance criteria\n    - Generate unit tests for individual functions in generated code\n    - Generate integration tests for API endpoints and external calls\n    - Map NFR requirements to performance tests\n    - Map SR requirements to security tests\n  -->\n  <xs:simpleType name="TestType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="acceptance"/>\n      <xs:enumeration value="integration"/>\n      <xs:enumeration value="unit"/>\n      <xs:enumeration value="security"/>\n      <xs:enumeration value="performance"/>\n      <xs:enumeration value="inspection"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    ConfidenceType: Probability/certainty level for trace links and estimates\n\n    Range: 0.0 to 1.0 (0% to 100% confidence)\n\n    INTERPRETATION:\n    - 1.0: Certain; formally verified or definitionally true\n    - 0.8-0.99: High confidence; strong evidence or expert judgment\n    - 0.5-0.79: Medium confidence; reasonable belief with some uncertainty\n    - 0.2-0.49: Low confidence; tentative or speculative\n    - 0.0-0.19: Very low confidence; placeholder or assumption needing validation\n\n    FOR LLMs:\n    - Use confidence on trace edges to indicate strength of relationship\n    - Lower confidence links should be flagged for stakeholder review\n    - When eliciting, ask about confidence when relationships are uncertain\n    - When analyzing impact, weight changes by confidence of affected links\n  -->\n  <xs:simpleType name="ConfidenceType">\n    <xs:restriction base="xs:decimal">\n      <xs:minInclusive value="0.0"/>\n      <xs:maxInclusive value="1.0"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!--\n    StateKindType: Classification of states in a state machine\n\n    VALUES:\n    - initial: The starting state; exactly one per state machine\n    - normal: Regular intermediate state (default)\n    - final: Terminal state; no outgoing transitions allowed\n\n    FOR LLMs:\n    - Every state machine must have exactly one initial state\n    - Final states represent completed lifecycles\n    - Normal states are the default; omit the attribute for normal states\n  -->\n  <xs:simpleType name="StateKindType">\n    <xs:restriction base="xs:token">\n      <xs:enumeration value="initial"/>\n      <xs:enumeration value="normal"/>\n      <xs:enumeration value="final"/>\n    </xs:restriction>\n  </xs:simpleType>\n\n  <!-- =========================\n       Reusable complex types\n\n       Building blocks used by multiple sections of the schema.\n       ========================= -->\n\n  <!--\n    TextBlockType: Rich text content container\n\n    Allows mixed content (text with embedded elements) for descriptions,\n    statements, rationales, and other narrative content.\n\n    FOR LLMs:\n    - Can contain plain text or simple markup\n    - Use for any prose content: descriptions, rationales, notes\n    - Keep content concise but complete\n    - In statements, use normative language: "SHALL", "SHOULD", "MAY" (RFC 2119)\n  -->\n  <xs:complexType name="TextBlockType" mixed="true">\n    <xs:sequence>\n      <xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    RefType: Single reference to another element by ID\n\n    Used to create links between elements (e.g., requirement references a goal).\n    The @ref attribute must contain a valid IdType that exists in the document.\n\n    FOR LLMs: Always verify that referenced IDs exist in the document.\n  -->\n  <xs:complexType name="RefType">\n    <xs:attribute name="ref" type="IdType" use="required"/>\n  </xs:complexType>\n\n  <!--\n    RefsType: Collection of references to other elements\n\n    Container for multiple ref elements, used when an artifact relates to\n    several other artifacts (e.g., a requirement linked to multiple goals).\n  -->\n  <xs:complexType name="RefsType">\n    <xs:sequence>\n      <xs:element name="ref" type="RefType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!-- =========================\n       Root Element\n\n       The rqml element is the document root. It enforces:\n       1. Required version and document identity\n       2. Unique IDs across all elements (via xs:key)\n       3. Referential integrity for trace edges (via xs:keyref)\n       ========================= -->\n\n  <!--\n    rqml: Root element of an RQML document\n\n    REQUIRED ATTRIBUTES:\n    - version: Schema version (fixed at "2.0.1")\n    - docId: Unique document identifier; keep stable across revisions\n    - status: Document lifecycle state (draft/review/approved/deprecated)\n\n    STRUCTURE:\n    Contains sections in fixed order: meta, catalogs?, domain?, goals?,\n    scenarios?, requirements, behavior?, interfaces?, verification?, trace?, governance?\n\n    CONSTRAINTS:\n    - All @id attributes must be unique within the document\n    - All trace edge @from and @to must reference existing IDs\n\n    FOR LLMs:\n    - Always include xmlns="https://rqml.org/schema/2.0.1"\n    - Start documents with status="draft" during elicitation\n    - Use a meaningful docId that identifies the system/project\n  -->\n  <xs:element name="rqml" type="RqmlDocumentType">\n\n    <!-- Ensure IDs are unique across the document -->\n    <xs:key name="allIds">\n      <xs:selector xpath=".//profile|.//term|.//actor|.//stakeholder|.//constraint|.//policy|.//decision|.//risk|.//entity|.//attr|.//rule|.//stateMachine|.//state|.//transition|.//goal|.//qgoal|.//obstacle|.//goalLink|.//scenario|.//misuseCase|.//edgeCase|.//reqPackage|.//req|.//criterion|.//api|.//endpoint|.//event|.//testSuite|.//testCase|.//traceEdge|.//issue|.//approval"/>\n      <xs:field xpath="@id"/>\n    </xs:key>\n\n    <!-- Trace edges: internal refs (from/to) must point to declared ids.\n         External refs (fromUri/toUri) are not validated by schema.\n         Keyrefs only fire when the attribute is present. -->\n    <xs:keyref name="traceFromRef" refer="allIds">\n      <xs:selector xpath=".//traceEdge"/>\n      <xs:field xpath="@from"/>\n    </xs:keyref>\n    <xs:keyref name="traceToRef" refer="allIds">\n      <xs:selector xpath=".//traceEdge"/>\n      <xs:field xpath="@to"/>\n    </xs:keyref>\n\n    <!-- State machine initial state must reference a declared state -->\n    <xs:keyref name="smInitialRef" refer="allIds">\n      <xs:selector xpath=".//stateMachine"/>\n      <xs:field xpath="@initial"/>\n    </xs:keyref>\n\n    <!-- Transition from/to must reference declared states -->\n    <xs:keyref name="transitionFromRef" refer="allIds">\n      <xs:selector xpath=".//transition"/>\n      <xs:field xpath="@from"/>\n    </xs:keyref>\n    <xs:keyref name="transitionToRef" refer="allIds">\n      <xs:selector xpath=".//transition"/>\n      <xs:field xpath="@to"/>\n    </xs:keyref>\n\n  </xs:element>\n\n  <!--\n    RqmlDocumentType: Structure of the complete RQML document\n\n    Defines the top-level sections in their required order.\n    Only `meta` and `requirements` are mandatory; others are optional\n    but recommended for complete specifications.\n  -->\n  <xs:complexType name="RqmlDocumentType">\n    <xs:sequence>\n      <xs:element name="meta" type="MetaType"/>\n      <xs:element name="catalogs" type="CatalogsType" minOccurs="0"/>\n      <xs:element name="domain" type="DomainType" minOccurs="0"/>\n      <xs:element name="goals" type="GoalsType" minOccurs="0"/>\n      <xs:element name="scenarios" type="ScenariosType" minOccurs="0"/>\n      <xs:element name="requirements" type="RequirementsType"/>\n      <xs:element name="behavior" type="BehaviorType" minOccurs="0"/>\n      <xs:element name="interfaces" type="InterfacesType" minOccurs="0"/>\n      <xs:element name="verification" type="VerificationType" minOccurs="0"/>\n      <xs:element name="trace" type="TraceTypeContainer" minOccurs="0"/>\n      <xs:element name="governance" type="GovernanceType" minOccurs="0"/>\n    </xs:sequence>\n\n    <xs:attribute name="version" type="xs:token" use="required" fixed="2.0.1"/>\n    <xs:attribute name="docId" type="IdType" use="required"/>\n    <xs:attribute name="status" type="StatusType" use="required"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Meta Section\n\n       Document identity, ownership, and conventions. Required section that\n       must appear first. Establishes provenance and change control context.\n\n       FOR LLMs:\n       - Always populate title and system\n       - Use conventions to establish ID patterns and normative keywords\n       - Track updates in dates/updated for change management\n       - Use profiles for domain-specific customizations\n       ========================= -->\n\n  <!--\n    MetaType: Document metadata container\n\n    REQUIRED CHILDREN:\n    - title: Human-readable document name\n    - system: Name/code of the system being specified\n\n    OPTIONAL CHILDREN:\n    - summary: Overview of scope and purpose\n    - authors: Who wrote/owns this document\n    - dates: Creation, update, and release timing\n    - conventions: Rules for IDs and normative language\n    - profiles: Domain-specific customizations\n  -->\n  <xs:complexType name="MetaType">\n    <xs:sequence>\n      <xs:element name="title" type="xs:string"/>\n      <xs:element name="system" type="xs:string"/>\n      <xs:element name="summary" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="authors" type="AuthorsType" minOccurs="0"/>\n      <xs:element name="dates" type="DatesType" minOccurs="0"/>\n      <xs:element name="conventions" type="ConventionsType" minOccurs="0"/>\n      <xs:element name="profiles" type="ProfilesType" minOccurs="0"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name="AuthorsType">\n    <xs:sequence>\n      <xs:element name="author" type="AuthorType" minOccurs="1" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    AuthorType: Individual author/contributor information\n\n    FOR LLMs: Capture at least name and role for accountability.\n    Contact info helps with follow-up questions during elicitation.\n  -->\n  <xs:complexType name="AuthorType">\n    <xs:sequence>\n      <xs:element name="name" type="xs:string"/>\n      <xs:element name="role" type="xs:string" minOccurs="0"/>\n      <xs:element name="org" type="xs:string" minOccurs="0"/>\n      <xs:element name="contact" type="xs:string" minOccurs="0"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    DatesType: Temporal metadata for change control\n\n    - created: When the document was first created (xs:date format: YYYY-MM-DD)\n    - updated: When the document was last modified\n    - targetRelease: Version/sprint/date when requirements should be delivered\n  -->\n  <xs:complexType name="DatesType">\n    <xs:sequence>\n      <xs:element name="created" type="xs:date" minOccurs="0"/>\n      <xs:element name="updated" type="xs:date" minOccurs="0"/>\n      <xs:element name="targetRelease" type="xs:string" minOccurs="0"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ConventionsType: Document-wide rules and standards\n\n    - normativeKeywords: How to interpret MUST/SHALL/SHOULD/MAY (typically RFC 2119)\n    - idConventions: Patterns for generating IDs (e.g., "REQ-<AREA>-NNN")\n\n    FOR LLMs: Follow these conventions when adding new elements.\n  -->\n  <xs:complexType name="ConventionsType">\n    <xs:sequence>\n      <xs:element name="normativeKeywords" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="idConventions" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name="ProfilesType">\n    <xs:sequence>\n      <xs:element name="profile" type="ProfileType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ProfileType: Domain-specific customization or viewpoint\n\n    Profiles allow tailoring the spec for different audiences or domains\n    (e.g., safety-critical, regulatory, mobile). Similar to viewpoints in\n    ISO/IEC/IEEE 42010 architecture descriptions.\n\n    ATTRIBUTES:\n    - id: Unique identifier for the profile\n    - type: Category of profile (e.g., "safety", "compliance", "mobile")\n  -->\n  <xs:complexType name="ProfileType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="type" type="xs:token" use="required"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Catalogs Section\n\n       Shared definitions and reusable reference lists. Centralizes vocabulary\n       and facts to keep requirements concise and consistent.\n\n       FOR LLMs:\n       - Define terms in glossary BEFORE using them in requirements\n       - Define actors and stakeholders to establish WHO the system serves\n       - Capture constraints early - they limit the solution space\n       - Log decisions to preserve rationale (like ADRs)\n       - Document risks so requirements can address them\n       ========================= -->\n\n  <!--\n    CatalogsType: Container for all catalog subsections\n\n    Subsections can appear in any order and multiple times.\n    All provide referenceable items for use throughout the document.\n  -->\n  <xs:complexType name="CatalogsType">\n    <xs:choice minOccurs="0" maxOccurs="unbounded">\n      <xs:element name="glossary" type="GlossaryType"/>\n      <xs:element name="actors" type="ActorsType"/>\n      <xs:element name="stakeholders" type="StakeholdersType"/>\n      <xs:element name="constraints" type="ConstraintsType"/>\n      <xs:element name="policies" type="PoliciesType"/>\n      <xs:element name="decisions" type="DecisionsType"/>\n      <xs:element name="risks" type="RisksType"/>\n    </xs:choice>\n  </xs:complexType>\n\n  <!--\n    GlossaryType: Domain vocabulary definitions\n\n    Establishes shared understanding of terms to reduce ambiguity.\n    IEEE 29148 emphasizes consistent terminology in requirements.\n\n    FOR LLMs:\n    - Add terms when stakeholders use domain-specific language\n    - Reference terms by ID in requirements to enforce consistency\n    - Include synonyms to handle variant terminology\n  -->\n  <xs:complexType name="GlossaryType">\n    <xs:sequence>\n      <xs:element name="term" type="TermType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    TermType: Individual glossary entry\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., TERM-PCI, TERM-PAYMENT)\n\n    CHILDREN:\n    - name: The term as used in text\n    - definition: Precise meaning in this context\n    - synonyms: Alternative names for the same concept\n  -->\n  <xs:complexType name="TermType">\n    <xs:sequence>\n      <xs:element name="name" type="xs:string"/>\n      <xs:element name="definition" type="TextBlockType"/>\n      <xs:element name="synonyms" type="SynonymsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n  </xs:complexType>\n\n  <xs:complexType name="SynonymsType">\n    <xs:sequence>\n      <xs:element name="synonym" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ActorsType: Users and external systems that interact with the system\n\n    Actors from UML use case modeling - entities outside the system boundary\n    that interact with it. Can be humans, systems, or devices.\n  -->\n  <xs:complexType name="ActorsType">\n    <xs:sequence>\n      <xs:element name="actor" type="ActorType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ActorType: Individual actor definition\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., ACT-USER, ACT-ADMIN, ACT-PAYMENT-GATEWAY)\n    - name: Human-readable actor name\n    - type: Category of actor (e.g., "human", "system", "device", "timer")\n\n    CHILDREN:\n    - description: Role and characteristics of this actor\n    - goals: References to goals this actor wants to achieve\n\n    FOR LLMs:\n    - Reference actors in scenarios via actorRef\n    - Link actors to their goals to trace motivation\n    - Use actor types to distinguish user personas from system integrations\n  -->\n  <xs:complexType name="ActorType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="goals" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="type" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    StakeholdersType: Parties with interest in the system\n\n    Stakeholders may not directly use the system but have concerns that\n    requirements must address (e.g., compliance officers, operations team).\n    Aligns with BABOK stakeholder analysis.\n  -->\n  <xs:complexType name="StakeholdersType">\n    <xs:sequence>\n      <xs:element name="stakeholder" type="StakeholderType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    StakeholderType: Individual stakeholder definition\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., STK-RISK, STK-OPS, STK-LEGAL)\n    - name: Stakeholder name or role\n    - org: Organization they belong to\n\n    CHILDREN:\n    - concerns: What this stakeholder cares about; requirements should address these\n\n    FOR LLMs:\n    - Use ownerRef to assign requirements to responsible stakeholders\n    - Ensure each concern maps to at least one requirement\n    - Different stakeholders may have conflicting concerns - flag these\n  -->\n  <xs:complexType name="StakeholderType">\n    <xs:sequence>\n      <xs:element name="concerns" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="org" type="xs:string" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    ConstraintsType: Non-negotiable limitations on the solution\n\n    Constraints restrict what solutions are acceptable, unlike requirements\n    which specify what the solution must do. They come from technical,\n    business, regulatory, or organizational sources.\n  -->\n  <xs:complexType name="ConstraintsType">\n    <xs:sequence>\n      <xs:element name="constraint" type="ConstraintType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ConstraintType: Individual constraint definition\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., CON-HTTPS, CON-K8S, CON-JAVA17)\n    - severity: Impact level (e.g., "high", "medium", "low", "blocking")\n\n    CHILDREN:\n    - statement: What is constrained and how\n    - source: Where this constraint comes from (policy, standard, etc.)\n\n    FOR LLMs:\n    - Constraints with severity="blocking" must be satisfied by any solution\n    - When generating code, check constraints first to avoid invalid approaches\n    - Reference constraints in requirement rationale to explain "why this way"\n\n    EXAMPLES:\n    - "All APIs must use TLS 1.2+" (source: Security Policy)\n    - "Must deploy to AWS us-east-1" (source: Data Residency Policy)\n    - "Must use Java 17 LTS" (source: Platform Standards)\n  -->\n  <xs:complexType name="ConstraintType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="source" type="xs:string" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="severity" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    PoliciesType: Organizational and regulatory obligations\n\n    Policies define what MUST be done due to external mandates (laws,\n    regulations, standards) or internal rules. They differ from constraints\n    in that they specify obligations rather than limitations.\n  -->\n  <xs:complexType name="PoliciesType">\n    <xs:sequence>\n      <xs:element name="policy" type="PolicyType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    PolicyType: Individual policy definition\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., POL-GDPR-CONSENT, POL-PCI-STORAGE)\n    - source: Authority mandating this policy (e.g., "GDPR Art. 7", "PCI-DSS 3.4")\n\n    CHILDREN:\n    - obligation: What must be done to comply\n    - evidence: How compliance is demonstrated\n\n    FOR LLMs:\n    - Generate PR (Policy/Compliance) requirements from policies\n    - Include evidence requirements in verification section\n    - Policy violations can have legal/financial consequences - flag gaps\n  -->\n  <xs:complexType name="PolicyType">\n    <xs:sequence>\n      <xs:element name="obligation" type="TextBlockType"/>\n      <xs:element name="evidence" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="source" type="xs:string" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    DecisionsType: Architecture and design decisions\n\n    Records significant decisions and their rationale. Similar to Architecture\n    Decision Records (ADRs). Preserves context for future maintainers.\n  -->\n  <xs:complexType name="DecisionsType">\n    <xs:sequence>\n      <xs:element name="decision" type="DecisionType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    DecisionType: Individual decision record\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., DEC-IDEMPOTENCY, DEC-DATABASE)\n    - status: Decision lifecycle (draft/review/approved/deprecated)\n\n    CHILDREN:\n    - context: Why this decision was needed (the problem)\n    - decision: What was decided (the solution chosen)\n    - alternatives: Other options considered and why rejected\n    - consequences: Implications of this decision (good and bad)\n\n    FOR LLMs:\n    - When generating code, follow approved decisions\n    - Deprecated decisions may explain legacy code\n    - Use decision context to understand trade-offs\n    - Reference decisions in requirement rationale\n  -->\n  <xs:complexType name="DecisionType">\n    <xs:sequence>\n      <xs:element name="context" type="TextBlockType"/>\n      <xs:element name="decision" type="TextBlockType"/>\n      <xs:element name="alternatives" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="consequences" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    RisksType: Identified risks to the project or system\n\n    Risks are potential problems that could prevent goals from being achieved.\n    Aligned with ISO 31000 risk management principles.\n  -->\n  <xs:complexType name="RisksType">\n    <xs:sequence>\n      <xs:element name="risk" type="RiskType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    RiskType: Individual risk entry\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., RISK-FRAUD, RISK-DOWNTIME, RISK-DATA-LOSS)\n    - severity: Impact level (e.g., "critical", "high", "medium", "low")\n\n    CHILDREN:\n    - statement: Description of the risk and its potential impact\n    - mitigation: How this risk is addressed (link to requirements/controls)\n\n    FOR LLMs:\n    - Create trace edges from risks to goals they threaten (type="threatens")\n    - Create trace edges from requirements to risks they mitigate (type="mitigates")\n    - Generate SR (Security) or NFR requirements to address high-severity risks\n    - Unmitigated high-severity risks should be flagged\n  -->\n  <xs:complexType name="RiskType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="mitigation" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="severity" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Domain Section\n\n       Captures shared understanding of the problem space: key concepts,\n       data structures, and business logic. Provides vocabulary for requirements.\n\n       Aligned with Domain-Driven Design (DDD) and Michael Jackson\'s Problem Frames.\n\n       FOR LLMs:\n       - Use entities as the basis for data models and class hierarchies\n       - Use attributes to generate database schemas and API payloads\n       - Use business rules to generate validation logic\n       - Reference domain elements in requirements via appliesTo or refs\n       ========================= -->\n\n  <!--\n    DomainType: Problem space model\n\n    CHILDREN:\n    - overview: High-level context, assumptions, and scope boundaries\n    - entities: Key domain objects and their attributes\n    - businessRules: Invariants and logic that govern the domain\n  -->\n  <xs:complexType name="DomainType">\n    <xs:sequence>\n      <xs:element name="overview" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="entities" type="EntitiesType" minOccurs="0"/>\n      <xs:element name="businessRules" type="BusinessRulesType" minOccurs="0"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <xs:complexType name="EntitiesType">\n    <xs:sequence>\n      <xs:element name="entity" type="EntityType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    EntityType: Domain object definition\n\n    Entities are the core concepts in the problem domain. They become classes,\n    database tables, API resources, and form the ubiquitous language.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., ENT-PAYMENT, ENT-USER, ENT-ORDER)\n    - name: Entity name (use PascalCase for code generation)\n\n    CHILDREN:\n    - description: Purpose and role of this entity\n    - attr: Attributes (properties/fields) of the entity\n\n    FOR LLMs:\n    - Generate classes/types from entities\n    - Generate database tables from entities\n    - Generate API resource schemas from entities\n    - Entity names become part of the ubiquitous language\n  -->\n  <xs:complexType name="EntityType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="attr" type="AttrType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n  </xs:complexType>\n\n  <!--\n    AttrType: Entity attribute (property/field)\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., ATTR-PAYMENT-ID, ATTR-AMOUNT)\n    - name: Attribute name (use camelCase for code generation)\n    - type: Data type token (e.g., "uuid", "string", "decimal", "ISO8601-timestamp", "email")\n    - required: Whether this attribute must have a value (boolean)\n\n    CHILDREN:\n    - description: Purpose and semantics of this attribute\n    - constraints: Validation rules (e.g., "positive", "max 255 chars", "valid email format")\n\n    FOR LLMs:\n    - Generate class properties from attributes\n    - Generate database columns from attributes\n    - Generate validation code from constraints\n    - Use type tokens consistently across the document\n\n    COMMON TYPE TOKENS:\n    - uuid: Universally unique identifier\n    - string: Text value\n    - decimal: Numeric value with precision\n    - integer: Whole number\n    - boolean: True/false\n    - ISO8601-timestamp: Date-time in ISO 8601 format\n    - email: Email address format\n    - url: URL/URI format\n    - enum:value1,value2,value3: Enumerated values\n  -->\n  <xs:complexType name="AttrType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="constraints" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="type" type="xs:token" use="required"/>\n    <xs:attribute name="required" type="xs:boolean" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    BusinessRulesType: Domain logic and invariants\n\n    Business rules are constraints and logic that govern how the domain behaves.\n    They exist independent of any particular system implementation.\n    Aligned with the Business Rules Manifesto.\n  -->\n  <xs:complexType name="BusinessRulesType">\n    <xs:sequence>\n      <xs:element name="rule" type="RuleType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    RuleType: Individual business rule\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., BR-DECLINE, BR-DISCOUNT, BR-SHIPPING)\n\n    CHILDREN:\n    - statement: The rule expressed in domain language\n    - examples: Concrete instances showing the rule in action\n\n    FOR LLMs:\n    - Generate validation logic from business rules\n    - Generate test cases from examples\n    - Business rules may become FR (functional) or DR (data) requirements\n    - Rules often translate to if/then logic or constraints\n\n    EXAMPLE:\n    - Rule: "Orders over $100 qualify for free shipping"\n    - Example: "$150 order -> free shipping; $50 order -> $5.99 shipping"\n  -->\n  <xs:complexType name="RuleType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="examples" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Goals Section\n\n       Captures WHY the system exists: business objectives, quality targets,\n       and obstacles that threaten success. Goals drive requirements.\n\n       Aligned with KAOS and i* goal-oriented requirements engineering.\n\n       FOR LLMs:\n       - Start elicitation by asking "what are you trying to achieve?"\n       - Decompose high-level goals into sub-goals (refines relationship)\n       - Derive requirements that satisfy goals\n       - Identify obstacles/risks that threaten goals\n       - Quality goals need measurable metrics\n       ========================= -->\n\n  <!--\n    GoalsType: Goal model container\n\n    CHILDREN:\n    - goal: Business/functional objectives\n    - qgoal: Quality/non-functional objectives\n    - obstacle: Threats to goal achievement\n    - goalLink: Relationships between goals, obstacles, and other elements\n  -->\n  <xs:complexType name="GoalsType">\n    <xs:sequence>\n      <xs:element name="goal" type="GoalType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="qgoal" type="QualityGoalType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="obstacle" type="ObstacleType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="goalLink" type="GoalLinkType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    GoalType: Business or functional objective\n\n    Goals express what stakeholders want to achieve. They are intentional\n    (describe desired state) rather than operational (describe how to achieve).\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., GOAL-AVAIL, GOAL-REVENUE, GOAL-COMPLIANCE)\n    - title: Short descriptive name\n    - priority: Importance (must/should/may)\n    - status: Lifecycle state\n    - ownerRef: Reference to stakeholder who owns this goal\n\n    CHILDREN:\n    - statement: What should be achieved (use "Maintain...", "Achieve...", "Ensure...")\n    - rationale: Why this goal matters (business justification)\n\n    FOR LLMs:\n    - Ask "why?" to discover goals behind requirements\n    - High-level goals decompose into sub-goals (create goalLink with type="refines")\n    - Requirements satisfy goals (create trace edge with type="satisfies")\n    - Goals without requirements indicate gaps\n\n    EXAMPLES:\n    - "Achieve 99.9% availability during peak shopping periods"\n    - "Maintain compliance with PCI-DSS for all card transactions"\n    - "Ensure new users can complete checkout within 3 minutes"\n  -->\n  <xs:complexType name="GoalType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="rationale" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="priority" type="PriorityType" use="optional"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n    <xs:attribute name="ownerRef" type="IdType" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    QualityGoalType: Non-functional quality objective\n\n    Quality goals specify HOW WELL the system should perform. They map to\n    ISO/IEC 25010 quality attributes (performance, security, usability, etc.).\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., QGOAL-LATENCY, QGOAL-SECURITY, QGOAL-USABILITY)\n    - title: Short descriptive name\n    - priority: Importance (must/should/may)\n    - status: Lifecycle state\n\n    CHILDREN:\n    - statement: The quality objective\n    - metric: Measurable criteria (CRITICAL for verifiability)\n\n    FOR LLMs:\n    - Quality goals become NFR (non-functional) requirements\n    - Always ask for metrics - vague quality goals are untestable\n    - Generate performance/security/etc. tests from quality goals\n    - Quality goals often conflict - identify trade-offs\n\n    EXAMPLES:\n    - Goal: "Low latency checkout" | Metric: "p95 latency \u2264 500ms under 200 rps"\n    - Goal: "High availability" | Metric: "99.9% uptime monthly"\n    - Goal: "Accessible interface" | Metric: "WCAG 2.1 Level AA compliance"\n  -->\n  <xs:complexType name="QualityGoalType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="metric" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="priority" type="PriorityType" use="optional"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    ObstacleType: Threat to goal achievement\n\n    Obstacles are conditions or events that could prevent goals from being met.\n    They drive risk mitigation and defensive requirements.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., OBS-DB, OBS-FRAUD, OBS-VENDOR)\n    - title: Short descriptive name\n    - likelihood: Probability of occurrence (e.g., "high", "medium", "low")\n    - severity: Impact if it occurs (e.g., "critical", "high", "medium", "low")\n\n    CHILDREN:\n    - statement: Description of the obstacle\n    - mitigation: How to address it (may reference requirements)\n\n    FOR LLMs:\n    - Create goalLink with type="threatens" to connect obstacles to goals\n    - Generate requirements that mitigate high-likelihood/high-severity obstacles\n    - Link mitigations to requirements via trace edges (type="mitigates")\n    - Unmitigated critical obstacles should be flagged\n  -->\n  <xs:complexType name="ObstacleType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="mitigation" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="likelihood" type="xs:token" use="optional"/>\n    <xs:attribute name="severity" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    GoalLinkType: Relationship between goals and obstacles\n\n    Captures how goals relate to each other and to obstacles.\n    Used for goal decomposition and threat modeling.\n\n    ATTRIBUTES:\n    - id: Unique identifier for this link\n    - from: Source element ID\n    - to: Target element ID\n    - type: Relationship type (TraceType - typically refines, threatens, mitigates, conflictsWith)\n    - confidence: Certainty of this relationship (0.0-1.0)\n\n    COMMON PATTERNS:\n    - Sub-goal refines parent-goal (decomposition)\n    - Obstacle threatens goal (threat)\n    - Goal conflictsWith goal (trade-off)\n    - Requirement mitigates obstacle (addressed by requirement)\n  -->\n  <xs:complexType name="GoalLinkType">\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="from" type="IdType" use="required"/>\n    <xs:attribute name="to" type="IdType" use="required"/>\n    <xs:attribute name="type" type="TraceType" use="required"/>\n    <xs:attribute name="confidence" type="ConfidenceType" use="optional"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Scenarios Section\n\n       Narrative descriptions of system usage. Includes positive use cases,\n       negative misuse cases, and boundary edge cases.\n\n       Aligned with Cockburn use cases and Sindre/Opdahl misuse cases.\n\n       FOR LLMs:\n       - Use scenarios to discover requirements through "what happens when..."\n       - Generate acceptance tests from scenario narratives\n       - Misuse cases drive security requirements\n       - Edge cases drive robustness requirements\n       ========================= -->\n\n  <!--\n    ScenariosType: Scenario collection\n\n    CHILDREN:\n    - scenario: Normal/positive use cases\n    - misuseCase: Abuse/attack scenarios\n    - edgeCase: Boundary/exceptional scenarios\n  -->\n  <xs:complexType name="ScenariosType">\n    <xs:sequence>\n      <xs:element name="scenario" type="ScenarioType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="misuseCase" type="ScenarioType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="edgeCase" type="ScenarioType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ScenarioType: Individual scenario definition (used for scenario, misuseCase, edgeCase)\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., SCN-CHECKOUT, SCN-FRAUD, SCN-TIMEOUT)\n    - title: Short descriptive name\n    - actorRef: Reference to the actor performing this scenario\n\n    CHILDREN:\n    - narrative: Step-by-step description of what happens\n    - refs: Links to related goals, requirements, or risks\n\n    FOR LLMs:\n\n    For SCENARIOS (positive use cases):\n    - Describe the happy path of user interaction\n    - Include main flow and notable alternative flows\n    - Derive FR (functional) requirements from scenario steps\n    - Generate acceptance tests from scenarios\n\n    For MISUSE CASES (abuse scenarios):\n    - Describe how attackers or malicious users might abuse the system\n    - Derive SR (security) requirements to prevent/detect abuse\n    - Link to risks in catalogs\n    - Generate security tests from misuse cases\n\n    For EDGE CASES (boundary scenarios):\n    - Describe unusual but valid conditions (empty inputs, max values, etc.)\n    - Derive robustness requirements\n    - Generate boundary tests from edge cases\n\n    EXAMPLE NARRATIVE FORMAT:\n    "1. User enters email and password\n     2. System validates credentials against user store\n     3. System generates session token\n     4. System redirects to dashboard"\n  -->\n  <xs:complexType name="ScenarioType">\n    <xs:sequence>\n      <xs:element name="narrative" type="TextBlockType"/>\n      <xs:element name="refs" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="actorRef" type="IdType" use="optional"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Requirements Section (REQUIRED)\n\n       The core normative content - statements of what the system MUST do.\n       This is the primary driver for implementation.\n\n       Aligned with IEEE 29148 requirements qualities: necessary, verifiable,\n       unambiguous, consistent, complete, feasible, traceable.\n\n       FOR LLMs:\n       - This section drives code generation\n       - Each requirement should map to implementable code\n       - Use acceptance criteria for test generation\n       - Type attribute determines implementation approach\n       ========================= -->\n\n  <!--\n    RequirementsType: Requirements container\n\n    CHILDREN:\n    - reqPackage: Grouping container for related requirements\n    - req: Individual requirement statements\n\n    Requirements can be organized into packages or listed directly.\n    Packages help manage ownership and scope.\n  -->\n  <xs:complexType name="RequirementsType">\n    <xs:sequence>\n      <xs:element name="reqPackage" type="ReqPackageType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="req" type="ReqTypeItem" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ReqPackageType: Logical grouping of requirements\n\n    Packages organize requirements by feature area, component, or ownership.\n    Similar to Volere requirement categories or agile epics.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., PKG-AUTH, PKG-PAYMENTS, PKG-REPORTING)\n    - title: Package name\n    - ownerRef: Reference to stakeholder responsible for this package\n\n    CHILDREN:\n    - description: Purpose and scope of this package\n    - req: Requirements within this package\n\n    FOR LLMs:\n    - Use packages to organize by feature area or bounded context\n    - Package ownership helps route implementation to the right team\n    - When generating code, package names may map to modules/namespaces\n  -->\n  <xs:complexType name="ReqPackageType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="req" type="ReqTypeItem" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="ownerRef" type="IdType" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    ReqTypeItem: Individual requirement definition\n\n    The fundamental unit of specification. Each requirement is a normative\n    statement about what the system must do or how it must behave.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., REQ-AUTH-001, REQ-PAY-002)\n    - type: Requirement category (ReqType: FR/NFR/IR/DR/SR/CR/PR/UXR/OR)\n    - title: Short descriptive name\n    - status: Lifecycle state (draft/review/approved/deprecated)\n    - priority: Importance (must/should/may)\n    - ownerRef: Reference to responsible stakeholder\n    - appliesTo: Token indicating scope (e.g., entity ID, component name)\n\n    CHILDREN:\n    - statement: The normative requirement (use SHALL/SHOULD/MAY)\n    - rationale: Why this requirement exists\n    - notes: Implementation hints or clarifications\n    - acceptance: BDD-style acceptance criteria\n    - refs: Links to goals, scenarios, or other requirements\n\n    FOR LLMs - REQUIREMENT STATEMENT GUIDELINES:\n    - Use active voice: "The system SHALL..." not "It should be possible to..."\n    - Be specific: "within 200ms" not "quickly"\n    - Be testable: each statement should have clear pass/fail criteria\n    - One requirement per statement: avoid "and" joining unrelated behaviors\n    - Use normative keywords from RFC 2119:\n      * SHALL/MUST: Absolute requirement\n      * SHOULD: Recommended but not mandatory\n      * MAY: Optional\n\n    FOR LLMs - CODE GENERATION BY TYPE:\n    - FR: Application logic, services, controllers, business rules\n    - NFR: Architecture decisions, caching, async processing, optimization\n    - IR: API handlers, protocol implementations, serialization\n    - DR: Models, schemas, validators, data access code\n    - SR: Auth middleware, encryption, audit logging, security filters\n    - CR: Configuration, deployment scripts, dependency management\n    - PR: Compliance features, audit trails, reporting\n    - UXR: UI components, accessibility, internationalization\n    - OR: Logging, monitoring, health checks, alerting\n\n    EXAMPLE STATEMENTS BY TYPE:\n    - FR: "The system SHALL allow users to reset their password via email link"\n    - NFR: "The API SHALL respond within 200ms for 95th percentile requests"\n    - IR: "The system SHALL accept payment requests in ISO 20022 format"\n    - DR: "Email addresses SHALL be validated against RFC 5322 format"\n    - SR: "Failed login attempts SHALL be logged with source IP and timestamp"\n    - CR: "The system SHALL be deployable on Kubernetes 1.28+"\n    - PR: "User data exports SHALL be provided within 30 days per GDPR Art. 20"\n    - UXR: "Form fields SHALL display inline validation errors on blur"\n    - OR: "The system SHALL emit metrics to Prometheus in OpenMetrics format"\n  -->\n  <xs:complexType name="ReqTypeItem">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="rationale" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="notes" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="acceptance" type="AcceptanceType" minOccurs="0"/>\n      <xs:element name="refs" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="type" type="ReqType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n    <xs:attribute name="priority" type="PriorityType" use="optional"/>\n    <xs:attribute name="ownerRef" type="IdType" use="optional"/>\n    <xs:attribute name="appliesTo" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    AcceptanceType: Container for acceptance criteria\n\n    Acceptance criteria define when a requirement is satisfied.\n    Based on BDD/Gherkin given-when-then format.\n  -->\n  <xs:complexType name="AcceptanceType">\n    <xs:sequence>\n      <xs:element name="criterion" type="CriterionType" minOccurs="1" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    CriterionType: Individual acceptance criterion\n\n    Uses given-when-then structure from BDD (Behavior-Driven Development).\n    Each criterion is a testable scenario for the requirement.\n\n    ATTRIBUTES:\n    - id: Optional unique identifier for the criterion\n\n    CHILDREN:\n    - given: Preconditions/context (optional - may be implicit)\n    - when: Action/trigger (optional - may be implicit)\n    - then: Expected outcome (required - must be verifiable)\n\n    FOR LLMs:\n    - Generate test cases directly from acceptance criteria\n    - "given" becomes test setup/fixtures\n    - "when" becomes test action\n    - "then" becomes test assertions\n    - Multiple criteria = multiple test cases\n\n    EXAMPLES:\n    Criterion 1:\n      given: "A user with a valid session"\n      when: "The user submits an order with items totaling $150"\n      then: "Free shipping is applied and total reflects no shipping charge"\n\n    Criterion 2:\n      given: "A guest user without a session"\n      when: "The user attempts to access /account"\n      then: "The user is redirected to /login with return URL preserved"\n  -->\n  <xs:complexType name="CriterionType">\n    <xs:sequence>\n      <xs:element name="given" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="when" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="then" type="TextBlockType" minOccurs="1"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="optional"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Behavior Section\n\n       State machines that formalize entity lifecycles derived from requirements.\n       Models valid states and transitions to enable precise behavioral specs.\n\n       Placed after requirements because state machines refine/formalize requirement\n       statements into explicit lifecycle models. Transitions reference requirements.\n\n       Aligned with UML state machine concepts (simplified flat model).\n\n       FOR LLMs:\n       - Use state machines to formalize entity lifecycles (Order, Payment, User, etc.)\n       - Generate state enums, transition functions, and validation logic\n       - Generate state transition tests (happy path, all transitions, invalid transitions)\n       - Link transitions to requirements via refs for traceability\n       - Check guards to generate conditional logic\n       ========================= -->\n\n  <!--\n    BehaviorType: Container for state machines\n\n    CHILDREN:\n    - stateMachine: Individual state machine definitions\n  -->\n  <xs:complexType name="BehaviorType">\n    <xs:sequence>\n      <xs:element name="stateMachine" type="StateMachineType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    StateMachineType: Finite state machine definition\n\n    Models the valid lifecycle of an entity or process. An entity is always\n    in exactly one state; transitions move it between states based on events\n    and guards.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., SM-ORDER, SM-PAYMENT, SM-USER-ACCOUNT)\n    - name: Human-readable state machine name\n    - entityRef: Optional reference to the domain entity this governs\n    - initial: Required reference to the initial state ID\n\n    CHILDREN:\n    - description: Purpose and scope of this state machine\n    - state: State definitions (at least one required)\n    - transition: Transition definitions between states\n\n    FOR LLMs:\n    - Generate state enum/type from all state names\n    - Generate transition validation function\n    - Use entityRef to link to domain entity for the status field\n    - Ensure initial state exists and is reachable\n    - Verify all non-final states have at least one outgoing transition\n\n    EXAMPLE ID PATTERNS:\n    - SM-ORDER (order lifecycle)\n    - SM-PAYMENT (payment processing)\n    - SM-TICKET (support ticket workflow)\n    - SM-DOC-REVIEW (document approval process)\n  -->\n  <xs:complexType name="StateMachineType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="state" type="StateType" minOccurs="1" maxOccurs="unbounded"/>\n      <xs:element name="transition" type="TransitionType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="entityRef" type="IdType" use="optional"/>\n    <xs:attribute name="initial" type="IdType" use="required"/>\n  </xs:complexType>\n\n  <!--\n    StateType: Individual state in a state machine\n\n    Represents a distinct condition or situation in an entity\'s lifecycle.\n    States are mutually exclusive; an entity is in exactly one state at a time.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., ST-PENDING, ST-CONFIRMED, ST-CANCELLED)\n    - name: Human-readable state name (use for enum values in code generation)\n    - type: State kind: initial, normal, or final (default: normal)\n\n    CHILDREN:\n    - description: What this state represents and when an entity is in it\n    - onEntry: Actions to perform when entering this state\n    - onExit: Actions to perform when leaving this state\n    - invariant: Conditions that must hold while in this state\n\n    FOR LLMs:\n    - Generate enum values from state names (use PascalCase or snake_case)\n    - onEntry actions become side effects in transition handlers\n    - onExit actions become cleanup logic before transitions\n    - invariant becomes validation logic or assertions\n    - States with type="final" should have no outgoing transitions\n\n    EXAMPLE STATE NAMES:\n    - Pending, Confirmed, Shipped, Delivered, Cancelled (order)\n    - Draft, Review, Approved, Published, Archived (document)\n    - Active, Suspended, Closed (account)\n  -->\n  <xs:complexType name="StateType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="onEntry" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="onExit" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="invariant" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="type" type="StateKindType" use="optional" default="normal"/>\n  </xs:complexType>\n\n  <!--\n    TransitionType: State transition definition\n\n    Defines a valid movement from one state to another, optionally triggered\n    by an event and constrained by a guard condition.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., TR-CONFIRM, TR-SHIP, TR-CANCEL)\n    - from: Source state ID (must exist in same state machine)\n    - to: Target state ID (must exist in same state machine)\n    - event: Optional event name that triggers this transition\n\n    CHILDREN:\n    - description: Human-readable explanation of this transition\n    - trigger: What causes this transition (if not captured by event attribute)\n    - guard: Condition that must be true for transition to fire\n    - action: What happens during the transition (side effects)\n    - refs: Links to requirements this transition implements\n\n    FOR LLMs:\n\n    CODE GENERATION:\n    - Generate transition table/map: { from, to, event, guard? }\n    - Generate event handler functions from event names\n    - Guard text becomes conditional logic (if/when)\n    - Action text becomes side effect code\n    - Use refs to add traceability comments in generated code\n\n    TEST GENERATION:\n    - Generate test for each transition (valid path)\n    - Generate test for transition with guard=true and guard=false\n    - Generate test for invalid transitions (wrong source state)\n    - Generate test for missing event (should reject)\n\n    PATTERNS:\n    - event="confirm" -> onConfirm() handler\n    - guard="payment authorized" -> if (order.paymentAuthorized)\n    - action="send email" -> emailService.send(...)\n\n    EXAMPLE:\n    <transition id="TR-SHIP" from="ST-CONFIRMED" to="ST-SHIPPED" event="ship">\n      <guard>All items picked and packed</guard>\n      <action>Capture payment; generate tracking number</action>\n      <refs><ref ref="REQ-ORDER-SHIP"/></refs>\n    </transition>\n  -->\n  <xs:complexType name="TransitionType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="trigger" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="guard" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="action" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="refs" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="from" type="IdType" use="required"/>\n    <xs:attribute name="to" type="IdType" use="required"/>\n    <xs:attribute name="event" type="xs:string" use="optional"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Interfaces Section\n\n       System boundaries and contracts with external systems.\n       Describes APIs, events, and other integration points.\n\n       Aligned with ISO/IEC/IEEE 42010 interface specifications.\n\n       FOR LLMs:\n       - Generate API handlers from endpoint definitions\n       - Generate event handlers from event definitions\n       - Generate client SDKs from API specifications\n       - Generate OpenAPI/AsyncAPI specs from interface definitions\n       ========================= -->\n\n  <!--\n    InterfacesType: Interface specifications container\n\n    CHILDREN:\n    - api: Synchronous API definitions (REST, RPC, GraphQL)\n    - event: Asynchronous event definitions (messages, webhooks)\n  -->\n  <xs:complexType name="InterfacesType">\n    <xs:sequence>\n      <xs:element name="api" type="ApiType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="event" type="EventType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    ApiType: API surface definition\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., API-PAYMENTS, API-USERS, API-ADMIN)\n    - name: Human-readable API name\n    - protocol: Communication protocol (e.g., "https", "grpc", "graphql", "websocket")\n    - auth: Authentication method (e.g., "oauth2", "api-key", "jwt", "mtls", "none")\n\n    CHILDREN:\n    - description: Purpose and scope of this API\n    - endpoint: Individual endpoint definitions\n\n    FOR LLMs:\n    - Use protocol to determine implementation pattern\n    - Use auth to generate authentication/authorization middleware\n    - API names may map to controller classes or service modules\n    - Generate OpenAPI specification from api + endpoints\n  -->\n  <xs:complexType name="ApiType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="endpoint" type="EndpointType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n    <xs:attribute name="protocol" type="xs:token" use="optional"/>\n    <xs:attribute name="auth" type="xs:token" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    EndpointType: Individual API endpoint\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., EP-CREATE-PAYMENT, EP-GET-USER)\n    - method: HTTP method or operation type (e.g., "GET", "POST", "PUT", "DELETE", "PATCH")\n    - path: URL path with parameters (e.g., "/payments", "/users/{id}", "/orders/{orderId}/items")\n\n    CHILDREN:\n    - summary: Brief description of what this endpoint does\n    - request: Request body/parameters specification\n    - response: Success response specification\n    - errors: Error responses and conditions\n\n    FOR LLMs:\n    - Generate route handlers from method + path\n    - Generate request DTOs/validators from request description\n    - Generate response DTOs from response description\n    - Generate error handling from errors description\n    - Use domain entities as basis for request/response schemas\n\n    PATH PARAMETER CONVENTIONS:\n    - Use {paramName} for path parameters\n    - Use snake_case or camelCase consistently\n    - Example: /users/{userId}/orders/{orderId}\n\n    COMMON PATTERNS:\n    - GET /resources - List resources (paginated)\n    - POST /resources - Create new resource\n    - GET /resources/{id} - Get single resource\n    - PUT /resources/{id} - Replace resource\n    - PATCH /resources/{id} - Update resource partially\n    - DELETE /resources/{id} - Remove resource\n  -->\n  <xs:complexType name="EndpointType">\n    <xs:sequence>\n      <xs:element name="summary" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="request" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="response" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="errors" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="method" type="xs:token" use="required"/>\n    <xs:attribute name="path" type="xs:string" use="required"/>\n  </xs:complexType>\n\n  <!--\n    EventType: Asynchronous event definition\n\n    Events represent messages exchanged asynchronously between systems\n    or components (message queues, event buses, webhooks, etc.).\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., EVT-PAYMENT-CREATED, EVT-ORDER-SHIPPED)\n    - name: Event name (use PascalCase for consistency)\n\n    CHILDREN:\n    - description: When this event is emitted and its purpose\n    - payload: Data structure carried by the event\n\n    FOR LLMs:\n    - Generate event classes/types from event definitions\n    - Generate event handlers/subscribers\n    - Generate event publishers/emitters\n    - Use domain entities as basis for payload schemas\n    - Generate AsyncAPI specification from events\n\n    EVENT NAMING CONVENTIONS:\n    - Use past tense for things that happened: PaymentCreated, OrderShipped\n    - Use present tense for commands: ProcessPayment, ShipOrder\n    - Include domain context: PaymentService.PaymentCreated vs OrderService.PaymentReceived\n  -->\n  <xs:complexType name="EventType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="payload" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="name" type="xs:string" use="required"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Verification Section\n\n       How requirements are tested and validated. Captures planned\n       and executed verification activities.\n\n       Aligned with IEEE 29148 verification requirements and V-model testing.\n\n       FOR LLMs:\n       - Generate test code from test case definitions\n       - Map test cases to requirements via refs\n       - Use acceptance criteria (given/when/then) for test implementation\n       - Ensure each requirement has at least one verifiedBy trace\n       ========================= -->\n\n  <!--\n    VerificationType: Verification container\n\n    CHILDREN:\n    - testSuite: Logical grouping of test cases\n    - testCase: Individual verification items\n  -->\n  <xs:complexType name="VerificationType">\n    <xs:sequence>\n      <xs:element name="testSuite" type="TestSuiteType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="testCase" type="TestCaseType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    TestSuiteType: Logical grouping of test cases\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., TS-PAYMENT, TS-AUTH, TS-PERFORMANCE)\n    - title: Suite name\n\n    CHILDREN:\n    - description: Purpose and scope of this test suite\n    - members: References to test cases in this suite\n\n    FOR LLMs:\n    - Generate test suite/describe blocks from test suites\n    - Use suite organization for test execution grouping\n    - Suites may map to test files or test classes\n  -->\n  <xs:complexType name="TestSuiteType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="members" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n  </xs:complexType>\n\n  <!--\n    TestCaseType: Individual verification item\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., TC-AUTH-001, TC-PERF-LOAD)\n    - type: Test category (TestType: acceptance/integration/unit/security/performance/inspection)\n    - title: Test name\n\n    CHILDREN:\n    - purpose: What this test verifies (the "why")\n    - steps: How to execute the test (the "how")\n    - expected: Expected outcome (the "what")\n    - refs: Links to requirements/scenarios being verified\n\n    FOR LLMs - TEST GENERATION BY TYPE:\n\n    acceptance:\n    - Generate from requirement acceptance criteria\n    - Use end-to-end test frameworks (Cypress, Playwright, etc.)\n    - Focus on user-facing behavior\n\n    integration:\n    - Test component interactions\n    - Use API testing tools\n    - Mock external dependencies appropriately\n\n    unit:\n    - Test individual functions/methods\n    - Use unit test frameworks (Jest, pytest, JUnit, etc.)\n    - Focus on logic correctness\n\n    security:\n    - Generate from SR requirements\n    - Include auth bypass attempts, injection tests, etc.\n    - Use security testing tools\n\n    performance:\n    - Generate from NFR requirements with metrics\n    - Use load testing tools (k6, JMeter, etc.)\n    - Include baseline and stress scenarios\n\n    inspection:\n    - Document manual review checklists\n    - Include compliance verification points\n    - May not generate automated code\n\n    TEST CASE EXAMPLE:\n    purpose: "Verify password reset flow works for valid users"\n    steps: "1. Request reset for valid email\n            2. Extract token from email\n            3. Submit new password with token"\n    expected: "Password is updated and user can login with new password"\n  -->\n  <xs:complexType name="TestCaseType">\n    <xs:sequence>\n      <xs:element name="purpose" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="steps" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="expected" type="TextBlockType" minOccurs="0"/>\n      <xs:element name="refs" type="RefsType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="type" type="TestType" use="required"/>\n    <xs:attribute name="title" type="xs:string" use="required"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Trace Section\n\n       Explicit relationships between all artifacts for impact analysis\n       and coverage tracking. This is the traceability matrix in graph form.\n\n       Aligned with IEEE 29148 traceability requirements.\n\n       FOR LLMs:\n       - Use traces to answer "what depends on this?" before making changes\n       - Use traces to verify coverage (every goal has satisfying requirements)\n       - Create traces when generating code (implements relationship)\n       - Maintain trace integrity when modifying documents\n       ========================= -->\n\n  <!--\n    TraceTypeContainer: Container for trace edges\n\n    Trace edges form a directed graph connecting all artifacts.\n    Use queries on this graph for impact analysis and coverage reports.\n  -->\n  <xs:complexType name="TraceTypeContainer">\n    <xs:sequence>\n      <xs:element name="traceEdge" type="TraceEdgeType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    TraceEdgeType: Individual traceability link\n\n    Supports both internal references (to elements within the RQML document) and\n    external references (to systems like Jira, Git, files, regulations, etc.).\n    At least one endpoint should be internal for the trace to be useful within RQML.\n\n    ATTRIBUTES:\n    - id: Unique identifier for this edge\n    - from: Source element ID within this document (keyref-validated)\n    - to: Target element ID within this document (keyref-validated)\n    - fromUri: Source as external URI (for tracing from external systems)\n    - toUri: Target as external URI (for tracing to external systems)\n    - type: Relationship type (TraceType)\n    - confidence: Certainty of this relationship (0.0-1.0)\n    - status: Lifecycle state (draft/review/approved/deprecated)\n    - createdBy: Who created this trace (person, role, or tool)\n    - createdAt: When this trace was created (ISO 8601 dateTime)\n    - tags: Space-separated category tags for filtering (e.g., "safety security")\n\n    ENDPOINT RULES:\n    - Use from/to for internal RQML elements (validated by schema)\n    - Use fromUri/toUri for external systems (not validated)\n    - At least one of from or fromUri should be specified\n    - At least one of to or toUri should be specified\n    - Can combine internal and external (e.g., from + toUri)\n\n    CHILDREN:\n    - notes: Explanation of why this relationship exists\n\n    EXTERNAL URI CONVENTIONS:\n    - Jira:        jira:PROJ-1234\n    - GitHub:      github:owner/repo/issues/42 or github:owner/repo/pull/99\n    - Git commit:  git:a1b2c3d4e5f6\n    - File:        file:src/auth/login.ts#L42-L87\n    - Confluence:  confluence:12345678\n    - Regulation:  urn:gdpr:article:17 or urn:iso27001:A.12.3\n    - Full URL:    https://jira.example.com/browse/PROJ-1234\n\n    FOR LLMs - COMMON TRACE PATTERNS:\n\n    Internal traces (within RQML):\n    - requirement satisfies goal: from="REQ-001" to="GOAL-001" type="satisfies"\n    - qgoal refines goal: from="QGOAL-001" to="GOAL-001" type="refines"\n    - obstacle threatens goal: from="OBS-001" to="GOAL-001" type="threatens"\n    - requirement mitigates risk: from="REQ-001" to="RISK-001" type="mitigates"\n    - testCase verifies requirement: from="TC-001" to="REQ-001" type="verifiedBy"\n    - requirement dependsOn requirement: from="REQ-002" to="REQ-001" type="dependsOn"\n    - goal conflictsWith goal: from="GOAL-001" to="GOAL-002" type="conflictsWith"\n\n    External traces (to/from external systems):\n    - requirement implements Jira story: from="REQ-001" toUri="jira:PROJ-1234" type="implements"\n    - code implements requirement: fromUri="file:src/auth.ts#L42" to="REQ-001" type="implements"\n    - git commit implements requirement: fromUri="git:a1b2c3d" to="REQ-001" type="implements"\n    - requirement satisfies regulation: from="REQ-GDPR-001" toUri="urn:gdpr:article:17" type="satisfies"\n    - external spec refines goal: fromUri="confluence:12345" to="GOAL-001" type="refines"\n\n    IMPACT ANALYSIS:\n    To find what\'s affected by changing element X:\n    1. Find all edges where from=X or to=X (internal) or fromUri/toUri match (external)\n    2. Recursively follow edges to find transitive impacts\n    3. Higher confidence edges indicate stronger impacts\n\n    COVERAGE ANALYSIS:\n    To verify all goals are addressed:\n    1. For each goal, find edges where to=goal_id and type=satisfies\n    2. Goals without satisfies edges are uncovered\n    3. Flag uncovered goals for stakeholder attention\n\n    LIFECYCLE MANAGEMENT:\n    - status=draft: Auto-generated or tentative traces awaiting verification\n    - status=review: Traces under stakeholder review\n    - status=approved: Confirmed traces that can be relied upon\n    - status=deprecated: Traces no longer valid but kept for audit history\n    - Use createdBy to track accountability (person, role, or tool like "import-jira")\n    - Use createdAt for audit trails and staleness detection\n    - Filter by status=approved for reliable impact analysis\n\n    CATEGORIZATION:\n    Use tags to categorize traces for filtering and reporting:\n    - safety: Functional safety traces (IEC 61508, ISO 26262)\n    - security: Security-related traces (ISO 27001, OWASP)\n    - compliance: Regulatory compliance traces (GDPR, HIPAA, SOX)\n    - performance: Performance requirement traces\n    - accessibility: Accessibility requirement traces (WCAG)\n    - Custom tags as needed for project-specific concerns\n    Example: tags="safety compliance" for a trace relevant to both domains\n  -->\n  <xs:complexType name="TraceEdgeType">\n    <xs:sequence>\n      <xs:element name="notes" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <!-- Internal references (keyref-validated when present) -->\n    <xs:attribute name="from" type="IdType"/>\n    <xs:attribute name="to" type="IdType"/>\n    <!-- External references (URI-based, for tracing to external systems) -->\n    <xs:attribute name="fromUri" type="xs:anyURI"/>\n    <xs:attribute name="toUri" type="xs:anyURI"/>\n    <xs:attribute name="type" type="TraceType" use="required"/>\n    <xs:attribute name="confidence" type="ConfidenceType"/>\n    <!-- Lifecycle metadata -->\n    <xs:attribute name="status" type="StatusType"/>\n    <xs:attribute name="createdBy" type="xs:string"/>\n    <xs:attribute name="createdAt" type="xs:dateTime"/>\n    <!-- Categorization -->\n    <xs:attribute name="tags" type="xs:NMTOKENS"/>\n  </xs:complexType>\n\n  <!-- =========================\n       Governance Section\n\n       Change control, accountability, and approval workflows.\n       Tracks issues to resolve and sign-offs obtained.\n\n       Aligned with ISO/IEC/IEEE 12207 configuration management.\n\n       FOR LLMs:\n       - Check governance/issues for open questions before implementing\n       - Approved documents are ready for implementation\n       - Issues may block requirements or indicate uncertainty\n       - Update governance when making document changes\n       ========================= -->\n\n  <!--\n    GovernanceType: Governance container\n\n    CHILDREN:\n    - issue: Open questions, concerns, or deviations\n    - approval: Sign-offs and authorizations\n  -->\n  <xs:complexType name="GovernanceType">\n    <xs:sequence>\n      <xs:element name="issue" type="IssueType" minOccurs="0" maxOccurs="unbounded"/>\n      <xs:element name="approval" type="ApprovalType" minOccurs="0" maxOccurs="unbounded"/>\n    </xs:sequence>\n  </xs:complexType>\n\n  <!--\n    IssueType: Open question or concern\n\n    Issues track things that need resolution: missing information,\n    conflicting requirements, deferred decisions, or risks.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., ISS-PCI, ISS-SCOPE, ISS-RESOURCE)\n    - status: Issue lifecycle (draft/review/approved/deprecated - where approved means resolved)\n    - owner: Person or role responsible for resolution\n\n    CHILDREN:\n    - statement: What needs to be addressed\n    - notes: Progress, context, or resolution details\n\n    FOR LLMs:\n    - Check issues before implementing - they may indicate blocking concerns\n    - Issues with status="review" need stakeholder input\n    - Resolved issues (status="approved") contain decisions to follow\n    - Create issues when encountering ambiguity during elicitation\n  -->\n  <xs:complexType name="IssueType">\n    <xs:sequence>\n      <xs:element name="statement" type="TextBlockType"/>\n      <xs:element name="notes" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n    <xs:attribute name="owner" type="xs:string" use="optional"/>\n  </xs:complexType>\n\n  <!--\n    ApprovalType: Sign-off record\n\n    Approvals track who has reviewed and accepted the specification.\n    Required for regulated environments and formal release processes.\n\n    ATTRIBUTES:\n    - id: Unique identifier (e.g., APR-SEC, APR-LEGAL, APR-PRODUCT)\n    - role: The role required to approve (not a specific person)\n    - status: Approval state (draft=pending, approved=obtained, deprecated=revoked)\n\n    CHILDREN:\n    - description: Scope of this approval (what is being approved)\n\n    FOR LLMs:\n    - Documents need approvals before implementation in regulated contexts\n    - Check approval status before treating requirements as final\n    - Different roles approve different aspects (security, legal, product, etc.)\n  -->\n  <xs:complexType name="ApprovalType">\n    <xs:sequence>\n      <xs:element name="description" type="TextBlockType" minOccurs="0"/>\n    </xs:sequence>\n    <xs:attribute name="id" type="IdType" use="required"/>\n    <xs:attribute name="role" type="xs:string" use="required"/>\n    <xs:attribute name="status" type="StatusType" use="optional"/>\n  </xs:complexType>\n\n</xs:schema>\n';