# Acceptance run for task 314 (Q167) Jason runs this inside the Stack once rows 128, 135 to 143 and 147 to 149 are live. It checks PRD version 1.5: one need goes from his spec to a landed commit, and only hard waits reach his inbox. Row 128 is there because the assistant is the business's threaded instance. The bus refuses a plain `message.send` to it with `thread-required-use-thread-send` (`packages/bus/src/broker.mjs:281` at c550efa27), and before row 128 no CLI or Console code creates a project or a thread. Row 143's summary also lands only in Jason's most recently opened assistant thread in the spec's project, so without one, step 9 fails. `` is the business the bus host runs. `` is the project the need belongs to, `stack` for this run. Every command runs on the host, as Jason. The need is a `mosaic version` command that prints the release and the bus schema. ## Before the run - `mosaic bus status` says the host is live. - `mosaic inbox` shows no open decision. If one is open, resolve or supersede it first, so step 6 starts from an empty inbox. - The business has security-reviewer and merge-gate instances, and both are in `launch.instances`. Jason adds them with the row 165 command (or the Console's Settings page), reading the revision first, then runs `scripts/mosaic business validate `: ``` scripts/mosaic business instances scripts/mosaic business instance add security-reviewer --definition security-reviewer --launch --revision scripts/mosaic business instances scripts/mosaic business instance add merge-gate --definition merge-gate --launch --revision scripts/mosaic business validate ``` Each add prints the new revision, so the second add can take it instead of a second read. Both adds say a bus restart is needed. The running bus only learns the new instances at restart, which needs Mos's go or Jason's hand. - `arbiters.technical` is `cto`, which step 5 assumes. ## Steps 1. Create the project repository, if it doesn't exist yet: ``` mosaic project init mosaic project check ``` Pass: `check` reports the layout valid. The first commit's author is Jason. (REQ-PROJ-1) Then create a bus project named for `` with repo ``, create an assistant thread in it, and open that thread (for `stack`): ``` mosaic project create stack --repo stack mosaic thread create stack assistant mosaic thread open stack/assistant mosaic threads --project stack ``` Steps 3, 6 and 9 use this thread. Pass: `mosaic threads --project stack` shows `stack/assistant` under the project, and the broker made it as Jason. 2. Open the spec in the Console editor and write it: > North star: anyone can tell what is running in one command. > Need: a `mosaic version` command that prints the release and the bus > schema. Before saving, open the same file in a second Console tab. Save in the first tab. Pass: the save makes one local commit with Jason as author, and the editor shows the new commit. Then edit and save in the second tab, which still holds the old commit: the save is refused and writes nothing. (REQ-PROJ-2, REQ-PROJ-3) 3. Tell the assistant about the need, in the thread from step 1: ``` mosaic talk --thread stack/assistant "New need: the mosaic version command in spec/north-star.md. Start it." ``` Pass: `talk` prints only the assistant's reply to this message. 4. Watch the work start: ``` mosaic tasks mosaic agents mosaic trail ``` Pass, all on the trail: - pm makes the tasks and sends the chief of staff a staff request naming the roles and counts (REQ-COS-2); - the chief of staff launches a coder, a reviewer and a security-reviewer through role.launch (REQ-ROLE-5); - the coder pushes a work ref, and the reviewer and the security-reviewer each approve it. 5. Watch it land: ``` mosaic trail git -C log --oneline -3 main ``` Pass: - pm hands the approved candidate to merge-gate, and merge-gate raises the `git.merge.protected` decision citing `spec/north-star.md` at the commit from step 2; - the CTO resolves it, not Jason (REQ-DEC-2); - merge-gate lands it, the trail records the allowed action with the landed commit, and the commit is on the working repository's `main` (REQ-LAND-1). 6. Check the inbox, then ask for one hard wait on purpose. Run `mosaic inbox`, tell the assistant in the step 1 thread "Open a new account for the project on an outside service.", then run `mosaic inbox` again. Pass: the first `inbox` is empty, so nothing from steps 3 to 5 reached Jason. After the request, the inbox holds one decision for `account.create`. Resolve it with the reject option. (REQ-WAIT-1) 7. Restart the host halfway through the next merge. Use a second small change, for example "print the help when an option is unknown", and restart once the CTO has resolved its merge decision and before merge-gate lands it. Mos or Jason runs the restart: ``` mosaic bus stop mosaic bus start --pm ``` Pass: the merge lands from a new run of the same merge-gate instance with the approval from before the restart, and no new decision is raised. (REQ-DEC-5) 8. Change the spec in the Console editor: also print the commit. Save. ``` mosaic tasks mosaic trail ``` Run `mosaic trail` for each task from step 4 and each task made after the save. A task's trail lists the decisions filed under it with the spec commit each one cites; `mosaic trail ` shows one in full. Pass: - the save makes a new commit by Jason; - no decision settled under the step 2 commit is reopened on its trail (REQ-DEC-6); - the new raises cite the new commit on their trails, and no raise citing the step 2 commit is accepted after the save; - pm and the CTO each answer the spec commit with an accept (REQ-PROJ-4). 9. Change the spec in a way that breaks a settled decision, for example: "the version command prints nothing and exits." Save. Pass: pm or the CTO answers with a BLOCK naming the conflict, the commit stays, and the assistant tells Jason about the block in its own words, in the step 1 thread. The assistant's message doesn't quote the chief of staff's text. (REQ-PROJ-4, REQ-ASSIST-3) Then revert the spec in the editor with a new commit. 10. Give the coder instance a name with the CLI command row 141 adds (`docs/TOOLS.md` names it once that row lands), then send it a message by that name: ``` mosaic agents mosaic talk "Reply with your role name." ``` Pass: the reply comes from the instance with that name, and the trail records both the name and the instance. (REQ-MSG-2) ## Result The run passes when every step passes. Record the run with the date, the release, the bus schema and the result of each step in Vikunja task 314. A failed step names the requirement it checks, so the fix goes back to that row.