Checked-in SQL project intent

Review a database rename before anyone treats it as applied.

TraceMap can deterministically surface supported checked-in SQL project refactor intent, with provenance and explicit limitations, for design and release review.

Public claim level: demo. This static proof page is grounded in a checked-in synthetic sample at commit 26189d1dd8d97d5741005ae7cbd033840099f216. It is not build, deployment, or database-state evidence.

Proof identity

Two rules keep supported intent and unknowns separate.

Supported intent ruledatabase.sql-project.refactor-intent.v1

Gap ruledatabase.sql-project.refactor-intent.gap.v1

Extractor familySqlProjectRefactorExtractor · sql-project-refactor/0.1.0

Supported tierTier2Structural for bounded literal project linkage and supported operation identities.

Gap tierTier4Unknown for unsupported, ambiguous, unsafe, missing, or truncated evidence.

Coverage labelsbounded-static-evidence, reduced, and partial.

Public-safe flow

Project declaration becomes a review question, not an operational conclusion.

1.sqlproj

A literal checked-in reference identifies the bounded refactor-log surface.

2.refactorlog

Supported table, column, and schema identities express static project intent.

3TraceMap evidence

Rule ID, tier, relative span, commit SHA, extractor version, coverage, and limitations stay attached.

4Human review

Design and release reviewers decide what additional owner, build, runtime, and approval evidence is required.

Supported categories

Three bounded operation shapes are visible.

The table rename and schema move below are fixture-backed. The column rename is labeled as an illustrative supported category so it is not mistaken for a third fixture fact.

rename-tabledbo.InventoryItem → dbo.CatalogItem · fixture evidence · checked-in intent only

rename-columndbo.InventoryItem.DisplayName → dbo.InventoryItem.ItemName · illustrative supported category · not a fact from this fixture

move-schemadbo.CatalogItem → catalog.CatalogItem · fixture evidence · checked-in intent only

Representative evidence

Provenance travels with every fixture-backed row.

project-log-linkInventory.sqlproj → Inventory.refactorlog · Tier2Structural · line 3 · bounded-static-evidence

table-rename-intentdbo.InventoryItem → dbo.CatalogItem · Tier2Structural · refactor-log line 2 · source fact ID retained in the packet

table-schema-move-intentdbo.CatalogItem → catalog.CatalogItem · Tier2Structural · refactor-log line 7 · source fact ID retained in the packet

All paths in the JSON packet are repository-relative. Raw XML, raw SQL, source snippets, and operation keys are omitted.

Tier 4 stays visible

A gap is reduced coverage, not clean absence.

Unsupported or unsafe shapeRefactorOperationUnsupported · Tier4Unknown · review the source with an owner.

Missing project linkRefactorLogReferenceMissing · Tier4Unknown · do not infer that refactor intent is absent.

Bounded operation capRefactorOperationLimitExceeded · Tier4Unknown · truncated inventory remains partial.

Other bounded gapsMalformed, oversized, ambiguous, property-driven, globbed, conditional, path-escaping, and unreferenced surfaces remain explicit unknowns.

Downstream handoff

The same intent can route three review conversations.

Database design review

Supported operations appear as ReviewRecommended global evidence without becoming PostgreSQL schema state.

Release review

Source and target identity, supporting fact IDs, provenance, and limitations help reviewers ask whether the proposed change is aligned.

Operator runbook

The milestone state is intended-by-project-refactor-log; build, validation, deployment, and approval remain owner evidence.

Static boundary

What this proof does not establish.

No SQL project build, DACPAC creation or inspection, deployment-plan or generated-script inspection, or SqlPackage invocation.
No database connection, SQL execution, or target dbo.__RefactorLog inspection.
No claim that a refactor was deployed, applied, compatible, successful, reversible, approved, or safe to run.
No replacement for database owners, DBAs, runtime validation, tests, change control, or release approval.

Reviewer questions

End with ownership, not approval.

Identity: Does the proposed application change align with the checked-in source and target identity?
Coverage: Are unsupported, missing, ambiguous, or truncated refactor-log shapes hiding additional intent?
Validation: Who owns build, deployment-plan, compatibility, and runtime evidence?
Approval: Which database owner or DBA must review the change before an operational decision?

Follow the proof path

Keep intent, gaps, and owners together.

Full article Public JSON packet Database design review SQL operator handoff Output artifacts Evidence tiers Limitations Capabilities Rule catalog