Check the code your AI wrote against the code you run.

Transient visual feedback in one of these libraries outlives the thing it belongs to: the fading trail left behind by a presentation pointer keeps animating and drawing after the user has switched to a different page of the same document, because the component that owns those in-flight trails is one long-lived manager that never recorded which page each trail was started on, and nothing tears them down when the active page changes. The same shape of bug is a standing contract across the folder: short-lived state - the transient status of an in-flight fetch, a pending selection, an interaction still in progress - is owned by something that outlives the scope the state actually belongs to, and has to be reset when that scope changes underneath it. Which files own scope-bound ephemeral state of this kind and would have to change?

tldraw #10509 · fix(editor): clear laser trails when the current page changes 9 files in the key

Repositories, each pinned at its own commit

Retriever

When a container's very first population fails, the failure is swallowed rather than delivered: every caller already waiting on that first settled state - a callback registered before the failure, a promise someone is awaiting - never learns the attempt failed, and the container is left facing outward as still-loading forever. Worse, once the container is explicitly marked as having failed, nothing it does afterward - not even a fully successful retry - is allowed to bring it back to a working state; the failure is a one-way door. The same two-part contract, delivered exactly once and never a dead end, is honored deliberately elsewhere in the folder: an asynchronous outcome must reach everyone who registered for the first settlement of a value, and a later successful attempt must be able to undo an earlier failure rather than being permanently blocked by it. Which files implement the one-way trap that has to be reopened, and which own the deliver-once / recoverable-afterward machinery it needs to match?

db #1751 · fix(db): propagate initial query errors 15 files in the key

Repositories, each pinned at its own commit

Retriever

A correlated per-parent computation joins its result back to the parent that asked for it using a key built only from the computed value itself - never from which parent produced it. So when two different parents' correlated computations happen to produce the same value, the join can no longer tell them apart, and a value silently attaches itself to the wrong parent's row - the correlation was real, but the key that was supposed to carry it only captured part of what made the two cases different. The same hazard is handled deliberately elsewhere in the folder: several libraries look up or normalize a piece of state using a key computed from an object, and that key has to capture every dimension that can make two logically different objects collide, not merely the dimension an equality check or a filter clause happens to reference. Which files build the join key that drops the parent's identity, and which own the key-completeness contract it has to be brought in line with?

db #1761 · fix(db): preserve correlated include route identity 9 files in the key

Repositories, each pinned at its own commit

Retriever

React tightens what a pending value that suspends rendering must look like: any awaitable consumed during render must carry a resolved status/value/reason protocol stamped on the object itself. Which async feeders across the folder produce, shim, or throw such pending values into the renderer, and which files must be updated?

4 repositories, each pinned at its own commit 9 files in the key

Repositories, each pinned at its own commit

Retriever

Removing a thing is neither final nor self-contained here. The removal path can run again on something already removed and does real work the second time instead of stopping, and the cleanup it triggers for the removed thing's stored derivatives is aimed by a name prefix rather than by identity - so it reaches every stored object whose name begins the same way, including ones belonging to entities that merely share a naming ancestor and were never meant to be touched. The two faults compound: a repeat removal re-runs a cascade that was already too wide. Elsewhere in the folder the same two obligations are met on purpose: one library routes every removal - single, batched, and clear-all - through one mutator so the terminal state is the same however you get there, another keeps a keyed family of entries where dropping one member is defined not to disturb its siblings, and another draws an explicit line between matching an entry by its exact identity and matching it by a partial leading fragment, because the second is a filter and must never be used where the first is meant. Which files make removal non-terminal and aim its cascade by prefix, and which own the terminal-and-scoped-removal contract they have to be brought in line with?

tldraw #10298 · fix(dotcom): make file hard delete terminal and scope its R2 history cleanup 7 files in the key

Repositories, each pinned at its own commit

Retriever

