An identity that moved, a search that only knew where it moved to, and the duplicate that followed

[briansrls]

#11485 relocated the review sheet's identity from Drive's appProperties to properties. The reason was right — the bootstrap create and the recurring search run under different OAuth clients, and an app-private marker reads as absent to the other one, which is itself a way to mint a duplicate. The search query was rewritten to match. Both halves are correct read alone.

What neither half said is that a file already carrying the old field is still the review sheet. The operator's live spreadsheet was such a file. The next converge searched, got a clean, well-formed, empty result, and created a second spreadsheet beside one holding real data. Nothing refused, because nothing failed — the lookup answered the question it was asked. It was recovered by hand, and nothing in the model would have recovered it.

The earliest unjustified boundary is not the query

review_sheet_search_query implements its own contract correctly. The boundary is one link up, where the identity relation is declared: the relation a converge needs is "is this the review sheet", and the query was rewritten as though the field name were that relation. Those two agree before the move, and agree again once every file has migrated. The in-between is exactly where this repository stood, and no declaration anywhere said the in-between existed.

What lands

extdeps.google.drive — UpdateFileProperties, PATCH /files/{id}. PATCH rather than PUT because the merge semantics are the safety property: the properties map merges by key, so writing one key leaves every property this repository never wrote untouched, where a PUT would replace the resource and drop them. The superseded field is deliberately not cleared — a file carrying both markers is reachable by either search, which is the state that fails safe while any reader of the old field may still exist; clearing it is a second write owed its own readback.

gunbc.review_sheet_drive_converge — the identity's history. SupersededSearchReading = SupersededNotConsulted | SupersededRead { observation }. That first arm is the structural claim rather than bookkeeping: "we did not look" can no longer arrive at the decision wearing the same shape as "we looked and found nothing", and no path leads from it to Apply. A caller that skips the second read cannot mint a file, whatever the first read said.

A create now requires absence established across the whole identity, not across its current spelling. Every refusing arm of the superseded read — unreadable, incomplete, paged, duplicated — refuses the converge rather than falling through, because each is precisely the state that cannot tell a migrated drive from an unmigrated one. Answering "create" there is this same defect repeated one generation later (§5: a failure arm must refuse, never widen).

The second search is issued only where its answer can change the decision, which is also the only place it is safe to skip. An adopted sheet settles the identity, so the steady state — every run after the first — issues exactly the one files.list it issued before this change.

The readback asserts the id, not a count. files.update answering 200 establishes that Drive accepted a write, not that a search on the current marker now reaches this file — which is the only property the migration exists to produce. So verification re-asks the original question, the query that found nothing before the write, and requires the answer to be the file we patched. Exactly-one would also be satisfied by a concurrent create elsewhere, and adopting that would hand the converge a different spreadsheet than the one holding the operator's data: the original defect with the roles reversed.

Evidence

Twelve witnesses green by execution, eight new. The pairing is deliberate:

• unconsulted_superseded_search_refuses_the_create supplies the exact input shape the old fold answered Apply-create for, so it is red against the previous behaviour rather than merely true.
• absence_under_both_markers_still_creates is the positive control, without which a fold that refused every absence would satisfy every other claim here while leaving the converge unable to mint the first sheet.

The remaining four are pre-existing claims, re-shaped by the signature change and re-run.

The class is filed

gunbc.recurring_failure_mode identity_relation_modelled_at_its_current_spelling_only — ceiling 3, with the trigger naming the capability: an identity relation whose locations are an ordered set with the resolver derived from it, so a relocation is an append and a lookup reading one element is unwritable.

The row also records why no witness held this. #11485 shipped a claim asserting the search query names properties and the marker key. That claim is true, it went green, and it is about the query's spelling rather than about the relation the query decides. A witness discriminates only at the boundary it is pointed at, and every witness in that module pointed at the new spelling because the new spelling was what the change was about. The claim nobody writes is that a subject recorded under the previous spelling is still found.

Not claimed here

A live run. The Drive half has not been executed against the real API since this change, and the operator's sheet was already migrated by hand — so there is no legacy-marked file left to exercise the migration arm against. That inhabitance is owed by the next real converge rather than asserted by this PR.

Follow-up to #11581.

🤖 Generated with Claude Code

[gunbai-bot]

Both findings confirmed and fixed in 19f6e22. They are one thing, and taking them in the order they actually happened rather than the order they were reported makes the repair obvious.

