Skip to main content

0028: Retire The Solo Unity Attestation Pipeline

Status: Accepted

Date: 2026-07-21

Context​

The Solo Unity profile began as a proportional catalog of tools the owner had used successfully: Unity MCP, VContainer, UniTask, PrimeTween, Odin, Feel, Animancer, Shapes, Wwise, editor-comfort assets, and related Unity packages. Read-only detection, exact-version recording, explicit license authority, and bounded package or source apply operations address recurring problems in the owner's real projects.

The profile later grew a parallel evidence system around those useful operations. Its prescribed sequence created immutable revision directories, slice charters, normalized test receipts, three assessment generations, per-dependency human worksheets, nonce-bound operational requests, finalized receipts, conflict-resolution receipts, rendered status reports, and atomic milestone manifests.

That subsystem now occupies at least 70 active files and roughly 27,500 lines across scripts, schemas, tests, and tracked Lanternworks artifacts. The owner runbook requires eleven numbered phases. After the full Lanternworks replay, the generated owner report still showed zero fully ready dependencies and six outstanding human or live-Unity checks. The machinery faithfully reported that those checks had not happened, but it did not make the checks easier to perform, improve the game, or serve another consumer.

The system therefore optimized integrity of its own evidence chain instead of the owner's actual constraint: limited attention for making and judging games. Git already preserves checkpoints. Unity already owns compilation, import, tests, logs, profiling, Game view, and runtime behavior. A direct observation with a concise checkpoint note is adequate unless a real external consumer requires a portable receipt.

Decision​

  • Keep the Solo Unity dependency catalog, capability bundles, proportional recipes, project-safe detection, and explicit authority metadata.
  • Keep read-only bootstrap planning and bounded, reviewed package or owner-source apply operations where they reduce a demonstrated risk.
  • Use the ordinary STAGE delivery loop for game slices. Do not require a profile-specific slice charter.
  • Verify dependency adoption directly in Unity through the package's named readiness checks, settled Console, focused tests, composed use where relevant, human inspection where required, and an intentional Git checkpoint.
  • Retire profile assessments, assessment versions, status rendering, human acceptance packets, operational proof packets, evidence-conflict receipts, atomic milestone bundles, and their compatibility schemas.
  • Do not normalize Unity results into STAGE-owned JSON merely to prove that Unity's own result existed. Preserve raw output only when a named consumer needs it.
  • Preserve the rejected design and its measured results in Git history and in this ADR. Do not keep active generated examples solely as monuments to the experiment.
  • A future portable receipt must identify its independent consumer before new schema or orchestration work begins.

Consequences​

  • The profile becomes a personal stack guide and safe bootstrap helper instead of a release-governance system.
  • Starting or extending a Unity project no longer requires an external evidence directory or assessment lifecycle.
  • Human judgment remains required for feel, visuals, workflow comfort, and product value, but it happens on the owning surface instead of through an attestation form.
  • Agents still fail closed on dirty repositories, unauthorized private assets, stale plans, unsupported versions, and mutation outside an approved boundary.
  • Historical assessment and conflict-resolution interfaces are intentionally removed before STAGE 1.0 because no independent consumer depends on them.

Evidence Boundary​

The file and line counts measure this repository, and the owner report measures one same-owner dogfood project. They do not prove that formal evidence systems are useless in regulated, safety-critical, multi-team, vendor, or external audit settings. They prove that this particular system was disproportionate to one person making Unity games in spare time.

Last updated on