@rune-kit/rune 2.3.3 → 2.4.0

package/docs/ARCHITECTURE.md

@@ -1,332 +0,0 @@
-# Rune Architecture
-
-## 5-Layer Model
-
-| Layer | Name | Count | Can Call | Called By | State |
-|-------|------|-------|----------|----------|-------|
-| **L0** | **Router** | **1** | **L1-L3 (routing)** | **Every message** | **Stateless (rule-based)** |
-| L1 | Orchestrators | 5 | L2, L3 | L0, User | Stateful (workflow) |
-| L2 | Workflow Hubs | 28 | L2 (cross-hub), L3 | L1, L2 | Stateful (task) |
-| L3 | Utilities | 26 | Nothing (pure)* | L1, L2 | Stateless |
-| L4 | Extension Packs | 14 free + 4 pro + 4 business | L3 | L2 (domain match) | Config-based |
-
-### L0 — The Enforcement Layer
-
-`skill-router` is the only L0 skill. It enforces a single discipline: **check the routing table before every response**. It doesn't do work — it ensures the right skill does the work.
-
-- Loaded via plugin description, always active
-- Routes user intent to the correct L1-L3 skill
-- Prevents agents from bypassing skills ("I'll just do it manually")
-- See `skills/skill-router/SKILL.md` for the full routing table and anti-rationalization gate
-
-### L4 — Extension Packs (Activation Protocol)
-
-L4 packs are domain-specific instruction sets stored as `extensions/*/PACK.md` files. They are activated (read) in two ways:
-
-**1. Explicit invocation** — User runs `/rune <pack-skill>` (e.g., `/rune rag-patterns`)
-   - `skill-router` detects the L4 trigger in Tier 4 routing table
-   - Agent reads `extensions/<pack>/PACK.md`
-   - Agent follows the matching skill's Workflow steps
-
-**2. Implicit detection** — `cook` detects domain context in Phase 1.5
-   - Scout output reveals domain signals (e.g., `three.js` in dependencies)
-   - Cook matches against L4 pack mapping table
-   - Agent reads matching PACK.md and applies its constraints/patterns
-   - Domain patterns supplement cook's standard phases
-
-**L4 calling rules:**
-- L4 CAN call L3 utilities (scout, verification, hallucination-guard)
-- L4 CANNOT call L1 or L2 skills
-- L4 CANNOT call other L4 packs (no cross-pack dependencies)
-- If L4 pack file not found on disk, skip silently (graceful degradation)
-
-### Exceptions
-
-- `team` (L1) can call other L1 orchestrators — meta-orchestration pattern.
-- *L3→L3 coordination: `context-engine` → `session-bridge`, `hallucination-guard` → `research`, `session-bridge` → `integrity-check` (documented in SKILL.md).
-
-## Mesh Protocol
-
-### Loop Prevention
-
-```
-Rule 1: No self-calls (history[-1] !== target)
-Rule 2: Max 2 visits to same skill per chain
-Rule 3: Max chain depth: 8
-Rule 4: If blocked → escalate to L1 orchestrator
-```
-
-### Model Auto-Selection
-
-```
-Read-only / scan?           → haiku   (cheapest)
-Write / edit / generate?    → sonnet  (default)
-Architecture / security?    → opus    (deep reasoning)
-
-Override: priority=critical → always opus
-Override: budget constraint → downgrade
-Override: user preference   → manual in config
-```
-
-### Parallel Execution
-
-| Context | Max Parallel | Reason |
-|---------|-------------|--------|
-| L3 utilities (haiku) | 5 | Cheap, fast, independent |
-| L2 hubs (sonnet) | 3 | Moderate cost, may share context |
-| L1 orchestrators | 1 | Only one orchestrator at a time |
-
-### Error Handling & Resilience
-
-| If this fails... | Try this instead... |
-|-------------------|---------------------|
-| debug can't find cause | problem-solver (different reasoning) |
-| docs-seeker can't find | research (broader web search) |
-| browser-pilot can't capture | verification (CLI checks) |
-| scout can't find files | research + docs-seeker |
-| test can't run (env broken) | deploy fix env → test again |
-| review finds too many issues | plan re-scope → fix priorities |
-
-## Skill Groups
-
-### L1 Orchestrators
-
-| Skill | Model | Role |
-|-------|-------|------|
-| cook | sonnet | Feature implementation orchestrator (v0.5.0 — phase-aware execution) |
-| team | opus | Multi-agent parallel orchestrator |
-| launch | sonnet | Deploy + marketing orchestrator |
-| rescue | sonnet | Legacy refactoring orchestrator |
-| scaffold | sonnet | Project bootstrap orchestrator (BA-powered, 9-phase pipeline) |
-
-### L2 Workflow Hubs
-
-| Group | Skills |
-|-------|--------|
-| CREATION | plan, scout, brainstorm, design, skill-forge, ba, mcp-builder |
-| DEVELOPMENT | debug, fix, test, review, db |
-| QUALITY | sentinel, preflight, onboard, audit, perf, review-intake, logic-guardian |
-| DELIVERY | deploy, marketing, incident, docs |
-| RESCUE | autopsy, safeguard, surgeon |
-
-### L3 Utilities
-
-| Group | Skills |
-|-------|--------|
-| KNOWLEDGE | research, docs-seeker, trend-scout |
-| REASONING | problem-solver, sequential-thinking |
-| VALIDATION | verification, hallucination-guard, integrity-check, completion-gate, constraint-check, sast |
-| STATE | context-engine, journal, session-bridge |
-| MONITORING | watchdog, scope-guard |
-| MEDIA | browser-pilot, asset-creator, video-creator |
-| DEPS | dependency-doctor |
-| WORKSPACE | worktree |
-| GIT | git |
-| DOCUMENTS | doc-processor |
-
-## Cross-Hub Mesh (L2 ↔ L2)
-
-```
-plan ↔ brainstorm     (creative ↔ structure)
-fix ↔ debug           (fix ↔ root cause)
-test → debug          (unexpected failure)
-review → test         (untested edge case found)
-review → fix          (bug found during review)
-review → review-intake (external feedback received on reviewed code)
-review-intake → fix   (verified feedback → apply changes)
-review-intake → test  (reviewer found untested edge case)
-review-intake → sentinel (reviewer flagged security concern)
-fix → test            (verify after fix)
-deploy → test         (pre-deploy verification)
-debug → scout         (find related code)
-marketing → scout     (analyze assets)
-plan → scout          (scan before planning)
-fix → review          (self-review complex fix)
-review → scout        (more context needed)
-surgeon → safeguard   (untested module found)
-preflight → sentinel  (security sub-check)
-audit → sentinel      (security phase delegation)
-audit → autopsy       (complexity/health phase)
-audit → dependency-doctor (deps phase delegation)
-audit → scout         (discovery phase)
-audit → journal       (save audit report)
-
-# perf
-perf ← cook           (Phase 5 quality gate)
-perf ← audit          (performance dimension delegation)
-perf ← review         (performance patterns detected in diff)
-perf ← deploy         (pre-deploy perf regression check)
-perf → scout          (find hotpath files)
-perf → browser-pilot  (Lighthouse / Core Web Vitals)
-perf → verification   (run benchmark scripts if configured)
-
-# db
-db ← cook             (schema change detected in diff)
-db ← deploy           (pre-deploy migration safety check)
-db ← audit            (database health dimension)
-db → scout            (find schema/migration files)
-db → verification     (run migration in test env)
-db → hallucination-guard (verify SQL syntax and ORM methods)
-
-# incident
-incident ← launch     (watchdog alerts during Phase 3 VERIFY)
-incident ← deploy     (health check fails post-deploy)
-incident → watchdog   (current system state — what's down)
-incident → autopsy    (root cause after containment)
-incident → journal    (record incident timeline)
-incident → sentinel   (check for security dimension)
-
-# design
-design ← cook         (frontend task detected, no design-system.md)
-design ← review       (AI anti-pattern detected in diff)
-design ← perf         (Lighthouse Accessibility BLOCK)
-design → scout        (detect platform, tokens, component library)
-design → asset-creator (generate base visual assets from design system)
-
-# skill-forge
-skill-forge ← cook    (feature being built IS a new skill)
-skill-forge ← plan    (plan identifies need for reusable skill)
-skill-forge → scout   (scan existing skills for overlap)
-skill-forge → plan    (structure complex multi-phase skills)
-skill-forge → hallucination-guard (verify referenced skills exist)
-skill-forge → verification (validate SKILL.md format)
-skill-forge → journal (record skill creation ADR)
-
-# review-intake
-review-intake ← cook  (Phase 5: external review arrives)
-review-intake ← review (self-review surfaces issues to address)
-review-intake → scout  (verify reviewer claims against codebase)
-review-intake → fix    (apply verified changes)
-review-intake → test   (add tests for reviewer-found edge cases)
-review-intake → hallucination-guard (verify suggested APIs exist)
-review-intake → sentinel (re-check security if reviewer flagged)
-
-# completion-gate
-completion-gate ← cook    (Phase 5d: validate agent claims)
-completion-gate ← team    (validate cook reports from streams)
-
-# worktree
-worktree ← team           (Phase 2: create worktrees for streams)
-worktree ← cook           (optional isolation for complex features)
-
-# sast
-sast ← sentinel           (deep analysis beyond regex patterns)
-sast ← audit              (security dimension in full audit)
-sast ← cook               (security-sensitive code paths)
-sast ← review             (security patterns detected in diff)
-
-# constraint-check
-constraint-check ← cook   (end-of-workflow discipline audit)
-constraint-check ← team   (verify stream agent compliance)
-constraint-check ← audit  (quality dimension assessment)
-
-# logic-guardian
-logic-guardian ← cook     (Phase 1.5: complex logic project detected)
-logic-guardian ← fix      (pre-edit gate on manifested files)
-logic-guardian ← surgeon  (pre-refactor on logic modules)
-logic-guardian ← team     (validate logic integrity across streams)
-logic-guardian ← review   (check if diff removes manifested logic)
-logic-guardian → scout    (scan project for logic files)
-logic-guardian → verification (run tests after logic edits)
-logic-guardian → hallucination-guard (verify references after edit)
-logic-guardian → journal  (record logic changes as ADRs)
-logic-guardian → session-bridge (save manifest for cross-session)
-
-# ba (Business Analyst)
-ba ← cook             (Phase 1 BA gate — feature requests, integrations, greenfield)
-ba ← scaffold         (Phase 1 requirement elicitation)
-ba → plan             (hand-off: requirements.md → implementation planning)
-ba → brainstorm       (explore approaches when requirements are ambiguous)
-ba → research         (domain research for hidden requirements)
-
-# scaffold (Project Bootstrap)
-scaffold → ba         (Phase 1: requirement elicitation)
-scaffold → research   (Phase 2: tech stack research)
-scaffold → plan       (Phase 3: architecture planning)
-scaffold → design     (Phase 4: design system generation)
-scaffold → fix        (Phase 5: code generation)
-scaffold → test       (Phase 6: test generation)
-scaffold → docs       (Phase 7: documentation)
-scaffold → git        (Phase 8: initial commit)
-scaffold → verification (Phase 9: build + test verification)
-scaffold → sentinel   (Phase 9: security scan)
-
-# docs (Documentation Lifecycle)
-docs ← cook           (Phase 8: auto-update docs after feature)
-docs ← scaffold       (Phase 7: generate initial docs)
-docs → scout          (scan codebase for doc-worthy exports)
-docs → doc-processor  (generate PDF/DOCX from markdown)
-docs → git            (commit doc changes)
-
-# git (Semantic Git Operations)
-git ← cook            (Phase 7: semantic commit generation)
-git ← scaffold        (Phase 8: initial commit)
-git ← docs            (commit doc changes)
-git ← launch          (tag and release)
-
-# mcp-builder (MCP Server Builder)
-mcp-builder ← cook    (building an MCP server)
-mcp-builder → scout   (scan for existing MCP patterns)
-mcp-builder → test    (generate MCP server tests)
-mcp-builder → docs    (generate MCP server documentation)
-mcp-builder → hallucination-guard (verify SDK imports exist)
-
-# doc-processor (Document Format Utility)
-doc-processor ← docs  (PDF/DOCX generation)
-doc-processor ← marketing (generate branded PDFs)
-```
-
-## Master Plan + Phase Files (Amateur-Proof Architecture)
-
-The `plan` skill (v0.4.0) produces structured plans designed for **any model to execute with high accuracy**.
-
-### Design Principle
-
-> Plan for the weakest coder. If Haiku (Amateur) can execute the phase file, every model benefits.
-
-### Structure
-
-```
-.rune/
-  plan-<feature>.md          ← Master plan: overview (<80 lines)
-  plan-<feature>-phase1.md   ← Phase 1: self-contained execution detail (<200 lines)
-  plan-<feature>-phase2.md   ← Phase 2: self-contained execution detail
-  ...
-```
-
-### Phase File Template (Amateur-Proof)
-
-Every phase file MUST include these 7 mandatory sections:
-
-| Section | Purpose | Why Amateur Needs It |
-|---------|---------|---------------------|
-| Data Flow | ASCII diagram of data movement | Prevents wrong function call order |
-| Code Contracts | Function signatures, interfaces | Prevents wrong return types |
-| Tasks | File paths, logic, edge cases | Prevents missed files |
-| Failure Scenarios | When/Then/Error table | Prevents missing error handling |
-| Rejection Criteria | Explicit DO NOTs | Prevents common anti-patterns |
-| Cross-Phase Context | Imports from prior, exports for future | Prevents broken dependencies |
-| Acceptance Criteria | Testable conditions | Prevents "done" without proof |
-
-### Execution Flow
-
-```
-1. cook Phase 0: check for existing master plan → resume from current phase
-2. cook Phase 2: plan produces master + phase files → user approves
-3. cook Phase 3-7: load ONLY current phase file → test → implement → quality → commit
-4. cook Phase 7: mark phase ✅ in master plan → announce next phase
-5. Next session: Phase 0 detects master plan → loads next phase → executes
-```
-
-**One phase per session = small context = better code from any model.**
-
-## Context Bus
-
-Each workflow maintains a shared context managed by L1:
-
-```
-L1: full bus (complete picture)
-L2: relevant subset (only what they need)
-L3: minimal query (stateless, no history)
-L4: domain-filtered subset
-```

