ConfirmationHandler's options parameter is declared-but-never-produced after the structured-confirm retirement

[os-support-ai]

Observation recorded while implementing #4314 (retire the structured confirm arm — maintainer ruling 2026-08-17). Filed unassigned per the PM's re-scope order on that card; observation-class, nothing user-reachable is broken.

What

ConfirmationHandler (packages/core/src/actions/ActionRunner.ts, the public handler type consumers pass to setConfirmHandler) declares an optional second parameter:

export type ConfirmationHandler = (message: string, options?: {
 title?: string;
 confirmText?: string;
 cancelText?: string;
}) => Promise<boolean>;

The only producer of that argument was the structured confirm arm's forwarding inside ActionRunner's precedence read — retired in #4314. The runner now invokes confirmHandler(message) with one argument, always. The signature was deliberately left untouched by the retirement PR: packages/app-shell was held by another session that round, and narrowing a public handler type is its own contract call.

Consumers still reading the parameter

• packages/app-shell/src/views/ActionConfirmDialog.tsx renders state.options?.confirmText with a translation fallback (actionConfirm.confirm).
• packages/app-shell/src/hooks/useConsoleActionRuntime.tsx implements the handler as (message, options).

With no producer, options is now always undefined at runtime; those reads are dead-in-practice but type-check forever — the declared surface outlives the data that fed it.

Why this is the ADR-0049 shape

Declared-but-never-produced public surface: the same enforce-or-remove doctrine the #4314 ruling applied to the arm itself. Two ways it can resolve, both contract calls, neither decided here:

1. Remove: retire the options parameter from ConfirmationHandler; app-shell's reads fold to their existing fallbacks. Narrowing a public handler type — needs the usual consumer radius over @object-ui/core dependents.
2. A producer returns: the Structured confirm.message outranks confirmText in ActionRunner but has no translation-bundle key — and the types deprecate authors INTO it #4314 reopen condition (real demand brings the structured arm back WITH bundle keys _actions.{name}.confirm.* designed in) would make the dialog title/button labels translatable and options live again.

Whoever picks this up should re-check session holds on packages/app-shell first.

---

Generated by Claude Code

[os-warren]

Concentrated finding round #4 — first-touch grading (triage seat, session session_01JEhkB6ShK2HHDzozy7Qwgz): promoted to pm:queue, with a Clause-② flag for the dispatching seat.

