thoth-agents 0.2.11 → 0.3.1

package/src/skills/sdd-design/SKILL.md

@@ -1,155 +0,0 @@
----
-name: sdd-design
-description: Create `design.md` as a technical solution design with architecture decisions and file changes.
----
-
-# SDD Design Skill
-
-Create the technical solution design that explains how the approved spec will
-be built. OpenSpec `design.md` is a technical approach artifact covering
-implementation architecture, tradeoffs, and repository patterns.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- Proposal and specs exist and implementation planning needs technical depth
-- A prior design needs to be revised after spec changes
-
-This phase is not a UI/UX design task. Do not route this phase to the designer
-agent because it is named `design`; the default implementation owner is a
-technical write-capable role such as `deep`.
-
-## Prerequisites
-
-- `change-name`
-- Proposal artifact
-- Spec artifact
-- Access to the repository code that will change
-
-## Workflow
-
-1. Read the shared conventions.
-2. Recover `sdd/{change-name}/proposal` and `sdd/{change-name}/spec` using the
-   retrieval protocol in
-   the persistence contract.
-3. If revising work, recover `sdd/{change-name}/design` with the same
-   mode-aware retrieval rules.
-4. Read the actual code paths affected by the change before deciding on an
-   approach.
-5. If the selected mode includes OpenSpec, write
-   `openspec/changes/{change-name}/design.md` using this structure. In
-   `thoth-mem` mode, produce the same content without creating the file:
-
-   ```md
-   # Design: {Change Title}
-
-   ## Technical Approach
-   ## Architecture Decisions
-   ### Decision: {Title}
-   **Choice**:
-   **Alternatives considered**:
-   **Rationale**:
-   ## Data Flow
-   ## File Changes
-   ## Interfaces / Contracts
-   ## Testing Strategy
-   ## Migration / Rollout
-   ## Open Questions
-   ```
-
-6. If the selected mode includes thoth-mem, persist the design with:
-
-   Use the memory tool binding for `mem_save` with the canonical SDD topic key
-   and required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-## Optional Sub-Artifacts
-
-Beyond the always-present `design.md`, `sdd-design` MAY produce optional plan
-sub-artifacts. They are gated by BOTH conditions, config as the hard floor and
-author judgment within the gate:
-
-- **Hard gate (config)**: `rules.design.sub_artifacts` MUST be `true`. When
-  `false` or absent, NO sub-artifacts are ever produced (back-compat default).
-- **Complexity gate (config threshold, author-evaluated)**: when enabled, the
-  change MUST meet `rules.design.complexity_threshold` (e.g. `affected_domains`,
-  `affected_files`, `external_research` — eligible when ANY trigger is met). The
-  threshold is the reviewable hard floor; the author still selects which (if any)
-  sub-artifacts add value within the gate. An eligible change MAY still produce
-  zero sub-artifacts.
-
-`design.md` is ALWAYS produced regardless of the gate. The optional types are:
-
-- `research.md` — only when there is genuine unknown investigation.
-- `data-model.md` — only when there is a non-trivial data shape.
-- `contracts/` (subdir) — only when there are interfaces to pin; follow the
-  `checklists/` subdir as the precedent for change-dir subdirectory layout.
-- `quickstart.md` — only when a runnable smoke path helps.
-
-Note: the `clarify` phase now precedes design (`spec -> clarify -> design`), so
-design consumes the already-clarified spec.
-
-## Constitution Check and Handoff Hints
-
-    ### Consume upstream handoffHints
-
-    At design start, surface the spec phase's `handoffHints` (recorded
-    `## Assumptions` and `[NEEDS CLARIFICATION]` resolutions) and treat them as
-    constraints the design must preserve. When the spec declared no hints, surface
-    nothing. Surfacing is gated by `rules.handoffs.surface_hints`.
-
-    ### Constitution Check self-review
-
-    Before finalizing the design, run a Constitution Check self-review: evaluate the
-    emerging design against EACH principle in `openspec/memory/constitution.md` —
-    delegate-first coordination, read-only role boundaries, governed persistence,
-    multi-harness parity, and evidence-led verification. Report any principle the
-    design would violate.
-
-    - On a detected violation, BLOCK finalization and surface the violated
-      principle through the harness blocking-input surface (the
-      AskUserQuestion-equivalent primitive). An explicit user override MUST be
-      logged with the violated principle before proceeding. Gated by
-      `rules.constitution.enforce_check`; when disabled, note the skip and do not
-      block.
-    - This self-review does not replace `plan-reviewer`'s independent Constitution
-      Check; both run. See `_shared/openspec-convention.md` (Constitution
-      Governance, Handoff Hints) for the canonical, harness-agnostic semantics.
-
-    ## Output Format
-
-Return:
-
-- `Change`
-- `Artifact`: `openspec/changes/{change-name}/design.md`
-- `Topic Key`: `sdd/{change-name}/design`
-- `Key Decisions`: concise bullet list
-- `Files Planned`: created, modified, deleted paths
-- `Next Step`: `sdd-tasks`
-
-## Rules
-
-- Base the design on the actual codebase, not generic assumptions.
-- Do not route this phase to the designer agent. `sdd-design` itself always
-  stays with the technical write-capable agent.
-- Later `sdd-apply` tasks may route to the designer agent when the work is
-  specifically user-facing UI, visual work, screenshots, or visual QA.
-- Every architecture decision must include rationale.
-- Use concrete file paths and interfaces.
-- Keep implementation details aligned with the spec and repository patterns.
-- Retrieve full dependencies with the protocol in the persistence contract.