When part of a tree is not the part that actually got shown - it was superseded and replaced by a stand-in while it was still settling - the per-node enter and leave notifications for the superseded part still run, because the code that decides which nodes entered and which left compares only the old set against the new set. It has no notion of where the shown region stops, so nodes below that boundary are treated exactly like nodes the user is really looking at: their callbacks fire for a region that was never presented, and they fire against membership that was published without any record of which branch it belonged to, so an observer re-entering during publication sees the wrong extent. The concept that would fix this does not exist anywhere in the repository yet - there is no name to search for. Elsewhere in the folder the same hazard is handled on purpose: one library carries an explicit flag down the tree so that a subtree currently held back does not run its attach and detach work, another attaches and detaches only along the branch that is genuinely depended upon, and another funnels all observer notification through a single batching point so that membership and notification cannot interleave. Which files decide entered-and-left membership without a boundary, and which own the scoped-notification contract they have to be brought in line with?

router #8165 · fix(router-core): skip lifecycle callbacks below fallback boundaries 7 files in the key

Repositories, each pinned at its own commit

Retriever

Two different entry points reach the same privileged write. One of them checks that the caller is allowed to perform it; the other was built later, for a different transport, and never grew the same check - it validates only that the target exists and that the payload is well formed, then performs the write. So the permission that the first door enforces is not a property of the operation at all, only a property of one route to it, and any caller who knows the second door bypasses it entirely. The check the second door is missing has no shared name yet: at this revision the condition is written out inline at the door that does enforce it, so there is no single helper to look for. The same hazard is answered deliberately elsewhere in the folder, where libraries deliberately funnel every mutating entry point - however many public method names it wears - through one internal chokepoint that validates and applies the change, so that a new public method cannot accidentally acquire fewer guarantees than the old ones. Which files perform the privileged write without the check, which one holds the check that was not shared, and which own the single-chokepoint contract they have to be brought in line with?

tldraw #10300 · fix(dotcom): apply the same write gate to both asset upload paths 7 files in the key

Repositories, each pinned at its own commit

Retriever

Several of these libraries let a record be built either from nothing or out of an existing record, and the second path is where they go wrong. In one library, three producers of a derived record are each incomplete, and each is invisible until the record is derived rather than constructed. One of them, preparing a record just before it is stored, edits the sub-object it was handed instead of replacing it - harmless when that sub-object was made for the occasion, destructive when it belongs to the record being derived from, and an outright failure when that source is protected against writes. One of them, when a gradual transition between two versions of a record needs the shorter side padded out, mints the padding by copying an existing member and changing only what it thought of, so the padded members are indistinguishable to the step that later has to tell members apart, which keeps one and drops the rest. One of them rebuilds a composite in a new coordinate space out of its parts alone, so everything the composite had additionally been told about itself - how it should be treated, which of its parts to hold but disregard, what the caller asked to override - is absent from the result. A fourth producer, in a different library, reconstructs live state from a package that a different version of the same library may have written, and assumes every field the current version writes is present in it. The contract behind all four is that a derived record is a new and independent thing: it carries forward everything the original carried that the derivation does not deliberately replace, it is given its own identity wherever identity is what tells members apart, it tolerates an original written by an older or sparser producer, and it is never produced by writing into the original. Two further libraries in this folder make that discipline the centre of their core rather than an afterthought, and are the reference a complete derivation should be measured against. Which files derive a record incompletely, or by writing into its source, and which own the contract they have to be brought in line with?

tldraw #10248 · fix(lines): do not mutate the caller's points in onBeforeCreate 5 files in the key

Repositories, each pinned at its own commit

Retriever