package/docs/COMMUNITY-PACKS.md

@@ -1,109 +0,0 @@
-# Community Extension Packs
-
-## What Are Community Packs?
-
-Community L4 extension packs extend Rune's core mesh with domain-specific skills. They follow the same PACK.md format as core extensions but are maintained by the community.
-
-Community packs are **SKILL.md markdown files** — they contain instructions, not executable code. This makes them inherently safe: Claude reads them and follows the patterns, but packs cannot execute arbitrary code.
-
-## Creating a Community Pack
-
-### 1. Scaffold
-
-```bash
-# Use skill-forge to generate the structure
-/rune pack create my-pack-name
-```
-
-Or manually create:
-```
-my-pack-name/
-├── PACK.md       # Required — follows docs/EXTENSION-TEMPLATE.md
-├── LICENSE        # Recommended — MIT preferred
-└── README.md     # Optional — for GitHub display
-```
-
-### 2. Write PACK.md
-
-Follow `docs/EXTENSION-TEMPLATE.md` exactly. Required sections:
-- YAML frontmatter (name, description, layer: L4)
-- Purpose
-- Triggers
-- Skills Included (with ### headers, workflow steps, examples)
-- Connections
-- Constraints
-- Sharp Edges
-- Done When
-- Cost Profile
-
-### 3. Validate
-
-```bash
-node scripts/validate-pack.js ./my-pack-name
-```
-
-### 4. Publish
-
-1. Push your pack to a public Git repository
-2. Submit a PR to [rune-kit/rune-community-index](https://github.com/rune-kit/rune-community-index) adding your pack to `index.json`:
-
-```json
-{
-  "name": "@community/my-pack-name",
-  "repo": "github:username/rune-pack-name",
-  "description": "One-line description",
-  "version": "0.1.0",
-  "tags": ["domain", "framework"]
-}
-```
-
-## Installing Community Packs
-
-```bash
-/rune pack install github:username/rune-pack-name
-```
-
-This clones the repo to `.rune/community-packs/<name>/` and registers it in `.rune/community-packs/registry.json`.
-
-## Managing Packs
-
-```bash
-/rune pack list              # List all installed packs (core + community)
-/rune pack remove <name>     # Remove a community pack
-/rune pack install <git-url> # Install from Git
-/rune pack create <name>     # Scaffold a new pack
-```
-
-## Security
-
-- Community packs are validated by `integrity-check` (L3) on load
-- Packs cannot modify core L1-L3 skills
-- Packs are sandboxed to their `.rune/community-packs/<name>/` directory
-- All pack files are markdown — no executable code
-
-## Quality Guidelines
-
-A good community pack:
-- Solves a real domain-specific problem (not covered by core L1-L3)
-- Has concrete workflow steps (not vague advice)
-- Includes code examples for every skill
-- Declares connections to the core mesh (which L2 skills call it, which L3 it uses)
-- Has constraints that prevent common mistakes in the domain
-- Lists sharp edges specific to the domain
-
-## Pack Registry Format
-
-`.rune/community-packs/registry.json`:
-```json
-{
-  "version": 1,
-  "packs": {
-    "my-pack-name": {
-      "repo": "github:username/rune-pack-name",
-      "installed": "2026-02-28",
-      "version": "0.1.0",
-      "path": ".rune/community-packs/my-pack-name"
-    }
-  }
-}
-```

package/docs/CONTRIBUTING-L4.md

@@ -1,215 +0,0 @@
-# Contributing L4 Extension Packs
-
-> **H2 Document** — How to create and submit community L4 extension packs for the Rune mesh.
-
----
-
-## What is an L4 Extension Pack?
-
-L4 packs add domain-specific skills on top of Rune's language-agnostic L1-L3 core. A pack is a directory containing a `PACK.md` file that defines 3-6 skills for a specific domain (React patterns, trading algorithms, mobile development, etc.).
-
-**The core mesh (L1-L3) is frozen at 40 skills.** All growth in Rune happens through L4.
-
----
-
-## The 2-Gate L4 Filter
-
-L4 packs have a lighter filter than L1-L3 skills. A proposed pack must pass both gates:
-
-### Gate 1 — Domain Coherence
-> Do all skills in this pack serve the same domain?
-
-The pack's skills must form a coherent unit. A pack mixing React patterns with mobile deployment has no identity. Each skill in the pack should be something a developer in this domain would invoke together.
-
-❌ **Fail:** Pack with `react-hooks`, `django-models`, `kubernetes-deploy` — no coherent domain
-✅ **Pass:** Pack with `react-hooks`, `component-patterns`, `performance-audit`, `a11y-audit` — frontend domain
-
-### Gate 2 — Core Mesh Integration
-> Does the pack connect to at least 2 existing L1-L3 skills?
-
-L4 packs must integrate with the existing mesh — not operate as isolated utilities. Connections must be meaningful (actual data flow, not ceremonial mentions).
-
-Typical connection patterns:
-- Pack skill is called by `cook` (L1) when domain detected
-- Pack skill calls `scout` (L2) for codebase scan
-- Pack skill calls `verification` (L3) after changes
-- Pack skill calls `sentinel` (L2) for domain-specific security
-
-❌ **Fail:** Pack with 0 inbound connections from L1-L3 (no orchestrator calls it)
-✅ **Pass:** Pack called by `cook` on stack detection, calls `scout` + `verification`
-
----
-
-## Pack Structure
-
-```
-extensions/
-└── your-pack-name/
-    └── PACK.md
-```
-
-`PACK.md` must follow `docs/EXTENSION-TEMPLATE.md` exactly. Required sections:
-
-```markdown
----
-name: "@rune/pack-name"
-description: One-line description.
-metadata:
-  author: your-github-username
-  version: "0.1.0"
-  layer: L4
-  price: "$9|$12|$15"
-  target: Target developer audience
----
-
-# @rune/pack-name
-
-## Skills Included
-[3-6 skills with brief description each]
-
-## Connections
-[Explicit list of L1-L3 skills this pack calls or is called by]
-
-## Tech Stack Support (if applicable)
-[Framework/library table]
-```
-
----
-
-## Naming Conventions
-
-- Pack name: `@rune/domain-name` (lowercase kebab-case)
-- Pack directory: `extensions/domain-name/` (without `@rune/` prefix)
-- Skill names within pack: `verb-noun` or `domain-pattern` (lowercase kebab-case)
-- Max pack name length: 48 characters
-
-**Good names:** `@rune/ui`, `@rune/trading`, `@rune/ai-ml`, `@rune/ecommerce`
-**Bad names:** `@rune/my-awesome-react-hooks-pack-v2`, `@rune/FRONTEND`, `@rune/things`
-
----
-
-## Connection Patterns by Pack Type
-
-### Frontend Packs (`@rune/ui`, `@rune/mobile`)
-```
-cook (L1) ← detects React/Vue/Svelte/SwiftUI → calls pack skill
-pack skill → scout (L2): scan component library
-pack skill → verification (L3): run component tests
-pack skill → sentinel (L2): check for XSS/CSRF patterns
-```
-
-### Backend Packs (`@rune/backend`, `@rune/saas`)
-```
-cook (L1) ← detects Express/FastAPI/Django → calls pack skill
-pack skill → scout (L2): scan API routes and models
-pack skill → db (L2): schema and migration check
-pack skill → sentinel (L2): security audit
-```
-
-### Data/AI Packs (`@rune/ai-ml`, `@rune/analytics`)
-```
-cook (L1) ← detects ML framework → calls pack skill
-pack skill → scout (L2): find model files and data pipelines
-pack skill → perf (L2): inference performance check
-pack skill → verification (L3): run model tests
-```
-
-### DevOps Packs (`@rune/devops`)
-```
-deploy (L2) ← calls pack skill for platform-specific deploy
-launch (L1) ← calls pack skill for infrastructure setup
-pack skill → watchdog (L3): setup platform monitoring
-pack skill → sentinel (L2): infrastructure security scan
-```
-
----
-
-## Submission Process
-
-1. **Fork** `github.com/rune-kit/rune`
-2. **Create** `extensions/your-pack-name/PACK.md`
-3. **Validate** your pack passes both gates (self-check below)
-4. **Run** structural validator: `node scripts/validate-skills.js`
-5. **Open PR** with title: `feat(l4): add @rune/pack-name — [one-line description]`
-
-### PR Description Template
-
-```markdown
-## New L4 Pack: @rune/pack-name
-
-### Gate 1 — Domain Coherence
-[Explain: what domain does this serve? Why are these skills cohesive?]
-
-### Gate 2 — Core Mesh Integration
-Inbound: [which L1-L3 skills call this pack, and when?]
-Outbound: [which L1-L3 skills does this pack call?]
-
-### Skills
-- `skill-1`: [what it does]
-- `skill-2`: [what it does]
-
-### Who needs this?
-[Describe the developer audience — job title, stack, use case]
-```
-
----
-
-## Review Criteria
-
-Pack PRs are reviewed against these criteria:
-
-| Criterion | Pass | Fail |
-|-----------|------|------|
-| Gate 1: Domain coherence | All skills serve same domain | Mixed domains or generic skills |
-| Gate 2: Mesh integration | ≥2 connections to L1-L3 | 0 or 1 connections |
-| PACK.md completeness | All required sections present | Missing Skills, Connections, or metadata |
-| Connection accuracy | Stated connections verified in L1-L3 SKILL.md files | Claimed connections not in L1-L3 files |
-| Skill count | 3-6 skills | <3 (too thin) or >6 (too broad) |
-| Naming | Lowercase kebab-case, ≤48 chars | CamelCase, numbers, or overly specific names |
-| No bloat | Skills would fail Rune's core 5-gate filter | Skills duplicate existing L1-L3 functionality |
-
----
-
-## What Makes a Good L4 Skill?
-
-**Good L4 skill:**
-- Domain-specific knowledge that belongs in L4 (not generic enough for L1-L3)
-- Clear integration points with the core mesh
-- Would be used together with other skills in the same pack
-
-**Bad L4 skill:**
-- Wraps an existing L1-L3 skill with minor variation (The Bloat)
-- Generic enough to belong in the core mesh (should be a core PR instead)
-- 0 mesh connections (dead node)
-
----
-
-## Example: Good vs Bad Pack
-
-```markdown
-# GOOD: @rune/trading
-
-Skills: market-data-validator, risk-calculator, backtest-runner, portfolio-analyzer
-Domain: Algorithmic trading — financial data validation, risk management, backtesting
-Connections: called by cook (L1), calls scout (L2) + sentinel (L2) + perf (L2)
-Why L4 not L3: Trading domain knowledge is not language-agnostic — belongs in L4
-
-# BAD: @rune/code-helpers
-
-Skills: code-formatter, variable-renamer, comment-generator, snippet-library
-Domain: Generic utilities with no domain coherence
-Connections: 0 inbound, 0 outbound
-Why rejected: These are Claude's base capabilities wrapped in skills. Zero mesh value.
-```
-
----
-
-## Version Policy
-
-L4 packs use semver independently of the Rune core. See `docs/VERSIONING.md`.
-
-- `0.x.y` — experimental, API may change
-- `1.0.0` — stable, API contract locked
-- Patch (`x.x.N`) — bug fixes, content improvements
-- Minor (`x.N.0`) — new skills added to pack
-- Major (`N.0.0`) — breaking change to skill interface or connection contract