rosett-ai 1.3.3

data/conf/design/ci_pipeline.yml

@@ -0,0 +1,100 @@
+---
+name: ci_pipeline
+domain: ci
+version: 1.1.0
+status: implemented
+priority: 1
+author: hugo
+created_at: "2026-02-18"
+modified_at: "2026-03-17"
+modified_by: claude
+depends_on:
+  - security
+  - testing
+  - styles
+
+intent: |
+  Define the CI/CD pipeline that enforces security and testing constraints on
+  every code change. Without enforcement gates, security rules are suggestions,
+  not constraints. This pipeline must be in place before feature development
+  begins. It is the mechanism that ensures the security and testing design
+  documents are not just documentation but are actively enforced on every
+  commit and merge request.
+
+constraints:
+  - No code merges to main without passing all CI stages
+  - Security audit stage (bundler-audit, ruby_audit) must run first and block on any finding
+  - Static analysis (rubocop, reek) must block on any violation — no warnings-only mode
+  - Test stage must produce JUnit XML artifacts for GitLab integration
+  - Mutation testing runs on merge requests only (too slow for every push)
+  - Mutation testing must block merge if score drops below threshold
+  - Mutation testing timeout is 30 minutes maximum
+  - Coverage reports must be preserved as CI artifacts
+  - Pipeline must complete in under 15 minutes for push events (excluding mutation testing)
+  - No allow_failure on security or test stages
+
+acceptance_criteria:
+  - GitLab CI YAML is valid and passes rai validate-ci-yaml
+  - Pipeline has distinct stages in order — audit, lint, test, mutation, build
+  - bundler-audit check exits non-zero on known CVEs
+  - ruby_audit check exits non-zero on Ruby stdlib CVEs
+  - rubocop exits non-zero on any violation
+  - reek exits non-zero on any code smell above configured threshold
+  - flay exits non-zero on structural duplication above threshold
+  - flog exits non-zero on complexity above threshold (deferred — see ADR-001, covered by RuboCop Metrics cops)
+  - rspec produces JUnit XML report and coverage/ artifacts
+  - mutant runs only on merge_request_event and blocks merge on score drop
+  - Build stage produces .deb package artifact
+  - Pipeline duration is under 15 minutes for push events
+
+examples:
+  - scenario: "Developer pushes a commit with YAML.load in new code"
+    expected: |
+      Lint stage fails: RuboCop flags YAML.load as security violation.
+      Pipeline stops. Developer must fix to YAML.safe_load before re-pushing.
+    not: "Pipeline passes with a warning. Code merges with unsafe YAML parsing."
+  - scenario: "A gem dependency has a new CVE published"
+    expected: |
+      Next CI run fails at audit stage. bundler-audit reports the CVE with
+      advisory URL. Pipeline blocks. Developer updates gem or adds justified
+      exception to .bundler-audit.yml.
+    not: "CVE is silently ignored. Pipeline passes with vulnerable dependency."
+  - scenario: "Merge request adds new Compiler class with AI-generated tests"
+    expected: |
+      Push stages pass (audit, lint, unit test). Mutation stage runs on changed
+      files. If mutant score >= 85%, MR is mergeable. If score < 85%, MR is
+      blocked with mutation report showing surviving mutations.
+    not: "Mutation testing is skipped. MR merges without test quality validation."
+  - scenario: "Developer adds a new feature but forgets to write tests"
+    expected: |
+      SimpleCov minimum_coverage_by_file (80%) fails for the new file.
+      Pipeline blocks at test stage.
+    not: "Untested code merges. Coverage drops silently."
+
+anti_patterns:
+  - Using allow_failure on security or test stages
+  - Skipping stages with CI variables or manual overrides
+  - Running mutation testing on every push (too slow, blocks development)
+  - Not preserving test artifacts (coverage reports, JUnit XML)
+  - Hardcoding credentials or tokens in CI configuration
+  - Using --no-verify or equivalent to bypass pre-commit hooks
+  - Ignoring bundler-audit advisories without documented justification
+
+preferences:
+  language: ruby
+  patterns:
+    - fail_fast_pipeline
+    - artifacts_for_debugging
+    - merge_request_gates
+  gems:
+    - bundler-audit
+    - ruby_audit
+    - rubocop
+    - rubocop-performance
+    - rubocop-rspec
+    - reek
+    - flay
+    - rspec
+    - simplecov
+    - mutant-rspec
+    - rspec-junit-formatter

