rosett-ai 1.3.3

data/conf/design/ui_framework.yml

@@ -0,0 +1,111 @@
+---
+name: ui_framework
+domain: ui
+version: 1.1.0
+status: implemented
+priority: 3
+author: hugo
+created_at: "2026-02-18"
+modified_at: "2026-03-17"
+modified_by: claude
+depends_on:
+  - architecture
+  - accessibility
+  - i18n
+
+intent: |
+  Define the pluggable UI framework that allows rosett-ai to run as a TUI application
+  by default, with optional GUI frontends installed as separate Debian packages.
+  The abstract UI interface (lib/rosett_ai/ui/base.rb) defines the contract that all
+  implementations must fulfill, including accessibility methods and i18n support.
+  GUI layers must follow their platform's Human Interface Guidelines — rosett-ai does
+  not impose a uniform look across toolkits.
+
+constraints:
+  - TUI is the default and must work on any terminal supporting UTF-8
+  - GUI packages are separate Debian packages with correct dependency declarations
+  - lib/rosett_ai/ui/base.rb defines the interface — all implementations must satisfy shared_examples
+  - GUI implementations must follow platform HIG (GNOME HIG for GTK4, KDE HIG for Qt6)
+  - All interactive elements must be keyboard-accessible in all UI variants
+  - Accessible mode (--accessible) provides linear, screen-reader-friendly output
+  - No business logic in UI layer — UI calls into lib/rosett_ai/ for all domain operations
+  - Qt 6 is the current major release (not Qt 5)
+
+acceptance_criteria:
+  - lib/rosett_ai/ui/base.rb exists with documented abstract methods
+  - shared_examples "a UI implementation" passes for TUI implementation
+  - TUI mode works without X11/Wayland on a headless server
+  - Accessible mode (--accessible) produces linear text output
+  - Assistive tech auto-detection (ORCA_RUNNING, BRLTTY_TTY) defaults to accessible mode
+  - text_direction method returns correct direction based on current locale
+  - announce method is defined for screen reader live-region announcements
+  - All interactive elements have keyboard bindings documented
+
+examples:
+  - scenario: "Blind user launches rosett-ai with Orca screen reader running"
+    expected: |
+      ORCA_RUNNING env var detected. Accessible mode auto-enabled.
+      Output is linear text with structured headings. No box drawing characters.
+      Screen reader announces navigation and state changes.
+    not: "ncurses-style box drawing confuses Orca. User must manually pass --accessible."
+  - scenario: "Developer creates new rosett-ai-gtk4 package"
+    expected: |
+      Implements all methods from RosettAi::UI::Base. Passes shared_examples
+      'a UI implementation'. Registers via RosettAi::UI::Registry. Uses
+      GtkAccessible for all widgets. Follows Adwaita styling.
+    not: "Skips accessibility methods. Reimplements business logic. Uses custom styling."
+  - scenario: "User switches from TUI to GTK4 mid-session"
+    expected: "bin/raictl --ui gtk4 launches fresh GTK4 session. State is read from config, not transferred."
+    not: "Hot-swapping UI while running. Shared mutable state between UI instances."
+
+anti_patterns:
+  - Business logic in UI code
+  - GUI-specific code in core package
+  - Ignoring platform HIG to create uniform cross-toolkit appearance
+  - Hardcoding terminal escape codes instead of using tty-* gem abstractions
+  - Skipping accessibility contract methods in new UI implementations
+  - Using Qt 5 instead of Qt 6
+
+accessibility:
+  roles:
+    - element: "config_form"
+      role: "form"
+      label: "Settings and configuration input areas"
+    - element: "main_menu"
+      role: "navigation"
+      label: "Menu and command navigation structures"
+    - element: "status_bar"
+      role: "status"
+      label: "Status indicators and progress feedback"
+  keyboard:
+    - key: "Tab"
+      action: "Move focus to next interactive element (handled by TTY gems)"
+    - key: "Enter"
+      action: "Activate focused element (handled by TTY gems)"
+    - key: "Escape"
+      action: "Cancel or close current dialog (handled by TTY gems)"
+    - key: "Arrow keys"
+      action: "Navigate within lists and menus (handled by TTY gems)"
+  announcements:
+    - event: "state_change"
+      announce: "State changes announced via announce() method"
+      priority: "polite"
+    - event: "error"
+      announce: "Error conditions announced with assertive priority"
+      priority: "assertive"
+    - event: "progress"
+      announce: "Progress updates announced with polite priority"
+      priority: "polite"
+
+preferences:
+  language: ruby
+  gems:
+    - tty-prompt
+    - tty-table
+    - tty-spinner
+    - pastel
+    - gtk4 (rosett-ai-gtk4 package only)
+  patterns:
+    - abstract_interface_with_shared_examples
+    - plugin_registry_with_auto_discovery
+    - presenter_pattern

