[objectstack-fleet]

Requested by Leehom · project thread

Fixes #29067

Clause-②: yes (widening)
Metadata-protocol: none

维护者速读

• 改了什么：spec 补上推送通道的协议面：设备注册请求加三个可选字段（vendor / appId / locale），INotificationService 加三个可选设备方法，新增推送数据契约（只允许同站相对路径的 route），新增 APNs / FCM 传输配置（密钥只能按引用写）。
• 为什么改：Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041 推送通道和 notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068 设备注册路由都卡在这张 spec 卡上；手机壳（mobile#144）和 Console（Console: register the mobile shell's native push token after sign-in, unregister it on sign-out #29042）要靠它注册设备、点推送打开页面。
• 风险与回滚：纯加宽，今天能写的请求一个也不拒；没有加路由行，DEFAULT_NOTIFICATION_ROUTES 字节不变。回滚即 revert 本 PR。
• 先看：packages/spec/src/api/push-delivery.zod.ts（route 的拒收正则）、packages/spec/src/system/push-config.zod.ts（内联密钥两道拒收）、packages/spec/src/contracts/notification-service.ts（三个设备方法的语义）。
• 两分钟验证：pnpm --filter @objectstack/spec exec vitest run src/api/push-delivery.test.ts src/system/push-config.test.ts src/api/register-device-request.test.ts，预期 3 个文件全绿。
• 需要你做的：无，席位落地（落地前欠声明面的 contract review）。

What changes

