| name | cybernetic-debugging-workflow |
| description | Use when a cybernetic pre-goal or runtime failure is unclear, repeated, cross-component, or at risk of being patched without locating the failing invariant and owner. |
Cybernetic Debugging Workflow
Purpose
Convert unexpected behavior into a reproducible counterexample, a classified
fault owner, and the smallest justified repair.
Workflow
- Capture the exact failing state, event, artifacts, hashes, command, and
observed output.
- Reproduce the failure or state why current evidence cannot reproduce it.
- Trace backward across component boundaries until the earliest violated
invariant is identified.
- Compare with a working path and list the material differences.
- Form one falsifiable root-cause hypothesis and test it with the smallest
discriminating probe.
- Classify ownership as artifact, shared infrastructure, compiler, verifier,
authority, human semantics, or external dependency.
- Apply the smallest authorized repair, then rerun the original counterexample
and the affected control-chain checks.
Non-Convergence
Track repeated failures by invariant, owner, relevant artifact hashes, and
smallest counterexample. Escalate to DiagnoseNonConvergence only when the same
fingerprint repeats without meaningful artifact change.
Test Policy
A durable regression test is optional. Add one when the discovered
counterexample protects a critical invariant or makes future verification
materially cheaper; otherwise preserve focused runtime evidence.
Boundaries
- Do not make speculative bundles of unrelated changes.
- Do not translate infrastructure defects into product semantics questions.
- Do not use a generic
Blocked state when a typed owner and next action exist.