The duplication came first, and it created the job the bad test was written to do. I authored the query shape twice to vary one token. Then, having built the relation twice, I reached for a test that the two copies agreed — validation standing exactly where construction was available.

And the test was worse than absent, by the mechanism you named. legacy contains "appProperties has { key" — capital P — so the lowercase pattern "properties has { key" never matched, the negation was permanently true, and the || short-circuited before current was ever inspected. Green by construction while its own annotation cited it as establishing the property the migration decision rests on.

The fix is the construction, and it dissolves the test rather than repairing it. One review_sheet_marker_query(marker_field, marker_value); review_sheet_current_marker_property_field becomes a declaration beside the superseded one; both wrappers delegate. "Identical except the field" is now asserted nowhere, because it cannot be false — there is one query shape and the field is the only thing either caller supplies.

What replaces it is the residue that can still go red, and I established that by mutation rather than by reading — reading is what produced a vacuous check in the first place:

claim	mutation	observed
the_superseded_field_is_not_the_current_one	superseded field → "properties"	false
each_marker_query_is_the_shared_builder_at_its_declared_field	one wrapper appends " and starred=true"	false

Both restored, both re-observed true, and the working tree re-checked for residue of either mutation before committing. Sixteen witnesses in the module green by execution afterwards.

The first of those guards something real rather than a style rule: if the superseded field were edited to the current spelling, the second search would ask the first question again, answer absent for the same reason, and open the create arm over a drive holding a legacy-marked sheet — the original defect, reached through the machinery built to prevent it.

— sent from zesty-crane-846

[briansrls]

HOLD — source-reviewed exact head 19f6e22585ae643811134ebf17c516e63ba6a104.

The incident analysis is right, but this implementation does not yet close the identity relation it names.

1. The PATCH success body cannot decode under its declared field mask. UpdateFileProperties requests fields=id and maps 200 to DriveFile, whose required fields include name and mimeType. A real successful PATCH can therefore become RestExchangeUndecodable, and this PR explicitly has no live migration run. Either request every required field or introduce the narrow response carrier this operation actually asks GitHub Drive to return.

2. The superseded location is skipped exactly when a cross-generation duplicate can exist. read_superseded_marker returns SupersededNotConsulted whenever the current-marker search finds one file, and ensure_review_spreadsheet immediately returns Noop. Therefore current-marker file A plus superseded-marker file B is reported converged, although the PR's own failure-mode row says the lookup owes both locations until the old population is established empty. This is the duplicate already minted by the incident, merely hidden by the new/current result.

Until a retirement receipt exists, read and reconcile the full identity extent on every decision that would adopt or create: absent under both may create; the same file under both may adopt; different file IDs must conflict; any unread/incomplete location must refuse. A union search derived from the identity-location carrier would also satisfy that contract.

Nonblocking but worth keeping visible: UpdateFileProperties introduces another hard-coded gunbcReviewSheet spelling beside the declared marker key. The language limitation is real, but it remains an unpinned duplicate authority.

Please do not run or merge this head as the recurring sheet converge. The present source can still hide an existing duplicate and its migration operation has no executable successful decode.

[briansrls]

Additional blocking finding on the same head: the superseded-marker read cannot generally observe the incident it claims to repair.

The PR says the marker moved from appProperties because bootstrap creation and recurring search use different OAuth clients. Google Drive defines appProperties as private to the requesting application. But read_superseded_marker performs the legacy appProperties query through the current drive.Files credential—the recurring client. In the intended cross-client case, that client cannot see the old marker, so the legacy query can answer a clean SheetAbsent against the original file and the create arm opens again.

A two-query fold is insufficient when one query is structurally blind under the active credential. Recovery needs one of:

• a one-time migration read under the original creating OAuth client;
• an operator/recorded legacy file ID that is independently read and patched;
• or another observable identity shared across clients.

Until that acquisition boundary exists, appProperties absence under the recurring client must not be treated as evidence that no legacy-marked sheet exists. This is the same earliest boundary as the original incident, not a separate optimization.

[gunbai-bot]

The HOLD is correct and the fix is in 92cae60. This one is worth stating bluntly: the fix reproduced the defect it exists to close, and the authority was in the file I was editing.

extdeps.google.drive — three hundred lines above the operation I added to it, in an annotation written when #11485 moved the marker — already says:

"A property private to the creating app is invisible to the searching app, so the search would have answered SheetAbsent against a file that exists and the converge would have minted a second spreadsheet."

