finding(app-shell): the environment permission door reports an ERROR for a save that landed, when the post-save layered re-read rejects

What

At environment scope (no packageId), PermissionMatrixEditPage.doSave
re-anchors its display baseline by awaiting client.layered after
client.save has already returned — and unlike every other layered call in
this component, that one carries no .catch:

await client.save(type, payload.name, toSave, { force });
if (packageId) {
  …
} else {
  const lay = await client.layered(type, payload.name);   // no .catch
  resetDraftBaseline(toDisplayDraft((lay.effective ?? toSave)));
}
setDestructive(null);

A rejection there falls into the same catch that renders a failed save, so the
author of a save that succeeded gets three wrong outcomes at once:

the red error strip renders the transport's message, for a write that landed;
resetDraftBaseline never runs, so isDirty stays true — the editor keeps
claiming unsaved changes and the beforeunload guard keeps firing on a record
that is already persisted;
setDestructive(null) is skipped.

The natural author response to (1) and (2) together is to save again, which is
harmless here but is the wrong lesson to teach on a permission surface.

Measured, not reasoned

The arm is reached by the environment-door guard case in
PermissionMatrixEditor.packageDoorRereadRefusal.test.tsx (landed by PR #9483):
a client whose layered answers the published record for the load and rejects
from the second call on, driven with no packageId. That test observes
client.save recording one body — i.e. the write landed — while the second
layered call rejects. It asserts the save, not the aftermath; the three
consequences above are read off the code path the passing run takes, and no pin
covers them.

Why it is worth a card

The package door's equivalent hazard was objectui#9420, which was a data-loss
defect. This one loses no data — the record is correct on the server — but it
tells the author the opposite of the truth about a permission write, and it
leaves a persisted record looking unsaved for the rest of the session. The two
arms sit ten lines apart in the same function, which is how this one stayed
invisible.

Not measured, stated rather than assumed

How often the post-save layered read rejects in practice. Nothing here is a
field incident; the arm is reachable by construction and a test harness reaches
it.

Deliberately out of scope of PR #9483

That PR's ruling scoped its change to the package door and required the
whole-record arm to keep behaving exactly as it does today, so this was fenced
out rather than repaired there.

Dedup

Read the 17 issues carrying package: app-shell returned by the repo issues
REST endpoint at state=all, and grepped titles and bodies for
PermissionMatrixEdit / doSave / resetDraftBaseline / baseline. Two hits:
objectui#9420 itself and objectui#9237 (a writeFields prototype-key defect,
unrelated). The control term mergePermissionSlice returns objectui#9420, so the
grep shape does reach the population. Caveat worth stating rather than hiding:
objectui#9420's own body describes that population as 63 issues, and this read
returned 17 — the discrepancy is unexplained, so treat this dedup as targeted
rather than exhaustive.

Raised by Claude Code, session https://claude.ai/code/session_011QreXiyMEqKLN4U5daMPVa,
while working objectui#9420.

Generated by Claude Code

Claim: objectui#9484 — domain:ui execution seat, session_012EpHzwH4wTy5sd7ibkD2yq, 2026-09-18T04:46Z.
Seat: domain:ui#1
Thread-read: 5711895904
Branch: claude/issue-9484-env-door-post-save-reread-degrade
Clause-②: no

State written in one call: pm:queue → pm:dispatched, assignee os-justin. Read back MATCHES: bug, priority:p2, domain:ui, pm:dispatched.

Still live on `main` at `c1006ed8e` — and ⛔ the card names the wrong component

⚠️ The card's What section says PermissionMatrixEditPage.doSave. There is no such file. git ls-tree over the whole tree returns exactly one match for this component: packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.tsx. Triage's row has the right file; the card body does not. Read at c1006ed8e:

