didericis
556217ae7b
The first run against the branch's own code confirmed the doctor fix — no traceback, the firecracker probes now report "TAP pool: 0/8" instead of dying on PermissionError — and then failed for a reason the installer cannot fix. The Apple `container` service is per-USER. `container system status` reports an appRoot under ~/Library/Application Support/com.apple.container/, and bbtest sees "container system service: NOT running" while the creating admin's is running. A brand-new account therefore has no backend until it runs `container system start` once, doctor rightly fails, and `test` would be permanently red for host state that install.sh neither creates nor can regress. So stop treating doctor's exit code as one verdict. `test` now fails when the install is broken — no entry point, doctor crashed, or doctor could not report a usable python and config dir — and reports backend readiness as a note. BB_TEST_REQUIRE_BACKEND=1 restores the strict behaviour. A traceback is checked for explicitly rather than inferred from the exit code, because those are the same value. The PermissionError bug exited non-zero exactly like a missing prerequisite does; only the traceback distinguishes a defect from an environment fact, and that distinction is the whole point of this change. The research doc's footprint table had the service as a host-wide launchd service that survives user deletion. It does not. The state lives in the home and goes with it, so the reset is more complete than claimed — but the corollary is that a fresh account cannot run a bottle until the service is started for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5
Research notes
Investigations into a question or a design space — landscape surveys,
tradeoff analyses, "should we do X or Y," assessments of an approach
before (or instead of) committing it to a PRD. A research note is where
the thinking lives; a PRD is where a decided feature lives, and a
decision record is where a settled choice lives (see
../README.md for picking between them).
Notes are opinionated. They reach a conclusion rather than dumping a neutral survey — the point is to move a decision forward and leave a durable record of why it went the way it did.
Naming
kebab-case-topic.md, named by subject and not numbered (unlike
PRDs and decision records). Pick a name that says what was
investigated: bash-vs-python-vs-go.md, pipelock-assessment.md,
issue-tracking-vs-in-repo-decision-history.md.
Shape (freeform)
There's no fixed template — use whatever structure fits the question. In practice most notes share a loose shape:
- Open with the question — a sentence or two on what's being investigated and why it came up.
- Lead with the verdict — a
## Summarynear the top stating the conclusion, so a reader gets the answer without reading the whole thing. - Then the analysis — whatever the argument needs: comparison tables, per-option sections, failure-mode walkthroughs, the axes that actually matter.
- End with a recommendation when the note exists to drive a decision.
Keep the reasoning self-contained and grounded: cite sources, link files and PRDs, and prefer concrete evidence from this repo over generic claims — a note should stand on its own without a chat log or a Gitea thread. When a note's recommendation gets acted on, capture the resulting decision in a PRD or a decision record; the note stays as the "why we looked into it," not the system of record for the choice.