`http_requests_total` never sees auth routes or the REST data API — the two highest-traffic inbound surfaces are outside the only HTTP counter the docs tell operators to monitor

[os-support-ai]

Blocked-by: #9832

⚠️ Status, 2026-08-19 (domain:cli seat, session session_01WeN7F6jQFpcqW2BN56RdPa): the maintainer-ruled Option-A transport seam landed via PR #9746 (152bff8fcd). This card stays open because the seam is inert in a shipped deployment — objectstack serve registers no metrics backend at all, so nothing resolves and no middleware installs. Sub-issues #9832 (the wiring), #9833 (dispatcher double-count), #9834 (duration/error metrics carry the same hole). Details in the ACCEPT comment below.

---

Filed by the triage seat (session session_01XZ5gajYBe7nCthCPdaTDvq) as the side-product of #9623's §1 measurement, which that card explicitly flagged as "worth its own look, but it is not what this card is about". Unassigned, finding, awaiting first-touch grading. The measurement is #9623's, verbatim provenance below; a claimant must re-verify on the current origin/main before treating it as scope.

The claim (measured in #9623 at b057e53f4)

http_requests_total has exactly one emitter, instrumentRouteHandler (packages/runtime/src/observability/instrument.ts:106). It is applied by a Proxy that packages/runtime/src/dispatcher-plugin.ts:700-721 builds over a local server binding from ctx.getService('http.server') — the proxy is never registered back as the service. Consequently:

• plugin-auth mounts on the raw Hono app (registerAuthRoutes → getRawApp() → rawApp.all(basePath + '/*'), packages/plugins/plugin-auth/src/auth-plugin.ts:1622,2240) — no sign-in traffic is counted.
• packages/rest resolves http.server itself (rest-api-plugin.ts:129) — the REST data API, i.e. the bulk of real traffic, is outside the counter too.

Why it is worth a card of its own

The docs' operator guidance (FAQ "what metrics should I monitor": 5xx rate, p95 latency — both derived from http_requests_total / http_request_duration_ms) is materially misleading if the counter covers neither the data API nor auth: a deployment can be melting down on /api/v1/* while the counters stay flat. This is a declared≠enforced shape on the observability surface — the SEMCONV registry declares the HTTP family as the stable namespace "so hosts can wire alerts/dashboards against it", and the wiring silently excludes the main surfaces.

What first-touch grading has to establish

1. Re-verify the two mount paths on current origin/main (the Decide whether SEMCONV should declare an auth-failure metric — nothing instruments authentication today, and 401/403 out of http_requests_total cannot stand in for it #9623 measurement is hours old).
2. Whether the fix is mechanical (register the instrumented proxy back as the http.server service, or instrument at the raw-app layer) or a design fork — if the proxy-registration order is load-bearing, this may need a decision.
3. Producer question: who owns the proxy wiring (dispatcher-plugin.ts, packages/runtime) — likely domain:cli by the lane table.

Refs: #9623 (provenance), objectstack-ai/objectos#96 / #87 (the docs half that keeps colliding with missing signals).

Dedup

search_issues is currently unreliable against this repo (multiple seats report 0-hit-with-failing-control today). Checked instead against this round's full open-issue listings and #9623's own all-229 dedup pass from ~1h ago, which found no card on the counter's coverage. If a duplicate surfaces, merge there.

[os-zhuang]

Returned to needs-user-decision — the pre-declared fork fired, and the enumeration changed what the fork is about

domain:cli seat, session session_012WKSnqAaoqtW3QX7SSf1Vk, PM loop round 21. Paired with the label write (pm:dispatched → needs-user-decision). Dev returned status: needs_decision with no fix — ruling ② fired exactly as triage pre-declared it. PR #9746 carries a 12-case measurement harness only, Part of #9650, ⛔ never a closing keyword.

The premise held; the scope did not

Every structural claim in the card re-verified on the current ref. But the Zone 2 assumption I asked to be falsified rather than trusted was falsified decisively:

the card names 2 uninstrumented inbound surfaces. The measured count is at least 14, in two structurally different classes.

• Class A — framework-native getRawApp() mounts (11 measured): plugin-auth, metadata HMR, cloud-connection, marketplace proxy + install-local, runtime-config, trigger-api, webhooks, approvals, the console SPA, the unknown-hostname guard.
• Class B — http.server consumers mounting via verb methods (7): packages/rest via RouteManager, storage, i18n, settings, datasource admin, the dispatcher itself (the only one instrumented today), and the non-Hono conformance adapter.

⇒ Class A is invisible to any IHttpServer-level wrapper by construction. I verified the mechanism myself rather than accepting it — dispatcher-plugin.ts:700-721:

if (prop === 'get' || prop === 'post' || prop === 'delete') { …instrument… }
return Reflect.get(target, prop, receiver);

getRawApp takes the second line and returns the untouched app. No proxy-shaped fix can ever reach those 11 mounts, at any ordering. And the same three lines show a second defect: the Proxy traps get/post/delete only, while RouteManager mounts put and patch — so even a favourably-ordered proxy undercounts REST.

Seam A is disqualified four times over, each measured

1. Order-load-bearing — in the shipped serve.ts order REST starts (:2548) before the dispatcher (:2566), so REST keeps the raw handle. The unfavourable row is the real one.
2. Structurally cannot reach class A, per the Reflect.get passthrough above — independent of order.
3. Leaks verbs — put/patch uninstrumented.
4. Cannot even be spelled as described — ctx.registerService throws [Kernel] Service 'http.server' already registered; it would require replaceService, i.e. deliberately swapping out a service another plugin provided.

Seam B (middleware in the dispatcher's start()) covers nothing. Seam C (same middleware in Phase 1 init()) covers all three probes with status — but contradicts the documented rationale at dispatcher-plugin.ts:588-604, makes http.server an init-time boot dependency under ADR-0116, and is Hono-specific: it reads zero on the conformance node adapter, which deliberately omits getRawApp.

⛔ Why this is not mine to rule

Each live option crosses a line this seat cannot: A moves the emitter into packages/plugins/plugin-hono-server — outside this card's surface and outside domain:cli, so it needs re-dispatch by appointment. B changes the IHttpServer contract in packages/spec — another seat's package and a contract decision. C changes the dispatcher's lifecycle contract. ⛔ Human floor on all three.

The dev's recommendation is A now, B as the principled successor, and its safety argument is the one I find most persuasive: C fails hardest on the AI-authored-code axis because it looks complete while reading zero on a non-Hono transport — reproducing this card's own failure mode (a counter silently blind to a whole surface) one level up. ⚠️ Also flagged as cheap-now/unfixable-later: the route label should be the pattern (c.req.routePath), not the concrete path, or the series count explodes on /api/v1/data/:id traffic.

The pin is the deliverable, and it is honest about being one

12 cases on a real booted Hono adapter in the shipped plugin order, driving the real RouteManager from @objectstack/rest and the exact getRawApp().all(basePath + '/*') construct from auth-plugin.ts:1622-1630. A positive control asserts the dispatcher's own route is counted — without it, both "not counted" results would be indistinguishable from a broken metrics injection. ⭐ The two "does NOT count" assertions are the acceptance criterion in executable form: whichever seam wins, both must flip together.

⚠️ Reverse verification reported honestly: run 1 had three failures, two for reasons other than predicted — both harness defects, root-caused rather than papered over, and one produced strictly stronger evidence (measuring on the real booted app instead of a synthetic Hono instance). "Reporting 'prediction met' on run 1 would have been false."

The lint round-trip, and both escape hatches refused

Lint & Repo Gates went red on the first push — two getService<any>('http.server') sites tripping the slot-lookup rule. Fixed at the call sites: typed to IHttpServer (the declared contract, core-service-contracts.ts:155) and the .id marker replaced by identity comparison — a Proxy is never === its target, so the stub needs no marker at all and the assertion got stronger. ⛔ UNCONTRACTED_SLOTS untouched, ⛔ slot-lookup-baseline.json untouched, both confirmed by git status.

Two method findings that outlive this card

• ⭐ My corrected grep shape was still incomplete. I circulated \.method\s*(\?\.)?\s*\( after the optional-call miss. The dev found a second miss class it does not cover — a generic type argument: getService<IHttpServer>('http-server') needs (<[^>]*>)? too. That gap was 5 of 10 sites. And a third class is unreachable by any literal-string grep: rest-api-plugin.ts:129 resolves the service through a variable, naming no literal at all.
• ⚠️ A phantom green, caught with a control. pnpm --filter @objectstack/runtime typecheck passes, but tsc --listFiles shows the new file is not in that program — tsconfig.json excludes **/*.test.ts (897 files listed, dispatcher-plugin.ts present, zero .test.ts). Pre-existing ledgered debt under [P2] framework: 66 个包用 tsup 构建、无人做类型检查 —— 实测 18 个包共 380 处 code-tier 错误(#4118 的 framework 侧对应) #4311, so reported rather than re-filed, and the file was instead measured inside the hidden-test compile: 0 errors from it, total 227 = the frozen ledger number exactly.

Gate-derivation gap noted, ⛔ correctly not re-filed: dispatch-gates named neither pnpm lint nor check:slot-lookup for a packages/runtime/src path — a second confirmed instance of #9721 / #9700, now shown on a test-only diff. #9745 filed for the serve.ts comment that states a false sufficiency condition (a middleware installed from kernel:bootstrapped observes nothing, because every route mounts in Phase 2). ⛔ Neither graded by this seat.

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling recorded (2026-08-18, live chat with the triage session session_014v3dpZ2224xgf98dfY4rw4; authorization verbatim: 「其他接受你的建议」, accepting the per-card recommendation presented in that session, restated here as the operative ruling).

Ruling: Option A — transport-owned seam. http_requests_total is emitted from the Hono adapter itself (packages/plugins/plugin-hono-server), as a raw-app middleware installed at the end of HonoServerPlugin.init() next to installMiddlewareSeam() — the layer where every inbound request on that transport converges, including all getRawApp() mounts. Additionally ruled:

• Route label = PATTERN (c.req.routePath, e.g. /api/v1/auth/*), never the concrete path — settled now because it becomes unfixable once dashboards wire against the first shipped label.
• Option B (IHttpServer response-observing contract hook) is the principled successor: file it as its own spec card, ⛔ not folded into this fix.
• Option C rejected — silently reads zero on a non-Hono transport, reproducing this card's failure mode one level up. Option D rejected.
• Documented expectation: a transport that does not implement the seam reports no HTTP metrics — state this plainly in the docs/PR body rather than letting it read as coverage.

Label: needs-user-decision → pm:queue. Acceptance criterion stands as pinned: the two "does NOT count" assertions in PR #9746's 12-case harness must both flip together. Clause-② no (metric coverage; no accept/reject change). Producer file surface is plugin-hono-server (+ the runtime pin) — domain:cli per the lane table, so this stays in lane; cli seat: the round-21 assignee is left in place, clear or re-claim when re-dispatching.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 23
Session: session_01WeN7F6jQFpcqW2BN56RdPa
Branch: claude/issue-9650-http-metrics-auth-and-rest-coverage (the existing round-21 branch — PR #9746 already carries the 12-case harness; continue on it, ⛔ do not start a fresh branch)
Worktree: objectstack-issue-9650
Domain: domain:cli
File surface: packages/plugins/plugin-hono-server/src/adapter.ts and src/hono-plugin.ts (the init()-time seam beside installMiddlewareSeam() only), the existing pin packages/runtime/src/http-metrics-inbound-coverage.hono.integration.test.ts, .changeset/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — node scripts/pm/dispatch-gates.mjs --tier over the surface above returns no path-derived mandate this round (floor sonnet · default opus · ceiling fable), ⛔ not recalled. Held at default: the design fork that made this card expensive is now ruled, so what remains is wiring plus pins
Clause-②: no — ruled explicitly in the maintainer's own words ("metric coverage; no accept/reject change"). Adding a counter changes nothing any route accepts or rejects and widens no public response shape
Serial constraints cleared: packages/plugins/plugin-hono-server/** — no in-flight PR names it; the round-21 branch is this card's own. ⛔ packages/rest/src/rest-server.ts out of surface (measured last round to be neither producer nor consumer of this seam). #9774 holds packages/cli/src/commands/init.ts, disjoint. Sibling round-23 cards #9487 (packages/core) and #9436 (packages/adapters/hono) are disjoint by construction — but see the cross-card note below, which is a read coupling, not a file one

Why this is dispatchable now

⚠️ The seat post recorded this card in the decision box at handover (23:19Z). It was ruled at 22:29:32Z. Re-derived from this card's comments, not inherited.

The ruling (⛔ not re-litigable)

Option A — transport-owned seam. Emit http_requests_total from the Hono adapter itself, as a raw-app middleware installed at the end of HonoServerPlugin.init(), next to installMiddlewareSeam() — the layer where every inbound request on that transport converges, including all getRawApp() mounts.

Also ruled:

• Route label = PATTERN (c.req.routePath, e.g. /api/v1/auth/*), ⛔ never the concrete path. Settled now because it becomes unfixable once dashboards wire against the first shipped label.
• Option B (an IHttpServer response-observing contract hook) is the principled successor — ⛔ file it as its own packages/spec card, do not fold it in here.
• Option C rejected (dispatcher installs the middleware from its own init()) — it reads zero on a non-Hono transport, reproducing this card's failure mode one level up. Option D rejected.
• Documented expectation: a transport that does not implement the seam reports no HTTP metrics. State this plainly in the docs/PR body rather than letting it read as coverage.

The acceptance criterion is already executable — ⛔ do not rewrite it to fit the fix

packages/runtime/src/http-metrics-inbound-coverage.hono.integration.test.ts (on your branch) currently asserts that the auth mount and the REST mount are NOT counted. Those two assertions are this card's acceptance criterion in executable form:

⭐ Both must flip together. Flipping one reproduces the card one surface over — that is precisely the defect being fixed. The positive control (the dispatcher's own route is counted) must stay: without it, a "now counted" result is indistinguishable from a broken metrics injection, exactly as a "not counted" result was.

The harness boots a real Hono adapter in the shipped serve.ts plugin order, drives the real RouteManager from @objectstack/rest, and uses the exact getRawApp().all(basePath + '/*') construct from auth-plugin.ts:1622-1630. Keep it that way — ⛔ do not substitute a hand-rolled stand-in for either.

What last round measured, so you do not re-measure it

Carried as established fact (all measured on a real booted app, not read):

• Seam A (register the instrumented proxy back as http.server) is disqualified four times over — getRawApp passes through the Proxy via Reflect.get so class-A mounts are unreachable structurally, at any ordering; the Proxy traps only get/post/delete so REST's put/patch leak; registerService throws [Kernel] Service 'http.server' already registered; and REST starts (serve.ts:2548) before the dispatcher (:2566), so REST holds the raw handle.
• Phase 1 init() is the sufficient condition, ⛔ not "before kernel:listening" — a middleware installed from a kernel:bootstrapped hook observes nothing, because every route mounts in Phase 2 start().
• The framework-agnostic use() seam cannot carry {status} — the adapter runs the whole use() chain and only then returns Hono's next(), so a middleware there has no response to read.
• The card's "2 uninstrumented surfaces" is false: at least 14, in two classes. Class A (11 getRawApp() mounts) is invisible to any IHttpServer-level wrapper by construction. This is why the answer is a transport seam.

PM mechanism assumptions — measure, and falsifying them is a good run

• That installMiddlewareSeam() in HonoServerPlugin.init() (hono-plugin.ts:405, seam at adapter.ts:855/877) is the right anchor and that installing beside it observes every mount with status. Last round measured a Phase-1 raw-app middleware covering auth, REST and the dispatcher with status — but that was a harness-installed middleware, ⛔ not this exact call site. Verify at the real site.
• That the dispatcher's existing Proxy instrumentation should be removed or made a no-op once the transport seam lands, rather than left to double-count its own route. ⚠️ Check whether the dispatcher's route would be counted twice; if removing the Proxy is out of surface or changes other behaviour, report rather than widening.
• That c.req.routePath is populated for wildcard mounts at the install point. It returned /api/v1/auth/* last round — confirm it still does from the adapter's own seam.

⚠️ Cross-card read coupling — no shared file, but a shared gate table

Sibling round-23 card #9436 owns scripts/check-route-envelope.mjs this round (counter changes plus four ratchet pointer retargets). Your surface does not include that file and must not. ⇒ If your change moves any counter in scripts/check-route-envelope.mjs, STOP and report — do not edit it, and do not "fix" a counter that moved. Both PRs are green in isolation in that scenario and wrong together, which is the failure mode this note exists to catch.

Gates

Re-derive with node scripts/pm/dispatch-gates.mjs from the actually changed paths. ⚠️ It does not name pnpm lint or check:slot-lookup — measured twice on this very card's branch, once on a test-only diff. Run pnpm lint regardless. ⚠️ pnpm --filter @objectstack/runtime typecheck is a phantom green for the harness file: tsconfig.json excludes **/*.test.ts, so that command never reads it — check with tsc --listFiles as last round did.

⛔ Neither eslint.config.mjs's UNCONTRACTED_SLOTS nor scripts/slot-lookup-baseline.json may be touched; last round's identical lint failure was correctly fixed at the call sites by typing lookups to IHttpServer and comparing handles by identity. ⛔ Never weaken a gate to get green.

This card now carries a real behaviour change, so skip-changeset no longer applies as it did to the measurement-only PR — add a changeset for the published packages the diff touches. ⚠️ PR #9746's body and title say "measurement only, no fix" and it uses Part of #9650 — both need updating when the fix lands, and the closing keyword becomes appropriate only if the PR fully discharges the card.

Report at draft-PR time — ⛔ do not wait on CI convergence. Terminal report: machine-checkable fields only.

---

Generated by Claude Code

[huangyiirene]

os-dev-report

{
  "issue": 9650,
  "status": "rework",
  "branch": "claude/issue-9650-http-metrics-auth-and-rest-coverage",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9746",
  "premise_still_valid": true,
  "summary": "The ruled Option-A seam is implemented, measured and pinned: HonoServerPlugin.init() now installs a raw-app middleware emitting http_requests_total{method,route,status} immediately before installMiddlewareSeam(), with route = the matched PATTERN. The card's acceptance criterion flipped as a pair - the auth getRawApp() mount and the REST RouteManager route are both counted, and the dispatcher positive control still holds. status is rework, not done, for one measured reason that is not fixable inside the dispatched file surface: the shipped serve.ts registers no ObservabilityServicePlugin anywhere in the repo and constructs new HonoServerPlugin({ port }) with no observability, so NEITHER link of the canonical resolution chain exists there and the seam installs no middleware at all in an objectstack serve deployment. The seam is correct and inert at the host. Filed as sub-issues of this card: 9832 (CLI wiring), 9833 (dispatcher double count, measured 2 vs 1), 9834 (the same hole still open on http_request_duration_ms / http_request_errors_total); plus 9835, the IHttpServer contract-hook spec card the ruling directed.",
  "files_changed": [
    "packages/plugins/plugin-hono-server/src/adapter.ts - new installHttpMetricsSeam(metrics), idempotent, one app.use('*') emitting after next()",
    "packages/plugins/plugin-hono-server/src/hono-plugin.ts - new observability.metrics option, private resolveMetrics(ctx) canonical chain, install call at end of init() BEFORE installMiddlewareSeam()",
    "packages/runtime/src/http-metrics-inbound-coverage.hono.integration.test.ts - section 1 assertions flipped, section 4 added (6 cases), header rewritten",
    ".changeset/http-requests-total-transport-seam.md - @objectstack/plugin-hono-server minor"
  ],
  "surface_breach": "none taken. packages/cli/src/commands/serve.ts was READ ONLY and never edited. It fails the bounded-in-place test on two of the four conditions: the repair is not mechanical (buildServeObservability() is called once, deep in the dispatcher block, so reusing it needs hoisting or memoising and the better option - registering ObservabilityServicePlugin once for all consumers - is a design choice that also lights up cache and storage metrics), and it adds verification surface in the hottest file in the repo. Filed as 9832 instead.",
  "zone_2_assumptions": {
    "a_install_beside_installMiddlewareSeam_observes_every_mount_with_status": "HELD, and verified at the REAL call site rather than by a harness-installed stand-in. Measured labels from one boot in the shipped serve.ts plugin order: [{GET,/.well-known/objectstack,200},{GET,/.well-known/objectstack,200},{POST,/api/v1/auth/*,200},{GET,/api/v1/data/probe,200},{GET,/api/v1/data/:id,200},{GET,/*,404}].",
    "b_dispatcher_proxy_double_counts": "CONFIRMED, and it is a per-surface duplicate, not a uniform scale factor. One request each, one shared registry: /.well-known/objectstack counted 2, /api/v1/auth/* counted 1. Reported, NOT widened - removing the emission is not separable from instrumentRouteHandler's request-id header, http_request_duration_ms, http_request_errors_total and the ErrorReporter (incl. the res.__obsRecordedError side channel), and packages/runtime was outside the surface. Pinned as an executable measurement naming the follow-up; when 9833 lands the expectation becomes toBe(1).",
    "c_routePath_populated_for_wildcard_mounts_from_the_adapters_own_seam": "HELD. /api/v1/auth/* for the getRawApp wildcard. Also measured beyond the assumption: a parameterized REST route labels as /api/v1/data/:id for concrete /api/v1/data/abc123 and /api/v1/data/def456 - two ids, ONE series - and an unmatched path labels /* with status 404, so the '|| unmatched' fallback never fires in practice.",
    "deviation_from_the_suggested_spelling": "Used routePath(c) from the hono/route subpath export instead of the c.req.routePath getter. Same VALUE (the ruling's substance is untouched); the getter is marked @deprecated in hono 4.13.2's own .d.ts and indexes matchResult without a bounds check, while the helper is the non-deprecated spelling and returns '' rather than throwing. Available in both hono versions resolved in this workspace (4.13.2 and 4.12.34); the package declares ^4.13.2."
  },
  "acceptance_criterion": "Both 'does NOT count' assertions flipped TOGETHER in packages/runtime/src/http-metrics-inbound-coverage.hono.integration.test.ts section 1. The positive control (dispatcher's own route IS counted) is unchanged and still present. The harness composition was NOT weakened to fit the fix: still a real Hono adapter booted in the shipped serve.ts order, still the REAL RouteManager from @objectstack/rest, still the exact getRawApp().all(basePath + '/*') construct. The only composition change is wiring the registry into the transport, which is the fix's own wiring. Sections 2 and 3 (the seam-A and seam-B/C measurements that produced the ruling) are kept intact so the ruling's evidence stays executable.",
  "cross_card_route_envelope": "NO counter moved in scripts/check-route-envelope.mjs. Not asserted - measured, by running the gate TWICE on the same tree, the second time with adapter.ts checked out at the merge base. Identical both runs: 10 route modules (7 conformant, 2 ratcheted, 1 exempt), 16 dispatcher domains, 11 plugin-mounted modules with 161 hand-built bodies, current-user-endpoints.ts exempt closed at unenveloped 9. No stop condition; the file was never opened for edit.",
  "tests": "All heavy commands under flock -E 99 -w 540 /tmp/os-heavy-verify.lock; verdicts read from reported counts, never a piped exit code. Gate union re-run on the FINAL head 8957c72227 (origin/main merged at 9ff11921a2), after the last commit. Build closure first: pnpm --workspace-concurrency=2 --filter '@objectstack/runtime^...' --filter '@objectstack/plugin-hono-server' --filter '@objectstack/rest' build -> success; later the full closure the ratchet requires, pnpm exec turbo run build --filter='./packages/*' --filter='./packages/*/*' --concurrency=2 -> 'Tasks: 70 successful, 70 total'. SUITES: the pin -> 'Test Files 1 passed (1)' / 'Tests 18 passed (18)'; pnpm --filter @objectstack/plugin-hono-server test -> 'Test Files 18 passed (18)' / 'Tests 211 passed (211)'; pnpm --filter @objectstack/hono test -> 'Tests 73 passed (73)' (the downstream consumer of this adapter). TYPECHECK: pnpm --filter @objectstack/plugin-hono-server typecheck -> clean, script name echoed so it is not a zero-match phantom. GATES, each result echoed: pnpm lint (eslint . --no-inline-config) -> exit 0, EMPTY output on the whole repo; check:slot-lookup -> OK, 107 unswept sites in 25 files, none new, baseline verified against 4c260cd; check:route-envelope -> OK (see cross_card_route_envelope); check:nul-bytes -> OK, 6273 text files, no raw control bytes, plus 75 self-test assertions; check:type-check-debt --re-measure -> OK, 33 ledger entries re-measured in 380.8s, 1926 raw tsc errors, none above its recorded number, 'surplus: none'; check:type-check-coverage -> OK, 64/77 packages; check:engine-double-contract -> OK, 321 pinned, 133 DEBT, 2 exempt; check:where-matcher -> OK, 258 matchers, none new; check:query-options-erasure -> OK, ratchet holds, 67 unswept non-test sites, none new; check:cross-package-test-inputs (both spellings) -> OK, 12 packages, all declared; check:test-source-alias -> OK, 72 packages scanned; check:type-source-resolution -> OK, 76 packages scanned; check:changeset-gate-self-tests -> OK; check-adr-0087-registration -> OK, 1 non-breaking changeset seen; check-empty-changeset -> OK, 1 declaring changeset added; check-changeset-no-major -> OK; check:objectui-changeset -> OK; scripts/docs-audit/check-affected-docs.mjs -> OK, 242 self-test cases. ABLATION, both legs rebuilt and PROVEN to have reached dist: prediction file written BEFORE the run naming RED and specifically 7 of 18 with the seven cases listed; ablated leg -> node scripts/ablation-dist-preflight.mjs @objectstack/plugin-hono-server 'HTTP request counter armed' --absent -> 'marker absent from all 6 built files', run -> 'Tests 7 failed | 11 passed (18)', exactly the seven predicted; restore leg -> same preflight without --absent -> 'marker present in 2 built files', run -> 'Tests 18 passed (18)'. The CORS case failed on its POSITIVE leg (AssertionError: expected [] to include 'POST') while not.toContain('OPTIONS') passed vacuously against an empty array, which is why that positive leg exists.",
  "gate_derivation": "node scripts/pm/dispatch-gates.mjs with NO paths - the script derived the change set itself from the merge base (4 paths, three-dot semantics). 11 path-matched + 5 convention-triggered. The brief's warning reproduced exactly: the derivation named NEITHER pnpm lint NOR check:slot-lookup for these paths. Both were run regardless and both are green. That is now a THIRD confirmed instance of the already-filed 9721 / 9700, so it is reported here and not filed again.",
  "phantom_green_caught_a_real_defect": "pnpm --filter @objectstack/runtime typecheck is green and does NOT read the harness file (that tsconfig excludes **/*.test.ts). check:type-check-debt does read it and went RED: TEST_DEBT 227 -> 228. Root-caused rather than papered over - a CORS option spelled `origin` where HonoCorsOptions declares `origins`, so that test's CORS config was silently falling back to defaults. Fixed at the call site, then re-measured directly by compiling the hidden test layer against a temp config that lifts the exclusion: 227 total, 0 from this file, matching the frozen ledger exactly. The ledger was NOT raised; eslint.config.mjs UNCONTRACTED_SLOTS and scripts/slot-lookup-baseline.json were never touched.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9832 (sub-issue of #9650): `objectstack serve` registers no ObservabilityServicePlugin anywhere in the repo, so `observability:metrics` is unregistered in every shipped CLI deployment - this seam, cache and storage all resolve to nothing. This is what keeps #9650 from being discharged.",
    "filed as #9833 (sub-issue of #9650): the dispatcher's instrumentRouteHandler Proxy double-counts its own routes once both emitters share a registry - measured 2 vs 1, a per-surface duplicate.",
    "filed as #9834 (sub-issue of #9650): http_request_duration_ms and http_request_errors_total still carry the identical coverage hole, so the p95-latency half of the documented operator guidance is still dispatcher-only.",
    "filed as #9835 (standalone spec card, as the maintainer's ruling directed): give IHttpServer a response-observing hook so HTTP metrics stop being Hono-only."
  ]
}

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

ACCEPT — PR #9746. ⛔ Reclassifying the dev's own rework verdict: the work needs none

domain:cli seat, session session_01WeN7F6jQFpcqW2BN56RdPa, round 23. Reviewer of record; checked against GitHub and the tree, ⛔ not against the report's self-description.

The dev returned status: rework. I disagree, and the distinction matters. Nothing in this PR needs reworking — the ruled seam is implemented, the acceptance criterion inverted as a pair, every gate is green and the ablation is honest. What it found is that the card cannot be discharged by this diff, for a reason outside the dispatched surface. That is done + Part of, with the card blocked — ⛔ not rework. Conflating "my work is unfinished" with "the card is unfinished" would have sent a correct PR back around for nothing.

The finding, and it is larger than this card

The seam is correct and inert in a shipped deployment. I verified all three links myself on origin/main rather than taking the report:

claim	reading
serve.ts registers no ObservabilityServicePlugin	✅ zero production instantiations repo-wide — only the class, its own test, and doc mentions in service-cache / service-storage. Control: the symbol exists in 9 files, so the query is live
serve.ts builds the transport without observability	✅ serve.ts:1758 — new HonoServerPlugin({ port })
nothing registers observability:metrics	✅ registerService(…observability…) → zero matches. Control: OBSERVABILITY_METRICS_SERVICE is defined, and service-cache/service-storage docs say it is "registered by ObservabilityServicePlugin" — by nobody, in fact

⇒ Neither link of the canonical resolution chain exists in objectstack serve, so this seam installs no middleware at all there. ⭐ And the blast radius is wider than HTTP metrics: cache and storage metrics resolve to nothing too. Filed as #9832.

⚠️ That is this card's own failure mode arriving one level up again — a counter that reads zero and looks like "no traffic". The card began as "the counter misses 2 surfaces", became "at least 14", and now ends at "the whole observability service is unregistered in production". ⛔ I am not treating that as scope creep to absorb: it is the measurement, and it belongs in its own card.

Checklist

• Form — draft ✅ · base main ✅ · Part of #9650, closing keyword deliberately withheld ✅. Title and body both updated off the "measurement only, no fix" framing, as instructed. 4 files.
• Scope — plugin-hono-server (adapter + plugin), the runtime harness, the changeset. Inside surface. ⛔ No governed path ⇒ no ACCEPT fork.
• ⛔ Cross-card boundary HELD, and measured rather than asserted — scripts/check-route-envelope.mjs untouched, verified by running the gate twice on the same tree, the second time with adapter.ts reverted to the merge base: identical output. That is the strongest possible answer to the stop-and-report clause I attached, and it was not the cheap one.
• Clause ② — no, per the maintainer's own ruling (metric coverage, no accept/reject change). Dispatched opus; no gate owed.

The acceptance criterion inverted as a pair

Both "does NOT count" assertions now read "counts", together, and the positive control survives. §2 and §3 — the measurements that disqualified seams A and B/C — are kept intact, so the ruling's evidence stays executable instead of decaying into a claim in a comment. ⭐ I did not ask for that; it is the right instinct.

§4 additionally pins the seam's real edges: pattern labelling (two record ids → one series), a 429 the use() chain refuses is counted, a CORS preflight the transport answers itself is not, the service-resolution chain, and no-backend-no-middleware.

Deviation, declared: routePath(c) from hono/route instead of the ruled c.req.routePath. Same value; the getter is @deprecated in hono 4.13.2 and indexes matchResult without a bounds check. The ruling's substance — PATTERN, never the concrete path — is untouched, and the deviation was flagged rather than slipped in. Accepted.

Two things worth keeping

⭐ A gate caught a real defect and the dev root-caused it instead of ratcheting. check:type-check-debt went red, TEST_DEBT 227 → 228: a CORS option spelled origin where HonoCorsOptions declares origins, so that test's CORS config was silently falling back to defaults. Fixed at the call site; ⛔ the ledger was not raised, UNCONTRACTED_SLOTS and slot-lookup-baseline.json untouched. ⚠️ Note pnpm --filter @objectstack/runtime typecheck is green and never reads that file — the phantom green again.

⭐ A vacuous assertion caught by its own positive leg. In the CORS case, not.toContain('OPTIONS') passed against an empty array — it would have passed no matter what. The paired toContain('POST') is what failed and exposed the defect above. That is exactly why a negative assertion needs a positive twin.

Ablation: predictions written to a file before the run naming RED and specifically which seven of eighteen; ablated leg gave exactly those seven, both legs dist-proven by preflight.

Known consequence landing with this, ⛔ not hidden

The dispatcher's Proxy still emits the same counter, so a host wiring one registry to both double-counts the dispatcher's own routes — measured 2 vs 1, a per-surface duplicate, ⛔ not a uniform scale factor an operator could divide out. Filed as #9833, and pinned in §4 as toBe(2) with a comment naming the follow-up that makes it toBe(1). ⇒ Main will carry a test asserting a known duplicate; that is deliberate and it will fail loudly when #9833 lands, which is what makes it a ledger rather than a blind spot.

Verdict and next state

ACCEPT. All six required checks green at 8957c72227, plus Part-of PR must not also close its card. Flipping ready and enqueuing.

⇒ On merge, this card moves to pm:blocked with Blocked-by: #9832 — the seam is real but unobservable in production until the CLI registers a metrics backend, and the card's own premise ("operators are told to alert on this counter") is not satisfied while that holds. #9833, #9834 and #9835 are separately filed and ⛔ ungraded by this seat.

---

Generated by Claude Code

[huangyiirene]

PR #9746 MERGED — card stays open, now pm:blocked on #9832

domain:cli seat, session session_01WeN7F6jQFpcqW2BN56RdPa, round 23 close-out. Paired with the label write (pm:dispatched → pm:blocked) and the Blocked-by: #9832 line now at the top of the body.

Landed

#9746 merged, origin/main = 152bff8fcd. Three readings: the commit on origin/main, the PR's own merged state, and a probe — installHttpMetricsSeam in packages/plugins/plugin-hono-server/src/adapter.ts, baseline verified 0 at 9ff11921a2 (⛔ not assumed — this shift had three probes whose naive baselines were wrong), now 2. Control: installMiddlewareSeam reads 3 on both sides, so the query is live either way.

🔓 Releases the serial hold on packages/plugins/plugin-hono-server and on the runtime harness file.

Delivered / remaining / whose

Delivered	The ruled Option-A transport seam: http_requests_total{method,route,status} emitted from HonoServerPlugin.init() beside installMiddlewareSeam(), route label = matched PATTERN. The card's acceptance criterion inverted as a pair — the auth getRawApp() mount and the REST RouteManager route are both counted, positive control intact. §2/§3 kept executable so the ruling's own evidence survives.
Remaining	#9832 — objectstack serve registers no ObservabilityServicePlugin and builds new HonoServerPlugin({ port }), so neither link of the resolution chain exists and the seam installs nothing in a shipped deploy. #9833 — dispatcher Proxy double-counts its own routes once both emitters share a registry (measured 2 vs 1). #9834 — http_request_duration_ms / http_request_errors_total still carry the identical hole.
Whose	All three are unassigned sub-issues awaiting triage grading — ⛔ not graded by this seat. #9835 (the IHttpServer response-observing hook) is a standalone packages/spec card and belongs to the domain:spec seat.

Why this card is not closed

The card's premise is that operators are told to alert on this counter. A seam that is correct but installs no middleware in the only deployment shape the CLI produces does not satisfy that premise — it would close the card on a counter that still reads flat while /api/v1/* melts down, which is the exact failure the card describes.

⭐ The finding is larger than the card, and it was measured rather than inferred: cache and storage metrics are dark too, because the missing registration is shared. That is why #9832 is its own card and not a footnote.

For the record

The dev returned status: rework; I reclassified it. Nothing in the PR needed reworking — the distinction is between "my work is unfinished" and "the card is unfinished", and conflating them would have sent a correct, fully-gated PR back around for nothing.

⚠️ Its Zone-2 falsification was of my brief, twice over: I framed the seam as the whole job, and the measurement found both the host-wiring gap and the double-count. ⭐ Also worth keeping: a gate caught a real defect in the change (check:type-check-debt 227 → 228, root cause a CORS option spelled origin where the type declares origins) and the dev root-caused it instead of raising the ledger.

---

Generated by Claude Code

[huangyiirene]

Measurement update from #9832's implementation run — this card's recorded blocker is narrower than its body states

Recording now rather than at unblock time, because the fact does not depend on #9832 landing.

What this card records

That the ruled transport seam landed (152bff8fcd) and is inert at the host, because neither link of the resolution chain exists in a shipped objectstack serve. That is why this card sits pm:blocked on #9832.

What was measured on the parent commit, before any of #9832's fix

#9832's dev booted the real showcase app through the real serve.ts with OS_OBS_EXPORTER=console and read the counters on both legs. On the baseline leg — no ObservabilityServicePlugin registered, i.e. today's shipped behaviour:

• http_requests_total 5 — already emitting, with auth (/api/v1/auth/*) and the REST data API (/api/v1/data/:object) already counted
• CacheServicePlugin: registered memory cache adapter (metrics=NoopMetricsRegistry)
• StorageServicePlugin: registered local storage adapter (swappable, metrics=NoopMetricsRegistry)
• storage_operations_total 0

Why the HTTP half is already live

#9835 landed after this card was filed (7ff3975070). packages/runtime/src/dispatcher-plugin.ts:731-734 now arms the transport-wide counter itself:

const transportCountsRequests =
    typeof (rawServer as IHttpServer).afterResponse === 'function';
if (transportCountsRequests && config.observability?.metrics) {
    armHttpRequestCounter(rawServer as IHttpServer, config.observability.metrics);
}

It uses the metrics registry serve.ts already passes the dispatcher explicitly — step 1 of the resolution chain, which never needed the service registration. So the seam is reached through the option, not through observability:metrics, and it is live in a shipped serve today.

I verified this independently on origin/main rather than taking the report's word: the arming site is there, and armHttpRequestCounter latches per server object (two arming sites exist — packages/plugins/plugin-hono-server/src/adapter.ts:1056 and dispatcher-plugin.ts:734 — and the latch is what keeps them from double-counting).

What this changes, and what it does not

⇒ The http_requests_total half of this card's inertness claim is no longer true. It was true when filed; #9835 made it stale.

⛔ The card is not discharged. What remains dark in a shipped deployment is the cache and storage half — both consumers still resolve to NoopMetricsRegistry, because they reach the chain at step 2 (observability:metrics), which nothing registers. That is exactly what #9832 fixes, and it is still a real blocker.

So the correct reading of this card today is: one of the two dark surfaces lit itself via a different route; the other still needs #9832. Staying pm:blocked on #9832 is still right — the label is unchanged.

I will re-verify this card's file surface on the merged ref once #9832 lands (PR #9951, currently in rework on an unrelated gate) and then close or re-queue it on measurement, not on this note.

---

Generated by Claude Code

[huangyiirene]

Closing — the claim is measurably false now, on the merged ref

Blocker discharged: #9832 landed (PR #9951, cb6c82194a). Re-verified on merged main as promised, and closing on measurement, not on the blocker having cleared.

This card's claim

http_requests_total has exactly one emitter… applied by a Proxy the dispatcher builds over a local server binding… Consequently plugin-auth (mounting via getRawApp()) and packages/rest (resolving http.server itself) are outside the counter.

Why it no longer holds

1. The mechanism moved, and the code says so by name. packages/plugins/plugin-hono-server/src/adapter.ts (~:992-1004) carries a section headed "Why the counter lives here and not one layer up (#9650)":

The counter used to be emitted by a wrapper the runtime dispatcher built over its own IHttpServer handle, so it saw only the routes the dispatcher itself registered. Everything else on the same server was invisible to it — measured, at least 14 inbound surfaces in two classes:

• plugins that mount through getRawApp (auth, metadata HMR, cloud-connection, marketplace, runtime-config, trigger-api, webhooks, approvals, the console SPA). These bypass IHttpServer entirely, so NO wrapper at that level can ever reach them.
• plugins that resolve http.server themselves and mount through the verb methods (the REST data API via RouteManager, storage, i18n, …)

That is this card's two surfaces, named, with the reason the old location could never have covered them. It landed as #9835 (7ff3975070), after this card was filed.

2. It is armed in a shipped serve, and that was measured by booting. ⭐ I am not resting this on the JSDoc — prose is a claim by the author, not a reading. #9832's implementation run booted the real showcase app through the real serve.ts with OS_OBS_EXPORTER=console and read the counters. On the baseline leg — before any of #9832's own fix — http_requests_total read 5, with auth (/api/v1/auth/*) and the REST data API (/api/v1/data/:object) already counted.

The arming path does not depend on #9832: serve.ts passes the registry to the dispatcher explicitly (step 1 of the resolution chain), and dispatcher-plugin.ts:731-734 arms armHttpRequestCounter on the raw server whenever the transport exposes afterResponse. So the coverage this card asks for is live in any deployment with OS_OBS_EXPORTER set.

3. It is pinned. #9951 added a booted pin asserting the transport counts a getRawApp() mount labelled by the registered pattern — explicitly "the surface the dispatcher's own proxy could never see, and the reason the counter lives at the transport."

⛔ What this does NOT close — read this before generalising

#9834 stands in full and is NOT covered. I checked rather than assumed: armHttpRequestCounter registers exactly one observer emitting exactly one family —

metrics.counter(RUNTIME_METRICS.httpRequestsTotal, { method, route, status })

httpRequestsTotal and nothing else. No http_request_duration_ms, no http_request_errors_total. The p95-latency half of the operator guidance this card complains about is still dispatcher-routes-only. Recorded there in comment 5340851641.

⇒ The operator-facing complaint is only half discharged. The 5xx-rate half is fixed; the p95-latency half is #9834's, still open, and closing this parent must not be read as closing that.

#9833 — separately recommended for closure against #9835 rather than #9832 (comment 5340837275): emitHttpRequestsTotal: !transportCountsRequests makes the two emitters mutually exclusive by construction, under a Symbol.for per-server latch. ⚠️ I read the call site, not instrumentRouteHandler's body — whoever closes it should confirm the callee honours the flag.

Disposition

Closing as completed. Sub-issue ledger: #9832 ✅ merged · #9833 open (closure recommended, verification named) · #9834 open, unblocked by this, claim intact.

---

Generated by Claude Code