rust-as-spec IDP Platform Cell (v3.3.15)

TL;DR: A governed Rust service template where specs, tests, docs, policies, and CI all agree — and the repo can prove it.

Kernel baseline: v3.3.9-kernel This tag freezes the Rust-as-Spec kernel template (specs, ACs, xtask contracts, and /platform/* introspection). Forks inherit this baseline and extend it with domain-specific stories, requirements, and services. See docs/how-to/adopt-kernel.md for adoption instructions.

---

For IDPs / platform teams: This repo is a Rust service cell template that:

• Exposes /platform/* introspection APIs and cargo xtask idp-snapshot for IDP tiles
• Guarantees 65 kernel ACs via tier1-selftest + CI enforcement
• Ships a stable kernel contract at v3.3.9-kernel
• Validates cell readiness via cargo xtask kernel-status

See IDP Cell Contract for the full integration datasheet.

5-minute trust check: How to Trust a Cell

15-minute audit path: docs/audit/AUDIT_PATH.md — How to verify changes via receipts, not line-by-line review

---

What This Is

A governed Rust template with:

• A running platform app — HTTP service with /platform/* introspection APIs
• A heavy xtask CLI — commands for every workflow, from onboarding to release
• Specs as source of truth — spec_ledger.yaml, BDD features, and policies all describe the same behavior
• An 12-step selftest gate — one command validates everything: cargo xtask selftest
• LLM/agent-first design — bundles, Skills, Agents, and /platform/agent/hints for autonomous workflows

Architecture at a glance:

┌──────────────────────────────────────────────────────────────────┐
│  Specs (YAML + Gherkin)                                          │
│    spec_ledger.yaml → REQs → ACs → tests → docs                  │
│    devex_flows.yaml → commands + workflows                       │
│    config_schema.yaml → configuration contract                   │
└───────────────────────────┬──────────────────────────────────────┘
                            │
┌───────────────────────────▼──────────────────────────────────────┐
│  Runtime (Rust HTTP App)                                         │
│    /platform/status  — governance health                         │
│    /platform/graph   — full REQ/AC/test/doc graph                │
│    /platform/tasks   — work items                                │
│    /platform/agent/hints — what to do next                       │
│    /ui               — dashboard showing same state as CI        │
└───────────────────────────┬──────────────────────────────────────┘
                            │
┌───────────────────────────▼──────────────────────────────────────┐
│  Enforcement (xtask CLI + CI)                                    │
│    cargo xtask selftest — 11-step governance gate                │
│    cargo xtask ac-status — AC → test → status mapping            │
│    cargo xtask contracts-check — keeps docs in sync              │
└──────────────────────────────────────────────────────────────────┘

Try It in 60 Seconds

nix develop                    # Enter dev shell (hermetic environment)
cargo xtask dev-up             # One-command setup + validation
cargo xtask selftest           # Run full 11-step governance gate
cargo run -p app-http          # Start service at http://localhost:8080

Then:

• Visit http://localhost:8080/ui for the governance dashboard
• curl http://localhost:8080/platform/status for health JSON
• curl http://localhost:8080/platform/graph for the full governance graph

Kernel Stability

This repo is the kernel template. After v3.3.x, changes are limited to:

• Bug fixes in existing behavior
• Security/compatibility updates
• Explicit kernel contract extensions (with ADR + version bump)

Forks inherit the kernel as-is and extend with domain-specific specs, ACs, and code.

Verification: cargo xtask selftest passes all 11 steps → kernel contracts intact.

---

Template Version: v3.3.15

Kernel Baseline: v3.3.9-kernel

Using this as a template? Start here:

• Quick Start Guide – Get productive in 15 minutes
• Your First Hour – Hands-on exploration (30-60 min)
• Pre-Fork Checklist – Validate before forking
• Kernel snapshot – what you're inheriting
• New service guide – step-by-step setup
• Troubleshooting Guide – when things go wrong
• Run cargo xtask kernel-smoke after cloning – it should be green

---

1. Who This Is For

Use this template if:

• You ship Rust services in regulated or multi-team environments (FinTech, health, platform/platform-engineering).
• You want spec-as-code and doc-as-code with real teeth: CI fails if specs/tests/docs drift.
• You plan to use LLMs/agents as active contributors, not just copilots.
• You want a repeatable service cell to plug into a portal/IDP (Backstage/Port/Humanitec/etc.).

Don’t use this if:

• You just need a quick Axum “hello world”.
• You’re experimenting without any governance requirements.
• You don’t care about AC traceability or policy tests yet.

---

2. What You Get

2.1 Specs and governance as code

• specs/spec_ledger.yaml – stories → requirements → acceptance criteria (ACs) → tests → docs.
• specs/config_schema.yaml – configuration schema for the service.
• specs/devex_flows.yaml – developer workflows (flows + commands).
• specs/tasks.yaml – work items the platform can surface via CLI and HTTP.

2.2 Verification

• BDD (Cucumber + Rust) for platform and DevEx behaviour.
• Unit tests for spec runtime, graph invariants, config validation, etc.
• cargo xtask ac-status – computes AC → test → status mapping and writes:
  • docs/feature_status.md – AC health dashboard, auto-generated.

2.3 Enforcement

• cargo xtask selftest – the single mandatory CI gate (11 steps):
  1. Core checks (fmt, clippy, unit tests)
  2. Skills governance lint
  3. Agents governance lint
  4. BDD acceptance tests
  5. AC status + ADR mapping
  6. LLM context bundler checks
  7. Policy tests (OPA/Conftest)
  8. DevEx contract (required xtask commands, flows)
  9. Governance graph invariants (REQ/AC/command connectivity)
  10. AC coverage sanity

If selftest is red, the service is not in a governed state.

2.4 Introspection surfaces

• HTTP APIs (/platform/*):

  • /platform/status – governance health, policy status, auth mode, metadata.
  • /platform/graph – full governance graph as JSON.
  • /platform/tasks – tasks from tasks.yaml (list + status updates).
  • /platform/devex/flows – developer flows and commands.
  • /platform/docs/index – documentation inventory.
  • /platform/schema – machine-readable schema/OpenAPI for the platform.
  • /platform/agent/hints – suggestions for where to work next.

• Web UI (/ui):

  • Dashboard view for status and governance metrics.
  • Graph visualization (Mermaid) of stories/REQs/ACs/docs/commands.
  • Flows and tasks views for day-to-day work.

The UI has no separate database: it calls the same loaders selftest uses.
If the UI shows it, CI enforces it.

---

3. High-Level Architecture

The pipeline is:

Specs (YAML) ──> Loader (Rust) ──> Selftest (CI) ──> Introspection (HTTP/UI)
   spec_ledger      spec-runtime        xtask selftest      /platform/*, /ui
   config_schema    graph model
   devex_flows
   tasks, docs

Under the hood:

┌─────────────────────────────────────┐
│ Adapters (HTTP, gRPC)              │
│  ├─ app-http (Axum)                │
│  └─ adapters-grpc (Tonic)          │
└────────────┬────────────────────────┘
             │
┌────────────▼────────────────────────┐
│ Business Core                       │
│  ├─ business-core (domain)         │
│  ├─ governance (specs + policies)  │
│  └─ telemetry (metrics + tracing)  │
└────────────┬────────────────────────┘
             │
┌────────────▼────────────────────────┐
│ Infrastructure                      │
│  ├─ spec-runtime (loaders + graph) │
│  ├─ model (shared types)           │
│  └─ proto (gRPC definitions)       │
└─────────────────────────────────────┘

---

3.1 Crate Structure (Microcrate Architecture)

The workspace follows a microcrate architecture with explicit layering and contract stability. Crates are organized into five categories:

Category	Purpose	Examples
Contract	Stable API surface, versioned, minimal deps	platform-contract, xtask-contract, gov-contracts, receipts-core, spec-types
Core Logic	Business rules, domain models, governance logic	gov-model, gov-policy, spec-ledger
Foundation	Cross-cutting utilities, lightweight infrastructure	http-errors, http-platform, http-core, gov-http-types, telemetry
Adapter	Infrastructure implementations (DB, HTTP, messaging)	adapters-db-sqlx, gov-http-*, http-middleware
HTTP/Router	Axum application, routing, middleware wiring	app-http
Facade	Build-time tools, configuration, IaC	rust_iac_config, gov-xtask-core

Layering Rules:

• Contract crates depend only on foundation crates (or std)
• Foundation crates depend only on other foundation crates (or std)
• Core logic crates depend on contract and foundation crates
• Adapter crates depend on core logic and foundation crates
• HTTP/router crate depends on adapter and core logic crates
• Facade crates have no runtime layering restrictions

Contract Stability: Contract crates define the stable API surface of the platform. Breaking changes require:

1. An ADR documenting the change
2. Version bump in specs/contracts_manifest.yaml
3. Updates to dependent crates and consumers

For detailed architecture documentation, see:

• Architecture Overview — Complete microcrate architecture documentation
• ADR-0030: Microcrate Architecture — Decision record with rationale

---

4. Detailed Setup Guide

4.1 Prerequisites

Required: Nix with flakes (Tier-1, recommended for exact CI parity)

Optional: Docker, WSL2 (if on Windows), VS Code (recommended editor)

Note: You can develop without Nix (Tier-2), but policy tests and exact CI parity require it. See docs/reference/environment.md for detailed setup by platform and tier.

4.2 Getting up and running (5 minutes)

# Clone the template
git clone https://github.com/EffortlessMetrics/Rust-Template.git my-service
cd my-service

# Enter the Nix dev shell (Tier-1)
nix develop

# One-command environment setup and validation (recommended)
cargo xtask dev-up
# OR: Use the Claude Code skill directly
# /bootstrap-dev-env (requires Claude Code integration)

Alternatively, if you prefer manual setup:

# Check your environment
cargo xtask doctor

# Quick smoke test (validates template baseline – do this first!)
cargo xtask kernel-smoke

Expected: All checks green. If any fail, troubleshoot before proceeding.

Then:

# Install hooks (optional but recommended)
cargo xtask install-hooks

# Run the full selftest gate (before submitting PR)
cargo xtask selftest

Start the service:

cargo run -p app-http
# UI:   http://localhost:8080/ui
# APIs: http://localhost:8080/platform/status

VS Code users: Press F5 to run with debugger, or Ctrl+Shift+B to run kernel: smoke (default build task). See QUICKSTART.md for full editor setup.

---

5. Platform Support

Platform	Tier	Environment	Selftest	Notes
Linux	1	Nix devshell	✅	Canonical dev + CI environment
macOS	1	Nix devshell	✅	Intel and Apple Silicon supported
WSL2	1	Nix in WSL2	✅	Recommended for Windows; use Tier-1 setup
Windows	2	Native	⚠️	Core features work; some tools skipped

Tier-1: Full selftest with all gates (fmt, policy, clippy). Same environment as CI. Tier-2: Core functionality works. Some tools skipped. Use XTASK_LOW_RESOURCES=1 if needed.

For detailed setup by platform and troubleshooting, see docs/reference/environment.md.

---

6. Governance Model in Practice

6.1 Spec ledger

specs/spec_ledger.yaml is the core artifact:

• Stories (US-*) – user-facing goals.
• Requirements (REQ-*) – what must be true.
• Acceptance criteria (AC-*) – concrete behaviour.
• Tests – how each AC is verified (BDD tags, unit tests).
• Docs – which design/runbook/tutorial covers it.

Example fragment:

- id: REQ-TPL-PLATFORM-AUTH
  title: "Platform introspection supports authenticated mode"
  must_have_ac: true
  acceptance_criteria:
    - id: AC-TPL-PLATFORM-AUTH-BASIC
      text: >
        When PLATFORM_AUTH_MODE=basic, write endpoints under /platform/*
        reject unauthenticated requests with 401/403 and accept requests
        with the configured credential header; read endpoints may remain
        open or use the same guard.
      tests:
        - { type: bdd, tag: "@AC-TPL-PLATFORM-AUTH-BASIC", file: "specs/features/platform_security.feature" }

6.2 AC status and coverage

To see current coverage:

# Recompute AC statuses from tests
cargo xtask ac-status

# Open the generated dashboard
less docs/feature_status.md

Kernel ACs must be [PASS]. Non-kernel or template-only ACs may be [UNKNOWN] and are documented as such.

---

7. Platform APIs and Auth

7.1 Auth modes

Auth is applied once at the /platform/* router:

• PLATFORM_AUTH_MODE=none (default)

  • All /platform/* routes are open.
  • Intended for local/dev use.

• PLATFORM_AUTH_MODE=basic

  • All non-GET /platform/* routes require a shared token.
  • Read endpoints (GET) remain open or can share the same guard.
  • If basic is enabled without a token, the service:
    • Logs a startup warning.
    • Surfaces token_present: false in /platform/status.

Typical production setup:

export PLATFORM_AUTH_MODE=basic
export PLATFORM_AUTH_TOKEN="some-long-random-secret"

7.2 Key endpoints

Core governance and discovery:

# Governance health + metadata
curl http://localhost:8080/platform/status

# Full governance graph (stories/REQs/ACs/docs/commands)
curl http://localhost:8080/platform/graph

# Schema/OpenAPI for the platform
curl http://localhost:8080/platform/schema

# Schema for a specific type
curl http://localhost:8080/platform/schema/{name}

# Docs index (design docs, ADRs, how-tos)
curl http://localhost:8080/platform/docs/index

# AC coverage summary (BDD + test results)
curl http://localhost:8080/platform/coverage

Work and task management:

# Tasks from specs/tasks.yaml with filtering
curl http://localhost:8080/platform/tasks
curl http://localhost:8080/platform/tasks?status=Todo&req=REQ-MYSERV-001

# Suggested next work (for agents) – given a task, recommend sequence
curl "http://localhost:8080/platform/tasks/suggest-next?task=TASK-001"

# Task dependency graph (JSON or Mermaid format)
curl http://localhost:8080/platform/tasks/graph
curl "http://localhost:8080/platform/tasks/graph?format=mermaid"

# Update task status
curl -X POST http://localhost:8080/platform/tasks/{id}/status \
  -H "Content-Type: application/json" \
  -d '{"status": "InProgress"}'

Developer and agent workflows:

# Available developer flows and xtask commands
curl http://localhost:8080/platform/devex/flows

# Agent hints (prioritized work suggestions for Todo/InProgress tasks)
# Returns: task ID, title, owner, labels, REQ/AC IDs, and recommended commands
curl http://localhost:8080/platform/agent/hints

Metadata and issues:

# Development friction log (DevEx issues)
curl http://localhost:8080/platform/friction

# Friction entry by ID
curl http://localhost:8080/platform/friction/{id}

# Design questions and ambiguities
curl http://localhost:8080/platform/questions

# Question by ID
curl http://localhost:8080/platform/questions/{id}

# Fork/branch information (forks of this template)
curl http://localhost:8080/platform/forks

# Fork information by name
curl http://localhost:8080/platform/forks/{name}

---

8. Developer Workflows (xtask)

Everything runs through the xtask binary. It's designed to be friendly for humans and agents.

8.1 Onboarding & sanity

# Environment sanity check
cargo xtask doctor

# Quick code quality check (fmt, clippy, unit tests)
cargo xtask check

# Full governance gate (Tier-1) – includes all 11 selftest steps
cargo xtask selftest

# Local precommit gate (what CI enforces before merge)
cargo xtask precommit

8.2 Governance-specific checks

# Validate and lint Skills (name format, descriptions, allowed-tools safety, no secrets)
cargo xtask skills-lint

# Format Skills SKILL.md files (frontmatter, headings)
cargo xtask skills-fmt

# Validate and lint Agents (name format, descriptions, tools, model policy, skills references, no secrets)
cargo xtask agents-lint

# Format Agent .md files
cargo xtask agents-fmt

# Compute AC statuses from test results and write docs/feature_status.md
cargo xtask ac-status

# AC coverage summary (what % of ACs have passing tests)
cargo xtask ac-coverage

8.3 AC-first feature development

# 1. Create a new AC (requires both --story and --requirement)
cargo xtask ac-new AC-MYSERV-001 "Users can list todos" \
  --story US-MYSERV-001 \
  --requirement REQ-MYSERV-TODOS

# 2. Edit the spec ledger to add context
#    (specs/spec_ledger.yaml is updated by step 1)

# 3. Create a BDD scenario
#    Edit specs/features/todos.feature and tag with @AC-MYSERV-001

# 4. Generate an LLM context bundle (task name from .llm/contextpack.yaml)
cargo xtask bundle implement_ac

# 5. Implement the feature
#    (Use the bundle with your own editor or an LLM)

# 6. Run focused tests
cargo xtask test-ac AC-MYSERV-001
cargo xtask test-changed

# 7. Verify governance
cargo xtask ac-status
cargo xtask selftest

8.4 Selective testing

# Test only what changed vs origin/main (fast loop)
cargo xtask test-changed

# Plan-only mode (see what would be run)
XTASK_TEST_CHANGED_PLAN_ONLY=1 cargo xtask test-changed

# Test a specific acceptance criterion
cargo xtask test-ac AC-PLT-001

# List available tasks
cargo xtask tasks-list

# Discover available flows and commands
cargo xtask help-flows

8.5 Releases

# Build a local SBOM
cargo xtask sbom-local

# Prepare a release (version bump + docs)
cargo xtask release-prepare 3.3.1

# Generate release evidence
cargo xtask release-bundle 3.3.1
# -> release_evidence/v3.3.1.md

---

9. LLM / Agent Ergonomics

This repo is designed so that an agent can act as a real teammate, not a glorified autocomplete:

• Specs & schemas give a precise brief (spec_ledger.yaml, config_schema.yaml, devex_flows.yaml, tasks.yaml).
• Bundles give a bounded context:
  • cargo xtask bundle <TASK> produces curated context packs (e.g., implement_ac is a registered task).
  • Note: bundle/ is ignored by git. Bundles are generated on-demand with timestamps and git SHAs baked in; the contract (specs, ACs, tests) is what's versioned.
• Flows & Skills provide the patterns:
  • .claude/skills/*/SKILL.md describe governed-feature-dev, governed-maintenance, governed-release, and governance-debug flows.
  • Skills are governed: skills-lint validates name format, descriptions, allowed-tools safety, and prevents hardcoded secrets.
• Agents are first-class governed artifacts:
  • .claude/agents/*.md define long-lived, specialized agents with system prompts and tool bindings.
  • Agents are governed: agents-lint validates name format, descriptions, tools, model policy, skills references, and prevents hardcoded secrets.
  • See docs/AGENTS_GOVERNANCE.md and docs/AGENTS_TEMPLATE.md for governance rules and creation checklist.
• Platform APIs provide live telemetry:
  • /platform/status, /platform/graph, /platform/tasks, /platform/agent/hints, /platform/docs/index, /platform/schema, /platform/devex/flows.

The expected agent loop looks like:

1. Orient

   • Run cargo xtask doctor, cargo xtask ac-status, cargo xtask help-flows.
   • Call /platform/status and /platform/graph to understand the current state.

2. Pick work

   • Use cargo xtask tasks-list and /platform/agent/hints to identify a task.
   • Read the relevant REQ/AC entries in spec_ledger.yaml.

3. Plan with a bundle

   • Generate a bundle with cargo xtask bundle implement_ac or another task name from .llm/contextpack.yaml.
   • Use only what's in the bundle plus linked specs/docs unless you have a good reason to widen scope.

4. Execute via xtask and code

   • Follow the appropriate Skill (feature dev, maintenance, release).
   • Use test-changed and test-ac while iterating.

5. Validate and capture decisions

   • End with cargo xtask selftest in Tier-1.
   • If you had to make non-obvious choices, record them:
     • draft ADRs,
     • GitHub issues,
     • friction log entries.

Agents don’t need synchronous human approval to move forward; the spec ledger, flows, xtask commands, /platform/* APIs, and selftest provide the guardrails. Humans review the artifacts and CI results asynchronously.

For details, see:

• CLAUDE.md – agent operational prompt
• AGENT_GUIDE.md – deeper guidance for agent-driven work
• SELECTIVE_TESTING.md – validation ladder and change-aware testing
• TROUBLESHOOTING.md – common problems and solutions

---

10. Adoption Patterns

10.1 Greenfield: new service

• Clone this template into a new repo.
• Follow the Pre-Fork Checklist to validate your environment.
• Use the QUICKSTART.md guide to get oriented.
• Follow the New Service Guide for step-by-step setup.
• Adjust service_metadata.yaml, ledger entries, and tasks to your domain.
• Keep the platform kernel as-is; build your business logic in new crates or modules.
• Use selftest as the gate from day one.

10.2 Brownfield: existing repo

See docs/how-to/add-governance-to-existing-repo.md.

High-level flow:

• Add a governance/ subtree (specs, policy, docs) to your existing repo.
• Add spec-runtime + xtask crates to your workspace.
• Configure your CI to run cargo xtask selftest as a gate.
• Gradually map your existing tests/docs into the spec ledger.

---

11. Relationship to Portals/IDPs

This template is not a portal. It is the per-service kernel that a portal/IDP can rely on.

• If you use Backstage/Port/OpsLevel/etc.:

  • They provide catalogs, scorecards, golden paths.
  • This template defines what a "good Rust service" is in concrete, enforceable terms.

• If you use a platform orchestrator (Humanitec, Argo CD, etc.):

  • They standardize deployments and environments.
  • This template standardizes the service contract: specs, policies, AC coverage, /platform/* introspection.

The integration surface is:

• /platform/* APIs
• release_evidence/vX.Y.Z.md bundles
• docs/feature_status.md and service_metadata.yaml

---

12. Documentation Guide

Documentation is organized by audience and purpose:

12.1 Getting Started (New Users)

Start here if you're using this template for the first time:

• First Fork Runbook – One-page quick start for forking (do this first!)
• Quick Start Guide – Get productive in 15 minutes
• Pre-Fork Checklist – Validate your environment before forking
• New service guide – Step-by-step setup after forking
• Kernel snapshot – What you're inheriting from the template
• Troubleshooting Guide – Solutions for common problems

12.2 Daily Development (Contributors)

Use these guides while working in the codebase:

• CLAUDE.md – Agent operational instructions
• AGENT_GUIDE.md – Deeper guidance for agent-driven work
• Selective Testing Guide – Validation ladder and change-aware testing
• Change Acceptance Criterion – How to modify ACs (day-2 contracts)
• Add Acceptance Criterion – How to add new ACs
• Add HTTP endpoint – How to add new endpoints
• Change OpenAPI safely – How to evolve APIs
• LLM bundles guide – How to use context bundles
• Windows Development Guide – Platform-specific guidance for Windows

Governance & LLM surfaces:

• SKILLS_GOVERNANCE.md – Skills governance rules, lifecycle, and validation
• SKILLS_TEMPLATE.md – Copy-paste template for creating new Skills
• AGENTS_GOVERNANCE.md – Agents governance rules, lifecycle, and validation
• AGENTS_TEMPLATE.md – Copy-paste template for creating new Agents
• AGENTS_VALIDATION.md – Agent validation rules reference

12.3 Platform Setup (Maintainers)

Use these guides to configure the production environment:

• Branch Protection Setup – Configure branch protection rules
• Tag Signing Setup – Configure GPG/SSH tag signing
• Branch Protection Profiles – Different protection levels explained
• Required Checks Reference – CI checks that must pass
• Platform Support – Tier-1 vs Tier-2 platforms
• Supply Chain Hardening – Security best practices
• Integrate with IDP or Agent – Use /platform/* APIs with Backstage, Port.io, or LLM agents

12.4 Understanding the System (Architecture)

Read these to understand how the template works:

• Why This Exists – Motivation and philosophy
• Architecture Overview – System design
• Template Architecture – Template structure
• Rust-as-Spec Overview – Core concept
• Controls as Code – Governance approach
• IDP Positioning – How this fits with platform tools
• Template Contracts – What the template guarantees

Design docs:

• AC Governance Design – How ACs are governed and enforced
• Skills Governance Design – How Skills are governed
• Agents Governance Design – How Agents are governed

ADRs (Architecture Decision Records):

• ADR-0030: Microcrate Architecture for Contract Stability
• ADR-0020: Claude Code Skills Governance
• ADR-0021: Claude Code Agents Governance
• ADR-0022: Platform Metadata and Test Isolation

12.5 Audit & Trust

How to verify changes and understand the factory:

• Audit Path — 15-minute verification guide
• Provenance — What's automated vs human, trust model
• PR Cover Sheet — Canonical format for PR descriptions
• Receipts — Evidence schema and usage
• Failure Modes — Taxonomy of what can go wrong
• Casebook — Curated examples of governed change

12.6 Process & Planning

Roadmaps, ADRs, and planning documents:

• ROADMAP.md – Current state and future plans
• BACKLOG.md – Known gaps and future work
• Missing Manual – Unwritten docs and known documentation gaps
• ADR Index – Architecture decision records
• Release Playbook – How to cut releases

12.7 Reference Material

Technical references and command documentation:

• Documentation Sources – What to trust when docs disagree
• xtask Commands – Complete CLI reference
• CI Coverage – What CI tests
• Ignored Tests – Tests marked with #[ignore] and how to run them
• Feature Status – Auto-generated AC health dashboard
• Testing Strategy – How testing works
• CONSTITUTION.md – Core principles and boundaries

---

13. Current Status & Roadmap

Kernel Version: v3.3.9-kernel (see KERNEL_SNAPSHOT.md for what you inherit)

AC Health: See:

• Feature Status – Acceptance criteria health (auto-generated)
• Feature Status Notes – How to read the AC table (Kernel/Template/Meta)

Strategy: See ROADMAP.md for current direction and BACKLOG.md for known gaps.

---

14. License

This template is dual-licensed:

• MIT – see LICENSE-MIT
• Apache 2.0 – see LICENSE-APACHE

You may use it under either license.