No refusal test in this repo runs on the shipped path: every guard assertion uses the in-process handler, and all 37 hooks ship body-only through QuickJS #1167

Observation-class finding, measured while answering question 1 of #1075. Filed unassigned for triage; nothing here is currently red.

What was measured

pnpm build on origin/main (6bf8504) reports Skipping legacy runtime bundle (all 37 callables are body-only), and 37 of 37 hooks in dist/objectstack.json carry a body.source. So every hook in this app ships as a lowered, metadata-only body evaluated inside QuickJS.

Every refusal assertion in test/ runs the other path. test/cascade-guard-messages.test.ts, test/hooks-runtime*.test.ts, test/freeze-guard-reference-cleanup.test.ts and the rest all reach the guard through objectstack.config.ts, where handler is a live function and body is undefined — so resolveHandler returns the closure and the sandbox is never entered.

The two paths produce measurably different error objects for the same guard. account_protection, unchanged, refusing the same delete on the same real kernel:

in-process (what the tests measure)
  ctor      : Error
  message   : "Cannot delete customer account: 1 open opportunity still references it. Close or reassign it first."
  own props : ["stack","message"]

shipped body through QuickJS (what users get)
  ctor         : SandboxError
  message      : "hook 'account_protection' threw: Error: Cannot delete customer account: 1 open opportunity still references it. Close or reassign it first."
  innerMessage : "Cannot delete customer account: 1 open opportunity still references it. Close or reassign it first."
  own props    : ["stack","message","name","innerMessage"]

Full measurement, both legs and the rig used: #1075 (comment).

Why it is worth recording

• The wording pins from 删除被级联守卫拦下时,报错文案指向了错误的对象("删除客户"报成"Cannot delete contact") #693 / fix(hooks): 被拦下的删除要指名真正拦它的那条记录 (#693) #719 are a real contract, and they are taken on a path that does not ship. They pass today because they use toContain and the original sentence is a substring of the wrapped one — that is luck, not coverage. A future change to the guard's phrasing would still be caught; a change to how the runtime wraps the sentence would not be.
• More generally, this is why No refusal in this app carries an error envelope: every business rejection reaches REST as a bare Error with code and status undefined #1075's question 1 could sit open: the repo has a test/helpers/action-sandbox.ts harness that runs the shipped body under the real QuickJSScriptRunner, and it is used for lowering constraints and for ctx.api shape, but not for a single refusal.

What is NOT established

Whether a REST consumer actually sees the wrapped sentence. @objectstack/rest reads err.innerMessage in at least one place, so it may well surface the unwrapped one. No HTTP server was booted for this — see the "does not establish" section of the #1075 comment. This finding is about test coverage, not about a known user-visible defect. If the REST hop turns out to unwrap, the coverage gap is still real and the wording pins still measure a path that does not ship.

Suggested shape (not decided)

Cheapest useful step is one refusal case per guard class re-taken through runHookBody from test/helpers/action-sandbox.ts, asserting the sentence the shipped path produces. That overlaps #1075's question 3 (sweep scope) and should probably be sequenced with it rather than ahead of it.