package/src/skills/sdd-init/SKILL.md

@@ -1,233 +0,0 @@
----
-name: sdd-init
-description: Bootstrap OpenSpec structure and SDD context for a project.
-metadata:
-  author: gentleman-programming
-  version: "1.0"
----
-
-# SDD Init Skill
-
-Initialize SDD for a project by detecting local conventions, creating the
-minimal OpenSpec structure when needed, and persisting startup context.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist initialization context to thoth-mem only — do NOT create
-  or modify `openspec/` files.
-- `openspec`: create or update OpenSpec structure only — do NOT call thoth-mem
-  save tools.
-- `hybrid`: do both (default).
-
-## When to Use
-
-- SDD is needed but `openspec/` is not initialized
-- `openspec/` exists but is stale: missing `config.yaml` mechanism sections
-  (`constitution` / `consistency` / `requirements_quality` / `clarification` /
-  `handoffs`), missing `tasks.traceability` / `tasks.parallel_markers` /
-  `design.sub_artifacts` / `design.complexity_threshold` / `verify` toggles, or a
-  missing `openspec/memory/constitution.md`
-- A new project needs initial OpenSpec conventions
-- The team wants detected stack/context captured before `sdd-propose`
-
-## Prerequisites
-
-- Project root path
-- Project name
-- Selected persistence mode (default: `hybrid`)
-
-## Workflow
-
-1. Read the shared conventions before initializing.
-2. Detect project stack and conventions from repository files:
-   - Stack indicators: `package.json`, `go.mod`, `pyproject.toml`,
-     `requirements.txt`, `Cargo.toml`, `pom.xml`, `build.gradle`,
-     `composer.json`.
-   - Testing indicators: `vitest.config.*`, `jest.config.*`,
-     `playwright.config.*`, `pytest.ini`, `tox.ini`, `go test` conventions,
-     `Cargo.toml` test crates.
-   - Style indicators: `biome.json`, `.eslintrc*`, `eslint.config.*`,
-     `.prettierrc*`, `ruff.toml`, `.golangci.*`, `rustfmt.toml`.
-   - CI indicators: `.github/workflows/*`, `.gitlab-ci.yml`,
-     `azure-pipelines.yml`, `.circleci/config.yml`.
-   - Architecture hints: common layout markers such as `apps/`, `packages/`,
-     `services/`, `src/`, `cmd/`, `internal/`.
-3. Build concise config context (max 10 lines) using detected values. Use
-   `unknown` for missing signals.
-4. If the selected mode includes OpenSpec (`openspec` or `hybrid`), check
-   whether these already exist:
-   - `openspec/config.yaml`
-   - `openspec/specs/`
-   - `openspec/changes/`
-5. If the required OpenSpec paths already exist, do not dead-end. Compute
-   whether the project is fully aligned or stale, then realign additively:
-   - **Fully aligned** (all paths present AND `config.yaml` already carries
-     every mechanism section / toggle AND `openspec/memory/constitution.md`
-     exists) -> report a no-op and return. Never overwrite by default.
-   - **Stale / partial** (any piece below is absent) -> proceed to the
-     additive backfill in steps 5a-5c. Never overwrite a value that is
-     already present.
-
-    5a. Compute the per-piece *absent set* (detect each independently; treat a
-        partially-present `openspec/` per-piece, not all-or-nothing):
-        - missing `openspec/specs/`
-        - missing `openspec/changes/` (and `changes/archive/`)
-        - missing `config.yaml` mechanism sections: `constitution`,
-          `consistency`, `requirements_quality`, `clarification`, `handoffs`
-        - missing `config.yaml` toggles: `rules.tasks.traceability`,
-          `rules.tasks.parallel_markers`, `rules.design.sub_artifacts`,
-          `rules.design.complexity_threshold`,
-          `rules.verify` (`test_command` / `build_command` /
-          `coverage_threshold`)
-        - missing `openspec/memory/constitution.md`
-
-    5b. For each absent piece, additively create or merge ONLY that piece using
-        the canonical shapes defined in step 7 (`config.yaml`) and step 7a
-        (`constitution.md`). Merge missing `config.yaml` sections into the
-        existing file, preserving every present key and value verbatim. Never
-        rewrite a value that is already present. Never renumber or recreate an
-        existing `constitution.md` (see step 7a idempotency).
-
-    5c. Report exactly what was added (list each created path and each merged
-        `config.yaml` section / toggle). If the absent set was empty, report a
-        no-op instead.
-6. If any required OpenSpec path is missing and mode includes OpenSpec, create
-   only the minimum structure:
-
-   ```text
-   openspec/
-   ├── config.yaml
-   ├── specs/
-   └── changes/
-       └── archive/
-   ```
-
-7. Generate `openspec/config.yaml` dynamically with this shape:
-
-       ```yaml
-       schema: spec-driven
-
-       context: |
-         Tech stack: {detected}
-         Architecture: {detected}
-         Testing: {detected}
-         Style: {detected}
-
-       rules:
-         proposal:
-           - Include rollback plan for risky changes
-           - Identify affected modules/packages
-         spec:
-           - Use RFC 2119 keywords (MUST, SHALL, SHOULD, MAY)
-           - Use Given/When/Then scenarios
-         design:
-           guidance:
-             - Document architecture decisions with rationale
-             - Require a File Changes section
-           sub_artifacts: false        # optional design sub-artifacts (default off)
-           complexity_threshold:       # author-evaluated eligibility triggers (OR)
-             affected_domains: 3
-             affected_files: 12
-             external_research: true
-         tasks:
-           guidance:
-             - Group tasks by phase with hierarchical numbering
-             - Keep tasks small enough to complete in one session
-           tdd: false                  # TDD ordering flag (sdd-tasks-format)
-           traceability: true          # require [USN] + Spec: tag + Independent Test per task
-           parallel_markers: false     # [P] emission + executing-plans consumption (default off)
-         apply:
-           guidance:
-             - Follow existing code patterns and conventions
-           test_command: ''
-         verify:
-           test_command: ''
-           build_command: ''
-           coverage_threshold: 0
-         archive:
-           - Warn before merging destructive deltas
-
-         # --- mechanism sections (spec-kit-rigor) ---
-         constitution:
-           path: openspec/memory/constitution.md
-           enforce_check: true         # Constitution Check gate blocks on violation
-           version_policy: semver      # MAJOR=remove/redefine, MINOR=add, PATCH=clarify
-         consistency:
-           enforce_block: true         # CRITICAL findings block plan-review
-           require_coverage_percentage: true
-         requirements_quality:
-           enforce_block: true         # incomplete checklist blocks tasks phase
-           dimensions: [completeness, clarity, measurability, testability]
-         clarification:
-           max_markers_per_spec: 3     # [NEEDS CLARIFICATION] cap enforced by plan-reviewer
-         handoffs:
-           surface_hints: true         # surface SddPhaseContract.handoffHints at transitions
-       ```
-
-       Mixing bare `- item` list entries with `key: value` scalars under one key is
-       invalid YAML; when a phase carries scalar toggles (`tasks`, `apply`,
-       `verify`), put its guidance strings under a `guidance:` subkey.
-
-    7a. Bootstrap the project constitution at `openspec/memory/constitution.md`
-        (mode includes OpenSpec):
-        - **Absent** -> create it at `Version: 1.0.0` with `Ratified`/`Last-Amended`
-          dates, the five native principles (delegate-first coordination, read-only
-          role boundaries, governed persistence, multi-harness parity, evidence-led
-          verification) each with Statement/Rationale/Gate Implications, and an empty
-          `## Sync-Impact Report` section.
-        - **Present** -> preserve the existing content AND its existing version
-          unchanged; do NOT recreate or renumber it. This step is idempotent: a
-          second `sdd-init` run on a repo whose `constitution.md` is at `2.1.0`
-          leaves it at `2.1.0`.
-        - **Semver bump policy** (manual, by whoever edits the constitution): MAJOR
-          = a principle removed or redefined; MINOR = a principle added or guidance
-          materially expanded; PATCH = clarification/wording. Each edit also appends
-          a `## Sync-Impact Report` entry. No tooled auto-bump exists.
-        - See `_shared/openspec-convention.md` (Constitution Governance) for the
-          canonical artifact and gate semantics.
-
-8. Never create placeholder SDD artifacts (`proposal.md`, `design.md`,
-   `tasks.md`, or spec files) during initialization.
-9. If the selected mode includes thoth-mem (`thoth-mem` or `hybrid`), persist
-   the detected context and initialization status with:
-
-   ```text
-   Use the memory tool binding for `mem_save` with the canonical topic key and
-   required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-10. In `hybrid` mode, initialization is complete only when both OpenSpec setup
-    and thoth-mem persistence succeed.
-
-## Output Format
-
-Return:
-
-- `Project`
-- `Mode`
-- `Detected Context`: stack, architecture, testing, style, CI
-- `OpenSpec Status`: initialized, already initialized, or skipped by mode
-- `Created Paths`: list of directories/files created (if any)
-- `Topic Key`: `sdd-init/{project-name}` when mode includes thoth-mem
-- `Next Step`: usually `sdd-propose`
-
-## Rules
-
-- Realignment is strictly additive: when `openspec/` already exists, backfill
-  only the absent pieces and NEVER overwrite a value that is already present.
-- An existing `constitution.md` is never renumbered or recreated; create it
-  only when absent and otherwise preserve its content and version unchanged.
-- A re-run on a fully-aligned project is a reported no-op (no writes).
-- In `thoth-mem` mode, never create `openspec/` directories or files.
-- Keep `config.yaml` context concise (max 10 lines).
-- Detect and include CI, test, and style conventions in the context summary.
-- Never create placeholder spec/change files during init.

package/src/skills/sdd-propose/SKILL.md

@@ -1,101 +0,0 @@
----
-name: sdd-propose
-description: Create or update `proposal.md` for an OpenSpec change.
----
-
-# SDD Propose Skill
-
-Create the proposal artifact for a change and persist it with thoth-mem.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- A change needs its first `proposal.md`
-- An existing proposal must be refined after new requirements
-
-## Prerequisites
-
-- A `change-name`
-- User intent, problem statement, or prior exploration notes
-- Project name for thoth-mem persistence
-
-## Workflow
-
-1. Read the shared conventions before drafting.
-2. If the change already exists, recover the latest proposal using the
-   retrieval protocol from the persistence contract.
-3. Review relevant main specs under the active OpenSpec path to avoid
-   proposing contradictions.
-4. If the selected mode includes OpenSpec, write
-   `openspec/changes/{change-name}/proposal.md` using this shape. In
-   `thoth-mem` mode, produce the same content without creating the file:
-
-   ```md
-   # Proposal: {Change Title}
-
-   ## Intent
-   ## Scope
-   ### In Scope
-   ### Deferred / Needs Discovery
-   ### Out of Scope
-   ## Approach
-   ## Affected Areas
-   ## Risks
-   ## Rollback Plan
-   ## Success Criteria
-   ```
-
-5. If the selected mode includes thoth-mem, persist the full proposal with:
-
-   Use the memory tool binding for `mem_save` with the canonical SDD topic key
-   and required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-6. In `hybrid` mode, both the filesystem artifact and thoth-mem save must
-   succeed.
-
-## Output Format
-
-Return a short report with:
-
-- `Change`: change name
-- `Artifact`: `openspec/changes/{change-name}/proposal.md`
-- `Topic Key`: `sdd/{change-name}/proposal`
-- `Summary`: 2-4 bullets covering intent, scope, and major risks
-- `Next Step`: `sdd-spec` (full pipeline) or `sdd-tasks` (accelerated pipeline)
-
-## Rules
-
-- Use canonical OpenSpec filenames only.
-- Keep the proposal focused on why, scope, and success criteria.
-- Preserve the original user intent and product goal in proposal scope. Do not
-  silently shrink broad goals such as full UX redesigns.
-- Describe material behavior changes with `From`, `To`, `Reason`, and `Impact`
-  when applicable.
-- Use `Deferred / Needs Discovery` for unresolved affected areas that are still
-  part of the accepted goal.
-- Keep `Out of Scope` disciplined: include only explicit exclusions, rejected
-  options, ownership-separated future work, or deliberately deferred phases.
-- Do not move parts of the stated user goal to `Out of Scope` only because the
-  implementation path is unknown.
-- Always include rollback guidance and explicit out-of-scope items when they
-  exist.
-- Never reference engram.
-- Never rely on compact recall output alone when the mode uses thoth-mem.
-  Use `mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
-  `mem_get(id=...)` to retrieve the full artifact body.

