Bound a live link closure by the resources it assembles

[habdelra]

loadLinks walks a card's relationships breadth-first to assemble included[]. That walk is now bounded by how many resources it assembles, as SERVER_MAX_ASSEMBLED_LINK_RESOURCES in search-bounds.ts alongside the other server-side bounds. maxLinkDepth is deleted.

A hop count is the wrong unit for the job. It cannot say "this is getting expensive", because expense is resources and distance is not: a card carrying dozens of relationships is dozens of resources one hop out, and hundreds two hops out, under any depth limit. Nor was it what made the walk finite — the walk terminates on its own once every reachable resource has been visited. So what needs bounding is the width it brings back.

How the budget is spent

The budget is charged at classification time — when a relationship's target URL is resolved, before that URL joins the layer's batched read. So a graph that outgrows the ceiling is neither read nor assembled, rather than being read in full and then trimmed. That matters because the cost this bound stands in for is event-loop CPU: cloning, rewriting and serializing each resource, plus the reads that fetch them.

A target reached down several paths is charged once. The roots, the caller's omit list, and anything already in included are seeded as already-decided, so a relationship pointing back at a resource the response was always going to carry costs nothing — and still gets its data rewritten.

When the budget runs out, the relationship is left exactly as the index stored it: links.self names the target and no data claims it is carried. That is the shape a consumer already reads as "not loaded" and resolves for itself, one card at a time, for the links a template displays.

Polarity: exemption, not opt-in

Every other bound in search-bounds.ts is applied by the handler that knows it is serving live traffic. This one is inverted — every assembly is held to it unless a caller passes skipLinkAssemblyBudget.

A closure is assembled by more routes than search (the card+json read, the card+html item leg, and the write read-backs), and a bound that has to be remembered per route is a bound that a route added later forgets. Expressing the exemption instead means the failure direction is "something is bounded that could have been unbounded".

The exemption is set on the realm-server's own during-prerender traffic, for the same reason the prerendered-HTML leg is exempt from the page and time bounds: what a render assembles is baked into HTML that is cached and served long after the request that produced it, and the cached copy carries no way to say it was short.

A render's search needs no exemption, because it sets omitIncluded and the pass the budget bounds does not run there at all. The leg that carries the live exemption is the card+html entry GET, which is the one a render uses to fetch an item and which does run the pass. The card+json read takes the exemption too, but defensively rather than load-bearingly: no caller attaches the during-prerender marker to a card+json request today, so that branch is correct if the marker ever arrives rather than something a render relies on now.

The shortfall is visible

A response that carried less than its whole closure says so, as meta.linkClosureTruncated — on the card+json document, on the card+html entry document, and on the search collection's meta, next to the incomplete flag that does the same job for a short row count. A federated search ORs it across the realms that answered.

The ceiling that applied is deliberately not on the wire. It is an operator's number, recorded in the realm-server log when an assembly trips it, and a consumer acts on the fact rather than on the figure — which also means there is no per-server number to reconcile when several realms answer one search.

Caching

The budget is one number for the process, so it does not fragment any cache: every response at a given build and setting shares it, and whether a given card truncates is deterministic.

What enters both validators is whether the budget applied: :lb-off for an assembly that was exempt, :lb<n> for one that was bounded. Both halves earn their place. An exempt response and a bounded one are two different bodies for the same card at the same generations, so sharing a validator would let a conditional request be answered with the other's body — and since the exempt shape is a render's, a clipped closure reused by one would be baked into cached HTML. Naming the exemption rather than the number also leaves an exempt response's validator untouched by a retune, which cannot change its body.

buildCardJsonEtag carries it as part of the variant the constant CARD_JSON_ETAG_VARIANT already exists for; buildEntryHtmlEtag has no such constant, so it carries the component directly. Both fold it in only on a shape that actually assembles a closure — a links-only read and a pure-html response keep the validators they had. The card+json and card+html endpoint suites pin the validator by regex, so their patterns move with it.

Sizing

SERVER_MAX_ASSEMBLED_LINK_RESOURCES defaults to 1,000 and is env-overridable like its neighbours. It is a safety ceiling, not a tuning knob: measured against realms in use, the widest single card's closure runs to the low hundreds of resources, and a hundred-row page of the most connected type unions to about the same — so the default sits several times above healthy traffic. It also lands near the point where one assembly would hold the tens of MB of heap that SERVER_MAX_IN_FLIGHT_SEARCHES assumes per in-flight search.

