A5-2: bridge.py now posts Gitea commit statuses on the recipe PR's head SHA:
- pending on build trigger (so testme-on-pr.sh sees the run immediately)
- success/failure on build finish (so testme-on-pr.sh returns VERDICT=GREEN/RED)
Added post_commit_status() using the existing _api() helper + GITEA_TOKEN.
Called from process_testme() (pending) and watch_and_reflect() (terminal state).
A5-1: added recipe-maintainers/custom-html-tiny to bridge POLL_REPOS in
bridge.nix so !testme on custom-html-tiny PRs is picked up by the bridge poller.
Break-it probes (V1):
- !testmexyz on custom-html PR#2 (watched repo): correctly ignored — no Drone trigger ✓
- Non-collaborator auth: GET /orgs/recipe-maintainers/members/nonexistent-user-999 → 404 ✓
- bridge source: parse_body("!testmexyz") → (False, False) ✓
CRITICAL finding A5-2 (blocks V2–V8): testme-on-pr.sh reads Gitea commit statuses on the recipe
PR head SHA, but the bridge NEVER posts commit statuses — only PR comments. Drone posts statuses
on cc-ci repo only. POST=0 testme-on-pr.sh custom-html 2 → VERDICT=PENDING always. Fix: bridge
must POST /repos/{owner}/{recipe}/statuses/{sha} on build start/finish.
Finding A5-1: custom-html-tiny not in bridge POLL_REPOS — testme on tiny PRs would silently do
nothing. Must enroll it or use custom-html as sandbox instead.
BUILDER-INBOX.md: heads-up to Builder with both findings.
(1) Prior U2 R7 'empirical' line used a wrong-signature call to render_card_png/
render_badge_svg, so its TypeError was my test's bug not an R7 violation. Re-ran
correctly: render_card_png(nonexistent html_path) -> None, no raise, 'non-fatal'.
R7 holds (empirical + structural). U2 verdict UNCHANGED, still PASS.
(2) Eyeballed the real served u1-uk-shot summary.png — content matches results.json.
(3) Filed A3-1 [adversary] (HEAD->501 on /runs/, low-sev); Builder added do_HEAD in
9a47aa2 — Adversary to re-test live before closing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cold/independent against the REAL published run u1-uk-shot (+ deterministic fail render):
- 8 card unit tests pass on cc-ci-run.
- Live serving: summary.png 200 image/png 1280x800 69313B, screenshot.png 200, badge.svg
200, results.json 200 — all at /runs/u1-uk-shot/.
- CARDINAL no-inflation: render_card_png screenshots render_card_html verbatim; card text ==
results.json exactly (LEVEL 1 / capped L2 upgrade N/A / install checkmark / flags). Badge
'level 1' orange. Fail render: LEVEL 0 / install FAILED / cross; badge 'install failed' red.
Pass AND fail both render correctly; never greener than data.
- Traversal/whitelist guard: encoded ../etc/passwd, evil.sh, nonexist run, runid-traversal
all 404 (9B dashboard not-found = guard fires).
- Secret scan over all served artifacts: 0 real hits.
- R7 proven: forced card-unwritable/corrupt -> None, badge-garbage -> valid, no raise;
render runs after write_results, inside outer try/except, overall pre-computed.
HONESTY: a prior uncommitted draft referenced fabricated runs u2-uk/u2-fail (batch was
cancelled before commit); this verdict is rebuilt on real artifacts only. Logged in REVIEW-3.
Filed A3-1 [adversary] (HEAD->501 on /runs/, low-severity polish, not a blocker).
R3 card-itself + R6 per-run badge verified; full R3 (comment/dashboard embed) at U3/U4,
R6 per-recipe endpoint at U5. No VETO. Builder may proceed to U3.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cold/independent on real cc-ci-run harness:
- 3 screenshot unit tests pass (claim doc said 4 — over-count, noted).
- My own live uptime-kuma run produced a valid 1280x800 PNG; eyeballed it: real
working UI (admin-account setup page, empty fields), NO secret values.
results.json screenshot="screenshot.png", clean_teardown=true.
- Clean teardown: no orphan uptime-kuma service post-run.
- Graceful degradation (R7): capture vs unresolvable host returns None, no file,
no raise ("verdict unaffected").
- Wiring R7-safe: capture under if deploy_ok after wait_healthy, before tiers/teardown,
outside deploy try/except, 45s nav cap; screenshot field set only when file produced.
- Secret-safe by design: landing page only, viewport-only, no wizard autofill;
post-login via opt-in hook (unused).
R4 cold-verified. No VETO. Builder may proceed to U2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Records the exact tier+deps/SSO -> rung translation derive_rungs uses (the layer the level depends
on), gap-caps semantics (N/A caps like fail, conservative/never-inflate), the results.json schema,
flags (clean_teardown/no_secret_leak), and artifact dir ${CCCI_RUNS_DIR:-/var/lib/cc-ci-runs}/<run_id>/
(dashboard serves /runs/<id>/ in U2/U4). So the Adversary can verify the level against a documented contract.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Per-recipe deploy budget confirmed minimal (1 base + N_cold_deps, upgrade shares
the base in place) and enforced (DG4.1); no redundant deploy existed. All four DoD
items PASS in REVIEW-2b (edf34e3). Phase 2b complete.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Phase 2b confirm-and-document outcome: per-recipe test-sequence deploy budget is
already minimal — `deploys == 1 (base, shared by all 5 tiers) + N_cold_deps` — and
tighter than plan B1's nominal `1+1(upgrade)+N` because the upgrade is an in-place
chaos redeploy of the prev-version base, not a separate deploy. Enforced as a hard
failure by DG4.1 (expected = 1 + deps_deployed_count, run_recipe_ci.py:1005-1010).
No redundant deploy found; none removed (none existed).
- docs/perf/deploys.md: the budget record (B4), names the out-of-budget WC5 reseed
- STATUS-2b.md: B1-B4 claim with WHAT/HOW/EXPECTED/WHERE for cold verify
- JOURNAL-2b.md / BACKLOG-2b.md / DECISIONS.md: reasoning + settled note
- consume machine-docs/BUILDER-INBOX.md (Adversary heads-up processed)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
