canon(constraints): infra-config-is-seat-work — deploy is push, dashboard ≠ HUMAN-ONLY

[git-repo-auth]

Captain-ordered 2026-09-02 after the seventh recurrence of the same correction ("you do it for me all the time, then claim it is human-only"). Census of 40 repos pushed since 2026-03 found the ruling written locally in AMS (SPEC v1.1.1, 05-05 incident), appbuilder-mcp, bee-ai-auth (docs/ci-cd.md), and CDO — never at L1. This is the L1 sentence; the house wire is kitchen#69 §10.

Also done tonight, by API: 4 Workers (AMS, appbuilder, ptxprint, tincan) still had wrangler deploy on non-main triggers in violation of the 2026-05-05 ruling; patched to versions upload. All 17 house Workers now conform.

Captain reviews exact text before merge.

---

Note

Low Risk
Documentation-only L1 policy; no application code changes in this diff, though it governs how seats handle deploy and infra handoffs.

Overview
Adds a ratified L1 constraint (canon/constraints/infra-config-is-seat-work.md) so infra expectations live in canon instead of scattered repo docs.

It states that production deploy is merge-to-default / git push (no manual wrangler deploy), that wiring (domains, bindings, secrets, repo hooks, etc.) is done by the seat via the provider API—not by asking the captain to use a dashboard—and that HUMAN-ONLY is a closed set: secret, voice, irreversible, or approval; labels like “dashboard,” “manual,” or “connect the repo” count as seat misses.

The WHY section documents seven recurring captain corrections and ties enforcement to existing pieces: house health-code for concrete API steps, boarding shims citing this URI, and returning PRs that tag HUMAN-ONLY without a valid class (aligned with human_only_class_named in odd/gate/prerequisites.md).

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

[github-actions]

Canon Quality — Frontmatter Schema ✅

All 51 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: #437}

[github-actions]

Canon Quality — Homepage Surfacing ✅

51 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 — P0010 Retrieval-Readiness ⚠️

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

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

Kind distribution: {'essays': 53, 'canon': 250, 'apocrypha': 38, 'docs': 307, 'journals': 60, 'unknown': 6}
Kind source: {'path': 576, 'frontmatter': 132, 'none': 6} (frontmatter-primary, path-secondary)
Default-include visibility: 610 visible, 104 hidden (journals/apocrypha/unknown)

By rule: {'audience-invalid': 4, 'exposure-missing': 7, '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: #437}

[github-actions]

Canon Quality — oddkit_audit ✅

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

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