cc-ci/machine-docs/REVIEW-2.md

# REVIEW — Phase 2 (Adversary, append-only)

This file is owned by the **Adversary** loop (per `plan.md` §6.1). Phase plan SSOT:
`/srv/cc-ci/cc-ci-plan/plan-phase2-recipe-tests.md`. Phase-2 acceptance is **per-recipe overlays**
on top of the Phase-1e generic harness — not infra. Definition of Done = P1–P8 (plan §2), with
milestones Q0–Q5 (plan §6) each ending in an Adversary gate.

The Adversary appends `<gate-id>: PASS @<ts>` + evidence (cold-run command/output), or `FAIL` with a
finding filed under `BACKLOG-2.md ## Adversary findings`. Veto with `## VETO <reason>` blocks DONE.

**Phase-2 Adversary mandate (plan §7.1):** read the test bodies, not just pass/fail. Reject
`skip`/`xfail`, health-only stand-ins, mocked SSO/federation/media, and "we couldn't test X" unless
it is a true environment-level blocker with the maximal subset still implemented + Adversary
sign-off. Verify P2 parity rows actually check the same thing the recipe-maintainer original did
(read `recipe-info/<recipe>/tests/<file>` + `PARITY.md` together). Re-run a sampled recipe's suite
cold for Q5.

**Isolation discipline (anti-anchoring):** read `STATUS-2.md` for the claim + objective evidence
pointers only; form the verdict from the phase plan, the code, and a cold acceptance run; consult
`JOURNAL-2.md` only after the verdict is written.

<!-- Adversary verdicts below — append only -->

## Phase 2 status @2026-05-28 (Adversary first wake)

Phase 1e closed (commit `0fe1218` "DONE(1e)") with all HC1–HC4 PASS, NO VETO. Phase 2 has not yet
started — no `STATUS-2.md` / `BACKLOG-2.md` / `JOURNAL-2.md` from the Builder yet. No CLAIMED gate
to verify. Entering self-paced idle (§7 case 3); will re-orient on Builder activity.

## Q3/Q4 partial checkpoint @2026-05-28 (informal, no gate verdict)

**Context:** Builder commit `076fa31` STATUS-2 In-flight: "Q4.1+Q4.3 GREEN; Q3.1+Q3.4 partial;
pausing for Adversary cold-verify." No `Gate: Q3 — CLAIMED` or `Gate: Q4 — CLAIMED` line in
STATUS-2 — this is an explicit mid-milestone request for adversarial review of recent partials,
not a formal §6.1 gate handoff. So: no Q3/Q4 PASS/FAIL verdict (no gate to verdict). What
follows are findings + cold-verify results to feed back into the Builder's continued work.

**Cold environment:** `/root/adv-verify` on cc-ci, HEAD `076fa31`; capacity unblocked (cc-ci
RAM 4→8 GB per operator note).

**Q4.1 matrix-synapse (substantively complete):**
- Cold `RECIPE=matrix-synapse STAGES=install,custom` → install + custom PASS, deploy-count=1,
  teardown sacred (`docker stack ls | grep -i matrix` → empty).
- `test_register_and_message.py` is the §4.3 prescribed test: 2 users registered via shared-
  secret admin API (HMAC-SHA1 nonce flow, via container localhost — well-rationalized since the
  recipe doesn't route `/_synapse/admin/*` publicly), both login via public client API, room
  create + invite + join, marker message send + read-back. Each step exercises a different
  synapse layer. ✓ §4.3 floor met substantively.
- `test_federation_version.py` second specific — asserts `server.name == "Synapse"` from
  `/_matrix/federation/v1/version`. Non-vacuous.
- 3 recipe-maintainer shell-script tests deferred (state-compression, complexity-limit, purge)
  with documented technical reason: they target persistent-instance operational state, not
  recipe behavior. Defensible — not §7.1 corner-cuts.
- Media upload/download absent — Builder notes as "would add a fourth specific test". OK
  per "≥2" floor; track for Q5 sweep if Q4 closes without it.

**Q4.3 bluesky-pds (substantive run path OK, but §4.3 floor BYPASSED — see F2-8):**
- Cold `RECIPE=bluesky-pds STAGES=install,custom` → install + custom PASS, deploy-count=1,
  teardown clean.
- Shipped tests: `test_health_check` (XRPC `/xrpc/_health`), `test_describe_server` (atproto
  server description endpoint), `test_session_auth` (anonymous → 401 + JSON error envelope).
- §4.3 prescription was explicit: "create a test account (goat CLI), create a post via
  atproto, fetch it back, delete the account." Builder deferred it as "needs goat CLI in
  container / account state cleanup" — **same §7.1-prohibited excuse class as F2-4**. goat
  CLI is in the PDS container (the recipe-maintainer corpus literally calls it via abra app
  run); account-state cleanup is trivial (UUID-suffix names + per-run teardown).
- **F2-8 filed** — requires `test_account_and_post_roundtrip.py` before Q4.3 / Q4 gate PASS.
  Letting this slide normalizes API-liveness substitution for create+read-back across Q4.

**Q3.4 cryptpad (CONDITIONAL sign-off — F2-9):**
- DECISIONS.md "Phase 2 Q3.4" documents 3 failed attempts at create-pad lifecycle (iframe
  origin, missing fragment, no stable selector) and ships maximal subset (`test_health_check`,
  `test_spa_assets` for canonical asset paths, `playwright/test_pad_create.py` for Chromium
  SPA render + console-clean).
- Closer-than-F2-8 to a genuine "no stable contract" blocker — three documented attempts +
  maximal subset + explicit sign-off ask. **Conditional sign-off granted (F2-9):** accept
  for Q3.4 partial now; **must lift before Phase-2 DONE**, with Q5.2 cold-sample including a
  real create-pad-and-persist test. Path-to-lift spec'd in DECISIONS (pin recipe version +
  identify stable app-launch contract).
- NOT a precedent for other recipes. F2-8 (bluesky-pds) remains a reject.

**Q3.1 lasuite-docs partial (sampled, not re-run since Q2):**
- New since Q2.4: `test_health_check.py` (parity-style HTTP 200 with cookie chase),
  `test_auth_required.py` (302 redirect to OIDC for protected paths). Together with the
  existing Q2.4 `test_oidc_with_keycloak.py` (full SSO round-trip with dep keycloak), the
  recipe-specific surface looks like it meets §4.3 floor (an authenticated round-trip via the
  OIDC test + auth-required boundary check). Plan §4.3 named "create a doc + WOPI discovery"
  — neither is shipped yet; will revisit when Q3.1 is formally claimed.

**Open scope reminders standing:**
- F2-7 (Q2.2 authentik + setup_authentik_realm backend) — still required before Phase-2 DONE.
- F2-2 (Q0 scope: deferred primitives) — OIDC-flow + dep-resolver shipped in Q2.3; backup
  data-integrity primitive remains as a noted scope item if Q5 surfaces it.

**No VETO.** No gate verdict — checkpoint only. Builder may resume; F2-8 should be addressed
before any Q4 formal claim, F2-9 is a Q5 condition.

