STATUS/JOURNAL: A4 mitigated by capacity=1; A2/A3 fixed-in-code, awaiting Adversary re-test

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

JOURNAL.md

@@ -516,3 +516,11 @@ So the full D1→D2 path is wired and proven in two verified halves: poll-trigge
 RECIPE param correct) and Drone→harness 3-stage CI (build #33, green + clean teardown). Remaining for
 full single-comment E2E on a *recipe* PR: enroll the recipe in the bridge POLL_REPOS + open a recipe
 PR (M6.5/M10 breadth work).
+
+**Adversary findings status (signal for re-test):** A2 (janitor `-pr` filter) and A3 (teardown
+verification + `.env`-last ordering) are both already fixed in the current code
+(`lifecycle.RUN_APP_RE` hashed-scheme match; `teardown_app` `_residual()` raise + `docker stack rm`
+fallback) — awaiting the Adversary's kill-probe re-test on an idle host. A4 (concurrent same-recipe
+collision): its named root cause "no Drone concurrency cap (capacity=2)" is eliminated by
+MAX_TESTS=capacity=1 — no concurrent runs possible on this single node, so the shared-recipe-dir race
+can't occur. No Builder fix outstanding on findings; next milestone work is M6.5 breadth.

STATUS.md

@@ -49,6 +49,19 @@ resource safety: MAX_TESTS=1 + 60m timeout)
   read-only/outbound and needs no Gitea `ALLOWED_HOST_LIST` whitelist).
 
 ## Tracking (adversary findings I must address)
+- **[adversary] A4 — concurrent same-recipe runs collide on shared `~/.abra/recipes/<recipe>`.**
+  Root cause the finding names ("no Drone concurrency cap — runner capacity=2") is now **eliminated**:
+  MAX_TESTS = `DRONE_RUNNER_CAPACITY` = 1 (resource-safety change). With ≤1 build at a time there is
+  **no concurrent run** on this single node, so the shared-recipe-dir race cannot occur. Builder side
+  addressed via the concurrency cap (per plan §4.2 "concurrency cap 1–2"); Adversary to re-test/close.
+  (Per-run `ABRA_DIR`/HOME isolation would be belt-and-suspenders but is unnecessary at capacity=1.)
+- **[adversary] A2 — janitor `-pr` filter dead.** Already fixed in code: `lifecycle.RUN_APP_RE` =
+  `^[a-z0-9]{1,4}-[0-9a-f]{6}\.ci\.commoninternet\.net$` (the hashed scheme), plus a stack-name regex
+  for `.env`-less orphans, gated on age. Awaiting Adversary kill-probe re-test.
+- **[adversary] A3 — teardown unverified; `.env` removed before confirmed undeploy.** Already fixed:
+  `lifecycle.teardown_app` undeploys → `docker stack rm` fallback if services remain → removes
+  volumes/secrets while `.env` exists → drops `.env` LAST → then `_residual()` check raises
+  `TeardownError` if anything is left. Awaiting Adversary kill-mid-run re-test.
 - **[adversary] A1 — no-ACME hazard for test apps.** Acknowledged (valid). The harness (M4) MUST
   force `LETS_ENCRYPT_ENV=""` on every test-app deploy (already done in `scripts/deploy-proxy.sh` and
   the M1 manual custom-html deploy; `scripts/deploy-drone.sh` will too). Considering a structural