data/conf/design/claude_code_configuration.yml

@@ -0,0 +1,157 @@
+---
+name: claude_code_configuration
+domain: core
+version: 2.0.0
+status: implemented
+priority: 2
+author: hugo
+created_at: "2026-02-20"
+modified_at: "2026-03-17"
+modified_by: claude
+depends_on:
+  - security
+  - architecture
+  - compiler
+  - engine_architecture
+
+intent: |
+  Define a YAML-based authoritative configuration format for AI tool
+  settings that compiles to native format via the engine-plugin pattern.
+  Core provides the compilation framework (BaseConfigCompiler, SecretResolver,
+  MaskingSecretResolver, CompileResult) and CLI commands (rai config compile,
+  raictl config show). Each engine provides the domain-specific transformation
+  logic: scope routing, key mapping, version compatibility checks, and
+  format-specific output.
+
+  For Claude Code, the rosett-ai-engine-claude gem implements ConfigCompiler,
+  DomainTransformer, ScopeRouter, and KeyMap to compile scope YAML files
+  into Claude Code's native JSON settings across all four scopes (managed,
+  user, project, local). Other engines may implement config_compiler_class
+  to compile their own tool-specific settings.
+
+  The goal is a single source of truth (scope-specific YAML files maintained
+  by the engine) that eliminates manual JSON editing, enforces schema
+  validation, supports version compatibility assertions, and handles
+  secrets resolution without exposing sensitive values in source.
+
+constraints:
+  - All YAML files MUST be parseable with YAML.safe_load — no custom tags,
+    no permitted_classes, no extensions to the safe deserialisation surface
+  - Secret references use string convention "${secret:backend:key}" resolved
+    by deterministic string parser — never regex — to eliminate ReDoS vectors
+  - Secret resolution is single-pass only — resolved values are never
+    re-scanned for further references (prevents recursive injection)
+  - The secrets resolver MUST fail loudly (raise, never return nil) when a
+    referenced secret is missing or inaccessible
+  - File-backend secrets MUST validate 0600 permissions and reject files
+    owned by other users (prevent symlink/race attacks)
+  - File-backend secrets MUST enforce a size cap (64 KiB) to prevent
+    resource exhaustion from reading device files or oversized inputs
+  - Path-backend secrets MUST reject path traversal (no ".." components)
+    and validate against a whitelist of allowed directories
+  - Each YAML scope file compiles to exactly one native target — the
+    mapping is 1:1, never 1:many or many:1
+  - Configuration compilation follows the engine-plugin pattern — core
+    provides the abstract framework (BaseConfigCompiler), the engine
+    provides domain-specific transformation via config_compiler_class
+  - Core MUST NOT contain any engine-specific key mappings, scope routes,
+    or domain transformation logic — these belong in the engine gem
+  - No design or implementation in this document may contradict the security
+    design document (conf/design/security.yml)
+
+acceptance_criteria:
+  # Core framework criteria
+  - rai config compile delegates to the active engine's config_compiler_class
+    via the plugin registry (RosettAi::Plugins::Registry)
+  - BaseConfigCompiler provides schema validation, SHA256 diffing, file I/O,
+    and compile result tracking that all engines inherit
+  - SecretResolver resolves ${secret:env:*}, ${secret:file:*}, and
+    ${secret:path:*} references using deterministic string parsing (no regex)
+  - MaskingSecretResolver replaces all ${secret:*} values with "***" without
+    resolving actual secrets, used by rai config show
+  - The --simulate flag shows a diff of what would change in each target
+    file without writing anything
+  - The --verbose flag shows processing details during compilation
+  - CompileResult struct tracks scope, paths, json_data, warnings, action,
+    and diff for each compiled file
+  - Missing secrets cause compilation to abort with a clear error message
+    naming the missing reference and the file where it was declared
+  - No regex is used anywhere in the secrets resolution path
+  # Engine-side criteria (satisfied by rosett-ai-engine-claude)
+  - Engine provides ConfigCompiler, DomainTransformer, ScopeRouter, and
+    KeyMap classes that handle Claude Code-specific compilation
+  - Engine's ScopeRouter maps scope names to target file paths (managed,
+    user, project, local)
+  - Engine's DomainTransformer converts YAML domains to JSON using an
+    explicit KeyMap (snake_case to camelCase, not algorithmic)
+  - Engine checks version compatibility constraints against the installed
+    Claude Code version at compile time (warnings, not errors)
+  - RSpec tests exist for the compiler, schema validation, and secrets
+    resolver with mutant-verified kill rates
+
+examples:
+  - scenario: User compiles their personal configuration
+    expected: >
+      "bin/raictl config compile" resolves the active engine via the plugin
+      registry, delegates to the engine's ConfigCompiler, resolves any
+      secret references, and writes the native settings file.
+    not: >
+      The compiler silently overwrites settings without showing what
+      changed, or leaves secret reference strings unresolved in the output
+
+  - scenario: A secret reference points to an unset environment variable
+    expected: >
+      Compilation aborts with "Error: secret 'env:ANTHROPIC_API_KEY'
+      could not be resolved — environment variable ANTHROPIC_API_KEY
+      is not set"
+    not: >
+      The compiler writes a file containing the literal string
+      "${secret:env:ANTHROPIC_API_KEY}" or a null/empty value
+
+  - scenario: No engine provides a config_compiler_class
+    expected: >
+      "bin/raictl config compile" raises an error explaining that the
+      active engine does not support configuration compilation
+    not: >
+      The command silently does nothing or crashes with a NoMethodError
+
+  - scenario: A crafted input attempts ReDoS via nested secret patterns
+    expected: >
+      The deterministic string parser processes it in O(n) time.
+      "${secret:env:${secret:env:NESTED}}" is treated as a literal string
+      because it does not match the exact prefix/suffix pattern
+    not: >
+      The parser enters catastrophic backtracking or hangs
+
+  - scenario: User runs config compile --simulate
+    expected: >
+      A diff is shown for each target file (additions in green, removals
+      in red) without writing any files to disk
+    not: >
+      Files are modified during simulation, or no output is shown
+
+anti_patterns:
+  - Using regex for secret reference detection or resolution — use
+    deterministic string parsing (start_with?/end_with?/split) only
+  - Storing actual secret values in YAML source files, even temporarily
+  - Using YAML custom tags (!secret, !vault, etc.) which require
+    permitted_classes and widen the safe_load deserialisation surface
+  - Putting engine-specific key mappings or scope routes in core — these
+    belong in the engine gem
+  - Recursively resolving secret references (resolved values must never
+    be re-scanned for further ${secret:...} patterns)
+  - Silently ignoring missing secrets (returning nil or empty string)
+  - Writing compiled files when the source YAML has not changed
+    (wasteful I/O and misleading timestamps)
+
+preferences:
+  language: ruby
+  testing: rspec with factory_bot and mutant-rspec
+  gems:
+    - psych
+    - json_schemer
+    - diffy
+  patterns:
+    - compiler_pattern
+    - resolver_pattern
+    - engine_plugin_delegation