That is my superseded search exactly. It reads an app-private field; this repository never observes which OAuth client its token belongs to; I treated an empty result as absence and opened the create arm. In the one scenario this change was written for — bootstrap under one credential, recurrence under another — the search returns empty against a live sheet and the converge mints a duplicate beside it.

It is also the class I filed in this same PR. identity_relation_modelled_at_its_current_spelling_only cites absent_reads_identically_to_never_looked as its nearest neighbour and draws the boundary between them; I then built a fresh instance of the neighbour. Writing a row about a class does not make its author immune to it.

The repair keeps the asymmetry

A positive find needs no caveat — seeing the file is proof it was visible — so the migration path is untouched. Only the absent arm is conditioned, on a SupersededMarkerVisibility the caller supplies. An empty superseded result has two preimages the response cannot distinguish, so the standing decides rather than the response. That's what keeps this from being the over-prohibition §4d warns about.

What it costs, stated rather than buried

The CLI supplies the honest value — unobservable — so a drive where neither marker finds anything now refuses instead of creating. A genuinely empty drive cannot auto-mint its first sheet until someone establishes the client or supplies the file id; the refusal names both remedies rather than just stopping.

That is a real behavioural narrowing. I think it's the right trade — refusing costs an operator one manual step, creating wrongly costs a live spreadsheet going dark while every later converge adopts the replacement — but it is a narrowing, and a reviewer should weigh it rather than discover it.

Evidence

absence_under_an_unobservable_superseded_client_refuses_the_create, with an authorable red rather than an asserted one: mutating the unobservable arm back to Apply-create — the behaviour this commit removes — makes it return false; restored, true. Six sibling claims green beside it, including absence_under_both_markers_still_creates, which now supplies an established visibility and is the control proving the create path is still reachable rather than walled off.

Note the prior floor red on 19f6e22 was infra, not this diff: signature MemoryStallRefusedPageThrash, and the re-run passed at 59m23s on the identical tree.

— sent from zesty-crane-846

[gunbai-bot]

Review 67720 is right, and the finding is sharper than the caveat I wrote myself. I told the operator this change "narrows" the create path and that it stays reachable once someone supplies the basis. Nothing could supply it. Fixed in bd374a9.

SupersededFieldVisibleToThisClient had no production constructor. The only thing building it was a witness fixture — so an empty drive always refused, the refusal named two remedies that did not exist as inputs, and the two claims asserting a create was still reachable were green only through a value the actuator never emits. Deleting that fixture's visibility would have touched no running entry point while bootstrap stayed dead.

That is the pairing obligation inverted: supplying an input removed the last execution of the real path, and the claim meant to be the control for over-prohibition was the thing concealing it.

Two real routes, one per situation

Naming one and not the other would leave the other refusing with no route, which is the defect being repaired:

file	meaning
.gunbc/review-sheet-legacy-file-id	adopt this sheet — migrated through the same plan, so the marker is written and the readback still has to find it
.gunbc/review-sheet-no-legacy-sheet	this drive holds none; a create is permitted

The id is consulted ahead of every search, and that ordering is the point rather than an optimisation: the id exists precisely for the case where no search can reach the file, so consulting the searches first and falling back would make the remedy conditional on the failure mode it was supplied to route around.

This is a HumanIntervention in the strict sense rather than a gap dressed as one. Whether a drive holds a sheet marked with an app-private property this credential cannot see is not observable through this credential at all — no read closes it, so it is not a capability waiting to be built. A human with the Drive UI sees the file; this process cannot.

The fixture now routes through the production fold

w_visible() calls visibility_from_declaration rather than naming the arm, so the claims exercise what the actuator calls and deleting that fold reds them. Beside it, the control this change lacked: no_declaration_leaves_the_superseded_visibility_unobservable, whose red is authorable and observed — mutating NoDeclaration to read as visible turns it false.

Worth noting what that mutation didn't do: absence_under_an_unobservable_superseded_client_refuses_the_create stayed green under it, correctly, because its subject is the decision and it supplies its visibility directly. The fold now has its own control and the decision has its own — that split is what was missing.

Six claims green by execution, two new.

— sent from zesty-crane-846

[gunbai-bot]

Review 67745 is right on both counts, and the second one is the lesson. Fixed in 88da703.

Wrong Filesystem. std.resources Filesystem is a resource whose read capability is read, takes a TextFilePath, and returns only content. The shape my reader uses — Filesystem.Read returning .success/.content/.error — is the service in extdeps.filesystem.filesystem_io, which I never imported. The resource shadowed the service exactly as you describe, and trim was bare with no std.algebra import.

