workshop: name the roster after the rig and keep it current (#45)

The workshop lead names the team roster after the rig it actually runs in, taken from `rig whoami --json`
(`identity.rigName`), so a copy launched under another name gets its own roster instead of stopping at an existing
`workshop` one. If the daemon is unreachable and the name is null, the lead skips the roster and tries again at its
next start.

The roster is also kept current: when a seat picks up a capability or specialization worth asking it about, the lead,
as curator, adds it to that member's `capabilities`, adjusts `use_when` or `why` if needed, sets `updated_at`, and runs
`rig roster list` to check it still lists. The builder, code reviewer and QA seats tell the lead when they pick one up.
Starting again never replaces the file.

Text only: role guidance and the README.

rigs/workshop/README.md

@@ -81,8 +81,8 @@ it with your name if you want the lead to know who sent it:
 rig send orch-lead@workshop "Please take issue #<number>: <one line on what you want>"
 ```
 
-At first start the lead also publishes the team's roster, `<workspace.root>/rosters/workshop.json`,
-if there isn't one yet. Need expertise your team lacks? `rig roster find <topic>` lists who to ask and why.
+At first start the lead also publishes the team's roster, `<workspace.root>/rosters/workshop.json`
+(named after the rig), if there isn't one yet. Need expertise your team lacks? `rig roster find <topic>` lists who to ask and why.
 
 Stop the team with `rig down workshop`. That removes OpenRig's blocks from
 `CLAUDE.local.md` and `AGENTS.md`. The seats' git worktrees under `.worktrees/`

rigs/workshop/agents/workshop/guidance/builder.md

@@ -55,3 +55,7 @@ the person decide when the branch goes out.
 
 Send the lead a report they can quote in the pull request: what changed, each
 command you ran with the commit and the result, and what you could not run.
+
+When you pick up a specialization others should know to ask you about, such as
+a part of the code you now know well, tell the lead so it goes in the team's
+roster.

rigs/workshop/agents/workshop/guidance/code-reviewer.md

@@ -39,3 +39,7 @@ Something outside this change goes to the lead as a note, not a finding.
 Send findings to the builder and a short verdict, with what you ran, to the
 lead. If you cannot reach the daemon, write the report on your screen under a
 clear heading.
+
+When you pick up a specialization others should know to ask you about, such as
+a kind of defect you now catch reliably, tell the lead so it goes in the team's
+roster.

rigs/workshop/agents/workshop/guidance/lead.md

@@ -33,19 +33,23 @@ Tell the person what you added.
 A roster tells anyone who uses `rig roster find` who to ask on this team and
 why. Write one the first time you start, and never replace one that exists:
 
-1. Run `rig roster list`. If it shows a roster with id `workshop`, stop here.
-2. The file is `<workspace.root>/rosters/workshop.json`; `rig config get
+1. Take the rig's name from `rig whoami --json` (`identity.rigName`). It is
+   `workshop` unless this team was launched under another name; `<rig>` below
+   means that name. If it is null, the daemon isn't reachable: skip the roster
+   for now and try again at your next start.
+2. Run `rig roster list`. If it shows a roster with id `<rig>`, stop here.
+3. The file is `<workspace.root>/rosters/<rig>.json`; `rig config get
    workspace.root` gives the root. If the file exists, stop here too. Create
    the `rosters/` folder if it is missing.
-3. Run `rig ps --nodes --rig workshop --json --fields canonicalSessionName,hostSelfId`.
+4. Run `rig ps --nodes --rig <rig> --json --fields canonicalSessionName,hostSelfId`.
    It gives each seat's exact address and the host that serves it.
-4. Write the file with those addresses and hosts, today's date, and yourself as
+5. Write the file with those addresses and hosts, today's date, and yourself as
    curator (format: OpenRig's `docs/reference/rosters.md`):
 
    ```json
    {
      "version": 1,
-     "id": "workshop",
+     "id": "<rig>",
      "name": "Workshop",
      "purpose": "Build software in this repository, one pull request at a time",
      "curator": { "seat": "<your address>", "host": "<your host>" },
@@ -67,10 +71,21 @@ why. Write one the first time you start, and never replace one that exists:
    }
    ```
 
-5. Run `rig roster list` to see it listed, then tell the person in one line.
+6. Run `rig roster list` to see it listed, then tell the person in one line.
 
 Running this again, after `rig seat continue` or a restore, changes nothing.
 
+### Keep the roster current
+
+The roster is where the team records who does what, and seats grow into
+specializations as they work. You curate it. When a seat takes on a capability
+or specialization worth asking it about, add that to the seat's `capabilities`
+in the roster file. If its `use_when` or `why` no longer fit, adjust them too.
+Leave the other fields as they are, set the roster's `updated_at` to today,
+then run `rig roster list` to check it still lists. The other seats tell you when they pick one up; add what you notice
+yourself as well. Starting again never replaces the file; only these edits
+change it.
+
 ## Propose the first piece of work
 
 Unless the person has already given you work:

rigs/workshop/agents/workshop/guidance/qa.md

@@ -61,3 +61,7 @@ at the worktree root, which must not be committed.
 
 Send results to the builder and the lead. If you cannot reach the daemon, write
 them on your screen under a clear heading.
+
+When you pick up a specialization others should know to ask you about, such as
+a kind of check you now run well, tell the lead so it goes in the team's
+roster.