note(rcust): interim pre-review of frozen P5 (68954be) — cold unit 191 + lint PASS reproduced; manifest exposes NO generated/real secrets (HC2-honoring, pure presentation); one non-blocking heads-up re plausible SECRET_KEY_BASE public-dummy on dashboard (NOT an M1 verdict)

REVIEW-rcust.md

@@ -143,3 +143,54 @@ Net: P1+P2+P3+P4 all clean under cold adversarial probing; both halves of every
 final coverage re-diff on the COMPLETE branch (P1–P6, all 21 recipes, effective customization set
 unchanged); recipe-test diffs mechanical-only across the whole branch; HC2/F2-11/generic-floor
 integrity at the final head. These wait for `claim(rcust): M1`.
+
+### Interim pre-review of frozen P5 (branch @ 68954be) — @2026-06-10T19:06Z, cold from fresh host clone
+
+Builder landed P5 (customization manifest) and moved to P6, so P5 is frozen. Pre-reviewed it cold.
+**No blocking defect; one secret-SURFACE observation raised (heads-up to Builder, NOT a VETO, NOT
+an M1 secret-leak failure).** NOT an M1 verdict.
+
+Cold acceptance (fresh `git clone` on cc-ci host at 68954be, my own checkout):
+- `cc-ci-run -m pytest tests/unit -q` → **191 passed** (exact match to claim).
+- `nix develop .#lint --command scripts/lint.sh` → **lint: PASS**.
+
+Primary adversarial target — SECRET LEAKAGE via the new manifest surface (D-gate: published logs +
+dashboard contain NO secrets, incl. generated app passwords):
+1. **Generated/runtime secrets — NOT exposed (gate holds).** `manifest.build` collects only:
+   `meta_non_default` (static recipe_meta), hook NAMES (pre-ops/install_steps.sh/compose.ccci.yml),
+   overlay FILENAMES, custom-test COUNTS, and env-override KEY names (printed `KEY=1`, value never
+   rendered). It never touches `deps` (client_secret), `op_state`, abra-generated app passwords, or
+   any env VALUE. The cardinal concern — generated app passwords on the dashboard — is structurally
+   absent from this surface.
+2. **Cold all-recipes sweep.** Built+rendered the manifest for all 21 recipes on the host; grepped
+   the rendered blocks AND the results.json `customization` payload for secret/password/token/key/
+   credential and for any 32+ char high-entropy string. The ONLY hit, across every recipe, is
+   plausible's `EXTRA_ENV.SECRET_KEY_BASE` =
+   `"ccciplausibletestkeybase64charsexactlyforCIephemeral4567890123"`.
+3. **OBSERVATION (not a leak):** that value is a HARDCODED, committed, PUBLIC dummy CI constant
+   (tests/plausible/recipe_meta.py, in the open-source repo) — not a generated or real secret.
+   `meta_non_default` dumps EXTRA_ENV literal dicts verbatim into the log AND results.json (→
+   dashboard), so a field literally named `SECRET_KEY_BASE` with a value now appears on the
+   dashboard. No real secret is exposed (it's public), so this is NOT a D-gate failure and does NOT
+   block P5. BUT it's a standing surface: (a) a dashboard secret-scan gets a true-positive-shaped
+   hit on a public dummy (noise that could mask a real leak), and (b) if any recipe ever set a real
+   secret-ish literal in a meta dict, the manifest would surface it unredacted. Flagged to Builder
+   via BUILDER-INBOX as a heads-up to consider redacting values of sensitive-named meta keys before
+   M1. Will re-examine on the real dashboard at the M1 cold-verify.
+4. **HC2-honoring — confirmed.** Manifest routes ALL repo-local reads through `discovery._gated`
+   (ops.py loop direct; `install_steps`/`resolve_overlay_op`/`custom_tests` each call `_gated`
+   internally). An unapproved repo-local recipe contributes nothing to the manifest.
+5. **Pure presentation — holds.** `build()` only reads files/env and returns a dict; `render()`
+   formats a string. Called at run_recipe_ci.py:889-890 (print) + embedded at :1261 into results;
+   no state mutation, no verdict influence. `_jsonable` renders callables as `'<hook>'` (so a
+   callable EXTRA_ENV/READY_PROBE never leaks closure internals) and tuples→lists for JSON.
+
+Net: P1–P5 all clean under cold adversarial probing; every phase claim (unit count + lint)
+reproduced cold. No findings filed; no VETO. One non-blocking secret-surface heads-up sent.
+
+**Still UNVERIFIED for M1:** P6 (docs); `pytest tests/concurrency -q` cold; R2 end-to-end via the
+real orchestrator screenshot path; final coverage re-diff on the COMPLETE branch (all 21 recipes,
+effective customization unchanged); recipe-test diffs mechanical-only across the whole branch;
+HC2/F2-11/generic-floor integrity at final head; AND — at the M1 dashboard check — confirm the
+SECRET_KEY_BASE-named field on the real dashboard is the accepted public dummy (or redacted).
+These wait for `claim(rcust): M1`.

machine-docs/BUILDER-INBOX.md

@@ -0,0 +1,20 @@
+
+## [adversary heads-up @2026-06-10T19:06Z] P5 manifest — sensitive-named meta values on dashboard (non-blocking)
+
+NOT a gate FAIL, NOT a VETO — P5 is clean and I logged a PASS-equivalent pre-review. Heads-up for
+your consideration before M1:
+
+`manifest.build` dumps `meta_non_default` dict VALUES verbatim into the run log AND results.json
+(→ dashboard). Across all 21 recipes the only secret-shaped value is plausible's
+`EXTRA_ENV.SECRET_KEY_BASE` = "ccciplausibletestkeybase64charsexactlyforCIephemeral4567890123".
+That's a committed PUBLIC dummy CI constant, so no real secret leaks — fine today.
+
+But the dashboard now shows a field literally named `SECRET_KEY_BASE` with a value. Consider, at
+your discretion:
+  - redacting values of meta keys whose name matches a sensitive pattern
+    (SECRET|PASSWORD|TOKEN|KEY|CREDENTIAL) in the manifest (render the key, mask the value), OR
+  - documenting in the manifest/docs that meta values are repo-public-by-construction so a
+    secret-scan hit on the dashboard is expected noise for that one field.
+
+Either is acceptable to me. I'll re-check the real dashboard for this at the M1 cold-verify. No
+action required to keep P5 green.