service-automation: a flow `http` node that sets `signingSecret` sends its request unsigned on the inline arm (and on the durable arm's no-outbox fallback), while the published contract promises `X-Objectstack-Signature`

[objectstack-fleet]

Filing gate: ① a product defect with a named landing site.

• Class: (b) a declared capability not honoured, and (c) an authored key silently ignored.
• reach: measured at the executor seam every flow run takes, with a real request to a local receiver. The measurement was taken by the [security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590 dev in patch round 1 of PR fix(service-automation,metadata-protocol,runtime): withhold the remaining stored flow-credential positions at every depth, and answer a /meta list fault as itself (#20590) #20615, and is recorded in its os-dev-report on [security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590.
  • The flow's http node sets signingSecret, method: POST and a control header.
  • Non-durable (the default): the request arrives with the control header and with no X-Objectstack-Signature, and no signature-like header at all. The run reports success: true.
  • durable: true with no messaging outbox wired (the documented degrade to the inline arm): the same result, unsigned and success: true. The only log line is the existing inline-fallback warning, which does not say the signature was dropped.

Reader who acts: the triage seat (#6015) grades and routes it. It then goes to the domain:services seat. The fix lands in packages/services/service-automation/src/builtin/http-nodes.ts, the request/response arm below the durable branch.

Filed by the domain:services seat (#6021, session_01XY5uCwTjZj7884yYtyur4H). It comes from the at-tier contract review of PR #20615 (record 5886643746, escalation R2), measured in that PR's patch round 1. ⛔ Filed bare: grading and routing are triage's. ⛔ Not a claim.

What is declared, and what runs

• Declared, published: HttpConfigSchema.signingSecret in packages/spec/src/automation/io-node-config.zod.ts reads .describe('HMAC-SHA256 secret → X-Objectstack-Signature'). The http descriptor's configSchema in builtin/http-nodes.ts says the same. Neither says "durable only".
• Runs: only the durable arm hands signingSecret to the messaging outbox (enqueueHttp), which signs. The inline arm builds its fetch from cfg.headers and never reads signingSecret.
• So an author, human or AI, who sets the key on the default arm gets a request the receiving endpoint cannot authenticate, and no signal that the key did nothing. The same happens to a durable node on a host with no outbox.

Direction (a suggestion, not a ruling)

• Per the enforce-or-remove principle, a declared key that runs nowhere is an implementation gap: enforce it or retire it. ⛔ Do not narrow the description at the consumer.
• Enforce: the inline arm signs with the outbox's scheme, the same header and the same HMAC input, so one key means one thing on both arms. The durable no-outbox fallback then signs too.
• If signing cannot be honoured on a path, that path refuses loudly, never "unsigned and success: true". This is the answer the webhook precedents took: [security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542 refused to deliver unsigned when a stored secret did not resolve, and [security] the same stored-but-unresolvable collapse #8542 fixes for the signing secret is still open on resolveWebhookHeaders — the delivery goes out MISSING its authored headers #8558 did the same for its headers.
• Retiring the key or making it durable-only would be a contract change, which is the spec lane's work and moves Clause-②. That route is for the maintainer to choose, not the implementer.
• A pin: for each arm, with a signingSecret set, the received request carries a signature that verifies, or the node refuses.

Related, not the same

• [security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590 / PR fix(service-automation,metadata-protocol,runtime): withhold the remaining stored flow-credential positions at every depth, and answer a /meta list fault as itself (#20590) #20615: the same key's serving position (withheld from definition reads). This card is about its execution.
• [security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542 and [security] the same stored-but-unresolvable collapse #8542 fixes for the signing secret is still open on resolveWebhookHeaders — the delivery goes out MISSING its authored headers #8558 (closed): plugin-webhooks' own signing path, a different executor.

Dedupe

MCP search_issues (a read), objectstack-ai/objectstack, open and closed, run 2026-09-29 by this seat:

• "http node signingSecret inline request unsigned X-Objectstack-Signature": 1 ([security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542, closed, plugin-webhooks).
• "durable http callout fallback inline drops signature outbox not wired": 1 ([security] a dropped webhook subscription leaves no durable record — and the naive fix hands an operator a redeliver button that sends UNSIGNED #8069, closed, webhook redeliver).
• "flow http node signing secret not honoured non-durable request": 3 ([security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590, [security] the same stored-but-unresolvable collapse #8542 fixes for the signing secret is still open on resolveWebhookHeaders — the delivery goes out MISSING its authored headers #8558, [security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542).
• "HttpConfigSchema signingSecret describe declared not enforced": 2 ([security] Two more spec schemas permit inline credentials: ExternalDataSourceSchema.authentication (clientSecret/apiKey) and MessageQueueConfigSchema.sasl.password — census toward #7990's parked boundary-guard reopen trigger #8075, [security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542).
• None covers the flow http node's inline arm.

Dedupe words: http node signingSecret inline unsigned · durable fallback inline drops signature · X-Objectstack-Signature inline request

[objectstack-fleet]

Path: approvals and automation — a flow's outbound call is authenticated when its author says so | 缺项 (the http node's inline arm never reads signingSecret, so the request goes out unsigned and the run reports success: true) | P1

Triage: first grade — bug · security · priority:p1 · domain:services · area:workflow · pm:queue. Direction: enforce on both arms with the one existing scheme; refuse loudly where signing can't happen

Triage: lands in packages/services/service-automation/src/builtin/http-nodes.ts ⇒ domain:services.

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-09-29T10:52Z. ⛔ Not a claim, ⛔ not a dispatch.

Re-read on main by this seat.

• The request/response arm's fetch(url, { method, headers, body, … }) (http-nodes.ts:226) is built from cfg.headers alone. signingSecret (read at :123) reaches only the durable arm's enqueueHttp (:170).
• The durable no-outbox fallback (:211–214) warns that it degrades to inline, and then runs the same unsigned call.
• The scheme exists once: signBody / SIGNATURE_HEADER in packages/services/service-messaging/src/http-sender.ts:25, :50. It is sha256=<hex> of the HMAC-SHA256 over the exact body sent.

Why p1, not p0. NORTH-STAR rule 1 puts security first, and this is silent.

• The harm: an author who set the key gets a request the receiver can't authenticate, and a run that says success: true.
  • A receiver that verifies drops the call, and the flow's effect silently doesn't happen.
  • A receiver that doesn't verify was never protected anyway.
• Why not p0: it opens no path into objectstack's own data. An attacker gains nothing from it that they didn't already have against the receiver.

Direction (enforce, per the card's enforce-or-remove reading; ⛔ don't narrow the describe at the consumer).

• Both arms sign. When signingSecret resolves, the inline arm sends X-Objectstack-Signature computed over the exact serialized body it sends. The durable no-outbox fallback then inherits it.
• One scheme, not two copies. service-automation declares @objectstack/service-messaging as a devDependency only, so it can't import signBody at runtime as things stand. The seat either moves signBody and the header name to a package both already depend on at runtime, or takes it through the structural messaging surface the way enqueueHttp is taken. ⛔ No second hand-rolled HMAC input.
• Refuse, never send unsigned. If a path can't sign (the secret doesn't resolve, or a signer isn't reachable), the node fails with an error naming the key, never "unsigned and success: true". This is the [security] a stored webhook signing secret that resolves to null is treated as "authored unsigned" — the subscription arms and delivers UNSIGNED #8542 / [security] the same stored-but-unresolvable collapse #8542 fixes for the signing secret is still open on resolveWebhookHeaders — the delivery goes out MISSING its authored headers #8558 precedent.
• A GET with no body still signs, over the empty body the receiver sees. Pin the empty-body HMAC so the arms can't diverge.
• Pins:
  • For each arm (inline, and durable with no outbox), a node with signingSecret delivers a signature a local receiver verifies with signBody.
  • An unresolvable secret refuses.
  • A node without the key sends no signature header.

Not serial with PR #20615 (#20590): it touches flow-credential-projection.ts, not http-nodes.ts. It is the same key, but a different position (serving vs execution).

[objectstack-fleet]

Claim: PM loop round 1 · 2026-09-29T11:25Z
Session: session_01XY5uCwTjZj7884yYtyur4H
Account: os-justin (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-20628-http-node-signs
Worktree: objectstack-issue-20628
Domain: domain:services
Seat: domain:services (seat 1, seat post #6021)
Scope, per triage's grade 5888736223: both arms sign, one scheme, refuse where signing can't happen, a GET with no body signs the empty body, and the pins named there.
The seat's call on the one open choice, "one scheme, not two copies":

• The ruling: signBody and SIGNATURE_HEADER move to @objectstack/core, the lowest runtime package both service-automation and service-messaging already depend on. spec and types are contract-only and type-only.
• service-messaging keeps its existing exports as re-exports of the same binding, so nothing it publishes is removed.
• Why not the messaging surface: taking the signer through it would leave the durable no-outbox fallback, the very case with no messaging wired, unable to sign. Triage's direction has that fallback inherit the signature.
  File surface:
• packages/services/service-automation/src/builtin/http-nodes.ts and its tests.
• packages/services/service-messaging/src/http-sender.ts and src/index.ts (the scheme moves out, the exports stay).
• packages/core/src/ (one new module for the scheme, and its export). This is domain:engine's package, so a cross-lane notice follows.
• .changeset/20628-*.md.
• ⛔ Not packages/spec/**: the .describe() stays as published, now true.
  (stop on a breach outside these; explain in the report)
  Container & model: M, mode:subagent, model: opus (dispatch-gates --tier at 542670da: no path-derived mandate, floor sonnet · default opus · ceiling fable; a security fix across three packages with a published-surface move is design judgment ⇒ the default tier)
  Clause-②: yes (widening). @objectstack/core gains the exported scheme ⇒ at least minor for core.
  Thread-read: 5888736223
  Serial constraints cleared:
• Of the 8 open PRs at the claim, two touch these packages, and on other files: PR fix(plugin-security,core): security/explain answers enforcement's refusal at the object level, and explains another user in their organization (#20604) #20629 (plugin-security closeout (explain ≠ enforce): object-level security.explain answers allowed: true under a row-level policy comparing two fields of no shared class, while find refuses it with INVALID_FILTER / 400 #20604, this seat's) edits core/src/security/resolve-authz-context.ts, and PR fix(service-automation,metadata-protocol,runtime): withhold the remaining stored flow-credential positions at every depth, and answer a /meta list fault as itself (#20590) #20615 ([security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590, in the merge queue) edits service-automation's flow-credential projection. Neither touches http-nodes.ts, http-sender.ts, or core's entry. Triage: "Not serial with PR fix(service-automation,metadata-protocol,runtime): withhold the remaining stored flow-credential positions at every depth, and answer a /meta list fault as itself (#20590) #20615".
• This seat's in-flight dead tracker citations in the domain:services packages (629 sites, 112 numbers, 152 files): the ruling C+D stage for this lane (from #20556) #20596 stage 3 is in plugin-auth, disjoint.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 20628,
"status": "done",
"branch": "claude/issue-20628-http-node-signs",
"pr": "#20640",
"session": "session_01XY5uCwTjZj7884yYtyur4H",
"premise_still_valid": true,
"summary": "The outbound HTTP signature scheme moved to @objectstack/core as new root exports signHttpBody(body, secret) and HTTP_SIGNATURE_HEADER ('X-Objectstack-Signature'), in packages/core/src/security/http-signature.ts via security/index.ts. service-messaging keeps its published signHttpBody / HTTP_SIGNATURE_HEADER as re-exports of the same bindings, pinned by an identity test against the built packages; no second implementation remains. The flow http node's inline arm, and the durable arm's no-outbox fallback that degrades to it, now send X-Objectstack-Signature over the exact string passed as fetch's body: JSON.stringify(body), or the empty string when there is no body. The outbox arm is unchanged: it signs deliveryBody(payload) at enqueue. A non-empty authored signingSecret that resolves to undefined or '' after interpolation now refuses via refuseNode (a guard refusal, before the durable branch, so on every arm) and sends or enqueues nothing. An authored '' still sends unsigned on every arm. The refusal condition was measured: a whole {token} with no value resolves to undefined, which the contract parse accepts; a token valued '' or several empty tokens resolve to ''; null or a number is already refused by the contract parse, naming config.signingSecret; a partial template 'k_{token}' signs with 'k_', which fails loudly at the receiver and which the executor cannot tell from a real literal. Each arm, measured unsigned on main with a real local receiver at b9a7d91 (pins only, on 542670d): inline (default) YES, unsigned; durable with no messaging service YES, unsigned; durable with a MessagingService and no HTTP outbox YES, unsigned; durable with the outbox wired: already signed on main (a green control). A2: yes, both outboxes sign deliveryBody(payload), where the node passes payload body ?? {}. The inline serialization differs for a string body (JSON-quoted) and for no body (empty, versus '{}'). The pins verify signHttpBody(receivedBytes, secret) against the received header on every arm, and the empty-body HMAC is pinned as a literal. A4: core's main entry is Node-only and already imports node:crypto (api-key.ts, plugin-artifact-integrity.ts); only core/logger is browser-safe, and it was not touched. origin/main has moved 4 commits past the tested merge (3f45b6c to 04b202e). Of those, only engine.ts (flowLabel) overlaps service-automation, and none of them touches the changed files. The branch was not re-merged; CI and the queue rebuild on current main.",
"tests": "All at final head 62f989f unless stated. [RED first] b9a7d91: http-node-signing.test.ts 19 failed | 8 passed. The signing pins failed on each of the 3 in-process arms with 'AssertionError: no X-Objectstack-Signature arrived: expected undefined to be type of string', and the GET pin with 'expected undefined to be sha256=28c9179fd9763c0e7d41dc5241d9d7...'. The refusal pins failed with 'expected true to be false' (the run succeeded and the request went out unsigned). guard-refusal-inventory.test.ts new row: 1 failed | 15 passed (the fault edge routed it). [GREEN] those 2 files plus http-nodes.test.ts and http-delivery-outcome.integration.test.ts: 4 files, 56 passed. Full suites at 62f989f (after merging origin/main 3f45b6c): service-automation 153 files / 1895 passed; service-messaging 46 / 507; core --project local 57 / 1525; core http-signature.test.ts 3 passed. typecheck on core, service-messaging and service-automation: exit 0, test layers compile, no new debt. pnpm build --concurrency=2 over the whole tree at 62f989f: 72/72 successful. That covers every downstream consumer of @objectstack/core, including the runtime and plugin-hono-server export-star barrels. [ABLATION] at 1482879, fix committed first; http-nodes.ts and the test file are byte-identical at 62f989f. scripts/ablation-replace.mjs replaced the inline signing expression with '? headers': anchor 1 to 0, blob 2137f1ab2056 to 061481dd31ee. Result: 12 failed | 16 passed, exactly the 4 signing pins x 3 in-process arms, with the same two quoted assertions. Restore proven: blob 2137f1ab2056 == HEAD blob and git diff HEAD empty, re-proved by the script's own trap. No build/dist leg: the subject is the package's own src, read directly by vitest. [SCRATCH, not committed] secret-form table measured at the fixed head. Durable GET measurement (see findings).",
"mcp_calls": "0",
"api_writes": "3, each one relay stroke (POST /repos/objectstack-ai/objectstack/dispatches, run by fleet-write.yml as objectstack-fleet[bot]): (1) pr_create: POST /repos/objectstack-ai/objectstack/pulls, draft PR #20640 (body read back byte-identical, 10624 chars); (2) label-write assign: POST /repos//issues/20640/assignees with os-justin (read back: assignee os-justin; the labels documentation, size/l, tests and tooling were already there, written by the path labeler); (3) this report: POST /repos//issues/20628/comments. git push x5, which is not REST: the empty-branch probe, the RED pins, the fix, the changeset and the merge.",
"open_questions": [],
"out_of_scope_findings": [
"class: a · reach: executor seam only (engine.execute with a real MessagingService, MemoryHttpOutbox and HttpDispatcher on global fetch, and a local receiver). No public door was measured and no real producer is named (examples have no durable http node), so it is below the filing bar and was not filed · evidence: a durable: true http node with method GET enqueues payload {}. The dispatcher's send refuses a GET that has a body ('Request with GET/HEAD method cannot have body.'). After one tick the row showed status pending, attempts 1, that error, and the receiver had nothing, while the run reported success. The outbox would also sign such a bodyless GET over '{}' · dedupe words: durable http GET body outbox · GET/HEAD cannot have body sys_http_delivery · http node durable GET never delivers · carrier: 承接者:无 · noted in PR #20640 Acceptance notes",
"carrier: 承接者:无 · noted, not filed · flow-credential-projection.ts docblock says the durable arm hands signingSecret to the outbox, which signs every delivery. That is now incomplete, since the inline arm signs too; it is outside this card's file surface"
],
"arms_measured_on_main": {
"inline (default)": "measured unsigned on main (RED at b9a7d91)",
"durable, no messaging service (no-outbox fallback)": "measured unsigned on main (RED at b9a7d91)",
"durable, MessagingService with no HTTP outbox (no-outbox fallback)": "measured unsigned on main (RED at b9a7d91)",
"durable, outbox wired": "measured signed on main (a green control); an unresolvable secret was enqueued unsigned there (RED)"
},
"gates": "Head 62f989f, re-derived with dispatch-gates --commands --repo objectstack-ai/objectstack (65 commands; the dispatch-time list had 59, and the added families are engine-double-contract, objectql-double-limit, query-options-erasure, type-check-coverage, type-check-debt and where-matcher). 65 run, 65 exit 0, each exit code captured before any pipe. --ran reconciliation: 65 derived, 65 run, 0 NOT-MEASURED (a DERIVED zero). ⛔ rosters: 4 run, 4 exit 0 (node scripts/check-changeset-fixed.mjs, pnpm check:authz-resolver, pnpm check:error-code-casing, pnpm check:filter-alias-parity). Also run: pnpm check:published-readme-exports, exit 0. pnpm lint (repo-wide eslint --no-inline-config): exit 0. NOT MEASURED, because CI owns them: the 5 path-scheduled CI jobs (the Test Core shards, Temporal Conformance, the Dogfood shards), the 11 wide-population families and the 6 families with workflow-only argv values. PR CI conclusion not read at report time (in_progress).",
"line_budget": "n/a: no skills/** or governed ledger in the diff. The diff against merge-base 3f45b6c is 9 files, +491/-25 (516 changed lines, under the 5000 human-merge threshold).",
"deviations": [
"File surface: guard-refusal-inventory.test.ts (src/, not builtin/) gained one row. I read 'http-nodes.ts and its tests' as including the inventory row that drives the http executor, because the inventory header asks for each new guard to be added there.",
"Export names on core: the ruling's symbols signBody / SIGNATURE_HEADER are exported from @objectstack/core as signHttpBody / HTTP_SIGNATURE_HEADER. These are the exact names service-messaging already publishes, so each binding has one public name across both packages. A bare signBody / SIGNATURE_HEADER on core's root, which runtime re-exports with export-star, would sit beside the Ed25519 SIGNATURE_ALG and read ambiguously. service-messaging's http-sender.ts keeps the module-internal names as aliases of the same binding, so memory-http-outbox.ts and sql-http-outbox.ts (outside the surface) were not edited.",
"Not re-merged after 3f45b6c: origin/main is at 04b202e, 4 commits ahead, with no overlap on the changed files."
],
"files_changed": [
".changeset/20628-http-node-signs-both-arms.md",
"packages/core/src/security/http-signature.ts",
"packages/core/src/security/http-signature.test.ts",
"packages/core/src/security/index.ts",
"packages/services/service-automation/src/builtin/http-nodes.ts",
"packages/services/service-automation/src/builtin/http-node-signing.test.ts",
"packages/services/service-automation/src/guard-refusal-inventory.test.ts",
"packages/services/service-messaging/src/http-sender.ts",
"packages/services/service-messaging/src/index.ts"
]
}

[objectstack-fleet]

ACCEPT — PR #20640 at 62f989f1 · domain:services seat (#6021) · session_01XY5uCwTjZj7884yYtyur4H · 2026-09-29T12:39Z

Checklist, read on GitHub rather than from the report:

• Shape: a draft onto main, assigned os-justin. Fixes #20628 is line 1 and the only closing keyword. Line 2 carries Clause-②: yes (widening), as claimed. 9 files, +491 / −25. No governed path.
• Clause-②: yes (widening) is confirmed.
  • @objectstack/core's entry does export * from './security/index.js', and security/index.ts now exports HTTP_SIGNATURE_HEADER and signHttpBody: two new root exports, with core at minor.
  • @objectstack/runtime's entry also does export * from '@objectstack/core', so the two names become reachable through runtime's surface too, with no byte change in runtime. That is for the contract review to judge under ②.
  • service-messaging published signHttpBody / HTTP_SIGNATURE_HEADER on main before this PR (aliases of its internal signBody / SIGNATURE_HEADER). It still does, now as the SAME core bindings. Nothing is removed or renamed anywhere.
  • Marker: needs:contract-review goes on the PR with this ACCEPT.
• Naming deviation accepted. The seat's ruling named the module-internal spellings. The dev exported the names service-messaging already publishes, so each binding has one public name across both packages, and a bare SIGNATURE_HEADER on core's root would read beside the Ed25519 SIGNATURE_ALG ambiguously.
• Read at source: one HMAC implementation (core/src/security/http-signature.ts); http-sender.ts keeps its internal names as aliases of that binding and holds no createHmac. The inline arm signs the exact string it passes as fetch's body, or the empty string when there is none.
• Behaviour:
  • Every arm now signs.
  • A NON-EMPTY authored signingSecret that renders to nothing refuses the node, as a guard refusal on every arm, including the outbox arm, which used to enqueue such a delivery unsigned.
  • An authored '' still sends unsigned, which is the removal door [security] closeout: two stored-credential positions outside #20552's projection still reach a served read unredacted (a flow http node's signingSecret; the /meta list read's raw fallback) #20590 defined.
  • This is a runtime security behaviour inside what the contract already declared. It is not a Clause-② narrowing.
• Evidence:
  • Every arm was measured unsigned on main (red at b9a7d9115, 19 failed), with the outbox arm as the green control.
  • The ablation of the inline signing turned exactly the 12 signing pins red (4 × 3 arms), and the restore was proven.
  • The whole tree built, 72 / 72, which covers the export * barrels.
  • The 65 derived gates plus the 4 ⛔ rosters all exit 0.
• The guard-inventory row (guard-refusal-inventory.test.ts, outside builtin/) is accepted. The inventory's header asks every new guard to be listed there.

Findings, line by line:

• A durable GET enqueues {} as its payload, and the dispatcher's send refuses a GET with a body. The row stays pending and the run reports success → Acceptance notes, not filed. The reach is at the executor seam only, and no real producer is named (no example has a durable http node). The dedupe words are recorded in the report.
• flow-credential-projection.ts's docblock says only the outbox signs, which is now incomplete → Acceptance notes. The carrier is the next touch of that file.

Cross-lane: a notice to domain:engine (#6367) for the new core exports follows.

Landing waits for every check to be green on the head (running) and for the at-tier contract review that Clause-②: yes and the changeset prose owe.

---

Generated by Claude Code

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 62f989f1c227c94050384a95aa632ae6b6d19bb4
Local-runs: none

Inputs read: card #20628 (body and its four comments, ids 5888736223, 5889287363, 5890456215, 5890487087), PR #20640 (body, 9-file list, net diff against main from merge-base 3f45b6cc1), and the check-runs on the head. Read-only: nothing was built, run or re-run. Security family: defects below are stated abstractly, without a reproduction recipe.

Check-runs on the head, read at 2026-09-29T12:49Z: 23 completed success (among them Build Core, Check Changeset, Governed Surface Queue Guard, Temporal Conformance (live PG + MySQL), all three Dogfood Regression Gate shards, Test Core (2/6), Type Check · source gates, Type Check · consumer gates, Type Check · debt ledger, The card this PR closes must claim this branch), 6 skipped (path-filtered), 0 failure. Still in_progress at the reading: Test Core shards 1, 3, 4, 5, 6; Lint & Repo Gates; Type Check · workspace. Their conclusions are the gate verdicts; this record does not wait for them and the landing still requires every required context success (Multi-agent discipline §7). No governed path is in the file list, so no tier gate applies beyond that.

① Derived judgments

Public-surface changes the diff implies, each named:

1. @objectstack/core root gains two exports — RIGHT. signHttpBody(body, secret) and HTTP_SIGNATURE_HEADER come from the new packages/core/src/security/http-signature.ts through security/index.ts, which the root already re-exports with export *. Neither name existed anywhere in core, runtime or plugin-hono-server at the merge-base, so no collision; Build Core is green. core has no checked-in api-surface artifact (only spec does), so nothing was owed to a generator. node:crypto in a core main-entry module has precedent in the same directory (api-key.ts, plugin-artifact-integrity.ts, plugin-artifact-signature.ts); core/logger is untouched.
2. Transitive widening through export * from '@objectstack/core' in @objectstack/runtime and @objectstack/plugin-hono-server — RIGHT, and correctly disclosed in the PR body and the ACCEPT. No source in either package changes. Its changeset consequence is judged under ②.
3. @objectstack/service-messaging root is unchanged in names and types — RIGHT. signHttpBody, HTTP_SIGNATURE_HEADER, httpDeliveryBody, DEFAULT_HTTP_TIMEOUT_MS all still export; the first two are now the core bindings. http-sender.ts drops its own createHmac and re-exports the core pair under its module-internal names, so memory-http-outbox.ts and sql-http-outbox.ts (untouched) still import signBody / deliveryBody from it and sign exactly as before. One HMAC input remains in the repo; the identity pin in the new test holds it.
4. The flow http node's execution-time accept-set — RIGHT on every row. Read from the executor at the head, not from the card:
   • key absent → no signature header (unchanged);
   • authored '' → no header on every arm (unchanged; the deliberate unsigned spelling the card's sibling PR defined);
   • a literal, or a template rendering to a non-empty string → X-Objectstack-Signature on every arm. Inline arm and the durable no-outbox fallback: new. Outbox arm: unchanged, signs at enqueue;
   • a non-empty authored value rendering to undefined or '' → refused by refuseNode, placed after the contract parse and before the durable branch, so every arm refuses and nothing is sent or enqueued. New, and it is the "refuse, never unsigned with success" arm triage directed. Its message names config.signingSecret and the remedy, carries no tracker number and does not echo any secret value;
   • a non-string rendering → refused by the contract parse (unchanged);
   • a partial template rendering to a shorter literal → signs with that literal. Accepted limitation: the executor has no way to tell it from an authored literal, and the receiver's verification fails loudly. Guessing on string shape would be worse.
5. Which bytes are signed — RIGHT. The inline arm signs the exact string it hands fetch (JSON.stringify(body), or the empty string when there is no body); the outbox arm keeps signing deliveryBody(payload). The two serializations differ for a string body and for no body, which the PR body states; each arm signs what it sends, which is the only property a receiver can verify. Unifying the serializations would change the inline arm's wire bytes and is out of this card's scope. The empty-body HMAC is pinned as a literal in both the core test and the node test, so the fallback cannot drift to signing {} or null.
6. Header placement — RIGHT, noted. The signature is set after the author's headers under the exact header name, mirroring the outbox arm's existing behaviour on main; a differently-cased author header would travel beside it on both arms alike. Consistency with the outbox is the correct call for this card.
7. Spec untouched — RIGHT. HttpConfigSchema.signingSecret keeps its .describe(); the card forbade narrowing it at the consumer, and the runtime now honours it on every arm. The auto-generated reference page therefore needs no regeneration, and no hand-written page claims the key is durable-only (grep over content/docs at the head). ADR-0012's HMAC row names plugin-webhooks' own sender, a different package, so no accepted decision is reversed.
8. Pins cover every triage pin — RIGHT. For each of the three in-process arms and the wired-outbox arm: a verifying signature at a real local receiver (JSON body, string body, templated secret), the GET-with-no-body literal, no header without the key, no header for '', refusal for both empty renderings with the receiver seeing nothing and the outbox holding nothing. Plus the one-binding identity pin and the new guard-refusal-inventory.test.ts row, whose header requires every new refuseNode guard to be listed. RED-first at the pin-only commit and the ablation of the inline signing expression are recorded with quoted assertions in the report; consistent with the diff as read.
9. Test hygiene — RIGHT. The new test escapes its package through no filesystem path (package imports only), so check:cross-package-test-inputs has nothing to see; @objectstack/service-messaging is already a devDependency of service-automation; @objectstack/core is a runtime dependency of both services, so no package.json change was owed.

② Semver level

• Changeset .changeset/20628-http-node-signs-both-arms.md: @objectstack/core minor, @objectstack/service-automation patch, @objectstack/service-messaging patch. Matches what the diff publishes: two new root exports on core (widening ⇒ at least minor), a behaviour fix inside the declared contract on service-automation, and a same-name re-binding with no surface change on service-messaging.
• Clause-②: yes (widening) — on the PR body's second line and in the changeset body, consistent with each other; yes takes at least minor and core carries it. Not breaking, so no ADR-0087 disposition marker is owed. Check Changeset is success on the head.
• The newly refused case (a non-empty authored secret that renders to nothing) is not a Clause-② narrowing: the authorable shape is unchanged, the refusal is a run-time credential-resolution failure inside behaviour the contract already promised, and the card and triage directed it. The changeset states it as the one newly refused case.
• @objectstack/runtime and @objectstack/plugin-hono-server are not named in the changeset. Acceptable: the precedent that names them is for removals, so that the tombstone reaches the CHANGELOG an upgrader greps; for an addition inside the one Changesets fixed group they move anyway and nothing is greppable. The PR body's Cross-lane section discloses the reach.
• The changeset prose carries no tracker number and no model identifier; the refusal string carries no tracker number.

③ Boundary flags

open_questions: none. Dev flags, each answered:

1. Deviation — guard-refusal-inventory.test.ts outside builtin/. Answered, right: the inventory's own header asks that every new refuseNode guard be listed there, and the row drives the http executor. The seat accepted it on the card.
2. Deviation — export names signHttpBody / HTTP_SIGNATURE_HEADER instead of the claim's signBody / SIGNATURE_HEADER. Answered, right: they are the names service-messaging already publishes, so each binding has one public name across both packages; core's security index already exports the Ed25519 SIGNATURE_ALG, so a bare SIGNATURE_HEADER beside it would read ambiguously through the export * barrels. Accepted by the seat on the card.
3. Deviation — not re-merged after 3f45b6cc1; main is four commits ahead. Answered, right: those four commits touch none of the nine files (their only .changeset/ additions are differently named), and the PR reads mergeable. The queue rebuilds on current main.
4. Out-of-scope finding — a durable node with a bodyless read method never delivers while the run reports success (class a, reach at the executor seam only, carrier none). Answered, right per the filing gate: reach: requires a public door measured once or a named real producer, and neither exists (no example carries a durable http node). It sits in the PR's Acceptance notes with dedupe words, which is where the gate puts it. It is the seat's call, not the dev's, to lift it by measuring a public door or naming a producer; not escalated, because the disposition follows the rule as written.
5. Out-of-scope finding — flow-credential-projection.ts docblock now under-describes which arms sign (carrier none). Answered, right: a code comment outside the file surface, now incomplete rather than wrong; Acceptance notes is the correct place.
6. Acceptance note — header case. Answered under ① item 6.
7. Acceptance note — a durable node whose authored secret does not resolve now refuses where it used to enqueue unsigned. Answered: this is the intended enforce arm and is stated in the changeset.

Nothing escalated.

Implemented-by: claude/issue-20628-http-node-signs
Reviewed-by: session_01XY5uCwTjZj7884yYtyur4H

VERDICT: PASS

---

Generated by Claude Code