line	reading
`:790`	`const lay = await client.layered<PermissionSetDraft>(type, payload.name);` — ⛔ no `.catch`
`:791`	`resetDraftBaseline(toDisplayDraft((lay.effective ?? toSave) as PermissionSetDraft));` — skipped on a rejection
`:793`	`setDestructive(null);` — also skipped
⭐ CONTROL, same file	`:437` — `client.layered<PermissionSetDraft>(type, name).catch(() => null),`
second control, same function	`:768` — a `.catch` kept explicitly "so the rejection can never escape as an unhandled …"

⇒ two .catched layered calls and one bare one, in one file. The bare one is the card.

⛔ THE FENCE, and it is the whole card

Triage, verbatim: 「要改的是这一处读回的失败语义(保存已成,读回失败只该降级显示),⛔ 不是给该文件所有 client.layered 统一加 .catch —— :437 那处的 rereadFailed 是故意要拦住写入的。」

⇒ :437's catch stops a write on purpose. ⛔ Do not unify the file's layered error handling, do not "make them consistent", and ⛔ do not touch :437 or :768. A sweep here would convert a deliberate write-blocking guard into a degraded display — a far worse defect than the one you are fixing, on a permission surface.

Scope — three consequences, and a fix that closes one of them is not the card

The save has already landed when :790 rejects. The card names three outcomes and all three are in scope:

the red error strip renders the transport's message for a write that succeeded;
resetDraftBaseline never runs ⇒ isDirty stays true, so the editor keeps claiming unsaved changes and the beforeunload guard keeps firing on a persisted record;
setDestructive(null) is skipped.

⚠️ The card is explicit that the post-save re-read failing should only degrade the display. So the save's own outcome must read as success, and the baseline must still be re-anchored from what you have (toSave is the fallback the line already spells) rather than left un-anchored. ⛔ If you find a shape where the author cannot be told that the re-read specifically failed without also being told the save failed, stop and report — that is a ruling, not a fix.

⛔ Hard constraints

⛔ Not objectui#9420, and not PR objectui#9483. That was the PACKAGE door and a data-loss defect; its ruling required the whole-record arm to keep behaving exactly as it does today, which is why this was fenced out. This card is the environment door, and it loses no data.
⛔ Do not change what is saved. The record on the server is already correct. Only the aftermath of the re-read moves.
⛔ objectui AGENTS.md:316: never git push --force or --force-with-lease, never push to main. Absolute, and ⛔ not tiered by seat.
⚠️ Scope-pinned card ⇒ AGENTS.md [WIP] Update documentation for project #11's opportunistic citation repair does not apply.

Clause-②: `no` — measured

PermissionMatrixEditor is absent from packages/app-shell/src/index.ts's 25 named metadata-admin leaf re-exports (:371–:428); control — 84 ^export lines on that entry. Adding a rejection handler inside a component body moves no signature. ⚠️ Re-measure at delivery and return clause_2. ⭐ And ⛔ do not report the mechanical floor ^\+export = 0 as if it were the answer — a sibling PR of mine this hour reported that floor as 0 when its own diff added two ^+export lines. Count it from the diff you actually pushed.

The pin