data/conf/design/usage_optimization.yml

@@ -0,0 +1,122 @@
+---
+name: usage_optimization
+domain: operations
+version: 0.1.0
+status: draft
+priority: 6
+author: hugo
+created_at: "2026-03-04"
+modified_at: "2026-03-16"
+modified_by: claude
+depends_on:
+  - architecture
+  - compiler
+  - error_handling
+
+intent: |
+  Ensure the Rosett-AI CLI remains fast, memory-efficient, and scalable as the
+  engine count and configuration corpus grow.  Startup must feel instant
+  (<200ms), compile must skip unchanged files via content-addressed caching,
+  and RSS must stay bounded.  These targets protect the developer experience
+  on modest hardware (CI runners, laptops, Raspberry Pi) and prevent
+  performance regressions from creeping in unnoticed.  Profiling must be
+  trivially activatable so bottlenecks are caught before they ship.
+
+  A benchmark suite (spec/benchmarks/) provides per-command performance targets
+  and automated regression detection in CI. Each command has a documented
+  time budget (e.g., version <200ms, compile <500ms, validate <300ms). The
+  benchmark suite runs in CI on merge requests and fails if any command
+  exceeds its budget by more than 20%. This catches performance regressions
+  before they reach main.
+
+constraints:
+  - CLI startup (from exec to first Thor dispatch) must complete in under 200ms on warm cache
+  - Compile caching uses SHA256 content checksums stored at ~/.cache/rosett-ai/compile/ (XDG_CACHE_HOME)
+  - Cache format is a single JSON manifest mapping source path to {sha256, output_path, compiled_at}
+  - Zeitwerk lazy loading is already in use — no eager_load calls outside of test/CI
+  - Peak RSS must stay below 100MB for a full compile of all engines
+  - Parallelism strategy is Ractor first, concurrent-ruby fallback (per future-parallelism.md)
+  - Parallelism is deferred until validation exceeds 2 seconds or 100 files
+  - No new runtime dependencies — caching and profiling use stdlib only
+  - Backward compatible — cached and uncached compiles produce identical output
+  - --no-cache flag bypasses the cache for a single invocation
+  - RAI_PROFILE=1 enables profiling output (command timing breakdown to stderr)
+  - Cache invalidation is automatic — changed source SHA256 triggers recompile
+  - Incremental compilation only recompiles files whose source or dependencies changed
+  - Benchmark suite must define per-command time budgets with a 20% tolerance margin
+  - Benchmark results must be comparable across runs (use monotonic clock, warm JIT)
+  - CI benchmark job must fail if any command exceeds its budget
+
+acceptance_criteria:
+  - bin/raictl version completes in under 200ms (measured via time command)
+  - bin/raictl compile writes a cache manifest to $XDG_CACHE_HOME/rosett-ai/compile/manifest.json
+  - Second consecutive compile skips unchanged files and completes faster than first
+  - --no-cache flag forces full recompile regardless of cache state
+  - Cache manifest entries include source_sha256, output_path, compiled_at fields
+  - Stale cache entries (source file deleted) are pruned on next compile
+  - RAI_PROFILE=1 prints per-phase timing to stderr (load, validate, compile, write)
+  - Peak RSS during full compile of 10 engines stays below 100MB
+  - Zeitwerk loader.ignore prevents autoloading of unused engine modules
+  - No Ractor or thread code is introduced until the parallelism trigger is met
+  - Cache directory respects XDG_CACHE_HOME when set, defaults to ~/.cache/rosett-ai/
+  - spec/benchmarks/ contains per-command benchmark scripts with documented budgets
+  - CI runs benchmarks on merge requests and fails on budget violations
+
+examples:
+  - scenario: First compile after clean cache
+    expected: |
+      All source files are compiled.  Cache manifest is written with SHA256
+      for each source file.  Output identical to pre-cache behaviour.
+    not: |
+      Cache is written but compile output differs from uncached compile.
+      Manifest contains absolute paths that break on different machines.
+  - scenario: Second compile with no source changes
+    expected: |
+      Compiler reads manifest, computes SHA256 of each source, finds all
+      match, skips compilation, exits quickly.  "Nothing to compile" message
+      in verbose mode.
+    not: |
+      All files are recompiled despite no changes.  Cache is ignored.
+  - scenario: One behaviour file is modified between compiles
+    expected: |
+      Only the modified file (and files depending on it) are recompiled.
+      Other cached outputs are reused.  Manifest is updated with new SHA256.
+    not: |
+      All files are recompiled.  Unchanged outputs are rewritten to disk.
+  - scenario: Developer runs with RAI_PROFILE=1
+    expected: |
+      Stderr shows timing breakdown:
+      [profile] load: 45ms | validate: 12ms | compile: 89ms | write: 8ms | total: 154ms
+    not: |
+      Profiling output goes to stdout and breaks piped commands.
+      Profiling adds more than 5ms of overhead.
+
+  - scenario: CI benchmark detects performance regression
+    expected: |
+      Benchmark suite runs version, compile, validate commands 5 times each.
+      Median time is compared against budget: version <200ms, compile <500ms,
+      validate <300ms. If compile takes 650ms (exceeds 500ms + 20% = 600ms),
+      CI job fails with: "FAIL: compile exceeded budget (650ms > 600ms limit)".
+    not: |
+      Performance regression merges to main undetected. Benchmarks only run
+      locally. Budget violations are warnings instead of failures.
+
+anti_patterns:
+  - Caching compiled output without checksumming the source (stale cache risk)
+  - Using mtime instead of content hash for change detection (unreliable across git operations)
+  - Eager-loading all engine modules at startup (violates lazy loading)
+  - Introducing concurrent-ruby as a runtime dependency before parallelism is needed
+  - Storing cache in the project directory (pollutes git status)
+  - Caching without a --no-cache escape hatch (debugging nightmare)
+  - Memory-mapping large files without bounds (RSS explosion)
+  - Profiling always-on even when RAI_PROFILE is unset (overhead)
+
+preferences:
+  language: ruby
+  patterns:
+    - content_addressed_caching
+    - sha256_checksums
+    - xdg_cache_paths
+    - lazy_loading_zeitwerk
+    - monotonic_clock_profiling
+  gems: []

