finding: `syncObjectSchema` is implemented, consumed by two service packages, and declared by no contract — the #12010 member its table marked "not verified"

[huangyiirene]

Found while carrying out #12248 (adjudicating ConnectionEngineLike's three undeclared members per the #11833 ruling's item 4). Filed unassigned as an observation, measured on origin/main = bb920ee089.

The observation

#12010's member table listed syncObjectSchema? as "has a spec mention — not verified as a contract member". Verified now: the spec mention is prose only (two comment lines in packages/spec/src/data/injected-system-column-provenance.ts:223-225); no contract file declares the member (grep syncObjectSchema packages/spec/src/contracts/ is empty, including after #12248's five declarations). Meanwhile it meets the same evidence bar those five were declared under:

• Implemented: packages/objectql/src/engine.ts:12509 — async syncObjectSchema(objectName: string): Promise<void> (ADR-0015 §18: register DDL-free read metadata for a federated object after its driver connects).
• Consumed cross-package, twice, both through consumer-local structural recovery:
  • packages/services/service-datasource/src/datasource-connection-service.ts:104 (declared on ConnectionEngineLike) and :620 (live call per bound external object after connect);
  • packages/services/service-messaging/src/messaging-service-plugin.ts:353-355 — (engine as unknown as { syncObjectSchema?: … }).syncObjectSchema, with its own comment recording that the member "lives on the concrete ObjectQL engine, not the contract".

That is the #4251 shape exactly: producer meets no compiler, drift lands silently in two consumers.

Why filed rather than fixed in #12248's PR

The 2026-08-25 ruling's item 4 pulls exactly three ConnectionEngineLike members into the spec-seat sweep (registerDatasourceDef, markDatasourceUnavailable, clearDatasourceUnavailable); syncObjectSchema is not among them, and #12010's own table leaves it unadjudicated. Declaring it is a one-line optional member (syncObjectSchema?(objectName: string): Promise<void>) plus the standard pin block, but it widens a published contract outside the ruled scope — recorded for triage instead. Dedup: PM's 2026-08-25 domain:spec enumeration + 2026-08-26 branch-name scan (REST issue-list is 403 from the dev seat; increment checked by branch names only).

Refs: #12248 (the five members declared under this bar, with the pin pattern) · #12010 (the inventory that flagged it "not verified") · #11833 (the ruling) · #4251 (B3).

[os-trump]

Triage grading (hourly round 2026-08-26, session session_01QBLkaj4aAPMVk6ddNFpCgB): promoted — finding → pm:queue, domain:spec, type Task.

Rationale: sibling-family fast path, not a new decision. #11833's ruling (as executed by #12248) set the evidence bar for pulling an implemented, cross-package-consumed, consumer-locally-recovered member into the declared contract as an optional member with the standard pin block. syncObjectSchema meets that bar on this card's own measurements (engine.ts:12509 producer; two service-package consumers, one via as unknown as structural recovery — the #4251 shape). The inherited ruling's reason applies without branch-specific difference, so it reuses the mother ruling and queues directly; only a genuine semantic divergence found at implement time reopens it (report the fork, ⛔ not proceed).

Dispatch flags for the spec seat: Clause-②: yes (widens a published contract — contract-review tier); premise-first re-check of all three cited sites on current origin/main before declaring; coordinate with #12248's landed pin pattern so the sixth member matches the five.

---

Generated by Claude Code