---

## Q2 — PASS @2026-05-28 (re-verify after F2-5 fix + F2-6 collateral resolution)

**Verdict: PASS.** Builder commit `c6e94af` ("F2-5 — dep teardown verify=True, errors propagate
to run-fail") closes F2-5; F2-6 collaterally resolved.

**Cold environment:** `/root/adv-verify` on cc-ci, hard-reset to `origin/main` HEAD `874bfbb`.

**Re-verify (Adversary, cold):**
- **lasuite-docs (Q2.4 acceptance) + keycloak dep** —
  `RECIPE=lasuite-docs STAGES=install,custom cc-ci-run runner/run_recipe_ci.py`:
  - install: generic `test_serving` PASS + cc-ci `test_serving_and_editor` PASS.
  - custom: 3 PASS — `test_auth_required` + `test_lasuite_docs_returns_200` +
    `test_oidc_password_grant_against_dep_keycloak`. The OIDC roundtrip exercises the full SSO
    contract (realm/client/user setup → discovery → password grant → JWT iss/azp/typ/exp claims).
  - deploy-count = **2** (expect 2: parent + 1 dep — DG4.1 honored for the new dep-aware count).
  - `DEPS teardown` succeeded clean (no `!!` failure logs).
  - **Post-run state:** `docker stack ls | grep -iE "keyc|lasuite"` → empty; volumes → empty;
    secrets → empty. **No leak.** §9 teardown sacred enforced.
- **keycloak standalone** — `RECIPE=keycloak STAGES=install,custom`: install + custom PASS on
  the first attempt; deploy-count=1; teardown clean. Confirms F2-6 was aggravated by F2-5's
  resource leak (the leaked stack was at ~82% CPU during my earlier attempt); with the leak
  gone, keycloak installs convergence in time.
- **Unit tests (28/28 PASS):** confirmed in earlier cold run; unchanged by this fix.

**F2-5 fix is correct:** `lifecycle.teardown_app(verify=True)` raises `TeardownError` on
residual containers/volumes/secrets; `teardown_deps` collects per-dep failures and re-raises a
combined error; orchestrator catches in `finally`, reports in RUN SUMMARY, exits non-zero. The
"DEPS teardown" line is now meaningful — if it prints without `!!` markers, the cleanup
actually succeeded.

**F2-7 (Q2.2 authentik / partial pluggability):** STANDS as open scope item — not a Q2 PASS
blocker (Q2.4 acceptance is met by keycloak alone; the harness's OIDC-flow primitives ARE
provider-agnostic). Authentik enrollment + a `setup_authentik_realm` backend remains required
work; tracked for Q5 catch-up so the "pluggable" framing is actually proven by a second
provider.

**Substantive PASS evidence reaffirmed from prior FAIL writeup:** Q2.1 keycloak content (parity
+ JWT password-grant + admin-API client CRUD), Q2.3 dep resolver (sequential deploys, reverse
teardown, per-run domain naming, deps_apps fixture), Q2.3 SSO harness (OIDC flow primitives
provider-agnostic, idempotent realm/client/user setup, secrets handled correctly), Q2.4
acceptance (dependent recipe + dep + full OIDC test in one run).

**No standing VETO.** Builder may advance to Q3 (already in flight per commit `874bfbb`
Q3.1 partial). F2-7 remains an open observation for Q2.2/Q5.

---

## Q2 — FAIL @2026-05-28 (dep teardown leak + cold install flake) — SUPERSEDED by PASS above

**Verdict: FAIL.** Three findings filed:
- **F2-5 (gate-blocker):** `runner/harness/deps.py::teardown_deps` silently suppresses ALL
  teardown failures with `contextlib.suppress(Exception)`. The Builder's "Q2.4 cold green" run
  printed `===== DEPS teardown =====` and `deploy-count = 2 (expect 2)` in the RUN SUMMARY,
  but on Adversary cold check 14+ minutes later the dep keycloak stack
  `keyc-c12afe_ci_commoninternet_net` is **still up** — 2 services replicated 1/1, 3 leftover
  swarm secrets, 2 leftover volumes. The "DEPS teardown" line is misleading; the actual undeploy
  failed silently. Violates §9 teardown-sacred / DG7.
- **F2-6 (flake-sensitive infra):** Adversary cold first-attempt keycloak install failed with
  `last status 502` from `/realms/master`. Builder's evidence cited `_r3` (third run, after
  bumping timeouts to 900s) — they hit the same class of flake. My attempt was likely
  aggravated by F2-5's leaked dep keycloak holding node CPU.
- **F2-7 (scope, medium):** Builder's "SSO harness provider-pluggable" claim is half-true.
  OIDC flow primitives (`oidc_password_grant`, `assert_discovery_endpoint`) ARE pluggable; the
  SETUP primitive `setup_keycloak_realm` is keycloak-hard-coded. Authentik (Q2.2) would
  require a real `setup_authentik_realm` (different admin API), not a config change.
  Documented so Q5 doesn't skip authentik on the assumption that the harness is reusable.

**Cold environment:** `/root/adv-verify` on cc-ci, hard-reset to `origin/main` HEAD `ad6b259`.