It is not expected to engage. It exists so that no single card graph — authored by a person or by a model, and re-editable at any time — can make one request assemble an unbounded document.

Testing

packages/realm-server/tests/link-assembly-budget-test.ts drives a fan fixture (one consumer → N targets → one child each) through the test seam on the bounds module:

• a closure that fits arrives whole and the document claims nothing
• a closure past the budget is clipped to exactly the budget, the document reports it, and the clip lands mid-walk rather than rounding to a layer
• a clipped link still names its target
• the budget bounds what is read, asserted on the bind list of the batched i.url IN (...) lookup — the response body cannot tell a walk that read the whole graph and returned part of it from one that read only what it returned
• a card reached by two roots spends one slot
• a query-backed field clipped part-way through stays coherent — its umbrella still names every match and every member still names its target, so the consumer fetches what it is missing rather than reading the field as short
• the search and card+html item legs are bounded and report it on the document
• a during-prerender read carries the whole closure at the same budget
• retuning the budget rotates the validator, and a validator minted under the first is not honoured
• a bounded read and an exempt one never share a validator, and the bounded one's validator does not satisfy an exempt request
• retuning the budget leaves an exempt validator alone
• an opts object that says nothing about the budget is still bounded

The read-bound test carries a positive control: the same probe at a budget that fits must see all 16 resources, or its low count under a budget of 2 would be equally consistent with a counter that never matched a query.

The query-backed test pins the wire shape both ways: every member carries the data its query answered, clipped or not, while included[] holds only some of them — so a clipped member names a resource the document does not carry, which is exactly what a consumer reads as not-loaded and fetches for itself.

load-links-batching-test.ts (6) and live-link-closure-test.ts (6) are unchanged and pass — the latter is the control that catches a route dropping its closure for an unrelated reason. Verified together with the two endpoint suites whose validator patterns moved: 135 pass, 0 fail.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-17T07:10:48.654786Z	345cae6	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f575721b94

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Distinguish budget-exempt responses in validators

When a card exceeds the link budget, its normal live response is truncated while an x-boxel-during-prerender response is explicitly exempt, but both receive this same ETag because the variant includes only the numeric budget. In getCard, an If-None-Match match returns 304 before assembly, so a prerender request that revalidates a previously cached truncated live response can reuse that short document and bake it into cached HTML. The budget-exempt shape needs a distinct validator component (and buildEntryHtmlEtag has the same representation split).

Useful? React with 👍 / 👎.

[habdelra]

[Claude Code 🤖] Confirming the representation split, with one correction to the reachability and one consequence the bot could not see.

The split is real on both validators — see my thread on buildEntryHtmlEtag, which asks for the exemption rather than the number to be folded in (:lb-off / :lb<n>), fixing the collision and the needless rotation of exempt responses in one move.

The 304 path named here is not reachable on card+json today, for a reason that is itself a finding: nothing sends x-boxel-during-prerender on a card+json read. The header is attached only by duringPrerenderHeaders() (on _federated-search and on fetchCardEntry) and headlessCommandWriteHeaders() (on a card write); CardService#fetchJSON attaches neither, and loadCardDocument fetches card+source. So no prerender request revalidates a card+json ETag — and, for the same reason, a render's card+json reads are bounded rather than exempt. See my thread on #cardJsonLinkShape.

The two interlock: wiring the marker onto the card+json read makes this 304 scenario live. Both want fixing, and the validator one should land first or alongside.

[habdelra]

[Claude Code 🤖] Confirmed and fixed in f484dec. The split was real: buildCardJsonEtag took only resolveLinksOnly, so a bounded response and an exempt one minted the same validator while the budget could make their bodies differ.

The fix folds in whether the budget applied rather than its value — :lb-off when the assembly was exempt, :lb<n> otherwise — which closes the collision and also stops a retune rotating the validator of every exempt response, whose body the ceiling cannot change. Both validators carry it, and only on shapes that assemble a closure, so a links-only read and a pure-html response keep the validators they had.

Two corrections to the reachability, which do not change the fix. The 304 path you name is not live on card+json today: nothing sends x-boxel-during-prerender on a card+json read (the marker is attached only to _federated-search and to the card+html entry GET), so no prerender request revalidates a card+json ETag, and that route's reads are bounded rather than exempt. The collision is live on the card+html entry route instead, which does receive the marker — so the consequence you describe is real, just on the other route.

buildEntryHtmlEtag is fixed the same way, as you suggested. Tests added for both directions: a bounded and an exempt read of one card do not share a validator and the bounded one does not satisfy an exempt request, and an exempt validator is unchanged across a retune.

