The boot action-governance inventory reads `type` only, so every declarative `operation: 'update'` action is warned as "a button wired to nothing"

[os-litant]

Filed out of scope from #15079 (the runtime executor for the declarative row-level operation: 'update' action, ruled on #14092). Found while auditing whether the card's list of four type-only readers is complete — it is not, and this is the fifth.

What happens

reconcileActionRegistrations in packages/objectql/src/action-governance.ts builds the unboundDeclarations finding — "a declared script action with no body and no handler under any candidate key: a button wired to nothing" — from a type-only test:

for (const { action, objectName, storeKey } of declarations) {
    if ((action?.type ?? 'script') !== 'script') continue; // only script needs a handler
    if (action?.body) continue;                            // its handler is synthesized

A declarative update action is exactly that shape and is meant to be: ActionSchema refuses target and body beside operation: 'update', and its type stays at the materialized default 'script' because the platform action route IS where the write is performed. So every such action falls through both continues and lands in unboundDeclarations.

runActionGovernanceInventory then logs, at every boot and on every metadata:reloaded:

[action-governance] declared script actions with NO handler — a button wired to
nothing (ADR-0078); add a `body`, or register a handler under the declared `target`

Once the runtime executor lands, that sentence is false for these actions and its prescription is actively wrong: adding a body or a target is refused at parse time for an operation: 'update' action.

Why it is not just noise

The inventory is the ADR-0110 D5 governance surface an operator reads to find real dead buttons. A population that is never actionable and grows with every declarative update action an app author writes is how a diagnostic stops being read — and the undeclared-handler 404 on the /actions door cites [action-governance] by name as the place to look.

Blast radius, measured

• Warn-only. runActionGovernanceInventory is documented as "warn-only and exception-proof"; nothing refuses a boot or a dispatch on it, and the route dispatches the update correctly regardless. No behaviour is wrong — the diagnostic is.
• It reaches every host that boots the engine plugin, once per boot plus once per metadata reload whose fingerprint changed.

The fix, in one line of the same shape the runtime took

Read operation before type, as the runtime doors now do:

if (action?.operation === 'update') continue;   // the platform performs the write

@objectstack/objectql is where the reader lives, so this is that package's card. The runtime side deliberately did not widen into it: the executor does not need this seam, and #15079's file surface says to report rather than widen silently.

Refs

#15079 (the runtime executor) · #14092 (the ruling) · PR #15077 (the spec half, where operation/patch land) · ADR-0110 D5 (the inventory) · ADR-0078

[os-zhuang]

分诊 · domain:engine / priority:p2 / pm:queue

Anchor read, not guessed. packages/objectql/src/action-governance.ts ⇒ domain:engine. The filer already settled the lane question correctly — "@objectstack/objectql is where the reader lives, so this is that package's card" — and explicitly refused to widen #15079's runtime PR into it. That refusal is the behaviour that should stay cheap, and this routing exists so it costs nothing.

Verified on origin/main f1d7872 (2026-09-04T23:50:17Z):

claim	read
the type-only test	action-governance.ts:222 — if ((action?.type ?? 'script') !== 'script') continue; // only script needs a handler ✅
the finding it feeds	:220 builds unboundDeclarations, pushed at :234, returned at :237; described at :185 as "a declared script action with no body and no handler" ✅
operation: 'update' is already declared on main	packages/spec/src/ui/action.zod.ts:532, :574, :972, :980 ✅
and it keeps type at the default	action.zod.ts:537 — "an operation: 'update' action keeps type at its [default]" ✅; :574 — "target is refused: the platform writes" ✅

⚠️ One correction to the card's framing, and it raises the grade

The card presents the defect as future-tense: "Once the runtime executor lands, that sentence is false." Half of that is already true today.

• The finding's headline ("a button wired to nothing") is, strictly, accidentally accurate right now — runtime: execute the declarative row-level operation: 'update' action — the platform action route performs one data-plane update of the current record as the caller (runtime half of #14092) #15079's executor has not landed, so the button really does not execute yet.
• The prescription is already wrong, on today's main, with no dependency on runtime: execute the declarative row-level operation: 'update' action — the platform action route performs one data-plane update of the current record as the caller (runtime half of #14092) #15079: "add a body, or register a handler under the declared target" — and action.zod.ts:574 refuses target beside operation: 'update', with body likewise refused. An operator who follows the diagnostic's own instruction today hits a parse-time refusal.

⇒ This is not a latent card waiting on #15079. It is live now, and it gets worse (headline becomes false too) when the executor lands. That is why it goes to pm:queue, not pm:blocked.

Grade — p2

• Not p1. The filer measured the blast radius honestly and it holds: runActionGovernanceInventory is "warn-only and exception-proof", nothing refuses a boot or a dispatch, and the route dispatches the update correctly regardless. No behaviour is wrong — the diagnostic is.
• Not p3, for two reasons the card states well and one it does not. First: this is the ADR-0110 D5 governance surface an operator reads to find real dead buttons, and the undeclared-handler 404 on the /actions door cites [action-governance] by name as the place to look. Second: the false population grows with every declarative update action an app author writes — it is not a fixed-size annoyance but one that scales with adoption of a feature the platform is actively shipping. Third, mine: a diagnostic whose remedy is refused at parse time does not merely get ignored — it sends the one operator who does act on it into a dead end.

Boundary test — Bug, no manual floor

Adding if (action?.operation === 'update') continue; removes a false positive from a warn-only inventory. Nothing widens, no accept set changes, no contract moves. Ordinary lane work.

For whoever takes it — three things

1. Read operation before type, as the runtime doors already do. The filer's one-liner is the right shape; ⚠️ verify the ordering against how #15079/PR feat(spec): row-level declarative field write — operation: 'update' + patch on ActionSchema #15077 spell it so the engine and the runtime agree on precedence rather than each having its own rule.
2. ⭐ This was found while auditing whether runtime: execute the declarative row-level operation: 'update' action — the platform action route performs one data-plane update of the current record as the caller (runtime half of #14092) #15079's list of four type-only readers was complete — it was not, and this is the fifth. ⇒ Do not assume five is the answer either. The same sweep that found this one should be re-run and its result stated in the PR, because "we enumerated the readers" has now been wrong once on this exact question. If a sixth exists, it belongs on this card, not on a seventh card next week.
3. Pin it. A test that a declarative operation: 'update' action does not appear in unboundDeclarations is what stops this returning the next time the inventory is touched — and this repo's current shift has catalogued eleven instances of assertions nothing compares.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code

[claude]

Claimed by the PM dispatch loop.

Claim: session session_01ARYe3yQTQCUFm5qPYNgKaJ, branch claude/issue-15444-action-governance-operation-update.
Clause-②: no.

Card-specific — three things triage asked for, and one correction to the card's own framing.

⭐ The card understates itself, and triage corrected it: this is LIVE today, not latent. The card writes the defect in the future tense ("Once the runtime executor lands, that sentence is false"). Half of it is already true on today's main with no dependency on #15079: the finding's prescription — "add a body, or register a handler under the declared target" — is already wrong, because action.zod.ts refuses target beside operation: 'update', and refuses body too. An operator who follows the diagnostic's own instruction today hits a parse-time refusal. ⇒ Do not treat this as blocked on #15079.

1. Read operation before type, and go check how the runtime doors spell that precedence before you copy the card's one-liner. The card proposes if (action?.operation === 'update') continue; and the shape is right, but ⚠️ triage's instruction is to verify the ordering against PR feat(spec): row-level declarative field write — operation: 'update' + patch on ActionSchema #15077 / runtime: execute the declarative row-level operation: 'update' action — the platform action route performs one data-plane update of the current record as the caller (runtime half of #14092) #15079 so the engine reader and the runtime doors agree on precedence rather than each inventing its own rule. If they disagree, say so in the report rather than picking one silently.

2. ⭐ Re-run the sweep, and ⛔ do not assume five is the answer. This card exists because runtime: execute the declarative row-level operation: 'update' action — the platform action route performs one data-plane update of the current record as the caller (runtime half of #14092) #15079's audit of "four type-only readers" was incomplete and this was the fifth. 「We enumerated the readers」 has now been wrong once on this exact question. Re-derive the population mechanically, with a firing positive control on the same command and scope, and state the count in the PR. If a sixth exists it belongs on this card — ⛔ not on a seventh card next week.

3. Pin it. A test that a declarative operation: 'update' action does not appear in unboundDeclarations. ⚠️ And make it a real pin: this shift has catalogued eleven instances of assertions that compare nothing. Ablate it — remove your continue, prove the mutation is on disk, watch the pin go red, restore byte-exact.

⚠️ Anchors are triage's, read at origin/main f1d7872 — ⛔ re-derive them, do not trust the numbers. packages/objectql/src/action-governance.ts: the type-only test at :222, unboundDeclarations built at :220, pushed at :234, returned at :237, described at :185. packages/spec/src/ui/action.zod.ts: :532, :537 ("an operation: 'update' action keeps type at its default"), :574 ("target is refused: the platform writes"), :972, :980. These files move daily.

Blast radius is warn-only and that is measured, not assumed — runActionGovernanceInventory is documented "warn-only and exception-proof", nothing refuses a boot or a dispatch, and the route dispatches the update correctly regardless. No behaviour is wrong — the diagnostic is. ⇒ ⛔ Do not widen this into a behaviour change; the deliverable is removing a false positive from a governance surface an operator reads to find real dead buttons.

Clause-② reading (this seat's, not binding): no — a continue inside a warn-only inventory, no export and no accept set moves. ⭐ Re-measure it anyway with the dist/index.d.ts ablation on @objectstack/objectql, because a no this seat asserted has been wrong twice today.

⚠️ This Clause-② reading is this seat's and is NOT binding on you. Re-derive it from your own diff and re-declare it in your report. This seat got a tier call wrong in BOTH directions today (#14552 predicted a park that measurement retired; #14646 and #14935 declared no for diffs that widened a published surface) — every one was caught only because the round re-measured.

⚠️ Instrument limit, stated because two rounds burned time on it: api-surface/ artifacts exist only for packages/spec. For any other package the published surface is its files[] + types (dist/**). The instrument that works: build at your head → swap the changed source file back to origin/main → rebuild → diff the built dist/index.d.ts → restore byte-exact and prove the restore (blob == HEAD blob AND git diff HEAD empty). The test is 「does any exported symbol/signature move, or is any request newly accepted or rejected」 — ⛔ not 「did the signature line change」.

✅ The Corepack CI defect is FIXED. check-regen-pending.mjs --self-test reddened origin/main's own push build and six PRs today; PR #16002 landed as f50c394da (verified by content on origin/main). If you cut from current main you will not see it. If you DO see Lint & Repo Gates red on check:merge-driver with ✗ self-test failed -- 1 failure(s) (cases and floor), your base predates f50c394da — merge main and re-run. ⛔ Do not skip, disable or quarantine anything over it.

⭐ Discipline notes earned the hard way today, all from real failures:

1. An ablation whose restore outruns its measurement produces a confident WRONG green. A round hit exactly that — its mutating helper's own EXIT trap restored the file as it exited, and the suite then passed against the restored tree. Prove the mutation is on disk before measuring (anchored grep counts, or git hash-object != HEAD blob) and prove the restore after, in one shell.
2. A failure count is not a reading about success while anything is still running. Read status explicitly. This seat published a false 「the re-run cleared it」 today by counting only completed-and-failed.
3. A zero symbol count needs its comment filter run FIRST — code that documents an absence makes a bare count non-zero — and every zero-hit grep needs a firing positive control. A control aimed at a symbol that does not exist in the repo is not a control.
4. cancelled is not failed. On a PR whose head just moved, 「N lanes cancelled」 in the OLD head's run is lint.yml's concurrency: cancel-in-progress, not evidence about that head. Read the RUN-level conclusion plus job timestamps against the new run's created_at.
5. The shared verify lock is contended. scripts/pm/os-verify-lock.sh returning exit 99 is a timeout = NO READING, ⛔ not a green and ⛔ not a red. Re-run to a real result and say so. Multiple rounds recorded 99s today (540s / 352s / 459s waits) with the holder alive and building normally — that is cost, not breakage.
6. Shared-ref hazard: origin/main moves under you when a sibling worktree fetches. Pin every diff and merge to a sha, never to the ref name. One round read 9 changed files that were really 5.

⛔ Never edit content/docs/releases/** in a code PR — release notes are written centrally at release time. Your PR's input to them is its changeset. E3 (2026-09-05) 「已发布必修，其余立卡」 — "published" is a MEASUREMENT against built dist/**/*.d.ts, dist/**/*.{js,mjs,cjs} and content/docs/**, not a guess.

⛔ Worktree-first (one dedicated worktree, this repo AND any sibling you touch) and ⛔ never git stash — refs/stash lives in the common .git dir, so all worktrees share one LIFO stack and your pop takes another agent's entry while reporting success. Use a patch file or a wip commit. ⛔ Never force-push or rebase a pushed branch.

Bump level: additive widening of a published surface ⇒ at least minor. ⭐ The act wins over the commit type — the gate at .github/workflows/pr-automation.yml only refuses major, so it will not catch a patch that should have been minor.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 15444,
  "status": "done",
  "branch": "claude/issue-15444-action-governance-operation-update",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16039",
  "premise_still_valid": true,
  "summary": "The card's premise held and was reproduced before any fix: a declarative `operation: 'update'` action lands in `unboundDeclarations` (the pin reported `count: 2` against unmodified source at the base sha). Both readers that still asked `type` before `operation` now ask `operation` first, in the ruled bare-equality shape: `packages/objectql/src/action-governance.ts` (this card) and `packages/lint/src/validate-ai-tool-references.ts` (the SIXTH reader, found by the sweep and fixed here per Zone 1.3 rather than deferred). Two PM assumptions measured FALSE or moved. (a) Zone 2.2 is FALSE: #15079's executor HAS landed on origin/main, by content -- `isDeclarativeUpdateAction` and the [#15079] guards were introduced by 8a12067bd (2026-09-04). So the finding's headline is already false today too, not merely 'becomes false when it lands'; both limbs are wrong now, which raises the grade and leaves the deliverable unchanged. (b) The changeset is `patch`, NOT the anticipated `minor`: the dist/index.d.ts probe found the only objectql delta to be JSDoc prose and lint's barrel byte-identical, and nothing is newly accepted or rejected (the inventory is warn-only; the removed lint finding is severity 'warning' and os lint gates on severity === 'error' alone), so the 'additive widening ⇒ at least minor' floor does not apply. Flagged rather than silently taken -- cheap for the PM to overrule. Zone 2.1 confirmed by measurement on both limbs. Clause-② re-derived independently: `no`.",
  "tests": "All readings at 150373751 (final commit); exit codes captured by redirecting first, then reading $?, never across a pipe. REPRODUCTION (before fix, unmodified source): `pnpm --filter @objectstack/objectql exec vitest run --maxWorkers=2 src/action-governance.test.ts` -> lock VERDICT 'command-exit 1'; 'AssertionError: expected { count: 2, actions: [ ...(2) ] }'; 'Tests 2 failed | 15 passed (17)'. AFTER FIX: 3 objectql governance suites 'Test Files 3 passed (3) / Tests 37 passed (37)'; lint suite 'Test Files 1 passed (1) / Tests 13 passed (13)'; lock VERDICT 'command-exit 0'. ABLATION (one shell, both guards, restore proved after measuring): objectql guard marker 1->0, disk blob 7839435571 != HEAD 752ed5414d => MUTATION PROVED ON DISK, then 'Tests 2 failed | 15 passed', restore blob == 752ed5414d BYTE-EXACT and `git diff HEAD` EMPTY; lint guard marker 1->0, disk d5ce54b4b5 != HEAD 4509e751ff, then 'Tests 1 failed | 12 passed', restore BYTE-EXACT and diff EMPTY. No rebuild leg needed and none claimed: both tests import their subject by relative path inside its own package, so vitest resolves source, not dist. CLAUSE-② PROBE (build at head -> swap changed file to base sha -> rebuild -> diff dist/index.d.ts -> restore): objectql diff is 15 lines, ALL JSDoc prose on reconcileActionRegistrations, no exported symbol or signature moved; lint dist/index.d.ts byte-identical (245107 both sides); both restores BYTE-EXACT with `git diff HEAD` EMPTY. TYPECHECK: `pnpm --filter @objectstack/objectql typecheck && pnpm --filter @objectstack/lint typecheck` exit=0 (VERDICT 'command-exit 0'). It first went RED honestly -- objectql's check:test-typecheck reported 'src/action-governance.test.ts: 1 type error(s)' (TS2769) which I fixed; coverage then verified with --listFiles: 1 hit for each edited test file, so this is a measurement, not a green over unread files. ESLINT: full repo `npx eslint . --no-inline-config` exit=0, 6037 files linted, errorCount 0, warningCount 0 (counts read from --format json, not estimated) -- no narrowing claimed because the whole scan ran. GATES: 20 derived gates run locally, every one exit=0, quoting their own verdict lines -- check:nul-bytes 'OK (scanned 7721 text file(s) -- 7721 tracked, 0 untracked-not-ignored; skipped 7 binary; no raw ASCII control bytes).'; check:startup-registry-verdict 'checkmark startup registry verdicts: 42 startup/open-registry seam(s) across 2261 file(s), 35 read-only (legal), none recording a verdict the boot can contradict.'; check:cross-package-test-inputs 'OK: 27 package(s) read outside themselves, all declared, and turbo.json hashes every declared glob.'; check:empty-changeset 'No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added).'; check:changeset-no-major 'This diff introduces no `major` bump.'; plus durability-log-level, registry-log-declared, logger-receiver-detach, changeset-fixed, changeset-gate-self-tests, objectui-changeset, test-source-alias, doc-authoring, objectql-double-limit, where-matcher, single-claim-paths, org-identifier, published-files, undeclared-dep-imports, type-source-resolution. Gate family re-derived AFTER the final commit via `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack`; provenance line confirms commit 150373751 and the 5-path change set; 122 entries discovered, the farm left to CI per the local-scope rule. SWEEP (Zone 1.3), two axes, each with a firing positive control on the same command and scope: axis 1 (action-declaration `type` reads) 41 hits after narrowing from 310, controls fired -- action-governance.ts:222 1 hit, the four known #15079 runtime readers 4 hits; axis 2 (the target/body 'is it wired' shape) exactly 3 hits, both controls firing. Triage of all 41 leaves exactly TWO unguarded readers on today's main, both fixed here. ZONE 2.1 measured with ActionSchema.safeParse via @objectstack/spec/ui: operation+patch+target -> success false at path [target]; operation+patch+body -> success false at path [body]; operation+patch alone -> success TRUE (full green parse, the control that makes the two refusals attributable to those keys). An earlier attempt at this probe died with ERR_MODULE_NOT_FOUND from outside the workspace -- recorded as NOT MEASURED and re-run inside packages/objectql, not reported as a failure. Lock discipline: every heavy run went through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-15444-dev set before the first attempt; no exit 99 was recorded, so every reading quoted here is real.",
  "mcp_calls": "0 - every GitHub read and write went through repo-scoped REST (probed first: HTTP 200); no MCP GitHub tool was called",
  "open_questions": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code