@rune-kit/rune 2.6.0 → 2.8.0

package/skills/fix/SKILL.md

@@ -3,7 +3,7 @@ name: fix
 description: Apply code changes and fixes. Writes implementation code, applies bug fixes, and verifies changes with tests. Core action hub in the development mesh.
 metadata:
   author: runedev
-  version: "0.6.0"
+  version: "0.8.0"
   layer: L2
   model: sonnet
   group: development
@@ -68,6 +68,29 @@ Read and fully understand the fix request before touching any file.
 - If the request is ambiguous or root cause is unclear → call `rune:debug` before proceeding
 - Note the scope: single function, single file, or multi-file change
 
+### Step 1b: Recovery Policy Matrix
+
+Before locating code, classify the incoming error/task into a recovery category to determine the right fix strategy. This prevents wasting effort on the wrong approach.
+
+| Error Type | Recovery Action | Strategy |
+|------------|----------------|----------|
+| `INPUT_REQUIRED` — missing user input, ambiguous spec | **PROMPT_USER** | Return NEEDS_CONTEXT with specific questions. Do NOT guess. |
+| `INPUT_INVALID` — wrong format, type mismatch, encoding | **AUTO_FIX** | Fix at validation layer. Add schema validation (Zod/Pydantic) if missing. |
+| `TIMEOUT` — operation exceeded time limit | **RETRY** with adjustment | Increase timeout, add retry with exponential backoff, or chunk the operation. |
+| `POLICY_BLOCKED` — security gate, lint rule, contract violation | **ABORT** | Do NOT work around the policy. Report to caller with the specific rule that blocked. |
+| `PERMISSION_DENIED` — auth failure, file access, API scope | **PROMPT_USER** | Cannot fix permissions programmatically. Report exact permission needed. |
+| `DEPENDENCY_ERROR` — missing package, version conflict, broken dep | **AUTO_FIX** | Install missing dep, resolve version conflict, or suggest alternative package. |
+| `LOGIC_ERROR` — wrong output, incorrect calculation, bad algorithm | **INVESTIGATE** | Do NOT auto-fix. Call `rune:debug` — logic errors need root cause analysis. |
+| `ENVIRONMENT_ERROR` — wrong Node/Python version, missing system dep | **PROMPT_USER** | Report exact version/tool needed. Agent cannot change system environment. |
+
+**Decision flow**:
+1. Read the incoming diagnosis/error
+2. Classify into one of the 8 error types above
+3. Apply the recovery action — this determines whether to proceed (AUTO_FIX, RETRY), ask (PROMPT_USER), stop (ABORT), or re-diagnose (INVESTIGATE)
+4. Announce: "Recovery policy: {error_type} → {action}"
+
+**Why**: Without a recovery matrix, fix attempts the same strategy (read → change → test) for every error type. A POLICY_BLOCKED error doesn't need code reading — it needs the policy reported. An INPUT_REQUIRED error doesn't need debugging — it needs a question asked. Matching strategy to error type eliminates wasted cycles.
+
 ### Step 2: Locate
 
 Find the exact files and lines to change.
@@ -263,6 +286,8 @@ Known failure modes for this skill. Check these before declaring done.
 | Single-point validation (fix one spot, hope it holds) | MEDIUM | Step 5: add entry + business logic + environment + debug layers for data-flow bugs |
 | Removing debug instrumentation before fix is verified | MEDIUM | Step 5b: preserve `#region agent-debug` markers until all tests pass — premature cleanup erases failure history |
 | Runaway fix loop — 20+ fixes without checking quality decay | HIGH | Step 4.5: WTF-likelihood self-regulation. >20% risk = STOP. Hard cap 30 fixes/session. Each fix adds risk — diminishing returns after ~15 |
+| Each fix creates a new bug elsewhere — whack-a-mole | CRITICAL | Tight coupling signal. STOP fixing → escalate to debug with note "each fix creates new failure — suspect structural issue". Debug will route to plan for redesign |
+| Applying same fix strategy to every error type | MEDIUM | Step 1b Recovery Policy Matrix: classify error type FIRST — POLICY_BLOCKED needs reporting not fixing, INPUT_REQUIRED needs questions not code |
 
 ## Done When
 

package/skills/mcp-builder/SKILL.md

@@ -3,7 +3,7 @@ name: mcp-builder
 description: Build Model Context Protocol servers from specifications. Generates tool definitions, resource handlers, and test suites for MCP servers in TypeScript or Python (FastMCP).
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L2
   model: sonnet
   group: creation
