stack/docs/acceptance/314.md

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.

<business> is the business the bus host runs. <project> 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. No verb adds an instance today, so Jason adds them by editing the business file, then runs scripts/mosaic business validate <business>.
• arbiters.technical is cto, which step 5 assumes.

Steps

1. Create the project repository, if it doesn't exist yet:

   mosaic project init <business> <project>
   mosaic project check <business> <project>
   

   Pass: check reports the layout valid. The first commit's author is Jason. (REQ-PROJ-1)

   Then create a bus project named for <project> with repo <project>, 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 <task>
   

   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 <decision>
   git -C <working repository> 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 <business> --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 <task>
   

   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 <decision> 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 <name from the agents list> "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.