/framework-health

name: framework-health
description: "Evaluate Mycelium's own process effectiveness. Measures cycle velocity, discard trends, confidence calibration, gate effectiveness, regression rate. Run quarterly or every 20 cycles."
metadata:
  instruction_budget: "50"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Framework Health Check

Mycelium evaluates its own process. This is triple-loop learning — the framework assessing whether it is getting better at producing good outcomes.

When to Use

• Quarterly review (scheduled)
• After 20 completed leaf cycles (triggered by cycle-history.yml count)
• When process friction is suspected
• Before major framework changes (baseline measurement)

Workflow

1. Load Cycle Data

Read `.claude/canvas/cycle-history.yml`.

**Framework-self-host detection** (per `engine/cycle-learning.md#framework-on-framework-exemption`): if the project root contains `plugins/mycelium/plugin.json` AND `CLAUDE.md` begins with `# Mycelium:`, this is the framework dogfooding itself. Skip the cycle-count gate and route to a corrections-graduation summary:

• Count entries in `.claude/memory/corrections.md` (total, and ×graduated-to-mechanism in the last 90 days).
• Read `.claude/memory/cluster-instances.md` and list clusters at-or-above their graduation criterion that are not yet graduated (this is the framework analogue of "actual outcome vs predicted ICE").
• Skip cycle-derived dimensions (velocity, discard rate, confidence calibration, regression rate) — they do not apply. Still run Steps 2b, 4b, 4c, 4d.

Otherwise (product project, not framework-self-host): if fewer than 5 cycles recorded, report: "Insufficient cycle data for framework health assessment. [N] cycles recorded; minimum 5 needed. Continue recording outcomes."

2. Measure Five Dimensions

For each dimension, compute the metric and compare against trend (if prior assessments exist):

**Cycle Velocity**:

• Average days from diamond creation to completion, grouped by scale
• Trend: improving / stable / degrading
• If degrading: flag for investigation

**Discard Rate**:

• Count of discards per lifecycle phase
• Average discard phase (1-10 scale)
• Trend: shifting earlier (good) / shifting later (bad) / stable
• If >50% of discards at Phase 7+: flag "late discard pattern"

**Confidence Calibration**:

• **Cycle-class scope (per `engine/cycle-learning.md#cycle-class`)**: ONLY `product-leaf` cycles feed calibration. `meta-dogfood` (framework-self-development) and `observation` (strategic-process reflection) cycles carry no ICE *by design* — they are EXCLUDED, not missing. This matches `cycle-history.yml#calibration_summary`, which already excludes them from aggregates; the dimension was previously computed over all cycles, which is the bug this fixes.
• For `product-leaf` cycles with predicted confidence/ICE and actual outcome:
• Compute: actual success rate per confidence band (0.3-0.5, 0.5-0.7, 0.7-0.9)
• Compare with expected rate (confidence 0.7 should succeed ~70%)
• Report calibration factor: actual/expected
• If calibration factor < 0.8 or > 1.2: flag miscalibration
• **If 0 product-leaf cycles**: report calibration as **"honestly empty — N meta-dogfood + M observation cycles, 0 product-leaf"**, status `empty-by-design`. Do NOT flag it as warning/critical and do NOT synthesize a factor from non-product cycles. For a project early in delivery (no leaf shipped yet) this is the correct early state; for a framework-self-host / dogfood project it is the steady state (its work is meta-dogfood, not product delivery).
• **Masking guard (protects real product projects):** if the project is *actually doing product/delivery work* (active L3/L4 product diamonds, shipped features) yet shows 0 product-leaf cycles, that is a **cycle_class mis-assignment to investigate** — NOT an empty-by-design pass. Surface it: "0 product-leaf cycles despite active delivery — check cycle_class on recent entries." Only treat empty as by-design when the absence of product-leaf cycles is itself honest (discovery-phase or framework-self-development).

**Gate Effectiveness**:

• **SOURCE: `cycle-history.yml#cycles[].gates_fired`.** Named explicitly as of v0.121.0, because

this dimension previously said "count the gates" without saying from what — and the field that `engine/cycle-learning.md` added expressly to close it (*"was unInstrumented in cycle records"*) was read by nothing. Producer specced, consumer unwired, dimension computed from air.

• For each theory gate, count: times checked, times passed, times failed
• Compute hit rate: failures / total checks
• Flag rubber stamps (0% failure rate) and hard blocks (>80% failure rate)
• **IF NO CYCLE CARRIES `gates_fired`, REPORT THE DIMENSION AS `no-data`, NAMING THE COUNT** —

*"no-data: 0 of N closed cycles carry gates_fired"* — and say the next `/mycelium:retrospective` populates it. **Do NOT reconstruct gate outcomes from memory, the transcript, or a read of the guards.** A dimension filled by hand at assessment time reports on the assessor, not on the cycles, and it is indistinguishable in the dashboard from one backed by records. The validator already emits this absence as a WARN; the dashboard must not paper over what the validator flags.

• **Theory X/Y audit** (per `${CLAUDE_PLUGIN_ROOT}/harness/theory-tensions.md` Tension 7): for any hard-block gate, check it is *scaffolding* (surfaces its why, an escape hatch exists, leaves the user more capable), not *coercion* (compliance for its own sake, no surfaced reason, no escape). A high-block gate that fails this audit is a Theory-X drift to remediate, not just a strict gate.

**Demand Mix** (Seddon: value demand vs failure demand):

• **SOURCE: