amadan
plan: phase 0 was wrong about its own five failures
Running the root package here does not produce five failures and a pass for everything else. It produces five failures and then the test binary EXITS — a log.Fatal on the same root cause takes the process down, in 0.2 seconds, against 147 in CI. Everything after that point is unrun and nothing says so, which means nobody has ever seen this package's local state at all. TestConfigDefaultWalk fails at its first assertion too and is not in the five, because the binary is already gone by then. One cause, not five: walkConfig climbs from cwd to the filesystem root, passes through /home/paulca, and adopts the developer's own global config as a PROJECT pin — authoritative, per the resolution spec, so resolution never falls past it. Any checkout under a home directory that has ever run `carlos auth default` gets this. Filed as discussion #17 rather than fixed in passing. The narrow half has a precedent to copy exactly (CARLOS_CONFIG, mirroring CARLOS_CREDENTIALS at auth.go:134). The other half needs the walk to have a boundary — $HOME, or the repo root, which is what config.go's own header already describes a project config as — and that is a documented-behaviour change owned by the console-default-resolution spec, not something to decide while clearing a red gate. Phase 1 does not wait on it. The gate that matters is CI's, and CI has never had this problem.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PEkJh1ESqiA84quAHJV4K6
1 file changed,
+31
−12
docs/superpowers/plans/2026-09-04-scanning-to-deployable.md+31 −12
diff --git a/docs/superpowers/plans/2026-09-04-scanning-to-deployable.md b/docs/superpowers/plans/2026-09-04-scanning-to-deployable.md| index bdb62894f..26a9d27c2 100644 |
| --- a/docs/superpowers/plans/2026-09-04-scanning-to-deployable.md |
| +++ b/docs/superpowers/plans/2026-09-04-scanning-to-deployable.md |
| @@ -41,10 +41,15 @@ true. It is also the exact shape of camouflage a sixth failure needs: the |
| package was known to be red, so the count was never read. |
| The fix is one line. The lesson costs more than the fix: **a known-failing |
| -package cannot be a known-failing package.** The environmental failures are |
| -real and specific — the checkout sits under `/home/paulca`, so `pick()` finds a |
| -live `~/.carlos/config` — and from here they are named individually, by test, |
| -not as a count. Phase 0 closes this. |
| +package cannot be a known-failing package.** |
| + |
| +And the note was not even accurate about its own five. Running the package |
| +locally shows the test binary **exiting after 0.2 seconds** — a `log.Fatal` on |
| +the same root cause takes the process down, so most of a 147-second suite is |
| +never run and nothing says so. The cause is one lookup with no boundary: |
| +`walkConfig` climbs from cwd to `/`, passes through `/home/paulca`, and adopts |
| +the developer's own global config as a project pin. Filed as **discussion |
| +#17**; Phase 0 carries the diagnosis and Phase 1 does not wait on the fix. |
| ### What is deployable today |
| @@ -120,16 +125,30 @@ without it. Starting that clock now overlaps someone else's work with tasks |
| - [x] Fix the `carlos store` usage assertion. |
| - [ ] Push, and read `amadan ci status carlos/platform` until the gate passes. |
| -- [ ] Replace the "five tests fail environmentally" note in both plans with the |
| - named list, and the reason (`pick()` finds a real `~/.carlos/config` because |
| - the checkout is under `/home/paulca`). A count is not a note; a list is. |
| -- [ ] Add a `make test` wrapper or `CARLOS_CONFIG` override so the root package |
| - passes locally too. **The right end state is zero known-failing tests**, so |
| - that any red is news. If that turns out to be more than an hour, file it and |
| - move on — but file it, because the camouflage is the actual defect here. |
| +- [x] Diagnose the local failures properly — and the diagnosis is worse than the |
| + note. **The test binary does not run to completion on this machine**: a |
| + `log.Fatal` on the same root cause takes the process down after five |
| + reported failures, in 0.2 seconds, against 147 in CI. Everything after that |
| + point is unrun, and nothing says so. `TestConfigDefaultWalk` fails at its |
| + first assertion too and is not in the five, because the binary is already |
| + gone. There is no basis for "five". |
| +- [x] One cause, not five: `walkConfig` (`config.go:62`) climbs from cwd to the |
| + filesystem root, passes through `/home/paulca`, and adopts the developer's |
| + global config as a *project* pin. It bites any checkout under a home |
| + directory that has ever run `carlos auth default`. |
| +- [x] **Filed as `carlos/platform` discussion #17** rather than fixed here. The |
| + narrow half copies an existing precedent (`CARLOS_CONFIG`, mirroring |
| + `CARLOS_CREDENTIALS` at `auth.go:134`); the other half needs a walk boundary |
| + — `$HOME` or the repo root — and that is a documented-behaviour change owned |
| + by `2026-08-04-console-default-resolution-design.md`, not a midnight |
| + drive-by. |
| +- [ ] **Zero known-failing tests, and a line in AGENTS.md** saying a |
| + known-failing test is a defect in its own right. This is the bullet that |
| + pays for the other two: the failure count was what got read instead of the |
| + names, and that is precisely how a week of red went unexamined. |
| **Done when:** `amadan ci status carlos/platform -branch worktree-store-scan-on-demand` |
| -exits 0. |
| +exits 0. The local suite is #17's job, and Phase 1 does not wait on it. |
| ## Phase 1 — land the sweep half |