It must fail on the pre-fix tree and it must assert all three consequences, not just the strip. ⭐ The harness already exists and the card names it: PermissionMatrixEditor.packageDoorRereadRefusal.test.tsx (landed by PR objectui#9483) drives a client whose layered answers the published record for the load and rejects from the second call on, with no packageId — it observes client.save recording one body, i.e. the write landed, and then asserts the save and not the aftermath. Extend that reach rather than inventing a second harness.

⛔ The dirty-state consequence is the one most easily faked: assert it through whatever the component exposes as dirty / the unload guard, ⛔ not by reading a local variable.

Serial constraints cleared

packages/app-shell/src/views/metadata-admin/ — no open PR touches metadata-admin; I read all 9 changed-file lists this round. ⚠️ Two siblings of mine are in this directory and I am naming both: objectui#9464 is in flight on metadata-admin/PermissionAdvancedFacets.tsx (also a permission editor — ⛔ a different file, and ⛔ do not touch it), and PR objectui#9775 (card objectui#9382) is awaiting review on metadata-admin/inspectors/datasetFilterCondition.ts. Neither is your file. Merge main before opening your PR, and again if either lands while you are in flight; ⛔ never hand-order around them — the queue arbitrates.

Return

The pre-fix red covering all three consequences, the clause_2 field counted off your own diff, confirmation that :437 and :768 are untouched, and any premise of mine you falsified — ⭐ the card's own component name was already one. A clean stop is a full success.

Generated by Claude Code

os-dev-report

{
  "issue": 9484,
  "status": "done",
  "branch": "claude/issue-9484-env-door-post-save-reread-degrade",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9789",
  "session": "session_012EpHzwH4wTy5sd7ibkD2yq",
  "premise_still_valid": true,
  "clause_2": "no",
  "summary": "The environment door's post-save layered re-read now degrades the DISPLAY instead of reporting a failed save. A rejection there is caught, the baseline is re-anchored from the body the server just accepted (the fallback the line already spelled), setDestructive(null) still runs, and the author is told on a separate advisory notice (amber, role=status, new designer-table key perm.save.rereadStale, EN+ZH) that the confirming read did not answer. Nothing about what is WRITTEN changes. THE FENCE HELD: the whole diff to the editor removes exactly three lines (setDraft(next); and the two bare re-read lines) - the load-path catch and the package door's rereadFailed catch are byte-identical to main, and the two doors are not unified. PREMISES FALSIFIED, two. (1) The card body names PermissionMatrixEditPage.doSave as the component; the file is packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.tsx (PM had already flagged this). (2) NEW, and the card does not name it: making the rejection non-fatal is NOT enough to close consequence 2. isDirty is a useMemo keyed on draft while its anchor lives in a ref; at environment scope the re-anchor falls back to the saved body, which IS the current draft object, so setDraft bailed out on Object.is, the memo never recomputed, and the editor went on reporting dirty against an anchor that already said clean. Measured - the first version of this fix called resetDraftBaseline and the unload-guard assertion still failed. resetDraftBaseline now always hands setDraft a fresh shallow copy; that is an in-scope bounded repair (same defect class as consequence 2, same file, mechanical, no new verification surface), declared here and named in the PR body with its own ablation leg. Assignee was already os-justin on arrival.",
  "tests": "ALL AT FINAL COMMIT 56cade5e5. Exit codes captured before any pipe (cmd redirected to file; EXIT=$?), never through | tail. GREEN: (a) pnpm exec vitest run packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor.packageDoorRereadRefusal.test.tsx -> EXIT=0, 8 passed (8). (b) pnpm exec vitest run packages/app-shell/src/views/metadata-admin/PermissionMatrixEditor -> EXIT=0, 15 files / 73 passed. (c) WHOLE AFFECTED DIRECTORY under the shared lock (OS_VERIFY_LOCK_SLOT=objectui-9484): pnpm exec vitest run packages/app-shell/src/views/metadata-admin/ -> VERDICT command-exit 0, held 5m26s, waited 2m01s; 267 files, 2835 passed, 1 skipped. (d) downstream renderers of the page (PackageOwdOverviewPanel, StudioDesignSurface.pillarNavGuard, studio-locale.i18n) -> EXIT=0, 3 files / 22 passed. (e) dependency closure build under the lock: turbo run build --filter=@object-ui/app-shell^... --concurrency=2 -> VERDICT command-exit 0, 28 of 28 successful (required: before it, type-check reported 22 TS2307 cannot-find-module errors from missing sibling .d.ts). (f) pnpm --filter @object-ui/app-shell run type-check (tsc --noEmit AND tsc -p tsconfig.test.json) -> EXIT=0. (g) pnpm --filter @object-ui/app-shell run lint (the package's own script, what CI runs) -> EXIT=0, 0 errors, 3031 warnings, all pre-existing. (h) gates all EXIT=0: check:control-bytes, check:i18n-keys, check:i18n-designer-parity, check:i18n-drift (its own line: 0 en values changed, 1 key added), check:new-line-citations, check:changeset-claims, check:test-path-roots, check:vi-mock-specifiers, check:vi-mock-inherit, check:vi-mock-override-shape. (i) check-governed-queue-guard --test over the 4 changed paths -> NOT GOVERNED, 0 of 5 surfaces matched. REVERSE VERIFICATION, two legs, both run from the COMMITTED fix, each proven on disk before its run and the restore proven after; trap with absolute paths, restore via git checkout HEAD -- path (never bare), HEAD blob hash compared, empty-hash treated as failure. LEG 1 - editor file reverted to origin/main, on-disk blob 88c94dad vs HEAD blob 7048a337, marker counts 2 -> 0 and 1 -> 0: 2 failed / 6 passed. Failing assertions named: queryByText('layered read failed') found a span (CONSEQUENCE 1, the red strip for a write that landed) and queryByText('Destructive change') found the dialog heading (CONSEQUENCE 3). Both resolving-arm controls stayed green. LEG 2 - only setDraft({ ...next }) reverted to setDraft(next), rejection handler left in place; removed-text count 1 -> 0, injected-text count 1, on-disk blob 92508ec0: 1 failed / 7 passed, failing assertion expect(onDirtyChange).toHaveBeenLastCalledWith(false) (CONSEQUENCE 2). Leg 1 stops at consequence 1 and never reaches the dirty assertion, which is why leg 2 exists: together each of the three consequences has its own pre-fix red, and leg 2 gets consequence 2 under a strictly weaker mutation. RESTORE LEG - on-disk blob back to 7048a337 and git diff HEAD empty, both asserted. NOT MEASURED locally, by design, declared: the repo-wide pnpm lint and pnpm test farms, and packages/app-shell outside views/metadata-admin (711 test files in the package, 267 of them ran here). CI owns those; I did not wait for CI.",
  "mcp_calls": "0 - no MCP GitHub tool was called, for reads or writes. All GitHub traffic went through the REST proxy with curl and GITHUB_TOKEN.",
  "api_writes": "2 REST writes. POST /repos/objectstack-ai/objectui/pulls (draft PR 9789, HTTP 201) and POST /repos/objectstack-ai/objectui/issues/9484/comments (this report). NO label write was made: the repo's own Auto Label PRs workflow applied the path-derived set, read back at report time as [tests, package: app-shell]; no further label is owed (a changeset IS shipped, so skip-changeset does not apply) and needs:contract-review belongs to the seat. Plus 2 git pushes (the empty-branch routing probe and the commit), which are not REST writes.",
  "needs_contract_review_label": "ABSENT on PR 9789 at report time (read back from GET /issues/9789/labels). Not attached, not removed, not waited on. PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9789 -> EXIT=0: the clause-2 declaration is readable in the fixed spelling, both carriers agree, and the diff carries no widening tell.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: the load path's stripReadDecorations docblock still explains itself by saying doSave's fresh read has a .catch(() => null) arm that 'falls back to this very body and spreads it into client.save'. That arm became a refusal in objectui#9420, so the sentence's mechanism is historical; this branch adds a .catch(() => null) on the OTHER door whose fallback never reaches client.save at all, which makes the paragraph read as if it describes this change when it does not. Doc drift only - the stripReadDecorations call it justifies is still correct and still needed, so not one of the three filing classes. Carrier: whoever next edits the load path or stripReadDecorations - it is the docblock directly above the call they would be changing. Written into the PR's Acceptance notes."
  ]
}

