finding: `IObjectQLEngine.getSchema` still returns `unknown` — the fork-3 defect class, one member over from the #12248 `getObject` fix

[huangyiirene]

Found while carrying out #12248 (typing getObject per the #11833 ruling's fork 3). Filed unassigned as an observation, measured on origin/main = bb920ee089 (branch base of PR for #12248).

The observation

#12248 types IObjectQLEngine.getObject / EngineSchemaRegistryView.getObject as ServiceObject | undefined because the class has always returned that type and ServiceObject lives in spec (data/object.zod.ts), voiding the header's "engine-local type" rationale for unknown. The member ONE LINE ABOVE has the identical shape and was not in the ruled scope:

• Contract: packages/spec/src/contracts/objectql-engine.ts:191 — getSchema(objectName: string): unknown;
• Implementation: packages/objectql/src/engine.ts:6360 — getSchema(objectName: string): ServiceObject | undefined (and getObject is literally its alias, engine.ts:12382).

The measured consumer re-narrowing (the same drift the #4251/#11493/#11833 sweeps keep finding)

Cross-package callers reading getSchema through casts or any today (grep on the base ref, non-test):

• packages/plugins/plugin-security/src/security-plugin.ts:1592 — ql.getSchema(opCtx.object) as EngineOwnedSchemaLike | undefined (plus ~4 more probe sites in the same file);
• packages/services/service-messaging/src/sql-http-outbox.ts:275 — engine.getSchema(this.objectName) as …;
• packages/metadata-core/src/record-organization.ts:79,229 — (engine as any).getSchema(objectName);
• packages/runtime/src/action-execution.ts:1596 — ql.getSchema(objectName) under a typeof probe.

Why filed rather than fixed in #12248's PR

The 2026-08-25 ruling on #11833 names getObject (fork 3) and the three ConnectionEngineLike members (item 4); getSchema is in neither table. Typing it is the same one-line change plus the same consumer-compat verification, but it moves a contract member outside the ruled scope, so it is recorded for triage instead. Dedup: the PM's 2026-08-25 domain:spec enumeration (51 open, none covering these members) plus a branch-name scan on 2026-08-26; the REST issue-list channel is 403 from the dev seat, so the post-enumeration increment was checked by branch names only.

Refs: #12248 (the fix one member over, with the pin pattern to copy) · #11833 (the ruling) · #11493 / #4251 (the evidence bar).

[os-trump]

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

Rationale: same sibling-family fast path as #12482, graded this round — #11833's ruling as executed by #12248 (fork 3: getObject typed to ServiceObject | undefined because the implementation always returned it and the type lives in spec) applies to getSchema without branch-specific difference: getObject is literally its alias (engine.ts:12382), so the mother ruling's reason transfers whole. Reuses that ruling and queues directly; a genuine semantic divergence found at implement time is a fork to report, ⛔ not proceed.

Dispatch flags for the spec seat: Clause-②: yes (changes a published contract member's declared type — contract-review tier). Fold-or-serial, pre-answered as fold-eligible with #12482 on the five gates: ① same defect shape and fix pattern (contract-member adoption per #12248's pin pattern); ② same region (packages/spec/src/contracts/objectql-engine.ts + pin blocks); ③ both members ruled by inheritance from #11833/#12248; ④ independently verifiable — one named pin per member, one commit per card if folded; ⑤ exclusion list: any other unknown-typed or undeclared engine members NOT measured on these two cards (including the rest of #12010's "not verified" rows) are out — folding is these two members only, ⛔ no "same shape" sweep. The spec seat makes the final fold/serial call at claim time; consumer-compat verification across the four cast sites named on this card is part of the acceptance either way.

---

Generated by Claude Code