One of these libraries resolves references to things that live outside its own data - an identifier that has to be turned into something fetchable, and remote documents that have to be pulled in before a result can be produced. Resolution has three possible outcomes, not two: it succeeded, it has not finished yet, and it failed. Throughout this library only the first two are modelled, and the third is quietly folded into one of them, in four different places and four different ways. A shared bounded store keyed by location keeps whatever the last attempt produced, including the placeholder that means "this attempt failed", and the store has no operation for forgetting an entry at all, so one bad moment on the network makes that location permanently unavailable for the rest of the session; a second surface keeps a per-object promise for the same reason and never discards the rejected one, so a retry can never happen. A third place keeps showing what the previous reference resolved to after the reference itself is changed or taken away, because it only reacts when the resolved end product differs, and the end product of "nothing" is not something it compares. A fourth treats a reference that cannot currently be resolved as a reference that does not exist: it is dropped from the material handed to the next consumer rather than carried across unresolved, and an error raised while removing one is swallowed so the caller believes the removal happened. Each of these is invisible whenever the network cooperates and whenever references are only ever added. The contract is that a failed resolution is a transient fact about one attempt, never a value to be stored in place of the thing, and that a reference whose target cannot be produced right now must be kept, retried and reported rather than substituted with absence. Elsewhere in the folder that separation is the design: one library gives a failing attempt its own object with its own lifecycle - it can be paused, resumed, cancelled and asked for its status, and its failure never becomes the stored value - and another enumerates the three outcomes explicitly as distinct states so that a failure travels alongside the data rather than replacing it. Which files store, keep or discard a failed resolution as though it were an answer, and which own the contract they have to be brought in line with?

tldraw #10338 · fix(editor): export embedding of multi-url styles, font lists, failed fetches and bare @import rules 13 files in the key

Repositories, each pinned at its own commit

Retriever

One of these libraries lets a grouping construct that has no representation of its own stand in for a real container in the host environment, and the shim that makes that work implements the parts of the host contract its author remembered. Three of the operations a real container must support are wrong in the same way: registering interest in an event and then withdrawing it loses track of what was registered, so the withdrawal silently does nothing; dispatching an event through the stand-in behaves differently depending on what kind of real container it is standing inside; and asking where the stand-in sits relative to another element gives an answer that contradicts the tree for the two edge cases - the outermost element of the document, and a stand-in that currently contains nothing at all. Each of these is invisible in the common case and only shows up when the construct is used where a real container would have been. The contract is that a stand-in for a host object must satisfy the host's own contract at its edges, not merely in the middle, and that the tree-shaped questions must be answered from the tree the framework maintains rather than from whatever the host happens to return. Elsewhere in the folder the same problem is handled by refusing to stand in at all: two libraries attach their listeners to a real element they own and route everything through it, so no host contract is ever emulated. Which files emulate a host container incompletely, and which own the delegate-to-a-real-element contract they can be compared against?

react #37160 · [DOM] Fix Fragment removeEventListener dropping tracked listeners 5 files in the key

Repositories, each pinned at its own commit

Retriever

Several places in these libraries decide whether they HAVE something by asking whether the thing is truthy, and the things in question are values supplied by the application, which are allowed to be zero, an empty string, or nothing at all. So a combined result that legitimately computes to an empty value is treated as no result, and recomputed on every pass instead of being reused; and a failure whose value is legitimately empty is treated as no failure, so the consumer that was supposed to be told about it is never told and runs on down the success path. In both cases the presence of the thing and the value of the thing have been collapsed into one test, and the only inputs that expose it are the ones an application is entitled to produce. The contract is that presence is a separate fact from value: it has to be carried by a flag, a tag, a wrapper or a status, never inferred from the value's own truthiness. Elsewhere in the folder that separation is the whole design: one library models every outcome as a tagged pair whose tag - not its payload - says which arm it is, and another goes further and enumerates the values that have no natural ordering at all, with a comment saying they are handled explicitly rather than left to fall out of a comparison. Which files infer presence from truthiness, and which own the presence-is-not-value contract they have to be brought in line with?

query #11065 · fix(query-core): memoize falsy combine results in QueriesObserver 4 files in the key

Repositories, each pinned at its own commit

Retriever