didericis
71c0f8ed88
"Does the installer work" and "can a new user actually run a bottle" are
different questions, and collapsing them is what made the previous run
ambiguous. Split them into two cycles over the same throwaway account:
test a macOS system WITHOUT the prerequisites set up for this user,
which is the default state of every new account since the Apple
`container` service is per-user. Asserts the install is sound;
reports backend readiness without failing on it, because
install.sh provides no backend and cannot regress one.
test-ready the same system WITH them. Runs `container system start` for the
throwaway user, then demands doctor go fully green, backend
included — the end-to-end claim.
The new `prereqs` step runs `container system start` rather than
`bot-bottle backend setup --backend=macos-container`, because that subcommand
does not start anything: it checks, then tells you to run `container system
start` yourself (backend/macos_container/setup.py, "no privileged host setup
required"). The harness runs what the product actually asks for.
test-ready sets BB_TEST_REQUIRE_BACKEND, so it demands exactly what `test`
merely reports. Both share one cycle function; the step count and the PASS
claim are the only differences beyond the extra step, so neither variant can
drift from the other's teardown or dirty-account guarantees.
Rig covers the distinguishing case directly: identical host state where `test`
passes on install soundness and `test-ready` starts the service and reaches a
green backend, plus the service-start failure and an install failure under
test-ready. 22 scenarios, all passing.
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.