data/conf/design/version_management.yml

@@ -0,0 +1,60 @@
+---
+name: version_management
+domain: ci
+version: 1.1.0
+status: implemented
+priority: 1
+author: hugo
+created_at: "2026-02-23"
+modified_at: "2026-03-17"
+modified_by: claude
+depends_on:
+  - ci_pipeline
+  - lifecycle_management
+
+intent: >-
+  Any software modification that touches version upgrades (Ruby, gems, or
+  other dependencies) must pass quality checks before merging. The primary
+  gate is `rai tooling check-versions`, which verifies that all version
+  references across the codebase are consistent with canonical sources
+  (.ruby-version, Gemfile.lock). This check is enforced in both CI and
+  pre-commit hooks to prevent stale version strings from reaching the
+  remote repository.
+
+constraints:
+  - "`rai tooling check-versions` must pass in CI before merge"
+  - "`check-versions` must run as an overcommit pre-commit hook"
+  - "Ruby version consistency: all MAJOR.MINOR.PATCH references must match .ruby-version"
+  - "Gem version consistency: resolved versions in Gemfile.lock are the canonical source"
+  - "Inline suppression (`rai:no-version-check`) is the only way to exempt a line"
+  - "Historical version references in documentation must use inline suppression, not directory-level exclusions"
+
+acceptance_criteria:
+  - "`rai tooling check-versions` detects stale Ruby version references"
+  - "`rai tooling check-versions --gems` detects stale gem version references"
+  - "Overcommit pre-commit hook blocks commits with version mismatches"
+  - "CI pipeline fails on version mismatches"
+  - "Lines with `rai:no-version-check` are skipped"
+  - "Constraint patterns (~>, >=, etc.) are not flagged as mismatches"
+
+examples:
+  - scenario: "Developer upgrades Ruby from 3.3.10 to 3.3.12"
+    expected: "check-versions flags any remaining 3.3.10 references in docs/code"
+    not: "3.3.10 in CHANGELOG.md or conf/design/ triggers a false positive"
+  - scenario: "LaTeX document describes historical upgrade from 3.3.8 to 3.3.10"
+    expected: "Line has `% rai:no-version-check` and is skipped"
+    not: "Entire doc/reference/src/ is excluded from checks"
+  - scenario: "Gemfile.lock resolves thor at 1.5.0 but README says thor 1.4"
+    expected: "check-versions --gems flags the stale gem reference"
+
+anti_patterns:
+  - "Excluding entire directories to silence version mismatches"
+  - "Using --no-verify to bypass pre-commit version checks"
+  - "Hardcoding gem versions in documentation instead of referencing Gemfile.lock"
+
+preferences:
+  language: ruby
+  patterns:
+    - "Inline suppression for intentional exceptions"
+    - "Array-form system() for all shell commands"
+  testing: rspec