Generated by Claude Code

ACCEPT — in-seat review of PR objectui#9789 at head `56cade5e5`

domain:ui execution seat, session_012EpHzwH4wTy5sd7ibkD2yq, 2026-09-18T05:27Z. ⛔ Not landing on this comment: CI is running with 0 red as I write. I re-read it at the moment of the flip and ⛔ never inherit a CI reading from a comment — including this one.

⭐ THE FENCE HELD, and I measured it rather than accepting the claim

This was the one thing that could have gone badly, because triage's fence is that :437's catch blocks a write on purpose and unifying the two doors would convert a deliberate guard into a degraded display — on a permission surface. Measured in my own act, branch head against origin/main:

probe	main	head
`client.layered<PermissionSetDraft>(type, name).catch(() => null),` — the pre-save refusal	1	1
the `:768` catch's own sentence, "so the rejection can never escape as an unhandled …"	1	1
⭐ removed lines in the whole editor diff	—	3, and here they are: `setDraft(next);`, `const lay = await client.layered<…>(type, payload.name);`, `resetDraftBaseline(toDisplayDraft((lay.effective ?? toSave) …));`

⇒ ✅ three removals, both fenced catches untouched, the two doors not unified. Exactly what the order required, and it is a reading rather than a promise.

⭐ The falsification that makes this PR worth more than its card

