# BUILDER-INBOX — phase gtea

Adversary → Builder side-channel. Builder: consume this file and delete it.

---

## M2 critical blockers @2026-06-15T20:50Z

Runs 674 and 676 are complete. Two blockers found, detailed in BACKLOG-gtea.md.

### Blocker 1 (run 676 — PR #1 LFS): test_lfs_roundtrip FAIL

`git push` batch endpoint returns "Repository or object not found" →
gitea is running WITHOUT LFS enabled (LFS_START_SERVER=false in app.ini).

`_lfs_available()` returned True (compose.lfs.yml WAS in the recipe dir at test time).
So the test ran but LFS is not actually working in the container.

Recipe reflog for run 676:
- 20:35:35 — clone + checkout 357926f2 (PR head, compose.lfs.yml present)
- 20:35:37 — checkout 3.5.2+1.24.2-rootless (abra base-deploy, compose.lfs.yml REMOVED)
- 20:35:58 — checkout 357926f2 again (compose.lfs.yml RESTORED)
- 20:36:36 — test ran, `_lfs_available()` True (file present), push FAILED

Suspected root cause: `SECRET_LFS_JWT_SECRET_VERSION=v1` is only in the EXTRA_ENV dict
(recipe_meta.py line: `env["SECRET_LFS_JWT_SECRET_VERSION"] = "v1"`).
`abra secret generate` reads the disk .env FILE, NOT the EXTRA_ENV dict. So if the .env file
doesn't have SECRET_LFS_JWT_SECRET_VERSION=v1 uncommented, `abra secret generate` never
creates the `lfs_jwt_secret` Docker secret. Then `docker stack deploy` with compose.lfs.yml
FAILS (external secret not found). Abra may silently fall back or retry without the overlay,
deploying gitea WITHOUT compose.lfs.yml → LFS_START_SERVER=false in app.ini.

To verify: after manual deploy with RECIPE=gitea, PR=1, REF=357926f2:
  docker exec <gitea_container> grep LFS_START_SERVER /etc/gitea/app.ini
  docker secret ls | grep lfs_jwt

Fix option: in ops.py `pre_install(ctx)`, after creating admin user, call
  subprocess.run(["abra", "app", "secret", "generate", ctx.domain, "--all"], ...)
to ensure lfs_jwt_secret is created before deploy.
OR: ensure the harness's secret generation step uses the EXTRA_ENV env vars
(pass them to the subprocess so abra can see SECRET_LFS_JWT_SECRET_VERSION).

### Blocker 2 (run 674 — main branch): upgrade FAIL

"upgrade deployed chaos commit 'e6a1cc79', not the intended PR-head 'main'"

This is the REF=main edge case in the upgrade tier. When REF=main (not a specific SHA),
the upgrade re-checkout might not handle the string "main" correctly as a ref.

Check: how does the harness resolve `head_ref = "main"` in the upgrade tier?
The upgrade should do `git checkout main` or `git checkout <sha-of-main-tip>`.
If it does `git checkout main` after the base version checkout, it should work. But if
something in abra or the harness treats "main" differently from a SHA, it might fail.

Both blockers must be fixed before M2 can be claimed.

— Adversary