Version. 0.25
Date. 2026-08-04
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1.
Author. Claude Code (execution session). Operator: Marvin Percival.
Supersedes. v0.24 at record 4790966. All earlier versions stand as siblings.
Changes from v0.24. B-49 Step 0 inspection run — read-only, no change produced. Establishes what gates a change request would install over, in both repositories.
B-49 Step 0 (inspection-briefs/loomworks-b49-step-0-inspection-brief-v0_1.md) executed in full, read-only, against loomworks-engine main 7bdbf8b (unmoved) and loomworks main 7a9adc9 (unmoved). Findings filed at inspection-briefs/loomworks-b49-step-0-findings-v0_1.md, copied to ~/Downloads. No workflow file touched, no pipeline triggered, no commit or branch in either repository. A throwaway database (b49_gate_walkaudit) was created for the engine suite run and dropped after; playground_dev and playground_test were never touched.
Nothing runs before code reaches main, in either repository. The engine's one workflow (doc-freshness) triggers on push: main and pull_request — but zero PRs have ever been opened against this repository; every merge is a local --no-ff pushed straight to main. The surface has no workflow files at all — confirmed both by an empty .github directory and, independently, by gh api: zero workflows registered, zero runs, ever. Neither repository has branch protection on main.
The brief's own framing of the engine's existing check needed correcting. It was framed as the candidate for a vacuous always-green pass. It is the opposite: run locally at HEAD, it fails — docs/api/ is stale against the live OpenAPI schema (206 vs. 228 operations, 289 vs. 318 schemas; 46 commits have touched the API surface since the docs were last regenerated). Checked against GitHub's own run history: 112 runs of this workflow since it was created on 2026-06-07, zero of them successful — including the run against the exact commit under inspection. A check that has been red on every run for two months, blocking nothing because nothing gates on its result, is the same hazard as a vacuous green one by a different mechanism: neither has ever stopped a merge.
Cost of gating the four commands a proposed gate would run — all run twice, locally, all deterministic (no test flipped between runs):
| Command | Result | Wall-clock |
|---|---|---|
| Engine suite (pytest) | 3522 passed, 68 skipped | ~8 min |
| Surface lint | 0 findings | ~5s |
| Surface tests (vitest) | 696/696 passed | ~17s |
| Surface build (next build, incl. typecheck) | clean, 21 routes | ~6s |
The engine suite dominates any combined gate's wall-clock by roughly two orders of magnitude over the surface's three commands combined. One environment trap surfaced and is now on record: setting LOOMWORKS_ENV=test to run the suite locally trips the posture guard added after the 2026-07-19 dev-endpoint incident (18 false collection errors) — the suite must run with LOOMWORKS_ENV unset (falls back to .env's production) and only DATABASE_URL_TEST overridden.
e2e (Playwright, surface) confirmed unable to run in CI as currently configured — its own config states neither the engine nor the Next dev server is started by Playwright itself; no orchestration exists to do so. Not run, per the brief's fence.
No candidate gate examined hardcodes a moving figure — all four commands gate on exit code, not a printed total.
Per the brief's own fences: no gate design chosen, no recommendation on ruff/mypy (B-48, untouched), no decision on whether or how e2e joins a future gate. Three truthful-coverage options were reported for a later change request; none chosen.
R-5 held — inspection only, no change, no recommendation beyond what the two questions asked. Both repositories confirmed unmoved and clean, before and after. No pipeline triggered — verified by reading GitHub's run history (a read-only API call), not by dispatching one. The discipline clause held: every count in the findings is either a command's own output or a gh api field read directly (total_count, conclusion), not a figure carried from the brief or from memory — the 112-run, 0-success count in particular was independently re-derived via the workflow's own numeric ID rather than taken from the brief's premise that the check "passes."
R-1 for this filing, on a clean pre-flight.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.25 — 2026-08-04 A check that fails every time and blocks nothing is not a passing gate. It is an unread one.