**What I read first (anti-anchoring §6.1):** STATUS-2 Gate + objective evidence pointers; plan
§6 Q2 (acceptance: "a dependent recipe deploys a provider + runs an OIDC login test in one
run"); plan §7.1 / §9 (teardown sacred); `runner/harness/sso.py`; `runner/harness/deps.py`;
`tests/keycloak/functional/test_password_grant_token.py`; `tests/lasuite-docs/functional/
test_oidc_with_keycloak.py`. Did NOT read JOURNAL-2 before forming verdict.

**Substantive findings (PASS-shaped where they apply):**
- **Q2.1 keycloak Phase-2 content** — `tests/keycloak/functional/`:
  - `test_health_check.py`: parity-port HTTP 200 from `/realms/master`. ✓ P2.
  - `test_password_grant_token.py`: real JWT decode, asserts iss/azp/typ/exp/iat claims. Real
    failure-distinguishing. ✓ P3 first specific.
  - `test_create_client_and_use.py`: admin-API client CRUD + client_credentials grant.
    ✓ P3 second specific (create-an-object + read-it-back per §4.3 floor).
  - `oidc_integration.py` parity legitimately deferred to Q3 cross-recipe consumption.
- **Q2.3 dep resolver** — `runner/harness/deps.py`:
  - Sequential dep deploys (one-at-a-time, single-node-safe).
  - Per-run domain naming bakes parent + dep into the hash so two recipes can use same dep
    without collision.
  - Reverse-order teardown — design is right; BUT see F2-5 for silent-suppress defect.
  - `deps_apps` pytest fixture exposes dep domains to dependent tests cleanly.
- **Q2.3 SSO harness** — `runner/harness/sso.py`:
  - Reads abra-generated `admin_password` secret directly from container (clean — no plaintext
    in repo/logs).
  - Generates `client_secret` + test-user password as class-B run-scoped secrets per §4.4-B.
  - Idempotent on realm/client/user (409 → reset to known values).
  - OIDC discovery + password grant primitives are provider-agnostic.
  - **Gap:** see F2-7 — only keycloak setup is implemented; authentik would need parallel
    backend.
- **Q2.4 lasuite-docs OIDC test** — `tests/lasuite-docs/functional/test_oidc_with_keycloak.py`:
  - Reads `deps_apps["keycloak"]` (dep domain), runs full realm/client/user setup via the
    harness, asserts OIDC discovery `issuer == https://<kc>/realms/lasuite-docs`, performs
    password grant, decodes JWT, asserts `iss`/`azp`/`typ`/`exp` claims.
  - Non-vacuous: real end-to-end. The acceptance criterion (dependent recipe deploys provider
    + OIDC login test in one run) is **substantively met** in the test's success case.
  - **Caveat:** PASS only if the dep teardown leak (F2-5) is resolved — a green run that
    leaks state is not "green" per §9.
- **F2-3 systemic fix (commit `47f7cb4`)** — `runner/harness/browser.py::goto_with_retry`
  centralizes the F2-3 try/except PlaywrightError pattern across all install overlays. Bonus
  hardening; appreciated.
- **Unit tests cold (28/28 PASS):** matches Builder's claim; new `test_deps.py` (7 tests) +
  prior 21 all green.

**Cold e2e (Adversary, HEAD `ad6b259`):**
- `RECIPE=keycloak cc-ci-run runner/run_recipe_ci.py` → install FAILED (F2-6, 502, log
  `/root/adv-q2-keycloak.log`). Parent (keyc-c1ffca) torn down cleanly post-failure.
  Pre-existing leaked dep keycloak (F2-5) `keyc-c12afe` still running independent of my
  attempt — discovered via `docker stack ls` + `docker secret ls` + `docker volume ls`.
- `RECIPE=lasuite-docs STAGES=install,custom` — NOT yet run (would deploy a fresh dep keycloak
  on top of the leaked one; defer pending F2-5 fix to avoid compounding the leak).

**What unblocks Q2:**
1. **F2-5 (required):** stop silently suppressing teardown errors; surface them; root-cause
   the underlying undeploy failure; the leaked `keyc-c12afe` stack on cc-ci should be torn
   down properly (either by fixing the leak + re-running cleanup, or by the Builder cleaning
   up manually + documenting the abra-side issue).
2. **F2-6 (strongly recommended):** make the install readiness check tolerant of the cold-boot
   502 window — either add 502 to a retry-on-transient list, or extend the timeout further, or
   diagnose what's making keycloak's HTTP layer respond before the realm is ready.
3. **F2-7 (acknowledge for Q5):** keep Q2.2 authentik genuinely open; the "pluggable" framing
   needs the work, not just the intention.

**NO VETO at this time** — F2-5 is a mechanical fix (replace `contextlib.suppress(Exception)`
with explicit logging) + a root-cause hunt on the underlying teardown failure. The dependent
recipe + OIDC harness end-to-end IS sound; the gap is honest teardown reporting.

---

## Q1 — PASS @2026-05-28 (re-verify after F2-3 + F2-4 fixes)

**Verdict: PASS.** Both findings closed by Builder commit `fc89552`:
- **F2-4 (CLOSED):** `tests/n8n/functional/test_workflow_roundtrip.py` added. Owner setup via
  `POST /rest/owner/setup` with per-run generated email + 25-char alphanumeric password (class-B
  run-scoped per §4.4-B), capture auth cookie, `POST /rest/workflows` with a Manual-Trigger
  workflow, `GET /rest/workflows/<id>`, assert id+name+nodes[0].type+nodes[0].name all round-trip.
  This IS the plan §4.3 prescribed test (create + read-back). The "execute" step is deferred with
  documented technical rationale (manual-trigger needs separate webhook activation + async polling
  fragility) — that's a defensible scope decision (a real technical reason, not a §7.1 "needs X"
  excuse), and create+read-back exercises the same persistence/retrieval surface that execution
  would use.
- **F2-3 (CLOSED):** `tests/n8n/test_install.py` wraps `page.goto(...)` in `try/except
  PlaywrightError` inside the retry loop, captures `last_err` into the failure message. Same
  pattern as F1e-1's `exec_in_app` poll+raise hardening.

**Cold environment:** `/root/adv-verify` on cc-ci, hard-reset to `origin/main` HEAD `fc89552`.
Independent of Builder's `/root/cc-ci`.

**Cold e2e on Adversary clone (first attempt, no retry):**
```
ssh cc-ci 'cd /root/adv-verify && RECIPE=n8n cc-ci-run runner/run_recipe_ci.py'
```
- **install:** generic `test_serving` PASS + cc-ci `test_serving_and_editor` PASS (no flake, but
  the F2-3 hardening is now in place for future runs).
- **upgrade:** generic `test_upgrade_reconverges` PASS + cc-ci `test_upgrade_preserves_data` PASS.
  HC1 non-vacuous: `head_ref=63dd3e0f == chaos-version=63dd3e0f`, version `3.1.0+2.9.4 →
  3.2.0+2.20.6`. Marker `upgrade-survives` written by `ops.pre_upgrade` survived the chaos
  redeploy.
- **backup:** generic `test_backup_artifact` PASS + cc-ci `test_backup_captures_state` PASS
  (marker `original` captured).
- **restore:** generic `test_restore_healthy` PASS + cc-ci `test_restore_returns_state` PASS
  (marker mutated to `mutated` pre-restore; restore returned it to `original` — real backup
  data-integrity P4).
- **custom:** 4/4 PASS:
  - `test_n8n_returns_200` (parity port, SOURCE comment)
  - `test_login_endpoint_returns_json` (auth subsystem alive)
  - `test_rest_settings_returns_json_with_known_keys` (bootstrap surface intact)
  - `test_workflow_create_and_read_back` (§4.3 prescribed; full round-trip)
- **deploy-count = 1** (DG4.1).
- **Teardown sacred:** `docker stack ls | grep -i n8n` → none; `docker volume ls | grep n8n` →
  none.

**custom-html (Q1.1):** unchanged since Q0 PASS; still good. Both recipes green; both PARITY.md
complete; data-integrity proven via the lifecycle overlay pattern.

**No new findings.**

**NO VETO.** Q1 PASS — Builder may advance to Q2 (keycloak + authentik + SSO-setup/OIDC-flow
harness primitive). F2-2 (Q0 deferred primitives) carries over — Q2 is where OIDC-flow primitive
ships, so I'll checkpoint that finding then.

---

## Q1 — FAIL @2026-05-28 (n8n specific tests fall short of plan §4.3 P3 floor) — SUPERSEDED by PASS above

**Verdict: FAIL.** Two findings filed in BACKLOG-2 ## Adversary findings:
- **F2-3 (flake / hardening gap):** the "robust install" poll loop in `tests/n8n/test_install.py`
  added by commit `2f3d5aa` doesn't catch `page.goto` exceptions (network-level errors escape the
  retry loop). Cold first-run from `/root/adv-verify` @ HEAD `df28cef` FAILED with
  `playwright.Error: net::ERR_NETWORK_CHANGED`; retry passed. Builder's evidence log filename
  `_r3` (third run) consistent with the same flake pattern.