@@ -321,6 +321,58 @@ mcp-server-<name>/
 - Installation: Claude Code, Cursor, Windsurf config snippets
 - Configuration reference (env vars with descriptions)
 
+## Reference Pattern: Multi-Provider Adapter
+
+When the MCP server needs to call multiple AI providers (e.g., both Anthropic and OpenAI), use the **Provider Adapter** pattern to normalize different APIs behind a unified interface.
+
+### Interface
+
+```typescript
+interface ProviderAdapter {
+  formatRequest(params: RequestParams): { url: string; init: RequestInit };
+  parseResponse(data: unknown): { content: string; usage: TokenUsage | null };
+  formatStreamRequest(params: RequestParams): { url: string; init: RequestInit };
+  parseSSEEvent(eventType: string, data: string): StreamChunk | null;
+}
+```
+
+### Discriminated Union for Stream Chunks
+
+```typescript
+type StreamChunk =
+  | { type: "thinking"; content: string }
+  | { type: "text"; content: string }
+  | { type: "done" }
+  | { type: "done_with_usage"; usage: TokenUsage }
+  | { type: "usage_delta"; inputTokens?: number; outputTokens?: number }
+  | { type: "error"; message: string };
+```
+
+### When to Apply
+
+- MCP server wraps multiple AI providers (e.g., a router server that dispatches to Claude, GPT, or local models)
+- MCP server aggregates responses from multiple APIs with different response formats
+- MCP server needs to support streaming from providers with different SSE event schemas
+
+### Key Implementation Notes
+
+- Each provider adapter handles its own SSE event types (Anthropic: `content_block_delta`, `message_start`; OpenAI: `response.output_text.delta`, `[DONE]`)
+- Buffer management for SSE: handle incomplete lines, track event types, manage abort signals
+- Provider-specific prompt tuning: some models benefit from additional constraints (e.g., "Maximum 2-3 paragraphs" for verbose models)
+- Per-provider token tracking: normalize different usage reporting formats into a single `TokenUsage` type
+
+### Cost-Aware Model Selection
+
+When building MCP servers that call AI providers, support **dual-model configuration** — allow users to specify a primary model for critical operations and a cheaper model for background tasks (summarization, classification, metadata extraction). This avoids burning expensive API credits on tasks that don't need maximum quality.
+
+```typescript
+// config.ts
+const config = {
+  primaryModel: process.env.PRIMARY_MODEL || 'claude-sonnet-4-20250514',
+  backgroundModel: process.env.BACKGROUND_MODEL || 'claude-haiku-4-5-20251001',
+};
+```
+
 ## Constraints
 
 1. MUST validate all tool inputs with Zod (TS) or Pydantic (Python) — never trust AI-provided inputs

package/skills/onboard/SKILL.md

@@ -3,7 +3,7 @@ name: onboard
 description: Auto-generate project context for AI sessions. Scans codebase, creates CLAUDE.md and .rune/ setup so every future session starts with full context.
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L2
   model: sonnet
   group: quality
@@ -227,6 +227,56 @@ Audit the project's baseline context cost from MCP servers and agent configurati
 
 **Skip if**: Total MCP tools ≤80 AND CLAUDE.md ≤150 lines (healthy baseline).
 
