Systematic Debugging

Execute

→ Bug? Test failure? Unexpected behavior? → Find root cause first. No fixes without evidence.

1. Isolate: read error → reproduce → check git diff → drill upward through diagnostic layers:

L1 symptom → L2 logic → L3 system → L4 architecture → L5 cross-system contract → L6 platform constraint → L7 spec gap. Stop when no deeper "why" remains OR terminal unactionable (T1-T4).

1. Identify owner: compare with working code → locate canonical owner → flag duplicate owners as a finding
2. Before fixing, run Patch-Shape Triage and Ripple Signal Triage if the candidate fix touches shared/core/cross-module behavior, contract, source-of-truth, fallback, adapter, duplicate owner, producer+consumer, or consumer-side patching. Surface Change Necessity for non-trivial fixes. Run Minimality Check when the candidate fix adds a new branch, fallback, owner, adapter, or compatibility path. Also run Pre-Edit Complexity Check when the candidate fix touches an overloaded owner or may worsen source complexity.
3. Prove: one hypothesis → minimal test → iterate. 3+ failed fixes = question architecture, do not attempt another code fix.

After fix, if any symptom persists → differential diagnosis (Phase 4 Step 4bis).

1. Fix: failing test → minimal code at canonical owner → verify → Reflection + architecture review → repair + retirement track

→ Done when: confidence ≥ B, both tracks explicit, DeeperCause answered "no" with evidence, no H-class hard signal still active.

Systematic Debugging

Overview

Random fixes waste time and create new bugs. Symptom fixes are failure.

This skill is the canonical debugging workflow. Use it to move from symptom to root cause, then to the smallest sufficient stable repair and retirement plan. Smallest repair means correct owner + bug class fixed + bounded entropy, not the smallest textual diff.

When to Use

Any technical issue: test failures, bugs, unexpected behavior, performance problems, build/integration failures.

Especially under time pressure, when "just one quick fix" seems obvious, after multiple failed fixes, or when duplicate owners / fallback chains may be involved.

Quick bug lane

For low-risk, single-owner bugs, keep the report compact: Symptom, Reproduction, Root Cause, Change Necessity, Fix Boundary, and Verification. Still collect root-cause evidence before editing. Quick bug lane must surface Change Necessity before source edits; one compact sentence is enough when it names the user-visible need, no-change / non-code option, why code change is necessary, minimum change boundary, and an explicit decision token such as Decision: code-change; minimum-boundary wording is not a substitute for the decision. If fallback, duplicate owner, consumer-side patching, contract risk, shared logic, or cross-module behavior appears, escalate to the full workflow.

The Four Phases

Phase 1: Root Cause Investigation

BEFORE attempting ANY fix:

1. Read Error Messages Carefully

• Don't skip past errors or warnings — they often contain the exact solution
• Read stack traces completely; note line numbers, file paths, error codes

1. Reproduce Consistently

• Can you trigger it reliably? What are the exact steps? Does it happen every time?
• If not reproducible → consult feedback-loop-construction.md to build an automated reproduction loop; don't guess
• Record baseline: inputs, environment, version, logs, success/failure criteria

1. Check Recent Changes

• What changed that could cause this? Git diff, recent commits, new dependencies, config changes, environmental differences

1. Gather Evidence in Multi-Component Systems

• Instrument each component boundary: log what enters and exits
• Run once to see where data breaks, then focus investigation there

1. Trace Data Flow (when error is deep in call stack)

• Where does bad value originate? What called this with bad value?
• Keep tracing up until you find the source. Fix at source, not at symptom.
• For the complete backward tracing technique, see root-cause-tracing.md.

1. Drill Upward Through Diagnostic Layers

Start at L1. Exhaust all "why" questions at each layer before moving upward. The chain is open-ended — architecture is not the endpoint.

`` L1 Symptom: what failed? where? exact reproduction? L2 Logic: which branch, invariant, or state transition is wrong? L3 System: which component boundary, dependency, or ownership seam? L4 Architecture: what design choice, duplicated owner, or fallback chain? L5 Cross-system: which API / SLA / timing contract between systems? L6 Platform: what runtime / OS / framework constraint? L7 Spec gap: who never defined correct behavior for this case? ``

Hard signal definitions (H/T/D) are in the Quality Gate — apply them there, not during initial investigation.

When the stop layer is not obvious, the user asks where the diagnosis stops, the issue crosses component/system boundaries, or a user-provided fact falsifies the current layer, expose a compact Layer Stop Card before fixing:

```text Layer Stop Card:

• Current Stop Layer: L1 Symptom | L2 Logic | L3 System | L4 Architecture | L5 Cross-system Contract | L6 Platform | L7 Spec Gap | T-class boundary
• Checked Path:
• Evidence For Stop:
• Excluded Layers:
• Falsifier:
• User Intervention Point:
• Next Action:

```

The card is an advisory readback of the diagnostic stop point. It is not a GateDecision, PolicySnapshot, or completion authority.

1. Patch-Shape Triage Before Editing

Treat the first obvious fix as evidence, not clearance to edit. If the candidate fix shape matches any item below, continue upward before changing code unless you can prove the local layer is the canonical owner:

• keyword, phrase, regex, negation-word list, or sample-text exception
• local guard, extra conditional, try/catch, early return, or one-off branch
• fallback, adapter, compatibility branch, prompt branch, or legacy path expansion
• consumer/caller/readiness/presentation-layer patch
• downstream re-parsing of raw text when typed intent, normalized state,

contract, or another source-of-truth already exists

• artifact/download/export/readback/cache patch that does not first locate

the producer and source-of-truth owner

• duplicate parsing, duplicate owner, or "keep both for now" reasoning
• fix that only names the observed sample instead of the bug class

Required output before editing when this gate fires:

``text PatchShape: CanonicalOwner: UpwardDrillSignal: Decision: fix owner | continue investigation | escalate ``

If the tempting fix is "just add a small guard/fallback", also run:

```text Minimality Check:

• Smallest textual diff:
• Existing owner / reuse path:
• Correct owner:
• Bug class fixed:
• New branch/fallback added:
• Existence proof for new path:
• Old path retired or scheduled:
• Verdict: sufficient repair | local patch | needs first-principles review

```

local patch is a mitigation, not a sufficient repair, unless it is the canonical owner and includes a retention reason plus retirement trigger. For candidate additions that are not ordinary repair code, use docs/current/AEGIS_MINIMALITY_REFERENCE.md to check whether the new surface needs to exist before editing.

If the repair or retirement boundary depends on deleting old paths, retaining compat for a proven external dependency, or stopping on persistent-state risk, compose anti-entropy-governance before editing. It decides the path; it does not grant destructive authority.

1. Change Necessity

After root cause and canonical owner are identified, but before repair code, make the code-change decision visible. This is the "should code change at all?" check; it is not a new artifact and does not belong in the using-aegis hot path.

```text Change Necessity:

• User-visible need:
• No-change / non-code option:
• Why code change is necessary:
• Minimum change boundary:
• Decision: no-change | docs/config-only | code-change | needs-clarification

```

In quick bug lane, keep Decision: explicit even when using natural prose.

If the decision is no-change, do not edit source code. If the decision is docs/config-only, narrow the fix to that surface and verify it. If the decision is needs-clarification, pause before repair. If the decision is code-change, carry the minimum boundary into Fix Boundary, Minimality Check, and verification.

1. Pre-Edit Complexity Check

After root cause and canonical owner are identified, check whether the fix adds complexity to the wrong or overloaded place:

Use using-aegis/references/complexity-governance.md for shared pressure signals and the meaning of over-budget.

```text Pre-Edit Complexity Check:

• Target edit file:
• Existing pressure signal:
• Owner fit:
• Safer edit boundary:
• Decision: edit-in-place | extract helper | add owner file | split task | pause for plan update

```

If the safer boundary changes the implementation shape, pause and update the plan/spec.

If the likely repair would grow an already oversized maintained artifact and the slice cannot govern that growth immediately, do not present the repair as a completed fix boundary. Escalate with a plan update or a visible follow-up requirement.

Phase 2: Pattern Analysis

1. Find working examples in the same codebase — what works that's similar?
2. Compare against references — read completely, don't skim
3. Identify differences between working and broken — list every difference
4. Understand dependencies — config, environment, assumptions
5. Locate the canonical owner — which file/module should own this? Multiple owners = a finding, not normality

Phase 3: Hypothesis and Testing

1. Form single hypothesis: "I think X is the root cause because Y" — be specific
2. Test minimally: smallest possible change, one variable at a time. Prefer instrumentation over code edits while still proving the cause.
3. Verify: worked? → Phase 4. Didn't? → Form NEW hypothesis. Don't stack fixes.
4. When you don't know: say "I don't understand X", don't pretend
5. Run Reflection at the end of each loop:

• Goal | DeeperCause (yes/no/uncertain) | Evidence | Risk/Unknown | Decision (exit/iterate/escalate)
• If DeeperCause = uncertain → continue or escalate. Only exit when root cause is deep enough and evidence is sufficient.

Phase 3.5: Pre-Claim Gate