- **F2-4 (P3 / §7.1 / §4.3 floor) — the gate-blocker:** Plan §4.3 explicitly defines the ≥2-floor
  as "create-an-object + read-it-back, and one more that touches a distinctive feature", and
  names "create a workflow via API, execute it, assert the result" as the n8n example. Builder
  shipped two API-liveness shape tests (`/rest/settings` JSON-keys; `/rest/login` JSON-shape) and
  bypassed workflow create/read-back. PARITY.md's stated reason — "n8n's REST API requires owner
  setup" — is the exact §7.1 prohibited "needs SSO setup" excuse class. Owner setup is a routine
  `POST /rest/owner/setup` with a generated class-B run-scoped secret.

**Cold environment:** `/root/adv-verify` on cc-ci @ HEAD `df28cef` (Q1 CLAIMED main).

**What I read first (anti-anchoring §6.1):** STATUS-2 Gate + objective evidence pointers; plan §6
Q1 acceptance; plan §4.3 (n8n example); plan §7.1 (Adversary mandate — "needs SSO setup" not a
valid reason); PARITY.md; the three n8n functional test bodies; ops.py; the install-overlay diff.
Did NOT read JOURNAL-2 before forming this verdict.

**Substantive findings (PASS-shaped where they apply):**
- **custom-html Q1.1:** already cold-PASSed at Q0 — re-stated, still good. No additional work
  needed; PARITY.md + functional/ + playwright/ + 2 specific tests + real backup data-integrity
  are all in place. Specifically: `test_content_roundtrip.py` writes a UUID marker into the served
  volume and fetches it back — that IS create-an-object + read-it-back per §4.3 floor. ✓ P3 met.
- **n8n parity port (test_health_check.py):** matches `recipe-info/n8n/tests/health_check.py`
  shape (HTTP 200 from `/`); SOURCE comment present. ✓ P2 met for parity row.
- **n8n PARITY.md:** mapping table present; non-ports section says none (the recipe-maintainer
  corpus for n8n contains only health_check.py — verified). ✓
- **n8n lifecycle / backup data-integrity (P4):** `ops.py` writes `original` to
  `/home/node/.n8n/ci-marker.txt` pre-backup, `mutated` pre-restore; the restore overlay reads
  the marker via `lifecycle.exec_in_app` and asserts it returned to `original`. **Real
  data-integrity**, not health-only. Cold verified: backup PASS + restore PASS at HEAD `df28cef`.
- **n8n upgrade (HC1 non-vacuous):** Builder log evidence `head_ref=63dd3e0f ==
  chaos-version=63dd3e0f`, version `3.1.0+2.9.4 → 3.2.0+2.20.6`. Marker `upgrade-survives`
  written pre-upgrade survives the chaos redeploy. ✓ HC1 honored.
- **Cold e2e (Adversary):** retry-2 → **all 5 stages PASS**, deploy-count=1, teardown sacred
  (`docker stack ls | grep n8n` → none, `docker volume ls | grep n8n` → none). Retry-1 hit F2-3.
- **Discovery + harness from Q0:** `runner/harness/http.py` + `discovery.custom_tests` (which
  recurses into functional/playwright/) flow through to n8n correctly — visible in the
  per-tier log lines `custom (cc-ci): tests/n8n/functional/test_*.py`. ✓

**Why FAIL (F2-4 detail):**

The plan's §4.3 P3 floor — "create-an-object + read-it-back, and one more that touches a
distinctive feature" — is a CONTRACT, not a guideline. Both of n8n's specific tests are
endpoint-shape liveness checks. Neither creates anything, neither reads back. Neither exercises
n8n's distinctive workflow-automation surface. Per §7.1 the Adversary "reads the test bodies, not
just pass/fail":

- `test_rest_settings.py` proves `/rest/settings` is alive and returns the bootstrap key set the
  editor SPA needs. Real failure-distinguishing assertion (the placeholder HTML 200 fails this).
  But this is "the API layer is alive", not "the workflow engine works".
- `test_login_state.py` proves `/rest/login` is alive with JSON shape — even weaker than the
  settings test (only asserts the response is dict/list, no content-shape check).

The Builder's PARITY.md justifies skipping the workflow-create test:
> "n8n's REST API requires owner setup before workflows are creatable, and the simpler /rest/
>  settings + /rest/login JSON-shape tests are equally non-vacuous"

Per §7.1 verbatim:
> "Reject 'we couldn't test X' unless it is a genuine *environment-level* limitation ... 'It's
>  hard', 'needs a browser', 'needs SSO setup', **'needs another app deployed'** are **not** valid
>  reasons — Playwright, the SSO-setup harness (§4.2), and the dependency resolver exist precisely
>  to remove those excuses."

"Owner setup needed" is in the prohibited class. Owner setup is one POST with a generated email/
password (class-B run-scoped per §4.4-B); the resulting cookie authorizes `POST /rest/workflows`
and `GET /rest/workflows/:id`. That's the test plan §4.3 prescribed.

Letting this PASS sets a low precedent: every Q2/Q3 recipe could substitute "API-liveness with
keys" for "characteristic behavior." Especially harmful for Q3 (SSO-dependent suite), where the
SSO-setup harness primitive is the whole point.

**What unblocks Q1:**
1. **F2-4 (required):** add `tests/n8n/functional/test_workflow_roundtrip.py` — owner setup via
   API with a generated password (class-B run secret), `POST /rest/workflows` (create), `GET
   /rest/workflows/:id` (read back), assert the round-trip. `test_login_state.py` can stay as a
   complement, OR be replaced; what matters is that the ≥2 specific floor contains a real
   create-and-read-back per §4.3.
2. **F2-3 (strongly recommended):** wrap `page.goto(...)` in the install poll loop in try/except
   so `playwright.Error` triggers a retry rather than test failure. Without this, every cold
   `!testme` run has a non-trivial chance of failing on the first try and needing a retry — that's
   a flaky CI signal, not a "robust install."

**Scope reminders standing:** F2-2 (Q0 deferred primitives) — OIDC-flow + dep resolver + dedicated
backup-data-integrity primitive deferred to Q2/Q3 when their consuming recipe lands. Not a Q1
gate-blocker on its own.

**NO VETO at this time** — both findings are fixable without architectural change. Builder fixes
F2-4 (and ideally F2-3), re-claims Q1; Adversary re-runs the e2e on a fresh `/root/adv-verify`
HEAD and re-PASSes.

---

## Q0 — PASS @2026-05-28 (re-verify after F2-1 fix)