Verified on origin/main @ 12841b6: the optional options bag is declared at packages/core/src/actions/ActionRunner.ts:462-466; the sole runner call site at :988-990 passes one argument (adjacent comment cites the #4314 retirement, landed as PR #5209); the dead-in-practice readers are packages/app-shell/src/views/ActionConfirmDialog.tsx:58 and packages/app-shell/src/hooks/useConsoleActionRuntime.tsx:190.

Why queue, not decision: the maintainer already ruled the structured-confirm retirement (#4314, 2026-08-17); this vestigial parameter was deferred for a scheduling reason (app-shell held by another session), not a product one — completing a standing ruling is dispatchable. #4314's reopen condition survives this removal.

⚠️ Clause-② note for the claim: narrowing a published callback type in @object-ui/core makes existing two-parameter handler implementations fail to type-check — a breaking change on the compile contract of a published package (no runtime accept/reject change). The claim comment must declare Clause-②: yes per the intake gate, the PR needs a breaking-annotation changeset, and the dev should sweep the consumer radius. Dispatch must also re-check session holds on packages/app-shell first, per the body. Serial: ActionRunner.ts churned twice this cycle (#5209, #5218), both merged; no open PR. Size suggestion: S–M, opus.

---

Generated by Claude Code

[claude]

Claim: PM loop round 21
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5205-confirmation-handler-options
Worktree: objectui-issue-5205
Domain: repo:objectui
File surface: packages/core/src/actions/ActionRunner.ts + its tests (stop on breach; explain in the report)
Container & model: M, mode:subagent
Clause-②: yes — triage flagged this for the dispatching seat, and I am carrying the flag forward rather than resolving it: ConfirmationHandler is the public handler type consumers pass to setConfirmHandler, so narrowing its signature is a published-surface change. The dispatch requires the dev to measure the consumer population before removing anything and to stop and report if any external shape depends on it.

Serial constraints cleared: ⚠️ PR #5478 touches packages/core/src/utils/column-identity.ts — a different file, and it is in the merge queue. No other in-flight card holds packages/core/src/actions/**.

⛔ Governed-surface check run before dispatch: the declared surface hits none of AGENTS.md / CLAUDE.md / .claude/** / docs/adr/** / skills/**. If the work turns out to need one, stop and report — published skills/** ownership is an open question with the maintainer and no seat may land it.

---

Generated by Claude Code

[claude]

os-dev-report

Status: needs_decision — STOPPED AT ZERO COMMITS. The measurement the dispatch
ordered contradicts this card's central premise, so the 回翻条款 applies: I report the
fork rather than re-rule it.

The premise is false: options has a live producer

The card states "The only producer of that argument was the structured confirm arm's
forwarding inside ActionRunner's precedence read" and concludes "With no producer,
options is now always undefined at runtime."

That is true only inside ActionRunner. It is false for the repo. A second producer
has existed all along, and it bypasses the runner entirely:

packages/app-shell/src/views/ObjectView.tsx:1397

const confirmed = await confirmHandler(
 t('console.objectView.deleteViewConfirm', { name: viewLabel }),
 {
 title: t('console.objectView.deleteViewTitle'),
 confirmText: t('console.objectView.delete'),
 cancelText: t('console.objectView.cancel'),
 },
);

That confirmHandler is destructured at ObjectView.tsx:911 from
useConsoleActionRuntime, whose ConsoleActionRuntime.confirmHandler is declared
ConfirmationHandler at useConsoleActionRuntime.tsx:78. So this is the published type
being invoked with a fully-populated, fully-localized options bag.

It is reachable UI, not dead code: the enclosing handleDeleteView
(ObjectView.tsx:1389) is wired at ObjectView.tsx:2472
(onDeleteView={isAdmin ? handleDeleteView : undefined}) and :2486
(onDelete={handleDeleteView}) — the admin "delete saved view" confirmation.

git blame: the call and its three localized keys date to 2026-08-10 (5bfaabde0,
36ae2705b4) — they predate both the #4314 ruling (2026-08-17) and the triage
(2026-08-19). Nothing regressed; the search was simply scoped to the runner.

Consequence: removing options does not delete inert surface. It silently deletes a
working feature — the delete-view dialog would lose its title and both button labels and
fall back to the generic actionConfirm.* strings.

Consumer census (with counter-probes)

Site	Role	Reads/writes options
core/.../ActionRunner.ts:988	producer (runner)	no — passes 1 arg
app-shell/.../ObjectView.tsx:1397	producer	writes all 3 fields, localized
app-shell/.../useConsoleActionRuntime.tsx:190	implementer (message, options)	reads — forwards to setConfirmState :192
app-shell/.../RecordDetailView.tsx:494	implementer (message, options?: …)	reads — forwards to setConfirmState :496
app-shell/.../ActionConfirmDialog.tsx:50,55,58	terminal reader	reads title, cancelText, confirmText
react/.../useActionRunner.ts:26, react/.../ActionContext.tsx:35	re-declares onConfirm?: ConfirmationHandler	pass-through
components/.../page-header-action-i18n.test.tsx:83	test double	no

Counter-probe A (method sensitivity). Same grep applied to ToastHandler — a sibling
whose options bag is known-live — finds its two-argument producers at
ActionRunner.ts:1136 and :1151. The method detects two-argument calls; the
non-zero result above is not a search artifact.

Counter-probe B (positive control on the same lines). message — indisputably live —
travels through identical syntax at the identical call sites:
setConfirmState({ open: true, message, options, resolve }) at :192 and :496,
rendered at ActionConfirmDialog.tsx:51 (message) beside :50/:55/:58 (options).
There is no methodological asymmetry that could make message real and options
spurious — they are read by the same component from the same state object.

Reverse-verification (ablation)

Narrowed the type to (message: string) = Promise< boolean > in
packages/core/src/actions/ActionRunner.ts, rebuilt @object-ui/core, type-checked.

⚠️ First ablation run was a FALSE GREEN. I edited src only and got 0 errors. Before
reading that as a result I checked whether the mutation had reached the consumer:
packages/core/dist/actions/ActionRunner.d.ts:393 still carried the two-parameter form.
app-shell resolves @object-ui/core through dist/index.d.ts →
dist/actions/index.d.ts:8 → ActionRunner.js, so the un-rebuilt leg measured the
unmutated tree. Rebuilding core and proving the narrowed form present at
dist/actions/ActionRunner.d.ts:393 produced the real result.

Predictions were recorded before the run:

#	Predicted	Observed
1	ObjectView.tsx TS2554 "Expected 1 arguments, but got 2"	✅ ObjectView.tsx(1399,13): error TS2554: Expected 1 arguments, but got 2.
2	useConsoleActionRuntime.tsx:190 fails — 2 required params vs 1-param target	✅ TS2345 + TS7006 ×2 (richer than predicted)
3	RecordDetailView.tsx:494 no error (its options?: is optional)	✅ absent from output
4	packages/core stays clean	✅ 0 errors, exit 0

Baseline (closure built, unmutated): 0 errors, exit 0.
Ablated: 4 errors, exit 2 — all in packages/app-shell, none in packages/core.

src/hooks/useConsoleActionRuntime.tsx(190,59): error TS2345: Argument of type '(message: any, options: any) =' Promise< boolean > 'is not assignable to parameter of type' ConfirmationHandler'.
src/hooks/useConsoleActionRuntime.tsx(190,60): error TS7006: Parameter 'message' implicitly has an 'any' type.
src/hooks/useConsoleActionRuntime.tsx(190,69): error TS7006: Parameter 'options' implicitly has an 'any' type.
src/views/ObjectView.tsx(1399,13): error TS2554: Expected 1 arguments, but got 2.

Restored: source reverted, core rebuilt on the restore leg too, narrowed form proven
absent from dist, app-shell type-check back to 0 errors / exit 0,
git status --porcelain empty, git diff origin/main...HEAD empty.

The published-surface question the dispatch asked me to answer

The dispatch asked whether "an implementer who wrote (msg, opts) = … still type-checks
against a one-parameter type" makes removal safe. Measured answer: no — the premise is
half-true, and the half that is false is the common case.

• Bare form (message, options) = … (contextually typed, both params required):
  rejected. A source signature may not have more required parameters than its
  target. Observed as TS2345 plus two TS7006 implicit-any errors under
  noImplicitAny. This is the natural way to write it, and it is what this repo's own
  useConsoleActionRuntime.tsx:190 does.
• Explicitly-optional form (message: string, options?: { … }) = …: accepted —
  optional params do not count toward required arity. RecordDetailView.tsx:494 survives.

So the escape hatch exists but is not the default; an external implementer who wrote the
obvious two-parameter handler gets a compile break. @object-ui/core is public
(private unset, v17.6.0, files: ["dist", …]) and the type is reachable from the
package entry through the re-export chain above — so this is a genuine narrowing of a
published .d.ts.

Precedent in this exact file: useConsoleActionRuntime.tsx:82-87 documents
objectui#4040, where a one-parameter declaration was a narrower restatement of a
two-parameter implementation and nothing caught it. Removing options would reintroduce
that same shape deliberately.

Why I stopped

Three independent stop conditions from the dispatch all fired:

1. Premise falsified (回翻条款) — a live producer exists; stop at zero commits.
2. "If any consumer reads options … STOP and report" — three do, and one is a
   terminal render of localized strings.
3. File-surface breach — my declared surface is
   packages/core/src/actions/ActionRunner.ts + its tests. Every compile break lands in
   packages/app-shell (4 errors, 2 files) and the feature repair would be a third file.
   packages/core alone stays green, which is exactly why a runner-scoped search read
   this as a clean removal.

I did not add a pin test or a "keep and document" comment either — choosing that
resolution would itself be re-ruling the card, which the 回翻条款 forbids.

For the maintainer

The card's option 2 ("a producer returns") is not a future condition — a producer never
left. Suggested re-triage:

• Recommended — close as not-a-defect / re-scope to documentation. options is live,
  localized and user-reachable. The correct minimal follow-up, if any, is a comment at
  ActionRunner.ts:462 naming the out-of-runner producer so the next liveness sweep does
  not re-derive "no producers" from the runner alone.
• Not recommended — remove. Breaks a shipped admin feature's localization, breaks
  app-shell's compile, and narrows a published .d.ts against implementers who wrote
  the natural two-parameter form.

Two secondary observations, recorded rather than filed (both are facets of this card's own
subject, and filing them while the card is in decision would just be noise):

1. RecordDetailView.tsx:494's handler is fed only by the runner, so its options
   is in fact always undefined — the parameter is live on the ObjectView path and
   inert on the RecordDetailView path. The card's "dead-in-practice" reading is correct
   for exactly one of the two implementations.
2. useConsoleActionRuntime.tsx:190 and RecordDetailView.tsx:494 are near-duplicate
   confirm-runtime implementations feeding the same ActionConfirmDialog.

Branch claude/issue-5205-confirmation-handler-options was pushed as an empty write-route
probe and carries zero commits; no PR opened.

---

Generated by Claude Code

---

Generated by Claude Code

[claude]

回翻条款 — premise falsified. Moving to needs-user-decision.

PM round 21, session session_01RV6yuVCxymHYE16PL9vQkE. ⛔ Not a ruling — reporting the fork. Zero commits; nothing was changed.

options is not declared-but-never-produced. It is produced outside ActionRunner: packages/app-shell/src/views/ObjectView.tsx:1397 calls confirmHandler(message, {title, confirmText, cancelText}) with all three fields localized through t(), and ActionConfirmDialog.tsx:50/55/58 renders them. The handler is typed ConfirmationHandler at useConsoleActionRuntime.tsx:78, so the published type is invoked with a populated bag. It is reachable UI, not dead code — handleDeleteView is wired at ObjectView.tsx:2472 (onDeleteView={isAdmin ? handleDeleteView : undefined}) and :2486.

Nothing regressed. git blame dates the call and its three i18n keys to 2026-08-10 (5bfaabde0, 36ae2705b4) — before the #4314 ruling (2026-08-17) and before the triage (2026-08-19). The card's and the grading's shared error was scope: the search was runner-scoped, and the producer is one package over. Worth keeping as a method note — "no producer" is only as wide as where you looked.

Removing it would delete a working feature, not inert surface: the delete-view dialog loses its title and both button labels, falling back to generic actionConfirm.* strings; app-shell fails to compile in two files outside the declared surface; and a published .d.ts narrows.

The published-surface question I put to the dev, answered

My dispatch asked whether TypeScript's tolerance of extra parameters makes the removal safe. Half-true, and the false half is the common case: a bare (msg, opts) => … is rejected — two required parameters cannot satisfy a one-parameter target — while only the explicitly-optional (msg, opts?: {…}) form survives. So removal is a genuine breaking narrowing for the natural spelling.

In-file precedent the dev found: useConsoleActionRuntime.tsx:82-87 carries a comment about objectui#4040, where a one-parameter declaration was a narrower restatement of a two-parameter implementation and nothing caught it. Removing options would deliberately reintroduce that shape.

Method note worth keeping — a false green, caught

The dev's first ablation leg edited src only and produced 0 errors. Rather than reading that as a result, it checked reachability and found packages/core/dist/actions/ActionRunner.d.ts:393 still carrying the two-parameter form: app-shell resolves @object-ui/core through dist, so the un-rebuilt leg had measured the unmutated tree. It rebuilt, proved the narrowed form present in dist, and only then re-ran — 4 errors, all in app-shell, none in packages/core. That distribution is exactly why a runner-scoped search reads this as a clean removal.

The fork

The card's two options no longer partition the space: its option 2 ("a producer returns") is not a future condition — a producer never left.

• A (dev's recommendation) — keep the parameter, and add a comment at ActionRunner.ts:462 naming the out-of-runner producer so the next liveness sweep does not re-derive "no producers" from the runner alone.
• B — remove it anyway: needs a new dispatch covering packages/app-shell, replacement for three localized strings, and a breaking-change changeset. Deletes working localization for no measured benefit.
• C — split: RecordDetailView.tsx:494's handler is fed only by the runner, so its options really is always undefined. That half is genuinely inert.

⛔ I am not choosing. Returning unassigned.

Two things the dev deliberately did not file, recording them here instead because both are facets of this card while it is in decision: the RecordDetailView.tsx:494 inert half above, and the fact that useConsoleActionRuntime.tsx:190 and RecordDetailView.tsx:494 are near-duplicate confirm runtimes feeding one dialog — a deduplication candidate whose right shape depends on how you rule here.

---

Generated by Claude Code