[finding] RecordDetailView carries a second confirm runtime whose options bag no feeder ever fills

Observation recorded while executing the 2026-08-22 ruling on #5205 (keep ConfirmationHandler's options parameter, document its out-of-runner producer). Filed unassigned, observation-class — nothing user-reachable is broken. Recording it here because #5205 closes with that PR and these two facts would otherwise leave the tracker with it; both were noted in that card's thread but never triaged on their own.

Verified on origin/main @ 5da008463.

1. `app-shell` has two near-duplicate confirm runtimes feeding one dialog

packages/app-shell/src/hooks/useConsoleActionRuntime.tsx — confirmHandler typed ConfirmationHandler, sets { open, message, options, resolve }.
packages/app-shell/src/views/RecordDetailView.tsx — a second confirmHandler, declared with the inline shape (message: string, options?: { title?: string; confirmText?: string; cancelText?: string }) rather than the published ConfirmationHandler type, setting the same state shape.

Both feed ActionConfirmDialog. This is the same duplication family as #5610 (RecordDetailView's second copy of the param dialog's action?.title fallback) and #3320 — RecordDetailView re-implementing a shared runtime and then drifting from it.

2. On the `RecordDetailView` path, `options` really is always `undefined`

The #5205 ruling turns on a live producer — handleDeleteView in ObjectView.tsx calls its handler with all three fields localized. RecordDetailView's handler has no such producer: it is passed only as onConfirm={confirmHandler} into the action runner, and the runner invokes the confirm handler with one argument (the structured confirm arm that used to forward a bag was retired in #4314). So its options parameter, and the dialog's reads on that path, are dead-in-practice.

The parameter is therefore live on the ObjectView path and inert on the RecordDetailView path — which is why a whole-repo liveness question about ConfirmationHandler has no single answer, and why #5205's card title read as true from one angle.

Not a request to remove anything

⛔ The ConfirmationHandler signature itself is settled: keep, per the 2026-08-22 ruling on #5205; that is not reopened here. What is unresolved is whether RecordDetailView should keep its own copy of the confirm runtime at all — if it consumed useConsoleActionRuntime instead, both facts above disappear at once, and the inline type would stop shadowing the published one. Shape and appetite are a triage call, not decided here.

Generated by Claude Code

Finding concentration round (triage seat, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24, maintainer-invoked): promoted → pm:queue (domain:ui), Task. Fence: type RecordDetailView's second confirmHandler as the published ConfirmationHandler (killing the inline near-duplicate shape) + pin that both runtimes feed the dialog the same fields. ⛔ Merging the two runtimes into one is a larger refactor — out of scope; report if the typing alignment surfaces a real divergence.

Generated by Claude Code

Claim: PM loop round 38 (refill slot)
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5835-recorddetailview-confirm-handler-type
Worktree: objectui-issue-5835
Domain: domain:ui
File surface: packages/app-shell/src/views/RecordDetailView.tsx + a test pinning both runtimes + a changeset. packages/app-shell/src/hooks/useConsoleActionRuntime.tsx is read-only here.
Container & model: S, mode:subagent, model: opus
Clause-②: no — an inline structural type is replaced by the published type it already structurally matches. Nothing that parses or renders changes its accept/reject behaviour, and no surface widens.

⚠️ SERIAL — read this before your first edit

#5565 is IN FLIGHT inside packages/app-shell/src/** right now. Its surface is apps/console/src/pages/system/ApprovalsInboxPage.tsx plus whatever metadata-read seam it needs — most likely packages/app-shell/src/views/metadata-admin/previews/ (where useObjectFields lives) and packages/app-shell/src/index.ts (it may export that hook).

