0031: Close Owner-Source Transfer At The Staged Checkpoint

Status: Accepted

Date: 2026-07-21

Context

The Solo Unity profile grew four source-oriented operations:

1. inventory exact committed dependency bytes from an authorized reference;
2. transactionally apply an approved subset to a target project;
3. verify the target index before commit; and
4. rebuild a clean post-commit provenance comparison from the profile and both repositories.

The first three form one useful transaction. Inventory establishes authority, paths, modes, .meta companions, exclusions, package declarations, and LFS source state. Apply rejects conflicts and rolls back its own partial work. The staged checkpoint then catches the gap that apply cannot see: Git attributes or LFS filters may transform bytes during staging, and unrelated paths may enter the commit.

The fourth operation repeated the committed comparison after that transaction. It had one same-owner Lanternworks consumer, produced a 421-line retained receipt, and was absent from the active owner workflow. Reconstructing it from the current catalog and recipe also made a historical source claim depend on profile state that may legitimately change later.

Decision

• Keep source inventory, transactional apply, and staged checkpoint as the complete optional exact-source transfer workflow.
• Surface the staged checkpoint in the Solo Unity profile and owner runbook.
• Require the checkpoint only when the STAGE source-transfer tools copied an exact owner-controlled source. Do not add it to ordinary package changes or authored asset work.
• Keep the checkpoint result transient by default. Save it only for a named audit, release, or migration consumer.
• Retire the generic post-adoption dependency-provenance schema, verifier, tests, and generated Lanternworks receipt.
• Preserve historical exact-source conclusions in the case study and Git history without presenting the retired receipt as active evidence.

Consequences

• The rare licensed/local-source workflow has one explicit closing safety gate before commit.
• Normal game development remains unaffected.
• Agents no longer maintain two exact-byte evidence formats around one source transfer.
• Later source audits can compare pinned revisions directly or introduce a purpose-built migration check when a concrete upgrade requires one.
• The target project and its committed files remain authoritative after the transfer; STAGE does not become the long-term owner of imported dependencies.

Evidence Boundary

The staged checkpoint proves only that the intended index contains the receipt-bound source bytes, package declaration, allowed project-owned paths, and declared storage policy. Unity import, compilation, composed use, license entitlement, usefulness, upgrades, and human workflow acceptance still require their owning checks.