qa(checklist): integration-system — 26 ledger edits from the 18.2.0 release sweep (#25807) #25844

Filing gate: maintainer-directed task. Filed by the 18.2.0 release-assessment thread · session_01G3h9iZTpL8aCiXbfsp8H5u. ⛔ Not a claim, ⛔ not dispatched.

Maintainer's words (project thread, 2026-10-25, verbatim): 22:54Z 「约 300 条清单准确性问题：是不是应该开卡？」, then 22:55Z 「写issue，不派发」.

Parent: wave anchor #25807 (18.2.0 release test sweep). RUNNER's extraction obligation parks checklist-accuracy findings on the anchor; the maintainer asked for them as issues, so the wave's findings are split into one card per ledger file and the anchor links each card. This is not a release blocker, so it carries no target:v18.

Reader who acts: the lane owning docs/qa/platform-checklist/** (domain:devx). Dedupe (open and closed): no card holds these lines; the 18.0 precedent closed its accuracy rows on its anchor #24579.

Wanted

For each line below, edit docs/qa/platform-checklist/areas/integration-system.json: revise the item's text, bump its revision, and append a history entry citing the run record the line comes from. Keep pnpm check:platform-checklist green. A line that turns out to describe a product defect rather than stale text gets its own card instead of a ledger edit.

Findings (26)

From #25812 — priority:P0, 23 items, at 6679644a, pin b41ed7f68956

• integration-system.datasource-credential-refusal-matrix step 2: an schemaMode: 'external' datasource needs an external: {} block or it answers 400, easy to misread as a refusal.

From #25815 — release-18.2.0-tier1, 156 items, at 6679644a, pin b41ed7f68956 (clause labels: aK = acceptance[K], nK = negative[K])

• integration-system.connector-auth-kind-application a2: verify says 'pinned by connector-materialization.test.ts (fails boot loudly when credentialRef does not resolve)'; that case asserts /credentialRef 'MISSING' did not resolve/ only — not the connector, provider or the two remedies the clause requires, and it is an in-process kernel boot, not a boot log
• integration-system.connector-auth-kind-application a3/n1: packages/spec/src/integration/connector-provider.test.ts ('rejects inline authentication secrets on a catalog descriptor / on a provider-bound instance (§3)') pins the [security] sys_metadata.metadata is a general cleartext sink: any authored artefact whose schema permits an inline credential lands it there (datasource config.password, connector authentication) #7990 half at schema level but is not in the ref; no pin found for the oauth2 discriminator refusal (spec/src/integration/connector.test.ts still parses oauth2 under AuthConfigSchema)
• integration-system.connector-declarative-boot n1 says 'any of the four malformed-entry builds' while a3 lists three rejections — the counts disagree
• integration-system.connector-declarative-boot ref's self-description matches the pin on this tree (two cases; halves only for a0–a2)
• integration-system.connector-descriptor-audit a2: plugin.ts calls auditDeclaredConnectors on both the boot and the reload path; connector-descriptor-audit.test.ts drives only kernel:ready, so the reload half has no pin
• integration-system.connector-descriptor-audit a1(c)/n1: no case in the ref feeds a provider-bound connector instance to findInertDeclaredConnectors or the kernel audit
• integration-system.connector-stdio-default-deny ref is accurate: it scopes mcp-provider.test.ts to negative[0] at the provider unit and says a0-a2 are evidence-only, a3/n1 need the run
• integration-system.datasource-admin-lifecycle a8: the ledger half names packages/services/service-datasource/src/datasource-route-ledger.conformance.test.ts as citable evidence, but it is not in automated.ref; the 404 half is pinned over a stubbed service only
• integration-system.email-template-render a5: packages/qa/dogfood/test/email-template-overlay-survives-boot.dogfood.test.ts ('after a cold boot the metadata door and the rendered mail both carry the admin's wording') pins the redeploy-survival half and is not in the ref.
• integration-system.email-template-render a3: packages/qa/dogfood/test/email-template-two-locales-survive-boot.dogfood.test.ts ('control: a locale nobody saved keeps the package ladder') touches the locale ladder and is not in the ref.
• integration-system.email-template-render ref: one e2e pin for an 8-clause item; kind 'e2e' over-implies coverage (a1, a2, a4, a6, a7 unpinned).
• integration-system.external-schema-drift-gate a4/a6: oracle is 'test' and the pins assert them, but each verify/evidence also asks for a live 'armed background drift check' log line — scored from the pin; the live line remains a boot leg
• integration-system.external-schema-drift-gate n3: no pin asserts renderDiffMessage's text (datasource/object/per-column diff) — the fail-default case asserts rejects.toBeInstanceOf only
• integration-system.external-schema-drift-gate n5: 'is a no-op when the external-datasource service is absent' asserts resolves undefined, not the absence of warn/error logs
• integration-system.external-schema-introspection a3: remote-tables-twin.equivalence.test.ts only twins listRemoteTables; the object-draft ≡ external/tables/:remote/draft twin and the shared 400 EXTERNAL_DATASOURCE_ERROR refusal across spellings are not pinned (admin-routes covers the admin spelling's 400 only)
• integration-system.external-schema-introspection a4: twin admission cases compare status+code across spellings but never assert the 403 message names manage_platform_settings
• integration-system.external-schema-introspection n0/n2: admin-routes.test.ts drives a real HonoHttpServer with vi.fn services (route-level HTTP, not a booted stack)
• integration-system.inbound-mailbox-association a2: scored at in-process — the clause's 'api' oracle is the stored rows, which the pin reads through the real engine after a real ingest; no HTTP read was made
• integration-system.inbound-mailbox-association a1: inline-forward.test.ts pins the parser's participant extraction, not that an inline-forwarded message is ASSOCIATED with the original participants' records
• integration-system.notification-org-and-redeliver-eligibility a1: notification-organization-follows-event.integration.test.ts proves organization_id on every row at the engine (ObjectQL+SqlDriver), but asserts nothing about the '[notify] no organization in scope' log line
• integration-system.notification-org-and-redeliver-eligibility a2: the foreign mark-read is pinned only at unit level (messaging-service.test.ts › [security(service-messaging): a mark-read receipt takes the organization of whichever notification the caller names, with no check that the caller was its recipient #22026] markRead writes a read receipt only for a notification delivered to that user › ⛔ the non-recipient half…)
• integration-system.notification-org-and-redeliver-eligibility a3: the redeliver pin drives the door through Request→Response (member handler + Hono canonical app) on a LiteKernel, not a full served stack

From #25817 — release-18.2.0-manual-set, 29 items, at 6679644a, pin b41ed7f68956

• integration-system.connector-degraded-recovery: steps[4]'s WARN "Connector … replaced" also prints on a husk-to-husk re-registration, so it is not a recovery signal; the descriptor state is.
• integration-system.connector-degraded-recovery: os compile accepts transport.kind:'carrier_pigeon'; only the boot refuses it.
• integration-system.notify-inbox-delivery knownGaps[2]: the app-todo scratch needs its node_modules. A symlink to the tree's copy works.

Acceptance

• Every line above is either applied (item revised, revision bumped, history cites the record) or answered on this card with the reason it was not.
• pnpm check:platform-checklist is green.
• The PR links this card and [sweep] v18.2.0 release test sweep #25807.

Generated by Claude Code