@rune-kit/rune 2.6.0 → 2.7.0

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,32 @@ 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)
+
+> From OpenSpec (Fission-AI/OpenSpec, 32.8k★): "Dependencies without metadata create phantom coupling."
+
+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 +335,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/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/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.