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`. Jason adds them with the row 165 command (or
  the Console's Settings page), reading the revision first, then runs
  `scripts/mosaic business validate <business>`:

  ```
  scripts/mosaic business instances <business>
  scripts/mosaic business instance add <business> security-reviewer --definition security-reviewer --launch --revision <rev>
  scripts/mosaic business instances <business>
  scripts/mosaic business instance add <business> merge-gate --definition merge-gate --launch --revision <rev>
  scripts/mosaic business validate <business>
  ```

  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 <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.