The GOVENANT Standard — Part 16: The Repo Scanner and Continuous Certification
The structural half of the audit instrument (Part 9), automated as a read-only GitHub integration — and, once installed, run as a check on every pull request, turning conformance from a quarterly snapshot into a continuous property of the codebase.
The governing constraint, stated first: code proves structure; only runtime proves life. The reference implementation’s first audit (00 §0.2) is the permanent cautionary tale — architecture excellent, delivery flatlined. A code-only scan would have graded that system beautifully while it shipped nothing. The scanner therefore carries a hard verdict ceiling (§16.3): it may assert structural findings; it MUST NOT assert ALIVE or COVERED, ever.
16.1 What the scanner is
A read-only repository integration (GitHub App first; GitLab/Azure DevOps followers) that runs in the customer’s CI environment and exports aggregate findings only — the same run-in-their-environment, nothing-leaves architecture as the self-serve audit kit (J2), with an order-of-magnitude lower ask: an App install is a familiar, scoped, revocable grant that passes security review where “read credentials to production data” dies.
One scan, three products (§16.4): the audit wedge, the integration accelerator, and governance CI.
16.2 What it detects
| Probe | What it finds | Standard basis |
|---|---|---|
| Terminal-edge inventory | Call sites that touch the world: mail/SMTP SDKs, CRM clients, payment APIs, repo mutations, filing/upload endpoints | Part 0 §0.7; the domain map, drafted mechanically |
| Side doors | Credentials and provider SDKs reachable from agent code paths — the fence-rule enumeration, automated | 15 §15.9 step 1; 14 §14.7.2 |
| Chokepoint violations | Actuation call sites that bypass the single gated function | AP-5; Part 4 §4.4 rule 1 |
| Bus bifurcation | Event types as string literals rather than typed constants imported by both sides | AP-3; Part 4 §4.4 rule 2 (“a typo must fail the build” — a linter’s job by definition) |
| Hopeful fields | Nullable reason/assertion/decided_by columns where the standard requires NOT NULL | AP-7; Part 4 §4.4 rule 3 |
| Blind sensors | Monitors filtering on fields no producer writes | AP-6 (partially static: producer→field→sensor trace) |
| Coverage invariants C1–C3 | Scope creep (duty levers ⊄ charter) and dependency-order inversions, from config | Part 3 §3.5 — explicitly “statically checkable” |
| Scheduler inventory | Cron entries, queue consumers, event subscriptions scattered across deploy config | Part 3 §3.10 — the roster-import draft, generated |
Every finding cites file:line and carries a confidence tier; low-confidence heuristics are
labeled as leads, never as findings (§16.5).
16.3 The verdict ceiling
The scanner’s maximum verdict is “structurally L2-capable”: gates exist, chokepoints hold, side doors enumerated (or absent), invariants pass. It MUST NOT claim:
- ALIVE — a database fact: one governed action traceable by ID with a verified outcome row (00 §0.5). Invisible in source.
- COVERED — a database fact: duties due vs. delivered vs. reasoned misses. Invisible in source.
- Any maturity level as achieved rather than candidate — the audit’s rules of evidence (Part 9: ground truth is the database and the code) require both halves.
The report’s own closing line enforces the upsell honestly: “Structure verified. Now prove it’s alive.” The scan is the X-ray; the runtime audit is the pulse. Selling the X-ray as the whole physical would be the instrument committing the exact fraud it exists to catch.
16.4 The three products
16.4.1 The wedge — scan-as-audit (transforms J2)
The self-serve entry drops from “grant DB access, run a kit” to “install an App, read the report in an hour.” Output: the structural scorecard, the anti-pattern findings, and the side-door inventory — forwardable to the buyer in the same afternoon. The runtime audit remains the paid second act, now pre-sold by the scan’s own ceiling disclaimer.
16.4.2 The integration accelerator — scan-to-PR (transforms Install; attacks J3-F3, J4 effort)
The scan’s output is the domain map and the gap register — so generate the work:
- Levers drafted from the terminal-edge inventory (each with its owning-role placeholder and a proposed outcome assertion from the provider’s response shape).
- The gating codemod: a draft PR per actuation call site swapping the direct SDK call for
actions.create(15 §15.3), reviewable function-by-function. - The roster import drafted from the scheduler inventory (Part 3 §3.10 steps 1–2, generated).
Install stops being a services project and becomes reviewing a pull request. Human review is mandatory — the codemod is a proposal entering through the constitution plane like any other agent-authored artifact (5 §5.2: agent-authored config is an outbound artifact).
16.4.3 Governance CI — continuous certification (the moat)
Installed as a required check, the scanner runs on every PR:
- “This PR introduces an ungated terminal edge” → blocked at merge. The fence rule becomes something that cannot regress.
- New event types without consumers, new duties failing C2/C3, new hopeful fields → caught at review time, not at the next quarterly audit.
- Certificates pin to commit SHAs (extending 13 §13.3’s version-pinning): the certificate names the SHA whose scan passed and whose runtime probes passed; the check history is the structural half of the probe log. Conformance becomes a continuous property with a public ledger of its own — a claim no snapshot-based badge can match.
16.5 Precision discipline (brand-critical)
One false “ungated edge” finding in a prospect’s repo, publicly dunked on, discredits the instrument (J2-F6, applied double — the scanner runs unattended at scale). Rules:
- Conservative by construction: findings only where the rule is mechanical (a provider SDK import reachable from an agent entrypoint); heuristics ship as labeled leads.
- Every finding cites evidence (
file:line+ the matched pattern) — the scanner obeys the audit’s own rules of evidence. - Suppressions are provenance-carrying config, reviewable and visible in the report (“3 findings suppressed by the customer”), never silent.
- Language/framework coverage is published as a matrix — a scan of a stack the scanner half-understands must say so rather than under-report.
16.6 Limits
- Code-only blindness (§16.3) — restated because it will be forgotten by sales before it is forgotten by engineering.
- Legacy is off-repo: J3’s claims core is a mainframe, not a GitHub repo. The scanner accelerates the modern-stack half of an enterprise engagement; the legacy connector work remains manual.
- Coverage matrix reality: start narrow (TypeScript + Python; the top agent frameworks; a fingerprint library of major provider SDKs) and publish the matrix. Breadth grows with the fingerprint library, which is itself a compounding asset — every engagement teaches it new edges.
16.7 Build order
- Fingerprint library for terminal edges + side doors (TS/Python, top providers) → the wedge report (§16.4.1).
- PR-check mode with the fence-rule gate (§16.4.3 minimal: block new ungated edges) — small delta over #1, disproportionate moat.
- The codemod generator (§16.4.2) — highest engineering cost, gated on #1’s precision holding in the field.
- SHA-pinned certification once the registry exists (13 §13.9 item 3).