data/conf/design/compiler.yml

@@ -0,0 +1,128 @@
+---
+name: compiler
+domain: compiler
+version: 2.0.0
+status: draft
+priority: 2
+author: hugo
+created_at: "2026-02-18"
+modified_at: "2026-03-23"
+modified_by: claude
+depends_on:
+  - security
+  - architecture
+  - scope_hierarchy
+
+intent: |
+  Define the compilation pipeline that transforms source documents (behaviours,
+  design specs, locale files) into target-specific output formats. This is the
+  core product capability of Rosett-AI: author once in the richest format, compile
+  down per AI target. The compiler must be pluggable to support new AI models
+  without code changes, and must enforce security constraints during all file
+  operations (safe YAML parsing, path validation, permission setting).
+
+  Compilation is scope-aware: the compiler resolves source directories from the
+  active scope hierarchy (global, local, project) before operating. Source files
+  are discovered from scope-appropriate directories, merged according to the
+  configured merge strategies, and written to scope-appropriate output locations
+  as declared by each engine's target profile. CLI flags (--global, --local,
+  --project) allow users to force a specific scope; without flags, the scope is
+  auto-detected from the user's working directory. See scope_hierarchy.yml for
+  the full scope specification.
+
+constraints:
+  - All YAML parsing must use YAML.safe_load with explicit permitted_classes
+  - All output file writes must validate target path is within allowed directories
+  - All output files must be written with explicit permissions (0644)
+  - Compiler backends are pluggable via conf/targets/ profiles
+  - Source documents (conf/behaviour/, conf/design/) are never modified by compilation —
+    the sole exception is `rai retrofit`, which writes to source directories as a
+    controlled reverse-compilation operation (see retrofit.yml)
+  - Compilation must be idempotent (running twice produces identical output)
+  - Dry-run mode (--simulate) must never write to disk
+  - Verbose mode must never expose secrets or API keys in output
+  - Compilation errors must identify the source file and line/field that caused the error
+  - Locale compilation must produce platform-native formats (gettext, Qt Linguist)
+  - Compilation is scope-aware — source directories are resolved from the active
+    scope hierarchy (see scope_hierarchy.yml)
+  - CLI flags --global, --local, --project select a specific scope; without flags,
+    scope is auto-detected from the working directory
+  - "Each engine's target profile declares output directories: an absolute path
+    for global output and a relative path for scoped (local/project) output.
+    The compiler resolves the relative path against the active scope directory"
+  - Output target directory is never hardcoded — it is resolved from the engine's
+    target profile and the active scope
+
+acceptance_criteria:
+  - bin/raictl compile produces output files in scope-resolved output directories
+    (e.g. ~/.claude/rules/ for global scope, <project>/.claude/rules/ for project scope)
+  - bin/raictl compile --engine claude produces CLAUDE.md-compatible markdown rules
+  - bin/raictl compile --engine generic produces lowest-common-denominator markdown
+  - bin/raictl compile --simulate --verbose shows scope-resolved source directories,
+    target output paths, and diffs — without writing any files
+  - bin/raictl compile --vendor writes a lockfile recording compiled state
+  - bin/raictl compile --locales compiles ruby-i18n YAML to gettext and Qt formats
+  - Adding a new target profile in conf/targets/ requires no code changes
+  - Invalid source documents produce clear error messages identifying the problem
+  - Compilation of 100 behaviour files completes in under 5 seconds
+  - bin/raictl compile --global compiles only global-scope sources to global output
+  - bin/raictl compile --local compiles merged global+local sources to local output
+  - bin/raictl compile --project compiles merged global+local+project sources to project output
+  - bin/raictl compile (no flag) auto-detects scope from working directory
+  - Compiler resolves source directory from the active scope before reading any files
+  - "Each engine's target profile declares output directories (global absolute,
+    scoped relative) — see scope_hierarchy.yml and engine_architecture.yml"
+
+examples:
+  - scenario: "User runs bin/raictl compile from a project directory"
+    expected: |
+      Resolves scope from working directory: discovers project, local (if present),
+      and global source directories. Merges sources per scope hierarchy. Compiles
+      to project-scope output directory (e.g. <project>/.claude/rules/).
+      Sets 0644 permissions. Reports count of compiled rules and active scope.
+    not: "Ignores working directory. Always compiles from rosett-ai's own conf/."
+  - scenario: "User runs bin/raictl compile --engine mistral"
+    expected: |
+      Reads conf/targets/mistral.yml for model capabilities. Compiles behaviours
+      to flat markdown format (no YAML in prompt). Truncates or chunks if output
+      exceeds max_context. Writes to configured output location.
+    not: "Uses Claude-specific formatting for Mistral. Ignores context window limits."
+  - scenario: "A behaviour file has invalid YAML syntax"
+    expected: |
+      Compilation stops for that file. Error message includes filename and
+      parse error details. Other valid files still compile. Exit code is non-zero.
+    not: "YAML.load is used and succeeds despite syntax issues. Error is swallowed."
+  - scenario: "User runs bin/raictl compile --simulate --verbose"
+    expected: |
+      Shows scope resolution: 'Scope: project (~/projects/acme-api/.rosett-ai/)'.
+      Shows source directories per scope. Shows diff of what would change
+      on disk at scope-resolved output paths. Zero files written. Exit code 0.
+    not: "Actually writes files despite --simulate flag. Omits scope information."
+  - scenario: "User runs bin/raictl compile --global"
+    expected: |
+      Compiles only global-scope sources (~/.config/rosett-ai/conf/) to global
+      output directories. Local and project scopes are ignored even if
+      .rosett-ai/ markers exist in the current directory tree.
+    not: "Merges all scopes. Project-specific rules appear in global output."
+
+anti_patterns:
+  - Using YAML.load instead of YAML.safe_load during compilation
+  - Writing output to arbitrary paths without validation
+  - Modifying source documents during compilation
+  - Hardcoding AI model assumptions instead of reading target profiles
+  - Silently skipping invalid source documents without error reporting
+  - Non-idempotent compilation (different output on repeated runs with same input)
+  - Hardcoding output directory (e.g. ~/.claude/rules/) instead of resolving from scope
+  - Assuming a single fixed source directory for all invocations
+  - Ignoring --global/--local/--project flags
+
+preferences:
+  language: ruby
+  patterns:
+    - strategy_pattern_for_target_backends
+    - pipeline_pattern_for_compilation_stages
+    - value_objects_for_compiled_output
+  testing: rspec with file-based fixtures for input/output validation
+  gems:
+    - json_schemer
+    - diffy

