Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.
migrations/0034_artifacts_page.sql — wire ?page=artifacts to the <<<ArtifactRegistry>>> tag (#458 merged it INERT: no Documents/Document_Templates pair, no nav entry). Copy 0025_shadowforge_page.sql / 0023_bug_catalog.sql.
goal
Wire ?page=artifacts to the <<<ArtifactRegistry>>> invocator. The tag EXISTS and is INERT: #458
merged checkouts/current/congruency/invocators/tags/dev/ArtifactRegistry.php, but nothing invokes it,
so ?page=artifacts returns "No such page — the DocumentID you asked for isn't in the database".
THIS IS A SPEC DEFECT, NOT A WORKER FAILURE. #458's body said "Invoked as <<<ArtifactRegistry>>> on
?page=artifacts" and then "DO NOT: add a nav/menu entry". The worker obeyed both and built a component
with no caller; the auditor passed it because it met every stated criterion. The criteria were wrong.
Do not re-litigate #458 — its PHP is merged and fine. This ticket only adds the wiring it was denied.
DELIVERABLE: migrations/0034_artifacts_page.sql
COPY THE ESTABLISHED PRECEDENT — do not invent a mechanism. 0025_shadowforge_page.sql and
0023_bug_catalog.sql already do exactly this, and 0023 states the shape outright:
"Mirrors ?page=forge / ?page=omni: a data table + api_routes + a Document_Templates/Documents
pair splicing in the <<<BugCatalog>>> invocator. Additive."
The live wiring to mirror, verified:
Documents(DocumentID='forge', TemplateID=95, Title='Forge · Congruency ...')
Document_Templates(TemplateID=95, Content= a full HTML page containing <<<ForgeView>>>)
(Document_Templates has 27 rows; Documents has 26. Store_Content_Blocks is EMPTY — a red herring,
do not use it.)
1. Insert a Document_Templates row whose Content is a full HTML page (same skeleton the sibling
templates use: <<<TitleTag>>>, <<<Style>>> in <head>, the nav, then the body) splicing in
<<<ArtifactRegistry>>>. Do NOT hardcode a TemplateID that collides — allocate past the max.
2. Insert a Documents row DocumentID='artifacts' pointing at that TemplateID, with a Title/Description
matching the house style ('Artifacts · Congruency ...').
3. ADD THE NAV ENTRY. The nav currently reads: Pages, Tags, Bugs, forms, tickets, Graphs, Source,
Forge, Omni-git, Shadow Forge, Memory Graph, memories, Source, Docs, Repo Docs, API, Search,
Annotations, Database. 'Artifacts' belongs beside Forge/Omni-git. Add it wherever the siblings do
it — find that, mirror it, do not invent a second nav mechanism.
4. ADDITIVE + IDEMPOTENT + SELF-CONTAINED, exactly as 0023 requires of itself: CREATE ... IF NOT
EXISTS any base table it touches so it applies to a bare db (a fresh seed / the migration-isolation
shadow), and re-applying must not duplicate rows or collide on a TemplateID.
5. NO SCHEMA CHANGES, no new tables, no data. ticket_artifacts already exists and already has 20
kind='forge-vm' rows from #455. This migration is wiring only.
ACCEPTANCE (all live, all re-runnable):
* After applying, `curl '?page=artifacts'` renders the registry — NOT "No such page". It must show
kind as the tag with counts (today: forge-vm 20).
* `?page=artifacts&kind=forge-vm` lists the items; each row links to its sha detail;
`?page=artifacts&sha=cafa1a965b591b7c4184b484ffd8e625981a79d48f9b4ae8a4adf7b4c5ade927` shows
noble-arm64-base.img and every location that sha lives at.
* 'Artifacts' appears in the nav beside Forge / Omni-git.
* Applying it TWICE is a no-op (idempotent) — prove it.
* schema_migrations gains exactly one row: 0034_artifacts_page.sql.
* No other page regresses: ?page=forge, ?page=omni, ?page=tree still render.
RUN ON CLAUDE.
patch
none
approval
unapproved
runs
no runs recorded
mandate (clauses)
not yet recorded — lands with the ticket-class build
manifestations
not yet recorded — lands with the ticket-class build
guarantees
not yet recorded — lands with the ticket-class build
journey (blunders & successes)
not yet recorded — lands with the ticket-class build