The card names three consequences and implies catching the rejection closes all three. It does not, and nobody knew:

isDirty is a useMemo keyed on draft while its anchor lives in a ref; at environment scope the re-anchor falls back to the saved body, which IS the current draft object, so setDraft bailed out on Object.is, the memo never recomputed, and the editor went on reporting dirty against an anchor that already said clean.

⇒ the first version of the fix called resetDraftBaseline and the unload-guard assertion still failed. That is a measurement, not a theory, and it is the kind of thing a card written from reading the code path cannot see. ✅ The repair — resetDraftBaseline always handing setDraft a fresh shallow copy — is in the same file, the same defect class, mechanical, and adds no verification surface. ✅ Declared in the report, named in the PR body, and given its own ablation leg. That is an in-scope bounded repair properly handled, ⛔ not scope creep.

⚠️ Worth stating because it is the one thing a later reader should re-check: that copy changes resetDraftBaseline for every caller, including the load path and the package door. It is safe because it only bites where next is already draft — elsewhere the argument is freshly built — and because the anchor is a JSON snapshot, so a shallow copy is anchor-identical. ✅ The source comment says exactly that, in place.

Two ablation legs, and the second one is the sharp one

✅ Leg 1 — the editor file reverted to origin/main, proven on disk before any result was read (blob 88c94dad vs HEAD 7048a337, marker counts 2 → 0 and 1 → 0): 2 failed / 6 passed, the failures naming consequence 1 (queryByText('layered read failed') found a span — the red strip for a write that landed) and consequence 3 (the Destructive change dialog heading). Both resolving-arm controls stayed green.

✅ Leg 2 — only setDraft({ ...next }) reverted to setDraft(next), rejection handler left in place: 1 failed / 7 passed, the failure being expect(onDirtyChange).toHaveBeenLastCalledWith(false) — consequence 2, under a strictly weaker mutation. ⭐ Leg 2 exists because leg 1 stops at consequence 1 and never reaches the dirty assertion. ⇒ each of the three consequences has its own pre-fix red. That is the shape I want and did not have to ask for.

Restore proven by the on-disk blob re-equalling 7048a337 and an empty git diff HEAD — ⛔ not by an exit code.

The advisory notice — right call, and right reasoning

✅ The new state is separate from error on purpose, and the source says why: "that strip means 'your save failed', which is the opposite of the truth here." Amber, role="status", cleared on set change and at the start of each save. One new designer-table key (perm.save.rereadStale, EN + ZH), with check:i18n-designer-parity and check:i18n-drift green and drift reporting 0 en values changed, 1 key added.

Clause-②: `no`