data/conf/design/comply.yml

@@ -0,0 +1,153 @@
+---
+name: comply
+domain: security
+version: 0.1.0
+status: implemented
+priority: 2
+author: hugo
+created_at: "2026-03-15"
+modified_at: "2026-03-16"
+modified_by: claude
+depends_on:
+  - security
+  - licensing_system
+  - policy_management
+  - error_handling
+  - engine_architecture
+#
+intent: |
+  Automate compliance checks for EU CRA and NIS2 directives, GPL-3.0
+  licensing requirements, and organisational policy adherence. Surface
+  compliance gaps before release rather than after deployment by providing
+  CRA vulnerability disclosure verification, SBOM generation, SPDX header
+  checks, and dependency license auditing through a single `rai comply`
+  command with machine-readable output for CI integration.
+
+  SBOM generation is a core capability: `rai comply --sbom` produces a
+  CycloneDX JSON document from Gemfile.lock and system metadata using the
+  syft CLI (when available) or a built-in Ruby fallback that parses
+  Gemfile.lock directly. The SBOM includes component name, version, PURL,
+  license SPDX identifier, and supplier. SPDX-format output is also
+  supported via `--sbom-format spdx` for organisations that mandate SPDX
+  over CycloneDX. SBOM output is written to a configurable path (default
+  `sbom.cdx.json` or `sbom.spdx.json` in the project root).
+
+  Comply is the compliance verification layer. It runs checks against
+  declarative rules. Policy management (policy_management.yml) defines
+  what policies apply to a project. Comply verifies that the project
+  meets those policies and produces an auditable report.
+#
+constraints:
+  - "CRA checks must not require network access by default — offline SBOM
+    analysis"
+  - "License audit must detect GPL-incompatible dependencies in the full
+    dependency tree"
+  - "SPDX header verification must support Ruby, YAML, JSON, Bash, and
+    Markdown files"
+  - "Output must be machine-readable (JSON/YAML) for CI integration and
+    TTY-aware (formatted table when interactive, structured data when piped)"
+  - "Must not store or transmit any proprietary compliance data"
+  - "Compliance rules must be declarative YAML, not hardcoded"
+  - "SBOM generation must work offline using Gemfile.lock as primary source —
+    syft CLI is optional (used when available for richer metadata)"
+  - "SBOM output must conform to CycloneDX 1.5 JSON schema or SPDX 2.3 JSON
+    schema depending on --sbom-format flag"
+  - "SBOM must include PURL (Package URL) identifiers for all components"
+  - "Exit code must distinguish pass (0), warning (1), and failure (2)
+    for CI pipelines"
+  - "This design governs compliance verification (checking adherence).
+    Policy definition and governance is handled by policy_management.yml.
+    Licensing system mechanics are handled by licensing_system.yml"
+#
+acceptance_criteria:
+  - "`rai comply` runs all compliance checks and produces a summary report"
+  - "`rai comply --cra` checks CRA-specific requirements (SBOM, vulnerability
+    policy)"
+  - "`rai comply --license` audits dependency licenses against GPL-3.0
+    compatibility"
+  - "`rai comply --headers` verifies SPDX headers on all source files"
+  - "`rai comply --format json` outputs machine-readable results"
+  - "CI pipeline can gate releases on compliance check exit code"
+  - "Compliance rules are loaded from conf/compliance/*.yml"
+  - "`rai comply --sbom` generates a CycloneDX 1.5 JSON SBOM from Gemfile.lock"
+  - "`rai comply --sbom --sbom-format spdx` generates an SPDX 2.3 JSON SBOM"
+  - "SBOM includes component name, version, PURL, license SPDX ID, and supplier"
+  - "SBOM generation works offline without syft (Ruby fallback parser)"
+  - "TTY-aware summary shows pass/warn/fail counts in colour when
+    interactive, plain counts when piped"
+  - "Exit code 0 on all pass, 1 on warnings only, 2 on any failure"
+#
+examples:
+  - scenario: "Developer runs `rai comply` before tagging a release"
+    expected: |
+      All checks pass; SBOM is current; all files have SPDX headers.
+      Summary: 12 checks passed, 0 warnings, 0 failures.
+    not: "Missing headers silently ignored or only warned about"
+  - scenario: "A new gem dependency has an AGPL-3.0 license"
+    expected: |
+      License audit flags it as potentially GPL-incompatible and explains
+      why: 'AGPL-3.0 imposes network copyleft obligations that may conflict
+      with GPL-3.0-only. Review and add to allowlist or replace dependency.'
+    not: "Silent acceptance of incompatible licenses"
+  - scenario: "Running in CI without internet access"
+    expected: |
+      Offline checks complete successfully using cached SBOM data.
+      Network-dependent checks (e.g. NVD lookup) are skipped with warning.
+    not: "Failure because NVD or other remote service is unreachable"
+  - scenario: "Developer generates SBOM for CRA compliance"
+    expected: |
+      `rai comply --sbom` produces sbom.cdx.json in CycloneDX 1.5 format.
+      Each component includes name, version, PURL, and license. Output
+      validates against the CycloneDX JSON schema.
+    not: |
+      SBOM generation requires internet access. Missing gems are silently
+      omitted. Output is an invalid CycloneDX document.
+  - scenario: "Compliance report in CI pipeline"
+    expected: |
+      `rai comply --format json` outputs structured results parseable by
+      CI tools. Exit code 2 triggers pipeline failure. Report includes
+      each check's name, status, and resolution guidance.
+    not: "Human-readable text output that CI cannot parse."
+#
+anti_patterns:
+  - "Hardcoding compliance rules in Ruby — use declarative YAML configs"
+  - "Requiring internet access for basic compliance checks"
+  - "Treating warnings as informational-only — they must have a clear
+    resolution path"
+  - "Mixing legal advice into tool output — report facts, not interpretations"
+  - "Coupling compliance checks to a specific engine's config format"
+#
+gui_notes: |
+  Document interactions (cross-references):
+
+  1. policy_management.yml: policies define what applies; comply verifies
+     adherence and produces reports.
+
+  2. licensing_system.yml: licensing mechanics (key management, activation).
+     Comply checks license compatibility of dependencies.
+
+  3. security.yml: comply enforces security-adjacent requirements (SPDX
+     headers, vulnerability disclosure).
+
+  4. error_handling.yml: exit codes and structured error messages follow
+     the error hierarchy.
+
+  5. engine_architecture.yml: compliance rules may reference engine
+     capabilities or engine-specific outputs.
+
+  6. distribution.yml: comply gates release publishing — CI runs comply
+     before deploy:publish.
+#
+preferences:
+  language: ruby
+  patterns:
+    - "Command pattern for individual check types"
+    - "Declarative YAML for compliance rule definitions"
+    - "Array-form system() for any shell-out to SBOM tools"
+    - "TTY-aware output (TtyHelper)"
+  testing: rspec with compliance rule fixtures, license compatibility
+    scenarios, SPDX header detection, and CI output format tests
+  gems:
+    - license_finder
+    - json_schemer
+    - thor

