5c499d290b
test / image-input-builds (pull_request) Successful in 47s
test / unit (pull_request) Successful in 59s
test / integration-docker (pull_request) Failing after 2m50s
test / coverage (pull_request) Has been skipped
tracker-policy-pr / check-pr (pull_request) Failing after 12m32s
prd-number-check / require-numbered-prds (pull_request) Failing after 12m45s
Both variants now pass, and the with-prerequisites run settled several things that were guesses before: * The Apple `container` service is per-user, confirmed directly rather than inferred: the throwaway account's appRoot is its own (/Users/bbtest/Library/Application Support/com.apple.container/), and starting it left the admin's service running and its agents intact. * Setting up a new account is two steps, not one. The guest kernel lives in that same per-user app root, so a fresh account has none and `container system start` prompts to download it — and only prompts, since the flags default to asking. Headless callers need --enable-kernel-install. * Neither step is performed by `bot-bottle backend setup --backend=macos-container`, which checks and then defers to `container system start`. So the real path for a new account is `container system start --enable-kernel-install`. * Any of it requires entering the user's launchd domain with `launchctl asuser`, because the apiserver is a per-user agent reached over XPC. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5
Docs
How this project records what it builds and why — and a guide to picking the right document for what you're capturing.
When to write which document
| Artifact | For |
|---|---|
Design workflow (docs/design-workflow.md) |
How discussion becomes canonical design, how dependencies are recorded, and when implementation may begin. |
Glossary (docs/glossary.md) |
Canonical term definitions — what words mean in this project. |
PRD (docs/prds/) |
A feature: what to build, scope, success criteria. |
Research note (docs/research/) |
A landscape/tradeoff investigation. |
Decision record (docs/decisions/) |
A decision that isn't itself a feature — a policy, a convention, a "we will / won't do this," or a load-bearing choice made inside a larger PRD that deserves to be discoverable on its own. |
A decision that's fully specified by a PRD doesn't need duplicating in a decision record. Write one when the decision would otherwise be buried in prose, lost in an issue thread, or have no in-repo home at all (small requests that don't merit a PRD; non-feature choices like merge strategy or a trust posture).