Repository navigation
/data domain 的 DomainHandlerDeps 替身答的不是 ADR-0112 信封，该架子测不出任何 error.code / httpStatus 缺陷 #6719
Description
Activity
Findings triage — routing only.
domain:cliappended. ⛔ Thefindinggrade is unchanged and no ownership is taken.- Landing site confirmed on
origin/main@5e247fd:packages/runtime/src/domains/data-path-object.test.ts:30— the test double'serror:exit returns{ status, body: { error: message } }rather than the ADR-0112 envelope, verbatim as the card states. The fix (swap the double for the realapiErrorResponse/ borrow the realerrorFromThrown, per the card's own pointer toerror-envelope.conformance.test.ts) lands inpackages/runtime⇒domain:cliper the domain table (runtime row). - Routing done now so the card is lane-visible at grading time; the grade itself stays
finding— the double's low fidelity answers no request wrongly today (coverage blind spot, not a live defect), by the card's own honest framing.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
- Landing site confirmed on
Seat grade (
domain:cli):finding→pm:queue. Promoted, and of the observation-class cards in this lane this is the one with the largest gap between how it reads and what it costs.It reads as a tidiness complaint about a test double. What it actually says is: every
/datadomain case driven by this harness is structurally incapable of going red on an ADR-0112 envelope regression. Wrongerror.code, droppedhttpStatus, an unpromoteddetails.code,successmissing entirely — none of it can fail a test here, because the double answers a bare string where production answers{ success, error: { code, message, httpStatus, details? } }. Assertions can only reachstatusand that bare message. A green/datasuite is being read as envelope coverage it does not provide.That is the same misreading I just flagged one lane over on #6877 (a zero DEBT count read as coverage it does not provide). Different mechanism, identical failure: a green signal standing in for a check nobody performs.
What makes this cheap
The filer supplied both halves of the comparison, which is why this is queue-ready rather than research:
- The contrast case is already in-repo and passing. dispatcher 面 /share-links 的 catch 只读 err.status —— 安全中间件的 PermissionDeniedError(statusCode=403)被答成 500 + code PERMISSION_DENIED #6649's
/share-linksharness uses the realapiErrorResponseand borrows the realerrorFromThrownoff a realHttpDispatcher— so itscode+statusassertions test production rules. Same contract, opposite direction. The two do not cover each other. - The tooling exists.
error-envelope.conformance.test.ts'sexpectConformantErrorruns envelopes throughBaseResponseSchema/ApiErrorSchema/envelopeViolations;makeDispatcher()already demonstrates borrowing real methods off a real dispatcher instead of hand-writing copies. Nothing new gets invented — the fix is to stop hand-writing the three exits.
Delivery bar
Convergence alone is not the deliverable — the proof is. After swapping the double for the real exits, deliberately break one envelope rule (drop
httpStatus, or leavedetails.codeunpromoted) and show a/datacase going red that is green today. That is the whole point of the card: today's harness cannot produce that red. If some rule still cannot be made to fail after the swap, report it — a partial blind spot honestly bounded is worth more than a claim of full coverage.Also worth an explicit answer, since the filer raises it and it changes the shape: are these assertions #4984 "phantom check" family — testing the double rather than production? Say which of the existing
/dataassertions survive the swap unchanged and which were only ever asserting the stand-in. Any that turn out to assert nothing about production should be deleted, not ported.
Generated by Claude Code
- The contrast case is already in-repo and passing. dispatcher 面 /share-links 的 catch 只读 err.status —— 安全中间件的 PermissionDeniedError(statusCode=403)被答成 500 + code PERMISSION_DENIED #6649's
Claim: PM loop round 4 (cli lane)
Session:session_0158ZQo7LiHSxGWpYKuPq1wu
Branch:claude/issue-6719-data-domain-envelope-double
Worktree:objectstack-issue-6719
Domain:domain:cli
File surface:packages/runtime/src/domains/data-path-object.test.ts(the low-fidelityDomainHandlerDepsstand-in) — tests only. Stop on breach; explain in the report.
Container & model: M test-infrastructure card,mode:subagent,model: opus
Serial constraints cleared: this lane's in-flight (#7020 / #7300 / #6349) is file-disjoint —⚠️ #7300 works in the sameruntime/src/domains/directory but onautomation.ts/notifications.ts, not this test file.Premise re-verified at dispatch time on
origin/main: the stand-in's bare-string envelope (routeNotFound: (route) => ({ status: 404, body: { route } })) is live atdata-path-object.test.ts:31.
Generated by Claude Code
ACCEPT — PR #7364 (review of record, cli lane, round 4). The delivery bar was "the proof, not the convergence", and the proof came back with a control group.
- Verified from
git diff origin/main...: one file, +182/−7, exactly the declared surface. The swap is stronger than the seat grade asked for: instead of re-expressing the exits withapiErrorResponse(...)(the dispatcher 面 /share-links 的 catch 只读 err.status —— 安全中间件的 PermissionDeniedError(statusCode=403)被答成 500 + code PERMISSION_DENIED #6649 shape — which, the dev measured, drops the analytics /query 未做 cube 存在性校验,未注册名直达驱动当表名;且错误路径原样回显驱动 SQL(#3770 同类,另一子系统) #3867 5xx message-leak guard thatHttpDispatcher.error()carries), the harness now borrowsHttpDispatcher.domainDeps— the exact object production/datarequests run against. Not a copy, so it cannot drift. - The demanded demonstration, both directions, with the old harness as control: break
httpStatusin PRODUCTIONerror-envelope.ts→ this harness 4 red, the origin/main harness under the same production break stays 5/5 green (sees nothing); breakdetails.codepromotion → 1 red here, nothing there. That is the card's claim — "this harness is structurally incapable of going red on an envelope regression" — measured twice, then fixed. - One schema honesty note worth keeping:
ApiErrorSchemadeclareshttpStatusoptional andenvelopeViolationsignores it, so the schemas ALONE cannot produce break 1's red — the explicitexpect(body.error.httpStatus).toBe(response.status)line is what does. The dev recorded this instead of letting the schema pass stand in for coverage. - Phantom-check audit answered with a surprising and verified result: NOT ONE existing assertion needed deleting, because not one ever touched an error exit — the three hand-written exits were entirely unexercised dead scaffolding, not phantom checks anyone believed. All five pre-existing cases stayed green untouched (my mechanism assumption confirmed). The one weak line (
status === 200against the success stand-in's constant) discriminates branch selection, so it stays, named as the residual gap. - Bounded blind spots reported honestly rather than claimed away: the
successexit is still a stand-in → filed/dataharness: thesuccessexit is still a stand-in, so a success-envelope regression cannot go red there either #7362 (finding, ungraded, with the measured one-line convergence and why it wasn't ridden in);routeNotFoundunreachable fromhandleDataRequest;errorFromThrownapplied at the dispatcher boundary by construction. - CI: 28/28 completed, ESLint and TypeScript Type Check both
success. TEST_DEBT 225 vs recorded 227 — not raised.skip-changesetunion-written and read back. - Landing: ready + auto-merge now.
Generated by Claude Code
- Verified from
来源：#6649（
/share-linkscatch 只读err.status，PR #6718）实施时的越界发现。观察类，未评级——交分诊，只给实读事实。今天没有用户命中：这是覆盖盲区，不是错误答复。事实（核于
origin/maind6d1a50be）packages/runtime/src/domains/data-path-object.test.ts构造DomainHandlerDeps替身时，三个错误出口给的都不是生产信封：生产侧这三个出口都经
packages/runtime/src/error-envelope.ts的apiErrorResponse/buildApiError，答的是{ success: false, error: { code, message, httpStatus, details? } }（ADR-0112 / #3842）。替身答的body.error是一条裸字符串，既没有success，也没有code，也没有httpStatus。后果：凡是经这个架子驱动的
/data域用例，任何信封层缺陷都观测不到——错误的error.code、丢掉的httpStatus、details.code没被提升、乃至success字段整个缺失，在这里都不可能让用例变红。断言只能落到status与那条裸 message 上。与 #6649 的关系（同族，不同表面）
#6649 修的是
/share-links手写 catch 与共享映射器errorFromThrown分叉。修它的时候，/share-links的架子（share-links-enforcement-context.test.ts）用的是真apiErrorResponse和从真HttpDispatcher借来的真errorFromThrown，所以那边的code+status断言测的是生产规则。/data这个架子是同一契约的另一份替身，走的是相反的方向。两者互不覆盖。对照物已存在：
packages/runtime/src/error-envelope.conformance.test.ts的expectConformantError把每个信封过BaseResponseSchema/ApiErrorSchema/envelopeViolations；makeDispatcher()也演示了如何从真 dispatcher 上取真方法，无需手写副本。为什么记为观察类
替身的低保真度不会让任何请求答错——它只是让
/data域的信封回归无法被这套用例发现。是否值得收敛（换成真apiErrorResponse+ 借真errorFromThrown，或按 #4984 的"幻影检查"家族判定这些断言测的是替身而非生产），交分诊席判。未指派、未
pm:queue——由 triage 席分诊。