MAX_INTERPRETATION_DEPTH exhaustion is silent and does not fall back, so F-Depth's second half is unmet for one of the three bounds

[lex00]

What

Found while landing #2367 (PR #2369), and deliberately left out of it.

#2367 documented the three fold depth bounds and asked that each exhaustion produce a [fold:run] fallback with a message naming the bound. Two of the three already did: MAX_FUNCTION_CALL_DEPTH (32, packages/core/src/fold/fold.ts:524) says "call depth exceeded — is it recursive?", and MAX_RESOLUTION_DEPTH (200, packages/core/src/discovery/fold-import.ts:3301) says "cross-file resolution depth exceeded 200 … almost certainly a resolution bug".

MAX_INTERPRETATION_DEPTH (16, packages/core/src/discovery/fold-import.ts:1773) does neither. On exhaustion, resolveInterpretableFactory returns undefined, which its documented contract defines as "not interpretable, never broken". The caller treats that as "invoke rather than interpret", and the file still folds. So exhausting this bound does not fall back to run, does not name the bound, and leaves no trace — it silently changes how the factory is evaluated while reporting the file as folded.

Why it is a spec gap and not a style choice

The specification's F-Depth (INTENTIUS/typescript-as-data spec/judgments.md, J4) has two halves: an implementation must state its bounds, and on exhaustion must fall back rather than fail. #2369 satisfies the first for all three. For this bound the second is unmet in a specific way: it neither falls back nor fails — it degrades. A reviewer cross-checking against the reference implementation will find chant reports "folded" for a file the reference reports "fell back at depth 16", and nothing in chant's output explains the difference.

Why #2369 did not change it

Three reasons, all recorded there: resolveInterpretableFactory's "undefined means not interpretable, never broken" contract is documented and relied on; the depth path has no test coverage, so a behavioural change would land blind; and forcing a throw there is a real change to the fold verdict for any project with a 16-deep composite chain, which none of the corpus has, so the differential would not catch a regression. Documenting the asymmetry was the honest move for a docs PR.

Do

Decide which of two things resolveInterpretableFactory should do at depth 16, and make it do that loudly:

• Fall back, matching the other two bounds: return a [fold:run] reason naming MAX_INTERPRETATION_DEPTH, so the file goes to run and the operator sees why. This is what F-Depth asks for and what the other two already do.
• Keep degrading to invocation, but say so: a [fold:degraded]-class diagnostic naming the bound, so the fold verdict is still "folded" but the trace records that interpretation was cut off. This preserves today's behaviour and makes it visible.

Either way: a test that builds a 17-deep composite chain and asserts the outcome by name (red today — there is nothing to assert on), and a fold-adversarial corpus entry for it so the differential covers the shape (#2347 is adding that corpus).

Update the section #2369 added to concepts/typescript-as-data.mdx to match whichever is chosen; the depth-bound guard (scripts/fold-depth-bound-claims.test.ts) pins the values, not the behaviour, so it will not catch a prose claim going stale on this.

Refs #2367, #2369, #2347, INTENTIUS/typescript-as-data#46 (F-Depth).

[lex00]

From the spec side. F-Depth (J4) is amended to record this: the rule stands as "fall back, not fail and not degrade", and chant is named as meeting it for two bounds and not MAX_INTERPRETATION_DEPTH. Inventory row L7.8 says the same.

On the two options: the spec prefers fall back. J2's verdict is two-valued, fold or run. A fold(degraded) would be a third verdict, and everything downstream that reads the verdict, including the taint fixpoint, would have to learn it. Falling back keeps the judgment as it is and matches the other two bounds. If chant chooses to degrade-and-say-so instead, the spec would need a new rule for the diagnostic and a statement that a degraded fold still meets the objective, which is a claim the differential would then have to cover.

The reference implementation does not interpret at all yet (#22, parked), so it cannot disagree with chant on this until it does. The disagreement is on record in the spec text rather than in a failing cross-check for now.

[lex00]

Decision: fall back, matching the other two bounds. Not degrade-and-announce.

Why

Three reasons, in the order they weigh.

F-Depth asks for it, and two of three bounds already do it. An implementation whose three stated bounds behave two different ways on exhaustion is the thing a normative spec exists to prevent. MAX_FUNCTION_CALL_DEPTH and MAX_RESOLUTION_DEPTH both fall back and name themselves; this one should be unremarkable rather than a third case a reader has to learn.

Degrading silently is the failure shape we just spent #2349 removing. That bug was "[object Object]" produced identically by fold and by run, so the differential saw agreement and said nothing — a wrong answer hidden by consistency. This is the same shape one level up: chant reports a file as folded when the factory was invoked rather than interpreted, and nothing in the output distinguishes the two. A reviewer cross-checking against the reference gets "folded" here and "fell back at depth 16" there, with no way to tell which of those is the bug. Both #2349 and this one are cases where reporting success while having done something else is worse than failing.

The cost is smaller than it looks. Changing the fold verdict for a project with a 16-deep composite chain sounds serious until you read the bound's own comment: "real composite nesting is 2-3 deep, and a chain past this is a bug, not a design." If a project has one, "we fell back to run, and here is the bound that sent us there" is a better outcome than quietly invoking their factory. The corpus has nothing that deep, which is exactly why this needs the test and the adversarial entry rather than the differential.

What has to change beyond the one line

resolveInterpretableFactory returns undefined at fold-import.ts:1972, and its contract defines undefined as "not interpretable, never broken". That contract is fine and should stay — the problem is that the depth case is being squeezed into it. Those are two different facts:

• not interpretable — this factory's shape is outside the subset. Invoking it is correct and the file still folds.
• gave up — the factory might well be interpretable and we stopped looking. Invoking it is a different evaluation than the one being reported.

So the depth case needs its own return, carrying a reason that reaches the [fold:run] path naming MAX_INTERPRETATION_DEPTH, rather than being flattened into the "not interpretable" answer. The one-line guard becomes a distinguishable outcome; the existing contract keeps its meaning for every other caller.

Tests, as the issue asks

A 17-deep composite chain asserting the fallback by name, red today because there is nothing to assert on. A fold-adversarial corpus entry for the shape, so the differential covers it going forward (#2347's corpus is the home). And the prose section #2369 added to concepts/typescript-as-data.mdx updated to say all three bounds fall back, since scripts/fold-depth-bound-claims.test.ts pins the values and not the behaviour and will not catch that claim going stale.

Ordering

This is independent of #2349 and of the behaviour work; it can land whenever. It does want to land before the next cross-check against the reference implementation, since the mismatch it produces is exactly the kind a reviewer would otherwise file against chant.