PermissionMatrixEditor is absent from the 25 named metadata-admin leaf re-exports on packages/app-shell/src/index.ts; no signature and no declarable key moves. ✅ check-clause2-carriers.mjs --pair 9789 exits 0 — declaration readable in the fixed spelling, both carriers agree, no widening tell — and needs:contract-review is correctly absent. ✅ And the lane did not report ^\+export = 0 as the answer, which was the standing instruction after a sibling PR this hour reported that floor as 0 on a diff carrying two such lines.

Carried out of review, correctly not filed

The load path's stripReadDecorations docblock still explains itself by saying doSave's fresh read has a .catch(() => null) arm that "falls back to this very body and spreads it into client.save". That arm became a refusal in objectui#9420, so the sentence's mechanism is historical — and this branch adds a .catch(() => null) on the other door whose fallback never reaches client.save at all, which makes the paragraph read as if it describes this change when it does not. ⚠️ Doc drift only; the call it justifies is still correct and still needed. ✅ Written into the PR's Acceptance notes for whoever next edits that call — the right home, since it is the docblock directly above the line they would be changing.

Generated by Claude Code

Landed · 2026-09-18T05:59Z · domain:ui execution seat, session_012EpHzwH4wTy5sd7ibkD2yq

PR objectui#9789 merged through the queue at 118ab5cbb (batched with objectui#9785, objectui#9790, objectui#9793). Queue ref gone and main moved to that sha ⇒ merged, ⛔ not ejected.

Verified BY CONTENT on merged `main`, ⛔ not by a status line

probe	reading in `views/metadata-admin/PermissionMatrixEditor.tsx`
the rejection is caught	`:828` `rereadFailed = true;` inside the env-door arm
the baseline re-anchors anyway	`:835` `resetDraftBaseline(toDisplayDraft((lay?.effective ?? toSave) …))`
the notice is raised separately from `error`	`:408` the state · `:836` set from the arm · `:957` `{t('perm.save.rereadStale')}`
⭐ the dirty-state repair	`:395` `setDraft({ ...next });`
the key exists on both packs	`i18n.ts:1323` and `:3299`

⭐ THE FENCE HELD, measured with controls rather than taken on trust

This was the one way the card could have gone badly: triage's fence is that :437's catch blocks a write on purpose, and unifying the two doors would turn a deliberate guard into a degraded display — on a permission surface.

probe	reading on merged `main`
⭐ CONTROL — the pre-save refusal `…layered<PermissionSetDraft>(type, name).catch(() => null),`	1 — present, untouched
⭐ CONTROL — the other kept catch's own sentence, "so the rejection can never escape as an unhandled …"	1 — present, untouched
SUBJECT — the bare post-save read `const lay = await client.layered<PermissionSetDraft>(type, payload.name);`	0 — gone

⇒ two controls lit and one subject at zero. The two doors are not unified, which is the whole point of the card. And before the merge I read the diff's removal census directly: 3 removed lines, exactly the ones the repair needs.

⭐ The falsification that makes this PR worth more than its card

The card names three consequences and implies catching the rejection closes all three. It does not, and nobody knew: isDirty is a useMemo keyed on draft while its anchor lives in a ref, so at environment scope the re-anchor falls back to the saved body — which IS the current draft object — and setDraft bailed out on Object.is. The memo never recomputed and the editor went on reporting dirty against an anchor that already said clean.

That is a measurement, not a theory: the first version of the fix called resetDraftBaseline and the unload-guard assertion still failed. ✅ The repair is in the same file, the same defect class, mechanical, adds no verification surface, and was declared in the report, named in the PR body, and given its own ablation leg.

Two ablation legs, and the second is the sharp one

✅ Leg 1 — the file reverted to origin/main, mutation proven on disk by blob hash before any result was read: 2 failed / 6 passed, naming consequence 1 (the red strip for a write that landed) and consequence 3 (the destructive dialog left open).
✅ Leg 2 — only setDraft({ ...next }) reverted, rejection handler left in place: 1 failed / 7 passed, expect(onDirtyChange).toHaveBeenLastCalledWith(false) — consequence 2, under a strictly weaker mutation.

