@rune-kit/rune 2.1.1

package/skills/browser-pilot/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: browser-pilot
+description: Playwright browser automation. Navigates URLs, takes screenshots, checks accessibility tree, interacts with UI elements, and reports findings.
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L3
+  model: sonnet
+  group: media
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# browser-pilot
+
+## Purpose
+
+Browser automation for testing and verification using MCP Playwright tools. Navigates to URLs, captures accessibility snapshots and screenshots, interacts with UI elements (click, type, fill form), and reports findings with visual evidence.
+
+## Called By (inbound)
+
+- `test` (L2): e2e and visual testing
+- `deploy` (L2): verify live deployment
+- `debug` (L2): capture browser console errors
+- `marketing` (L2): screenshot for assets
+- `launch` (L1): verify live site after deployment
+- `perf` (L2): Lighthouse / Core Web Vitals measurement
+
+## Calls (outbound)
+
+None — pure L3 utility using Playwright MCP tools.
+
+## Executable Instructions
+
+### Step 1: Receive Task
+
+Accept input from calling skill:
+- `url` — target URL to open
+- `task` — what to do: `screenshot` | `check_elements` | `fill_form` | `test_flow` | `console_errors`
+- `interactions` — optional list of actions (click X, type Y into Z, etc.)
+
+### Step 2: Navigate
+
+Open the target URL using the Playwright MCP navigate tool:
+
+```
+mcp__plugin_playwright_playwright__browser_navigate({ url: "<url>" })
+```
+
+Wait for the page to load. If navigation fails (timeout or error), report UNREACHABLE and stop.
+
+### Step 3: Snapshot
+
+Capture the accessibility tree to understand page structure:
+
+```
+mcp__plugin_playwright_playwright__browser_snapshot()
+```
+
+Use the snapshot to:
+- Identify interactive elements (buttons, inputs, links)
+- Find specific elements referenced in the task
+- Detect accessibility issues (missing labels, roles)
+
+### Step 4: Interact
+
+Based on the task, perform interactions using Playwright MCP tools:
+
+- **Click**: `mcp__plugin_playwright_playwright__browser_click({ ref: "<ref>", element: "<description>" })`
+- **Type**: `mcp__plugin_playwright_playwright__browser_type({ ref: "<ref>", text: "<value>" })`
+- **Fill form**: `mcp__plugin_playwright_playwright__browser_fill_form({ fields: [...] })`
+- **Navigate back**: `mcp__plugin_playwright_playwright__browser_navigate_back()`
+- **Select option**: `mcp__plugin_playwright_playwright__browser_select_option({ ref: "<ref>", values: [...] })`
+
+Limit: max 20 interactions per session. If the task requires more, stop and report partial results.
+
+After each interaction, take a new snapshot to verify the result before proceeding.
+
+### Step 5: Screenshot
+
+Capture visual evidence:
+
+```
+mcp__plugin_playwright_playwright__browser_take_screenshot({ type: "png" })
+```
+
+For full-page capture (landing pages, long content):
+
+```
+mcp__plugin_playwright_playwright__browser_take_screenshot({ type: "png", fullPage: true })
+```
+
+Save with a descriptive filename if the `filename` param is supported.
+
+### Step 6: Report
+
+Compile findings into a structured report:
+
+```
+## Browser Report: [url]
+
+- **Task**: [task description]
+- **Status**: SUCCESS | PARTIAL | FAILED
+
+### Page Info
+- HTTP Status: [status]
+- Load outcome: [loaded | timeout | error]
+
+### Accessibility Findings
+- [finding from snapshot — missing labels, broken roles, etc.]
+
+### Interaction Log
+- [action taken] → [result: success | element not found | error]
+
+### Console Errors
+- [error message — source]
+
+### Screenshots
+- [screenshot path or description]
+
+### Summary
+- [overall assessment — what works, what failed, any critical issues]
+```
+
+### Step 7: Close
+
+Always close the browser when done:
+
+```
+mcp__plugin_playwright_playwright__browser_close()
+```
+
+This step is mandatory even if earlier steps fail. Use a try-finally pattern in your reasoning.
+
+## Output Format
+
+Structured Browser Report with task status, page info, accessibility findings, interaction log, console errors, screenshots, and summary. See Step 6 Report above for full template.
+
+## Constraints
+
+1. MUST close browser when done — Step 7 is non-optional even if earlier steps fail
+2. MUST NOT exceed 20 interactions per session
+3. MUST NOT store credentials or sensitive data in interaction logs
+4. MUST take screenshot evidence before reporting visual findings
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Not closing browser when done (including on error) | CRITICAL | Constraint 1: Step 7 browser_close() is mandatory — treat as try-finally |
+| Storing credentials or tokens in interaction logs | HIGH | Constraint 3: redact all sensitive values before logging |
+| Exceeding 20 interactions without stopping and reporting partial | MEDIUM | Constraint 2: stop at 20, report what was tested and what remains |
+| Reporting visual findings without screenshot evidence | MEDIUM | Constraint 4: screenshot before reporting — "looks broken" without screenshot is invalid |
+
+## Done When
+
+- URL navigated successfully (or UNREACHABLE reported)
+- Page snapshot captured for accessibility context
+- All requested interactions completed (or partial with reason if >20)
+- Screenshot taken as visual evidence
+- Console errors captured if task requested them
+- Browser closed (Step 7 executed)
+- Browser Report emitted with status, findings, and screenshot reference
+
+## Cost Profile
+
+~500-1500 tokens input, ~300-800 tokens output. Sonnet for interaction logic.