data/conf/design/workflow.yml

@@ -0,0 +1,227 @@
+---
+name: workflow
+domain: core
+version: 0.1.0
+status: implemented
+priority: 3
+author: hugo
+created_at: "2026-03-15"
+modified_at: "2026-03-16"
+modified_by: claude
+depends_on:
+  - architecture
+  - engine_architecture
+  - behaviour_composition
+  - security
+  - error_handling
+  - git_hooks
+#
+intent: |
+  Provide repeatable, composable AI-assisted workflows that can be shared
+  across projects and teams. Define and execute multi-step workflows (e.g.
+  "review-and-fix", "refactor-with-tests", "translate-locale") as declarative
+  YAML at three scopes: global (~/.config/rosett-ai/workflows/), local
+  (.rosett-ai/workflows/), and project (.rosett-ai/conf/workflows/). Compose behaviours,
+  engine capabilities, and typed steps (shell, rosett-ai, prompt) into auditable,
+  reproducible sequences — replacing ad-hoc prompt chaining with governed
+  automation.
+
+  Workflows complement git hooks (git_hooks.yml) but serve a distinct purpose:
+  git hooks automate reactions to git lifecycle events (pre-commit, post-merge),
+  while workflows orchestrate multi-step sequences that may or may not involve
+  git. A git hook may trigger a workflow (e.g. post-merge runs the "sync-config"
+  workflow), but workflows are independently invocable and not tied to git events.
+#
+constraints:
+  - "Workflow definitions must be declarative YAML — no embedded Ruby or shell
+    in the YAML. Shell execution occurs only in shell-type steps via array-form
+    commands"
+  - "Shell steps use array-form execution only — no string interpolation or
+    shell expansion"
+  - "Workflows must declare required engine capabilities upfront"
+  - "Each step must be independently skippable and resumable"
+  - "Workflow execution must produce an audit log (who, what, when, which engine)"
+  - "Local workflows override global workflows of the same name"
+  - "Project workflows override local workflows of the same name"
+  - "Workflows must not access network unless explicitly declared via
+    network_required: true at the workflow or step level"
+  - "Each workflow step must declare its type: shell (array-form command),
+    raictl (CLI subcommand), or prompt (AI query). Unrecognised step types
+    are rejected at validation time"
+  - "Workflows must have a configurable maximum step count (default 50) to
+    prevent runaway definitions. Validation rejects workflows exceeding the
+    limit"
+  - "Prompt-type steps must not contain literal secrets or API key references
+    — only ${secret:env:NAME} placeholders. Prompt content is subject to
+    injection review during validation"
+  - "Prompt-type steps produce an audit hash (SHA-256 of prompt content +
+    engine + timestamp) for reproducibility and provenance tracking"
+  - "Steps using remote engines must declare network_required: true — failure
+    to declare this produces a warning (error in --strict mode)"
+  - "This design governs workflow definition, execution, scoping, and audit.
+    Git hook integration (which git events trigger which commands) is governed
+    by git_hooks.yml. Workflows may be invoked by hooks but are independently
+    defined and not coupled to git lifecycle events"
+  - "Each step in a workflow may specify an engine override, allowing a single
+    workflow to use different engines for different steps (e.g. Ollama for
+    local analysis, Claude for generation)"
+#
+acceptance_criteria:
+  - "`rai workflow list` shows available workflows from all three scopes"
+  - "`rai workflow run NAME` executes a workflow with the default engine"
+  - "`rai workflow run NAME --engine claude` executes with a specific engine"
+  - "`rai workflow validate NAME` checks workflow YAML against schema"
+  - "`rai workflow create NAME` scaffolds a new workflow from template"
+  - "Workflow audit log records each step execution with timestamp and outcome"
+  - "Scope precedence is enforced: project > local > global"
+  - "`rai workflow run NAME --resume` continues from the first incomplete step,
+    skipping previously completed steps based on the audit log"
+  - "`rai workflow run NAME --simulate` performs a dry run showing which steps
+    would execute, their types, and engine assignments without side effects"
+  - "Exit code 0 on success, 1 on step execution failure, 2 on validation
+    error, 3 on missing workflow, 5 on missing engine dependency"
+#
+examples:
+  - scenario: "Team shares a 'code-review' workflow via project .rosett-ai/conf/workflows/"
+    expected: "All team members get the same review workflow; it appears in `rai workflow list`"
+    not: "Each developer defines their own version of the same workflow"
+  - scenario: "A workflow step requires capability 'code_generation' but the engine lacks it"
+    expected: "Clear error before execution starts, listing missing capabilities"
+    not: "Failure mid-workflow when the step actually runs"
+  - scenario: "Developer resumes a partially completed workflow"
+    expected: |
+      `rai workflow run translate-locale --resume` reads the audit log,
+      identifies steps 1-3 as completed, and continues from step 4.
+      --verbose shows: 'Skipping step 1 (completed 2026-03-15T10:00:00Z)'
+    not: "Entire workflow re-runs from scratch. No way to resume."
+  - scenario: "Workflow uses mixed step types"
+    expected: |
+      steps:
+        - name: lint
+          type: shell
+          command: ["bundle", "exec", "rubocop", "--autocorrect"]
+        - name: compile
+          type: rai
+          command: compile --verbose
+        - name: review
+          type: prompt
+          engine: claude
+          prompt: "Review the changes for security issues"
+          network_required: true
+      Each step type is validated differently: shell checks array-form,
+      raictl checks valid subcommand, prompt checks for secret leakage.
+    not: |
+      All steps are treated identically. Shell commands use string-form.
+      Prompt content is not validated for secrets.
+  - scenario: "Developer dry-runs a workflow before execution"
+    expected: |
+      `rai workflow run deploy-config --simulate` outputs:
+        Step 1/4: [shell] lint — bundle exec rubocop
+        Step 2/4: [rai] compile — compile --engine claude
+        Step 3/4: [prompt] review — (claude, network_required: true)
+        Step 4/4: [shell] commit — git commit -m "..."
+      No files are modified, no commands execute.
+    not: "Dry-run silently executes shell commands. No preview available."
+  - scenario: "A shell step fails mid-workflow"
+    expected: |
+      Workflow stops at the failed step. Audit log records the failure.
+      `rai workflow run NAME --resume` can be used after fixing the issue
+      to continue from the failed step.
+    not: |
+      Workflow continues after failure. No audit trail of the failure.
+      Developer must re-run the entire workflow from scratch.
+  - scenario: "Shell step uses string-form command"
+    expected: |
+      `rai workflow validate NAME` rejects the workflow: 'Step "deploy"
+      uses string-form shell command — must be array-form for security'.
+    not: "String-form command is accepted and executed with shell expansion."
+  - scenario: "Multi-engine workflow with per-step engine selection"
+    expected: |
+      steps:
+        - name: analyze
+          type: prompt
+          engine: ollama
+          prompt: "Analyze this file for patterns"
+        - name: generate
+          type: prompt
+          engine: claude
+          prompt: "Generate refactored version"
+          network_required: true
+      Each step uses its declared engine. Engine capability is validated
+      per-step, not just at the workflow level.
+    not: |
+      All steps must use the same engine. No way to mix local and remote
+      engines in a single workflow.
+#
+anti_patterns:
+  - "Embedding Ruby code in workflow YAML definitions"
+  - "Workflows that cannot be interrupted and resumed"
+  - "Implicit network access during workflow execution"
+  - "Monolithic workflows that cannot be composed from smaller units"
+  - "String-form shell commands that allow injection"
+  - "Prompt steps containing literal API keys or secrets"
+  - "Workflows that silently skip failed steps"
+  - "Coupling workflow definitions to specific git events instead of
+    keeping them independently invocable"
+  - "Assuming all workflow steps use the same engine — multi-engine
+    workflows are a first-class use case"
+#
+gui_notes: |
+  Document interactions (cross-references):
+
+  1. git_hooks.yml: hooks may trigger workflows but are independently
+     defined. Hooks automate git lifecycle; workflows orchestrate steps.
+
+  2. behaviour_composition.yml: workflows compose behaviours as inputs.
+     Scope precedence (project > local > global) is consistent between
+     workflows and behaviours.
+
+  3. engine_architecture.yml: workflow steps reference engine capabilities.
+     Per-step engine selection leverages the engine manifest contract.
+
+  4. security.yml: shell steps use array-form execution. Prompt steps
+     are validated for secret leakage and injection patterns.
+
+  5. error_handling.yml: workflow errors (step failure, missing engine,
+     validation) follow the structured error hierarchy (exit codes,
+     what/why/fix format).
+
+  6. compiler.yml: workflows may invoke compilation as an rai-type step.
+     Workflows are not part of the compilation pipeline themselves.
+
+  Workflow YAML schema outline:
+    name: string (unique identifier)
+    description: string
+    version: string (semver)
+    author: string
+    scope: global | local | project
+    network_required: boolean (default false)
+    engine: string (default engine, overridable per step)
+    required_capabilities: [string]
+    max_steps: integer (default 50)
+    steps:
+      - name: string
+        type: shell | rosett-ai | prompt
+        command: [string] (shell) | string (rai)
+        prompt: string (prompt type only)
+        engine: string (optional override)
+        network_required: boolean
+        skip_if: string (condition expression)
+        on_failure: stop | continue | retry(n)
+    audit:
+      log_path: string (default .rosett-ai/logs/workflows/)
+      retention_days: integer (default 90)
+#
+preferences:
+  language: ruby
+  patterns:
+    - "Step executor pattern with pluggable step types"
+    - "Scope resolution chain (project > local > global)"
+    - "Structured audit logging"
+    - "Per-step engine selection"
+    - "Resume from audit log"
+  testing: rspec with workflow fixture YAML files, step executor mocks,
+    resume/dry-run scenarios, and multi-engine workflow integration tests
+  gems:
+    - json_schemer
+    - thor