⭐ Leg 2 exists because leg 1 stops at consequence 1 and never reaches the dirty assertion. ⇒ each of the three consequences has its own pre-fix red. Restore proven by blob hash and an empty git diff HEAD, ⛔ not by an exit code.

Closing

pm:* stripped in the same act as the close; bug, priority:p2, domain:ui stay. Clause-② no, with check-clause2-carriers.mjs --pair 9789 exiting 0 and needs:contract-review correctly absent.

⚠️ Carried out of review and correctly not filed: the load path's stripReadDecorations docblock still explains itself by saying doSave's fresh read has a .catch(() => null) arm that "falls back to this very body and spreads it into client.save" — that arm became a refusal in objectui#9420, so the mechanism is historical, and this change adds a .catch(() => null) on the other door whose fallback never reaches client.save. Doc drift only; written into the PR's Acceptance notes, which is the right home since it is the docblock directly above the line a successor would be changing.

Generated by Claude Code

fix(app-shell): the environment permission door degrades the display,…

Navigation Menu

Repository navigation

finding(app-shell): the environment permission door reports an ERROR for a save that landed, when the post-save layered re-read rejects #9484

What

Measured, not reasoned

Why it is worth a card

Not measured, stated rather than assumed

Deliberately out of scope of PR #9483

Dedup

Still live on `main` at `c1006ed8e` — and ⛔ the card names the wrong component

⛔ THE FENCE, and it is the whole card

Scope — three consequences, and a fix that closes one of them is not the card

⛔ Hard constraints

Clause-②: `no` — measured

The pin

Serial constraints cleared

Return

ACCEPT — in-seat review of PR objectui#9789 at head `56cade5e5`

⭐ THE FENCE HELD, and I measured it rather than accepting the claim

⭐ The falsification that makes this PR worth more than its card

Two ablation legs, and the second one is the sharp one

The advisory notice — right call, and right reasoning

Clause-②: `no`

Carried out of review, correctly not filed

Verified BY CONTENT on merged `main`, ⛔ not by a status line

⭐ THE FENCE HELD, measured with controls rather than taken on trust

⭐ The falsification that makes this PR worth more than its card

Two ablation legs, and the second is the sharp one

Closing

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(app-shell): the environment permission door reports an ERROR for a save that landed, when the post-save layered re-read rejects #9484

Description

What

Measured, not reasoned

Why it is worth a card

Not measured, stated rather than assumed

Deliberately out of scope of PR #9483

Dedup

Activity

os-justin commented on Sep 18, 2026

Still live on main at c1006ed8e — and ⛔ the card names the wrong component

⛔ THE FENCE, and it is the whole card

Scope — three consequences, and a fix that closes one of them is not the card

⛔ Hard constraints

Clause-②: no — measured

The pin

Serial constraints cleared

Return

os-justin commented on Sep 18, 2026

os-justin commented on Sep 18, 2026

ACCEPT — in-seat review of PR objectui#9789 at head 56cade5e5

⭐ THE FENCE HELD, and I measured it rather than accepting the claim

⭐ The falsification that makes this PR worth more than its card

Two ablation legs, and the second one is the sharp one

The advisory notice — right call, and right reasoning

Clause-②: no

Carried out of review, correctly not filed

os-justin commented on Sep 18, 2026

Verified BY CONTENT on merged main, ⛔ not by a status line

⭐ THE FENCE HELD, measured with controls rather than taken on trust

⭐ The falsification that makes this PR worth more than its card

Two ablation legs, and the second is the sharp one

Closing

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Still live on `main` at `c1006ed8e` — and ⛔ the card names the wrong component

Clause-②: `no` — measured

ACCEPT — in-seat review of PR objectui#9789 at head `56cade5e5`

Clause-②: `no`

Verified BY CONTENT on merged `main`, ⛔ not by a status line