feat(governance): consume the Core artifact schema references — GAP-020 (2 of 4)

[beyondnetPeru]

The row was reopened by product direction with a precise complaint: a satellite that only documents the link has not consumed it. CORE_ARTIFACT_SCHEMAS.md let a reader find the canonical shape of a PRD; no machine could.

What ships

The correspondence lives as data in CoreArtifactSchemaCatalog, and every artifact served by GET /api/phase-artifact-profiles now carries it:

{ "artifactKind": "prd", "label": "PRD", "required": true,
  "canonicalSchema": { "schemaId": "https://evolith.dev/schema/prd.schema.json",
                       "provenance": "core-schema" } }

The artifact-fields screen renders it as a link.

Three values, not a nullable id

value	meaning	what to do
core-schema	the Core publishes a canonical shape	follow the $id
tool-output	the Core deliberately publishes none	read the tool's own format
none	nothing upstream covers it	the tenant's ArtifactFieldSchema is the only authority

Collapsing the last two into null would erase the difference between a gap someone should close and a decision already taken.

The mapping is a decision, so it is guarded like one

A slug matcher would miss security-scan-result ⇄ Security Scan Report, rollback-plan ⇄ Rollback Procedure and observability-readiness ⇄ Observability Validation — and miss them silently. CoreArtifactSchemaCatalogTests parses the markdown table and compares both ways: a documented row nobody wired fails, and a wired entry nobody documented fails too. Verified by breaking it in both directions, not assumed.

adr-registry is deliberately not mapped to adr.schema.json: a registry is a list of ADRs and not an ADR, so the mapping would look like coverage and produce a false negative against the real artifact.

What I deliberately did NOT build — please sanity-check this call

Hardwired validation of artifact content against these schemas. The reopen text asks for it ("usarlas para validar los artefactos que personas o agentes llenan"), and T-056 — which you ratified — says content validation is the tenant's configuration and not engine code. So the reference is exposed for a tenant's own configuration to point at, and nothing here rejects an artifact. Enforcing it would make the Core the authority over what a tenant may record. Flagging it rather than skipping it quietly.

Local: 6/6 new tests; frontend lint + typecheck + build green. The 10 integration failures on my machine are the DB-gated suite that fails by design without PostgreSQL — CI provides it.

Board: 0 OPEN, 1 DEFERRED, 107 RESOLVED.

🤖 Generated with Claude Code

[beyondnetPeru]

Correcting the bookkeeping before this merges: GAP-020 stays OPEN.

The reopen asked for four things. This PR does two.

ask	state
consume the Core schema references	✅ done
expose them in the phase forms	✅ done
persist or cache them tenant-aware	❌ not built
use them to validate what people and agents fill in	❌ not built — collides with T-056

Closing the row on two of four would be precisely the defect this session has been undoing all week: a row that reads as done while a stated requirement is unbuilt. The row is narrowed instead, and the board and catalog are back to PENDING with the progress recorded — the tri-surface guard from #107 checks that they agree.

On the two that remain: tenant-aware caching is arguably unnecessary, since the references are Core-authoritative and tenant-agnostic — but that is my judgement and the row has not ratified it. Content validation needs a product decision first, because T-056 puts it in the tenant's configuration and not in engine code.

Board: 1 OPEN, 1 DEFERRED, 106 RESOLVED.