The corrected imports are precisely what gunbc.instruments.github_app_acquire already uses for the same job — std.algebra { trim }, extdeps.filesystem.filesystem_io { Filesystem }, std.resources { Network } alone, with std.resources.Filesystem qualified in the uses clause. I could have copied them from a module I had open two hours earlier.

My verification was worthless, and that is the part worth recording

I "typechecked" by running the CLI entry with --function nope, took NoSuchFunction as proof the module was sound, and reported it that way. That check reaches no body. It is the rostered class an_unreached_entry_body_is_never_typechecked, and it returns green for any unresolved name in any function the entry does not call. So this defect wasn't caught late — it was never looked for, and I said "typechecks through the CLI" about a body nothing had compiled.

What replaced it is execution on the exact function

A probe that imports read_superseded_declaration and matches its result, run against the live filesystem:

• no declaration → both declared paths read, fold answers NoDeclaration
• .gunbc/review-sheet-legacy-file-id present → short-circuits on the first read, answers DeclaredLegacySheetId carrying 1CzExampleLegacyFileId — a value from disk that no fixture supplied

That is the arm you correctly said had no compiling producer, now green by execution rather than by a typecheck that never ran.

The general repair is not diligence

The handoff from the session that landed #11552 names it from the other side of the same night: eight review findings there, every one a single-authority or honest-reporting defect, two reintroduced while writing the memory about that class — and the fix wasn't notes, it was the census that finds identifiers called but neither declared nor imported. This is the fourth instance of that shape today. A probe that reaches the body is the cheap version of that census and it takes one file.

— sent from zesty-crane-846

[gunbai-bot]

Review 67779 found the arm I added to close the duplicate doing it again by a third route. Both findings are real. Fixed in 3ea1341.

The short-circuit was silent wrongness

DeclaredLegacySheetId applied the migration without reading observed or superseded — both of which converge_review_spreadsheet had already computed and handed in. The case my annotation never considered is exactly the one you name: current marker absent, superseded search naming A, declaration naming B. The fold patches B, verify_marker_migration sees only B and answers MigratedAndVerified, and A stays on the superseded marker, goes dark, and the run reports success. That's the same identity split the failure-mode row in this PR describes — and my own annotation arguing for the ordering is what made it look deliberate rather than unconsidered.

It also stepped over the current search's refusal arms, so a write could land while it was still unknown whether a current-marked sheet existed. A line-stop a later branch can skip is not a line-stop.

The rule that keeps both properties

The id is honoured unless a search positively names a different file.

Absence, unreadability and partial listings are exactly the ignorance the id was supplied to compensate for, so they don't veto it — that's what keeps this from becoming the over-prohibition that killed bootstrap two revisions ago. A positive find that disagrees is two files answering for one identity, which only an operator settles. A duplicated superseded find is that same question, so the declared id must be one of the named files or the disagreement stands.

The pairing finding is right, and its repair is not a claim

The witnesses construct SupersededMarkerDeclaration directly and never call read_superseded_declaration. But claims here are pure — no claim can call a function that performs a filesystem read, so asserting this pairing in a witness isn't available.

The honest discharge is an executing entry point, which is the shape gunbc.instruments.github_app_acquire already uses for its own custody reads rather than asserting them in prose: review_sheet_declaration_receipt — argv-free, read-only, performing the two reads the converge performs and reporting which declaration is in force. Deleting the reader reds it.

Evidence

Three new decision claims, each an arm the first cut got wrong:

• a_declared_id_disagreeing_with_the_superseded_find_refuses — names both legacy-A and declared-B in the refusal
• a_declared_id_does_not_bypass_an_unreadable_current_search
• a_declared_id_agreeing_with_the_superseded_find_migrates — the control, without which a fold refusing every declared id would satisfy the other two while leaving the id route dead

And the receipt run live, twice: readable id → exit 0; id at chmod 000 → REFUSING: ... the host refused this read as permission_denied: Permission denied (os error 13).

— sent from zesty-crane-846

[gunbai-bot]

Both findings are real and both are fixed in 243ec88. The second one I had argued myself into, so I want to name that rather than just patch it.

Effect propagation (review 67878)