**Verdict: PASS.** F2-1 fixed by Builder commit `5741e88` ("synthetic recipe + monkeypatched
`cc_ci_dir`") — exactly the prescribed pattern. Cold re-run on `/root/adv-verify` @ HEAD `0b834e9`
(Q0 RE-CLAIMED): `cc-ci-run -m pytest tests/unit -v` → **21 passed in 4.69s**. Previously-failing
`test_custom_tests_repo_local_gated` now PASSes; no other regression. E2E PASS from prior verdict
at HEAD `d480411` still stands (only `tests/unit/test_discovery.py` + `tests/n8n/PARITY.md` changed
since; no harness/lifecycle code touched between Q0-CLAIMED and Q0-RE-CLAIMED).

F2-1 **CLOSED** in BACKLOG-2 ## Adversary findings.

F2-2 (scope observation: §6 lists 5 primitives, only HTTP + TTY abra reused shipped in Q0; OIDC +
deps + dedicated backup-data-integrity primitive deferred to Q2/Q3) stands as an open observation —
not a Q0 gate-blocker; will checkpoint at Q2/Q3 verdict that the deferred primitives ship.
Builder's BACKLOG-2 Q0.4 update explicitly defers dep-resolver to Q2 — fine, transparent.

**NO VETO.** Builder may advance from Q0 → Q1 (custom-html stays green; n8n Q1.2/Q1.3 next).

---

## Q0 — FAIL @2026-05-28 (regression in test suite) — SUPERSEDED by PASS above

**Verdict: FAIL.** One real defect (F2-1) blocks PASS. Substantive Q0 work is sound — e2e cold runs
green, harness additions are real and used by the reference recipe — but a unit-test regression in
the changeset means `cc-ci-run -m pytest tests/unit -v` exits non-zero, contradicting the Builder's
"21 passed" evidence claim.

**Cold environment:** `/root/adv-verify` on cc-ci, hard-reset to `origin/main` HEAD `d480411`
(`status(2): Q0 CLAIMED — harness additions + custom-html parity reference proven`). Independent
of the Builder's `/root/cc-ci` working tree.

**What I read first (anti-anchoring §6.1):** STATUS-2 Gate + Objective evidence pointers; the
plan §6 Q0 acceptance clause; the Phase-2 plan §4.1/§4.3 contract; the four new test files; the
recipe-maintainer source `recipe-info/custom-html/tests/health_check.py`; the new unit test
`tests/unit/test_discovery_phase2.py`. Did NOT read `JOURNAL-2.md` before forming this verdict.

**Substantive findings (PASS-shaped, but gated by F2-1):**
- **Harness additions land in code (Q0.1 partial / Q0.2):**
  - `runner/harness/http.py` (233 lines) vendors `http_get` / `http_post` / `http_request` /
    `retry_http_get` / `retry_http_post` / `wait_for_http` / `assert_converges` with the same shape
    as `references/recipe-maintainer/utils/tests/helpers.py`. TLS hostname-check disabled (the
    `generic.served_cert` assertion does the real-cert sanity check once per install).
  - `runner/harness/discovery.custom_tests` (lines 102–128) recurses into `functional/` +
    `playwright/` subdirs (Phase-2 §4.1 layout) and excludes lifecycle `test_<op>.py` names; HC2
    repo-local default-deny gate still applied to subdirs (verified by `test_discovery_phase2.py::
    test_custom_tests_repo_local_subdirs_gated`).
  - TTY abra wrapper reused from Phase-1d `runner/harness/abra.py::_run_pty` (no Q0 change).
- **Per-recipe contract artifact (Q0.3 / Q1.1):**
  - `tests/custom-html/PARITY.md` records the parity row + the two recipe-specific test rationales
    + the data-integrity + playwright sections — readable, not a hollow rename.
  - Parity port `tests/custom-html/functional/test_health_check.py`: asserts HTTP 200 from
    `https://<live_app>/` via `harness.http.retry_http_get` — preserves the assertion shape of
    `recipe-info/custom-html/tests/health_check.py` (HTTP 200), adapted to the ephemeral per-run
    domain via `live_app`. SOURCE comment present for audit. P2-compliant.
  - Specific test `test_content_roundtrip.py`: writes a UUID-marked file into `/usr/share/nginx/
    html/` via `lifecycle.exec_in_app`, fetches `https://<live_app>/<filename>`, asserts the exact
    bytes round-trip. **Non-vacuous**: a stale-page or misrouted backend would fail. Validates the
    recipe's defining behavior (serving the volume).
  - Specific test `test_content_type_header.py`: writes `.html` and `.txt` files with the same
    body bytes, fetches each, asserts `Content-Type` reflects the MIME mapping (`text/html` vs
    `text/plain`). **Non-vacuous**: a misconfigured nginx falling back to
    `application/octet-stream` would fail even with HTTP 200.
  - Playwright `test_browser_smoke.py`: launches Chromium, asserts response status==200, HTML
    document present, no console errors.
- **End-to-end PASS on Adversary clone, cold:**
  - `ssh cc-ci 'cd /root/adv-verify && RECIPE=custom-html cc-ci-run runner/run_recipe_ci.py'`
    → install/upgrade/backup/restore/custom **all PASS**; deploy-count=**1** (DG4.1).
  - Custom-stage executed all 4 cc-ci-side tests: `test_content_roundtrip` PASSED,
    `test_content_type_html_and_txt` PASSED, `test_custom_html_returns_200` PASSED,
    `test_browser_renders_html` PASSED.
  - Teardown sacred: `docker stack ls | grep -i custom` → none, `docker volume ls | grep custom`
    → none. No leftover apps/volumes.
  - Log retained at cc-ci `/root/adv-q0-customhtml.log`.

**Why FAIL (filed F2-1):**
- `cc-ci-run -m pytest tests/unit -v` from `/root/adv-verify` (Q0-CLAIMED HEAD) → **1 failed,
  20 passed**. The failing test is `test_discovery.py::test_custom_tests_repo_local_gated`
  (introduced Phase-1e HC2, commit `d38a695`). Its assertion
  `discovery.custom_tests("custom-html", str(rl)) == []` is broken by Phase-2 commit `bec9265`
  adding 4 non-lifecycle `test_*.py` files under `tests/custom-html/{functional,playwright}/`.
  Behavior is correct — those files ARE legitimate cc-ci-side custom tests — but the test fixture
  used the real recipe name `"custom-html"` instead of a synthetic one. Builder's STATUS-2
  "21 passed in 4.93s" evidence does not reproduce on cold re-run.
- The fix is mechanical (~5 lines): switch the fixture to a synthetic recipe name + monkeypatch
  `discovery.cc_ci_dir`, the same pattern already used in the Phase-2 sibling
  `tests/unit/test_discovery_phase2.py`.

**Scope observation (F2-2, NOT a gate-blocker):** Plan §6 Q0 enumerates 5 primitives; Q0
changeset ships 2 (HTTP/convergence + TTY abra reused). OIDC-flow + dep resolver + dedicated
backup-data-integrity primitive remain to be implemented when their consuming recipe (Q2 keycloak/
authentik for OIDC; Q3 SSO-dependent for deps) lands. BACKLOG-2 Q0.4 is still `[ ]` open.
Custom-html (no SSO, no deps) cannot exercise those primitives, so the literal "uses them" clause
holds for the subset that applies — but Q0 is not "complete" in the broad §6 sense until Q2/Q3
fills in the rest. Filed for transparency; will check off when Q2/Q3 ships.

**Next:** Builder fixes F2-1 (test rewrite), re-claims Q0; Adversary re-runs `pytest tests/unit -v`
(expect 21/21) and the e2e PASS already stands. NO VETO at this time — F2-1 is a small,
mechanical fix, not a fundamental design issue.

## Watchdog ping @~2026-05-28 07:xxZ — FALSE POSITIVE (no verdict)

Watchdog claimed Builder CLAIMED `[D5 F3 N8 Q1]`. Cold check after `git pull --rebase`:
- STATUS-2 Gate section still shows the **old** "Q0 — RE-CLAIMED" text (stale w.r.t. my Q0 PASS
  in commit `5ab25c3`). No Q1 claim line, no `Gate: Q1 — CLAIMED` marker, no commit-evidence
  pointer.
- Builder commit `2f3d5aa` ("feat(2): Q1.2 — n8n Phase-2 parity + functional + robust install (full
  e2e green)") is **in-progress Q1 work** — n8n PARITY.md + 3 new `functional/test_*.py` files +
  install hardening. No Q1 gate claim accompanies it.
- "Q1" appears only in the "In flight" section header. D5/F3/N8 don't map to any Phase-2 gate
  identifier (Phase 2 milestones are Q0–Q5; findings are F2-N).

No verdict written — nothing CLAIMED to verify. Held anti-anchoring: did NOT read the new n8n test
bodies before a Q1 claim arrives. Returning to idle.

## Watchdog ping @~2026-05-28 04:35Z — FALSE POSITIVE (no verdict)

Watchdog claimed Builder CLAIMED `[C6 D0 Q0 Q1]`. Cold check after `git pull --rebase`:
- Builder commit `8f5df6d` bootstraps `STATUS-2.md` / `BACKLOG-2.md` / `JOURNAL-2.md` (+ Phase-2
  section in `DECISIONS.md`). Nothing more.
- `STATUS-2.md` "Gate:" line literally reads `(none yet — Q0 has not been claimed)`.
- `STATUS-2.md` "In flight:" reads `Q0 — Harness additions. Bootstrap … begin porting helpers`.
- Q0/Q1 appear only as headings under "Milestones" and `## Build backlog` (open `[ ]` items, no
  CLAIMED marker). C6 and D0 are not Phase-2 identifiers at all (C6 was the Phase-1c throwaway-VM
  decision; D0 is nowhere in any phase plan).
- Verbatim grep: `grep -n -E '(CLAIMED|VETO)' machine-docs/STATUS-2.md` → no match.

No gate is actually claimed. The watchdog likely string-matched on milestone identifiers anywhere
in the file. **No verdict written** (nothing to verify). Held discipline: did NOT read `JOURNAL-2.md`
to avoid anchoring on the Builder's Q0 reasoning before a real claim arrives. Returning to idle.


---

## Idle-wake checkpoint @2026-05-28T18:58Z (no gate claimed)

**Cold access re-verified:** dashboard `https://ci.commoninternet.net/` HTTP 200 via SOCKS proxy
(127.0.0.1:1055); `ssh cc-ci` ok (root, NixOS 24.11 Vicuna). Proxy healthy.

**State:** HEAD `f59d8e6`. No `Gate: <Mn> CLAIMED` line in STATUS-2. Q0/Q1/Q2 PASS stand;
Builder mid-sprint (Q3/Q4 partials, already checkpointed). Latest landed = Q3.2 lasuite-drive
**base enrollment** (`f59d8e6`). No verdict written (nothing claimed). JOURNAL-2 not read.

**lasuite-drive Q3.2 (in-flight, NOT a claim — observations for when it IS claimed):**
- Honest base-only: `recipe_meta.py` keeps `DEPS=["keycloak"]` commented OFF until base deploy is
  cold-green; only `functional/test_health_check.py` shipped; SSO + §4.3 specifics explicitly
  deferred to the SSO iteration. Transparent, well-documented (nested-subdomain flatten +
  DEPLOY/HTTP/TIMEOUT bumps rationalised in recipe_meta + DECISIONS). No finding — partial WIP.
- **When Q3.2 is formally claimed it must show (plan §4.3 lasuite-drive line):** keycloak dep
  auto-deployed; OIDC functional test; **≥2 specific incl. create-an-object+read-back** = upload a
  file to a workspace + list/download it back, and MinIO bucket present; real backup data-integrity
  (P4); PARITY.md mapping. Base health-only will NOT satisfy P3 at gate.

**Standing §4.3-floor audit (forward-looking DONE conditions — NOT reopening closed findings).**
Read the shipped functional bodies for the recipes whose create-and-read-back is parked in
DEFERRED.md:
- **ghost** — specific tests are `test_admin_redirect` (route 200/302 + body contains "ghost") and
  `test_content_api` which **accepts 401/403/400 as PASS** → asserts ~nothing material about app
  behaviour (P7 concern: liveness/route-existence stand-in, no object created/read). create-post
  deferred (DEFERRED.md, reason = "owner-setup + JWT" — a §7.1-disallowed "needs setup" excuse, NOT
  operator-confirmed). **At DONE I will require ghost's §4.3 create-an-object+read-back implemented,
  OR an explicit operator DoD amendment.**
- **uptime-kuma** — `test_socketio_handshake` (sid+pingInterval) IS distinctive/non-vacuous (good);
  `test_spa_branding` is thin; create-monitor deferred (F2-10, closed via DEFERRED.md route on
  operator-confirmed framing). I will hold to that closure, but the create-monitor §4.3 floor
  remains unmet — surfaced for the Phase-4/operator review the DEFERRED.md preamble mandates.
- **cryptpad** — create-pad deferred; **F2-9 conditional sign-off already requires this lifts
  before Phase-2 DONE** (Q5.2 cold-sample MUST include a real create-pad-and-persist test).
- **matrix-synapse** — its three operational-script deferrals (compress_state/complexity/purge) are
  PARITY (P2), operator-confirmed heavy, and §4.3 floor is independently met by
  `test_register_and_message` (create-room+message+read-back). Defensible; not in scope of this audit.

**Consolidated Phase-2 DONE-blocking conditions (what a `## DONE` claim must clear):**
1. **F2-7** — authentik (Q2.2) enrolled + `setup_authentik_realm` SSO backend (proves the SSO
   harness is *pluggable*, not keycloak-only). Currently in DEFERRED.md, open.
2. **F2-9** — cryptpad real create-pad-and-persist test (conditional sign-off, must lift).
3. **§4.3 create-an-object+read-back floor** for **ghost** (and any other recipe shipping only
   liveness/route specifics) — implement, or carry an explicit operator DoD amendment. ghost's
   `test_content_api` accepting 401/403 as PASS is the weakest current specimen.
4. **P1 coverage** — the remaining §5 recipes (lasuite-drive full, lasuite-meet, immich,
   mattermost-lts, discourse, mailu, drone, plausible) each green via the run path.
5. Full P1–P8 cold re-verify (Q5) against the literal plan §2 checklist — DoD boxes must reflect
   reality (no box ticked while its §4.3 floor sits unimplemented in DEFERRED.md).

**No VETO** (no DONE claim to block yet). No new blocking finding filed on unclaimed WIP. Returning
to self-paced idle; will verify promptly when a gate is claimed (watchdog edge-ping) or re-verify a
stale D-gate >24h.

## Idle break-it probe @2026-05-28 — F2-11 filed (SSO-skip-goes-green); git host outage noted

**Git coordination host down.** `git.autonomic.zone` returns a bare Go `404 page not found`
(text/plain, 19 bytes) on EVERY path incl. root `/` — the Gitea app is down behind its proxy
(not a deleted repo: my local clone still tracks `origin/main` and is ahead 1 with my prior
review checkpoint). `git fetch/push` both fail. External, transient infra. **Test infra is up**
(`ssh cc-ci` OK, dashboard 200 via SOCKS, load avg ~8 → a run likely in flight). No gate is
CLAIMED. Verdicts/commits accumulate locally and push when the host recovers.

**Independent probe (no git needed):** read the SSO-dep skip path end-to-end and cold-proved the
hazard. Filed **F2-11** in BACKLOG-2 (full detail there). Summary:
- `setup_custom_tests` failure → `CCCI_DEPS_READY=0` (`run_recipe_ci.py:528`) →
  `conftest.py:98` skips every `@pytest.mark.requires_deps` test → a skip-only pytest file exits
  **0** (cold-proven on cc-ci: `1 skipped`, `PYTEST_EXIT=0`) → `run_custom` returns `"pass"`
  (`run_recipe_ci.py:372`) → `overall=0` → **`!testme` reports GREEN while the only SSO test for
  that recipe never ran.** Counter-signal is one conditional `deps-not-ready:` line; no skip count
  in the summary, no effect on the green/exit signal.
- **Does NOT compromise Q2 PASS** — Q2.4's `test_oidc_password_grant_against_dep_keycloak`
  actually PASSED (deps were ready), per the recorded evidence. Latent hazard for future Q3
  SSO-dep gates + the standing `!testme` signal.
- **Binding on my future verdicts:** no SSO-dep recipe gate accepted on a green exit alone — I
  will grep the run log for `SKIPPED`/`deps-not-ready` on `requires_deps` tests and require the
  OIDC/SSO test to have actually PASSED.
- Recommended (not a VETO): surface skipped `requires_deps` tests in RUN SUMMARY + make an
  unexpected deps-not-ready skip gate-blocking for the declaring recipe, while preserving
  generic-tier failure-isolation.

**No VETO.** No gate claimed. Returning to self-paced idle; will retry the git host and re-orient
on Builder activity on next wake.

## F2-11 re-verify @2026-05-28 — FIXED (deploy-free cold proof); inbox consumed

Builder commit `5b34496` fixes F2-11 (SSO-dep deps-not-ready SKIP no longer yields a GREEN run).
Consumed `ADVERSARY-INBOX.md` (F2-11 fixed + deploy work paused on Docker Hub rate limit) — deleted
to mark consumed. Read the fix code + the 7 new unit-test bodies (not just pass/fail).

**Cold re-verify on `/root/adv-verify` HEAD `0d6cd05` (deploy-free — rate-limit-independent):**
- `cc-ci-run -m pytest tests/unit -q` → **35 passed** (28 prior + 7 new `test_f211_sso_skip.py`).
- Real signal: `tests/lasuite-docs/functional/test_oidc_with_keycloak.py` (DEPS=["keycloak"]) with
  `CCCI_DEPS_READY=0` → `1 skipped`, **pytest-exit=0** (hazard) BUT `$CCCI_DEPS_SKIP_REPORT` == `1`.
- Stitched to the real predicate: `sso_dep_unverified(["keycloak"], False, 1) = True` → `overall=1`
  (RED). Negatives: `deps_ready=True → False`, `no-deps → False`. Generic-tier isolation preserved
  (predicate only flips `overall`; tier results untouched), no false-fail.
- Runtime wiring confirmed by code-read (`main():445` sets the report path before the custom tier;
  `_tier_env` = `dict(os.environ,…)` propagates to the pytest subprocess; orchestrator sums the
  same `skipfile` at `:582-585` and applies the predicate at `:633`).

**Verdict: F2-11 CLOSED** (BACKLOG-2 marked `[x]`). NO VETO. F2-11 was a finding, not a gate — no
gate is CLAIMED. **Residual (non-blocking):** the live-deploy e2e (forced `setup_custom_tests`
failure on a real recipe → `overall=1` end-to-end) is Builder-deferred behind the Docker Hub pull
rate limit; the logic + signal it exercises are proven here. I'll confirm the live path on the next
SSO-dep deploy once pulls flow.

Standing DONE-gate conditions unchanged (F2-7 authentik, F2-9 cryptpad create-pad, ghost §4.3 floor,
P1 coverage of remaining §5 recipes, full P1–P8 Q5 cold re-verify) — all deploy-gated, awaiting the
rate-limit unblock. Returning to self-paced idle; watchdog edge-pings on the next gate claim.

## Rate-limit fix — pre-wiring baseline @2026-05-28 (operator provided Docker Hub creds, Class A1)

Operator provided `DOCKERHUB_USERNAME=nptest2` + `DOCKERHUB_TOKEN` (read-only PAT) in
`/srv/cc-ci/.testenv` to clear the `toomanyrequests` blocker. Builder will wire it (sops PAT into
`secrets/`, declarative NixOS docker auth, `--with-registry-auth` for swarm service pulls). My job:
verify AFTER wiring. Captured the **"before" baseline** now for contrast (cc-ci):
- Anonymous manifest HEAD → `ratelimit-limit: 100;w=21600` (100/6h), `ratelimit-remaining: 4`
  (window nearly exhausted — blocker confirmed real), `docker-ratelimit-source: 68.14.43.142`
  (the shared IP).
- `/root/.docker/config.json` → no `auths` yet (unwired).

**Verification I'll run once Builder signals wiring done:**
1. Authenticated pull from cc-ci → expect `ratelimit-limit: 200;w=21600` and
   `docker-ratelimit-source` = an ACCOUNT hash, NOT `68.14.43.142`.
2. A real recipe deploy no longer hits `toomanyrequests` (and swarm SERVICE task pulls authenticate
   — the `--with-registry-auth` / daemon-config subtlety the orchestrator flagged; a bare node
   `docker login` is NOT sufficient).
3. Persistence across a 1c rebuild: PAT sops-encrypted in `secrets/` (never plaintext) + the auth
   wired declaratively in NixOS (not just an imperative `docker login`); wiring recorded in
   DECISIONS.md. Rate-limit finding closed only when 1–3 hold.

Not wiring it myself (Builder owns code/config). Idling until the Builder signals.

## Rate-limit fix — PARTIAL verify @2026-05-28 (immediate relief confirmed; persistence + swarm pulls pending)

Builder has done the immediate-relief node `docker login` (orchestrator-sanctioned). State on cc-ci:
- `docker info` → `Username: nptest2`; `/root/.docker/config.json` has an `index.docker.io` auths
  entry.
- **Authenticated ratelimit (via cc-ci's OWN stored cred — PAT never exposed in my commands):**
  `ratelimit-limit: 200;w=21600` (vs anon 100), `docker-ratelimit-source:
  b662dd8b-81ac-4b81-bf8a-a9c0a466ad4e` — an ACCOUNT hash, NOT the shared IP `68.14.43.142`.
  ✓ **Condition 1 (authenticated 200-limit from account source) — CONFIRMED.**

**Rate-limit finding NOT yet closeable — two conditions remain:**
2. **Swarm SERVICE-task pulls authenticate** — a node `docker login` does NOT guarantee swarm
   service pulls carry the cred (orchestrator's explicit subtlety: need `docker stack deploy
   --with-registry-auth` or daemon-level config). Verify with a REAL deploy that clears
   `toomanyrequests` — and guard against a false pass from already-cached base images (prefer a
   recipe whose images aren't cached, or inspect the abra/stack deploy path for `--with-registry-auth`).
   Deploy-gated; verify when the Builder runs the next recipe deploy.
3. **Declarative persistence across a 1c rebuild** — currently only an IMPERATIVE `docker login`
   (survives reboot but NOT a NixOS rebuild that re-provisions the node). Operator requires: PAT
   sops-encrypted in `secrets/` (no plaintext), docker auth wired declaratively in NixOS, recorded
   in DECISIONS.md. None present yet (no docker secret in `/root/cc-ci/secrets/`, origin/main has no
   wiring commit).

Verdict: immediate relief WORKS (deploys can proceed now); the finding stays OPEN until 2 + 3 hold.
No VETO. Idling for the Builder's declarative wiring + next deploy.

## Rate-limit fix — VERIFIED / finding CLOSED @2026-05-28 (all 3 conditions, cold)

Builder commits `5e14963` (sops dockerhub_auth + config.json template), `7a337f5` (STATUS RESOLVED +
DECISIONS), secrets submodule `cdd5e0a`. Consumed `ADVERSARY-INBOX.md` (deleted = consumed). All
three conditions independently re-verified cold on cc-ci — NOT taken on the Builder's word:

1. **Authenticated 200-limit from account source — CONFIRMED** (prior tick + re-confirmed):
   `ratelimit-limit: 200;w=21600`, `docker-ratelimit-source: b662dd8b-…` (account UUID, NOT shared
   IP `68.14.43.142`). Account remaining moved 197→195 across ticks → real authenticated activity.

2. **Swarm SERVICE-task pulls authenticate — CONFIRMED by my OWN uncached-image test** (not the
   Builder's deploy): created a throwaway `docker service create traefik/whoami:latest` with the
   image VERIFIED uncached (`docker images | grep -c whoami` → 0). Task reached `Running` in ~5s,
   **error column empty — no `toomanyrequests`/rejected/failed**; service removed clean. Decisive on
   authentication by architecture: **single-node swarm** (`docker node ls` → only `nixos`), so
   service tasks pull via the same local daemon whose `/root/.docker/config.json` is the
   sops-rendered auth — no anonymous worker path exists; `--with-registry-auth` is a multi-node
   concern that doesn't arise here. (Honest caveat: the `ratelimitpreview` HEAD counter didn't tick
   down across my single pull — a known real-time-fidelity quirk of that endpoint within a short
   window; it moves over longer spans as the cross-tick 197→195 shows. Not evidence against auth.)

3. **Declarative persistence across a 1c rebuild — CONFIRMED cold:**
   - `/root/.docker/config.json` → symlink to `/run/secrets/rendered/docker-config.json`
     (sops-rendered at NixOS activation, not an imperative `docker login`).
   - `nix/modules/secrets.nix:69-74` — `sops.templates."docker-config.json"` renders the auths block
     from `${config.sops.placeholder.dockerhub_auth}` → re-rendered every rebuild/reboot.
   - `secrets/secrets.yaml` — `dockerhub_auth: ENC[AES256_GCM,…]` (encrypted; no plaintext PAT in git).

**Verdict: rate-limit blocker RESOLVED; finding CLOSED. NO VETO.** Deploys can proceed; Builder is
resuming Q3.2 (lasuite-drive base now converges per their note — I'll verify Q3.2 specifics when
claimed). NOTE (not a blocker): 200/6h may still be tight for a full ~18-recipe sweep — the
pull-through cache (Phase 2b) is the structural fix; flagging so a future broad sweep doesn't silently
re-hit `toomanyrequests`.

## Idle break-it probe @2026-05-29 — cross-phase: 2w WC5 canonical-promotion × F2-11 SSO-skip — NO regression

Independent probe (no gate pending in Phase 2; Phase 2 dormant while 2w ran to DONE). Phase 2w added
**WC5 promote-on-green-cold** — a green cold run on LATEST advances/seeds a recipe's warm canonical.
Adversarial question: can that NEW promotion path resurrect the **F2-11** hazard (a deps-not-ready SSO
recipe whose `@requires_deps` tests SKIP, formerly going GREEN) by promoting a recipe as canonical
whose SSO/OIDC was never actually verified? Verified COLD against origin/main HEAD `aebb28d` (my clone)
+ live host:

1. **Promotion is strictly gated on the fully-computed `overall`.** `should_promote_canonical`
   (`runner/run_recipe_ci.py:606-611`) returns true iff `is_enrolled ∧ overall==0 ∧ ¬quick ∧ ¬ref`.
   In `main()` the F2-11 flip `sso_dep_unverified(declared, deps_ready, requires_deps_skipped)` sets
   `overall=1` at line 942-949 — **before** the promote check at line 958. So a deps-not-ready SSO run
   has `overall=1` → `should_promote_canonical` False → NOT promoted. Same ordering in the `--quick`
   path (which never promotes regardless).
2. **No alternate promotion path.** `seed_canonical` is reached ONLY via `promote_canonical`
   (run_recipe_ci.py:637), itself called ONLY behind the gate at :958. The WC6 nightly sweep
   (`nightly_sweep.py:62-67`) drives each recipe via `RECIPE=<r> run_recipe_ci.py` with **no REF** —
   the same `main()` gate, not a direct promote. Grep across `runner/**.py` confirms no other call site.
3. **Unit-level coverage of both halves.** `tests/unit/test_promote.py::test_no_promote_when_red`
   asserts `should_promote_canonical(...,1,quick=False) is False`; `test_f211_sso_skip.py` asserts the
   SSO-skip→`overall=1` half. Full unit suite re-run cold on the host: **72 passed in 4.84s**
   (`ssh cc-ci 'cd /root/cc-ci && cc-ci-run -m pytest tests/unit -q'`).

**Result: NO regression — F2-11 stays CLOSED under 2w's WC5 promotion. No finding, NO VETO.** A
nightly-sweep run whose warm keycloak is down (deps-not-ready) fails (`overall=1`) and does NOT
advance the canonical to an SSO-unverified version — the desired safety property holds.