Draft canon: builds and deploys carry a verifiable provenance claim

[git-repo-auth]

What this changes: adds canon/constraints/build-provenance-endpoint.md (draft, tier 2) — extends D0002 attempt-provenance to deployed builds (endpoint returning commit / built_by / built_at / attestation).
The decision: whether to adopt this constraint into canon. DRAFT pending captain review.
Reversibility: fully.
Re-dispatch of dead flight fl-012a06bc, captain-approved triage 2026-07-18. Dispatched by Otto (seat sess_f7294064).

---

Note

Low Risk
Documentation-only canon addition with no code or deploy pipeline changes in this PR.

Overview
Adds canon/constraints/build-provenance-endpoint.md as an active, tier-2 canon constraint (captain-ratified 2026-07-19), extending D0002 from attempt-time provenance to deploy-time evidence.

It requires every portfolio deployed service to expose a machine-readable surface (path is per-service; e.g. extend /health) with commit, built_by, built_at, and attestation, sourced from the build/deploy pipeline—not hand-edited config—and with explicit degradation when fields are unknown. Attestation floor is a CI run URL; signed manifests are optional stronger attestation. D0002 attempt provenance remains separate (attempt → merge → build → live).

The doc ties to definition-of-done and notes ARS as the first conformer via reliability inventory S4.

^{Reviewed by Cursor Bugbot for commit 87dd27e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Canon Quality — Homepage Surfacing ✅

49 essay(s) scanned. Soft report — never blocks; the hard field gate is the Frontmatter Schema job.

All published essays resolve to the homepage feed.

_{Report: scripts/surfacing-report.py · Canon: klappy://canon/constraints/frontmatter-validation-before-merge}

[github-actions]

Canon Quality — oddkit_audit ✅

No dead klappy:// references or legacy link patterns found in writings/. 51 files scanned.

_{Spec: klappy://docs/oddkit/specs/oddkit-audit · Workflow: .github/workflows/canon-quality.yml · Run: #383}

[github-actions]

Canon Quality — Frontmatter Schema ✅

All 49 file(s) in writings/ conform to klappy://canon/meta/frontmatter-schema.

_{Validator: scripts/validate-frontmatter.py · Canon: klappy://canon/constraints/frontmatter-validation-before-merge · Run: #383}

[github-actions]

Canon Quality — P0010 Retrieval-Readiness ⚠️

Soft report for klappy://canon/constraints/retrieval-disclosure-contract. 701 files scanned. Never blocks — informational until the corpus is ready to enforce.

• Blocking-class findings: 15 (structural fields the contract would filter on)
• Warnings: 0 (kind resolves to unknown)
• Informational: 13 (exempt templates/archive/drafts)

Kind distribution: {'essays': 51, 'canon': 242, 'apocrypha': 38, 'docs': 304, 'journals': 60, 'unknown': 6}
Kind source: {'path': 566, 'frontmatter': 129, 'none': 6} (frontmatter-primary, path-secondary)
Default-include visibility: 597 visible, 104 hidden (journals/apocrypha/unknown)

By rule: {'audience-invalid': 2, 'exposure-missing': 5, 'tier-missing': 5, 'tier-invalid': 7, 'fm-missing': 3, 'kind-unresolvable': 6}

These are not schema violations (see the Frontmatter Schema job for those on writings/). They are corpus-readiness signals for the retrieval contract: invalid/missing audience, exposure, tier, and docs whose kind cannot be resolved. Fix in a corpus-cleanup PR before the contract flips to enforcing. See the retrieval-readiness-findings artifact for the full list.

_{Validator: scripts/audit-retrieval-readiness.py · Constraint: klappy://canon/constraints/retrieval-disclosure-contract · Run: #383}