Targeted Debugger

Who the node is. The id is the key the DOT pins.

id

targeted-debugger

name

Targeted Debugger

type

agent

phases

Debugging

What it does, and the prose the agent is handed when the graph runs.

action25 words

Turn one run's failure evidence into the narrowest patch that addresses it, and stop once the attempt cap is spent or the evidence stops changing.

spec127 words

You are given the evidence from a run that failed: the assertions that did not hold, the stack traces underneath them, and the expected value beside the one actually obtained. Find the smallest change to the existing source that accounts for those failures and emit it on patch a patch, not a rewrite, leaving every part of the code the evidence does not implicate exactly as it is. Do not special-case the literal values in the trace: a change that satisfies only the example in front of you has fixed nothing, and it will come straight back. Stop after three attempts, and stop earlier if two consecutive runs hand you the same evidence, that means you are circling, and another pass costs a round without buying information.in full above

model

claude-opus-5

agent

Debugger

skill

skills/targeted-debugger.md

tools

none

mcp

filesystem

params

max_retries: 2

What arrives, what leaves, which nodes it expects to hear from, and what may not.

inputs

evidence : report

outputs

patch : code

dependencies

acceptance-tester

cannot

acceptance-criteria

will_not

special-case the literal values in a trace

The keys the static analysis reads. Nothing here instructs the agent.

risk_markers

none

notes180 words

max_retries: 2 is the declared cap for the tester -> debugger -> tester cycle: two attempts beyond the first, three patches in all, which is the "stop after three attempts" the spec above hands the agent. Engine spec §2.6 counts the attempts that follow the initial execution rather than the executions themselves, so the cap that reads as three is written as two, and the key is spelled the way Attractor spells it. It is load-bearing twice over. Drop it and doc 3 §4.1 charges the blueprint 1.5 for an unbounded loop. It also bounds a slower leak doc 2 §5.5 names: every iteration reveals another slice of the acceptance surface through the failure messages, so the cap limits how much of the criteria this node can reconstruct by accumulation. acceptance-criteria in cannot closes the fast version of the same leak. Doc 2 §5.5 hands this node the evidence of a failure and withholds the criteria themselves, and because that entry names a data type in the ontology the resolver enforces it: an edge carrying the criteria in raises bundle/prohibition-violated.

The card's own version, and who wrote it.

version

1.1.0

author

autogen

provenance

not stated