[objectstack-fleet]

domain:devx#1 · sunhaolin · session_017xRBcVy4VXmkQjn2MGeaWk

Clause-②: yes (narrowing) — the REST send door refuses callers and bodies it admitted (the breaking half), and the published IEmailService contract gains an optional getDefaultFrom() (a widening, the same move as isConfigured() on the same interface). No spec key, export or config field is removed or renamed.
Metadata-protocol: none
Skills-docs: none — no file under skills/** teaches POST /api/v1/email/send, client.email.send or IEmailService (a git grep of skills/ for each names nothing), so no skill line changes. The runtime-services page, content/docs/kernel/runtime-services/email-service.mdx ("Over HTTP"), states the four bounds in this change.

No tracking issue: this hardening was sent straight to a dev seat, so the body has no closing line.

Review tier: this change narrows who may call a public REST door and what they may send through it. It needs one contract-review-tier review of the current head before it enters the queue.

维护者速读

• 改了什么: REST 发信接口 POST /api/v1/email/send 在发送前做四道校验,不满足一律 403 PERMISSION_DENIED、不发信:① 调用方须持有 manage_platform_settings;② sentBy 一律记为当前登录用户;③ 发件人限定为部署配置的发件地址,自定义 headers 只接受"字符串到字符串"的普通对象(合法头名、单行值),且不得设 From/Sender/Return-Path;④ 邮件日志行的 organizationId 由服务端取调用方当前组织,不接受调用方另填别的组织,也不接受 identityMail(身份类邮件只由服务端自己发)。SMTP 通道把自定义头按"一个键一个头"的显式列表交给 nodemailer。
• 为什么改: 这个接口原来只校验"已登录",请求体几乎原样转给邮件服务:谁都能用部署自己的邮件通道发信、自选发件人和署名、把日志记到任意组织名下。现在由服务端决定发件人、署名和归属组织(ADR-0124)。
• 风险与回滚: 直接调此接口、但无该权限的集成会收到 403;带非配置发件人 from、他人 sentBy、别的组织 organizationId、identityMail: true,或自定义头不是普通字符串对象的调用都会被拒。flow、通知、认证邮件走服务内部调用,不受影响。回滚即 revert 本 PR。
• 先看: ① packages/rest/src/email-routes.ts:headersRefusal() 与第 4 道(组织/身份邮件)分支,以及转发前的 organizationId 盖章;② packages/plugins/plugin-email/src/transports/smtp.ts:自定义头改为显式列表;③ packages/rest/src/email-send-door-bounds.test.ts。
• 两分钟验证: pnpm --filter @objectstack/rest exec vitest run src/email-send-door-bounds.test.ts,预期 36/36 通过。
• 需要你做的: 定夺发信门槛:沿用 manage_platform_settings(本 PR 现状),还是另立专用的发信能力(需在 spec 的 PLATFORM_CAPABILITIES 新增一项,另起一张卡)。本 PR 保持现状,等你一句话。

What changes

POST {base}/email/send (packages/rest/src/email-routes.ts, both the unscoped and the environment-scoped mount) now applies four bounds between the auth floor and the send. Each one answers before the mail service is called, and each refusal is 403 PERMISSION_DENIED in the nested ADR-0112 envelope ({ error: { code, message } }), the shape enforceAuth already uses:

1. Capability. The caller must hold manage_platform_settings (EMAIL_SEND_CAPABILITY), read from the resolved context's systemPermissions. It is the capability the mail settings namespace reads and writes on, the one sys_identity_email requires for the whole row, and the one sys_email requires for its two body columns (body_text, body_html; the rest of a sys_email row is not gated on it). The check runs before the provider lookup, so a refused caller gets the same answer whether or not mail is wired.
2. Attribution. sentBy is always the authenticated caller. A body that names a different user is refused; a body that names the caller, or no one, is stamped with the caller.
3. Sender. The envelope sender is the deployment's configured sender (IEmailService.getDefaultFrom()). A from naming another address is refused; one naming the configured address is accepted and the configured value is forwarded in its place. A service that cannot report its sender, or a deployment with none configured, refuses a caller from. Custom headers are accepted in one shape only, the contract's string-valued header map: a plain object whose every key is a header field name (printable ASCII, no space, control character or colon) and whose every value is a single-line string. Any other shape is refused, and so are custom From, Sender and Return-Path headers, so the reserved-name check reads each header exactly as a transport will.
4. Organization. The message's mail-log row belongs to the caller's active organization: the door stamps organizationId from the tenantId the identity resolver vetted onto the execution context (the source meta-item-read-gate.ts documents), and the service stamps it verbatim onto sys_email.organization_id. A body naming another organization is refused, and so is a body naming one when the caller has no active organization. identityMail is refused for any value but false: identity mail is sent by the server itself, and its log is not a destination an HTTP caller chooses. The forwarded message never carries the caller's identityMail.

replyTo is deliberately not bounded: SendEmailInput.replyTo declares it a caller-supplied Reply-To address and makes no sender claim of it, so there is no configured value to bound it to.

To support bound 3, IEmailService (packages/spec/src/contracts/email-service.ts) gains an optional getDefaultFrom(). plugin-email's EmailService implements it by reading the live defaultFrom, so a sender changed in the Mail settings is followed. The member is optional, so existing implementations stay valid, and the door treats a missing member as unknown.

plugin-email's SMTP transport (packages/plugins/plugin-email/src/transports/smtp.ts) now hands nodemailer custom headers as an explicit list of name/value entries, one per key of the headers map, so every key is read as exactly one header name. A well-formed map puts the same headers on the wire as before (the existing wire test, sys-email-payload.wire.test.ts, still reads them there).

Server-internal senders (flows, notifications, auth mail, the messaging email channel) call IEmailService.send directly and are unchanged.

Docs: the client.email.send JSDoc; content/docs/kernel/runtime-services/email-service.mdx ("Over HTTP", now four bounds and the replyTo note); the integration-system.email-template-render checklist clause, revision 10, whose step (d) now also drives the headers-shape, organization and identity-mail refusals and the organization stamp.

Tests

• packages/rest/src/email-send-door-bounds.test.ts (36 cases), through the real HonoHttpServer transport over a contract-typed mail-service double. Every refusal case also asserts the service was never called; every admission case asserts what it was called with.
  • capability: entitled 200 with the caller stamped and no from; unentitled or no capability set 403 with neither service nor provider called; no provider 403 vs 501; anonymous 401; non-object body 400;
  • sentBy: foreign 403, the caller's own 200;
  • sender: foreign from 403 (string and object forms), restated configured address 200 with the configured value forwarded, no configured sender or no accessor 403 for a caller from while a send without one succeeds, From / sender / Return-Path 403, other headers pass through;
  • headers shape (new, 10 cases): a list of entries, an object value, a number value, a multi-line value, a name with a space, a name with a colon, a non-ASCII name, null and a string are each 403 with nothing sent; an empty map and a well-formed map are forwarded as sent;
  • organization (new, 5 cases): an organization-scoped caller is stamped with its organization, a restated organization is admitted, another organization 403, a caller with no active organization naming one 403, and a caller with none sends with no organizationId forwarded;
  • identity mail (new, 4 cases): true, 'true' and 1 are 403 with nothing sent; false is admitted and the forwarded message carries no identityMail.
• packages/plugins/plugin-email/src/transports/smtp.test.ts: the field mapping now expects the list form, and a new case pins one name/value entry per key, in order.
• packages/spec/src/contracts/email-service.test.ts: a compile-time parity pin for getDefaultFrom, the way isConfigured is pinned (absent stays assignable; either address form or undefined accepted; a number, or an object without address, refused by @ts-expect-error in a file check:test-typecheck compiles).
• packages/plugins/plugin-email/src/email-service.test.ts (unchanged in this round): getDefaultFrom returns the constructor sender, follows setDefaultFrom, and is undefined when none is set.

Acceptance notes

• Capability choice (pending the maintainer). manage_platform_settings is platform-scoped, so an organization administrator cannot send through this door. That matches who can configure the transport today. A dedicated send capability would be a PLATFORM_CAPABILITIES addition and is left to the maintainer's decision; this PR keeps the current choice.
• Display name. A from that restates the configured address with its own display name is accepted, and the configured display name is sent. A per-send display name is no longer possible through this door.
• replyTo stays caller-controlled (see What changes). Bounding it would need a contract that reserves it, which SendEmailInput does not.
• Service-level header validation is not added: normalizeMessage still forwards any non-empty headers object from server-internal callers, which are typed against the contract. The HTTP door is the bound for outside input.

Verification

Tree objectstack-ai/objectstack at 1b5c8eef (all readings below were taken at this head unless a line says otherwise).

Package tests and typecheck (at 1b5c8ee)

• pnpm --filter @objectstack/rest test: Test Files 335 passed (335), Tests 6614 passed, 326 skipped. Exit 0. (+19 over the previous head: the 19 new door cases.)
• pnpm --filter @objectstack/plugin-email test: Test Files 44 passed (44), Tests 748 passed. Exit 0.
• pnpm --filter @objectstack/client test: Test Files 52 passed (52), Tests 680 passed. Exit 0.
• pnpm --filter @objectstack/spec test: Test Files 750 passed (750), Tests 22315 passed, 1 todo. Exit 0.
• typecheck exit 0 on all four (rest, plugin-email, client, spec); each check:test-typecheck OK, spec holding its ledgered 52 files / 240 errors unchanged, the other three at 0.
• Built first: the dependency closure of the four packages (--filter 'PKG^...', 38 packages), lock verdict command-exit 0.

Ablations (committed first; each leg mutated through scripts/ablation-replace.mjs in wrap mode, restored to HEAD and proven by blob hash and an empty git diff HEAD)

The door test resolves ./rest-server and ./email-routes from src, and smtp.test.ts resolves ./smtp.js from src, so no rebuild leg was needed. Every leg's restore read blob == HEAD (email-routes.ts 0cd9f8785d03, smtp.ts ad530551a057) with git diff HEAD empty, and git status --porcelain was empty after the last leg.

• Shape check disabled: 2 of 36 red (null, a string). The list-of-entries case stays refused by the value check.
• Field-name check disabled: 3 of 36 red (space, colon, non-ASCII name).
• Value check disabled: 3 of 36 red (object value, number value, multi-line value). The list-of-entries case stays refused by the shape check.
• Organization refusal disabled: 2 of 36 red (another organization; naming one with none active).
• Organization stamp removed: 3 of 36 red (the two stamp cases and the identityMail: false case, which also reads the stamp).
• Identity-mail refusal disabled: 3 of 36 red (true, 'true', 1).
• Identity-mail strip removed: 1 of 36 red (identityMail: false forwarded).
• SMTP list form reverted to the plain map: 2 of 26 red in smtp.test.ts (the field mapping and the list-form case).

Full dogfood battery (the Clause-② line carries the narrowing arm)

• At 1b5c8ee, after building the @objectstack/dogfood dependency closure (69 packages, exit 0): pnpm --filter @objectstack/dogfood test, no shard, no path. Test Files 348 passed, 3 skipped (351); Tests 2806 passed, 20 skipped (2826). Exit 0.

Derived gate families (node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, at 1b5c8ee)

• 110 derived. --ran reconciliation over the recorded exit codes: 110 derived, 109 run, 1 NOT-MEASURED, 0 UNRUN.
• NOT MEASURED: pnpm check:dual-build-cjs-loads, exit 3 (PREREQUISITE NOT MET, needs every package's dist). CI's Lint & Repo Gates is green on this head.
• check:skill-examples and check:type-check-debt first exited 3 on prerequisites (no client-react dist; the debt re-measure did not get a lock turn) and were re-run after the closure build: 272 prose examples type-check across 3 surfaces, exit 0; the type-check debt re-measure OK, 0 raw tsc errors, exit 0.
• The changeset gates: check-adr-0087-registration accepts the one declared-breaking changeset (BREAKING+bang+clause-②-narrowing) with not-required (no-migration-prescription); check-changeset-no-major driven offline with this body as the PR payload reads Clause-②: yes (narrowing), Metadata-protocol: none, a non-protocol change at patch, exit 0.
• The derivation warns its tree is behind origin/main, with 6 changed scripts/pm/ inputs; none of this PR's files changed on main in that range, so main was not merged.

CI on 1b5c8ee

50 check runs: 41 success, 9 skipped (opt-in and matrix placeholders, Lint UI path-skipped), 0 failure, 0 pending. All ten required contexts are success except Lint UI, which is path-skipped. The red TypeScript Type Check on the previous head 5ba07d1 was its Type Check · workspace lane cancelled by the push of 1b5c8ee, not a type error.

---

Generated by Claude Code

_{Body refreshed by the PM seat 2026-10-29T13:18Z after contract review 6497633638 (must-fix 1: the body carried the stale Clause-② line) and os-dev report 6497744791.}

🤖 Generated with Claude Code

https://claude.ai/code/session_017xRBcVy4VXmkQjn2MGeaWk

[github-actions]

📓 Docs Drift Check

This PR changes 4 package(s): @objectstack/client, @objectstack/plugin-email, @objectstack/rest, @objectstack/spec, touching 12 documentable anchor(s).

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

• content/docs/ai/connect-mcp.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/api/client-sdk.mdx (via IEmailService (symbol, a top-level interface))
• content/docs/deployment/cloud-connection.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/deployment/self-hosting.mdx (via IEmailService (symbol, a top-level interface))
• content/docs/kernel/contracts/index.mdx (via IEmailService (symbol, a top-level interface))
• content/docs/kernel/runtime-services/email-service.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/kernel/runtime-services/sharing-service.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/permissions/authorization.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/permissions/sharing-rules.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/protocol/kernel/error-handling.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/protocol/kernel/plugin-spec.mdx (via EmailService (symbol, a top-level class))

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

• content/docs/releases/implementation-status.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v12.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v15.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/releases/v16.mdx (via RestServer (symbol, a top-level class), manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/releases/v17/17-1.mdx (via IEmailService (symbol, a top-level interface), manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/releases/v17/17-2.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/releases/v17/17-3.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v17/17-5.mdx (via RestServer (symbol, a top-level class))
• content/docs/releases/v17/17-6.mdx (via manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))
• content/docs/releases/v18/18-1.mdx (via IEmailService (symbol, a top-level interface), manage_platform_settings (literal, a string literal in EMAIL_SEND_CAPABILITY))

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

• 1 anchor(s) matched too much of the corpus to be a work list: PERMISSION_DENIED (literal, 48 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 58 of 210 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 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; 97 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 — 174 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 57c51aab4d2f63293676e9412daed8a5fc54c1bc → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0e004ed7e0accd9eff51823b622b1dfe7c548b2b — the merge of head 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04 into base 57c51aab4d2f63293676e9412daed8a5fc54c1bc, 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 0e004ed7e0accd9eff51823b622b1dfe7c548b2b && git checkout 0e004ed7e0accd9eff51823b622b1dfe7c548b2b
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 57c51aab4d2f63293676e9412daed8a5fc54c1bc 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04 && git checkout -B drift-repro 57c51aab4d2f63293676e9412daed8a5fc54c1bc && git merge --no-ff 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04

node scripts/docs-audit/affected-docs.mjs --json 57c51aab4d2f63293676e9412daed8a5fc54c1bc

⚠️ 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 57c51aab4d2f63293676e9412daed8a5fc54c1bc → 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 5a8a02333cb35c9c4aa77e0656e65b54b9f69263 · 2026-10-29T07:54Z

Triage seat, under gap rule (b) (#27062): this head is over 60 minutes old with no record and no claim. The review runs at CONTRACT_REVIEW_TIER. If the lane claims or posts a record on this head first, triage withdraws.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 5a8a02333cb35c9c4aa77e0656e65b54b9f69263
Local-runs: none
Scope: packages/spec/src/contracts/email-service.ts + packages/rest/src/email-routes.ts, packages/plugins/plugin-email/src/email-service.ts, packages/plugins/plugin-email/src/transports/smtp.ts, packages/rest/src/email-send-door-bounds.test.ts, packages/spec/src/contracts/email-service.test.ts, .changeset/harden-rest-email-send-door.md

Inputs read: PR #27469 body, file list (12 files), net diff vs main at the head, all 2 PR comments (docs-drift advisory; triage claim), and the 50 check-runs on the head: 41 success, 9 skipped (opt-in / matrix placeholders), 0 pending, 0 failure. No card exists: the PR body says it was sent straight to a dev seat with no tracking issue, and no comment names one.

① Derived judgments

• Public surface, @objectstack/spec: IEmailService gains an optional getDefaultFrom?(): EmailAddress | undefined. Additive, implementer-optional, consumer-nullable. Right. check:api-surface is among the green Lint gates; the api-surface/contracts.json baseline lists exports, not members, so no baseline moves. Right.
• Public surface, @objectstack/rest: two new exports from email-routes.ts (EMAIL_SEND_CAPABILITY, SENDER_HEADER_NAMES). The package entry does not re-export email-routes.ts (module header, confirmed on the head), so the published surface of @objectstack/rest does not move. Right.
• Accept set of POST {base}/email/send (both mounts, unscoped and environment-scoped): narrowed on three axes. (1) An authenticated caller without manage_platform_settings in the resolved context's systemPermissions is refused 403 before the provider lookup; an absent or non-array systemPermissions reads as the empty set. Fails closed; same field the federation door (external-datasource-routes.ts) and the package door read, populated by core/security/resolve-authz-context.ts. Right. (2) sentBy differing from String(context.userId) is refused; the forwarded sentBy is always the caller. Right. (3) A caller from is admitted only when its bare lower-cased address equals the configured sender's, and the forwarded value is the configured object, never the caller's text; absent accessor or unconfigured sender refuses a caller from. Right, and airtight for the from field itself.
• Capability choice: manage_platform_settings is a declared platform capability (spec/security/capabilities.ts, PLATFORM_ADMIN set in eval-user.zod.ts). It is the readPermission/writePermission of the mail settings manifest (service-settings/src/manifests/mail.manifest.ts:52-53) and the object-level requiredPermissions of sys_identity_email. On sys_email it gates the two body columns (body_text/body_html), not the row: the docblock's "the sys_email log is gated on it" is right for the bodies only. Precision, not a defect.
• Envelope: the three refusals use the nested { error: { code, message } } shape enforceAuth writes; the 501/400 in the same handler keep their pre-existing flat shape. check:route-envelope is green on the head. Right.
• Server-internal callers unchanged: flows, notifications, auth mail and the messaging channel call IEmailService.send directly; the diff touches only the HTTP handler. Right.
• Wrong: the sender-header clause of bound 3 does not hold for every shape the wire can carry (④, must-fix 1).

② Semver level

• Changeset: patch on @objectstack/rest, @objectstack/spec, @objectstack/plugin-email, @objectstack/client; Metadata-protocol: none. Under ruling A (check-changeset-no-major.mjs) none takes patch on every entry, and the spec precedent for this exact kind of change (fccbd9d, IEmailService.isConfigured()) shipped as a Patch Change. Level: right. Check Changeset and PR-body guards are green.
• Clause-②: no is wrong against the diff. The diff adds an optional member to the published IEmailService contract, which is a widening of a public surface; the repo's own declaration for the identical move on the identical interface reads Clause-②: yes (widening: an optional member on IEmailService) (fccbd9d, spec CHANGELOG). The gate comment keeps Clause-②'s meaning as "does this diff widen or narrow a published accept set or public surface"; a no over an added contract member contradicts it. Must-fix 2: the PR body and changeset carry Clause-②: yes, with the arm the maintainer rules (below).
• Arm (escalated, not graded): the door now refuses callers and bodies it admitted. Precedent is split: d9d7edd (ADR-0069 gate added to doors that answered a held session) declared no (narrowing) with a BREAKING banner and an adr-0087: marker; 7a606a9 and 454bbb6 (adding manage_platform_settings to existing /meta doors) declared a bare no. If the maintainer reads this as the former, the line is yes (narrowing), the changeset gains the BREAKING banner and the ADR-0087 disposition marker (the migration paragraph is already present). The reviewer does not decide this; the maintainer does.

③ Boundary flags

• Dev flag, capability choice (org admins cannot send): answered. The capability matches who may configure the transport and read the identity log today; a dedicated send capability is a PLATFORM_CAPABILITIES addition and belongs to a decision, not this PR. Escalated to the maintainer as a follow-up decision; no change owed here.
• Dev flag, per-send display name lost: answered, by design under bound 3 (the configured object is forwarded verbatim). No change owed.
• Dev flag, organizationId / identityMail pass through unbounded: answered as acceptable for this head because the admitted caller is platform-scoped, but it stays open: a holder can stamp any organization_id on the sys_email row or route a message into sys_identity_email. Escalated for a follow-up card.
• Not flagged by the dev, raised here, replyTo is unbounded: a caller may direct replies to any address. Reply-To is not a sender claim and the PR does not claim to bound it; recorded as an open question for the same follow-up, not a defect of this change.
• Not flagged by the dev, raised here, headers shape: see ④ must-fix 1.
• No open_questions block exists on the PR or a card.

④ Design judgment

packages/spec/src/contracts/email-service.ts (hits). Judged against the ADR it cites (ADR-0124, the server is the enforcement point) and its first consumer, the REST door.

• The member is optional, zero-argument, and its docblock binds the consumer to read absence as UNKNOWN and refuse a caller-chosen from. The first consumer does exactly that: typeof emailService.getDefaultFrom === 'function' ? ... : undefined, then !configuredAddress refuses. The plugin-email implementation reads this.options.defaultFrom live, so it follows setDefaultFrom from the mail namespace; pinned in email-service.test.ts (plugin-email). The contract holds against both. No finding on the member itself.
• Should-fix (parity): packages/spec/src/contracts/email-service.test.ts pins the sibling optional member isConfigured at compile time (absent assignable; wrong return type refused). No equivalent pin is added for getDefaultFrom. The REST bounds test's Partial of IEmailService double type-checks the member indirectly, so the shape is not unpinned, but the spec's own contract test is where the repo pins this interface.

Cited code, read to judge the scenario the member is accepted against (the door's refusals fail closed):

• Bound 1 fails closed on every shape of systemPermissions (absent, non-array, array without the name). Bound 2 fails closed (strict inequality against the stringified caller id). Bound 3's from clause fails closed on every shape of from (null, empty, array, object without address, string with a trailing angle-bracket address that differs, string with the address placed anywhere but the end): addressOf yields undefined or a non-matching string, and the forwarded value is the configured object regardless. These hold.
• Must-fix 1: the sender-header clause of bound 3 does not hold for every headers shape the wire can carry. The name scan and the transport do not read the same container, so a reserved sender header can still reach the message on the inline path. ⛔ The mechanism is withheld from GitHub (maintainer rule on security findings, qa(checklist-test, RUNNER rule 2): a security finding met in a QA run gets no GitHub card at all — only a pm-dispatch fix dispatch — and every issue write of a run goes through pm-dispatch (maintainer, 2026-10-29) #27382), and the triage seat has handed it to the maintainer. Fix: before the name scan, refuse (403, the same envelope) any headers that is not a plain object whose every value is a string, or normalize it to that shape and scan the result, so the check and the transport read one container. Pin: one case in email-send-door-bounds.test.ts posting a headers value outside that shape from an entitled caller, asserting 403 PERMISSION_DENIED and that send is never called; and one asserting that a record with a non-string value is refused or coerced before send.
• The 17-case bounds test otherwise covers both sides of each bound through the real Hono transport, proves the service is never called on refusal, and proves the forwarded from is the configured object. The two existing email-door suites grant the capability only to measure what lies past the gate, which is the right repair. The ablation account in the PR body is not relied on; the tree is.

Implemented-by: claude/harden-email-send-door
Reviewed-by: session_01AavokzJ5DndAwitDXvKy4U

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Contract-review-claim: session_01AavokzJ5DndAwitDXvKy4U · head 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04 · 2026-10-29T13:00Z

Triage seat, under gap rule (b) (#27062): this head is over 60 minutes old with no record and no claim; a delta from triage's FAIL on 5a8a0233. The review runs at CONTRACT_REVIEW_TIER. If the lane claims or posts a record on this head first, triage withdraws.

---

Generated by Claude Code

[objectstack-fleet]

domain:devx#1 · sunhaolin · session_017xRBcVy4VXmkQjn2MGeaWk

Ruled: maintainer, in the PM session session_017xRBcVy4VXmkQjn2MGeaWk, 2026-10-29 · 2026-10-29T13:05Z

Question (human floor, from the contract review): which capability the REST email-send door requires. Answer, verbatim option chosen: 「沿用 manage_platform_settings」 — keep manage_platform_settings as implemented. Accepted cost: an organization admin cannot send through the door, and a send-only integration needs a settings-write capability. A dedicated send capability is not pursued now.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04
Local-runs: none
Scope: packages/spec/src/contracts/email-service.ts + packages/rest/src/email-routes.ts, packages/rest/src/email-send-door-bounds.test.ts, packages/spec/src/contracts/email-service.test.ts, packages/plugins/plugin-email/src/email-service.ts, packages/plugins/plugin-email/src/transports/smtp.ts, packages/plugins/plugin-email/src/transports/smtp.test.ts, packages/rest/src/meta-item-read-gate.ts, packages/core/src/security/resolve-authz-context.ts, .changeset/harden-rest-email-send-door.md

Inputs read: PR #27469 body, file list (15 files), net diff vs main at the head, all 3 PR comments (docs-drift advisory; the prior FAIL record on 5a8a0233; triage's claim on this head), and the 50 check-runs on the head: 41 success, 9 skipped (matrix placeholders and opt-in lanes), 0 pending, 0 failure. No card exists: the PR body says the work went straight to a dev seat, and no comment names one. This is a re-review on a moved head; the delta section at the end verifies every prior finding.

① Derived judgments

• Public surface, @objectstack/spec: IEmailService gains the optional getDefaultFrom?(): EmailAddress | undefined. Additive, implementer-optional, consumer-nullable; the api-surface/contracts.json baseline lists exports, not members, so nothing moves there and check:api-surface (Lint & Repo Gates) is green. Right.
• Public surface, @objectstack/rest: email-routes.ts exports EMAIL_SEND_CAPABILITY and SENDER_HEADER_NAMES; packages/rest/src/index.ts on this head does not re-export the module, so the published surface of the package does not move. Right.
• Behaviour, @objectstack/plugin-email (every sender, not only the door): SmtpTransport.send now hands nodemailer custom headers as an explicit list of name/value entries, one per key of the message's headers map, in key order; smtp.test.ts pins the list and its order. For a well-formed map this is the same set of header fields on the wire; the Postmark and Resend transports already consume the map their own way and are unchanged. Right.
• Accept set of POST {base}/email/send (both mounts): narrowed on four axes, each refused 403 PERMISSION_DENIED in the nested envelope before the service is called. (1) Caller must hold manage_platform_settings in the resolved systemPermissions; absent or non-array reads as the empty set; judged before the provider lookup. Right. (2) sentBy must be absent or the caller; the forwarded value is always the caller. Right. (3) A caller from is admitted only when its bare lower-cased address equals the configured sender's, and the configured object is forwarded in its place; an absent accessor or unconfigured sender refuses a caller from. headers is admitted in exactly one shape: a plain object (null or Object.prototype prototype, never an array) whose every key passes the RFC 5322 field-name grammar (printable US-ASCII, no colon) and whose every value is a string without CR or LF, and no key lower-cases to from, sender or return-path. Right. (4) organizationId must be absent or equal the caller's vetted tenantId; a caller with no active organization may not name one; identityMail must be absent or false; the forwarded message strips both caller fields and stamps the vetted organization when there is one. Right.
• Where bound 4's organization comes from: context.tenantId, the field resolveAuthzContext (core) sets from an API key's vetted principal or from the session claim after vetOrganizationClaim — a claim for an organization the caller no longer belongs to is dropped and ctx.tenantId deleted, so the door reads undefined and refuses a body that names one. meta-item-read-gate.ts's metaCallerOrganizationId reads the same field; one source, as the module header says. The service stamps the forwarded value verbatim onto sys_email.organization_id and reads no other organization. Right.
• Fail-closed on odd values: organizationId: null, identityMail: null, headers: null and from: null are each refused (the !== undefined guards admit only absence). Right.
• Envelope: the four refusals use the nested shape enforceAuth writes; the 501/400 in the same handler keep their pre-existing flat shape; check:route-envelope is green. Right.
• Server-internal callers unchanged: flows, notifications, auth mail and the messaging channel call IEmailService.send directly; only the HTTP handler and the SMTP header hand-off changed. Right.
• Still passed through unbounded: replyTo (the module header now says so and why), relatedObject, relatedId, cc, bcc, attachments. None is a sender, attribution or tenant claim; see ③.
• Wrong: the PR body's Clause-② declaration (② below).

② Semver level

• Changeset (.changeset/harden-rest-email-send-door.md): patch on @objectstack/rest, @objectstack/spec, @objectstack/plugin-email, @objectstack/client; title fix(rest)!: …; Clause-②: yes (narrowing) with the reasoning for both halves (the door's accept-set narrowing; the optional member's widening, the isConfigured() precedent); Metadata-protocol: none; the adr-0087 HTML-comment marker not-required (no-migration-prescription) with its facts; the **BREAKING** banner; and a "What changes for you" migration paragraph. Under ruling A none takes patch on every entry and a non-protocol narrowing keeps its banner and disposition at patch; check-adr-0087-registration.mjs reads the narrowing arm from the changeset and found its marker (Lint & Repo Gates green). Level right, arm right, disposition right.
• Must-fix 1 (carried from the prior record's must-fix 2, half resolved): the PR body still declares Clause-②: no. Line 1 of the body on this head reads Clause-②: no, with no arm, while the changeset in the same PR reads Clause-②: yes (narrowing). AGENTS.md §3 requires the declaration on both carriers; the in-CI semver gate (check-changeset-no-major.mjs, "ONE carrier: the fixed Clause-②: line in the PR body") reads the body alone and therefore records this PR as neither widening nor breaking, which is the exact condition the direction arm was ruled in to end ([finding] An accept-set narrowing owes a **BREAKING** banner in core but not in platform-objects — and the ADR-0087 classifier reads the banner #16421: a narrowing shipping with every gate green). No gate cross-checks the two carriers, so both are green while they contradict each other. Fix: the PR body's line 1 reads Clause-②: yes (narrowing), byte-identical in value and arm to the changeset's; Metadata-protocol: none stays. A body edit does not move the head; pr-automation.yml re-runs Check Changeset on edited, and patch under none keeps it green.

③ Boundary flags

• Dev flag, capability choice (organization administrators cannot send): answered; the capability is the one that configures the transport and reads the identity log; a dedicated send capability is a PLATFORM_CAPABILITIES decision, not this PR. Escalated to the maintainer as a follow-up decision; no change owed here.
• Dev flag, per-send display name lost: answered by design under bound 3; no change owed.
• Dev flag, organizationId / identityMail "not bounded here": superseded by this head, which bounds both (bound 4). The flag survives only in the stale PR body (should-fix 1).
• Raised in the prior record, replyTo unbounded: answered on this head in the module header, the changeset, the docs and the client JSDoc: it is a caller-supplied Reply-To and makes no sender claim. Stays an open question for the follow-up card, not a defect.
• Raised in the prior record, headers shape: resolved; ④.
• Raised here, relatedObject / relatedId pass through: a caller may link the mail-log row to any object name and record id (email-service.ts writes them as related_object / related_id). Activity-stream linkage, not a sender, attribution or tenant claim; the admitted caller is platform-scoped. Escalated to the same follow-up card as replyTo; not a defect of this change.
• Raised here, breadth of the reserved set: SENDER_HEADER_NAMES is closed at the three names the module header, changeset, docs and checklist clause state. Whether other RFC 5322 origin-stating fields should join it is a maintainer question for the follow-up card; the bound as stated holds (④).
• No open_questions block exists on the PR, and there is no card.

④ Design judgment

packages/spec/src/contracts/email-service.ts (hits). Judged against ADR-0124 (the server is the enforcement point) and its first consumer, the REST door, on this head.

• The member is optional, zero-argument, and its docblock binds a consumer to read absence as UNKNOWN and refuse a caller-chosen from. The first consumer does exactly that (typeof emailService.getDefaultFrom === 'function', then !configuredAddress refuses), and the shipped wiring (rest-api-plugin.ts, ctx.getService('email')) hands it plugin-email's EmailService, whose getDefaultFrom reads this.options.defaultFrom live and so follows setDefaultFrom from the mail settings namespace (pinned in plugin-email's email-service.test.ts). Holds.
• The prior should-fix is resolved exactly: packages/spec/src/contracts/email-service.test.ts now pins the member the way it pins isConfigured (an implementation without it stays assignable; both address forms and undefined are accepted; a number and an object without address are refused at compile time). No finding on the member or its pin.

Cited code, read to judge the scenario the member is accepted against (the door's refusals fail closed):

• Bound 1 fails closed on every shape of systemPermissions; bound 2 on every sentBy other than absent or the caller; bound 3's from clause on every shape of from (addressOf yields undefined or a non-matching string, and the configured object is forwarded regardless). These hold, unchanged since the prior head.
• The sender-header clause of bound 3 now holds for every headers shape the wire can carry. The door admits exactly one container, the contract's record of string to string, and refuses every other shape before the reserved-name scan; the SMTP transport hands nodemailer the admitted map as an explicit per-key name/value list; so the check and the transport read the same container, and the prior must-fix 1 is resolved exactly, with more than the pin asked for (the key grammar and the CR/LF refusal). Pin: packages/rest/src/email-send-door-bounds.test.ts, describe "headers is accepted as a plain string-valued map only": nine refused shapes (a list of entries, an object value, a number value, a multi-line value, a key with a space, a key with a colon, a non-ASCII key, null, a string), each asserting 403 PERMISSION_DENIED, a message naming headers, and send never called; plus the admitted empty map and well-formed map forwarded as sent; the three reserved names still refused by it.each; and packages/plugins/plugin-email/src/transports/smtp.test.ts pinning the list nodemailer receives, one entry per key, in order. ⛔ No reproduction and no mechanism is recorded here.
• Bound 4 holds against the code it cites: the vetted tenantId is the only organization the door reads, the caller's own value never reaches the service, and identityMail is stripped so the row cannot be routed into sys_identity_email. Pinned in the two tenant describes (five organization cases, four identity-mail cases), each refusal asserting send never called and each admission asserting what was forwarded.
• The 23-case bounds suite drives the real Hono transport over a contract-typed double; the two existing door suites grant the capability only to measure what lies past the gate. The PR body's ablation account is not relied on; the tree is.
• Should-fix 1: the PR body's account is stale on this head: "three bounds", "17 cases", organizationId / identityMail "not bounded here", and a Verification section taken at 5a8a02333c. The tree is judged, not the body, but the body is what the maintainer reads at landing; refresh it with the Clause-② line (must-fix 1).

Delta since the prior record (5a8a0233 → this head)

• Two commits, both single-parent on a linear seven-commit branch over merge-base 9462d8ad; no merge to recompute. 5ba07d1f54 adds headersRefusal and bound 4 to the door, the SMTP list hand-off and its pin, the spec contract pin, nine shape cases plus nine tenant and identity-mail cases, the module-header precision on which sys_email columns the capability gates, and the changeset's yes (narrowing) declaration, banner and adr-0087 marker, with the docs, checklist clause (revision 10) and client JSDoc restated for four bounds. 1b5c8eef84 rewords one refusal message to name the headers field (the shape cases assert that word).
• Prior must-fix 1 (sender-header clause): resolved exactly (④).
• Prior must-fix 2 (Clause-② on body and changeset): partly resolved — the changeset carries yes (narrowing) with the banner and the ADR-0087 disposition the escalated arm asked for; the PR body still carries no. Carried forward as must-fix 1 above.
• Prior should-fix (spec contract pin for getDefaultFrom): resolved exactly.

Implemented-by: claude/harden-email-send-door
Reviewed-by: session_01AavokzJ5DndAwitDXvKy4U

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

domain:devx#1 · sunhaolin · session_017xRBcVy4VXmkQjn2MGeaWk
os-dev-report

{
  "issue": null,
  "status": "done",
  "branch": "claude/harden-email-send-door",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/27469",
  "head": "1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04",
  "session": "session_017xRBcVy4VXmkQjn2MGeaWk — subagent run, the parent PM session's id",
  "premise_still_valid": true,
  "summary": "Rework of the REST email send door on PR 27469, two commits on top of 5a8a0233 (5ba07d1f, 1b5c8eef), pushed to the same branch with no force push; the PR stays draft. Must-fix 1: the door now accepts custom `headers` only as the contract's string-valued header map (a plain object, every key an RFC 5322 header field name, every value a single-line string) before the reserved-sender-name check, and refuses any other shape with 403 PERMISSION_DENIED in the door's nested envelope without calling the service. Two further gaps of the same class turned up while I measured it against nodemailer 10.2.1 in this tree. I fixed both in place under the bounded in-place exemption (same defect class, a mechanical fix, files already in this PR's reviewed scope, the same gate family). First, the SMTP transport (`packages/plugins/plugin-email/src/transports/smtp.ts`) now hands nodemailer the headers as an explicit name/value list, one entry per key. Second, header names must be valid field names. The mechanism and a local stream-transport reading are kept OFF GitHub, in the PM-only notes file /tmp/claude-0/-home-user-objectstack/bdda939c-7424-5594-af38-0e6fe5d7eeed/scratchpad/pr-27469/PRIVATE-mechanism-notes.md. Must-fix 3: the door stamps `organizationId` from the caller's vetted `tenantId` (the source meta-item-read-gate.ts documents). It refuses a body naming another organization, or naming one when the caller has none, and refuses `identityMail` for any value but false; the forwarded message never carries the caller's `identityMail`. Must-fix 2: the changeset now reads `fix(rest)!:`, `Clause-②: yes (narrowing)`, `Metadata-protocol: none` and a `Skills-docs:` line, carries a BREAKING banner and exactly one ADR-0087 marker (`not-required (no-migration-prescription)`, accepted by the gate), and stays patch on all four packages. Should-fixes: a getDefaultFrom compile-time parity pin in packages/spec/src/contracts/email-service.test.ts, and a module header that now says the capability gates the `mail` settings namespace, the whole `sys_identity_email` row and only the two body columns of `sys_email`. `replyTo` is deliberately left unbounded: SendEmailInput.replyTo declares it a caller-supplied Reply-To address with no sender claim, so the contract gives no configured value to bound it to. The capability choice (manage_platform_settings vs a dedicated send capability) is left as is, flagged pending the maintainer. Docs, the client JSDoc, the rest-server docblock and the integration-system checklist clause revision 10 now state all four bounds. CONFLICT, not resolved by me: the dispatch asks for the PR body to declare the new Clause-② line, but os-dev.md forbids a dev PATCH of a PR body ('PR 正文 dev 只写一次…⛔ 不 PATCH;事后要改的报告点名改法,席位代写'), and os-dev.md wins, so the body is unchanged. A complete replacement body is ready for the seat at /tmp/claude-0/-home-user-objectstack/bdda939c-7424-5594-af38-0e6fe5d7eeed/scratchpad/pr-27469/pr-body.md. It has no HTML comments and no angle-bracket fragments outside details/summary, and its Clause-② and Metadata-protocol lines read declared `yes (narrowing)` / `none` through scripts/pm/clause2-line.mjs. Suggested title: `fix(rest)!: require a send capability on the REST email door and bound the sender, headers, organization and identity mail`. Until the body is rewritten, the live PR body still says `Clause-②: no`, and its Acceptance notes still say organizationId/identityMail pass through.",
  "tests": "All at head 1b5c8eef, each under scripts/pm/os-verify-lock.sh, with each part's exit captured separately. rest test: Test Files 335 passed (335), Tests 6614 passed, 326 skipped, exit 0 (+19 = the new door cases; email-send-door-bounds.test.ts is 36 cases). plugin-email test: 44/44 files, 748 passed, exit 0. client test: 52/52 files, 680 passed, exit 0. spec test: 750/750 files, 22315 passed, 1 todo, exit 0. typecheck exit 0 on rest, plugin-email, client and spec; check:test-typecheck is OK on each (spec holds its ledgered 52 files / 240 errors unchanged, so the new @ts-expect-error pins are compiled). Targeted first: the door, rest.test.ts and meta-state-route-engine-outage files 266/266; the smtp, sys-email-payload.wire and email-service files 61/61 (the wire test still reads the custom header on the real nodemailer wire after the list-form change); spec email-service.test 8/8. The first targeted run went red 3/266 on my own refusal wording (the value message did not name `headers`). I fixed the message, not the test, and committed it as 1b5c8eef. Ablations: committed first; 8 legs through scripts/ablation-replace.mjs in wrap mode, src-resolved, so no dist leg was needed. Each leg landed on disk (anchor count 1 to 0, blob changed), went red as predicted and restored to HEAD (blob == HEAD: email-routes.ts 0cd9f8785d03, smtp.ts ad530551a057; git diff HEAD empty; git status --porcelain empty at the end). Results: shape check off 2/36 red (null, string); field-name check off 3/36 (space, colon, non-ASCII); value check off 3/36 (object, number, multi-line); org refusal off 2/36; org stamp removed 3/36; identityMail refusal off 3/36; identityMail strip removed 1/36; SMTP list form reverted 2/26 in smtp.test.ts. The list-of-entries headers case is covered twice: it stays green under the shape leg alone and under the value leg alone, because the other check still refuses it.",
  "gates": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at 1b5c8eef: 110 derived. The first stderr line names objectstack-ai/objectstack at 1b5c8eef, with a STALE TREE warning (behind origin/main; 6 scripts/pm inputs changed there). None of this PR's files changed on main, so I did not merge main (AGENTS.md MA-discipline 10). Every command ran with its exit captured before any pipe. --ran reconciliation: 110 derived, 109 run, 1 NOT-MEASURED (derived from a recorded exit 3), 0 UNRUN, exit 0. NOT MEASURED: pnpm check:dual-build-cjs-loads, exit 3 PREREQUISITE NOT MET (needs every package dist). check:skill-examples (no client-react dist) and check:type-check-debt (its re-measure never got a lock turn) first exited 3. After the closure build both were re-run: 272 prose examples type-check, exit 0; type-check debt re-measure OK, 0 raw tsc errors, exit 0. Changeset gates: check-adr-0087-registration accepts the one declared-breaking changeset [BREAKING+bang+clause-②-narrowing] as not-required (no-migration-prescription), exit 0. check-changeset-no-major driven offline (--event) with the proposed body: LEVEL AXIS reads yes (narrowing) + none at patch, exit 0. With the current live body it still passes, reading `no` + none, exit 0. Clause-② line checker (readClause2Line / readMetadataProtocolLine from scripts/pm/clause2-line.mjs): changeset and proposed body both read declared yes/narrowing and declared none. CI check-runs on 1b5c8eef: 50 runs, 41 success, 9 skipped, 0 failure, 0 pending. Required contexts: Lint & Repo Gates success, TypeScript Type Check success, Test Core success, Build Core success, Governed Surface Queue Guard success, Type Check UI success, Test UI success, Build & E2E UI success, Live E2E UI success, Lint UI skipped (path). The TypeScript Type Check red the PM flagged on 5ba07d1f was its 'Type Check · workspace' lane concluding cancelled at 11:18:29, superseded by my push of 1b5c8eef at 11:17:21 (the run's conclusion is cancelled). It was not a type error, and the same check is success on 1b5c8eef. Not run locally: test:repo (CI Test Core green); check:dev-prereqs and check:skill-frame-freshness (this round's spec change is a test file, not a spec build input).",
  "dogfood_battery": "1b5c8eef · dogfood closure built (69 packages, exit 0), then `pnpm --filter @objectstack/dogfood test` under the lock, no shard and no path (lock held 2198s; parts sequenced with ';' and each exit echoed: BUILD 0, DOGFOOD 0) · Test Files 348 passed, 3 skipped (351) · Tests 2806 passed, 20 skipped (2826) · no failures",
  "mcp_calls": "0",
  "api_writes": "1 — POST repos/objectstack-ai/objectstack/issues/27469/comments (this os-dev-report, via scripts/pm/post-stamped.mjs). Plus 2 git pushes to claude/harden-email-send-door (not REST). No PR body, label, assignee or draft-state write.",
  "deviations": [
    "PR body not edited: os-dev.md forbids a dev PATCH of a PR body and wins over the dispatch; a replacement body is staged for the seat (path in summary).",
    "Scope widened, bounded in-place fix: smtp.ts list-form headers plus the header-field-name rule close two same-class gaps beyond the dispatched fix (mechanism in the private notes file).",
    "Refusal status for an off-shape headers value is 403 PERMISSION_DENIED, matching the governing record's pin and the door's other bounds, not 400.",
    "identityMail: false is admitted (it restates the door's answer, like sentBy = caller); every other value is refused, and the forwarded message never carries the key.",
    "Commit trailer: the model-free pair AGENTS.md requires, not the harness reminder's model-named Co-Authored-By."
  ],
  "open_questions": [
    {
      "question": "Who writes the PR body and title for the Clause-② change?",
      "options": ["A the seat writes the staged body (scratchpad pr-body.md) and the `fix(rest)!:` title", "B the dev PATCHes it, against os-dev.md"],
      "recommendation": "A, because os-dev.md reserves post-open body edits to the seat, and the staged text already reads clean through the Clause-② reader and the offline level axis."
    },
    {
      "question": "Capability for the send door (human floor, left as is): keep manage_platform_settings or add a dedicated send capability?",
      "options": ["A keep manage_platform_settings (current)", "B add a send capability to PLATFORM_CAPABILITIES on its own card"],
      "recommendation": "Maintainer's call. The PR keeps A and its 维护者速读 names it as the one pending action."
    }
  ],
  "out_of_scope_findings": [
    "carrier: none · noted, not filed: plugin-email normalizeMessage forwards any non-empty `headers` object from server-internal callers without checking the contract's string-valued map shape. Those callers are typed, and the HTTP door is now the bound for outside input, so this is a read-only inference with no public door: it goes in the staged body's Acceptance notes, not on a card."
  ]
}

[objectstack-fleet]

domain:devx#1 · sunhaolin · session_017xRBcVy4VXmkQjn2MGeaWk

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04
Local-runs: none
Scope: packages/spec/src/contracts/email-service.ts + packages/rest/src/email-routes.ts, packages/rest/src/email-send-door-bounds.test.ts, .changeset/harden-rest-email-send-door.md, content/docs/kernel/runtime-services/email-service.mdx, scripts/pm/clause2-line.mjs

Delta record. Same head as the full record 6497633638 (triage seat, FAIL); the head did not move. The only change since is the PR body, rewritten by the PM seat (the PR's updated_at reads 2026-10-29T13:18:23Z; the body's own subscript names the refresh). This record judges that edit against its one must-fix and its should-fix 1, and closes the escalated capability item with the maintainer's ruling. Every other judgment of 6497633638 stands as written and is not redone here.

Inputs read: the PR body over the REST API (not the GraphQL view), the changeset on the committed tree, the door module, the bounds suite and the docs page on the head, the shared declaration reader scripts/pm/clause2-line.mjs on main, all four PR comments (two prior records, the docs-drift advisory, the maintainer ruling 6497474261), the body-edit-triggered workflow run 40880722841 and its Check Changeset job, and the 54 check-runs on the head.

① Derived judgments

• Prior must-fix 1 (the body carrier): resolved exactly. Line 3 of the PR body (the first non-blank line after the seat signature) now reads Clause-②: yes (narrowing) — …, and a byte comparison against line 10 of .changeset/harden-rest-email-send-door.md on the committed tree finds the two lines identical in full, reasoning sentence included. The shared reader clause2-line.mjs reads the arm as the first token of the parenthetical opened after the value and keeps trailing em-dash reasoning, so both carriers read yes with arm narrowing; the in-CI semver gate, which reads the body alone, now records this PR as a declared narrowing, which is the condition the prior record named. Right.
• Metadata-protocol: none on line 4 of the body, byte-identical to the changeset's line 11. The level follows the kind: none takes patch on every entry, and the changeset grades all four packages patch. Right.
• Skills-docs: line present and in the closed shape. Line 5 of the body reads Skills-docs: none — REASON, byte-identical to the changeset's line 12; the (narrowing) arm owes this third line and the none — REASON form is one of the four the dispatch skill admits. The reason holds on the committed tree: a git grep of skills/ at the head for email/send, client.email.send, IEmailService and getDefaultFrom names no file, and content/docs/kernel/runtime-services/email-service.mdx ("Over HTTP") states four checks, the organization and identity-mail refusals and the replyTo note. Right.
• Prior should-fix 1 (the stale account): resolved. The body now states four bounds, names organizationId and identityMail as bound 4 with the vetted tenantId as the one source, and counts the bounds suite at 36 cases. The tree agrees: email-send-door-bounds.test.ts holds 6 capability, 2 attribution, 9 sender (5 plus a 3-row it.each plus the pass-through case), 10 headers-shape (a 9-row it.each plus the admitted maps), 5 organization and 4 identity-mail cases, 36 in all, and the "+19 over the previous head" arithmetic matches the three new describes. The Verification section is taken at 1b5c8eef throughout. Right.
• The body edit moved nothing in the tree. The head is the same commit the full record judged; the file list, diff and changeset are unchanged, so ①'s accept-set and public-surface judgments of 6497633638 apply unaltered.

② Semver level

• Changeset: patch on @objectstack/rest, @objectstack/spec, @objectstack/plugin-email, @objectstack/client; Clause-②: yes (narrowing); Metadata-protocol: none; **BREAKING** banner; one adr-0087 marker not-required (no-migration-prescription). Unchanged since 6497633638, and that record's level, arm and disposition judgments stand.
• Body: the same three declaration lines, byte-identical. The two carriers no longer contradict each other; the sole must-fix of 6497633638 is resolved.
• The gate re-run the edit owed passed. pr-automation.yml fired on the pull_request event at 2026-10-29T13:18:27Z (run 40880722841, head 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04). Its Check Changeset job (123471196824) completed success at 2026-10-29T13:19:57Z, with the ADR-0087 disposition step and the "Guard against accidental major bumps" step both green against the rewritten body. The sibling PR-body guards job in the same event is success; Auto Label and Check PR Size are skipped by design on an edit.
• Check-runs on the head after the re-run: 54 in all, 43 success, 11 skipped (the nine the prior record named plus the two edit-event skips above), 0 failure, 0 pending. No base-signature exception is needed.

③ Boundary flags

• Capability choice: closed by the maintainer. Comment 6497474261 (PM session, ruled at the human floor) answers the escalated question verbatim: 「沿用 manage_platform_settings」, keep manage_platform_settings as implemented; the accepted cost (an organization administrator cannot send through the door; a send-only integration needs a settings-write capability) is recorded there, and a dedicated send capability is not pursued now. The head implements exactly that choice (EMAIL_SEND_CAPABILITY = 'manage_platform_settings', bound 1). The item escalated in 6497633638 ③ is closed; nothing is owed on this PR.
• Should-fix 1 (non-blocking, body prose only): the rewritten body still presents the capability choice as open — the 维护者速读 "需要你做的" bullet asks the maintainer to decide between keeping manage_platform_settings and a dedicated capability ("等你一句话"), and the Acceptance notes head "Capability choice (pending the maintainer)". The ruling predates the refresh by thirteen minutes. Reword both to cite 6497474261 as decided so the maintainer is not asked again at landing. No carrier, test or code is affected; this does not change the verdict.
• The other flags of 6497633638 ③ (replyTo, relatedObject / relatedId, the breadth of SENDER_HEADER_NAMES) stand as answered or escalated there to the follow-up card; nothing in the body edit touches them.
• PR author is objectstack-fleet[bot]; no external-author note is owed.

④ Design judgment

Unchanged from 6497633638 ④ and not redone: the body edit touched no file in hits or in the cited code, and the head sha is the same, so the judgments on packages/spec/src/contracts/email-service.ts, the door's four bounds and their pins hold as recorded there. No finding.

Implemented-by: claude/harden-email-send-door
Reviewed-by: session_017xRBcVy4VXmkQjn2MGeaWk

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:devx#1 · sunhaolin · session_017xRBcVy4VXmkQjn2MGeaWk

ACCEPT → head 1b5c8eef84dfeb09fbd6be44435f73f5ae85ab04 · 2026-10-29T16:43Z

维护者速读

• 改了什么：REST 发信入口 POST /email/send 加了四道限制：调用方须持有 manage_platform_settings;发件人只能是配置好的发件地址;headers 只接受字符串键值表，且不能伪造发件头;组织归属由服务端从调用方身份推出，identityMail 不接受外部传入。
• 为什么改：QA 第三轮发现的安全加固(细节按披露裁决不公开)。
• 风险与回滚：属于 BREAKING 收窄，过去能调通的请求现在返回 403;回滚即 revert 本 PR。
• 先看：packages/rest/src/email-routes.ts、packages/rest/src/email-send-door-bounds.test.ts。
• 两分钟验证：pnpm --filter @objectstack/rest exec vitest run src/email-send-door-bounds.test.ts,预期 36 个用例全过。
• 需要你做的：无。权限沿用 manage_platform_settings,已按裁决定案(评论 6497474261)。

席位意见：收。契约复核在本 head 上 PASS(6497855687,判的是 6497633638 之后的增量),dogfood 全套 348 个文件、0 失败。

席位核对

1. 形态：draft、目标 main;按披露裁决不建卡，正文无关闭关键词。
2. 前提实测：契约复核 6497633638 和 6497855687 都在本 head 上读过代码。
3. 门禁：本 head 共 43 个 success、11 个 skipped、0 失败;Lint & Repo Gates 和 TypeScript Type Check 都是 success。
4. 接受的偏差：replyTo、relatedObject、relatedId 仍可由调用方传入。它们不涉及发件人身份或租户归属，后续卡另行跟进。
5. 范围外去向：plugin-email 的 normalizeMessage 对内部调用方不校验 headers 结构，只记录，不立卡(没有外部入口能触达)。Skills-docs: none — REASON 属实。
6. 落地：不属于受管面，781 行，低于 3000 行上限 → pr_ready + automerge_enable。

---

Generated by Claude Code