data/conf/design/content_packs.yml

@@ -0,0 +1,84 @@
+---
+name: content_packs
+domain: licensing
+version: 1.1.0
+status: implemented
+priority: 4
+author: hugo
+created_at: "2026-02-18"
+modified_at: "2026-03-17"
+modified_by: claude
+depends_on:
+  - security
+  - licensing_system
+  - compiler
+
+intent: |
+  Define the premium content pack system that delivers curated behaviours,
+  design patterns, and AI target profiles to licensed users. Content packs
+  are signed tarballs of YAML files with manifests, downloaded from a content
+  server and cached locally. The system must work offline after initial
+  download. Content packs are licensed under the NeatNerds Content License
+  (separate from GPL-3.0), and are data consumed by the software, not
+  derivative works of it.
+
+constraints:
+  - Content packs are signed with the same Ed25519 key pair used for license keys
+  - Content pack signatures must be verified before installation
+  - Content is stored locally in ~/.config/rosett-ai/premium/ after download
+  - Content packs must work offline after initial download
+  - Content pack manifests are YAML validated against schema
+  - Tier entitlement is checked before download (not after)
+  - Content packs are YAML files — no executable code in packs
+  - Content pack installation must not modify core rosett-ai files or configuration
+  - All content pack YAML must be parsed with YAML.safe_load
+
+acceptance_criteria:
+  - bin/raictl content list shows available packs for current license tier
+  - bin/raictl content list --available shows packs at all tiers (with tier labels)
+  - bin/raictl content install security_pack downloads, verifies, and installs pack
+  - bin/raictl content update re-downloads all installed packs (subscriber tier)
+  - Signature verification rejects tampered content packs
+  - Installed packs work without internet after download
+  - Content pack manifest schema exists in conf/schemas/
+  - bin/raictl compile integrates premium behaviours alongside core behaviours
+
+examples:
+  - scenario: "Supporter installs the security_behaviours content pack"
+    expected: |
+      License tier verified (supporter >= supporter). Pack downloaded from
+      content server. Ed25519 signature verified. Tarball extracted to
+      ~/.config/rosett-ai/premium/security_behaviours/. Manifest validated.
+      'Installed security_behaviours v2.1.0 (4 behaviours, 2 designs).'
+    not: "Pack installed without signature check. Arbitrary code executed from pack."
+  - scenario: "Community user tries to install a supporter-tier pack"
+    expected: |
+      'security_behaviours requires Supporter tier. Your tier: Community.
+      Visit https://neatnerds.be/rosett-ai/pricing for upgrade options.'
+    not: "Pack downloads but fails silently. Error message is unclear about tier."
+  - scenario: "Content pack tarball has been tampered with"
+    expected: "Ed25519 signature verification fails. 'Content pack signature invalid. Pack not installed.'"
+    not: "Tampered pack is installed. YAML with unexpected content is loaded."
+  - scenario: "Subscriber runs bin/raictl content update while offline"
+    expected: "Graceful failure: 'Cannot reach content server. Existing content packs unchanged.'"
+    not: "Crash. Existing content deleted. Error without explanation."
+
+anti_patterns:
+  - Including executable code (Ruby, shell) in content packs
+  - Installing packs without signature verification
+  - Requiring internet on every rosett-ai run to validate content
+  - Deleting local content when server is unreachable
+  - Mixing premium content with core rosett-ai files
+  - Using YAML.load to parse content pack files
+
+preferences:
+  language: ruby
+  gems:
+    - faraday
+    - ed25519
+    - minitar
+  patterns:
+    - offline_first_caching
+    - signed_content_distribution
+    - schema_validated_manifests
+  testing: rspec with fixtures for valid, tampered, and unsigned packs