package/src/skills/sdd-spec/SKILL.md

@@ -1,136 +0,0 @@
----
-name: sdd-spec
-description: Write OpenSpec delta specs with RFC 2119 language and GWT scenarios.
----
-
-# SDD Spec Skill
-
-Write or update the change specifications for one or more affected domains.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- A proposal is approved and must be converted into testable requirements
-- Existing change specs need to be expanded or corrected
-
-> Boundary: residual ambiguity that surfaces after spec authoring is resolved by
-> the `sdd-clarify` phase (between `spec` and `design`), not here — spec
-> authoring behavior itself is unchanged.
-
-## Prerequisites
-
-- `change-name`
-- The proposal artifact must exist
-- Access to any current main specs for impacted domains
-
-## Workflow
-
-1. Read the shared conventions.
-2. Recover the proposal using the retrieval protocol in
-   the persistence contract.
-3. If the change already has spec work, recover `sdd/{change-name}/spec` with
-   the same mode-aware retrieval rules before editing.
-4. Read `openspec/specs/{domain}/spec.md` for each affected domain to determine
-   whether you are writing a delta spec or a brand-new spec.
-5. If the selected mode includes OpenSpec, write canonical change artifacts
-   under `openspec/changes/{change-name}/specs/{domain}/spec.md`. In
-   `thoth-mem` mode, produce the same canonical content without creating files.
-6. Use this structure in every spec file:
-
-   ```md
-   # Delta for {Domain}
-
-   ## ADDED Requirements
-   ### Requirement: {Name}
-   The system MUST ...
-
-   #### Scenario: {Name}
-   - GIVEN ...
-   - WHEN ...
-   - THEN ...
-
-   ## MODIFIED Requirements
-   ## REMOVED Requirements
-   ```
-
-   For a brand-new domain, write a full spec instead of a delta.
-
-7. If the selected mode includes thoth-mem, persist the complete spec payload
-   with:
-
-   Use the memory tool binding for `mem_save` with the canonical SDD topic key
-   and required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-## Clarification Discipline and Requirements-Quality Checklist
-
-    Follow these mechanisms (canonical definitions in
-    `_shared/openspec-convention.md` — Clarification Discipline and
-    Requirements-Quality Checklist). All are gated by their `config.yaml rules:`
-    sections.
-
-    ### `[NEEDS CLARIFICATION]` markers and Assumptions
-
-    - Use `[NEEDS CLARIFICATION: <concrete question>]` ONLY for a genuine decision
-      fork where no single default is defensible. The marker text MUST name the
-      specific unresolved decision, not a vague placeholder.
-    - Cap markers at `rules.clarification.max_markers_per_spec` (default 3) per spec
-      file.
-    - Informed-guess-first: when an ambiguity has a defensible default, APPLY the
-      default and record it in an `## Assumptions` section of the spec rather than
-      emitting a marker. Do not silently default a genuine fork.
-
-    ### Generate `checklists/requirements.md`
-
-    At or after authoring the delta specs, generate
-    `openspec/changes/{change-name}/checklists/requirements.md` ("unit tests for
-    English"):
-
-    - One `## Domain: {domain}` section per authored delta domain.
-    - Each domain section carries checkbox items across the four dimensions:
-      completeness, clarity, measurability, testability.
-    - Items use the task checkbox states (`- [ ]` / `- [x]` / `- [-] waived:
-      reason`).
-    - The spec->tasks transition is gated on every item being `- [x]` or explicitly
-      waived (gated by `rules.requirements_quality.enforce_block`).
-
-    ### Declare handoffHints
-
-    Declare `handoffHints` for the design phase: the recorded `## Assumptions` and
-    any unresolved `[NEEDS CLARIFICATION]` resolutions the design phase must
-    preserve. Surfacing is gated by `rules.handoffs.surface_hints`.
-
-    ## Output Format
-
-Return:
-
-- `Change`
-- `Artifacts`: list of domain spec paths written
-- `Checklist`: `openspec/changes/{change-name}/checklists/requirements.md`
-- `Topic Key`: `sdd/{change-name}/spec`
-- `Coverage Summary`: requirements and scenarios added or modified
-- `Next Step`: usually `sdd-design`
-
-## Rules
-
-- Every requirement must use RFC 2119 keywords.
-- Every requirement must have at least one Given/When/Then scenario.
-- Specs describe behavior, not implementation details.
-- Keep domain boundaries explicit.
-- Use the retrieval protocol from the persistence contract for every SDD
-  dependency.