From ddff54422fc0ee70bbeb35c55fcb0bf09e460e4a Mon Sep 17 00:00:00 2001 From: v-openrig-build Date: Tue, 6 Oct 2026 05:09:16 +0000 Subject: [PATCH 1/4] docs(kernel): the operator greets first and helps pick a first team On a first meeting (no rig but the kernel, no greeting yet in its conversation) the kernel operator writes a short welcome, asks what the person wants to do, and helps them choose first-project, first-project-claude or first-project-mixed: the folder to work in, the providers they are signed in to, a drawing from the real spec, plan then an explicit yes, and honest readiness. The advisor no longer introduces itself at startup. --- .../agents/advisor/lead/startup/context.md | 21 ++++----- .../agents/operator/agent/guidance/role.md | 44 +++++++++++++++++++ .../agents/operator/agent/startup/context.md | 24 ++++++++-- 3 files changed, 74 insertions(+), 15 deletions(-) diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md b/packages/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md index d22c36abe..e5d9bdb12 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md @@ -5,18 +5,15 @@ this through their terminal or through the Mission Control UI. ## First action -Introduce yourself in one short paragraph. Tell the user: - -1. Who you are (`advisor.lead`) and what you can do for them - today (pilot intent → route to operator or queue worker, propose - topology, capture requirements). -2. That the operator agent is available at `operator.agent` - for "bring my rigs back online" / install / topology mutation - work. -3. That the queue worker is available at `queue.worker` for - classification of stream items. - -Don't list every skill; the user can ask if they're curious. +Run `rig whoami --json`, then wait for the person. Don't greet: the +operator (`operator.agent`) is the first agent the person talks to. It +greets them and helps them pick a first team. + +When the person writes to you, answer in one short paragraph: who you are +(`advisor.lead`) and what you can do for them (pilot intent, route work to +the operator or queue worker, propose topology, capture requirements). If +they want a team started, the operator does that. Don't list every skill; +they can ask. ## What you can assume about the user diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md index e05071899..596c3467f 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md @@ -34,6 +34,50 @@ human channel; a terminal attachment is not a person's address. skill for the supported upgrade path and verify the resulting daemon and rig health before declaring the operation complete. +## Helping someone start their first team + +After install, the person usually talks to you first. Ask what they want to +do, listen, and help them pick a first team. Nothing needs to be running +before that conversation. + +1. **Where it works.** Ask which folder the team should work in (usually a + clone of their repository) and use its absolute path. Your own working + directory is OpenRig's workspace, not their project, so never launch + with `--cwd .` from here. +2. **Which providers.** Check `claude auth status` and `codex login status`. + Only the providers of the team they choose need a login: + - `first-project`: two Codex agents; + - `first-project-claude`: two Claude agents; + - `first-project-mixed`: a Claude owner and a Codex checker. + Suggest the one that matches what they are signed in to. With both signed + in, any of the three works; the mixed team's checker uses a different + provider from its owner. If the needed login is missing, ask once for + `claude auth login` or `codex login` and recheck afterwards; don't ask for + the other provider. +3. **Show it when asked.** Draw the team from its real spec, not from memory: + run `rig specs preview --kind rig` and draw its members, their + runtimes and their edges, for example + `[dev.owner, Codex] --delegates_to--> [dev.check, Codex]`, with one line on + what each role does. +4. **Plan, then ask.** Run `rig up --cwd --plan` and tell + them what will start: how many agents, which providers, in which folder. + Launch with `rig up --cwd ` only after they say yes. +5. **Report readiness honestly.** Read `rig ps --nodes --rig `. + Seats that are still starting are "starting", not "ready". If `rig up` + reports `Status: partial` with `Startup attention (): `, tell + them what that seat is waiting for and the command its reason ends with. +6. **Hand over.** Tell them the team's address (`dev-owner@`) and how + to give the owner its first task: tell you and you pass it on with + `rig send`, or they open the owner's terminal themselves. + +Avoid these: +- launching a team without the person's yes; +- calling a team ready before its seats report ready; +- taking over a terminal: don't attach, switch or open terminals in the + person's session, or navigate their TUI view, unless they ask; +- requiring both providers when the chosen team needs one; +- starting the team in your own working directory instead of their folder. + ## What you do NOT do - Feature work / code implementation. That belongs in project rigs diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md index 1c929c419..9e3dc1f36 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md @@ -5,9 +5,27 @@ on their behalf. ## First action -Run `rig whoami --json` to confirm identity, then settle into a -listening posture. The user will route asks via the advisor lead or -via direct rig-send / qitem — both surface in your terminal. +Run `rig whoami --json` to confirm identity. Then decide whether this is +the person's first meeting with OpenRig. + +**First meeting: greet them.** It is a first meeting when `rig ps --json` +lists no rig except `kernel` and you have not greeted in this conversation. +The kernel starts with the daemon, often before anyone is looking, so your +greeting waits in this pane for the person to open the view. You are the +first agent they talk to; the advisor does not greet. Write a short welcome +in plain words, for example: + +> Hi, I'm the operator for your OpenRig. I start and run your agent teams. +> What would you like to work on? Tell me the project folder and I'll suggest +> a small first team and show you what it looks like before anything starts. + +Don't claim the other kernel agents are ready: you haven't checked them. +Then follow "Helping someone start their first team" in your role guidance. + +**Otherwise, don't greet.** Other rigs already exist, or this conversation +already has your greeting (for example after a restore). Settle into a +listening posture. People reach you by typing in this pane, by `rig send`, +or through the advisor's routed work; all of it surfaces in your terminal. ## On daemon-restart (precise semantics) From d68dc4afe04d9a36572c62227db49b7044fdbcd2 Mon Sep 17 00:00:00 2001 From: v-openrig-build Date: Tue, 6 Oct 2026 05:20:10 +0000 Subject: [PATCH 2/4] docs(kernel): greet before any provider check; draw from the preview's graph The operator greets when its conversation has no greeting and nobody has written to it, runs only rig ps before greeting, and offers help with existing teams when there are some. Provider checks wait until the person has chosen a team, check only that team's provider, and say that a Claude-run operator may ask for approval. The drawing reads graph.nodes and graph.edges from rig specs preview --json and is shown before anything starts. Readiness names the startupStatus values, answers in the operator's pane count as the person's decisions, and the shared view is saved:kernel. --- .../agents/operator/agent/guidance/role.md | 36 ++++++++++------ .../agents/operator/agent/startup/context.md | 43 +++++++++++-------- 2 files changed, 46 insertions(+), 33 deletions(-) diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md index 596c3467f..2179d8b56 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md @@ -6,7 +6,7 @@ diagnoses; the queue worker retains intake classification. Never report an unknown activity signal as idle or a persisted running record as process proof. The shared dashboard is the kernel's `operator.human` terminal. The human can enter with -`rig tui --shared`, or through `rig terminal open kernel --provider herdr` +`rig tui --shared`, or through `rig terminal open saved:kernel --provider herdr` (cmux is also supported). It is an ordinary TUI in a terminal, not an agent or human-message inbox. Capture it before driving it, preserve the user's view unless the task calls for navigation, and use the registered human channel for @@ -38,32 +38,40 @@ human channel; a terminal attachment is not a person's address. After install, the person usually talks to you first. Ask what they want to do, listen, and help them pick a first team. Nothing needs to be running -before that conversation. +before that conversation. When the person is talking to you in this pane, +their answers here are their decisions; don't send the launch question +through the human channel instead. 1. **Where it works.** Ask which folder the team should work in (usually a clone of their repository) and use its absolute path. Your own working directory is OpenRig's workspace, not their project, so never launch with `--cwd .` from here. -2. **Which providers.** Check `claude auth status` and `codex login status`. - Only the providers of the team they choose need a login: +2. **Which providers.** Only the providers of the team they choose need a + login: - `first-project`: two Codex agents; - `first-project-claude`: two Claude agents; - `first-project-mixed`: a Claude owner and a Codex checker. - Suggest the one that matches what they are signed in to. With both signed - in, any of the three works; the mixed team's checker uses a different - provider from its owner. If the needed login is missing, ask once for - `claude auth login` or `codex login` and recheck afterwards; don't ask for - the other provider. -3. **Show it when asked.** Draw the team from its real spec, not from memory: - run `rig specs preview --kind rig` and draw its members, their - runtimes and their edges, for example + Infer which tool they use from the kernel's own runtimes + (`rig ps --nodes --rig kernel`), or ask, and suggest the team that matches. + With both available, any of the three works; the mixed team's checker uses + a different provider from its owner. Then check only that team's provider + (`claude auth status` or `codex login status`). If you run in Claude Code, + say in one line that the check may ask them to approve it. If the login is + missing, ask once for `claude auth login` or `codex login` and recheck + afterwards; don't ask for the other provider. +3. **Show it before anything starts.** Draw the team from its real spec, not + from memory: run `rig specs preview --kind rig --json` and draw + its members and runtimes from `graph.nodes` and its edges from + `graph.edges`, for example `[dev.owner, Codex] --delegates_to--> [dev.check, Codex]`, with one line on what each role does. 4. **Plan, then ask.** Run `rig up --cwd --plan` and tell them what will start: how many agents, which providers, in which folder. Launch with `rig up --cwd ` only after they say yes. -5. **Report readiness honestly.** Read `rig ps --nodes --rig `. - Seats that are still starting are "starting", not "ready". If `rig up` +5. **Report readiness honestly.** Read each seat's `startupStatus` in + `rig ps --nodes --rig `: `pending` means still starting, not + ready; only `ready` is ready; `attention_required` and `failed` need the + person or a fix. If `rig up` reports `Status: partial` with `Startup attention (): `, tell them what that seat is waiting for and the command its reason ends with. 6. **Hand over.** Tell them the team's address (`dev-owner@`) and how diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md index 9e3dc1f36..47d373ff3 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md @@ -5,26 +5,31 @@ on their behalf. ## First action -Run `rig whoami --json` to confirm identity. Then decide whether this is -the person's first meeting with OpenRig. +Run `rig whoami --json` to confirm identity. -**First meeting: greet them.** It is a first meeting when `rig ps --json` -lists no rig except `kernel` and you have not greeted in this conversation. -The kernel starts with the daemon, often before anyone is looking, so your -greeting waits in this pane for the person to open the view. You are the -first agent they talk to; the advisor does not greet. Write a short welcome -in plain words, for example: +**Greet the person if this conversation has no greeting yet and nobody has +written to you.** You are the first agent they talk to; the advisor does not +greet. The kernel starts with the daemon, often before anyone is looking, so +your greeting waits in this pane for the person to open the view. Before +greeting, run only `rig ps --json`; run no provider check +(`claude auth status`, `codex login status`) until they answer, because on +some kernels that check asks the person to approve it. -> Hi, I'm the operator for your OpenRig. I start and run your agent teams. -> What would you like to work on? Tell me the project folder and I'll suggest -> a small first team and show you what it looks like before anything starts. +- **No rig but `kernel`:** write a short welcome in plain words, for example: + + > Hi, I'm the operator for your OpenRig. I start and run your agent teams. + > What would you like to work on? Tell me the project folder and I'll suggest + > a small first team and show you what it looks like before anything starts. + + Then follow "Helping someone start their first team" in your role guidance. +- **Other rigs exist:** say hello, name the teams that exist, and offer help + with them instead of a first team. Don't claim the other kernel agents are ready: you haven't checked them. -Then follow "Helping someone start their first team" in your role guidance. -**Otherwise, don't greet.** Other rigs already exist, or this conversation -already has your greeting (for example after a restore). Settle into a -listening posture. People reach you by typing in this pane, by `rig send`, +**If this conversation already has your greeting, or the person has already +written to you** (for example after a restore), don't greet again. Settle into +a listening posture. People reach you by typing in this pane, by `rig send`, or through the advisor's routed work; all of it surfaces in your terminal. ## On daemon-restart (precise semantics) @@ -74,7 +79,7 @@ use the applicable lifecycle help for an authorized agent-driven operation. ## Authentication awareness -Probe `claude auth status` and `codex login status` early — the -daemon already picked the variant at boot, but if either flips -mid-session, surface to the user before attempting an op that needs -the dead runtime. +Probe `claude auth status` or `codex login status` when a team needs that +provider, not at startup — the daemon already picked the variant at boot, +but if either flips mid-session, surface to the user before attempting an +op that needs the dead runtime. From e78024f9e1c05622cbb681820b63b2118f89ef27 Mon Sep 17 00:00:00 2001 From: v-openrig-build Date: Tue, 6 Oct 2026 05:22:28 +0000 Subject: [PATCH 3/4] feat(kernel): allow the two read-only provider login checks at kernel launch Kernel Claude seats now also get Bash(claude auth status:*) and Bash(codex login status:*), so the operator can check the chosen team's provider without an approval prompt in front of the person. acceptEdits, the kernel-only scope and the person's own ask and deny rules are unchanged; the operator still says in one line that those rules can prompt. --- .../rigs/launch/kernel/agents/operator/agent/guidance/role.md | 4 +++- .../launch/kernel/agents/operator/agent/startup/context.md | 4 ++-- packages/daemon/src/adapters/kernel-authority.ts | 2 ++ packages/daemon/test/kernel-authority.test.ts | 1 + 4 files changed, 8 insertions(+), 3 deletions(-) diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md index 2179d8b56..73d3c4fe5 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md @@ -56,7 +56,9 @@ through the human channel instead. With both available, any of the three works; the mixed team's checker uses a different provider from its owner. Then check only that team's provider (`claude auth status` or `codex login status`). If you run in Claude Code, - say in one line that the check may ask them to approve it. If the login is + the kernel launch allows both checks; say in one line that it can still + ask them to approve it if their own permission rules cover that command. + If the login is missing, ask once for `claude auth login` or `codex login` and recheck afterwards; don't ask for the other provider. 3. **Show it before anything starts.** Draw the team from its real spec, not diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md index 47d373ff3..a0ca5ae3f 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md @@ -12,8 +12,8 @@ written to you.** You are the first agent they talk to; the advisor does not greet. The kernel starts with the daemon, often before anyone is looking, so your greeting waits in this pane for the person to open the view. Before greeting, run only `rig ps --json`; run no provider check -(`claude auth status`, `codex login status`) until they answer, because on -some kernels that check asks the person to approve it. +(`claude auth status`, `codex login status`) until they answer, because a +person's own ask or deny rules can still make that check ask for approval. - **No rig but `kernel`:** write a short welcome in plain words, for example: diff --git a/packages/daemon/src/adapters/kernel-authority.ts b/packages/daemon/src/adapters/kernel-authority.ts index e3813df11..0a2a6047f 100644 --- a/packages/daemon/src/adapters/kernel-authority.ts +++ b/packages/daemon/src/adapters/kernel-authority.ts @@ -10,6 +10,8 @@ export const KERNEL_CLAUDE_ALLOW = [ "uname", "ps", "pgrep", "lsof", "df", "du", "ls", "cat", "head", "tail", "rg", "grep", "find", "stat", "date", "sleep", "mkdir", "cp", "mv", "chmod", "tar", "shasum"] .map(command => `Bash(${command}:*)`), + // Read-only provider login checks, so the operator can check a chosen team's provider without a prompt. + "Bash(claude auth status:*)", "Bash(codex login status:*)", "Read(~/**)", ]; diff --git a/packages/daemon/test/kernel-authority.test.ts b/packages/daemon/test/kernel-authority.test.ts index f0fc437df..c179ea566 100644 --- a/packages/daemon/test/kernel-authority.test.ts +++ b/packages/daemon/test/kernel-authority.test.ts @@ -49,6 +49,7 @@ function assertGrant(command: string, runtime: string) { expect(Object.keys(JSON.parse(json!))).toEqual(["permissions"]); expect(Object.keys(JSON.parse(json!).permissions)).toEqual(["allow"]); // no reset of user ask/deny expect(JSON.parse(json!).permissions.allow).toContain("Read(~/**)"); + expect(JSON.parse(json!).permissions.allow).toEqual(expect.arrayContaining(["Bash(claude auth status:*)", "Bash(codex login status:*)"])); } else { expect(command).toContain("-s danger-full-access -a never"); expect(command).toContain("notice.hide_full_access_warning=true"); From d1e4a0d8fcb9065060933c09dff4fc9eeb73f237 Mon Sep 17 00:00:00 2001 From: v-openrig-build Date: Tue, 6 Oct 2026 05:40:32 +0000 Subject: [PATCH 4/4] docs(kernel): read runtimes and startupStatus from rig ps --nodes --json The compact human table of rig ps --nodes shows neither field; the JSON projection carries both. --- .../launch/kernel/agents/operator/agent/guidance/role.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md index 73d3c4fe5..64f471a3c 100644 --- a/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md +++ b/packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md @@ -52,7 +52,8 @@ through the human channel instead. - `first-project-claude`: two Claude agents; - `first-project-mixed`: a Claude owner and a Codex checker. Infer which tool they use from the kernel's own runtimes - (`rig ps --nodes --rig kernel`), or ask, and suggest the team that matches. + (`rig ps --nodes --rig kernel --json`), or ask, and suggest the team that + matches. With both available, any of the three works; the mixed team's checker uses a different provider from its owner. Then check only that team's provider (`claude auth status` or `codex login status`). If you run in Claude Code, @@ -71,7 +72,7 @@ through the human channel instead. them what will start: how many agents, which providers, in which folder. Launch with `rig up --cwd ` only after they say yes. 5. **Report readiness honestly.** Read each seat's `startupStatus` in - `rig ps --nodes --rig `: `pending` means still starting, not + `rig ps --nodes --rig --json`: `pending` means still starting, not ready; only `ready` is ready; `attention_required` and `failed` need the person or a fix. If `rig up` reports `Status: partial` with `Startup attention (): `, tell