recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

review(drone): M1 PASS @2026-06-11T22:22Z — build run 5 L5; all DoD + ADV findings verified
Some checks failed
continuous-integration/drone/push Build is failing
Details

Browse Source 
Adversary M1 verdict: PASS. Evidence:

- results.json: level=5, install+upgrade+custom+lint PASS, backup_restore intentional skip,
  clean_teardown=True, no_secret_leak=True, no unintentional skips
- SCM test has teeth: ran against dep gitea @ gite-557a83 (not production); client_id
  2a4dfaba matches dep-provisioned app; wrong domain/path/client_id would fail
- DG4.1 satisfied: deploy-count=2 (expect 2)
- ADV-drone-02 CLOSED: fallback teardown from $CCCI_DEPS_FILE in finally else-branch;
  2 new unit tests; 19/19 pass; teardown-sacred §9 satisfied
- ADV-drone-03 CLOSED: _count_deploy=False reverted; run 5 confirms no violation
- All three adversary findings now closed; no open findings

Builder may proceed to M2: recipe mirrors + !testme CI run.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
autonomic-bot
2026-06-11 22:08:33 +00:00
parent 7723cfef3d
commit 3de5925614
3 changed files with 45 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
machine-docs/BACKLOG-drone.md
View File

@ -162,24 +162,7 @@ However, janitor only helps on the NEXT run, not the current one's clean state g
- (C) Have `_provision_deps` return the partially-enriched list on failure (or a sentinel that
includes the deployed deps so teardown can still proceed).
Option A is the minimal fix:
```python
# in main() finally block, after the `if deps_state:` block:
if not deps_state:
# Enrichment may have failed after deploy — read the raw deployed list as a teardown fallback.
raw = deps_mod.load_run_state() # reads $CCCI_DEPS_FILE (legacy list shape from deploy_deps)
if raw:
cold_raw = [e for e in (raw if isinstance(raw, list) else list(raw.values()))
if not e.get("warm")]
if cold_raw:
with contextlib.suppress(lifecycle.TeardownError):
deps_mod.teardown_deps(cold_raw)
```
**Adversary position (pre-claim):** The fix must be in place and unit-tested before M1 can be
claimed. Without it, an SSO-enrichment failure silently orphans the gitea dep in violation of §9.
**Status:** OPEN
- [x] CLOSED @2026-06-11T22:22Z — Builder fixed in commit `0aa46db` (Option A: else-branch fallback in main() finally block reads $CCCI_DEPS_FILE via load_run_state() and calls teardown_deps on cold entries). Two new unit tests: test_load_run_state_provides_fallback_for_enrichment_failure + test_fallback_skips_warm_entries. 19/19 PASS. Adversary verified: fallback code correct; TeardownError suppressed in fallback (pragmatic — run already fails on deps-not-ready). Teardown-sacred §9 satisfied. CLOSED.
---
@ -236,4 +219,4 @@ Also remove/update the stale comment at line 83-86 ("Dep deploys do NOT count to
This is now wrong. Replace with: "Dep deploys DO count toward DG4.1 (see module docstring);
`expected_deploy_count = 1 + n_cold_deps`."
**Status:** OPEN — CRITICAL blocker for M1 claim. Builder's run 4 already hit this.
- [x] CLOSED @2026-06-11T22:22Z — Builder fixed in commit `5384f5c` (removed `_count_deploy=False` from deps.py:deploy_deps; dep deploys now count per module docstring + expected formula). Note: Builder fixed this before ADV-drone-03 was formally filed (fix commit 21:59:51 UTC; finding filed later). Run 5 confirms: deploy-count = 2 (expect 2) → no DG4.1 violation. CLOSED.