workshop: say how to reach the newly installed team (#47)

The workshop README and the lead's guidance now say how to reach the newly installed team: rig capture and rig send from any shell, tmux attach (or switch-client inside tmux) using the attach command OpenRig prints per seat, bare rig for the TUI, and rig terminal open <rig> when herdr or cmux is available. The lead uses its own rig and session names rather than assuming "workshop". The exclude lines add gate-lane-verdict.json, which the QA seat's npm run gate writes at the worktree root. The note for people who ask Claude Code to do the setup now records that its default auto mode declined the rig up line on macOS with 2.1.289 and 2.1.290 (and, in an earlier 2.1.289 run, a permission rule for itself and rig context add --git), so run those two commands yourself. The vendored developing-openrig and openrig-skills copies are synced to openrig fcef78ab.

rigs/workshop/README.md

@@ -29,10 +29,11 @@ repository's own `developing-openrig` skill.
   open pull requests, with push credentials configured on this machine.
 
 Keep OpenRig's files out of your commits. OpenRig writes instruction files,
-settings and helper scripts into your clone. From the root of your clone:
+settings and helper scripts into your clone, and in an OpenRig clone the QA
+seat's `npm run gate` writes `gate-lane-verdict.json`. From the root of your clone:
 
 ```sh
-printf '%s\n' CLAUDE.local.md AGENTS.md /.openrig/ .claude/settings.local.json >> .git/info/exclude
+printf '%s\n' CLAUDE.local.md AGENTS.md /.openrig/ .claude/settings.local.json gate-lane-verdict.json >> .git/info/exclude
 ```
 
 This file is local to your clone and is never committed. It applies to the
@@ -49,12 +50,15 @@ Optional: add OpenRig's public context pack, so the seats load it at start:
 rig context add --git https://github.com/mvschwarz/openrig-world
 ```
 
-**If you ask Claude Code to do this setup for you,** plan to run two steps
-yourself. In OpenRig's test on macOS with Claude Code 2.1.289, its default auto
-mode declined them: adding a permission rule for itself (`[Self-Modification]`;
-add any rule yourself with `/permissions` or in `.claude/settings.local.json`),
-and `rig context add --git` (`[Untrusted Code Integration]`), even with an allow
-rule for that command.
+**If you ask Claude Code to do this setup for you,** plan to run some steps
+yourself. In OpenRig's tests on macOS, Claude Code's default auto mode declined
+the `rig up` line (`[Create Unsafe Agents]`, because it starts new agents) on
+2.1.289 and 2.1.290, and in an earlier 2.1.289 run also declined adding a
+permission rule for itself (`[Self-Modification]`; add any rule yourself with
+`/permissions` or in `.claude/settings.local.json`) and `rig context add --git`
+(`[Untrusted Code Integration]`), even with an allow rule for that command. Run
+`rig context add --git` and `rig up` yourself in a terminal, from the root of
+your clone.
 
 ## Run it
 
@@ -72,10 +76,25 @@ wrong place.
 
 Once the seats are up, the lead reads the repository's `ROADMAP.md` if it has
 one and looks for candidate work (open issues, TODOs, failing checks). It
-proposes one item, says why, and asks before starting. Answer it in the lead's
-terminal (`rig` opens the TUI), or give it work of your own from any shell. A
-message from your own terminal arrives marked as from an unsigned sender; start
-it with your name if you want the lead to know who sent it:
+proposes one item, says why, and asks before starting.
+
+**Reaching the team.** The rig is named `workshop` unless it was launched under
+another name (`rig ps` lists your rigs), and the lead's session is
+`orch-lead@<rig>`. Use whichever suits you; an agent that installed the team
+for you can do the first one itself:
+
+- From any shell, read the lead's screen with `rig capture orch-lead@workshop`
+  and answer with `rig send` (below).
+- Put a terminal on the lead with `tmux attach -t orch-lead@workshop`. From
+  inside tmux, use `tmux switch-client -t orch-lead@workshop`. Press Ctrl-b,
+  then d, to leave it running. `rig ps --nodes --rig workshop --json --fields canonicalSessionName,tmuxAttachCommand`
+  prints this command for every seat.
+- Run `rig` for OpenRig's TUI.
+- Open every seat as a tile with `rig terminal open workshop`, if
+  `rig terminal status` shows a terminal provider (herdr by default, or cmux).
+
+A message from your own terminal arrives marked as from an unsigned sender;
+start it with your name if you want the lead to know who sent it:
 
 ```sh
 rig send orch-lead@workshop "Please take issue #<number>: <one line on what you want>"

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

@@ -99,6 +99,17 @@ Unless the person has already given you work:
    rather than the others, and roughly how big it is. Then ask before starting.
    Don't start on a proposal nobody accepted.
 
+The person may not be at your terminal: an agent may have installed the team
+for them. With your proposal, tell them briefly how they can answer you. Use your
+own names from `rig whoami --json` (`identity.rigName` and
+`identity.sessionName`), not the word `workshop`:
+- from any shell: `rig send <your session> "<their answer>"`, and
+  `rig capture <your session>` to read your screen;
+- to come to your terminal: `tmux attach -t <your session>` (from inside tmux,
+  `tmux switch-client -t <your session>`), or `rig` for OpenRig's TUI;
+- to see the whole team: `rig terminal open <rig>`, when `rig terminal status`
+  shows a terminal provider.
+
 ## Scope the work
 
 Look before you build (the rig's culture):

rigs/workshop/agents/workshop/pi-skills.lock.json

@@ -1,6 +1,6 @@
 {
   "productRepository": "https://github.com/mvschwarz/openrig",
-  "productCommit": "aeb67bd0c7afdfdade597bfde35f669e894143c5",
+  "productCommit": "fcef78aba543791bb9175b4a2ac6e33130ec3e50",
   "pluginPath": "packages/daemon/assets/plugins/openrig-core",
   "pluginVersion": "0.1.4",
   "pluginManifestSha256": "5bd9904c982023f0b6a994dba348bb2df3f21663327017d007a2568069a681b5",
@@ -100,7 +100,7 @@
       "path": "skills/developing-openrig/SKILL.md",
       "source": ".agents/skills/developing-openrig/SKILL.md",
       "mode": "100644",
-      "sha256": "c59017278389d10bcaaab2eb068b41ccf79f205aa80b176924afcfc7a813db4d"
+      "sha256": "fba6335a4e091adb195d90774247bf1ee0e882464bb2ebc3a5d7e77b2d354e00"
     },
     {
       "path": "skills/forming-an-openrig-mental-model/SKILL.md",
@@ -202,7 +202,7 @@
       "path": "skills/openrig-skills/SKILL.md",
       "source": "packages/daemon/assets/plugins/openrig-core/skills/openrig-skills/SKILL.md",
       "mode": "100644",
-      "sha256": "e5f47e24a4c3cb1afceb1a3a93647313e9c30830aff58faabb5fa57838d1206c"
+      "sha256": "59601122bd3c4b8eb82cc6e31b710528c97a5fde3b09e01076f742fd6e39e73e"
     },
     {
       "path": "skills/openrig-user/SKILL.md",

rigs/workshop/agents/workshop/skills/developing-openrig/SKILL.md

@@ -23,12 +23,17 @@ not by restarting the daemon you live in.
 
 | You want to know | Read | How much to trust it |
 |---|---|---|
+| What OpenRig can already do, before you decide something is missing | `rig context get onboarding-width/public-what-you-can-do.md`; in this checkout, `packages/daemon/context-packs-src/onboarding-width/public-what-you-can-do.md` (the installed copy can differ) | The capability map; check it before proposing a new command or calling a gap a defect |
+| Whether a `rig` command already exists | `rig --help`: the full command list, before you decide a command is missing | The running binary; read the whole list, not only the command you expected |
+| Whether a problem is already known | The "Known problems to compare against" section of [`docs/reference/help.md`](../../../docs/reference/help.md) | Lists known issues by symptom; check an issue's current status before relying on it |
+| Whether a feature is already planned | [`ROADMAP.md`](../../../ROADMAP.md) | Check it before proposing a feature |
 | How the packages fit, the request path, where to add a command, route, migration, adapter, skill, context pack or scenario | [`ARCHITECTURE.md`](../../../ARCHITECTURE.md) | Checked against the commit it names; counts come with the command to refresh them |
 | Whether your change touches a high-risk area, what depends on it, what broke there before | [`docs/as-built/arteries.md`](../../../docs/as-built/arteries.md) | Incomplete by design: absence from it doesn't make a change safe |
 | What to run before you push, and what each layer can and can't prove | [`docs/as-built/test-layers.md`](../../../docs/as-built/test-layers.md) | Checked against the commit it names |
 | The exact behaviour of a `rig` command | `rig <command> --help` on the running binary, then `packages/cli/src/commands/` | The binary and the code win over any document |
-| A subsystem in depth | [`docs/as-built/`](../../../docs/as-built/README.md) | Most modules predate 0.6; check each one's `last-verified-against-source` marker against `git log` before relying on it |
+| A subsystem in depth | [`docs/as-built/`](../../../docs/as-built/README.md) | Each module names the commit it was last checked against in `last-verified-against-source`; compare that marker with `git log` before relying on it |
 | Rig spec, agent spec and other user-facing reference | [`docs/reference/`](../../../docs/reference/) | Ships to every user; if you find drift, fix it there |
+| Which shipped skill covers a task | [`skills/_canonical/core/openrig-skills/SKILL.md`](../../../skills/_canonical/core/openrig-skills/SKILL.md) | The index of the skills that ship with OpenRig |
 | How to open a good pull request, and what review looks like | [`CONTRIBUTING.md`](../../../CONTRIBUTING.md) | Current |
 
 If none of these answers your question, search the code before inventing an answer. A missing map is worth an issue.
@@ -56,6 +61,10 @@ stub-agent scenarios, which run the real CLI, daemon, tmux and SQLite with scrip
 OpenRig is a coordination layer for a trusted environment: it should help agents and people keep work flowing.
 
 - A change that removes friction, or makes state more truthful, is usually welcome.
+- OpenRig runs on agents working in context with tools. Before adding code for a behaviour, ask whether an agent with
+  the right instructions and today's commands could do it. A skill or a page of guidance is often the better change.
+  - Where to look: the capability map above, and the `agent-operated-workflows` skill, which ships in the
+    `openrig-core` plugin (`packages/daemon/assets/plugins/openrig-core/skills/agent-operated-workflows/SKILL.md`).
 - A change that adds a refusal, a prompt or a required step needs the concrete case in CONTRIBUTING.md: who is
   harmed, how, and what it costs everyone else.
 - One concern per pull request. Keep the diff reviewable in one sitting.

rigs/workshop/agents/workshop/skills/openrig-skills/SKILL.md

@@ -72,7 +72,7 @@ These are auto-delivered to every rig; their name+description are already in you
 These ship in the OpenRig repo and reach a seat when its profile selects them. To use one, select it in your profile's `uses.skills`, or open it directly at `packages/daemon/specs/agents/shared/skills/core/<skill>/SKILL.md`.
 
 - **openrig-software-factory** — a user wants continuing reviewed work: manual/team, queue-only orchestration or an explicit Workflow; add one or two seats to the running starter when useful, with context, ownership, concurrency, spend and permission limits. Load `rig context get skills/core/openrig-software-factory/SKILL.md`.
-- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `openrig-builder`).
+- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `developing-openrig`).
 - **openrig-cmux** — driving the `cmux` terminal provider.
 - **openrig-herdr** — opening/managing seat terminals via the default proof-gated provider.
 - **agent-startup-and-context-ingestion** — a seat is booting and ingesting its startup context.

rigs/workshop/bundle.yaml

@@ -14,6 +14,6 @@ preconditions:
   - name: Open a shell at the root of your clone of the repository you want to work on, set up the way its README says. Optionally add OpenRig's public context pack, then run the install from that same shell.
     commands:
       - rig context add --git https://github.com/mvschwarz/openrig-world
-  - name: "Keep OpenRig's files out of your commits: from the root of your clone, add CLAUDE.local.md, AGENTS.md, /.openrig/ and .claude/settings.local.json to .git/info/exclude (the README has the command). The lead adds any that are missing when it starts."
-  - name: "If you ask Claude Code to do this setup for you, plan to run two steps yourself. In OpenRig's test on macOS with Claude Code 2.1.289, its default auto mode declined adding a permission rule for itself ([Self-Modification]), so add any rule yourself with /permissions or in .claude/settings.local.json; and rig context add --git ([Untrusted Code Integration]), even with an allow rule for that command, so run it yourself."
+  - name: "Keep OpenRig's files out of your commits: from the root of your clone, add CLAUDE.local.md, AGENTS.md, /.openrig/, .claude/settings.local.json and gate-lane-verdict.json to .git/info/exclude (the README has the command). The lead adds any that are missing when it starts."
+  - name: "If you ask Claude Code to do this setup for you, plan to run some steps yourself. In OpenRig's tests on macOS, Claude Code's default auto mode declined the rig up line ([Create Unsafe Agents], because it starts new agents) on 2.1.289 and 2.1.290, and in an earlier 2.1.289 run also declined adding a permission rule for itself ([Self-Modification]; add any rule yourself with /permissions or in .claude/settings.local.json) and rig context add --git ([Untrusted Code Integration]), even with an allow rule for that command. Run rig context add --git and rig up yourself in a terminal, from the root of your clone."
   - name: "Before your first install on a machine, run claude --dangerously-skip-permissions once in your clone, accept its prompts (including Claude Code's bypass warning), then type /exit. Claude Code remembers it, so the seats start without stopping."