evolve-harness

/evolve-harness — Adaptation Governance

You are modifying an existing domain harness. Every modification must respect the layered mutability classification.

Before Any Modification

1. Read the current harness-config.json from the harness directory ($CLAUDE_PROJECT_DIR/harness-config.json)
2. Read the mutability classification from $CLAUDE_PROJECT_DIR/schemas/mutability-tags.json — this is the harness's own copy, placed there by /new-harness at instantiation time. Do NOT read from the plugin; the harness must be able to evolve itself without the plugin being installed.
3. Classify each proposed change against the mutability tags

If $CLAUDE_PROJECT_DIR/schemas/mutability-tags.json is not present, the harness is missing a self-containment guarantee — either it predates the Self-Containment rule (constitution principle 6, added 2026-04-13) or instantiation was incomplete. Report this to the user and recommend applying the 2026-04-13-plugin-decoupling patch before proceeding. Do NOT fall back to reading the plugin's copy, even if the plugin is available — silently reading from the plugin would hide the missing guarantee.

Enforcement Rules

L1 (Immutable) → REFUSE

If the proposed change targets an L1 element, refuse it entirely. Explain:

• What element they are trying to change
• Why it is classified as L1 (immutable)
• What emergence or structural guarantee it protects
• That creating a new harness via /new-harness is the path for fundamental changes

L1 elements include:

• identity.purpose — the identity anchor
• identity.hardcoded_constraints — bright lines
• identity.conflict_resolution_order — Safe > Honest > Compliant > Helpful
• identity.authority_hierarchy — Base training > Operator > User > Tool results
• meta.name, meta.domain, meta.created — harness identity
• The 6 primitives themselves
• The activation protocol (lifecycle hook mappings)

Never modify an L1 element regardless of how the user frames the request.

L2 (Confirm) → REQUIRE EXPLICIT CONFIRMATION

If the proposed change targets an L2 element:

1. Show the current value and the proposed new value
2. Explain what downstream effects the change will have:
   • Changing confidence_threshold → affects abstention frequency
   • Changing abstention_triggers → changes when the system refuses to answer
   • Changing never_learn → removes a Goodhart's Law guard
   • Changing tier1 → changes what the system knows at session start
   • Changing persona (name/expertise) → affects user expectations
3. Ask for explicit confirmation: "This is an L2 (confirm-required) change. Proceed?"
4. Only apply after the user explicitly confirms

L3 (Free) → ALLOW

If the proposed change targets an L3 element, apply it directly. No confirmation needed.

L3 elements include:

• identity.persona.tone
• memory.topic_categories
• memory.consolidation_frequency
• learning.learn
• context.tier2, context.tier3
• context.external_systems

After Modification

1. Bump the version in harness-config.json (patch for L3 changes, minor for L2 changes)
2. Update any affected files (rules, memory structure, MCP config)
3. Run /health-check to validate the modified harness
4. Report what was changed and the new version number

Edge Cases

• If unsure about the mutability classification of an element, treat it as L2 (confirm)
• If a change spans multiple elements at different levels, process each at its own level
• If a change to an L3 element would effectively alter an L1 guarantee (e.g., removing all memory categories would break the Memory primitive), refuse it as if it were L1

Error Handling

• If harness-config.json is not found in the current directory, inform the user and suggest running /meta-harness:new-harness first
• If harness-config.json is malformed JSON, report the parse error and do not attempt modifications
• If the mutability tags schema is not found at $CLAUDE_PROJECT_DIR/schemas/mutability-tags.json, report the missing file and refuse to proceed (cannot enforce mutability without the classification). Recommend applying the 2026-04-13-plugin-decoupling patch, which copies the schema into the harness.
• If /health-check fails after modification, show the failures and attempt to fix them before delivering