package/skills/completion-gate/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: completion-gate
+description: "Validates agent claims against evidence trail. Catches 'done' without proof, 'tests pass' without output, 'fixed' without verification. Called by cook and team at workflow end."
+user-invocable: false
+metadata:
+  author: runedev
+  version: "1.1.0"
+  layer: L3
+  model: haiku
+  group: validation
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# completion-gate
+
+## Purpose
+
+The lie detector for agent claims. Validates that what an agent says it did actually happened — with evidence. Catches the #1 failure mode in AI coding: claiming completion without proof.
+
+<HARD-GATE>
+Every claim requires evidence. No evidence = UNCONFIRMED = BLOCK.
+"I ran the tests and they pass" without stdout = UNCONFIRMED.
+"I fixed the bug" without before/after diff = UNCONFIRMED.
+"Build succeeds" without build output = UNCONFIRMED.
+</HARD-GATE>
+
+## Triggers
+
+- Called by `cook` in Phase 5d (quality gate)
+- Called by `team` before merging stream results
+- Called by any skill that reports "done" to an orchestrator
+- Auto-trigger: when agent says "done", "complete", "fixed", "passing"
+
+## Calls (outbound)
+
+None — pure validator. Reads evidence, produces verdict.
+
+## Called By (inbound)
+
+- `cook` (L1): Phase 5d — validate completion claims before commit
+- `team` (L1): validate cook reports from parallel streams
+
+## Execution
+
+### Step 1 — Collect Claims
+
+Parse the agent's output for completion claims. Common claim patterns:
+
+```
+CLAIM PATTERNS:
+  "tests pass" / "all tests passing" / "test suite green"
+  "build succeeds" / "build complete" / "compiles clean"
+  "no lint errors" / "lint clean"
+  "fixed" / "resolved" / "bug is gone"
+  "implemented" / "feature complete" / "done"
+  "no security issues" / "sentinel passed"
+```
+
+Extract each claim as: `{ claim: string, source_skill: string }`
+
+### Step 2 — Match Evidence
+
+For each claim, look for corresponding evidence in the conversation context:
+
+| Claim Type | Required Evidence | Where to Find |
+|---|---|---|
+| "tests pass" | Test runner stdout with pass count | Bash output from test command |
+| "build succeeds" | Build command stdout showing success | Bash output from build command |
+| "lint clean" | Linter stdout (even if empty = 0 errors) | Bash output from lint command |
+| "fixed" | Git diff showing the change + test proving fix | Edit/Write tool calls + test output |
+| "implemented" | Files created/modified matching the plan | Write/Edit tool calls vs plan |
+| "no security issues" | Sentinel report with PASS verdict | Sentinel skill output |
+| "coverage ≥ X%" | Coverage tool output with actual percentage | Test runner with coverage flag |
+
+### Step 3 — Validate Each Claim
+
+For each claim + evidence pair:
+
+```
+IF evidence exists AND evidence supports claim:
+  → CONFIRMED
+IF evidence exists BUT contradicts claim:
+  → CONTRADICTED (most serious — agent is wrong)
+IF no evidence found:
+  → UNCONFIRMED (agent may be right but didn't prove it)
+```
+
+### Step 4 — Report
+
+```
+## Completion Gate Report
+- **Status**: CONFIRMED | UNCONFIRMED | CONTRADICTED
+- **Claims Checked**: [count]
+- **Confirmed**: [count] | **Unconfirmed**: [count] | **Contradicted**: [count]
+
+### Claim Validation
+| # | Claim | Evidence | Verdict |
+|---|---|---|---|
+| 1 | "All tests pass" | Bash: `npm test` → "42 passed, 0 failed" | CONFIRMED |
+| 2 | "Build succeeds" | No build command output found | UNCONFIRMED |
+| 3 | "No lint errors" | Bash: `npm run lint` → "3 errors" | CONTRADICTED |
+
+### Gaps (if any)
+- Claim 2: Re-run `npm run build` and capture output
+- Claim 3: Agent claimed clean but lint shows 3 errors — fix required
+
+### Verdict
+UNCONFIRMED — 1 claim lacks evidence, 1 contradicted. Cannot proceed to commit.
+```
+
+## Verdict Rules
+
+```
+ALL claims CONFIRMED         → overall CONFIRMED (proceed)
+ANY claim CONTRADICTED       → overall CONTRADICTED (BLOCK — fix the contradiction)
+ANY claim UNCONFIRMED        → overall UNCONFIRMED (BLOCK — provide evidence)
+  (no CONTRADICTED)
+```
+
+## Output Format
+
+Completion Gate Report with status (CONFIRMED/UNCONFIRMED/CONTRADICTED), claim validation table, gaps, and verdict. See Step 4 Report above for full template.
+
+## Constraints
+
+1. MUST check every completion claim against actual tool output — not agent narrative
+2. MUST flag missing evidence as UNCONFIRMED — absence of proof is not proof of absence
+3. MUST flag contradictions as CONTRADICTED — this is more serious than missing evidence
+4. MUST NOT accept "I verified it" as evidence — show the command output
+5. MUST be fast (haiku) — this runs on every cook completion
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Agent rephrases claim to avoid detection | MEDIUM | Pattern matching covers common phrasings — extend as new patterns emerge |
+| Evidence from a DIFFERENT test run (stale) | HIGH | Check that evidence timestamp/context matches current changes |
+| Agent pre-generates evidence by running commands proactively | LOW | This is actually GOOD behavior — we want agents to provide evidence |
+| Completion-gate itself claims "all confirmed" without evidence | CRITICAL | Gate report MUST include the evidence table — no table = report is invalid |
+
+## Done When
+
+- All completion claims extracted from agent output
+- Each claim matched against tool output evidence
+- Verdict table emitted with claim/evidence/verdict for each item
+- Overall verdict: CONFIRMED / UNCONFIRMED / CONTRADICTED
+- If not CONFIRMED: specific gaps listed with remediation steps
+
+## Cost Profile
+
+~500-1000 tokens input, ~200-500 tokens output. Haiku for speed. Runs frequently as part of cook's quality phase.

