/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.
• **Which confidence (note added 0.319.0)**: the bands below are on a 0.0-1.0 scale read as a chance of success. An ICE Confidence scored since 0.319.0 is a value of Gilad's Confidence Meter on 0-10 (`/mycelium:ice-score` Step 2), a sum of evidence weights and not a probability. Do NOT divide it by ten or place it in these bands. For a cycle whose `predicted.ice_score` carries a meter value, report that the calibration factor was not computed for it and say why. How to compare a meter-scored prediction with its outcome is not designed yet, and no source read describes it.
• 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 recor