Your mechanism is right and sharper than I'd have got to. converge_review_spreadsheet now performs a filesystem read, and no stage requires a caller to declare a callee's resource — build_item_info populates resource_names from the item's own uses clause only, and the transitive effect fixpoint copies resource_names through unchanged. So there is no located refusal, the interpreter runs fine, and the failure surfaces one layer later in 05_emit_rust, which appends &fs per callee resource name at the call site while emitting the caller's signature from the caller's own uses.

Declared on every function on the chain — converge_review_sheet_all, converge_drive_half, converge_drive_half_cli — and not on drive_half_exit, which consumes an already-computed report and reaches no read. Declaring an effect a function doesn't perform is its own defect.

Verified by emission, not typecheck, since typecheck is exactly what can't see this: a scoped Rust emission of this closure now reports no unbound-fs error. Its one remaining blocking error is at review_sheet_drive_converge.dag:258 (filter in branch condition, inside membership_from_complete_page) — a line this PR does not touch, landed by #11485 and already on main.

The duplicated-selection arm (review 67876)

decide_with_declared_id migrated when the declared id was any member of a duplicated superseded find. The others stay on appProperties; the next run finds the migrated file, answers Noop, and read_superseded_marker never consults that field again once SheetObservedOne hits — so they go dark with MigratedAndVerified reported. The harm this PR's own failure-mode row describes, reached through a positive observation rather than an empty one.

I had reasoned that an operator supplying an id is the adjudication a duplicate needs. Your sentence is the correction and it's exact: a declaration written before the search is not a selection among files the search then found. The operator wrote that id without having seen the duplicates.

It was also inconsistent with every neighbour in the same function, as you note — a single superseded file that isn't the declared id already refuses for this precise reason, current-marker duplicates already refuse even when the declared id is among them, and with no declaration superseded duplicates always refuse. The module's own standing rule is that SheetDuplicated is a refusal and never a selection. One arm disagreed, and it was mine.

The arm now refuses and names every id, so the operator settles it with all of them in view. a_declared_id_among_superseded_duplicates_still_refuses asserts both appear; the agreement and disagreement claims re-run green beside it.

Also cleaned up in this push: three files (extdeps/github/app.dag, github_app_acquisition.dag, instruments/github_app_acquire.dag) had been swept into this branch by a git add -A after I checked them out from main to read during an audit. They're identical to main again and out of the diff, and main is merged in — which is what was actually breaking heal-generated-artifacts, since the docs regen couldn't resolve std.list first_duplicate_by_key on a 19-commit-stale branch.

— sent from zesty-crane-846

[briansrls]

HOLD — source-reviewed exact head 243ec88738c00f21c6c9cdbad048c841d31326e1.

The declaration reader, typed filesystem absence, disagreement refusals, and exact-ID migration readback are substantial repairs. Two blockers remain.

1. A current-marker hit still hides the legacy identity extent. read_superseded_marker returns SupersededNotConsulted whenever the current search finds one file, and ensure_review_spreadsheet immediately returns Noop. Thus current-marker file A plus superseded-marker file B is reported converged whenever no legacy-ID declaration happens to be installed. The witness exactly_one_match_adopts_without_writing preserves this path explicitly. This is the cross-generation duplicate the incident created, now hidden by A rather than repaired. Until a migration-complete/old-population-empty receipt exists, adoption as well as creation must reconcile the full identity extent—or require a subject-bound operator declaration before treating A as the sole lineage.

2. The PATCH success response still has no executable decode contract. UpdateFileProperties requests fields=id but maps HTTP 200 to DriveFile, whose required fields include name and mimeType. No source change in this head narrows that carrier or widens the field mask, and the PR still carries no live migration receipt. A legitimate successful PATCH may therefore arrive as RestExchangeUndecodable before the exact-ID readback can run. Use a response carrier matching {id} or request every required DriveFile field.

The operator-supplied file ID correctly repairs an invisible legacy file when present, but it cannot make the no-declaration/current-hit path safe, and it does not repair the wire decoder. Do not merge or run this head as the recurring converge.

[briansrls]

HOLD — exact head 2ab08a832977412c4546f20dcb3f17f5ab5f8c95.

The two prior P0s are repaired:

• every non-refusing current observation now performs the superseded-marker read;
• UpdateFileProperties now requests id,name,mimeType, satisfying the required DriveFile response fields.

The remaining blocker is now explicit policy rather than a missed branch:

adopt_unless_a_legacy_lineage_disagrees returns Noop when the current marker names file A and the superseded read is SheetAbsent, unreadable, incomplete, or paged. The witness a_current_hit_with_an_unreadable_legacy_search_still_adopts deliberately pins that behavior.

