[finding] app-shell's two confirm runtimes reset `confirmState` differently when the dialog closes

[yinlianghui]

Observation recorded while executing #5835 (type RecordDetailView's confirm handler as the published ConfirmationHandler + pin that both runtimes feed ActionConfirmDialog the same fields). Filed unassigned, observation-class — nothing user-reachable is known to be broken. Out of #5835's fence, which is the OPEN path; this is the CLOSE path.

Verified on origin/main @ 53dc89db8.

The two runtimes agree on open and disagree on close

Both mount ActionConfirmDialog and both hand it the same field set when it opens — { open, message, options, resolve }. That parity is now pinned by packages/app-shell/src/views/RecordDetailView.confirmRuntimeParity-5835.test.tsx.

Their onOpenChange handlers differ:

• packages/app-shell/src/hooks/useConsoleActionRuntime.tsx — replaces the whole state: setConfirmState({ open: false, message: '' }). message is blanked, and options / resolve are dropped.
• packages/app-shell/src/views/RecordDetailView.tsx — spreads and flips one flag: setConfirmState(s => ({ ...s, open: false })). message, options and resolve are all retained.

Why it may matter, and why it is filed rather than fixed

Two observable consequences, neither confirmed against a running app:

1. A blank frame during the close animation. ActionConfirmDialog renders state.message into AlertDialogDescription and keeps rendering during Radix's exit transition. The console runtime clears message synchronously on close, so the description can go empty while the dialog is still fading; RecordDetailView's copy fades out with its text intact.
2. A retained resolve. RecordDetailView keeps the previous promise's resolve in state after close. It is not a correctness bug today — ActionConfirmDialog calls state.resolve?.(false) itself before onOpenChange(false), so the promise is already settled and a second call would be a no-op — but it leaves a stale closure reachable in state, and the two runtimes disagree about whether that is intended.

Neither runtime is obviously the correct one; picking a winner is a call, not a cleanup, which is why this is filed instead of fixed. Same drift family as #5610 and #3320 — RecordDetailView re-implementing a shared runtime and then diverging from it with nothing red in between.

Not a request to merge the two runtimes; #5835's triage ruled that a larger refactor and out of scope.

---

Generated by Claude Code

[claude]

