Recorded from the QA run #7439 (records-forms FULL area, object-hook-lifecycle PARTIAL — the run's one framework-side observation). Observation-class: hook lifecycle, condition semantics, and body execution are all correct; only the log capability's output cannot be captured.
The measurement (QA run, showcase app, --log-level debug)
Hook bodies fire ([BodyRunner] hook fired appears) and do not throw, but the named log lines the hook bodies emit via ctx.log.info(…) ("task completed: …", "project over budget: …") never appear, even at debug level. Three checklist clauses went partial solely because this oracle cannot be captured.
Anchors (verified at origin/main @ d13ce33)
packages/runtime/src/sandbox/body-runner.ts:
:339 — hook context: log: engineCtx?.logger:377 — action context: log: actionCtx?.logger
Both wire the ['log'] capability directly to the caller-supplied logger with no fallback and no warning when it is absent. If the engine context arrives without a logger (or with one that drops the level), the capability is a declared surface that silently produces nothing — an author cannot tell "my hook did not run" apart from "my hook ran and logged into the void". The BodyRunner's own diagnostics (opts.logger?.debug at :74) use a different logger (opts.logger), which was observable in the same run — so the two log paths diverge somewhere between opts.logger and engineCtx.logger.
Why finding, not queue
No incorrect behavior ships: hooks execute, conditions gate, data is right. The cost is observability (an authoring/debugging surface), and the fix needs a diagnosis first — where engineCtx.logger comes from on the showcase boot path and why its output does not reach the process log stream at debug level.
Dedup
Searched open issues (body-runner, ctx.log, hook log): no existing card. #7365 (QA assertion field path) is a different QA-tooling defect.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Recorded from the QA run #7439 (records-forms FULL area,
object-hook-lifecyclePARTIAL — the run's one framework-side observation). Observation-class: hook lifecycle, condition semantics, and body execution are all correct; only the log capability's output cannot be captured.The measurement (QA run, showcase app,
--log-level debug)Hook bodies fire (
[BodyRunner] hook firedappears) and do not throw, but the named log lines the hook bodies emit viactx.log.info(…)("task completed: …","project over budget: …") never appear, even at debug level. Three checklist clauses went partial solely because this oracle cannot be captured.Anchors (verified at
origin/main@d13ce33)packages/runtime/src/sandbox/body-runner.ts::339— hook context:log: engineCtx?.logger:377— action context:log: actionCtx?.loggerBoth wire the
['log']capability directly to the caller-supplied logger with no fallback and no warning when it is absent. If the engine context arrives without a logger (or with one that drops the level), the capability is a declared surface that silently produces nothing — an author cannot tell "my hook did not run" apart from "my hook ran and logged into the void". The BodyRunner's own diagnostics (opts.logger?.debugat:74) use a different logger (opts.logger), which was observable in the same run — so the two log paths diverge somewhere betweenopts.loggerandengineCtx.logger.Why finding, not queue
No incorrect behavior ships: hooks execute, conditions gate, data is right. The cost is observability (an authoring/debugging surface), and the fix needs a diagnosis first — where
engineCtx.loggercomes from on the showcase boot path and why its output does not reach the process log stream at debug level.Dedup
Searched open issues (
body-runner,ctx.log,hook log): no existing card. #7365 (QA assertionfieldpath) is a different QA-tooling defect.本评论来自分诊座位 Routine（#5474 试点），不构成认领。