package/skills/constraint-check/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: constraint-check
+description: "Meta-validator for HARD-GATEs. Verifies that skills' mandatory constraints were followed during a workflow. Called by cook, team, and audit to audit discipline compliance."
+user-invocable: false
+metadata:
+  author: runedev
+  version: "1.1.0"
+  layer: L3
+  model: haiku
+  group: validation
+  tools: "Read, Glob, Grep"
+---
+
+# constraint-check
+
+## Purpose
+
+The internal affairs department for Rune skills. Checks whether HARD-GATEs and mandatory constraints were actually followed during a workflow — not just claimed to be followed. Reads the constraint definitions from skill files and audits the conversation trail for compliance.
+
+While `completion-gate` checks if claims have evidence, `constraint-check` checks if the PROCESS was followed. Did you actually write tests before code? Did you actually get plan approval? Did you actually run sentinel?
+
+## Triggers
+
+- Called by `cook` (L1) at end of workflow as discipline audit
+- Called by `team` (L1) to verify stream agents followed constraints
+- Called by `audit` (L2) during quality dimension assessment
+- `/rune constraint-check` — manual audit of current session
+
+## Calls (outbound)
+
+None — pure read-only validator.
+
+## Called By (inbound)
+
+- `cook` (L1): end-of-workflow discipline audit
+- `team` (L1): verify stream agent compliance
+- `audit` (L2): quality dimension
+- User: manual session audit
+
+## Execution
+
+### Step 1 — Identify Active Skills
+
+Parse the conversation/workflow to identify which skills were invoked:
+
+```
+Extract from context:
+  - Skills invoked via Skill tool (exact list)
+  - Skills referenced in agent narrative
+  - Phase progression (cook phases completed)
+```
+
+### Step 2 — Load Constraint Definitions
+
+For each invoked skill, extract HARD-GATEs and numbered constraints:
+
+```
+For each skill in invoked_skills:
+  Read: skills/<skill>/SKILL.md
+  Extract:
+    - <HARD-GATE> blocks → mandatory, violation = BLOCK
+    - ## Constraints numbered list → required, violation = WARN
+    - ## Mesh Gates table → required gates
+```
+
+### Step 3 — Audit Compliance
+
+Check each constraint against the conversation evidence:
+
+| Constraint Type | How to Verify | Evidence Source |
+|---|---|---|
+| "MUST write tests BEFORE code" | Test file Write/Edit timestamps before implementation Write/Edit | Tool call ordering |
+| "MUST get user approval" | User message containing "go"/"yes"/"proceed" after plan | Conversation history |
+| "MUST run verification" | Bash command with test/lint/build output | Tool call results |
+| "MUST show actual output" | Stdout captured in agent response | Agent messages |
+| "MUST NOT modify files outside scope" | Git diff files vs plan file list | Git + plan comparison |
+| "Iron Law: delete code before test" | No implementation code exists before test creation | Tool call ordering |
+
+### Step 4 — Classify Violations
+
+| Violation Type | Severity | Meaning |
+|---------------|----------|---------|
+| HARD-GATE violation | BLOCK | Skill says this is non-negotiable |
+| Constraint violation | WARN | Skill says this is required but not fatal |
+| Best practice skip | INFO | Recommended but optional |
+
+### Step 5 — Report
+
+```
+## Constraint Check Report
+- **Status**: COMPLIANT | VIOLATIONS_FOUND | CRITICAL_VIOLATION
+- **Skills Audited**: [count]
+- **Constraints Checked**: [count]
+- **Violations**: [count by severity]
+
+### HARD-GATE Violations (BLOCK)
+- [skill:test] Iron Law: implementation code written at tool_call #12 BEFORE test file created at #15
+- [skill:cook] Plan Gate: Phase 4 started without user approval message
+
+### Constraint Violations (WARN)
+- [skill:verification] Constraint 2: "All tests pass" claimed at message #20 without stdout evidence
+- [skill:sentinel] Constraint 3: files scanned list not included in report
+
+### Compliance Summary
+| Skill | HARD-GATEs | Constraints | Status |
+|-------|-----------|-------------|--------|
+| cook | 3/3 ✓ | 6/7 (1 WARN) | WARN |
+| test | 0/1 ✗ | 8/9 (1 WARN) | BLOCK |
+| verification | 1/1 ✓ | 4/6 (2 WARN) | WARN |
+| sentinel | 1/1 ✓ | 7/7 ✓ | PASS |
+
+### Remediation
+- BLOCK: test Iron Law — delete implementation, restart with test-first
+- WARN: verification — re-run and capture stdout
+```
+
+## Constraint Catalog (Quick Reference)
+
+Key HARD-GATEs across skills that constraint-check audits:
+
+| Skill | HARD-GATE | Check Method |
+|---|---|---|
+| test | Tests BEFORE code (Iron Law) | Tool call ordering |
+| cook | Scout before plan, plan before code | Phase progression |
+| plan | Every code phase has test entry | Plan content |
+| verification | Evidence for every claim | Stdout capture |
+| sentinel | BLOCK = halt pipeline | No commit after BLOCK |
+| preflight | BLOCK = halt pipeline | No commit after BLOCK |
+| debug | No code changes during debug | No Write/Edit in debug |
+| debug | 3-fix escalation | Fix attempt counter |
+| brainstorm | No implementation before approval | User message check |
+
+## Output Format
+
+Constraint Check Report with status (COMPLIANT/VIOLATIONS_FOUND/CRITICAL_VIOLATION), HARD-GATE violations, constraint violations, compliance summary table, and remediation steps. See Step 5 Report above for full template.
+
+## Constraints
+
+1. MUST check all HARD-GATEs for every invoked skill — not just the ones that seem relevant
+2. MUST use tool call ordering (not agent narrative) to verify temporal constraints
+3. MUST distinguish HARD-GATE violations (BLOCK) from constraint violations (WARN)
+4. MUST report specific evidence for each violation — not just "violated"
+5. MUST NOT accept agent's self-report as compliance evidence — check independently
+
+## Sharp Edges
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Agent self-reports compliance and constraint-check trusts it | CRITICAL | Constraint 5: check tool calls independently, not agent narrative |
+| Only checking cook constraints, missing test/sentinel/etc | HIGH | Constraint 1: audit ALL invoked skills, not just the orchestrator |
+| Temporal check wrong (tool calls reordered in context) | MEDIUM | Use tool call sequence numbers, not message ordering |
+| Too strict on optional steps (INFO treated as BLOCK) | LOW | Step 4 classification: only HARD-GATE = BLOCK, constraints = WARN |
+
+## Done When
+
+- All invoked skills identified from context
+- HARD-GATEs and constraints extracted from each skill's SKILL.md
+- Each constraint checked against conversation evidence
+- Violations classified as BLOCK/WARN/INFO
+- Compliance summary table emitted per skill
+- Remediation steps listed for each violation
+
+## Cost Profile
+
+~1000-2000 tokens input, ~500-1000 tokens output. Haiku for speed — reads skill files and checks tool call ordering.