• RegisterDeviceRequestSchema (api/protocol.zod.ts): adds optional vendor (PushVendorSchema: apns or fcm; absent, the server derives it from platform), appId and locale. deviceId stays optional. Its describe now says that re-registering a deviceId refreshes the device, and that without one the server mints an id and answers it, and the client keeps it. No .default() was added, so the bare alias stays isomorphic. The response and UnregisterDevice* are unchanged.
• INotificationService: adds optional registerDevice(userId, request), unregisterDevice(userId, deviceId) and invalidateDeviceToken(token). Their JSDoc states one live owner per token, not found (NOT_FOUND) for another user's device, and that an invalidated row is kept, disabled, with its invalidation time. Absence means the capability is unavailable.
• PushDeliveryDataSchema / PushRouteSchema (new api/push-delivery.zod.ts): notificationId and an optional route. The route must start with exactly one slash, and it may not contain a backslash, whitespace or a control character (a URL parser turns a backslash, or a stripped tab or newline, into a protocol-relative reference). The JSDoc states the derivation: the route is the notification's existing actionUrl (url / actionUrl in the payload, else /OBJECT/ID) when it passes the schema, and absent otherwise. No notify key is added, and the removed name PushNotificationSchema is not reused.
• PushServiceConfigSchema (new system/push-config.zod.ts, beside email-config.zod.ts, which declares the email transport configuration): a strict apns block (teamId, keyId, topic, environment: sandbox | production, keyRef) and a strict fcm block (projectId, serviceAccountRef). An inline secret is refused twice. Under a key such as key, privateKey, p8, serviceAccount or serviceAccountJson it is refused by name, with the ref key as the prescription. Inside a ref, any value containing whitespace or braces (a PEM block, a JSON document) is refused. The block is not wired into the stack definition: its one reader is the push plugin in Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041.
• Generated: api-surface/, export-origins/, declaration-map/, authorable-surface/, json-schema.manifest/, the strictness-ledger counts and content/docs/references/**, all written by pnpm --filter @objectstack/spec check:generated --fix plus gen:schema. The type-alias pin file is hand-maintained: 811 → 817 isomorphic pins, for the six new aliases.

Tests

• Red first (base 6b3ba82c, commit 8dcce8b7): register-device-request.test.ts failed 6 of its cases (the widened round-trip and the five vendor refusals), and push-delivery.test.ts / push-config.test.ts failed at import.
• Green at 088613be: the touched suites (register-device-request, push-delivery, push-config, notification-service, protocol, plugin-rest-api, type-alias-convention.pin) passed, Test Files 7/7 and Tests 327/327. check-spec-parsed-alias.mjs passed (817 pinned, OK). check:generated --fix exited 0 and check:docs exited 0.
• The route-catalog pin (plugin-rest-api.test.ts, 3 endpoints) is unchanged and green.

Acceptance notes

• Metadata-protocol: none. These are wire request and response shapes, a service contract, platform-produced delivery data, and an operator config shape that no authoring door reads. Nothing a metadata author writes changes (AGENTS.md Post-Task step 3; ADR-0087 has no disposition to declare), so the changeset is patch.
• No UserDeviceSchema (ruling 3). No published wire shape needs the stored row: the request and response cover the routes.
• Route table untouched (ruling 2). One sentence in DEFAULT_NOTIFICATION_ROUTES' JSDoc ("device registration, preferences, listing") was already false on main before this PR. This diff does not make it false, so it is left for notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068, which adds the device rows.
• Cloud-side surface: none is proposed here, and none is filed.

Verification

Stopped early at the maintainer's wrap-up word. Not measured locally: the dispatch-gates --commands battery, the full @objectstack/spec pnpm test / pnpm typecheck, pnpm lint on spec, and the final origin/main merge. Reason: wrap-up. CI runs the full set, and the seat reads its check-runs.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 24 documentable anchor(s). ⚠️ 12 changed file(s) yielded no anchor (packages/spec/api-surface/api.json, packages/spec/api-surface/system.json, packages/spec/authorable-surface/api.json, …), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/index.mdx (via INotificationService (symbol, a top-level interface))
• content/docs/kernel/runtime-services/data-service.mdx (via /api/protocol.zod (route, a path literal on a changed line))
• content/docs/kernel/services-checklist.mdx (via INotificationService (symbol, a top-level interface), registerDevice (symbol, a method of interface INotificationService), unregisterDevice (symbol, a method of interface INotificationService), /api/protocol.zod (route, a path literal on a changed line))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via registerDevice (symbol, a method of interface INotificationService), unregisterDevice (symbol, a method of interface INotificationService))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 12 changed file(s) yielded no anchor (packages/spec/api-surface/api.json, packages/spec/api-surface/system.json, packages/spec/authorable-surface/api.json, …) — pages documenting those are invisible to this run
• the SDK route bridge reached 60 of 216 client-bound route-ledger rows — the other 156 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 156: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 101 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 168 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 12aad143f717e140cc1ec7227281009ef37bb192 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 94bd0910b5a88e4e2a623cc700f347d0121feada — the merge of head 088613bebab0047841f35dda237422bbe53942bf into base 12aad143f717e140cc1ec7227281009ef37bb192, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 94bd0910b5a88e4e2a623cc700f347d0121feada && git checkout 94bd0910b5a88e4e2a623cc700f347d0121feada
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 12aad143f717e140cc1ec7227281009ef37bb192 088613bebab0047841f35dda237422bbe53942bf && git checkout -B drift-repro 12aad143f717e140cc1ec7227281009ef37bb192 && git merge --no-ff 088613bebab0047841f35dda237422bbe53942bf

node scripts/docs-audit/affected-docs.mjs --json 12aad143f717e140cc1ec7227281009ef37bb192

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 12aad143f717e140cc1ec7227281009ef37bb192 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Contract-review-claim: session_01AavokzJ5DndAwitDXvKy4U · head 088613bebab0047841f35dda237422bbe53942bf · 2026-11-02T08:55Z

Taken under references/contract-review.md rule (b): this head has waited over 60 minutes with no record, claim or hand-off on it (the lane's earlier record names an earlier head). At CONTRACT_REVIEW_TIER.

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 088613bebab0047841f35dda237422bbe53942bf
Local-runs: none
Scope: packages/spec/src/api/index.ts, packages/spec/src/api/protocol.zod.ts, packages/spec/src/api/push-delivery.zod.ts, packages/spec/src/contracts/notification-service.ts, packages/spec/src/system/index.ts, packages/spec/src/system/push-config.zod.ts + packages/spec/src/shared/strict-object.ts, packages/spec/src/shared/connector-auth.zod.ts, packages/spec/src/system/email-config.zod.ts, packages/spec/src/system/notification.zod.ts, packages/spec/llms.txt, packages/spec/authorable-surface/api.json, packages/spec/authorable-surface/system.json, packages/spec/liveness/connector.json, packages/spec/src/type-alias-convention.pin.test.ts, packages/services/service-messaging/src/messaging-service.ts, packages/services/service-automation/src/builtin/notify-node.ts, packages/client/src/index.ts, docs/adr/0012-notification-platform.md, docs/adr/0143-outbound-connector-auth-is-open-tier.md, .github/workflows/pr-automation.yml

Inputs read: card #29067 body and all five comments (claim, os-dev-report, parked note, release, the round-2 domain:spec#1 claim), PR #29101 body, file list, both PR comments, the net diff against main, the 65 check-runs on the head, consumer cards #29041 / #29042 / #29068 and the #28920 precedent. The rest of the diff (generated api-surface/, export-origins/, declaration-map/, json-schema.manifest/, content/docs/references/**, the strictness-ledger counts, the three new test files and the changeset) is the lane seat's ACCEPT at TIER_DEFAULT; the changeset and the two authorable-surface shards are READ here to judge ② and are not reviewed.

① Derived judgments

Gate verdicts on the head (the check-runs, not re-run): 60 success or skipped; two red lanes, both this diff's doing:

• Check Changeset — red: Metadata-protocol: none and @objectstack/spec: patch while the diff moves packages/spec/authorable-surface/api.json and system.json (none-baseline-moved). The gate prescribes Metadata-protocol: added and at least minor. Judged under ②.
• TypeScript Type Check → Type Check · source gates — red at check:llms-txt: packages/spec/llms.txt declares system 37 (tree 38), api 33 (tree 34), heading 213 (tree 215). The two new modules system/push-config.zod.ts and api/push-delivery.zod.ts are the delta and the PR does not touch llms.txt. Must-fix (M2 below).
• Spec property liveness green — read as absence, not classification: the ledger's denominator is the registered metadata kinds plus the unregistered-kind and spec-only overrides (liveness/README.md); api.json governs ApiEndpointSchema, and no ledger governs RegisterDeviceRequest, PushDeliveryData or PushServiceConfig. The planned-marker rule is judged by hand under ④ (M3).

Accept-set and public-surface changes the diff implies, each judged:

• RegisterDeviceRequestSchema gains optional vendor (PushVendorSchema), appId, locale; token / platform / deviceId / name unchanged, no .default(), bare alias isomorphic — right as a widening. One caveat the changeset words wrong: the object is non-strict, so a body carrying a stray vendor: 'hms' was STRIPPED and accepted before and is REFUSED now. No served route reads this schema at this head (the client re-exports the type only, packages/client/src/index.ts; the device methods were removed in 21 client SDK methods target routes no server surface mounts — delete on the open major train, or build the servers (#3587 finding) #3612), so no sender exists — a widening in fact, but "nothing a client writes today is refused" is not the exact statement. Should-fix wording (S5).
• RegisterDeviceResponseSchema, UnregisterDevice*, the *Preferences* schemas and DEFAULT_NOTIFICATION_ROUTES unchanged; the route-catalog pin (3 endpoints) green — right (ruling 2 on the card thread, ADR-0049: a route row with no handler is not registered; the rows ride notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068).
• New public schemas: PushVendorSchema, PushRouteSchema, PushDeliveryDataSchema (api/), ApnsTransportConfigSchema, FcmTransportConfigSchema, PushServiceConfigSchema (system/), exported through api/index.ts and system/index.ts; six z.input aliases, pin count 811 → 817 — right (no default, no transform in any of the six). PushRouteSchema and PushVendorSchema are exported without lazySchema; dispatcher.zod.ts and plugin-rest-api.zod.ts carry the same precedent and lint is green — right.
• INotificationService gains optional registerDevice, unregisterDevice, invalidateDeviceToken typed from api/protocol.zod — right; the send-only implementation stays complete (tested), and contracts/automation-service.ts already imports FlowRegistration from the same module, so the layering has precedent.
• api/protocol.zod.ts imports PushVendorSchema from system/push-config.zod.ts — right on precedent (ServedTranslationDataSchema from system/translation.zod). ADR-0012 §10 names notification/device.zod.ts as the home; no packages/spec/src/notification/ exists on main, and system/notification.zod.ts is the live home of the channel enum, so system/ is the right directory.
• The authorable-surface shards gain 14 keys (api/PushDeliveryData:notificationId|route, api/RegisterDeviceRequest:appId|locale|vendor, system/ApnsTransportConfig:environment|keyId|keyRef|teamId|topic, system/FcmTransportConfig:projectId|serviceAccountRef, system/PushServiceConfig:apns|fcm) — this IS a metadata-protocol added by the gate's own definition. Wrong as declared (none); see ②.
• The PushDeliveryDataSchema JSDoc's derivation claim (explicit payload.url / payload.actionUrl, else /OBJECT/ID from the emit's source, else none) — right against messaging-service.ts#actionUrlFor and the notify node's source forwarding (notify-node.ts, the explicit actionUrl wins). No notify key added — right, the card preferred derivation.

② Semver level

• Clause-②: yes (widening) on the PR body and the changeset — right for the diff (every change is additive; see the one wording caveat in ①).
• Metadata-protocol: none and '@objectstack/spec': patch — wrong. The authorable-surface baseline moved by 14 keys; AGENTS.md Post-Task step 3 and the Check Changeset step (pr-automation.yml, "WHICH LEVEL") say a new authorable key is added and takes at least minor on the package the diff moves, and the gate refused this head on exactly that line (none-baseline-moved). The round-2 claim on the card already declares Metadata-protocol: added; the PR body and changeset have to say the same. The PR body's argument ("no authoring door reads these") is the planned-marker question (④ M3), not a reason to grade none — feat(spec): an oauth2 authorization_code connector instance can take its OAuth client from the installer — clientSource: 'installer' #28920 is the precedent: clientSource was unread at its head and still declared added / minor with the marker. Must-fix M1: Metadata-protocol: added on the PR body and in .changeset/29067-push-device-registry-spec.md, level minor.
• No ADR-0087 disposition owed: nothing an author can write is renamed, removed or changed in meaning. Right.

③ Boundary flags

Dev flags and open_questions (the os-dev-report lists none; the out-of-scope finding on DEFAULT_NOTIFICATION_ROUTES' JSDoc goes to #29068 — accepted):

• Wanted 2 (route rows) deferred to notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068 — answered: ADR-0049 retired handlerStatus: 'planned', the runtime conformance test reds a catalog POST row with no served case, and the round-2 claim rules the same. Accepted.
• Wanted 3 (UserDeviceSchema) declined in the PR body as "ruling 3" — not accepted: the card asks for it, and the first server consumer notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068 names "sys_user_device per spec(notification): the push device registry's protocol face and the push payload route (spec slice of #29041) #29067's UserDeviceSchema" with ⛔ no packages/spec/** hunk of its own, so at this head the stored shape can be written by nobody. The round-2 claim on the card already re-adds packages/spec/src/system/push-device.zod.ts. Must-fix M5 under ④.
• Wanted 4 asks for four members (register, unregister, list for a user, invalidate); three are shipped and the omission is not explained in the PR body. No consumer at this head needs the list member (notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068's routes are register/refresh and unregister), so escalated to the seat: add listDevices?(userId) or record the ruling that drops it. Should-fix S4.
• Wanted 6, "the .p8 key by credentialRef" / "service-account JSON by credentialRef" — the diff names keyRef and serviceAccountRef. Judged under ④ M4.
• Wanted 7 (NotificationChannelSchema JSDoc) rides the server slice — answered; the JSDoc on main still says push has no delivery implementation, which is true at this head. Accepted; hand-off named (Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041).
• Cloud-side surface: none proposed, none filed — answered; the PR says so, and nothing in the config shape is hosted-only.
• Verification not measured locally (dispatch-gates battery, full spec test and typecheck, scoped lint, final merge) — CI answered it: the two reds above are the result the battery would have shown.

New public names — each needs the maintainer's approval before landing (escalated, not FAIL reasons):

• Schemas and types: PushVendorSchema / PushVendor, PushRouteSchema / PushRoute, PushDeliveryDataSchema / PushDeliveryData, ApnsTransportConfigSchema / ApnsTransportConfig, FcmTransportConfigSchema / FcmTransportConfig, PushServiceConfigSchema / PushServiceConfig.
• Keys: RegisterDeviceRequest.vendor, .appId, .locale; PushDeliveryData.notificationId, .route; PushServiceConfig.apns, .fcm; ApnsTransportConfig.teamId, .keyId, .topic, .environment, .keyRef; FcmTransportConfig.projectId, .serviceAccountRef.
• Values: vendor ∈ apns | fcm; environment ∈ sandbox | production.
• Interface members: INotificationService.registerDevice, .unregisterDevice, .invalidateDeviceToken.

④ Design judgment

packages/spec/src/api/protocol.zod.ts — against ADR-0012 §6, #29068 (server) and #29042 (ui):

• Holds: the three members are optional; vendor is the closed PushVendorSchema (an unknown vendor is invalid_value at vendor, five cases tested, including APNS and the empty string); the owner is the session's user and never a body member; refresh-by-deviceId and server minting are stated in the describe.
• M3 (must-fix, shared with the other two schema files): no key added by this PR is read by any consumer at this head (census: no reader of PushDeliveryData*, PushServiceConfig*, PushVendor* or the three members outside packages/spec; the client holds a type re-export only), and no describe carries the [PLANNED — not enforced] marker naming the card that will read it. The feat(spec): an oauth2 authorization_code connector instance can take its OAuth client from the installer — clientSource: 'installer' #28920 precedent (connector-auth.zod.ts#clientSource) is the shape: the marker opens the describe, names the reader and the slice that lands it, and the comment above it says what takes the marker off. Here: vendor / appId / locale are read by notifications: build the device registry (sys_user_device, /notifications/devices routes, client methods) on #29067's contract (server slice 1 of #29041) #29068; PushDeliveryData* and PushServiceConfig* by Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041. Where a liveness ledger governs the type, a planned row goes with it; none governs these three types, so the describe marker is the carrier (the ledger gate's green is not a classification). The JSDoc prose ("nothing reads this shape until the push channel plugin lands") is not the machine-read channel and is not on vendor / appId / locale at all.
• S1 (should-fix): the required / optional split is inverted against the ui consumer. Console: register the mobile shell's native push token after sign-in, unregister it on sign-out #29042's input is the shell's getPushToken() → { token, vendor }; the request REQUIRES platform and makes vendor optional, so the Console has to derive platform from vendor with no stated mapping, while the contract states only the reverse. State the vendor → platform mapping (apns → ios, fcm → android) or let platform be absent when vendor is present.
• S2 (should-fix): platform: 'web' with no vendor is left undefined ("web has no core vendor"). State the outcome at the contract: refused at the route, or accepted and never delivered.

packages/spec/src/contracts/notification-service.ts — against ADR-0012 §6 / §12 and #29068:

• Holds: optional members, one live owner per token, NOT_FOUND (not a distinct forbidden) for another user's device, the invalidated row kept and disabled with its time, re-registration re-enables. The toy implementation in the test exercises all three signatures.
• S3 (should-fix): ownership is stated per USER, not per device row. The same user re-registering the same token under a new deviceId (the server-minted id lost with the shell's storage; the shell exposes no stable device id) leaves two enabled rows for one phone and one token — a double push the contract permits. The toy registry already deletes every other row holding the token; say so in the contract: one row per token, the newest registration owns it, whoever the user is.
• S4: listDevices?(userId) (Wanted 4) absent — see ③.

packages/spec/src/api/push-delivery.zod.ts — against ADR-0012 §8 (data of the push body), #29041 ask 3 and #29042 acceptance:

• Holds. I tried to break PushRouteSchema: //host, /\host, / + tab or newline + /host, javascript:, a bare apps/..., the empty string are refused by the regex (^\/(?![/\\])[^\s\\\x00-\x1f\x7f]*$); \s in JS covers NBSP, U+2028/2029 and the other Unicode spaces; a percent-encoded %2F stays a path segment under any parser; /..//host normalizes to a path on the base origin (new URL, and pushState refuses a cross-origin result), so it cannot leave the server. The derivation (actionUrlFor) is read and matches the JSDoc; dropping, never failing, a route that does not pass is the right call for a delivery.
• M3 applies (reader Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041).

packages/spec/src/system/push-config.zod.ts — against ADR-0143 D3, ADR-0012 §4 / §6, card Wanted 6 and #29041:

• Holds on the security property: every block is strictObject from birth; an inline secret is refused by name under key / privateKey / p8 / authKey / signingKey / secret (APNs) and serviceAccount / serviceAccountJson / credentials / privateKey / secret / serverKey (FCM), each with the reference key as the prescription (tested, unrecognized_keys, message names the ref key); a PEM block or a JSON document pasted into the reference is refused by secretReference (^[^\s{}]+$). The vendor enum is closed (apns | fcm, .options pinned), and environment is closed. Placement beside email-config.zod.ts matches the card's "where per-environment email transport selection lives"; not wiring it into the stack definition before a reader exists is the right ADR-0049 posture.
• M4 (must-fix): the reference key is not the one D3 names. D3: "Every secret an author names is a credentialRef, resolved through CredentialResolver"; the card says the same twice. The diff names keyRef and serviceAccountRef and puts credentialRef in aliases, so an operator who writes the house spelling is REFUSED and sent to the new one. Each block holds exactly one secret, so credentialRef fits without ambiguity. Rename both to credentialRef (and move keyRef / serviceAccountRef to aliases), or carry the two new names to the maintainer with the reason D3 should not apply here; either way the record cannot pass a schema that refuses the ADR's own key.
• S6 (should-fix): APNs certificate-auth spellings (certificate, cert, p12, pem) are refused as unknown keys with no prescription; one guidance line saying token auth is the only transport closes it.
• M3 applies (reader Push channel: build the device registry routes (/notifications/devices) and the APNs + FCM transport that ADR-0012 marks "MUST ship M1" #29041, the push channel plugin).

packages/spec/src/api/index.ts, packages/spec/src/system/index.ts — the two export * lines are right and match the generated export-origins / api-surface shards.

• M2 (must-fix): the two new modules red check:llms-txt (Type Check · source gates): update packages/spec/llms.txt — system 37 → 38, api 33 → 34, heading 213 → 215 — and the Key Schemas prose of both rows (Push Config beside Email / SMS Config; Push Delivery under api), as the gate's header asks: the number and the row together.

M5 (must-fix, the missing file): card Wanted 3 — a UserDeviceSchema per ADR-0012 §6 narrowed to what core ships (vendor from PushVendorSchema, platform, token, deviceId, appId, locale, enabled, invalidated_at, last_seen_at), stating (a) user-owned or user-and-organization-owned, (b) one live owner per token, (c) the invalidation fields — is absent, and its first consumer #29068 is ordered to build sys_user_device on it with no spec hunk of its own. The round-2 claim on the card already names packages/spec/src/system/push-device.zod.ts; land it here with the [PLANNED — not enforced] marker naming #29068.

Must-fix: M1 (declaration and level), M2 (llms.txt), M3 (planned markers), M4 (credentialRef), M5 (UserDeviceSchema). Should-fix: S1–S6. No security mechanism finding: the inline-secret and off-server-route refusals hold as built; M4 is a rule-level naming conformance.

Implemented-by: claude/project-thread-d3h66h
Reviewed-by: session_01AavokzJ5DndAwitDXvKy4U

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Maintainer ruling: the new public names on this PR are approved · 2026-11-02T09:36Z

The maintainer answered triage's escalation of the new public names (contract review on head 088613be, ③) in the triage session, verbatim: 「要你批的新名字 同意」.

Approved, as listed by the review:

• Schemas and types:
  • PushVendorSchema / PushVendor
  • PushRouteSchema / PushRoute
  • PushDeliveryDataSchema / PushDeliveryData
  • ApnsTransportConfigSchema / ApnsTransportConfig
  • FcmTransportConfigSchema / FcmTransportConfig
  • PushServiceConfigSchema / PushServiceConfig
• Keys:
  • RegisterDeviceRequest.vendor|appId|locale
  • PushDeliveryData.notificationId|route
  • PushServiceConfig.apns|fcm
  • ApnsTransportConfig.teamId|keyId|topic|environment
  • FcmTransportConfig.projectId
• Values: apns|fcm and sandbox|production.
• Members: INotificationService.registerDevice|unregisterDevice|invalidateDeviceToken.

Two notes on what the approval does not settle:

• The secret references keyRef / serviceAccountRef are must-fix M4 of the review: ADR-0143 D3 and the card name the reference credentialRef. Renaming them to the ADR's credentialRef needs no new approval, because that name already exists. Keeping keyRef / serviceAccountRef is an ADR deviation, which the lane raises on its own.
• Any other public name the remaining must-fixes add, such as M5's UserDeviceSchema (named by the card), is listed at the next review and approved then.

The FAIL record's must-fixes still stand. This ruling approves names only.

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#1 · os-steve · session_01ADHkmPi25XXKx92Xmg4viS

Superseded by PR #29218 · 2026-11-02T09:44Z

The spec seat took #29067 over from server seat 5. Its card thread resumed this PR's three commits (to 088613be) on its own branch, claude/project-thread-cjde2j, merged main, and opened PR #29218, which carries everything here plus the card's remaining asks: UserDeviceSchema, INotificationService.listDevices, APNs/FCM secrets keyed credentialRef, and ADR-0049 [PLANNED — not yet served] markers. A session can push only its own branch, so this PR can't be updated in place. The seat closes it unmerged. Review continues on PR #29218.