⛔ Do not touch packages/app-shell/src/index.ts. This card needs no export change; if you believe it does, ⛔ stop and report rather than editing a barrel another card is live in.
⛔ Stay out of packages/app-shell/src/views/metadata-admin/** entirely.

Other concurrent siblings, all disjoint: #4730 (packages/i18n/src/locales/**), #5927 (packages/types/src/zod/**), #5856 (examples/schema-catalog/** + content/docs/plugins/**).

裁决 — triage's fence, carried verbatim

Triage seat, 2026-08-24 (finding concentration round, maintainer-invoked), promoted finding → pm:queue / Task. Verbatim:

Fence: type RecordDetailView's second confirmHandler as the published ConfirmationHandler (killing the inline near-duplicate shape) + pin that both runtimes feed the dialog the same fields. ⛔ Merging the two runtimes into one is a larger refactor — out of scope; report if the typing alignment surfaces a real divergence.

So: two deliverables, one explicit non-deliverable.

RecordDetailView's confirmHandler is declared with the inline shape (message: string, options?: { title?: string; confirmText?: string; cancelText?: string }) instead of the published ConfirmationHandler. Replace the inline shape with the published type.
Pin that both runtimes feed ActionConfirmDialog the same fields.
⛔ Do NOT merge the two runtimes. Consuming useConsoleActionRuntime from RecordDetailView would make both of this card's facts disappear at once, and the card says so — and it is still out of scope. It is a larger refactor on a file (RecordDetailView.tsx) with a recorded history of drifting from shared runtimes (RecordDetailView carries a second copy of the param dialog's dead action?.title fallback #5610, RecordDetailView.modalActionHandler still carries the dead server fallthrough that objectstack#3959 removed from the shared runtime #3320). ⛔ Not this card. ✅ If the typing alignment surfaces a real divergence between the two, that is exactly what triage asked you to report.

⛔ What is NOT reopened

The ConfirmationHandler signature itself is settled — keep, per the maintainer's 2026-08-22 ruling on #5205 (retain the options parameter, document its out-of-runner producer). ⛔ Do not propose removing options, do not re-argue its liveness, and ⛔ do not "simplify" the published type to match what RecordDetailView happens to use.

⚠️ The reason that matters, and it is the subtle part of this card: options is live on the ObjectView path and inert on the RecordDetailView path. handleDeleteView in ObjectView.tsx calls its handler with all three fields localized; RecordDetailView's handler is passed only as onConfirm={confirmHandler} into the action runner, and the runner invokes it with one argument — the structured confirm arm that used to forward a bag was retired in #4314. So a whole-repo liveness question about ConfirmationHandler has no single answer, which is why #5205's card title read as true from one angle and false from another. ✅ Adopting the published type on the inert path is correct precisely because the parameter is live elsewhere: one published type, two call paths, one of which never fills the bag.

PM mechanism assumptions — measure, do not assume

The card is verified at 5da008463 and is a day old on a file that moves. Re-derive all of it on your merge-base: both confirmHandler declarations, the inline shape's exact members, the onConfirm={confirmHandler} call site, and the runner's arity. Report any delta. ⚠️ This seat merged fix(plugin-detail,i18n): localize record:path's container labels and announce its goal terminus #6000 into packages/plugin-detail today and has Approvals drawer summary card can render a field the object declares hidden: true #5565 live in packages/app-shell — assume the file has moved.
⚠️ "Structurally identical" is a claim to verify, not to assume from the card's prose. If the published ConfirmationHandler is wider than the inline shape (extra members, a different return type, a required options), adopting it is not a no-op and the diff must say what changed. If it is narrower in any respect, ⛔ stop and report — that is a real divergence and triage asked for it by name.
The runner's arity is the load-bearing fact for deliverable 2. The card says the runner invokes the confirm handler with one argument. Verify it in the runner's own source rather than inferring it from the handler's signature — a handler that declares two parameters and is called with one is exactly the shape that looks fine at every site and is wrong.
⚠️ A type-only change is enforced only at the type boundary. Under erasure, reverting the declaration cannot move a runtime test. ✅ Say so plainly rather than manufacturing a runtime ablation — this lane accepted exactly that honesty on ObjectViewProps.views[].sort declares direction, but every sort consumer reads order — a host-supplied desc view silently sorts ascending #5293 today. The type-check leg is where the reverse verification lives; the pin in deliverable 2 is what protects the runtime claim.

Verification

Deliverable 2's pin is the one that must be able to fail. "Both runtimes feed the dialog the same fields" is satisfiable by a test that reads neither runtime — assert the fields arriving at ActionConfirmDialog from each path, and show the assertion goes red when one runtime's field set is perturbed. ⛔ A pin that compares two type declarations to each other proves nothing about what reaches the dialog.

Counter-probe required: a field that legitimately differs between the paths (or, if none does, an injected one) must make the pin red — otherwise "the same fields" is satisfiable by both sides being empty.

Reverse-verify at the type boundary, direction predicted before running: restore the inline shape and show type-check goes red (or, if it stays green because the shapes are structurally identical, ⛔ say so — that is the honest reading, and it means the pin in deliverable 2 is carrying the entire change). Prove every mutation on disk by grepping the injected text and separately the removed text. Restore under trap … EXIT INT TERM; confirm git diff HEAD --stat empty afterwards.

⚠️ Run app-shell path-filtered — whole-package vitest there is ~784 s and holds the shared lock; ⛔ do not run it. Use pnpm exec vitest run <paths> from the repo root (this repo's vitest guard refuses the --filter forms). Gates by name with exit codes: pnpm --filter @object-ui/app-shell type-check (⚠️ hyphenated type-check; echo the script name so a zero-match silent pass cannot read as green — and a first RED reading Cannot find module @object-ui/... is the unbuilt-closure signature, not a real failure: build the dependency closure and re-read), the path-filtered vitest, and eslint on changed files with the merge-base delta stated. ⚠️ This repo's eslint spelling is a plain eslint . per package — ⛔ do not add --no-inline-config; it disables legitimate inline disables and produces phantom errors (measured on #5605).

Run node scripts/check-changeset-presence.mjs rather than guessing whether a changeset is owed; empty frontmatter is this repo's "releases nothing" declaration. Draft PR, Fixes #5835. ⛔ Do not mark it ready, ⛔ do not enqueue, ⛔ do not enable auto-merge — the PM lands it. Post the terminal report here (plain-text first-line marker os-dev-report; ⛔ avoid short angle-bracket placeholders in prose — this repo's sanitizer eats them) and return it.

Generated by Claude Code

os-dev-report

{
  "issue": 5835,
  "status": "done",
  "branch": "claude/issue-5835-recorddetailview-confirm-handler-type",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6035",
  "premise_still_valid": true,
  "summary": "Re-derived every fact of the card on merge-base 53dc89db8 (not the card's 5da008463) and all of it held with no delta: both confirmHandler declarations, the inline shape's exact three members, the onConfirm={confirmHandler} call site, and the runner's arity. RecordDetailView's confirmHandler now uses the published ConfirmationHandler instead of an inline re-spelling of its shape, and a new 4-test pin asserts the state ARRIVING at ActionConfirmDialog from BOTH runtimes through one shared double. The two runtimes were NOT merged; useConsoleActionRuntime.tsx and packages/app-shell/src/index.ts are untouched, and nothing under views/metadata-admin/ was read or written. Structural comparison verified rather than inherited: the published type is neither wider nor narrower than the inline shape — same two params, same optionality, same three optional string members, same Promise<boolean> return — so the adoption is a structural no-op and there was no divergence to stop on. The one divergence I did find is next door, in the dialog's CLOSE path, and is filed not fixed.",
  "tests": "All gates at branch head 004b68ed7 (union re-run after the final commit). (1) pnpm --filter @object-ui/app-shell type-check — script name echoed '@object-ui/app-shell@17.6.0 type-check', TYPECHECK_EXIT=0. First run needed the dependency closure built (pnpm --filter '@object-ui/app-shell^...' build, lock VERDICT command-exit 0); an initial failure was the missing-node_modules signature, fixed by pnpm install in the worktree, not a real failure. (2) Path-filtered vitest, pnpm exec vitest run packages/app-shell/src/views/RecordDetailView.confirmRuntimeParity-5835.test.tsx --maxWorkers=2 — VITEST_EXIT=0, 'Test Files 1 passed (1) / Tests 4 passed (4)'. The ~784 s whole-package app-shell suite was NOT run. (3) pnpm exec eslint on the two changed files, plain spelling with no --no-inline-config — ESLINT_EXIT=0, warnings only. (4) node scripts/check-changeset-presence.mjs — exit 0, empty frontmatter accepted as the explicit 'releases nothing' exemption. Merge-base delta: 53dc89db8, two files plus the changeset. COUNTER-PROBE (deliverable 2's pin must be able to fail), both predicted 3-red/1-green before running and both observed exactly that: probe A dropped `options` from RecordDetailView's state literal — 3 failed, 1 passed, \"expected [ 'message', 'open', 'resolve' ] to deeply equal [ 'message', 'open', 'options', ...(1) ]\"; probe B injected an extra field — 3 failed, 1 passed, 'expected [ Array(5) ] to deeply equal ...'. In both, the single survivor is the console-runtime test (the untouched side), so the pin discriminates rather than failing wholesale. Probe A leaves type-check GREEN (ConfirmDialogState.options is optional), which is the gap the pin fills. Vacuity closed by writing the expected field set out as a literal tied to what ActionConfirmDialog.tsx reads, so 'both sides empty' fails. REVERSE VERIFICATION at the type boundary, direction predicted BEFORE running: restore the inline shape, expect GREEN because the shapes are structurally identical. Observed GREEN, REV_TYPECHECK_EXIT=0 — saying so plainly as instructed: the deliverable-2 pin carries the entire enforceable change; adopting the published type buys future coupling, not a gate today. No runtime ablation was manufactured for a type-only change (erasure); instead the erasure claim was MEASURED — transpiling RecordDetailView.tsx before/after with the workspace esbuild gives byte-identical output, 64527 bytes both sides, which is also what makes the empty-frontmatter changeset correct rather than convenient. Every mutation proved on disk with injected text and removed text grepped SEPARATELY (probe A 1/0, probe B 1/0, reverse 1/0); all restored under trap ... EXIT INT TERM; restored file byte-identical to the pre-probe copy per diff -q; injectedDrift5835 marker greps absent; git diff HEAD --stat carries no probe residue. Runner arity verified in the runner's OWN source, not inferred: packages/core/src/actions/ActionRunner.ts calls `await this.confirmHandler(this.evaluator.evaluate(action.confirmText) as string)` — one argument, confirming the card. The pin covers BOTH arities, since the second parameter is live through the ObjectView door and inert through the runner door.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #6034 (finding, unassigned, domain:ui): app-shell's two confirm runtimes reset confirmState differently when the dialog CLOSES — useConsoleActionRuntime replaces the whole state with { open: false, message: '' } (blanking message and dropping options/resolve), while RecordDetailView spreads and flips one flag, retaining all three. Two observable consequences, neither confirmed against a running app: a possible blank description frame during Radix's exit animation on the hook's path, and a retained stale resolve on the view's path (not a correctness bug today — the dialog settles the promise itself before onOpenChange). Same drift family as #5610/#3320. Neither side is obviously correct, so picking a winner is a call rather than a cleanup; out of this card's fence, which is the OPEN path."
  ]
}

Notes for the PM, outside the JSON:

Draft PR left as draft. Not marked ready, not enqueued, no auto-merge — refactor(app-shell): type RecordDetailView's confirm handler as the published ConfirmationHandler #6035 is yours to land. CI convergence was not waited on, per the standing contract; gate status at report time is the local union above, all green at 004b68ed7.
The serial fence was respected. packages/app-shell/src/index.ts needed no change and was not touched; packages/app-shell/src/views/metadata-admin/ was neither read nor written; useConsoleActionRuntime.tsx stayed read-only, which is also why both counter-probes perturbed the RecordDetailView side rather than the hook.
On mechanism assumption 2: no delta to report. The card's prose was accurate on every measured point, including the runner's one-argument arity.

Generated by Claude Code

PM review — ACCEPT

PR #6035, head 004b68ed7, merge-base 53dc89db8. Gate read at the usual mark.

Fences — all three held, checked directly

git diff --name-only returns nothing for packages/app-shell/src/index.ts, packages/app-shell/src/hooks/useConsoleActionRuntime.tsx, or anything under packages/app-shell/src/views/metadata-admin/. Three files changed, all inside the declared surface. ⚠️ That mattered this round: #5565 was live in packages/app-shell while you worked, and it landed a page-local seam precisely so it would not have to touch that barrel either. Two concurrent cards in one package, zero contention.

The honesty this card was really testing

I told you a type-only change is enforced only at the type boundary, that reverting it might well leave type-check green, and that if so you must say so rather than manufacture a runtime ablation. You did better than say so — you measured it:

restore the inline shape, expect GREEN because the shapes are structurally identical. Observed GREEN, REV_TYPECHECK_EXIT=0 — saying so plainly as instructed: the deliverable-2 pin carries the entire enforceable change; adopting the published type buys future coupling, not a gate today.

the erasure claim was MEASURED — transpiling RecordDetailView.tsx before/after with the workspace esbuild gives byte-identical output, 64527 bytes both sides, which is also what makes the empty-frontmatter changeset correct rather than convenient.

✅ Turning "types are erased, so no runtime ablation applies" from an appeal to a language rule into a byte count is the strongest form of that argument, and it does double duty: it is simultaneously the justification for the changeset declaring nothing. ✅ And stating that the type adoption buys future coupling rather than a gate today is the accurate description of what this PR is worth — a smaller, truer claim than "fixed the type".

Assumption 2 — verified, not inherited, and the answer was "no-op"

the published type is neither wider nor narrower than the inline shape — same two params, same optionality, same three optional string members, same Promise<boolean> return

That was the branch point of my dispatch: wider meant the diff owed an explanation, narrower meant stop and report. It was neither, so the adoption is a structural no-op and there was no divergence to stop on. ✅ Checking before adopting is what makes "structurally identical" a reading rather than the card's prose repeated back.

Assumption 3 — the runner's arity, from the runner's own source

packages/core/src/actions/ActionRunner.ts calls await this.confirmHandler(this.evaluator.evaluate(action.confirmText) as string) — one argument

✅ Exactly as instructed: read in the runner, not inferred from the handler's signature. A handler declaring two parameters and called with one is the shape that looks fine at every site and is wrong, and now it is measured. ✅ And the pin covers both arities, since the second parameter is live through the ObjectView door and inert through the runner door — which is the whole reason ConfirmationHandler's liveness has no single answer.

The pin discriminates, and probe A is the sharpest reading

Both counter-probes predicted 3-red/1-green before running and observed exactly that, with the single survivor being the console-runtime test — the untouched side. ✅ That is what proves the pin discriminates rather than failing wholesale; a uniform red would have proved nothing.

✅ And probe A leaves type-check GREEN, because ConfirmDialogState.options is optional. That one sentence is the justification for deliverable 2 existing at all: dropping options from the state literal is a real behaviour change that the type system cannot see, so the only thing that can catch it is a pin on what arrives at the dialog. ⛔ A pin comparing two type declarations to each other — the thing I forbade — would have been green through probe A.

✅ Vacuity closed the right way: the expected field set is written out as a literal tied to what ActionConfirmDialog.tsx reads, so "both sides empty" fails rather than passes.

⛔ The non-deliverable held, and the divergence triage asked for was found

The two runtimes were not merged. And the typing alignment did surface a real divergence — filed as #6034, not fixed:

the two confirm runtimes reset confirmState differently when the dialog CLOSES — useConsoleActionRuntime replaces the whole state with { open: false, message: '' } (blanking message, dropping options/resolve), while RecordDetailView spreads and flips one flag, retaining all three.

✅ That is exactly the outcome triage's fence anticipated — "report if the typing alignment surfaces a real divergence" — and the disposition is right on all three counts: it is on the CLOSE path while this card's fence is the OPEN path; neither side is obviously correct, so picking a winner is a call rather than a cleanup; and the two observable consequences are stated as unconfirmed against a running app (a possible blank description frame during Radix's exit animation on the hook's path; a retained stale resolve on the view's path, explicitly not a correctness bug today because the dialog settles the promise itself before onOpenChange). ✅ Recording what you did not verify is what makes the rest of the finding trustworthy. Same drift family as #5610 / #3320, correctly named.

One small thing, correctly diagnosed

The first type-check failure was the missing-node_modules signature in a fresh worktree, not the unbuilt-closure Cannot find module @object-ui/... one — different cause, different fix (pnpm install, then build the closure). ✅ Distinguishing the two rather than lumping them under "the usual red" is why the second run's green means something.

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] `RecordDetailView` carries a second confirm runtime whose `options` bag no feeder ever fills #5835

1. `app-shell` has two near-duplicate confirm runtimes feeding one dialog

2. On the `RecordDetailView` path, `options` really is always `undefined`

Not a request to remove anything

⚠️ SERIAL — read this before your first edit

裁决 — triage's fence, carried verbatim

⛔ What is NOT reopened

PM mechanism assumptions — measure, do not assume

Verification

PM review — ACCEPT

Fences — all three held, checked directly

The honesty this card was really testing

Assumption 2 — verified, not inherited, and the answer was "no-op"

Assumption 3 — the runner's arity, from the runner's own source

The pin discriminates, and probe A is the sharpest reading

⛔ The non-deliverable held, and the divergence triage asked for was found

One small thing, correctly diagnosed

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] RecordDetailView carries a second confirm runtime whose options bag no feeder ever fills #5835

Description

1. app-shell has two near-duplicate confirm runtimes feeding one dialog

2. On the RecordDetailView path, options really is always undefined

Not a request to remove anything

Activity

claude commented on Aug 24, 2026

yinlianghui commented on Aug 24, 2026

⚠️ SERIAL — read this before your first edit

裁决 — triage's fence, carried verbatim

⛔ What is NOT reopened

PM mechanism assumptions — measure, do not assume

Verification

yinlianghui commented on Aug 24, 2026

yinlianghui commented on Aug 24, 2026

PM review — ACCEPT

Fences — all three held, checked directly

The honesty this card was really testing

Assumption 2 — verified, not inherited, and the answer was "no-op"

Assumption 3 — the runner's arity, from the runner's own source

The pin discriminates, and probe A is the sharpest reading

⛔ The non-deliverable held, and the divergence triage asked for was found

One small thing, correctly diagnosed

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] `RecordDetailView` carries a second confirm runtime whose `options` bag no feeder ever fills #5835

1. `app-shell` has two near-duplicate confirm runtimes feeding one dialog

2. On the `RecordDetailView` path, `options` really is always `undefined`