Before claiming a root cause and entering Phase 4, check whether the Pre-Claim Gate applies. It applies whenever any Patch-Shape Triage signal is active (candidate fix is a guard, fallback, consumer/caller patch, artifact/cache patch, or sample-only naming — i.e. H1 / H3 / H8 / H10 / H11 / H13), or whenever the diagnosis crosses a component or system boundary, or a previous fix left a residual symptom.

When it applies, do not state a root cause or edit code until the five mechanical checks below pass. See root-cause-claim-contract.md for the full rationale, the six-topology table, and a worked example.

1. Causal Closure — every causal edge from symptom to claimed root has an

evidence anchor (file:line, test, log, reproduction). One "probably" edge leaves the chain open.

1. Falsifier Checked — state "if X were not the root cause, observable F

would appear," and confirm F was checked and absent.

1. Adversarial Self-Refutation — generate the strongest single argument

that this root cause is wrong, and show why it does not hold.

1. Causal Topology Gate — classify the topology explicitly; do not default

to single-root. Topology and the anti-disguise check are in Phase 4 Step 4bis and in root-cause-claim-contract.md.

1. Layer Ceiling Proof — if the claim stops at L?, show why L?+1 is

unreachable by concrete constraint, not by omission.

Required output before entering Phase 4 when the gate fires:

Pre-Claim Gate Pass:
Topology: single-root | single-root-multi-symptom | chain | independent-compound | conjunctive-cluster | disjunctive-or
CausalClosure: closed | open-edge: 
Falsifier: 
SelfRefutation:  -> 
LayerCeiling:  -> 
Verdict: pass | fail-

This gate is advisory method-pack discipline. It is not a GateDecision, PolicySnapshot, evidence sufficiency authority, or completion authority. It turns a self-judged stop ("I think this is deep enough") into a checkable, falsifiable claim ("here is the evidence chain, the falsifier I checked, the objection I survived, and the ceiling I reached"). The quick bug lane is exempt when no Patch-Shape signal fires and the bug is single-owner at the canonical owner.

Phase 4: Implementation

Fix the root cause, not the symptom:

1. Create Failing Test Case

• Simplest possible reproduction. One-off test script if no framework.
• MUST have before fixing.

1. Implement Single Fix

• Address the root cause identified. ONE change at a time.
• No "while I'm here" improvements. No bundled refactoring.
• Prefer changing the canonical owner instead of stacking more logic into a fallback path.
• If Change Necessity, Patch-Shape Triage, Ripple Signal Triage, or

Pre-Edit Complexity Check fired, carry its owner, downstream, contract, source-of-truth, fallback, retirement, edit-boundary, minimum-boundary, and verification findings into the fix boundary before editing code.

1. Verify Fix

• Test passes now? No other tests broken? Issue actually resolved?
• Verify the intended compatibility boundary still holds.
• Verify you did not silently move authority to the wrong layer.

1. If Fix Doesn't Work

• STOP. Count: How many fixes have you tried?
• If init --root

python new-work --root ... python add-evidence --root --work ... python check --root ```

Fast bug fix or quick bug fix pressure does not skip this: if Ripple Signal Triage fires, do the triage before editing and expand verification to the canonical owner plus affected downstream path.

These records are method-pack evidence trails only. They do not grant authoritative completion.

1. Stop-when review — re-read the diagnostic layer where you stopped. Did you reach "no deeper why remains" or a T-class terminal boundary? If the chain ended at L1-L2 and the evidence is conclusive, that is a valid endpoint. If there are still unexplained "why" questions, continue upward drilling before claiming done.

• Use a Layer Stop Card when the stop point affects the fix boundary,

contract owner, spec/product decision, or user correction path. Keep simple fast-path explanations cheap; do not emit the card for ordinary factual Q&A about the skill itself.

1. Hard signal check — apply these countable facts, not judgments:

Must continue upward drilling (H-class — ANY hit = NOT done):

• H1 — fix added a conditional branch (if / switch / catch / try)
• H2 — fix touched multiple sites but only 1 covered by failing test
• H3 — fix is at consumer/caller, not canonical owner
• H4 — same bug pattern exists elsewhere in repo (grep for it)
• H5 — original reproduction still produces any anomaly
• H6 — git log --grep shows this symptom was "fixed" before → Read that commit's diff. Understand why it failed. Do not repeat the same patch pattern.
• H7 — candidate fix adds keyword, phrase, regex, negation-word list, or sample-text exception
• H8 — candidate fix adds a local guard, one-off branch, early return, fallback, adapter, compatibility branch, prompt branch, or legacy path exp

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: GanyuanRan
• Source: GanyuanRan/Aegis
• License: MIT

Install and usage instructions live in the source repository linked above.