[finding] objectql's derived IntrospectedColumn.isUnique doc still says "has a unique constraint" after #11202 narrowed the producer to single-column uniqueness #11655

Found while implementing #11202. A one-line documentation drift, filed rather than fixed because the file is outside that card's declared file surface.

What

isUnique is not declared on the spec's IntrospectedColumn (packages/spec/src/contracts/schema-diff-service.ts) at all — it is a documented "SQL-introspection extra" carried on two derived interfaces:

• packages/drivers/driver-sql/src/sql-driver.ts — the producer's own declaration.
• packages/objectql/src/util.ts — the consumer-side derived declaration, currently:

export interface IntrospectedColumn extends SpecIntrospectedColumn {
  /** Whether this column has a unique constraint */
  isUnique?: boolean;

#11202 narrowed the flag's meaning across all three dialect arms: it is now true iff the column alone carries a single-column unique constraint, and membership of a composite UNIQUE (a, b) is deliberately not represented. The producer's declaration was updated to say so in that PR. The objectql copy above was not, and now over-claims in exactly the direction the ruling removed — "has a unique constraint" is the composite-member reading.

Why it matters beyond tidiness

This file is where the flag is consumed: introspectedSchemaToObjects a few lines below turns column.isUnique into a drafted field's unique: true. So the sentence a reader checks before trusting that mapping is the stale one, and it disagrees with the producer three packages away. Two declarations of one key with two different meanings is the seam #11122's ruling (「packages/spec is the one contract, producers align to it」) was closing.

Fix

Restate the narrowed semantics on the objectql declaration, pointing at the producer's contract sentence rather than paraphrasing it a third time. No behaviour change — documentation only.

Filed unassigned, per the finding rule.

Generated by Claude Code