[habdelra]

[Claude Code 🤖] This review went after the budget's arithmetic (can included[] exceed the ceiling; can a resource be charged twice or not at all), the exemption's reachability on every route that assembles a closure, the wire shape a clipped relationship leaves behind and how the host deserializer reads it, and whether the two validators separate exactly the bodies the budget can change. It also read the diff's new prose against the evergreen and privacy rules. It did not re-run the suite.

Bottom line: the mechanism is sound — the charge is placed correctly, included[] cannot exceed the ceiling, and a clipped relationship degrades to a lazy per-URL fetch rather than an error — but the exemption is wired to a signal that does not reach two of the three routes it is set on, and both validators encode the budget's value rather than whether it applied. No blocking issues; the two exemption comments should not ship asserting guarantees their routes cannot deliver.

On the questions in the description — the four that came back clean, so the inline threads are the whole of what needs action:

1. included.length <= budget holds. Every push in step 5 traces back to an entry classified in step 2. Entries sharing a target share one charge through decided; entries with different target URLs that converge on one row are separated by visited, which suppresses the second push. The seeded ids (roots, omit, included) are the only uncharged entries, and step 5 filters all three back out — roots additionally via the visited seeding at the top.
2. Charging is at worst generous, never short. allIdForms expands a seed into its resolved / RRI / virtual-alias spellings and step 2 keys on the resolved one, so the seeds match. Two spellings of one row that both resolve — a url and a file_alias hit of the same instance — spend two slots and yield one resource, the harmless direction. The one real mismatch is charging-before-reading; see the comment on the bookkeeping block.
3. The truncated wire shape is safe. resourceFrom missing yields { type: 'not-loaded', reference } on both the singular and plural paths, which the field getter turns into lazilyLoadLink — a clipped relationship is read exactly like a never-loaded one, for static links, file-meta links and cross-realm links alike. Query-backed members are the one shape whose data survives the clip; see that thread.
4. Deterministic for a static graph. Entry order follows relationship key order, nextLayer follows entry order, and walkAndPopulateQueryFields applies query fields sequentially rather than concurrently. A query-backed field's member order is the query's, which can move with no card-side invalidation — but that already moves the body under a fixed validator, so the clip inherits the exposure rather than creating it.
5. The default and its handling are defensible. The bound follows the file's conventions exactly: DEFAULT_/MIN_ pair, parsePositiveInt with the same fallback-is-also-clamped behaviour, the test seam, an exported const plus an effective let. Reading it through an accessor rather than importing the let is right for a cross-module consumer.

Recommendations, in the order I would take them:

1. Decide what sends the marker on a card+json read, or stop claiming the exemption there — thread on #cardJsonLinkShape in realm.ts.
2. Drop or re-caption the two search-leg exemptions that omitIncluded already makes unreachable — thread on handle-search.ts.
3. Put the exemption, not the budget's value, into both validators — thread on buildEntryHtmlEtag in realm.ts.
4. Correct the truncated-relationship comment for query-backed members — thread on the budget-spend block in realm-index-query-engine.ts.
5. Say whether linkClosureTruncated has a reader coming — thread on DocumentClosureMeta.
6. Reconcile "assembled" with what committed counts — thread on the bookkeeping block.

Adjacent, out of scope. The client-side memberValidator that the live-search selective refresh sends as If-None-Match builds a two-segment index:html string, while an item-bearing server ETag also carries the realm-info hash (and now the budget). Those cannot match, so item-bearing conditional entry GETs always 200 today and the selective refresh never gets its 304. Not this PR's to fix — but worth knowing before anyone reasons about the entry route's 304 path, including for recommendation 3.

[habdelra]

[Claude Code 🤖] This flag never reaches a link assembly. omitIncluded is set from cacheOnlyDefinitions three lines above, and assembleSearchEntryDoc gates its only loadLinks call on !opts?.omitIncluded — so on every request where this is true, the pass it exempts is not run at all. Realm#searchEntriesResponse has the same pair (omitIncluded: duringPrerender sitting next to skipLinkAssemblyBudget: duringPrerender).

What makes a render's search safe is omitIncluded skipping the pass; the comment credits the flag instead, so the next reader will take the flag for the mechanism. Either drop it from both search call sites, or keep it and say it is standing by against omitIncluded narrowing.

The searchEntry call in #entryHtmlResponse is the one that matters — it sets no omitIncluded, so its exemption is load-bearing and should stay.

Regression (flag added here), non-blocking.