data/conf/mcp/server_defaults.yml

@@ -0,0 +1,42 @@
+# frozen_string_literal: false
+# Default MCP server configuration for Rosett-AI.
+#
+# Override per-project via .rosett-ai-mcp.yml or per-user via
+# ~/.config/rosett-ai/mcp/server.yml.
+---
+http:
+  port: 8484
+  host: localhost
+  authentication:
+    type: api_key
+    key_source: auto
+    keyfile_path: rosett-ai-mcp-keys.yml
+    api_key_env: RAI_MCP_API_KEY
+  origin:
+    allowed_origins:
+      - "http://localhost:*"
+      - "http://127.0.0.1:*"
+    strict_mode: false
+  rate_limiting:
+    enabled: true
+    unauthenticated_rpm: 60
+    authenticated_rpm: 300
+  cors:
+    enabled: false
+    origins: []
+    methods:
+      - POST
+      - GET
+      - DELETE
+    headers:
+      - Content-Type
+      - Authorization
+      - Accept
+      - Mcp-Session-Id
+    max_age: 86400
+  max_request_size: 1048576
+  content_type_enforcement: true
+  tls:
+    enabled: false
+    cert_path: null
+    key_path: null

data/conf/mcp/trust.yml

@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-3.0-only
+# Copyright (C) 2026 Hugo Antonio Sepulveda Manriquez / NeatNerds
+#
+# Default trust sources for MCP server installation.
+# Users can add custom trusted domains via `rai mcp trust-sources add DOMAIN`.
+---
+trust_sources:
+  # NeatNerds Enterprise Manager (default trusted)
+  - domain: enterprise.neatnerds.be
+    type: enterprise
+    description: NeatNerds Enterprise Manager
+
+  # Goose project registry (community-vetted)
+  - domain: registry.block.xyz
+    type: registry
+    description: Goose MCP server registry
+
+  # Localhost is trusted by default for local development servers
+  - domain: localhost
+    type: local
+    description: Local development servers

data/conf/packaging/core.yml

@@ -0,0 +1,12 @@
+---
+name: rosett-ai
+variant: core
+description: >-
+  Rosett-AI — pluggable platform for AI-assisted development workflows
+ui_adapter: tui
+system_dependencies:
+  - libc6
+  - libssl3
+  - zlib1g
+  - libyaml-0-2
+package_dependencies: []

data/conf/packaging/gtk4.yml

@@ -0,0 +1,11 @@
+---
+name: rosett-ai-gtk4
+variant: gtk4
+description: >-
+  Rosett-AI — GTK4 desktop interface
+ui_adapter: gtk4
+system_dependencies:
+  - libgtk-4-1
+package_dependencies:
+  - name: rosett-ai
+    version: "current"

data/conf/packaging/qt6.yml

@@ -0,0 +1,11 @@
+---
+name: rosett-ai-qt6
+variant: qt6
+description: >-
+  Rosett-AI — Qt6 desktop interface
+ui_adapter: qt6
+system_dependencies:
+  - qt6-base
+package_dependencies:
+  - name: rosett-ai
+    version: "current"