approvals: `escalation.enabled` has zero readers — the SLA sweep gates only on `timeoutHours`, so `enabled: false` still escalates

[hotlong]

Filed by an os-dev agent working an unrelated card in www.objectos.ai (#63, an article about pause/resume and approval SLAs). Recording it rather than fixing it — out of scope for that card. No assignee.

What was measured

On origin/main at 107bb4b:

ApprovalEscalationSchema declares enabled with a false default:

packages/spec/src/automation/approval.zod.ts:616
  enabled: z.boolean().default(false).describe('Enable SLA-based escalation for this node'),

The sweep that actually escalates never reads it. It gates on timeoutHours alone:

packages/plugins/plugin-approvals/src/approval-service.ts:3472-3473
  const esc = cfg?.escalation;
  if (!esc || typeof esc.timeoutHours !== 'number' || esc.timeoutHours <= 0) continue;

escalateRequest reads esc.action, esc.escalateTo and esc.notifySubmitter. It does not read esc.enabled either.

Grep for a reader anywhere in packages/ and apps/:

• escalation.enabled / esc.enabled / escalation?.enabled — zero hits outside the declaration itself.
• The only other occurrences are three fixture lines in packages/lint/src/validate-approval-approvers.test.ts that write enabled: true.

Why it matters

This is the ADR-0049 declared-but-unenforced shape, and it fails open, which is the worse direction. An author who writes

escalation: { enabled: false, timeoutHours: 24, action: 'auto_approve' }

has stated, in the vocabulary the schema gave them, that this SLA is off. The sweep escalates anyway — and with action: 'auto_approve' that silently approves a request the author believed was not on a clock. The declared default (false) makes it worse: an author who sets timeoutHours and nothing else gets escalation they never turned on, while the schema tells them the feature defaults to off.

Note this is the mirror image of the waitEventConfig.timeoutMs / onTimeout retirement (#4158): those were removed because they claimed a behaviour nothing delivered. This one delivers a behaviour the key claims to gate.

Routes (for triage, not a recommendation to skip the ruling)

1. Enforce — add if (esc.enabled === false) continue; to runEscalations. Cheapest, but it changes behaviour for any stored flow that set enabled: false alongside a real timeoutHours and has been escalating; that population should be measured before the flip.
2. Remove — retire enabled and let the presence of timeoutHours be the switch, which is what the runtime already means. One fewer key, and the remaining one cannot disagree with itself.

Either way the ruling is a maintainer's, not this agent's. The liveness question ("who authors enabled, and what did they expect?") wants the usual three-repo read before the route is picked.

Not addressed here

#63 in www.objectos.ai is a content card and does not touch this code. The article deliberately does not document the defect — it shows enabled: true (the correct-as-declared spelling) and makes no claim about what happens when it is false, so it stays accurate under either route above.

---

Generated by Claude Code

[os-trump]

Triage: ADR-0049 declared≠enforced, failing open (enabled: false still escalates; with action: 'auto_approve' it silently approves a request the author declared off the clock). Routed domain:spec — the declaration lives in packages/spec/src/automation/approval.zod.ts, and either route moves the contract face; the plugin-approvals sweep is the enforcement half. Type Bug (runtime contradicts the declared default and the key's own description).

Queued measure-first, enforce-or-remove: before picking route 1 (gate the sweep on enabled) or route 2 (retire enabled, let timeoutHours be the switch), measure the liveness question the card names — who authors enabled (three-repo read), and the stored-flow population carrying enabled: false alongside a real timeoutHours that has been escalating. Either route changes accept/escalation behaviour: Clause-② yes at claim time, contract-review tier per the standing clause-② rule. Route 2 additionally retires a published key — if the measurement points there, the retirement follows the ADR-0087/spec-property-retirement playbook rather than a drive-by delete.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round R7, wave 5 — measurement half ONLY (the triage charter's own step 1; the route ruling is the maintainer's — the card says so, and escalation/auto-approve semantics sit on the security-adjacent manual floor)
Session: session_01E5LFCYBJ3q2s6yW6oMLxwy
Branch: claude/issue-12278-escalation-enabled-census (measurement record only; expected zero code changes — a branch exists only if the dev needs to commit a measurement script artifact, which it should not)
Worktree: objectstack-issue-12278
Domain: domain:spec
File surface: NONE (read-only measurement across objectstack + objectui; cloud and hotcrm are outside this session's reach and will be declared unmeasured, not guessed). Any code change is a breach — stop and report.
Container & model: S, mode:subagent, model: opus — measurement work; the clause-② fable tier applies to the post-ruling IMPLEMENTING dispatch, not this census (recorded so the tier ledger stays honest)
Clause-②: no (this dispatch changes nothing; the card's eventual implementing dispatch is the clause-② yes one, per triage)
Serial constraints cleared: zero file surface ⇒ no serial constraints; in-flight #12248 (contracts/data-engine.ts) and landing-watch PRs untouched. H17: no hit.

---

Generated by Claude Code

[huangyiirene]

Claim (dev): measurement-only — census half of the enforce-or-remove ruling. No branch, no worktree, no code change expected; every read below is against origin/main refs (git show <ref>:<path>), no checkout touched.

Session: session_01E5LFCYBJ3q2s6yW6oMLxwy — note this is the same session ID as the PM claim comment above, because this dev runs as a subagent of the dispatching PM seat and shares its session URL. It is not a competing claim; the PM claim and this one are the same actor. No branch will appear for this card.

Scope: objectstack + objectui (both reachable). cloud and hotcrm are outside this session's reach and will be declared unmeasured with the exact commands a seat with access would run — not guessed.

Census to follow as an os-dev-report comment.

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

os-dev-report

Measurement half only — no code change, no branch, no PR. Every read below is against an origin/main ref via git show <ref>:<path> / git grep <ref>; no checkout was modified.

repo	ref measured	card measured
objectstack-ai/objectstack	b6c96bcea5d4352c5a63b4aa9a8d6809b9ce15cf	107bb4b
objectstack-ai/objectui	7975f2d85e2c2dd20b27658618544818a337a495	not measured by the card

Headline: the card's "zero readers" holds for the RUNTIME, and is incomplete for the PLATFORM

The card grepped objectstack only. objectui carries a live, load-bearing reader of escalation.enabled — the metadata-admin flow-node inspector uses it as the progressive-disclosure controller for the entire escalation block. This does not contradict the card's runtime finding; it adds a consumer the route ruling has to price. Details in §3.

---

1. Who authors escalation.enabled?

objectstack — 5 authored writes, all true, all test/doc fixtures

#	file	line	value	timeoutHours also set	kind
1	packages/lint/src/validate-approval-approvers.test.ts	140	true	24	lint fixture
2	packages/lint/src/validate-approval-approvers.test.ts	151	true	24	lint fixture
3	packages/lint/src/validate-approval-approvers.test.ts	153	true	24	lint fixture
4	packages/spec/src/automation/approval.test.ts	264	true	48	spec parse test
5	packages/spec/src/automation/approval.test.ts	303, 306	true	24, 0	spec parse test
—	docs/qa/platform-checklist/areas/approvals.json	803, 814	true (prose)	1	checklist step text, not executable config

Zero product code, zero example app, zero seed, zero template authors this key. examples/app-showcase and examples/app-todo mention "escalation" only as flow names, notify topics and priority-escalation prose — neither authors an approval config.escalation block at all (git grep -i escalat origin/main -- examples/ → 30 hits, none a config block).

Docs that instruct authors to set it:

• content/docs/automation/approvals.mdx:629 — "escalation is real, not decorative: set enabled: true and timeoutHours"
• content/docs/references/automation/approval.mdx:40,77,104 — generated reference table, enabled documented as optional (default: false)
• skills/objectstack-automation/SKILL.md:610 — published skill documents { enabled, timeoutHours, action, escalateTo, notifySubmitter }

Declaration registries (published surface, not authored config):

• packages/spec/authorable-surface/automation.json:25 and packages/spec/authorable-surface.base.json:2071 — automation/ApprovalEscalation:enabled
• packages/spec/authorable-defaults/automation.json:16 — automation/ApprovalEscalation:enabled = false
• No packages/spec/liveness/ row exists for ApprovalEscalation yet.

objectui — zero authored configs, one live reader (see §3)

git grep -n "timeoutHours" origin/main in objectui returns only field declarations and their tests. No stored/authored escalation config anywhere in the repo.

Instrument disclosure — the control caught a real instrument bug

Control (a) is why this census is trustworthy. My first instrument found zero of the three lint-fixture writes the card names: its opener regex excluded a .-prefixed member assignment, so node.config.escalation = { enabled: true, … } never matched. Fixed ([^A-Za-z0-9_.] → [^A-Za-z0-9_]), after which control (a) passes — all three card-named writes found (lines 140/151/153).

A second, independent instrument (every enabled token repo-wide whose ±8-line neighbourhood mentions escalat) then found two more real writes the fixed opener still missed (approval.test.ts:303,306 — single-line ApprovalEscalationSchema.parse({ enabled: true, … }), no escalation: opener on the line). Both instruments plus a same-line git grep -i -E "escalat.*enabled|enabled.*escalat" agree on the union above. Confirmed false positives, discarded: IncidentResponsePolicySchema.enabled (incident-response.zod.ts:327, different schema), authorable-defaults/system.json:115,120, ADR-0066 tenancy: { enabled: false }.

Control (b) — the neighbouring key, same instrument

timeoutHours is not zero, so a zero on enabled is about the key, not the tool:

file	authored timeoutHours writes
packages/plugins/plugin-approvals/src/approval-service.test.ts	11 (lines 1583, 1668, 1688, 1703, 1713, 1729, 1748, 1758, 1770, 3417)
packages/lint/src/validate-approval-approvers.test.ts	3
packages/spec/src/automation/approval.test.ts	3

The asymmetry is the finding: all 11 runtime-behaviour tests in plugin-approvals author escalation with timeoutHours and omit enabled entirely — e.g. approval-service.test.ts:1688:

openInput(['u9'], {}, { escalation: { timeoutHours: 1, action: 'auto_approve', notifySubmitter: false } }), CTX,

Under the declared default (enabled: false) every one of these is a config the schema says is off, and the suite asserts it escalates. The runtime's own test suite encodes timeoutHours-is-the-switch.

---

2. Stored-flow hazard population (enabled: false + real timeoutHours)

In-repo population: ZERO. Every authored enabled in both reachable repos is true. No file in objectstack or objectui authors enabled: false alongside a timeoutHours.

But the repo is the wrong place to look, and zero here must not be read as zero in the field. The console manufactures exactly this shape:

• objectui packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts:732-745 declares escalation.enabled (defaultValue: 'false') as the controller, and gates timeoutHours, action, escalateTo, notifySubmitter behind showWhen: { field: 'escalation.enabled', equals: ['true'] }.
• isFieldVisible (same file, :1050-1070) additionally returns true "when the field already holds a stored value (so existing config is never hidden)".
• FlowNodeInspector.tsx:229 — const visibleFields = fields.filter((f) => isFieldVisible(f, node, fields)); — filters rendering only. There is no prune-on-save: nothing deletes a hidden field's stored value.

So a console author who enables SLA escalation, sets timeoutHours: 24, then toggles the "SLA escalation" switch back off, commits { enabled: false, timeoutHours: 24 } — the hazard shape, one click away, produced by the platform's own authoring UI, whose toggle is labelled SLA escalation / SLA 升级 and helped as "Escalate when a decision is not recorded within the timeout."

The actual population lives in tenant databases (sys_approval_request.node_config_json / stored flow metadata), not in any repo, and is not measurable from a git checkout by any seat. It is the one number route 1 needs and this census cannot supply. A query against a live deployment is the only instrument; see §4.

---

3. Re-verification of the zero-reader claim on the current tree

Re-measured at b6c96bc (card measured 107bb4b).

Runtime — claim CONFIRMED, unchanged, same line numbers:

packages/plugins/plugin-approvals/src/approval-service.ts:3472-3473

const esc = cfg?.escalation;
if (!esc || typeof esc.timeoutHours !== 'number' || esc.timeoutHours <= 0) continue;

escalateRequest (:3759) reads exactly three keys, no enabled:

• :3760 const action: string = esc.action ?? 'notify';
• :3762 esc.escalateTo
• :3824 if (esc.notifySubmitter !== false && raw.submitter_id)

slaDueAt (:474-476) reads cfg?.escalation?.timeoutHours — also no enabled.

git grep -nE "(esc|escalation|escalationConfig|escalationCfg|sla)\s*\??\s*\.\s*enabled" origin/main across all of objectstack → zero matches. No new reader has appeared since 107bb4b.

Platform — claim needs AMENDING. objectui reads it, as an authoring-UI controller:

file	line	read
packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts	732	declares the controller field, defaultValue: 'false'
same	733	timeoutHours showWhen: escalation.enabled === 'true'
same	742	action showWhen: escalation.enabled === 'true'
same	744	escalateTo showWhen: escalation.enabled === 'true'
same	745	notifySubmitter showWhen: escalation.enabled === 'true'
packages/app-shell/src/views/metadata-admin/i18n.ts	4060	'escalation.enabled': { label: 'SLA 升级', help: '在超时内未做决策时升级。' } (zh only)
packages/app-shell/src/views/metadata-admin/inspectors/json-schema-to-fields.test.ts	64, 99, 310-331	pins the derived field + all four showWhen wirings

So the accurate statement is: escalation.enabled has zero runtime readers and one authoring-UI reader. The key is inert where it is enforced and load-bearing where it is authored — which is precisely the disagreement the card describes, now with a name on both halves.

---

4. Unmeasured legs — declared, not guessed

cloud and hotcrm are outside this session's reach (not attached; only objectstack and objectui are present). Neither was measured; no inference is offered about them. www.objectos.ai was measured by the card's filer only (it reports the article shows enabled: true) — second-hand, not re-verified here.

A seat with access should run, per repo:

# 1. authored writes of the key (run BOTH instruments — they miss different shapes)
git grep -n -i -E "escalat.*enabled|enabled.*escalat" origin/main | grep -v CHANGELOG
git grep -n -C8 -E "[\"']?\benabled\b[\"']?[[:space:]]*[:=][^=]" origin/main | grep -i -C8 escalat

# 2. the hazard shape specifically
git grep -n -A6 -E "[\"']?escalation[\"']?[[:space:]]*[:=]" origin/main | grep "enabled.*false"

# 3. runtime readers
git grep -nE "(esc|escalation|escalationConfig|sla)[[:space:]]*\??[[:space:]]*\.[[:space:]]*enabled" origin/main

# 4. control (b) — the neighbouring key must be non-zero or the instrument is lying
git grep -n "timeoutHours" origin/main | grep -v CHANGELOG

And, for the population route 1 actually changes behaviour for — the only instrument that can answer it, against a live deployment, not a repo:

-- stored approval nodes that declare the SLA off but carry a real deadline
SELECT id, node_config_json
FROM   sys_approval_request
WHERE  json_extract(node_config_json, '$.escalation.enabled')      = 0
  AND  json_extract(node_config_json, '$.escalation.timeoutHours') > 0;

plus the same predicate over stored flow metadata (sys_flow / package flow definitions) for nodes that have not yet opened a request.

---

The fork, stated neutrally (no recommendation — the ruling is the maintainer's)

Evidence pulling toward route 1 (enforce: gate the sweep on enabled):

• The key is on the published authorable surface (authorable-surface/automation.json:25, authorable-surface.base.json:2071) with a documented default; removing it is an ADR-0087 retirement, not a delete.
• It has a real consumer today: the console inspector's whole escalation disclosure tree hangs off it (5 wirings + a pinned test + a zh label). Route 2 must rebuild that disclosure on some other controller or flatten it.
• Published docs and the published objectstack-automation skill both instruct authors to set it.
• It fails open today, and enforcing closes an auto-approve path that currently fires against an explicit enabled: false.

Evidence pulling toward route 2 (remove: timeoutHours is the switch):

• Zero runtime readers, re-confirmed at b6c96bc; the enforcement half has never read it.
• The runtime's own 11 behaviour tests omit enabled and expect escalation — timeoutHours-as-switch is what the system already means and what its suite pins.
• Zero product/example/seed authorship in either reachable repo; the only writers are test fixtures and doc prose.
• Two keys that can disagree is the defect class itself; one key cannot contradict itself.

The tension the ruling has to resolve: route 1's blast radius is unmeasured and unmeasurable from here (the stored enabled: false + timeoutHours population lives in tenant DBs, and the console manufactures that shape one toggle away, so it is plausibly non-zero), while route 2's blast radius is fully measured and entirely in-repo (one inspector disclosure tree, one pinned test, one zh label, three doc sites, one published skill table) — but route 2 retires a published key and hands the "is it off?" question to the presence of timeoutHours, which no authoring UI currently presents as a switch.

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

ACCEPT (measurement half) — reviewer of record: spec seat R7, session_01E5LFCYBJ3q2s6yW6oMLxwy. Zero-trace census verified (no branch, no PR, both checkouts clean); the report comment read back intact. Quality notes for the record:

1. The instrument bug (member-assignment writes excluded by the opener regex) was caught by the card-named control, disclosed, and cross-checked with two independent instruments — the union is the population. This is the third instrument-discipline save this shift.
2. Material amendment to the card: "zero readers" is now "zero RUNTIME readers, one AUTHORING-UI reader" (objectui flow-node inspector uses escalation.enabled as the progressive-disclosure controller, 5 showWhen wirings + pinned test + zh label) — this changes both routes' blast radii and is load-bearing for the ruling.
3. Second finding: the console MANUFACTURES the hazard shape (no prune-on-save; toggling the switch off commits enabled:false + live timeoutHours) — one click from the escalating-against-declaration state.
4. The runtime's own 11 behaviour tests author timeoutHours and omit enabled — the suite itself pins timeoutHours-as-the-switch. The asymmetry is the finding.
5. Unmeasured legs declared with exact commands + the SQL predicate for the tenant-DB population — the only instrument that can answer route 1's stored-flow question.

State conversion follows in the next comment: pm:dispatched → needs-user-decision with the four-facet block — the route ruling is the maintainer's (security-adjacent manual floor), now with the evidence it was waiting for.

---

Generated by Claude Code

[huangyiirene]

os-decision-facets

一句话问题:审批节点的 escalation.enabled 开关是个「声明了但运行时不读」的键 —— 作者写 enabled: false 照样升级(还可能静默自动通过);现在测量齐了,请裁:补上执行(Route 1)还是退役该键(Route 2)?

选项:

• Route 1(enforce):在升级扫描加一行 if (esc.enabled === false) continue; —— 让运行时兑现声明。
• Route 2(remove):按 ADR-0087 流程退役 enabled,timeoutHours 的存在与否即开关(运行时今天实际的语义)。

① 实际业务需求:census 实测 —— 仓内零产品/示例/种子作者(仅测试夹具),但整个创作面都在教 enabled 是开关:console 检查器用它做渐进披露控制器(5 处 showWhen + pin 测试 + 中文标签)、3 处已发布文档、已发布的 objectstack-automation 技能表都指导作者设置它。作者被教的语义与运行时执行的语义相反,这就是业务面的真实伤害点。
② 项目长远合理性:两个可互相矛盾的键就是缺陷类本身,长期只能留一个开关。Route 1 让声明=执行,与既有创作面一致;Route 2 收缩键面但把「关」变成「删掉 timeoutHours」—— 没有任何 UI 把它呈现为开关,需要重建检查器披露树 + 改 3 处文档 + 改已发布技能(token 天花板 0 余量)。
③ 防 AI 写代码犯错:今天是开放失败:AI 作者照 schema 写 enabled: false + action: 'auto_approve',得到的是它声明关闭的自动审批 —— 最危险的静默形状。Route 1 当场关闭这条 fail-open 路径;Route 2 也消除歧义但要求全部教学面同步重训。
④ 创业阶段不扩散:Route 1 diff 最小(运行时一行 + 测试),Route 2 是一次全套退役(ADR-0087 + 检查器重建 + 文档 + 技能),爆炸半径全部仓内可测但显著更大。

推荐 Route 1(enforce),回退 Route 2。核心理由:存量租户库里若存在 enabled:false + timeoutHours 的流程(仓位测不到,SQL 判据已附在 census),这些作者声明过关闭 —— enforce 恰恰是把系统行为改成他们声明的样子,方向上是兑现而非破坏;而 Route 2 与整个创作面为敌。⚠️ 无论选哪条,objectui 读者的存在意味着两条路都不是纯 spec 侧改动。

附带子问题(同批,免得二次弹):console 检查器隐藏字段不剪枝(开关切关后 timeoutHours 留在存量配置里)是独立缺陷,波及所有 showWhen 分组。建议:裁 Route 1 后单独立 objectui 卡(选项 B —— 它是通用检查器缺陷,escalation 只是一例);若裁 Route 2 则 escalation 一例自然消失,仍建议为其余分组立卡。

置信缺口:租户库存量人口不可从任何仓位测量(census 附了 SQL 判据与四条跨仓命令);cloud / hotcrm 两腿未测且已如实声明。

回一个字即可:「1」= Route 1 + 子问题按 B 立卡;「2」= Route 2 + 子问题按 B 立卡;其它意见照述。

---

Generated by Claude Code