callidescope-triage

Acting on a callidescope failure

Callidescope fails for a handful of distinct reasons, and reading which one occurred is most of the work. Separate them first:

The run said	It is
🚨 [DEPTH n > limit]	A finding about the code. Fix the layering
A breadth row over the limit	A finding. Split the callable
A configured destination is stale	Drift. Re-run --write
🔭 Rejected the command line	A mistake in the flags. Nothing was traced
🔭 Rejected the configuration	The run cannot do what was asked. Nothing was traced

The two rejections happen before any tracing, so they never say anything about the code.

A depth gate that failed

A stack ran deeper than limits.maximumDepth. The change that made it longer is the change that fixes it — that is the whole reason depth is the gate and staleness is not.

Read the printed stack before doing anything. The frames carry each callable's signature and the one-line summary of its documentation, and those summaries are how you tell the two cases apart:

• Every frame says something different. The layering is real: each stage does its own work. Question whether all the stages are needed, but do not start deleting one layer at a time — this case usually needs a design decision, not a trim.
• A run of frames all say roughly the same thing. Those are forwarding layers that exist only to pass arguments along. Collapse them. This is the common case and it is exactly what the tool was built to surface: the tools that would otherwise tell you are the ones reading a file at a time, so they see the forwarding and never the depth.

Raising maximumDepth is not a fix. The limit describes the shape the repository wants; moving it to fit today's worst stack means the gate stops gating, and every later stack gets a free pass to that new number. If the limit is genuinely wrong for the repository, change it as its own decision, on its own, with the reasoning written down — not as the thing that unblocks a pull request.