package/skills/context-engine/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: context-engine
+description: "Context window management. Auto-triggered when context is filling up. Triggers smart compaction and preserves critical information across compaction boundaries. Called by L1 orchestrators at context thresholds."
+user-invocable: false
+metadata:
+  author: runedev
+  version: "0.4.0"
+  layer: L3
+  model: haiku
+  group: state
+  tools: "Read, Glob, Grep"
+---
+
+# context-engine
+
+## Purpose
+
+Context window management for long sessions. Detects when context is approaching limits, triggers smart compaction preserving critical decisions and progress, and coordinates with session-bridge to save state before compaction. Prevents the common failure mode of losing important context mid-workflow.
+
+### Behavioral Contexts
+
+Context-engine also manages **behavioral mode injection** via `contexts/` directory. Three modes are available:
+
+| Mode | File | When to Use |
+|------|------|-------------|
+| `dev` | `contexts/dev.md` | Active coding — bias toward action, code-first |
+| `research` | `contexts/research.md` | Investigation — read widely, evidence-based |
+| `review` | `contexts/review.md` | Code review — systematic, severity-labeled |
+
+**Mode activation**: Orchestrators (cook, team, rescue) can set the active mode by writing to `.rune/active-context.md`. The session-start hook injects the active context file into the session. Mode switches mid-session are supported — the orchestrator updates the file and references the new behavioral rules.
+
+**Default**: If no `.rune/active-context.md` exists, no behavioral mode is injected (standard Claude behavior).
+
+## Triggers
+
+- Called by `cook` and `team` automatically at context boundaries
+- Auto-trigger: when tool call count exceeds threshold or context utilization is high
+- Auto-trigger: before compaction events
+
+## Calls (outbound)
+
+# Exception: L3→L3 coordination
+- `session-bridge` (L3): coordinate state save when context critical
+
+## Called By (inbound)
+
+- Auto-triggered at phase boundaries and context thresholds by L1 orchestrators
+
+## Execution
+
+### Step 1 — Count tool calls
+
+Count total tool calls made so far in this session. This is the ONLY reliable metric — token usage is not exposed by Claude Code and any estimate will be dangerously inaccurate.
+
+Do NOT attempt to estimate token percentages. Tool count is a directional proxy, not a precise measurement.
+
+### Step 2 — Classify health
+
+Map tool call count to health level:
+
+```
+GREEN   (<50 calls)    — Healthy, continue normally
+YELLOW  (50-80 calls)  — Load only essential files going forward
+ORANGE  (80-120 calls) — Recommend /compact at next logical boundary
+RED     (>120 calls)   — Trigger immediate compaction, save state first
+```
+
+These thresholds are directional heuristics, not precise limits. Sessions with many large file reads may hit context limits earlier; sessions with mostly Grep/Glob may go longer.
+
+#### Large-File Adjustment
+
+Projects with large source files (Python modules often 500-1500 LOC, Java files similarly) consume significantly more context per `Read` call. If the session has read files averaging >500 lines, apply a 0.8x multiplier to all thresholds:
+
+```
+Adjusted thresholds (large-file sessions):
+GREEN   (<40 calls)    — Healthy, continue normally
+YELLOW  (40-65 calls)  — Load only essential files going forward
+ORANGE  (65-100 calls) — Recommend /compact at next logical boundary
+RED     (>100 calls)   — Trigger immediate compaction, save state first
+```
+
+Detection: count `Read` tool calls that returned >500 lines. If ≥3 such calls → activate large-file thresholds for the remainder of the session.
+
+### Step 3 — If YELLOW
+
+Emit advisory to the calling orchestrator:
+
+> "[X] tool calls. Load only essential files. Avoid reading full files when Grep will do."
+
+Do NOT trigger compaction yet. Continue execution.
+
+### Step 4 — If ORANGE
+
+Emit recommendation to the calling orchestrator:
+
+> "[X] tool calls. Recommend /compact at next phase boundary (after current module completes)."
+
+Identify the next safe boundary (end of current loop iteration, end of current file being processed) and flag it.
+
+### Step 5 — If RED
+
+Immediately trigger state save via `rune:session-bridge` (Save Mode) before any compaction occurs.
+
+Pass to session-bridge:
+- Current task and phase description
+- List of files touched this session
+- Decisions made (architectural choices, conventions established)
+- Remaining tasks not yet started
+
+After session-bridge confirms save, emit:
+
+> "Context CRITICAL ([X] tool calls, likely near limit). State saved to .rune/. Run /compact now."
+
+Block further tool calls until compaction is acknowledged.
+
+### Step 6 — Report
+
+Emit the context health report to the calling skill.
+
+## Context Health Levels
+
+```
+GREEN   (<50 calls)    — Healthy, continue normally
+YELLOW  (50-80 calls)  — Load only essential files
+ORANGE  (80-120 calls) — Recommend /compact at next logical boundary
+RED     (>120 calls)   — Save state NOW via session-bridge, compact immediately
+```
+
+Note: These are tool call counts, NOT token percentages. Claude Code does not expose context utilization to skills. Tool count is a directional signal only.
+
+## Output Format
+
+```
+## Context Health
+- **Tool Calls**: [count]
+- **Status**: GREEN | YELLOW | ORANGE | RED
+- **Recommendation**: continue | load-essential-only | compact-at-boundary | compact-immediately
+- **Note**: Tool count is a directional proxy. Check CLI status bar for actual context usage.
+
+### Critical Context (preserved on compaction)
+- Task: [current task]
+- Phase: [current phase]
+- Decisions: [count saved to .rune/]
+- Files touched: [list]
+- Blockers: [if any]
+```
+
+## Constraints
+
+1. MUST preserve context fidelity — no summarizing away critical details
+2. MUST flag context conflicts between skills — never silently pick one
+3. MUST NOT inject stale context from previous sessions without marking it as historical
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Triggering compaction without saving state first | CRITICAL | Step 5 (RED): session-bridge MUST run before any compaction — state loss is irreversible |
+| Blocking tool calls when context is ORANGE (not RED) | MEDIUM | ORANGE = recommend only; blocking is only for RED (>120 calls) |
+| Injecting stale context from previous session without marking it historical | HIGH | Constraint 3: all loaded context must include session date marker |
+| Premature compaction from over-estimated utilization | MEDIUM | Tool count is directional only — sessions with heavy Read calls may need lower thresholds; only block at confirmed RED |
+| Not activating large-file adjustment on Python/Java codebases | MEDIUM | Track Read calls returning >500 lines; if ≥3 occur, switch to adjusted (0.8x) thresholds for the session |
+
+## Done When
+
+- Tool call count captured
+- Health level classified from count thresholds (GREEN / YELLOW / ORANGE / RED)
+- Appropriate advisory emitted matching health level (no advisory for GREEN)
+- If RED: session-bridge called and confirmed saved before compaction signal
+- Context Health Report emitted with tool count, status, and recommendation
+
+## Cost Profile
+
+~200-500 tokens input, ~100-200 tokens output. Haiku for minimal overhead. Runs frequently as a background monitor.