That still admits the exact incident topology:

properties     -> duplicate/current file A
appProperties  -> original file B, invisible to this OAuth client
legacy search  -> clean absent (or otherwise unreadable)
result         -> Noop / SpreadsheetAdopted(A)

The positive-disagreement wall never fires because app-private invisibility is the reason B cannot be positively found. The converge then reports the replacement lineage as converged and leaves the original data dark. This is not merely uncertainty around a harmless steady state; it is the original failure mode after the duplicate has already been minted.

There is a second modeling tell at the same boundary: visibility_from_declaration(DeclaredNoLegacySheet) constructs SupersededFieldVisibleToThisClient. An operator declaration that no legacy sheet exists does not establish OAuth-client visibility. It may justify adoption/create under policy, but it is a different fact and should not be laundered into the visibility carrier.

Blunt recommendation: stop iterating this PR as one unit

Ten rounds and several defects introduced by the preceding repair are evidence that three subjects are entangled:

1. Pure identity reconciliation — current observation × legacy observation × operator declaration, with an operator ruling on whether current-hit + unresolved legacy extent is converged or non-converged.
2. One-time migration actuation — PATCH an explicitly selected file and independently read back the exact ID.
3. Generation retirement — a subject-bound receipt that the legacy identity extent is retired, after which the second search and declaration are no longer required.

Split those. The pure decision table should land first and make the controversial arm impossible to hide in transport code. The effectful migration should then consume only its admitted plan and get a live specimen on a disposable/controlled sheet. The recurring converge should not report SpreadsheetAdopted while legacy extent is unresolved; use a distinct non-converged outcome or require the already-modeled operator declaration until a retirement receipt exists.

I do not recommend another solo patch round on this 1,500-line PR. Freeze this head as the study, recut the smaller authorities from current main, and review each exact SHA independently.

The exact-head witnesses workflow is also nonterminal as I write this, but the source HOLD is independent of CI.

[gunbai-bot]

Closing rather than rebasing, per the side-chat ruling that this PR be parked and its combined migration route not executed. The branch is kept, not deleted — fix/review-sheet-marker-migration at 2ab08a83 — so nothing here is lost, only stopped.

Why it is closed rather than repaired

This PR took ten review rounds, and most of them found a defect introduced by the fix in the round before. The root cause was structural, not effort: it decided the meaning of each reading inside effectful routing, so every repair to one arm opened another. That diagnosis is what produced the recut, and the recut's first cut has now landed.

Superseded by #11669 (merged): gunbc.review_sheet_identity — the subject carried in content, LegacyExtentEvidence keeping provenance separate from conclusion, LegacySearchVisibilityBasis, the sealed ReviewSheetIdentityStanding, the single LegacyExtentVerdict, and the an_absent_reading_assigned_an_extent_conclusion failure-mode row. Eighteen claims, each wall with its control.

Cut 1 is deliberately bounded and does not repair the production converge. It provides the authority a future repair is written against.

What this branch still holds, and where each piece goes

Six files, 14 commits ahead of main. Not salvaged wholesale — the point of the recut is that these are rebuilt against the kernel rather than carried across with their semantics embedded:

here	destination
superseded-marker query constructor; Drive producer; filesystem_exact_read declaration reader; DeclarationUnreadable	Cut 2 (A) — producers emitting LegacyExtentEvidence, deciding no standing
declared-id reconciliation against a standing, a contradicting observation and a file-by-id preflight	Cut 3 (C1) — admission, with its own refusals
UpdateFileProperties PATCH (fields=id,name,mimeType) and the id-asserting readback	Cut 4 (C2)
identity_relation_modelled_at_its_current_spelling_only	re-file against the kernel if still distinct from the landed row
—	Cut 5 (E) — legacy-generation retirement

Three standing constraints for whoever resumes this

1. Cut 1 is not a converge repair. Landing it changed no production behaviour.
2. Do not execute this branch's combined migration route. The operator's live sheet was repaired by hand; the ordinary steady-state adoption path was exercised live (two GETs, zero writes, existing sheet adopted).
3. Do not relocate the marker again until the producer and admission cuts are resumed. A second relocation with no producer is how the first duplicate was minted.

Worth recording for the next reader: an empty appProperties search establishes "this OAuth client received no matching rows", never "no legacy-marked file exists." Nothing in this corpus observes the OAuth application identity its token belongs to — a service-account principal is a different subject — so that gap is a capability, not a field.

🤖 Generated with Claude Code