Concentrated triage batch: finding → pm:queue + domain:ui, Task, S — the two confirm runtimes agree on open (pinned by #5835's parity test) and diverge on close (useConsoleActionRuntime blanks the whole state; the sibling preserves fields). Converge the close handlers on one reset shape and extend the existing parity pin to the close path; if a close-path consumer genuinely depends on the divergent shape, that is a finding to report, not a reason to keep both.

---

Generated by Claude Code

[yinlianghui]

Claimed + dispatched — domain:ui @ objectui execution seat

PM session session_01CSoz9uGhaaSgiq3hshtN7L, branch claude/issue-6034-confirm-runtime-close-parity.
The assignee field does not establish whose claim this is — this comment's session ID does. No earlier claim comment exists.

裁决 (binding)

The two confirm runtimes agree on open (pinned by #5835's parity test) and diverge on close: useConsoleActionRuntime blanks the whole state; the sibling preserves fields.

Converge the close handlers on one reset shape, and extend the existing parity pin to the close path.

⚠️ Extend the existing pin — do not write a second one. #5835's parity test already owns this relationship; a new parallel test would leave two pins that can disagree, which is the same class of defect as the two runtimes.

⛔ If a close-path consumer genuinely depends on the divergent shape, that is a finding to REPORT — not a reason to keep both. Report it and stop on that half; do not preserve the divergence behind a flag.

PM机制假设 (verify)

1. Both runtimes still diverge on close as described, and [finding] RecordDetailView carries a second confirm runtime whose options bag no feeder ever fills #5835's parity pin still covers open only. Re-derive on today's main.
2. Which reset shape is correct is your call to make from the code — the card does not rule it. Blanking and field-preserving are observably different on a reopen; establish which one consumers actually rely on before picking, and say why in the PR body.
3. Enumerate the close-path consumers of both runtimes. ⚠️ A convergence that lands on one runtime's callers and not the other's is the "fix three of four sites" trap that bit two cards tonight — Authored FormSection.visibleWhen is dropped by all four plugin-form layouts — declared, bridged, then never evaluated on the object-view chain #6111's card named six sites when the key was dropped at two hops, and Two authored-predicate evaluators still pass undefined scope after #6010 — console FormPage (both routes) and the wizard's submit-time required re-check #6110's named four when there were six, one of which would have shipped the whole fix inert.

Traps

⚠️ Parity pins can pass by degenerating. If your fixture's confirm state is empty or single-field, "blanked" and "preserved" look identical and the pin proves nothing. Use a multi-field confirm state, assert the specific surviving/cleared fields by name, and prove the close-path assertion red before the fix on whichever runtime you change.

⚠️ The open-path assertions will stay green either way — they are #5835's and are controls here, not evidence. Say so in the PR body.

⚠️ pnpm --filter <pkg> exec vitest / cd packages/x && pnpm exec vitest hit a guard (objectui#3378) — one form refuses loudly (ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL), another silently runs apps/console's 22 files and reports them green. Always run vitest from the repo root, and sanity-check the reported file/test count against the target's own.

⚠️ tsc resolves workspace deps through dist while vitest aliases to src/ — a type-check red can be unbuilt siblings, a real error, or both (a dev tonight got 15 errors: 14 noise + 1 real). Build the closure, then classify each remaining error by name.

Standing rules

Predict direction before running; prove mutations on disk by grepping injected AND separately removed text; print the landing site; assert anchor uniqueness; restore under trap … EXIT INT TERM with a cwd-independent command and confirm git diff HEAD --stat empty. Derive gates by enumerating each CI job's own step list. Cached turbo green is not a measurement — --force. Commit before you ablate. Changeset: a behaviour change on close — state it in words; ⛔ never major.

Collision bounds

packages/app-shell is a large shared package and two other agents have touched it tonight — ⚠️ #6165 is live in packages/app-shell/src/console/home/ (HomeRail.tsx, HomePage.tsx + tests), and #6224's PR #6265 deletes packages/app-shell/src/utils/metadataConverters.ts (draft, not yet landed). Different files is fine; same file is not. Check before editing and ⛔ report any file-level overlap rather than resolving it yourself.

Seven other agents are live elsewhere — ⛔ do not edit packages/plugin-form/**, packages/components/**, packages/plugin-list/**, packages/plugin-detail/**, packages/types/**, packages/core/**, packages/plugin-kanban/**, packages/plugin-map/**, examples/schema-catalog/**, apps/site/**.

⛔ Leave the PR draft — the PM lands it.

---

Generated by Claude Code

[os-litant]

Reclaim — the agent that held this is gone. Back to pm:queue.

domain:ui @ objectui execution seat, PM session session_01Mn4BZ5AVDM81pvfij1WwM9 (os-litant).

⚠️ This reverses a "hands off, live agent" note I posted earlier today. That note is withdrawn. I recorded a handover statement that seven cards had agents still running and set no re-check point on it — a one-time observation treated as a standing state.

Death established on four independent legs

leg	reading
host signal	maintainer confirms the predecessor seat is off shift; a subagent lives inside its parent session
branch movement	claude/issue-6034-confirm-runtime-close-parity @ ef2a3bd8 — unchanged across 75 minutes
content delta	git diff --shortstat origin/main... → empty — head is a baseline main commit
dev report	none — last comment is the 05:56Z claim, ~3.5h ago

This stroke: pm:dispatched → pm:queue, assignee cleared. ⛔ Nothing pushed, nothing lost.

⚠️ Note for the next dispatch

This card was the reason packages/app-shell was treated as occupied all morning, and three other workstreams were bounded away from it on that basis. That constraint is now lifted — but ⚠️ app-shell still carries open draft PR #6283 on views/metadata-admin/previews/block-types.ts. Different area, but check before editing.

⚠️ Brief this one to run path-filtered: whole-package app-shell vitest is ~784 s and holds a shared lock. ✅ pnpm exec vitest run PATHS from the repo root — ⛔ the --filter forms are refused or silently run the wrong package here.

---

Generated by Claude Code