[habdelra]

[Claude Code 🤖] You are right, and it was dead on both search call sites — omitIncluded is what keeps a render's search out of the pass, so the flag exempted something that never ran. Removed from both in f484dec, along with its SearchOpts member, and the note about why a render's search is safe now sits on omitIncluded where the reader will look. The searchEntry call in #entryHtmlResponse keeps its exemption, since that one runs the pass.

[habdelra]

[Claude Code 🤖] Which caller sends x-boxel-during-prerender on a card+json read?

Repo-wide, the header is attached in exactly two helpers: duringPrerenderHeaders(), used on the _federated-search fetch and on fetchCardEntry (the card+html / file-meta+html entry GET) in StoreService, and headlessCommandWriteHeaders(), used on a card POST/PATCH. CardService#fetchJSON — the one place the host sets Accept: card+json — attaches neither, and loadCardDocument fetches card+source rather than card+json. So isDuringPrerenderRequest is false for every host-issued card+json read, render or not, and the guarantee this comment states ("exempts a render's own") is one the route cannot deliver: a render's card+json reads are bounded, and whatever they clip is what the cached HTML gets built from.

If I have missed the caller, naming it here settles it. If not, the wiring belongs on the client side and the comment should not assert the exemption until it exists — it is the same gap that already leaves skipQueryBackedExpansion inert on this route, which is why it is worth stating rather than inheriting. The suite's during-prerender test sets the header by hand, so it pins the branch, not the wiring.

Pre-existing (the signal never arrives here), now load-bearing (this PR rests a correctness argument on it). Non-blocking on the code; the comment is the part to change.

[habdelra]

[Claude Code 🤖] You have not missed a caller — I checked the same way and reached the same two: duringPrerenderHeaders() on _federated-search and on fetchCardEntry, and headlessCommandWriteHeaders() on a write. Nothing sets it on a card+json read.

The comment overclaimed and is corrected in f484dec. What protects a render is the card+html entry leg, which does receive the marker and does run the assembly pass; the card+json branch is defensive rather than load-bearing, and the comment now says that instead of asserting a guarantee the route cannot deliver. I have left the wiring in place so the branch is correct if the marker ever arrives, rather than deleting it and having the exemption silently absent when it does.

[backspace]

[Claude Code 🤖] This one did not land: #cardJsonLinkShape's comment is byte-identical between the commit the review read and the branch head, so the correction described here is not in the tree.

The merge then made it wrong a second way. The comment says the exemption "needs no separate slot in the validator", and the commit that answered the validator thread gave it exactly that slot — -lb-off.

I have rewritten it on the branch to say what you say here: the branch is defensive rather than load-bearing, no caller attaches the marker to a card+json request, the exemption a render relies on is the card+html entry leg's, and the validator names the exemption rather than the ceiling. The wiring is untouched, so the branch is still correct if the marker ever arrives.

[habdelra]

[Claude Code 🤖] The validator carries the budget's value but not whether the budget applied, and both directions of that miss:

• An exempt item response (#entryHtmlResponse passes skipLinkAssemblyBudget: true during prerender) and a bounded live one for the same card at the same generations mint the identical validator, because resolveLinksOnly is false on both whenever liveReadsResolveLinksOnly is off — the default. Two bodies, one validator, and those two bodies differing is the entire premise of the exemption.
• A retune rotates the validator of every exempt response, whose body the budget cannot change.

Folding in the exemption instead of the number fixes both — :lb-off when the assembly was exempt, :lb<n> otherwise. cardJsonEtagVariant has the same shape and the same two cases.

The collision is latent rather than live today: the client-side memberValidator that feeds If-None-Match on the entry route is a two-segment index:html string that cannot match an item-bearing server ETag at all (see the review body). That makes this cheap to fix now and unpleasant to discover later.

Regression, non-blocking.

[habdelra]

[Claude Code 🤖] Fixed in f484dec, with your spelling: :lb-off when the assembly was exempt, :lb<n> otherwise, on both validators. That closes the collision and stops a retune rotating validators whose bodies cannot move.

Two things fell out of doing it. The exempt variant deliberately omits the number, so an exempt response keeps its validator across a retune — which is the half that makes the change worth more than a collision fix. And #patchedCardResponse turned out to need the flag threaded as a parameter rather than derived locally: its two callers differ (readEntry(duringPrerender) on the unchanged path, readEntry(false) on the other), so a single derived value would have been wrong for one of them.

[habdelra]

[Claude Code 🤖] "no data claims it is carried" holds for a stored relationship — LinkTargetInstance documents pristine_doc as carrying relative links.self and no data — but not for a query-backed field. applyQueryResults runs in step 1, before this, and rewrites every ${fieldName}.${index} as { links: { self: card.id }, data: { type, id } }. A member clipped here therefore goes out with a data naming a resource absent from included[], which is the shape step 1b's comment a few hundred lines up calls out as a hazard.

It is not one: both LinksTo.deserialize and LinksToMany.deserialize fall through to { type: 'not-loaded', reference } when resourceFrom misses, and the getter turns that into lazilyLoadLink. So the behaviour is right and only the justification is wrong — but the new query-backed test asserts links.self and nothing about data, so nothing in the tree currently distinguishes the two readings. Please say here what actually holds for both kinds of relationship, since step 1b's comment reads the opposite way.

Regression (comment), non-blocking.

[habdelra]

[Claude Code 🤖] Correct, and the comment is fixed in f484dec — it now states both kinds: a stored link goes out with links.self and no data, a query-backed member with both, because step 1 has already answered it. So a clipped query-backed member does ship data naming a resource included[] does not hold.

The behaviour was already right for the reason you name, and the test now pins it rather than leaving it to read either way: it asserts every member carries data, that included[] holds only some of them, and that nothing is carried twice — so the two readings are no longer both consistent with a green suite.

[habdelra]

[Claude Code 🤖] committed counts link URLs classified, not resources assembled. The charge lands before the batched read, so a link whose row is missing or errored, and a cross-realm fetch that fails, each spend a slot and contribute nothing to included[]. A card with a long tail of broken links — diagnostics.brokenLinks exists because that is a real, observed condition — can report linkClosureTruncated with included[] sitting well under the ceiling.

That is the safe direction for cost, and charging early is what lets the bound also bound the reads. But SERVER_MAX_ASSEMBLED_LINK_RESOURCES and its doc comment ("the most resources one loadLinks assembly may side-load into included[]") both name the other quantity. Is "scheduled" the intent, and if so should the name or the comment say it?

Non-blocking; a question rather than a defect.

[habdelra]

[Claude Code 🤖] Scheduled is the intent, and the comment was the thing that was wrong — fixed in f484dec. Charging at classification is what lets the ceiling bound the batched reads rather than only the assembly, which is most of its value.

The doc now says so and names the gap you identified: a link whose row is missing or errored, and a failed cross-realm fetch, each spend from the ceiling and add nothing to included[], so a card with many broken links can report its closure clipped while carrying fewer resources than the ceiling allows. I kept the constant's name — what it bounds is work undertaken, which is the quantity that costs — and made the comment describe that instead of included[].

[habdelra]

[Claude Code 🤖] Nothing reads linkClosureTruncated. The only references in the tree are the three writers, the federated merge, and the new tests — no host resource, store path, or component branches on it. "A consumer acts on the fact rather than on the figure" is therefore a claim about a consumer that does not exist yet.

Which one is it for, and when? If the answer is "none yet", say so here: this is a wire field on three public document shapes, and the operator-facing half of the job is already done by the warn line in loadLinks.

Non-blocking; a question.

[habdelra]

[Claude Code 🤖] None yet, and the comment now says so in f484dec rather than implying one exists.

It is here because a truncated response is otherwise indistinguishable from a small graph, which is the property the work was asked to provide — but you are right that nothing needs it to behave correctly: a clipped link is self-describing to the client, which deserializes it to a not-loaded value and fetches the card when a template reads the field. So it serves a caller assembling a total, or a person reading a response, and the operator-facing half is indeed already done by the warn line. I would rather ship it stated honestly than drop it and have the shortfall be invisible on the wire.

[github-actions]

Host Test Results

    1 files      1 suites   2h 30m 33s ⏱️
4 865 tests 4 851 ✅ 14 💤 0 ❌
4 880 runs  4 866 ✅ 14 💤 0 ❌

Results for commit 51f137f.

Realm Server Test Results

    1 files    240 suites   1h 21m 3s ⏱️
3 475 tests 3 475 ✅ 0 💤 0 ❌
3 523 runs  3 523 ✅ 0 💤 0 ❌

Results for commit 51f137f.

[habdelra]

@codex review

[Claude Code 🤖] Re-requesting because the previous pass was against f575721, and the head is now 345cae6 — which is where the finding from that pass was fixed. The validator split it identified is addressed by folding in whether the budget applied rather than its value (:lb-off / :lb<n>), across both buildCardJsonEtag and buildEntryHtmlEtag, plus the #patchedCardResponse path whose two callers differ in exemption state. Worth a look at that specifically, along with the search-leg exemptions removed as dead code and the three endpoint ETag assertions that moved with the variant.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 345cae6974

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[backspace]

[Claude Code 🤖] This pass went after convergence: whether the code now on the branch closes each thread from the first review, and whether the two merges with main keep the budget's guarantees. It re-verified the two claims those threads turn on — what a clipped relationship does in the host deserializer, and whether the two validators separate exactly the bodies the budget can change. It did not run the realm-server suites locally.

Bottom line: no blocking issues, and I have merged main and resolved the conflicts on the branch. Six of the seven threads are closed by the code. The seventh — the exemption comment on #cardJsonLinkShape — was answered as fixed, but that comment did not change; the merge then made it wrong a second way, so I corrected it here. Approving.

What I pushed to the branch

Two merge commits. Neither changes what the budget does.

1. Main moved the card+json validator from a resolveLinksOnly boolean to a CardJsonShape union, and made the write read-backs stop assembling a closure. buildCardJsonEtag keeps shape for links-only and write-echo, and splits full again on whether the budget applied. The budget flags on the write read-backs went with the closure they bounded.
2. Main then made a live read's link shape come from prevailing load. #cardJsonLinkShape reads resolveLinksOnly from that policy; the during-prerender marker still decides the budget exemption, so it keeps a local of its own.
3. Three comments described the code before the merge and not after:
   • the query engine said the write read-backs also report a clipped closure;
   • the shape union said a render's card+json body shares full's validator, which the exempt variant now separates;
   • #cardJsonLinkShape said the exemption needs no slot in the validator. The commit that added -lb-off made that false. It now says what your own reply to that thread says: the branch is defensive, because no caller marks a card+json request as during-prerender.
4. Two card+json ETag assertions in the endpoint suite matched a variant with no budget component — a GET after a write, and a no-op PATCH derived from a GET's validator. Both now match the budget the full shape carries.

Thread dispositions

1. Search exemption flag — resolved. The flag and its SearchOpts member are gone from both search call sites, and the reason a render's search is safe now sits on omitIncluded.
2. #cardJsonLinkShape comment — not resolved by the reply; fixed on the branch. See the reply in that thread.
3. Validators encode the value, not whether it applied — resolved on both validators, with tests for the collision, for the conditional request, and for the retune.
4. Query-backed clip — resolved, and the behaviour holds for a reason stronger than the comment claims. LinksTo.deserialize and LinksToMany.deserialize both return { type: 'not-loaded', reference } when resourceFrom misses, and the getters lazily load each slot. A query-backed linksToMany getter does not read the deserialized array at all — it re-runs the search client-side through ensureQueryFieldSearchResource — so a clipped member costs the client a fetch and cannot surface as an error.
5. The budget counts targets taken on, not resources landed — resolved. The constant's doc states the gap and names the broken-link case that makes the two totals differ.
6. Nothing reads linkClosureTruncated — resolved. The type says so.
7. Bot: budget-exempt responses share a validator — resolved by the same change as 3.

CI

All six realm-server shards pass on this head, which is what covers the two ETag assertions I changed and the new budget suite. Lint and the other package suites pass. The host shards and Percy were still running when I approved; this branch touches no host code.

Adjacent, out of scope

• The description still lists the write read-backs among the routes that assemble a closure. Main removed that. Worth a line before merge.
• Step 1b in loadLinks says that leaving fieldName.N entries on the wire without their targets in included[] "produces orphan-link errors". Nothing in the tree raises such an error now — both link paths degrade to not-loaded. The strip is still right for its own reason, but that justification is stale. Not this PR's to fix.

[backspace]

[Claude Code 🤖] The one red check on this head, Host Memory Baseline, is not this branch's.

It fails on Acceptance | Spec preview at +165.5 MB against a 0.0 MB baseline. Main fails the same job, on the same module, at the same figure — including the main commit this branch merged (c47715a0) and the one before it. This branch changes no host code.

The second row it reports, Acceptance | interact submode | create-file tests at 60.1 → 205.2 MB, carries a byte-identical figure on an unrelated branch whose own base main run did not report it. Two different changes cannot produce the same measurement to 0.1 MB, so that row reads as the baseline being stale against a layout difference rather than as either branch being heavy.

Safe to merge past here. Main is what needs the baseline refreshed, or the Spec preview regression found — it went red there around the time the link-shape work landed and has stayed red since.