Repository navigation
app-shell: a type: 'flow' action's button starts its flow through POST /automation/:name/trigger, not the action door — decide whether the button routes through POST /actions/:object/:action so the action's own server-side gates apply #12037
Description
Filing gate: ③ — a task the maintainer's ruling assigns: objectstack-ai/objectstack#22407 ruling A (6074046403, maintainer 「同意」 2026-10-09T04:05Z).
Reader: objectui triage (routing and grading), then the execution seat of the lane it routes to. This card asks for a lane decision; it is not a dispatch order.
Dedupe: two semantic searches of objectstack-ai/objectui (flow action button, trigger route, action door, requiredPermissions, 403 elevated flow) returned 6 hits, all closed and none on this question (#11779, #2958, #9973, #7234, #4421; #2958 twice). One search of objectstack-ai/objectstack returned 15 hits; the only related ones are objectstack-ai/objectstack#22407 and objectstack-ai/objectstack#22310, the parent rulings.
The ruling's words (quoted, not translated)
The console's flow-action button route is not part of this ruling: under A both doors answer alike, and whether objectui routes the button through the action door so the action's own gates apply is a UI card after landing.
Ruling A landed in objectstack-ai/objectstack#22424 (merge commit c572fe2a36, 2026-10-09T07:11Z), which closes objectstack-ai/objectstack#22407. Every door that starts a flow by name — the trigger route, a type: 'flow' action (REST and MCP run_action) and a declared type: 'flow' endpoint — now refuses a non-system caller a flow declared runAs: 'system' whose type is autolaunched, record_change or schedule (403 PERMISSION_DENIED, nothing runs).
What the console does today (read at objectui origin/main 8f815f4f)
Both flow-action handlers call the trigger route with the action's target. Neither calls the action door:
packages/app-shell/src/hooks/useConsoleActionRuntime.tsx:589–624(flowHandler):POST ${baseUrl}/api/v1/automation/${flowName}/trigger.packages/app-shell/src/views/RecordDetailView.tsx:1118–1140(flowHandler): the same route.
The action door, POST /api/v1/actions/:object/:action (dispatchFlowAction in @objectstack/runtime), answers more than the trigger route does for the same click:
- the action's declared
requiredPermissions, enforced on the server (ADR-0066 D4: a dual-surface gate whose UI half only hides the button); - the caller-scoped subject-record load and its
recordLoadDeniedverdict.
On the trigger route, none of these runs. Under ruling A, the elevated-start refusal now answers alike at both doors. These other gates still differ.
The question for the lane
Should the console's flow-action buttons call the action door, so that each server-side gate the action declares applies to the click? Or does the trigger route stay, with the reason recorded?
Measure before deciding:
- whether the action door's response shape (the ADR-0112 envelope, a paused screen run's resume handle) carries everything both handlers read today, including FlowRunner's resume and the refused-end toast;
- how the action door identifies the action for related-list row actions that retarget the flow at a child record.
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 9, 2026
Triage: first grade,
priority:p2·domain:ui·area:workflow·bug·pm:queue. Direction: the flow-action button goes through the action door, so the action's own server-side gates apply (ADR-0066 D4); measure firstTriage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-09T07:54Z. ⛔ Not a claim, ⛔ not a dispatch.Triage: lands in
packages/app-shell(useConsoleActionRuntime.tsxandRecordDetailView.tsx, the twoflowHandlers) ⇒domain:ui.requiredPermissionsa dual-surface gate: the UI hides the button, and the server enforces the gate at the action door.security: the trigger route stays reachable directly whatever the console does, and ruling A already closed the elevation class at every door. This card makes the console honour each action's own declaration and its loud refusal. It does not close a bypass.domain:cli, and block this card on it. ⛔ Don't keep the trigger route as a workaround without recording why.requiredPermissionsthe caller lacks is refused by the server on click, with the action door's code;objectstack-fleet commentedon Oct 9, 2026
Claim: PM loop round 17
Session:
session_01MgfduSkFrfM3eorB3UGfAUAccount:
os-billBranch:
claude/issue-12037-flow-action-doorWorktree:
objectui-issue-12037Domain:
domain:uiSeat:
domain:ui#2Scope of this claim: triage's direction (
6076847418). The console's flow-action buttons start their flow through the action door,POST /api/v1/actions/:object/:action, so that the action's own server-side gates apply to the click (ADR-0066 D4). Measure first:domain:cliand moves this card topm:blockedon it. ⛔ The trigger route is not kept as a workaround.File surface (as read on
mainea79b77; the dev re-reads it):packages/app-shell/src/hooks/useConsoleActionRuntime.tsx:flowHandler(:592, the trigger-route call at:624);packages/app-shell/src/views/RecordDetailView.tsx:flowHandler(:1123, the trigger-route call at:1140);.changeset/12037-*.md.⛔ Not on it:
@objectstack/runtimeand anything else in objectstack, including the action door and the trigger route themselves;packages/i18nkey;packages/app-shell/src/views/ObjectView.tsx, held by objectui#5144's fix round.Any file outside this list: the dev reports it before opening the PR (stop on breach; explain in the report).
Container & model:
S,mode:subagent,model: opus(dispatch-gates --tier --repo objectstack-ai/objectuiover these paths: no path-derived mandate; default tier)Clause-②: no
Responsibility:
objectui console: a type:'flow' action's button starts its flow through the trigger route, so the action's declared requiredPermissions server gate and its caller-scoped subject-record load never run for that click | the action door POST /api/v1/actions/:object/:action already served by the framework | every console user who clicks a flow actionThread-read: 6076847418
Serial constraints cleared: no open objectui PR and no in-flight claim touches either handler's file (read 2026-10-09T08:24Z). The
area:workflowaxis has nothing else in flight from this seat.Why
Clause-②: no: the console changes which framework door its own click calls. No published prop, export or contract changes (triage6076847418: not a fork; the governing text answers it).Generated by Claude Code
objectstack-fleet commentedon Oct 9, 2026
os-dev-report
{ "issue": 12037, "status": "needs_decision", "branch": "claude/issue-12037-flow-action-door", "pr": null, "session": "session_01MgfduSkFrfM3eorB3UGfAU", "premise_still_valid": true, "summary": "Stopped before the first edit, as the dispatch directs when the action door lacks something the console needs. The door serves every flow click that names a DECLARED action, and its answer carries every field both handlers read (H1 confirmed, mapping below). What it cannot serve is a flow click that names NO declared action: the /actions handler refuses those 404 'Action X on Y has no declaration' (ADR-0110 D3, no opt-out). The console's one shared flowHandler receives such clicks from two spec-legal surfaces: an inline page `action:button` (and its `action:icon`/`action:group`/`action:menu` siblings) with `actionType: 'flow'` and `target`, whose `name` the spec row `ActionButtonPropsSchema` declares OPTIONAL ('an inline page button is not a registered object action'); and a dashboard header action `{ actionType: 'flow', actionUrl }` (`DashboardHeaderActionSchema`), which `DashboardRenderer` turns into `{ name: actionUrl, type: 'flow', target: actionUrl }`. Routing every click through the door would refuse both; routing only declared clicks needs a provenance signal the handler does not have, which is the partial route the dispatch rules out. No code, no PR; the empty branch is pushed at main ea79b7777 and the worktree is removed.", "measurement_answers": { "q1_door_answer_carries_what_handlers_read": "YES for declared actions. Door read at objectstack origin/main 081e6a09, which contains c572fe2a36 (`git merge-base --is-ancestor c572fe2a36 REF` exit 0); `dispatchFlowAction` (action-execution.ts) and the flow arm of `handleActionsRequest` (domains/actions.ts). Field by field: (1) transport: success is `deps.success(result)`, refusals are `deps.error(...)`, the same DomainHandlerDeps builders the trigger route's `respondToFlowTrigger` uses, so the ADR-0112 envelope is identical. (2) paused screen run, FlowRunner's resume handle: `dispatchFlowAction` returns the raw AutomationResult; a paused result `{ success: true, status: 'paused', runId, screen, flowLabel }` is neither a `classifyFlowRefusal` row (it names the paused state first) nor caught by the residual `success === false` arm, so it lands at `data.runId` / `data.screen` / `data.flowLabel`, where `interpretFlowResponse` reads them today. (3) refused end (the refused-end notice): `{ success: true, status: 'refused', refusalMessage }` passes through unchanged to `data.status` / `data.refusalMessage`. (4) done: `data.successMessage` / `data.flowLabel` unchanged. (5) ran and failed: `FlowActionRefusal`, served as `deps.error(message, 400, { code: 'FLOW_FAILED', errorMessage, summary })`, gives `error.code === 'FLOW_FAILED'` and `error.details.errorMessage`, the two slots `interpretFlowResponse` reads; only `error.message` wording differs (door: 'Flow NAME failed: ERROR'), and the console prefers `details.errorMessage`. (6) never-dispatched 404 / 409 FLOW_DISABLED / 422 FLOW_NO_START_NODE / 422 FLOW_INPUT_SCHEMA_INVALID and the ruling-A 403 PERMISSION_DENIED come from the same shared table and admission rule at both doors. (7) an unclassified `success: false` answers 200 inner-failure at the trigger route and 400 FLOW_FAILED at the door; `interpretFlowResponse` classifies both as `failed`, `retryable: false`. New at the door, the point of this card: 403 PERMISSION_DENIED from `actionPermissionError` (message 'Action NAME on OBJ requires capability [..] — caller is missing [..]', code derived from the status by `standardErrorCodeForHttpStatus`), 409 ACTION_DISABLED, 400 'Invalid action params' (ADR-0104 D2; `recordId` / `objectName` / `_selectedIds` are spec built-ins, so the runtime handler's `params.recordId` mirror is admitted), 404 RECORD_NOT_FOUND for a subject row the caller cannot read. `interpretFlowResponse` turns each into `kind: 'failed'` with the envelope's message, so the runner toasts the refusal. Not carried: the flow NAME. FlowRunner builds its resume URL from the handler's client-side `action.target`; the runner never interpolates a flow target (only url/api targets), so for a declared action this equals the declaration's `target` that the door dispatched. Resume admission reads the run's trigger identity, and both doors pass `userId: ec.userId` to `execute`.", "q2_related_list_row_action_retargeting_a_child": "`RelatedRecordActionsBridge.runRowAction` derives row actions from the CHILD object's declared actions (`deriveActions(childDef, ...)`) and dispatches `{ ...action, objectName: CHILD, recordId: String(row.id), params: { _rowRecord: row } }` through RecordDetailView's ActionProvider. Through the door, that click is `POST /api/v1/actions/CHILD/ACTION_NAME` with body `{ recordId: CHILD_ROW_ID, params }`. `:object` is the child object, and `:action` is the child action's declared `name`, never its `target` (ADR-0110 D1). `resolveRouteActionDeclaration` resolves it on the child (embedded `actions[]` first, then a standalone declaration owned by the child or object-less), and the ADR-0066 D4 gate runs against that declaration. `loadActionSubjectRecord(CHILD, CHILD_ROW_ID, ...)` loads the CHILD row under the caller's own scope as the subject. `refuseDeniedSubjectLoad` refuses with 404 RECORD_NOT_FOUND when the caller cannot read it. `seedFlowActionParams` seeds `recordId`, the child's camelCase `...Id` alias and any `recordIdParam` with the child id, the same keys the trigger body seeds today. The exception is the related-list TOOLBAR dispatch (`runRowAction(objectName, undefined, action)`, no row). RecordDetailView's flowHandler falls back to the PARENT page id (`action.recordId ?? pureRecordId`) against the child object. At the door that is a child-object subject load by the parent's id, refused 404. The record page's script handler has the same fallback today (its `resolveRecordId` override)." }, "hypotheses": { "H1": "CONFIRMED for declared actions (q1 mapping). The blocker is outside H1: the door has no answer for an UNDECLARED flow click (ADR-0110 D3 404), and the console emits those from two spec-legal surfaces (see summary). Runtime reading: a one-time probe rendered `{ type: 'action:button', properties: { label, actionType: 'flow', target: 'inline_flow' } }` through the real SchemaRenderer + action-button registration under an ActionProvider whose `handlers.flow` was a spy. The click reached the spy once with `type: 'flow'`, `target: 'inline_flow'` and `name` undefined. The dashboard path is pinned by the committed `DashboardRenderer.headerActions.test.tsx` (`{ type: 'flow', target: 'convert_lead_wizard' }` reaches `handlers.flow`). The console's `GlobalActionRuntimeProvider` (ConsoleShell) registers `useConsoleActionRuntime`'s flowHandler for every subtree.", "H2": "READ, NOT BUILT. Both handlers build the same trigger body `{ recordId, objectName, params }` today and differ only in where the record id comes from. The runtime reads `params.recordId ?? _rowRecord.id ?? exactly one selectedRecords`, with multi/zero-select guards. The record page reads `action.recordId ?? pureRecordId`. That is the same split the two script handlers have (core `resolveServerActionRecordId` and the record page's `resolveRecordId` override). At the door the request is exactly core `createServerActionHandler`'s `POST /actions/OBJ/NAME { recordId, params }`. That factory returns `interpretActionResponse`'s envelope and drops the flow follow-ups (screen pause, refused notice), so one module-internal builder plus `interpretFlowResponse`/`judgeFlowLaunch` would serve both copies with no new export.", "H3": "CONFIRMED for row actions (q2). Exception: the related-list toolbar dispatch with no row sends the parent id against the child object and would be refused 404 at the door.", "H4": "CONFIRMED. `git grep '/trigger'` over packages/ and apps/ returned 20 lines. The only code that starts a flow by name is the two flowHandlers, `useConsoleActionRuntime` `flowHandler` and `RecordDetailView` `flowHandler`; their tests pin the URL (`useConsoleActionRuntime.test.tsx` x2, `useConsoleActionRuntime.refusedLaunch-9973.test.tsx`, `RecordDetailView.refusedLaunch-9973.test.tsx`, `RecordDetailView.headerApiInterpolation.test.tsx`). `flow-envelope.ratchet.test.ts` scans for `/trigger` and `/resume`, and its 'three known callers' pin names both handler files, so a door switch must update it. `apps/console` `useApiDiscovery.ts` has a developer API-explorer catalog row (`POST /trigger`), not a click path. The other hits are prose (`flowResponse.ts` header; 'current/trigger/vars' roots in flow inspectors; `disclosure.ts`; two unrelated test regexes). `git grep 'automation/'` returned 111 lines; non-test source hits are in 19 files, and the only ones that run or continue a run are the two flowHandlers and FlowRunner's `/runs/RUNID/resume` (a continuation, which the action door has no counterpart for). The rest are registry reads (`/connectors`, `/actions`, `/_status`, `/RUN/runs`), Studio `/toggle` / `/clone`, and comments.", "H5": "NOT MEASURED: first-load bytes, reason: no head diff exists (stopped at needs_decision before any edit); a console build would answer nothing about a delta." }, "docs_page": "No docs page describes which route a flow action's button calls. Two pages name the flow type: `content/docs/guide/architecture-overview.md` 'Supported Action Types' (`flow`: 'Execute a multi-step action sequence') and `content/docs/plugins/plugin-dashboard.mdx` (dashboard header `actionType` includes `'flow'` with `actionUrl` 'the target the action runner dispatches'), the second being one of the two undeclared-click surfaces.", "tests": "No gate run: no diff exists. NOT MEASURED: every gate family (vitest suites, type-check, changeset, line-citation, control-bytes, eslint, reverse leg), reason: stopped at needs_decision before the first edit. Branch head equals main at dispatch: `git rev-parse --short HEAD` = ea79b7777, no commit of mine. One-time runtime probe (uncommitted, deleted, `git status --porcelain` empty afterwards): `OS_VERIFY_LOCK_SLOT=issue-12037 bash os-verify-lock.sh -c 'pnpm exec vitest run packages/components/src/__tests__/zz-probe-12037-inline-flow.test.tsx'` gave 'Test Files 1 passed (1)', 'Tests 1 passed (1)', 'os-verify-lock: VERDICT command-exit 0'. Its assertions: `type === 'flow'`, `target === 'inline_flow'`, `name === undefined`. The first probe run gave VERDICT command-exit 1 because it rendered the registered component directly, skipping SchemaRenderer's `properties` hoist, so the button had no label. That is an instrument error, not a reading. Producer census (`git grep -E` for `actionType` = flow in any quoting): objectstack origin/main whole tree 0 hits (positive control, the same pattern with `url`: 8 files); objectui whole tree 3 hits, all test fixtures (`DashboardRenderer.headerActions.test.tsx`, `dashboard-header-global-filters-spec-7759.test.ts`, `p1-spec-alignment.test.ts`; control `url`: 14 files). Declared `type: 'flow'` actions in objectstack examples: `app-crm` `convert-lead.action.ts` and `app-showcase` `ui/actions/index.ts` (4 example files match the pattern of 260; the other two are a flow index and an API catalog).", "gates": "none run (no diff); head ea79b7777 = main at dispatch", "files_changed": [], "open_questions": [ { "question": "Which door serves a console flow click that names NO declared action (an inline page `action:button` / `action:icon` / `action:group` / `action:menu` with `actionType: 'flow'` + `target`, whose `name` the spec makes optional; a dashboard header action with `actionType: 'flow'` + `actionUrl`)? The action door refuses it 404 by ADR-0110 D3, and the one shared flowHandler cannot tell such a click from a declared one.", "decision_frame_verbatim": "**每个方案必须沿四条固定评估轴分析,这是决策分析的核心原则,不是可选项:**\n\n- **实际业务需求** — 它服务的是**真实存在的业务场景**,\n 还是投机性能力面?判据要求**实测**(谁在写这个键、谁在读、\n 示例应用与真实部署的用法),「读起来像有用」不作数。这条轴会改变结论,不是陪衬。\n- **项目长远合理性** — 哪个方案符合北极星方向与可持续架构(no workarounds、\n contract-first),临时补丁式选项要明说长期代价。\n- **防 AI 写代码犯错,尤其是防 AI 写元数据 app 犯错** — 哪个方案让 AI 在结构上*更难写错*:\n 契约收紧(严格 schema、publish 时响亮拒绝)优于消费端宽容(`??` 回退、静默容错)——\n 宽容恰是 AI 批量犯错被掩盖的温床;声明即强制,绝不让 AI 声明一个运行时不兑现的能力。\n- **创业阶段不扩散需求** — **创业阶段聚焦原则**:创业项目先专注核心能力,能力扩张默认\n 从紧,无拉动的声明面按 implementation-first 处置,已发布零消费能力不因沉没成本豁免。\n **过渡也从紧 —— 创业阶段不渐进**:废弃别名/拼写与能力退役默认**立即退休**,无分阶段\n 窗口、无双拼写宽限;staged 仅凭具名外部用户证据方可荐。**新增门禁默认否**:门禁是只减\n 不增的零件,例外只有维护者点名;荐新增门禁须引其点名原话,否则荐「不加」。\n\n**基本裁决原则**:spec 声明 > 实现 > 文档面;声明而未兑现是实现缺口,补实现或退役,\n⛔ 不在消费端收窄;未声明键随实现,文档随之。「声明即强制」只及 spec 与元数据契约、\n运行时能力,⛔ 不及 AGENTS.md 这类给 agent 读的约定 —— 那些的读者是 agent,不是门禁。\n推荐意见必须基于这四条轴给出理由;四轴冲突时如实呈现权衡,\n交维护者拍板。", "options": [ "A — Contract first: the spec retires the undeclared flow click, and the console routes EVERY flow click through the action door. A flow-typed `action:button` and its siblings must carry a `name` that names a declared action (refused at save; existence checked at `os validate`/publish). The dashboard header's `actionType: 'flow'` is retired, or its `actionUrl` is restated as a declared object-less action's name, which is what the console already does for `actionType: 'script'` (the renderer synthesizes `name: actionUrl` and the script handler posts `/actions/global/ACTIONURL`). Then objectui#12037 routes both handlers through the door and refuses a nameless flow click client-side with the script handler's existing sentence. Work: one objectstack spec card (`domain:cli`), then this card. Axis 1, business need: measured zero producers of undeclared flow clicks in objectstack (whole tree) and in objectui apps/examples (three test fixtures only). The measured real flow buttons, CRM `convert-lead` and the showcase flow action, are declared actions the door serves. Real deployments cannot be measured from here. Axis 2, long-term: one door per flow button, so every gate a declaration carries (ADR-0066 D4 capability, ADR-0104 D2 params, ADR-0126 activation, caller-scoped subject load) applies to every console flow click, with no console-side inference. Axis 3, AI mistakes: contract tightening, a loud save-time refusal in place of an ungated path. Axis 4, startup focus: retires an unpulled spec surface at once (zero producers, so no staged window) and adds no new gate (a strict-row refinement plus a reused client refusal).", "B — Implement the declared surface: the console keeps two doors behind the one handler. Clicks that name a declared action go to the action door; undeclared inline/dashboard flow starts stay on the trigger route, with the reason recorded: they carry no action declaration, so the trigger route's own checks (existence, ruling A's elevated-start refusal, runAs) are the whole set that applies. Axis 1: keeps a spec-legal shape that has zero measured producers. Axis 2: the handler needs a provenance signal it lacks today. The dashboard synthesizes `name: actionUrl`, and an inline button may carry any `name`, so either a new field crosses the published ActionDef / `action:button` forward path (barred by this claim's 'no new published prop'), or the console guesses from its metadata store at click time (standalone actions in env-scoped kernels may be absent client-side, which routes a declared action to the ungated door with no signal). Axis 3: consumer-side tolerance, so an AI-authored inline flow button runs with no action gate and no warning. Axis 4: adds a mechanism to keep an unpulled surface.", "C — The framework widens the action door to start an undeclared flow. This contradicts ADR-0110 D3 ('Executable over HTTP but undeclared has no remaining legitimate use'; refusal with no opt-out) and reopens what D3 closed. Every axis argues against it." ], "recommendation": "A. Axis 1 is measured: no producer of an undeclared flow click exists in either repository's apps or examples, and every measured flow button is a declared action. Axis 2: the card exists so a click meets the gate its action declares, and only A makes that hold for every click without a console-side guess. Axis 3: A is contract tightening, while B is the consumer tolerance the frame ranks below it. Axis 4: immediate retirement of a zero-producer surface, and no new gate. The four axes agree, so there is no tradeoff to escalate beyond the spec change itself. The base ruling principle forbids narrowing on the consumer side alone, which is why A needs the spec card first and objectui cannot refuse these clicks unilaterally." } ], "out_of_scope_findings": [ "carrier: the implementation round of objectui#12037 after the ruling (it rewrites exactly this fallback). Noted, not filed. RecordDetailView's related-list TOOLBAR dispatch (`RelatedRecordActionsBridge.runRowAction` with no row) falls back to the parent page's id against the child object, in both `flowHandler` (`action.recordId ?? pureRecordId`) and the script handler's `resolveRecordId`. Via the trigger route it seeds the parent id as `recordId` and as the child's `...Id` alias; via the door it is a child-object subject load by the parent's id, which `refuseDeniedSubjectLoad` answers 404. Code reading, not reproduced. Dedupe words: related list toolbar, parent record id, child object, recordId fallback.", "carrier: the same implementation round (H2's shared call shape absorbs it). Noted, not filed. `useConsoleActionRuntime.flowHandler` reads the row id as `_rowRecord.id`, while core `resolveServerActionRecordId` reads `_rowRecord[recordIdField]`, so the flow and script launches diverge on a declared `recordIdField`. Code reading, not reproduced. Dedupe words: recordIdField, _rowRecord, flowHandler, row id.", "carrier: the implementation round's docs-driven update (AGENTS.md commandment 2). Noted, not filed. `content/docs/guide/architecture-overview.md` 'Supported Action Types' describes `flow` as 'Execute a multi-step action sequence', but it starts a server-side flow by name. A docs observation, outside classes a/b/c. Dedupe words: architecture overview, supported action types, flow description." ], "deviations": [ "Stopped at needs_decision before the first edit, per the dispatch's door-lacks-something clause; no PR, so no label-write, no PR assignee, and no changeset.", "The door was read from the objectstack shared checkout via a private ref (`git fetch --depth=50 origin main:refs/os-dev/issue-12037/os-main`, deleted after use). That fetch also advanced the shared `refs/remotes/origin/main` there (73a0a6bf to 081e6a09, the configured refspec): a shared-ref side effect of a read. objectui installs no `@objectstack/runtime`, so the installed copy was not an option.", "Worktree `/home/user/objectui-issue-12037` was created, its empty branch pushed (the claim marker and write probe, exit 0), then removed with `git worktree remove` (no force, exit 0) after `rm -rf` of its node_modules. The probe test file was written, run once under the lock, and deleted, never committed.", "No eager-closure build: H5 is NOT MEASURED (no head to compare)." ], "mcp_calls": "0 — no MCP GitHub tool called", "api_writes": "1 — the os-dev-report comment on objectstack-ai/objectui issue 12037 through scripts/pm/post-stamped.mjs (POST .../issues/12037/comments, route as the tool printed it); `git push` of the empty branch is not a REST write; REST reads only otherwise (GET .../issues/12037, GET .../issues/12037/comments)" }Generated by Claude Code
objectstack-fleet commentedon Oct 9, 2026
Seat review of the dev's
needs_decision(6077490453): one contract fork goes back to triage. No code is written until it is answeredSeat
domain:ui#2·os-bill·session_01MgfduSkFrfM3eorB3UGfAU· 2026-10-09T08:42Z.What the dev measured, re-read by the seat on objectstack
081e6a09(it carries objectstack-ai/objectstack#22424):dispatchFlowActionanswers with the same ADR-0112 envelope as the trigger route. A paused screen run'srunId/screen/flowLabel, the refused end andFLOW_FAILEDland whereinterpretFlowResponsereads them. A related-list row action addresses the child object and the child's declared action name, and the door loads the child row as its subject.action:button(and itsaction:icon/action:group/action:menusiblings) withactionType: 'flow'and atarget. Itsnameis optional by the spec's own row:component.zod.ts:3481, "an inline page button is not a registered object action";actionType: 'flow'and anactionUrl(DashboardHeaderActionSchema).flowHandlercannot tell the two kinds of click apart. The dashboard renderer synthesizesname: actionUrl, and an inline button may carry anyname. Routing only declared clicks to the door would take a provenance signal the handler lacks, which is the partial route the claim rules out.convert-leadand the showcase flow action, are declared actions.Why this is a fork, not execution: ADR-0110 D3 is about an undeclared action handler. Whether a page or dashboard button may start a declared flow without an action declaration is a question about the spec's surface. The spec answers yes today, and ruling A gates the trigger route's elevated start, so neither text settles it.
Governing text: ADR-0110 D3 ("Executable over HTTP but undeclared has no remaining legitimate use"; refuse 404, no opt-out); ADR-0066 D4 (an action's
requiredPermissionsis a dual-surface gate whose server half lives at the action door);@objectstack/speccomponent.zod.ts:3481anddashboard.zod.tsDashboardHeaderActionSchema(both admit a flow click that names no declared action).Options (the dev's, kept):
actionType: 'flow'names a declared object-less action, asactionType: 'script'already does. Then this card routes every flow click through the door. Work order: an objectstack spec card (Clause-②, contract review), with this cardBlocked-by:it.Seat recommendation: A. The four-axis analysis is below.
The ask, for triage: rule A, B or C. Under A, file or route the spec card and name its lane; the seat then moves this card to
pm:blockedwithBlocked-by:it.State: the card keeps
pm:dispatchedandos-billand gainspm:retriage. No branch content and no PR exist. The two code findings in the dev's report (the related-list toolbar's parent-id fallback, and_rowRecord.idagainstrecordIdField) ride the implementation round.四轴分析
convert-lead、showcase)都是已声明动作,走动作入口即可。Clause-②),须走 spec 车道与合同复审,本卡不能在消费端单方面收窄。Generated by Claude Code
objectstack-fleet commentedon Oct 9, 2026
Triage answer to the fork: B, resolved rather than guessed. A click that names a declared action goes to the action door; a flow start that names none stays on the trigger route, with the reason recorded.
pm:retriageclearedTriage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-09T08:53Z. ⛔ Not a claim, ⛔ not a dispatch.This answers the seat's review
6077530139of the dev'sneeds_decision(6077490453).requiredPermissionsand no subject load to apply. For it the trigger route is the correct door, and ruling A's elevation refusal already holds there.nameresolve to a declared action of typeflowwith the same target, in the object metadata the console already loads.name: actionUrland an inline page button with no or a non-matchingname.packages/i18nkey, as the claim already says.triage-duties.mdsends to the maintainer's decision box. The dev's census found zero real producers, so there is no pull to open that decision now. If one appears, A comes back as a decision card with this card's measurement as its baseline.requiredPermissionsthe caller lacks is refused by the server on click, with the action door's code. This covers a related-list row action on the child.pm:dispatchedand the claim stand. The seat runs its build round on B.objectstack-fleet commentedon Oct 9, 2026
os-dev-report
{ "issue": 12037, "status": "done", "branch": "claude/issue-12037-flow-action-door", "pr": "https://github.com/objectstack-ai/objectui/pull/12046", "session": "session_01MgfduSkFrfM3eorB3UGfAU", "premise_still_valid": true, "summary": "Built on triage ruling B (`6077692839`). Both console flow-launch handlers now call one module-internal launcher, `launchConsoleFlow` in the new `packages/app-shell/src/utils/flowLaunch.ts`, which picks the door. A click goes through `POST /api/v1/actions/:object/:action` exactly when `findDeclaredFlowAction` finds, in the object metadata the console already holds, a `type: 'flow'` action of the click's `name` on the click's object with the same `target`. Otherwise the click stays on `POST /api/v1/automation/:flow/trigger`. The reason is recorded in both handlers' docblocks: an undeclared start has no action gate to apply, and ruling A's elevation refusal holds there. The door request is built by core's `createServerActionHandler`, so app-shell still names `/actions` nowhere and `actions-envelope.ratchet.test.ts` stays green, unedited. The answer is read by `interpretFlowResponse` / `judgeFlowLaunch` through an injected transport, which keeps the FlowRunner resume, the refused notice and the `FLOW_FAILED` `errorMessage`. Ride-along: RecordDetailView's flow path no longer sends the parent page id for a child object's toolbar action that has no row. Draft PR 12046 is open, assigned to os-bill.", "measurement_answers": { "q1_door_answer_carries_what_handlers_read": "YES; the field map is unchanged from the first round's report and is restated in the PR body table. On the door path the flow NAME comes from the declaration's `target`, which the lookup requires to equal the click's flow, so FlowRunner resumes under it. The pin resumes at `/api/v1/automation/showcase_reassign_wizard/runs/run-1/resume` and at `/api/v1/automation/qualify_lead_wizard/runs/run-1/resume`.", "q2_related_list_row_action": "`:object` is the child object, `:action` is the child action's declared `name`, and the body `recordId` is the child row. The door resolves the declaration on the child and loads the child row as the subject. Pinned: `/api/v1/actions/lead_task/escalate_task` with `{ recordId: 'task-9', params: {} }`, refused 403 and shown as the toast.", "metadata_source": "Object metadata only, with no new fetch type. The runtime reads the caller's `objects`, then the console store's `object` type through `withKnownObjects`, awaiting `metadata.ensureType('object')` first: the same cached call the param dialog makes at click time, and it refetches only past the store TTL. The record page reads its `objects` prop. That metadata carries `defineAction({ objectName })` declarations because `defineStack`'s bound-action merge (`stack.zod.ts`) appends bound top-level actions to each object's `actions[]`. Runtime reading: the console renders list row actions from `objectDef.actions` alone, and `e2e/live/screen-flow.spec.ts` clicks the bound `showcase_bulk_reassign` that way. ABSENT: object-less declared actions and standalone authored action rows that no object definition embeds. They keep the trigger route (today's behaviour), and the control pin 'an object-less declared action ... keeps the trigger route' holds it. `metadata.getItem('action', NAME)` (as `useNavActionDispatch` uses) would see them, but it is a click-time fetch and was not added." }, "hypotheses": { "H1": "CONFIRMED and pinned: the paused resume works off the declaration's target, the refusal shows as the toast, and the refused/failed arms are unchanged (the existing 9973 suites pass).", "H2": "CONFIRMED: one shared call shape, `launchConsoleFlow` plus `findDeclaredFlowAction`, module-internal, not in `utils/index` or the package entry, and imported only by the two handlers. Each handler keeps its own record-id rule (runtime: params, row, selection; record page: action, then the page record for its own object), passed in as `recordId`.", "H3": "CONFIRMED and pinned on the record page (row action on the child). Toolbar ride-along: a child action with no row now sends no `recordId` on both doors (pinned).", "H4": "CONFIRMED in round 1; after this change the only code that names `/trigger` is `utils/flowLaunch.ts`, and the only code that names `/resume` is `views/FlowRunner.tsx` (the ratchet's caller pin).", "H5": "MEASURED: both handler files ship in eager chunks (`DeclaredActionsBar`, `RecordDetailView`). `eagerGzipBytes` is 3238611 at base 47b1f0bb7 and 3238879 at head 66291b17c: +268 B gzip, with 289 eager chunks in both builds, under the +1024 B stop line. Each figure comes from a console `vite build` under the lock, read from `apps/console/dist/eager-closure.json`." }, "tests": "HEAD 66291b17c (`git rev-parse --short HEAD` printed inside the locked run). Union after the final commit: repo-root `pnpm exec vitest run` over 84 files. They are every `useConsoleActionRuntime*`, `RecordDetailView*`, `FlowRunner*`, `DeclaredActionsBar*`, `PageView*` and `RelatedRecordActionsBridge*` suite, plus `flowResponse.test.ts`, the app-shell `*.ratchet.test.ts`, `column-identity.ratchet.test.ts`, `one-authority-per-exported-name-6273.test.ts` and the two new pin files. Result: 'Test Files 84 passed (84)', 'Tests 596 passed (596)'. In the same locked command, `pnpm --filter @object-ui/app-shell type-check` echoed '> tsc --noEmit && tsc -p tsconfig.test.json'; 'os-verify-lock: VERDICT command-exit 0'. Reverse leg, committed first, trap-guarded with absolute paths: main's blobs (47b1f0bb7) of the two handler files under the two pin files plus the ratchet gave 'Tests 8 failed | 8 passed (16)'. The 8 failures were the 5 door pins, 2 parent-id pins and 1 delegation pin. The 8 passes were the trigger-route controls, which hold on main too. Restore: `git diff HEAD` showed 0 lines, and `git hash-object` equalled `HEAD:` for both files (a0b3fc0f22, fcfde81c42). Green on head: 'Tests 16 passed (16)'. Lock-free gates: `check-changeset-presence` '6 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; `check-changeset-no-major` OK; `check:new-line-citations` 'VERDICT new-cross-file-line-citations: 0 new citation(s)'; `check:control-bytes` OK; `docs:check-links` 'Links are valid across 17 scan roots'; `check:spec-symbols` OK; `check-vi-mock-override-shape` OK; `check-test-path-roots` OK; `check-lint-coverage` '46/46 packages linted'. ESLint narrowing: population is `eslint.config.js` `files: ['**/*.{ts,tsx}']`; 6 files from `--format json`, 0 errors. Warnings equal the base blobs (RecordDetailView 110, useConsoleActionRuntime 38). Invariance: no `projectService` / `parserOptions.project`, so linting is not type-aware and the diff cannot move an untouched file. Full `pnpm lint` / `pnpm test` belong to CI.", "gates": "all listed green on 66291b17c; CI at report time: 42 check runs, 20 success, 3 skipped, 19 in_progress", "eager_closure": "base 3238611, head 3238879, +268 B gzip (self-measured); budget bot reading on PR 12046: NOT MEASURED, reason: CI in_progress at report time", "files_changed": [ "packages/app-shell/src/utils/flowLaunch.ts", "packages/app-shell/src/hooks/useConsoleActionRuntime.tsx", "packages/app-shell/src/views/RecordDetailView.tsx", "packages/app-shell/src/hooks/__tests__/useConsoleActionRuntime.flowActionDoor-12037.test.tsx", "packages/app-shell/src/views/RecordDetailView.flowActionDoor-12037.test.tsx", "packages/app-shell/src/flow-envelope.ratchet.test.ts", "content/docs/guide/architecture-overview.md", ".changeset/12037-flow-action-door.md" ], "open_questions": [], "out_of_scope_findings": [ "carrier: RecordDetailView's next touch of `serverActionHandler`; no named PR. Noted, not filed. The record page's SCRIPT handler keeps the parent-id fallback for a related list's toolbar action with no row (its `resolveRecordId` override, `action.recordId ?? pureRecordId`). At the door that is a child-object subject load by the parent's id, answered 404 by `refuseDeniedSubjectLoad`. Outside the flow path rewritten here, as the build round directed. Code reading, not reproduced. Dedupe words: related list toolbar, script action, parent record id, resolveRecordId.", "carrier: whoever next touches core `resolveServerActionRecordId`; no named PR. Noted, not filed. It reads `_rowRecord[recordIdField]` as the record ADDRESS, but the spec describes `recordIdField` as 'Row field whose value seeds recordIdParam', and the door loads the subject by the body's `recordId`. The only producer with a non-id `recordIdField` (`sys_session` `revoke_session`) is an `api` action that never reaches that reader, so it is dormant. For that reason the flow launch was NOT aligned to it: its `_rowRecord.id` is the read the door contract wants. Dedupe words: recordIdField, recordIdParam, resolveServerActionRecordId, row address." ], "deviations": [ "One file outside the claim's literal surface list: the new module-internal `packages/app-shell/src/utils/flowLaunch.ts`, the H2 shared call shape that the build round asked to keep module-internal. It is not exported from `utils/index` or the package entry. Every other file is on the list. `ObjectView.tsx` and objectstack are untouched.", "`_rowRecord.id` vs `recordIdField` was not aligned with core; the reason is the second out-of-scope finding. The script handler's toolbar fallback was reported, not mirrored, because it is outside the code this PR touches.", "The runtime flowHandler now awaits `metadata.ensureType('object')` before the lookup: the store's existing `object` load, not a new fetch type, the same call the param dialog makes at click time. It fetches only when the store's cache is cold or past its TTL.", "Synced the branch to main by fast-forward (`ea79b7777` to `47b1f0bb7`, a merge, no rebase or force) before the first edit. Base console build and closure build ran in the worktree under the lock; worktree removed after the PR opened (no force, exit 0).", "The door was read again from objectstack origin/main (`440bed63` at this round's fetch, private ref deleted after use)." ], "mcp_calls": "0 — no MCP GitHub tool called", "api_writes": "3 this round, all through the fleet-write relay as objectstack-fleet[bot]: `pr_create`, POST /repos/objectstack-ai/objectui/pulls (draft, PR 12046, read-back identical 10845 bytes); `label-write --assign os-bill`, POST .../issues/12046/assignees (read back matches); and this os-dev-report comment, POST .../issues/12037/comments. Plus `git push` (not REST). Round 1 spent 1 comment (6077490453)." }Generated by Claude Code
objectstack-fleet commentedon Oct 9, 2026
os-dev-report
{ "issue": 12037, "status": "done", "branch": "claude/issue-12037-flow-action-door", "pr": "https://github.com/objectstack-ai/objectui/pull/12046", "session": "session_01MgfduSkFrfM3eorB3UGfAU", "premise_still_valid": true, "summary": "Live E2E reproduced locally, root-caused and fixed in this PR. The cause is ours: the live spec `e2e/live/screen-flow.spec.ts` asserted the old door. Against the pinned published backend (17.7.0), the declared `showcase_bulk_reassign` click went through the action door. The run paused, its screen rendered, Submit resumed it and the toast fired. Only the spec's request-shape assertion that a POST hit `/api/v1/automation/NAME/trigger` failed. The spec now asserts the action-door launch, and that no trigger-route start happened. All 5 allowlisted tests pass at head 418a24870, while the new spec is red against main's console. First-load bytes, re-measured against main 3c3115e: +268 B eager gzip and -3 B on the entry chunk. The +1.0 KB / +0.8 KB came from comparing against PR objectui#12036's last bot reading, a different tree from 3c3115e. Branch synced to main by merge (090b212ef) and pushed as 418a24870; the PR stays draft.", "live_e2e": { "failing_spec": "e2e/live/screen-flow.spec.ts — 'a row flow action renders its screen and resumes the run'", "error": "Error: the flow action never triggered a run — expect(received).toBeTruthy(), Received: undefined, at the spec's `expect(trigger, ...)` assertion (reproduced locally at 66291b17c, same message)", "root_cause": "The spec pinned the trigger route: it collected POSTs to `/api/v1/automation/` and required one matching `/automation/NAME/trigger`. This PR sends the declared `showcase_bulk_reassign` click to `POST /api/v1/actions/showcase_task/showcase_bulk_reassign` instead (ruling B), so no trigger request exists. Every earlier assertion in the same test passed before it failed (dialog visible, 'New Assignee' heading, fill, Submit, completion toast, dialog closed), so the flow itself ran end to end. Not a flake, and not the backend.", "backend_evidence": "Published backend per `e2e/live/ci/backend.env` OBJECTSTACK_VERSION=17.7.0. The showcase app came from tag `@objectstack/cli@17.7.0`, resolved to 4e4e881427a8, and the backend was booted by `e2e/live/ci/start-backend.sh` on :4037. `@objectstack/runtime@17.7.0` was published on 2026-10-06 (12:11 UTC), so it does NOT carry objectstack-ai/objectstack#22424 (merged 2026-10-09) or its elevated-start refusal. It does carry the door's flow arm: `dispatchFlowAction`, served by `handleActionsRequest` as `deps.success(result)`, read from the published `dist/index.js`. Live door probes with curl, signed in as the seeded admin: (1) `GET /api/v1/meta/object/showcase_task` -> `item.actions` holds `showcase_bulk_reassign` type `flow` target `showcase_reassign_wizard`, requiredPermissions none. So the bound action IS in the object metadata the console reads, measured live. (2) `POST /api/v1/actions/showcase_task/showcase_bulk_reassign` with body `{recordId: TASK_ID, params: {}}`, exactly the body `createServerActionHandler` builds -> HTTP 200 `{success:true,data:{success:true,status:'paused',runId,screen:{nodeId:'collect',title:'New Assignee',fields:[new_assignee]},flowLabel:'Reassign Task'}}`. No `Invalid action params` (the action declares no params) and no capability refusal (no `requiredPermissions`). (3) `POST /api/v1/automation/showcase_reassign_wizard/runs/RUN_ID/resume` with `{inputs:{new_assignee}}` -> HTTP 200, with collect and apply (`update_record`) both success. The door-started run resumes on the automation route.", "reproduction": "Ran the workflow's own steps locally: start-backend.sh (published 17.7.0, port 4037); `VITE_BASE_PATH=/ vite build` of apps/console under the lock; `vite preview --port 5237` with DEV_PROXY_TARGET pointing at the backend; then `playwright test` over the `test:e2e:live:ci` allowlist (screen-flow, action-modal, master-detail, saved-view-filter). The only local deviation is a scratch wrapper around `playwright.live.config.ts` that sets `launchOptions.executablePath: '/opt/pw-browsers/chromium'`; this container has Chromium 1194 and Playwright 1.62.1 expects 1234. Readings: head 66291b17c gave 1 failed (screen-flow, error above), 4 passed. Control main 3c3115e gave 5 passed. The fixed spec against main's console build failed with 'the declared flow action never started its run through the action door', so the new assertion can fail. Head 418a24870 gave 5 passed (33.6s). Every Playwright run went through the lock: VERDICT command-exit 1 / 0 / 1 / 0 respectively.", "fix": "Commit 418a24870 touches `e2e/live/screen-flow.spec.ts` only. It captures POSTs to `/api/v1/(automation|actions)/` and asserts a POST to `/actions/showcase_task/showcase_bulk_reassign`, then asserts that zero POSTs went to `/automation/NAME/trigger`. The resume assertion (`/runs/RUN_ID/resume` with `inputs.new_assignee`) and the persisted-data assertion are unchanged. The header explains the door rule. No fallback to the trigger route was added." }, "first_load_bytes": { "readings": "Built with plain `vite build` of apps/console, the same as round 2, under the lock, reading `dist/eager-closure.json`. Main 3c3115e: eagerGzipBytes 3239495, 289 eager chunks, entry `assets/index-b9f_J3fn.js` 74431 B. Head 418a24870 (66291b17c merged with 3c3115e): 3239763, 289 chunks, entry `assets/index-BIw9TIu8.js` 74428 B. Delta +268 B eager gzip, -3 B entry, under the +1024 B stop line.", "which_chunk": "`DeclaredActionsBar` +301 B; this is where the code of `useConsoleActionRuntime` and the new `utils/flowLaunch` lands. `RecordDetailView` -31 B, `ObjectView` +1 B, entry `index` -3 B. `flowLaunch.ts` moves nothing into the entry chunk: `createServerActionHandler` (core) and `flowResponse` were already in the eager closure, through `utils/consoleServerAction` and the two handlers.", "reconciliation": "The bot's PR reading matches this head build exactly: its entry file `index-BIw9TIu8.js` has the same content hash as my head build, and 3163.8 KB = 3239763 / 1024. The comparison base it was set against is PR objectui#12036's last bot reading (comment 6078101372, 09:21Z): 3162.8 KB, entry `index-B4W5k7-B.js`. That entry hash differs from main 3c3115e's `index-b9f_J3fn.js`, so it measured a different tree from main. Against 3c3115e itself the bot's arithmetic would read 3163.6 KB, which is +0.26 KB for this PR. The entry KB gap (71.7 vs 72.5) is in that base, not here: my builds measure the entry -3 B. Trim: not needed." }, "hypotheses": { "H1": "CONFIRMED live against published 17.7.0: paused screen, resume and completion through the door-started run (the curl probes and the green screen-flow spec at 418a24870).", "H2": "Unchanged from round 2.", "H3": "Unchanged from round 2 (unit pins); the live allowlist has no related-list flow spec.", "H4": "Unchanged; the live spec was the one remaining place that pinned the trigger route for a declared click, and it now pins the door.", "H5": "MEASURED against main 3c3115e: +268 B eager gzip, -3 B entry (see first_load_bytes)." }, "tests": "HEAD 418a24870 (printed inside the locked run). Repo-root `pnpm exec vitest run` over the same 84-file union as round 2 gave 'Test Files 84 passed (84)', 'Tests 596 passed (596)'. Then the closure build `pnpm --workspace-concurrency=2 --filter '@object-ui/app-shell^...' build`, then `pnpm --filter @object-ui/app-shell type-check`, which echoed `tsc --noEmit && tsc -p tsconfig.test.json`. All in one locked command: 'os-verify-lock: VERDICT command-exit 0'. Live allowlist at 418a24870: 5 passed; reverse readings are in live_e2e.reproduction. `pnpm exec eslint --format json e2e/live/screen-flow.spec.ts` gave 1 file, 0 errors, 0 warnings (base blob also 0/0). `check-changeset-presence` OK (the spec is not published source; the existing changeset covers the 6 source files). `check-changeset-no-major` OK, `check:new-line-citations` '0 new citation(s)', `check:control-bytes` OK.", "gates": "all listed green on 418a24870; PR CI re-runs on the push (Live E2E included: the workflow's `paths-ignore` does not cover `e2e/**`)", "files_changed": [ "e2e/live/screen-flow.spec.ts (this round)", "packages/app-shell/src/utils/flowLaunch.ts", "packages/app-shell/src/hooks/useConsoleActionRuntime.tsx", "packages/app-shell/src/views/RecordDetailView.tsx", "packages/app-shell/src/hooks/__tests__/useConsoleActionRuntime.flowActionDoor-12037.test.tsx", "packages/app-shell/src/views/RecordDetailView.flowActionDoor-12037.test.tsx", "packages/app-shell/src/flow-envelope.ratchet.test.ts", "content/docs/guide/architecture-overview.md", ".changeset/12037-flow-action-door.md" ], "open_questions": [], "out_of_scope_findings": [ "class: a · reach: the documented local command `e2e/live/ci/stop-backend.sh`, measured once: after it printed 'stopped pid 1750', port 4037 stayed bound by the backend's own child `objectstack serve --dev --port 4037` (pid 1796, parent `objectstack dev` pid 1751). The script kills only the pid that `start-backend.sh` recorded, so the dev server outlives it, and a re-run of `start-backend.sh` on that port reads as 'already running'-adjacent breakage. CI is unaffected (ephemeral runner, and the workflow header says so). Evidence: `lsof -ti tcp:4037` after the stop, with the child's cwd under the stopped backend dir. Dedupe words: stop-backend.sh, live backend, port still bound, child process, objectstack serve.", "carrier: the seat (PR body). Noted. PR 12046's body still reports gates on 66291b17c and bytes against 47b1f0bb7, and its Surface section omits the e2e spec. The edit to make: add `e2e/live/screen-flow.spec.ts` to Surface, and add the Live E2E root cause and readings plus the 3c3115e byte reconciliation from this report. Per contract the dev does not PATCH the PR body." ], "deviations": [ "One more file outside the claim's literal surface: `e2e/live/screen-flow.spec.ts`. It is the live test of the exact click path this PR changes, and the coordinator's instruction was to fix the cause inside this PR when it is ours.", "Synced to main by merge commit 090b212ef (no rebase, no force); the merge commit carries git's default message with no trailer pair.", "Local reproduction used a scratch Playwright config wrapper (executablePath to the preinstalled Chromium 1194); it was not committed and is deleted. The backend fixture, preview server and both backend processes were mine (recorded PIDs, port 4037/5237) and are stopped. `stop-backend.sh` left the child server running (see the class-a finding), so it was stopped by its PID 1796 / 1751 after its cwd confirmed it belonged to my backend dir.", "Did not read CI logs or the `live-e2e-artifacts` zip, as instructed; the failure was reproduced instead.", "Worktree removed after the push (node_modules first, no force, exit 0); the objectstack private ref was deleted." ], "mcp_calls": "0 — no MCP GitHub tool called", "api_writes": "1 this round: this os-dev-report comment, POST /repos/objectstack-ai/objectui/issues/12037/comments through `post-stamped.mjs` (fleet-write relay). Plus `git push` (418a24870, not REST). REST reads only otherwise: PR 12046, comment 6078746466, PR 12036 and its comments." }Generated by Claude Code
objectstack-fleet commentedon Oct 9, 2026
Review: ACCEPT — PR objectui#12046 (
Fixes), built on triage's ruling B (6077692839) ·domain:uiseat 2 · 2026-10-09T10:35ZImplemented-by:
os-devsubagent ofsession_01MgfduSkFrfM3eorB3UGfAU, branchclaude/issue-12037-flow-action-door, head418a248.Reviewed-by:
domain:uiseat 2 (session_01MgfduSkFrfM3eorB3UGfAU), against the PR's diff and CI on GitHub, not against the reports' prose.Built:
useConsoleActionRuntimeandRecordDetailViewnow call one module-internal launcher,launchConsoleFlowinpackages/app-shell/src/utils/flowLaunch.ts. It is not exported from the package entry.findDeclaredFlowAction. A click goes throughPOST /api/v1/actions/:object/:actionexactly when the click's object andnameresolve, in the object metadata the console already holds, to a declared action oftype: 'flow'with the sametarget. Otherwise it stays onPOST /api/v1/automation/:flow/trigger, and both handlers' docblocks record why.createServerActionHandler. Its answer is read byinterpretFlowResponse/judgeFlowLaunch, so FlowRunner's resume (under the declaration'starget), the refused end andFLOW_FAILEDkeep working.ensureType('object')is the store's existing cached load. BounddefineAction({ objectName })actions are in it: measured live,GET /meta/object/showcase_taskcarriesshowcase_bulk_reassign. Object-less declared actions and standalone rows are not in it, so they keep the trigger route, as every click did before. A control pin holds that.The Live E2E failure on
66291b1, root-caused and fixed in this PR:e2e/live/screen-flow.spec.tsasserted a POST to/automation/NAME/trigger. With this PR, the declaredshowcase_bulk_reassignclick goes through the action door instead.@objectstack/*17.7.0):66291b1: 1 failed, 4 passed;main3c3115e: 5 passed;main's console: red, as expected;418a248: 5 passed.418a248:Live E2E (informational)success.Checklist:
PR shape: draft, first line
Fixes #12037,Clause-②: no. The assignee isos-bill. Commit trailers carry no model name. Sync withmainwas by merge.Scope: 9 files. They are the claim's two handlers and their tests, plus:
flowLaunch.ts, the shared call shape the build round asked for;flow-envelope.ratchet.test.ts, updated to the new caller set;content/docs/guide/architecture-overview.md(Supported Action Types →flow);e2e/live/screen-flow.spec.ts;@object-ui/app-shell: patch.ObjectView.tsxand objectstack are untouched. Nothing published is added.Reverse leg: with
main's handler blobs, 8 of 16 pins turn red (5 door pins, 2 parent-id pins, 1 delegation pin). The 8 trigger-route controls stay green, as they should. Restored toblob == HEAD.Evidence: 84 files and 596 tests pass, with both repo-wide ratchets. The app-shell type-check passes. eslint warnings equal the base blobs. The changeset and line-citation checks pass.
First-load bytes: +268 B eager gzip, and -3 B on the entry chunk, against
main3c3115e. The growth is in theDeclaredActionsBarchunk. The budget bot's 3163.8 KB is this exact head build; its apparent +1.0 KB was measured against PR objectui#12036's last merge-ref reading, a different tree.PR body, superseded (the relay has no PR-body edit): its gates and bytes describe
66291b1against47b1f0b, and its Surface list omitse2e/live/screen-flow.spec.ts. This review states what is true on418a248.Noted, not filed:
serverActionHandler.e2e/live/ci/stop-backend.shleaves the backend's childobjectstack servebound to its port when run locally. CI is unaffected.Landing: through the merge queue once every check on
418a248is green.Generated by Claude Code