+### Step 6e — AI-Driven Interview (Optional, User-Initiated)
+
+When invoked as `/rune onboard --interview` or when the project is too ambiguous for automated detection (e.g., no package.json, no clear entry point, mixed languages), switch to **conversational onboarding** — the AI asks targeted questions instead of relying solely on file scanning.
+
+#### Interview Flow
+
+Ask 5-8 questions in sequence, adapting based on answers. Start broad, narrow based on responses:
+
+```
+Q1: "What does this project do in one sentence?"
+    → Captures purpose (README may be missing or outdated)
+
+Q2: "Who uses this — internal team, external users, or both?"
+    → Determines audience, affects DEVELOPER-GUIDE.md tone
+
+Q3: "What's the main entry point — where does execution start?"
+    → Bypasses file scanning for complex monorepos
+
+Q4: "What commands do you use daily? (dev server, tests, build)"
+    → Gets verified commands instead of guessing from config files
+
+Q5: "Any areas of the codebase you'd warn a new developer about?"
+    → Captures tribal knowledge that no scan can detect
+
+Q6: "Are there external services this depends on? (databases, APIs, queues)"
+    → Maps integration points for Architecture Map
+
+Q7: "What's the deployment story — how does code get to production?"
+    → Captures CI/CD context
+
+Q8 (conditional): "Anything else a new session should know that's not in the code?"
+    → Catches edge cases, workarounds, known issues
+```
+
+#### Interview Rules
+
+- **Adapt**: Skip questions that were already answered by earlier responses. If Q1 reveals "it's a Next.js app", don't ask about the framework.
+- **Validate**: Cross-reference answers with actual file scan results. If user says "we use Jest" but `vitest.config.ts` exists, ask to clarify.
+- **Merge**: Interview answers supplement (not replace) automated scan. Scan provides facts, interview provides context and intent.
+- **Store**: Save interview responses as high-confidence entries in `.rune/conventions.md` and `.rune/cumulative-notes.md` (tagged `[from-interview]`)
+
+#### When to Auto-Suggest Interview
+
+Suggest switching to interview mode (but don't force it) when:
+- Step 2 produces 3+ "unknown" fields in tech stack detection
+- Project has no README.md and no package.json/pyproject.toml/Cargo.toml
+- Project appears to be a monorepo with 3+ distinct sub-projects
+
+Output: `"ℹ️ This project is hard to auto-detect. Run /rune onboard --interview for guided setup."`
+
 ### Step 7 — Commit
 Use `Bash` to stage and commit the generated files:
 ```bash

package/skills/perf/SKILL.md

@@ -3,7 +3,7 @@ name: perf
 description: Performance regression gate. Detects N+1 queries, sync-in-async, missing indexes, memory leaks, and bundle bloat before they reach production.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: quality
@@ -242,6 +242,39 @@ Emit structured report:
 ### Verdict: PASS | WARN | BLOCK
 ```
 
+### Step 8.5 — Token Budget Tracking (AI-Powered Apps)
+
+For projects that call AI APIs (detected via imports of `anthropic`, `openai`, `@anthropic-ai/sdk`, `@ai-sdk/core`, `langchain`, `llamaindex`, or `fastmcp`), audit token usage patterns per operation type.
+
+**Scan for:**
+
+| Pattern | Finding | Impact |
+|---------|---------|--------|
+| AI call inside a loop without batching | `TOKEN_LOOP — [file:line] — AI call in loop over [collection] — batch or parallelize` | Cost scales linearly with collection size |
+| No token usage tracking | `NO_TOKEN_TRACKING — [file:line] — AI response usage not captured — add cost logging` | Invisible spend, no budget control |
+| Expensive model for simple tasks | `MODEL_MISMATCH — [file:line] — using [opus/gpt-4] for [classification/extraction] — use [haiku/gpt-4.1-mini]` | 10-30x cost difference for same result |
+| Missing max_tokens on open-ended prompts | `UNBOUNDED_TOKENS — [file:line] — no max_tokens on [call] — add limit to prevent runaway cost` | Single call can consume entire budget |
+| Duplicate AI calls for same input | `DUPLICATE_AI_CALL — [file:line] — same prompt sent to [provider] without caching — add response cache` | Wasted tokens on redundant calls |
+
+**Per-Operation Cost Awareness:**
+
+When token tracking IS present, analyze the operation type breakdown:
+
+```
+Operation Type          Avg Tokens    Frequency    Monthly Est.
+─────────────────────────────────────────────────────────────
+Chat (primary)          2,500 in/800 out    high         $X.XX
+Background notes        500 in/200 out      per-chat     $X.XX
+Summarization           1,500 in/300 out    periodic     $X.XX
+Classification          200 in/50 out       high         $X.XX
+─────────────────────────────────────────────────────────────
+Total estimated monthly                                  $X.XX
+```
+
+**Report this under a `### AI Token Budget` subsection** in the Perf Report. Only include when AI API usage detected — skip entirely for non-AI projects.
+
+**Key insight**: The most impactful optimization is often **model selection per operation** — using a cheaper model for background tasks (summarization, classification, metadata extraction) while reserving expensive models for primary user-facing interactions. A 10x cost reduction on 60% of calls = 6x overall savings.
+
 ## Output Format
 
 ```

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<150 lines each). Each session handles 1 phase. Uses opus for deep reasoning.
 metadata:
   author: runedev
-  version: "1.1.0"
+  version: "1.2.0"
   layer: L2
   model: opus
   group: creation
@@ -260,6 +260,30 @@ After spec approved → transition to Implementation Mode.
 
 Every plan output — master plan, phase file, or inline plan — MUST end with an **Outcome Block** containing: What Was Planned + Immediate Next Action (single action, imperative) + How to Measure table (at least one shell command).
 
+## Change Stacking (Overlap Detection)
+
+When producing phase files with wave-based task grouping, every task MUST declare dependency metadata:
+
+```markdown
+### Task: Implement auth middleware
+- **File**: `src/middleware/auth.ts` — new
+- **touches**: [src/middleware/auth.ts, src/types/auth.d.ts]
+- **provides**: [AuthMiddleware, verifyToken()]
+- **requires**: [UserModel from Wave 1]
+- **depends_on**: [task-1a]
+```
+
+**Pre-dispatch validation** (run after all tasks written, before presenting plan):
+
+| Check | Detection | Action |
+|-------|-----------|--------|
+| **File overlap** | Same file in `touches[]` of 2+ tasks in same wave | BLOCK — move to sequential waves or merge tasks |
+| **Missing dependency** | Task A's `requires[]` not in any prior task's `provides[]` | BLOCK — add missing task or fix dependency chain |
+| **Cycle detection** | Task A `depends_on` B, B `depends_on` A | BLOCK — decompose into smaller tasks to break cycle |
+| **Orphaned provides** | Task declares `provides[]` but no future task `requires[]` it | WARN — may indicate dead code or missing consumer task |
+
+**Skip if**: Inline plan (trivial task), single-phase plan, or all tasks are strictly sequential.
+
 ## Constraints
 
 1. MUST produce master plan + phase files for non-trivial tasks (3+ phases OR 5+ files OR 100+ LOC)
@@ -309,6 +333,8 @@ Every plan output — master plan, phase file, or inline plan — MUST end with
 | Recommending shortcut approach without Completeness Score | MEDIUM | Step 5.5: every alternative needs X/10 Completeness score + dual effort estimate (human vs AI). "Saves 70 LOC" is not a reason when AI makes the delta cost minutes |
 | Plan output missing Outcome Block | MEDIUM | Every plan output MUST end with Outcome Block (What Was Planned + Immediate Next Action + How to Measure) — executor drift when omitted |
 | Outcome Block "Next Action" is a list, not one action | LOW | One action only — ambiguity about where to start causes re-analysis and lost context |
+| Overlapping file ownership across parallel phases/streams | HIGH | Change Stacking: every task declares `touches[]` — overlap detection flags same file in 2+ tasks before execution |
+| Missing dependency between tasks that share artifacts | HIGH | Every task declares `provides[]` and `requires[]` — cycle detection + missing dep check before dispatch |
 
 ## Self-Validation
 

package/skills/preflight/SKILL.md

@@ -3,7 +3,7 @@ name: preflight
 description: Pre-commit quality gate that catches "almost right" code. Goes beyond linting — checks logic correctness, error handling, regressions, and completeness.
 metadata:
   author: runedev
-  version: "0.6.0"
+  version: "0.7.0"
   layer: L2
   model: sonnet
   group: quality
@@ -237,6 +237,40 @@ When a domain pack is installed (e.g., `@rune-pro/finance`, `@rune-pro/legal`),
 - `src/billing/invoice.ts:42` — WARN: price calculation uses `toFixed(2)` instead of `Intl.NumberFormat`
 ```
 
+### Step 4.6 — Organization Approval Requirements (Business)
+
+If `.rune/org/org.md` exists, load organization approval workflows and enforce them as additional quality gates.
+
+1. `Read` `.rune/org/org.md` and extract `## Policies`, `## Approval Flows`, and `## Governance Level`
+2. Apply organization-level quality requirements:
+
+| Org Policy | Preflight Check | Severity |
+|------------|----------------|----------|
+| `minimum_reviewers` | Verify PR has required reviewer count before merge | WARN: "Org requires {N} reviewers" |
+| `self-merge_allowed` | If "Never" or "No", flag self-merge attempts | BLOCK if org prohibits |
+| `required_checks` | Verify all org-required checks (tests, security scan, type check, lint) are passing | BLOCK if missing |
+| `staging_required` | If "Yes", verify staging deployment exists before production | WARN if no staging step |
+| `feature_flags` | If "Required for user-facing changes", flag new UI without feature flag | WARN |
+| `cross-domain_changes` | If changes span multiple team domains, require reviewer from each | WARN |
+
+3. Load `## Approval Flows > ### Feature Launch` and display the required approval chain:
+   - Output: "Org approval chain: {flow}" so developer knows the full pipeline
+   - If governance level is "Maximum", flag any attempt to skip gates
+
+4. Append org findings under `### Organization Requirements` section:
+
+```
+### Organization Requirements
+- **Org template**: [startup|mid-size|enterprise]
+- **Governance level**: [Minimal|Moderate|Maximum]
+- **Minimum reviewers**: 2 (1 must be director+)
+- **Required checks**: tests (≥80% coverage), security scan, type check, lint
+- **Approval chain**: contributor proposes → lead reviews → vp approves → deploy
+- WARN: Self-merge not allowed per org policy
+```
+
+If `.rune/org/org.md` does not exist, skip and log INFO: "no org config, organization requirements check skipped".
+
 ### Step 4.8 — Preflight Composite Score
 
 After all domain hooks (Step 4.5) and completeness checks (Step 4) complete, compute a **Preflight Health Score** to make the verdict numeric and comparable across runs.

package/skills/research/SKILL.md

@@ -3,7 +3,7 @@ name: research
 description: Web search and external knowledge lookup. Gathers data on technologies, libraries, best practices, and competitor solutions.
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L3
   model: haiku
   group: knowledge
@@ -67,6 +67,29 @@ Call `WebSearch` for each query. Collect result titles, URLs, and snippets. Iden
 - **Diversity: never select 3+ URLs from the same domain** — spread across source types
 
 
+### Step 2b — Diminishing Returns Detection
+
+After each WebSearch call, evaluate whether additional searches are productive:
+
+**Track across search results**:
+- **Entity set**: Extract key entities from each result set (library names, API names, version numbers, technique names, company names)
+- **New entity ratio**: `new_entities_in_this_search / total_entities_found_so_far`
+- **Result overlap**: How many URLs from this search were already seen in previous searches
+
+| Signal | Threshold | Action |
+|--------|-----------|--------|
+| New entity ratio < 10% | Last search added almost nothing new | Skip remaining queries, proceed to Step 3 with existing results |
+| Result overlap > 60% | Most URLs already fetched or seen | Skip this query's results entirely |
+| All 3 queries return same top 3 URLs | Search space is exhausted | Proceed directly to Step 3 — more queries won't help |
+
+**Report when triggered**:
+```
+Note: Research saturation reached after [N] searches — [M] unique entities found.
+Additional queries showed <10% new information. Proceeding with synthesis.
+```
+
+**Why**: Research skills commonly waste 2-3 WebFetch calls on pages that repeat information already gathered. Saturation detection saves tool calls and context tokens while preserving research quality — the first 3 sources typically contain 90%+ of available information.
+
 ### Step 3 — Deep Dive
 
 Call `WebFetch` on the top 3-5 URLs identified in Step 2. Hard limit: **max 5 WebFetch calls** per research invocation. For each fetched page:

package/skills/retro/SKILL.md

@@ -3,7 +3,7 @@ name: retro
 description: Engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with trend tracking. Per-person breakdowns, shipping streaks, and actionable improvements. Use when asked for "retro", "weekly review", "what did we ship", or "engineering retrospective".
 metadata:
   author: runedev
-  version: "0.1.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: knowledge
@@ -28,6 +28,7 @@ Retro is ENCOURAGING but CANDID. Every critique is anchored in specific commits,
 - `/rune retro 14d` — sprint retro (2 weeks)
 - `/rune retro 30d` — monthly review
 - `/rune retro compare` — current vs previous period side-by-side
+- `/rune retro --business` — cross-domain executive retrospective with HTML report (Business tier)
 - Called by `audit` (L2) for engineering health dimension
 - Auto-suggest: end of work week (Friday sessions)
 
@@ -226,6 +227,60 @@ Structure (~800-1500 words — concise, not a novel):
 
 **Tone**: Encouraging but candid. Specific and concrete. Anchored in actual commits, not vague impressions. Every critique paired with a specific suggestion.
 
+## Milestone Progressive Analysis
+
+At specific project milestones, retro automatically generates a **deeper analysis** with a different focal point per milestone. This goes beyond the standard weekly retro — it's a reflective checkpoint on the project's evolution.
+
+### Milestone Detection
+
+Count total retro snapshots in `.rune/retros/` (each represents ~1 retro session). Trigger milestone analysis when count reaches:
+
+| Milestone | Retro Count | Focal Point | Depth |
+|-----------|------------|-------------|-------|
+| First Month | 4 | **Foundations** — Are conventions solid? Is the architecture scaling? Are early decisions holding? | Standard + foundation review |
+| Quarter | 12 | **Patterns** — What recurring themes emerged? Which areas churn most? Is technical debt growing or shrinking? | Standard + theme extraction |
+| Half Year | 24 | **Growth** — How has the codebase evolved? Are the original architectural bets paying off? What would you do differently? | Standard + architecture review |
+| One Year | 50 | **Maturity** — Full project health assessment. Velocity trends over time. Team growth patterns. Knowledge distribution. | Standard + full evolution timeline |
+
+### Milestone Execution
+
+When a milestone is detected (retro count matches a threshold for the first time):
+
+1. **Announce**: `"🏁 Milestone: [name] ([count] retros). Generating deep analysis..."`
+2. **Load history**: Read ALL `.rune/retros/*.json` snapshots (not just the most recent)
+3. **Compute evolution metrics**: Plot key metrics over time (commits/week, test ratio, fix ratio, session depth)
+4. **Focal analysis**: Generate the milestone-specific analysis based on the focal point column above
+5. **Trend narrative**: Write a 300-500 word narrative on how the project has evolved, anchored in actual data
+6. **Save**: Write milestone report to `.rune/retros/{YYYY-MM-DD}-milestone-{name}.md`
+
+### Milestone Report Structure
+
+```markdown
+## Milestone: [name] — [date]
+
+### Evolution Timeline
+[ASCII chart or table showing key metrics across all retro snapshots]
+
+### [Focal Point] Analysis
+[300-500 words anchored in data — specific commits, files, metrics]
+
+### What's Working
+- [pattern that's improving, with evidence]
+
+### What Needs Attention
+- [pattern that's degrading, with evidence]
+
+### Recommendations
+- [1-3 concrete actions based on the focal analysis]
+```
+
+### Rules
+
+- Milestone analysis is **additive** — it runs ON TOP of the standard retro, not instead of it
+- Each milestone triggers ONCE — check if `.rune/retros/*-milestone-{name}.md` already exists before generating
+- If retro history is sparse (gaps >30 days), note this in the report — trends may be unreliable
+- Milestone analysis does NOT count toward the retro's normal output — it's a separate artifact
+
 ## Compare Mode
 
 When invoked as `/rune retro compare`:
@@ -247,6 +302,45 @@ SELF-VALIDATION (run before emitting report):
 - [ ] No code was modified — retro is read-only
 ```
 
+## Business Mode (--business)
+
+When invoked as `/rune retro --business`, generate a cross-domain executive retrospective with HTML output. Requires Business tier (`.rune/org/org.md` should exist).
+
+### Business Data Sources
+
+Pull from all installed domain packs:
+- **Engineering**: git history (commits, velocity, test ratio, fix ratio, hotspots)
+- **Revenue** (@rune-pro/sales): pipeline metrics, deal velocity, churn risk
+- **Support** (@rune-pro/support): ticket volume, SLA compliance, CSAT
+- **Finance** (@rune-business/finance): burn rate, runway, budget variance
+- **Compliance** (@rune-business/legal): framework status, audit dates, open items
+
+### Business Execution Steps
+
+1. **Gather**: Run standard retro Steps 1-10 for engineering data
+2. **Org Context**: Read `.rune/org/org.md` for team structure and governance level
+3. **Cross-Domain KPIs**: Aggregate metrics from domain signal history (`.rune/signals/`)
+4. **Team Health**: Score each team from org config on velocity, quality, morale
+5. **Compliance**: Check compliance frameworks from org security policies
+6. **HTML Render**: Load `report-templates/retro-business.html` from Business pack and populate all `{{placeholder}}` fields with computed data
+7. **Save**: Write HTML to `.rune/retros/{YYYY-MM-DD}-business.html`
+8. **Also save** JSON snapshot (same as standard retro) for trend tracking
+
+### Business Output
+
+```
+.rune/retros/2026-03-30-business.html  — Self-contained HTML report
+.rune/retros/2026-03-30.json           — Machine-readable metrics
+```
+
+The HTML report includes: KPI cards with trend deltas, domain performance bars (engineering, revenue, support, finance), team health table, compliance status, key insights (wins + risks), and is printable to PDF via Ctrl+P.
+
+### Graceful Degradation
+
+- If no Business pack installed: skip business mode, fall back to standard retro
+- If domain data unavailable: show "No data" for that domain, don't fail
+- If `.rune/org/org.md` missing: use generic team structure, WARN in report
+
 ## Constraints
 
 1. MUST NOT modify any code — retro is read-only analysis

package/skills/review/SKILL.md

@@ -3,7 +3,7 @@ name: review
 description: Code quality review — patterns, security, performance, correctness. Finds bugs, suggests improvements, triggers fix for issues found. Escalates to opus for security-critical code.
 metadata:
   author: runedev
-  version: "0.5.0"
+  version: "0.6.0"
   layer: L2
   model: sonnet
   group: development
@@ -252,6 +252,47 @@ Produce a structured severity-ranked report.
 - Include a Positive Notes section (good patterns observed)
 - Include a Verdict: APPROVE | REQUEST CHANGES | NEEDS DISCUSSION
 
+### Step 6.5: Fix-First Triage
+
+> From gstack (garrytan/gstack, 50.9k★): "Reviews that produce 20 findings and delegate all to the user waste everyone's time."
+
+Classify each finding as **AUTO-FIX** or **ASK** before reporting:
+
+| Category | Auto-Fix? | Examples |
+|----------|-----------|---------|
+| Dead imports, unused variables | AUTO-FIX | `import { foo } from './bar'` where foo is never used |
+| Missing error handling on obvious paths | AUTO-FIX | `await fetch()` without try/catch in production code |
+| Console.log in production code | AUTO-FIX | Remove `console.log` from non-CLI production files |
+| Architectural concern, trade-off | ASK | "This bypasses the auth middleware — intentional?" |
+| Ambiguous intent | ASK | "Is this fallback behavior correct for null users?" |
+| Style/convention disagreement | ASK | "Project uses camelCase but this file uses snake_case" |
+
+**After classification:**
+- Apply AUTO-FIX findings directly via `rune:fix` — include all in a single batch
+- Collect ASK findings into ONE `AskUserQuestion` — not 5 separate questions
+- Report both: "Auto-fixed 4 issues. 2 findings need your input: [...]"
+
+**Rationalization prevention**: "This looks fine" is NOT acceptable without evidence. If you can't cite a specific file:line or convention that justifies the code, flag it as UNVERIFIED — don't rationalize away uncertainty.
+
+### Step 6.6: Scope Drift Detection
+
+> From gstack (garrytan/gstack, 50.9k★): "Intent vs diff catches scope creep that plan-based guards miss."
+
+After reviewing code, compare **stated intent** vs **actual diff**:
+
+1. Read the originating source: TODO list, PR description, commit messages, or plan file
+2. Extract stated intent: "what was this change supposed to do?"
+3. Run `git diff --stat` to see actual file changes
+4. Compare:
+
+| Result | Meaning | Action |
+|--------|---------|--------|
+| **CLEAN** | All changed files serve the stated intent | Note in report |
+| **DRIFT** | 1-2 files changed that don't relate to stated intent | WARN — "These files were modified but aren't mentioned in the task: [list]" |
+| **REQUIREMENTS_MISSING** | Stated intent mentions files/features not in the diff | WARN — "Task mentions X but it's not in the diff" |
+
+**This is informational, not blocking.** Scope drift is common and sometimes intentional — but making it visible prevents silent creep.
+
 After reporting:
 - If any CRITICAL findings: call `rune:fix` immediately with the finding details
 - If any HIGH findings: call `rune:fix` with the finding details
@@ -476,6 +517,9 @@ When `cook` or `ship` checks review status: compare review commit hash with curr
 | Suggesting "add X" without checking if X is used | MEDIUM | YAGNI pushback: grep codebase for the suggested feature → if uncalled anywhere → respond "Not called anywhere. Remove? (YAGNI)". Valid pushback, not laziness |
 | Adding abstractions "for future flexibility" | MEDIUM | Three similar lines > premature abstraction. Only abstract when there are 3+ concrete callers today |
 | Missing cross-phase integration check at phase boundary | MEDIUM | When reviewing a phase completion: check orphaned exports, uncalled routes, auth gaps, E2E flow continuity. Delegate to completion-gate Step 4.5 |
+| Review loop exceeds 3 iterations without resolution | MEDIUM | Cap at 3 review loops. After 3rd iteration with unresolved findings → surface to user with "these findings persist after 3 fix attempts — needs human decision" |
+| Auto-fixing something that should have been ASK | HIGH | When in doubt, ASK. AUTO-FIX only for mechanical issues (dead imports, console.log). Anything involving intent or trade-offs = ASK |
+| Scope drift flagged on intentional refactoring | LOW | Scope drift is informational, not blocking. User can override with "intentional" — don't re-flag after override |
 
 ## Done When
 

package/skills/scope-guard/SKILL.md

@@ -136,6 +136,7 @@ Known failure modes for this skill. Check these before declaring done.
 | Classifying lock file changes as out-of-scope | LOW | package-lock.json, yarn.lock, Cargo.lock are always IN_SCOPE |
 | SIGNIFICANT CREEP threshold applied to 1-2 unplanned files | LOW | MINOR = 1-2 files, SIGNIFICANT = 3+ files — don't escalate prematurely |
 | Plan not loadable (no TodoWrite, no progress.md) | MEDIUM | Ask calling skill for plan as text description before proceeding |
+| Scope check against plan but not against stated intent | MEDIUM | Plan-based scope guard catches file drift; review Step 6.6 (Scope Drift Detection) catches intent drift. Both should run for full coverage |
 
 ## Done When
 

package/skills/scout/SKILL.md

@@ -3,7 +3,7 @@ name: scout
 description: "Fast codebase scanner. Use when any skill needs codebase context. Finds files, patterns, dependencies, project structure. Pure read-only — never modifies files."
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L2
   model: haiku
   group: creation
@@ -79,6 +79,27 @@ Based on the scan request, run focused searches:
 
 **Verification gate**: At least 1 relevant file found, OR confirm the target does not exist.
 
+#### Info Saturation Detection (Know When to Stop)
+
+Scout's default is "max 10 file reads" — but the real question is whether additional reads are productive. Track saturation across Phase 2 searches:
+
+**Entity tracking**: As you scan files, extract key entities (function names, class names, imports, API endpoints, config keys). Maintain a running set of discovered entities.
+
+| Signal | Threshold | Meaning | Action |
+|--------|-----------|---------|--------|
+| **New entity ratio** | Last 2 file reads added <2 new entities | Search is exhausted for this domain | STOP scanning, move to Phase 3 |
+| **Content similarity** | Last 2 files share >70% of the same imports/patterns | Files are in the same module, redundant reads | Skip remaining files in this directory |
+| **Query variation** | 3+ Glob/Grep queries with different patterns all return the same files | All search angles converge | Domain is fully mapped, proceed |
+
+**When saturation detected**: Emit in Scout Report:
+```
+### Saturation
+- Reached after [N] file reads — last 2 reads added [M] new entities
+- Recommendation: synthesize_and_report (further scanning unlikely to yield new insights)
+```
+
+**Why**: Without saturation detection, scout reads its full budget of 10 files even when 3 files already contain everything needed. This wastes context tokens and delays the calling skill. Early saturation detection returns control faster.
+
 ### Phase 3: Dependency Mapping
 
 1. Use `Grep` to find import/require/use statements in identified files

package/skills/sentinel/SKILL.md

@@ -3,7 +3,7 @@ name: sentinel
 description: Automated security gatekeeper. Blocks unsafe code before commit — secret scanning, OWASP top 10, dependency audit, permission checks. A GATE, not a suggestion.
 metadata:
   author: runedev
-  version: "0.8.0"
+  version: "0.9.0"
   layer: L2
   model: sonnet
   group: quality
@@ -198,6 +198,40 @@ If `.rune/contract.md` exists, validate staged changes against project contract
 
 If `.rune/contract.md` does not exist, skip and log INFO: "no project contract, contract validation skipped".
 
+### Step 4.86 — Organization Policy Enforcement (Business)
+
+If `.rune/org/org.md` exists, load organization security policies and enforce them as additional gates.
+
+1. `Read` `.rune/org/org.md` and extract the `## Policies > ### Security` section
+2. For each org security policy, validate staged changes:
+
+| Org Policy | Check | Severity |
+|------------|-------|----------|
+| `dependency_audit_frequency` | Verify audit cadence matches org requirement | WARN if overdue |
+| `secret_rotation` | Flag secrets older than org-defined rotation period | WARN |
+| `compliance_frameworks` | Ensure listed frameworks (SOC2, GDPR, HIPAA, PCI-DSS) checks are active | WARN if missing |
+| `penetration_testing` | Log when last pentest was conducted vs org schedule | INFO |
+| `separation_of_duties` | Verify commit author ≠ PR approver when org requires it | BLOCK if violated |
+
+3. Check `## Policies > ### Code Review` for minimum reviewer requirements:
+   - If org requires N reviewers, include in report: "Org policy requires {N} reviewer(s)"
+   - If org requires security reviewer for auth/data paths, flag auth-touching changes
+
+4. Check `## Policies > ### Deployment` for deploy window and feature flag requirements:
+   - If org requires feature flags for user-facing changes, flag new UI code without feature flag wrapper
+
+5. Append org policy findings to the sentinel report under `### Organization Policy` section
+
+```
+### Organization Policy
+- **Org template**: [startup|mid-size|enterprise]
+- **Governance level**: [Minimal|Moderate|Maximum]
+- `auth/login.ts` — WARN: org requires security reviewer for auth paths (Policy: Code Review)
+- Deploy window: Weekdays 09:00-16:00 (org policy)
+```
+
+If `.rune/org/org.md` does not exist, skip and log INFO: "no org config, organization policy check skipped".
+
 ### Step 4.9 — Six-Gate Finding Validation
 
 Before reporting ANY finding as BLOCK or WARN, it MUST pass through these 6 gates. Any gate failure → downgrade to INFO or discard. This prevents hallucinated vulnerabilities from blocking real work.