来源：#6649（/share-links catch 只读 err.status，PR #6718）实施时的越界发现。观察类，未评级——交分诊，只给实读事实。今天没有用户命中：这是覆盖盲区，不是错误答复。
事实（核于 origin/main d6d1a50be）
packages/runtime/src/domains/data-path-object.test.ts 构造 DomainHandlerDeps 替身时，三个错误出口给的都不是生产信封：
error: (message: string, code = 500) => ({ status: code, body: { error: message } }),
routeNotFound: (route: string) => ({ status: 404, body: { route } }),
errorFromThrown: (e: any) => ({ status: e?.statusCode ?? e?.status ?? 500, body: { error: e?.message } }),
生产侧这三个出口都经 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 席分诊。
来源：#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 席分诊。