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?

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?

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?

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?

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?

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?

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?