docs(operator): reuse a permission choice only where it covers the goal

The operator's guidance reused any permission choice carried in the
handoff, whatever it covered. A user-wide rule for rig commands could
then skip the one project offer for the goal's git and test commands,
which the person never allowed. A carried choice now counts only when
it covers the commands this goal repeats in this project. Keeping
prompts on covers them all. Otherwise the operator makes the one offer
for the commands the choice leaves out.

A kernel seat's prompt is answered in the kernel's view, not in the
team's space, and the guidance now says where.

CHANGELOG.md

@@ -13,12 +13,13 @@ deprecations, and behavioral changes. Breaking changes are called out explicitly
 OpenRig 0.7.12 is a patch for people running their own agent teams, cut from
 main `16e8b7fb`. When you answer your team, by typing, clicking or qualifying
 an answer, the answer now goes to an agent that reads it with the question and
-decides. Answers go to the configured receiving agent or kernel operator when
-available; otherwise they wait. Setup offers to register you as the team's
-person. `rig down` no longer stops a terminal it
+decides. When no receiving agent is available, your answer waits. Setup's
+guidance asks your agent to offer to register you as the team's person, and
+registering works when you ask for it. `rig down` no longer stops a terminal it
 can't show belongs to the seat. There are fixes across delivery, Codex,
 restore, the queue, Slack and speed, many contributed by people using
-OpenRig. Two repairs aren't in this release: see Known limits.
+OpenRig. Two repairs aren't in this release, and some checks weren't run: see
+Known limits.
 
 ### Before you upgrade
 
@@ -26,7 +27,8 @@ OpenRig. Two repairs aren't in this release: see Known limits.
   seat's own `OPENRIG_NODE_ID`, on the server and session it read. A terminal
   OpenRig didn't create, a mismarked one or a replaced one is left running, and
   `rig down` exits 2 naming it and how to stop it yourself. A seat joined with
-  `rig attach --self` is in that group. ([#2962](https://github.com/mvschwarz/openrig/pull/2962))
+  `rig attach` as an external CLI is listed as not stopped, since OpenRig never
+  stops it; that alone doesn't make `rig down` exit 2. ([#2962](https://github.com/mvschwarz/openrig/pull/2962))
 - **openrig-core is 0.1.28.** A Codex session kept running across the upgrade
   can ask for hook approval until it's relaunched.
 
@@ -34,15 +36,29 @@ OpenRig. Two repairs aren't in this release: see Known limits.
 
 - Answers nothing else reads, such as a host pairing request or a mode's
   scheduled end, use the configured receiving agent or the kernel operator.
-  Answers wait when no receiver is available. ([#2923](https://github.com/mvschwarz/openrig/pull/2923))
+  Answers wait when no receiver is available, and nothing decides them
+  meanwhile. To decide one yourself, use its own command: `rig host approve` or
+  `rig host deny` for a pairing request, `rig seat decide-permission` for a
+  runner's request. Closing an ask isn't permission, and words that were kept
+  aren't a default permit. ([#2923](https://github.com/mvschwarz/openrig/pull/2923))
 - Pairing answers go to the receiving agent, and you can decide directly in the
   TUI's pairing settings. A pairing request says who it went to and who reads
   the answer. ([#2931](https://github.com/mvschwarz/openrig/pull/2931), [#2935](https://github.com/mvschwarz/openrig/pull/2935))
 - A runner's permission answer goes to the receiving agent, which decides while
   the runner waits, so a qualified answer such as "only if it's the test file"
-  is read before anything acts. ([#2934](https://github.com/mvschwarz/openrig/pull/2934), [#2938](https://github.com/mvschwarz/openrig/pull/2938), [#2950](https://github.com/mvschwarz/openrig/pull/2950), [#2966](https://github.com/mvschwarz/openrig/pull/2966))
-- Setup offers to register you as the team's person, and the empty-registry
-  hint is right. A team you start from your own assistant fits your own logins,
+  is read before anything acts. Your answer is kept and an explicit decision
+  works, but the runner's confirmation updates to you aren't written in this
+  release. Don't expect a confirmation in the Feed, a notice of the receiver's
+  state or an immediate wake: the decision reaches the runner at its next read
+  (up to about 21 seconds in testing). To decide one yourself:
+  `rig seat decide-permission <askId> --option <id> --reason "…"`. This is the
+  runner's path only: a pairing request says who reads the answer, as above. ([#2934](https://github.com/mvschwarz/openrig/pull/2934), [#2938](https://github.com/mvschwarz/openrig/pull/2938), [#2950](https://github.com/mvschwarz/openrig/pull/2950), [#2966](https://github.com/mvschwarz/openrig/pull/2966))
+- Setup's guidance asks your agent to offer to register you as the team's
+  person. In testing the agent didn't reliably make that offer (0 of 5 runs).
+  Registering works when you ask for it: `rig gateway human add`. Nothing is
+  registered without your yes, an existing default person is kept, and no person
+  is chosen automatically. The empty-registry hint is right. A team you start
+  from your own assistant fits your own logins,
   with a review before anything is committed. ([#2924](https://github.com/mvschwarz/openrig/pull/2924), [#2905](https://github.com/mvschwarz/openrig/pull/2905))
 
 ### Harnesses and connections
@@ -80,8 +96,9 @@ OpenRig. Two repairs aren't in this release: see Known limits.
 
 - **Delivery and drafts:** Claude seats with a custom status line read idle and
   verify sends; a fresh idle hook doesn't type into a current Claude dialog;
-  Claude's context hint and drawn cursor are read correctly; a deliberate
-  override is delivered when the input can't be read; update notices beside the
+  Claude's context hint and drawn cursor are read correctly; when the input
+  can't be read, a deliberate override (`--dangerously-interact`) pastes with a
+  warning and doesn't press Enter, so it isn't submitted; update notices beside the
   paste hint are recognized. ([#2807](https://github.com/mvschwarz/openrig/pull/2807), [#2813](https://github.com/mvschwarz/openrig/pull/2813), [#2947](https://github.com/mvschwarz/openrig/pull/2947), [#2942](https://github.com/mvschwarz/openrig/pull/2942), [#2933](https://github.com/mvschwarz/openrig/pull/2933), [#2800](https://github.com/mvschwarz/openrig/pull/2800), [#2786](https://github.com/mvschwarz/openrig/pull/2786))
 - **Codex:** when you answer a Codex choice prompt, a message waiting on it is
   delivered instead of escalated; a working counter is compared only within one pane process; hook
@@ -114,8 +131,9 @@ OpenRig. Two repairs aren't in this release: see Known limits.
   config accepts two keys the daemon already resolves; `rig whoami` says the
   team is still being built during `rig up`; rigs with `@` in the name find
   attention; a seat waiting on a person names its question; the installer
-  reports PATH gaps with shell hints; daemon credentials stay out of the tmux
-  server's environment. ([#2914](https://github.com/mvschwarz/openrig/pull/2914), [#2969](https://github.com/mvschwarz/openrig/pull/2969), [#2955](https://github.com/mvschwarz/openrig/pull/2955), [#2949](https://github.com/mvschwarz/openrig/pull/2949), [#2891](https://github.com/mvschwarz/openrig/pull/2891), [#2888](https://github.com/mvschwarz/openrig/pull/2888), [#2883](https://github.com/mvschwarz/openrig/pull/2883), [#2850](https://github.com/mvschwarz/openrig/pull/2850))
+  reports PATH gaps with shell hints; daemon credentials stay out of a tmux
+  server's environment from its next start (a server already running keeps its
+  old environment until it restarts). ([#2914](https://github.com/mvschwarz/openrig/pull/2914), [#2969](https://github.com/mvschwarz/openrig/pull/2969), [#2955](https://github.com/mvschwarz/openrig/pull/2955), [#2949](https://github.com/mvschwarz/openrig/pull/2949), [#2891](https://github.com/mvschwarz/openrig/pull/2891), [#2888](https://github.com/mvschwarz/openrig/pull/2888), [#2883](https://github.com/mvschwarz/openrig/pull/2883), [#2850](https://github.com/mvschwarz/openrig/pull/2850))
 - **Pi and OMP:** typed edits submit in order on the affected Node releases
   (22.21.x to 22.22.0, 24.9.0 to 24.11.1, 25.0.0 to 25.1.0) instead of appending an
   insertion at the end. ([#2847](https://github.com/mvschwarz/openrig/pull/2847))
@@ -161,17 +179,35 @@ OpenRig. Two repairs aren't in this release: see Known limits.
 - **Custom blocker IDs** explain the wait, but their progress gives no event
   wake; the timer remains. ([#2983](https://github.com/mvschwarz/openrig/pull/2983))
 - **Delivery evidence** records what was known, not that the agent read the
-  message; where the input ended up can read unknown. ([#2937](https://github.com/mvschwarz/openrig/pull/2937), [#2943](https://github.com/mvschwarz/openrig/pull/2943))
-- **Runner permission answers:** when a person answers a runner's permission
-  request, the answer is kept, and an explicit decision works. In 0.7.12 the
-  runner's confirmation updates fail to record, so no receipt or Feed
-  confirmation appears, and the decision can reach the runner on its next read
-  rather than at once (up to about 21 seconds in our test). To settle a request
-  directly, run `rig seat decide-permission <request> --option <id>`. Pairing
-  answers are separate, and their receipts are kept. Tested on one native daemon
-  with the TUI and a runner driven by a stand-in agent. ([#2934](https://github.com/mvschwarz/openrig/pull/2934))
+  message; where the input ended up can read unknown. Events are best effort, so
+  a missing event isn't proof nothing was sent. ([#2937](https://github.com/mvschwarz/openrig/pull/2937), [#2943](https://github.com/mvschwarz/openrig/pull/2943))
+- **Runner permission answers** were run end to end with a real receiving
+  agent and the example runner, whose requesting agent was a stand-in; a
+  model-driven runner waiting on a person's answer hasn't been run. ([#2934](https://github.com/mvschwarz/openrig/pull/2934))
 - **herdr-app views** are one-shot; following isn't claimed. **Pull relay**
   needs a connector that implements pull. ([#2744](https://github.com/mvschwarz/openrig/pull/2744), [#2844](https://github.com/mvschwarz/openrig/pull/2844))
+- **A receiving agent you choose** (`agents.operator_session`) that runs in an
+  explicit or auto permission mode gets no OpenRig allowance for
+  `rig host approve` or `rig host deny`, so Claude's review can refuse them. A
+  kernel receiver in auto mode is included. The default kernel with the default
+  policy passed at its tested scope.
+- **A receiver that was stopped and then started** may not act on an answer that
+  waited for it. In the tested case where it needed to ask you something back,
+  the question appeared in its own conversation, not in the Feed or Steering.
+- **Delivery isn't fixed in general:** a footer row OpenRig doesn't recognize can
+  still hold a delivery ([#2925](https://github.com/mvschwarz/openrig/issues/2925)), and a held message's full envelope can stay held;
+  clearing a draft doesn't deliver it ([#2515](https://github.com/mvschwarz/openrig/pull/2515)).
+- **Not run for this release** (not run, not passed): the two-seat Codex journey
+  with `AGENTS.md` restore; Codex account-home, upgrade and continuity checks;
+  the OpenShell worker's second report; Pi model switches on real providers; ACP
+  in a desktop app; Slack directory paging; some Slack setup cases (channel and
+  thread precedence, a stopped receiver's delayed pickup, an inherited inbound
+  default, a plain yes with no receiver); native checks of [#2786](https://github.com/mvschwarz/openrig/pull/2786), [#2799](https://github.com/mvschwarz/openrig/pull/2799), [#2807](https://github.com/mvschwarz/openrig/pull/2807)
+  and [#2813](https://github.com/mvschwarz/openrig/pull/2813), with [#2947](https://github.com/mvschwarz/openrig/pull/2947) partly; a button-and-words answer, a non-pairing ask
+  with an explicit owner, Steering's Approve page, and these answer and setup
+  checks on a default model (the tested runs used smaller models);
+  `--wait-for-kernel` ([#2888](https://github.com/mvschwarz/openrig/pull/2888)), the installed effect of [#2800](https://github.com/mvschwarz/openrig/pull/2800), and [#2720](https://github.com/mvschwarz/openrig/issues/2720) beyond one
+  platform.
 - **From 0.7.11:** its known limits below still apply, except Codex hook setup
   with smol-toml 1.9.x ([#2720](https://github.com/mvschwarz/openrig/issues/2720)), fixed by [#2804](https://github.com/mvschwarz/openrig/pull/2804). 0.7.12 changes openrig-core
   again, so the Codex hook note there applies to this upgrade too. They weren't

packages/daemon/assets/skills/rigs/SKILL.md

@@ -166,7 +166,7 @@ person needs in their project or home folder and name that path.
   (never the logical ID or a guessed name) and send:
   `rig send <canonicalSessionName> 'This is the agent that installed OpenRig. The person will answer in your pane. Goal: <goal>. Project folder: <absolute path>. Branch: <branch>.'`
   If the person stays here, replace "The person will answer in your pane" with "The person stays with me; send me your questions and
-  results to relay." Carry their constraints and any declined permission choices in either handoff.
+  results to relay." Carry their constraints and any permission choice they made, chosen or declined, in either handoff.
   Or the person types the goal and folder in the operator's pane. If they give you a goal later, forward it the same
   way. The operator helps them pick a team that fits their logins, starts it (`rig up`) only on their yes to the plan it
   shows, and gives the goal to the team's lead. Before that yes, it says what launching into their folder changes for their own agent there; relay
@@ -190,7 +190,7 @@ person needs in their project or home folder and name that path.
   (`--dry-run` first). If it isn't, or you can't tell, say so and offer their choices: sign in to Claude Code, or give the
   seat a model their account can run with `rig seat set-model`, then start it again with
   `rig seat launch <seat> --fresh --stop --reason "…"` and check the model it reports. Either way the operator starts a
-  new conversation without your handoff, so send it again: the goal, folder, branch, constraints and declined choices.
+  new conversation without your handoff, so send it again: the goal, folder, branch, constraints and permission choices.
 - **Installation is finished** when the operator is ready and the person is talking to it; a healthy daemon alone isn't
   that. If they'd rather talk later, keep that choice, leave them the exact connection step and say the handoff to the
   operator is still pending.
@@ -207,6 +207,9 @@ person needs in their project or home folder and name that path.
   whole action, answer only when it's clearly inside what they said, and tell them you answered under that instruction,
   not that they said yes. Bring anything unclear or outside it back to them; a command's name or a path that looks like
   their project doesn't show what the action touches. Their instruction changes no permission setting.
+  Don't send them to a bare `tmux attach` to answer: relay their choice this way, or point them to that seat in the
+  team's terminals the operator opened. If they want fewer prompts, the operator offers once to allow the commands
+  that keep asking, for their project only (`applying-a-permission-policy`); tell it what they chose.
   Another kind of menu you can answer with
   the key that screen shows, or ask the person. Capture it again before sending anything more.
 - **Replies:** in a plain shell, other agents can't type into this session. Read work sent to you with

packages/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md

@@ -119,7 +119,8 @@ configurations, as below; do not take the pin from a cached page summary.
    from the installing agent; do not ask for them again. If the goal is missing,
    ask once: "What would you like to build or change?" If they already named a
    team, use it and skip the questions it answers. Keep any choice the
-   handoff carries, such as a trust or hook-review prompt they declined.
+   handoff carries, such as a trust or hook-review prompt they declined or
+   a permission choice they made.
 2. **Where it works.** If the folder is missing, 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: the workspace's `kernel` folder (on an older
@@ -249,11 +250,33 @@ configurations, as below; do not take the pin from a cached page summary.
    separates project files, not that Codex home. `rig setup` lists these writes. If they'd rather keep
    their folder as it is, offer a separate copy, such as a git worktree.
    If the plan declares non-interruptive or broad access, say so plainly before asking for their yes.
-   If they keep permission prompts on, say what that will be like before
-   their yes: each seat stops and asks before an action its permissions
-   don't already cover, the asks come often, especially early, and each one
-   needs their answer, in the seat's pane or through you. Their yes starts
-   the team; it isn't a yes to those later asks.
+   Before their yes, explain the team's permission defaults. Claude's team
+   default adds allowances for ordinary `rig` commands, project reads and
+   common tests. Branches, commits, running their program, installs and other
+   shell commands may ask, depending on existing native rules. A Codex seat
+   uses its configured writable roots and may ask for broader access. When a
+   prompt appears, they can answer in that seat's terminal or through you.
+   Their own agent's mode isn't the team's; existing user and project rules
+   can still affect the seats. Their yes starts the team; it isn't a yes to
+   later prompts.
+   - **A permission choice already made** (in the handoff or to you: fewer
+     prompts for this project, a mode, a rule, or keep prompts on): use it,
+     and don't ask again, when it covers the commands this goal will repeat
+     in this project. Keeping prompts on covers them all. A choice for other
+     commands or another scope, such as a user-wide rule for `rig` commands,
+     doesn't: make the one offer below for the commands it leaves out.
+   - **Otherwise, one offer if they want fewer interruptions:** name the
+     command families this goal will repeat in their folder (for example
+     `git switch`, `git add`, `git commit` and the project's test command)
+     and offer to allow just those, for this project only. For Claude seats
+     that's allow rules in the project's `.claude/settings.local.json`,
+     normally loaded by Claude sessions in that folder, including their own,
+     under the default setting sources; for a Codex seat, follow the same
+     skill's Codex rules. On their yes, apply it with
+     `applying-a-permission-policy`. Say what still asks: a command joined
+     with `&&`, `;` or a pipe asks unless every part is allowed, and on Claude
+     seats OpenRig's lifecycle commands still ask. On a no, keep the team
+     default and don't offer again.
    For a team that already exists, `rig seat status <seat>` shows each seat's
    planned permissions: the native mode, where it comes from, what OpenRig
    adds and what isn't known. Read it to them as planned, not observed.
@@ -339,10 +362,16 @@ configurations, as below; do not take the pin from a cached page summary.
     names. Tell them it's a usage limit, which seat, and when it resets, with
     the menu's choices in its own words. One of them may spend usage credits,
     so the choice is theirs.
-    When you see one, tell them where they already are: which seat, what its
-    prompt asks (`rig capture <session>` with the seat's
-    `canonicalSessionName` shows it) and the seat's `tmuxAttachCommand`, or
-    just its name if it has none. Don't answer another seat's prompt yourself.
+    When you see one, tell them where it is and where they can answer: which
+    seat, what its prompt asks (`rig capture <session>` with the seat's
+    `canonicalSessionName` shows it), and that seat's terminal, or through
+    you. A team seat's terminal is in the team's space from step 8. A kernel
+    seat's is in the kernel's view (`rig terminal open saved:kernel --window`;
+    the advisor has its own tab or window). Only when no space is open, give the
+    seat's `tmuxAttachCommand` as a command for a new terminal, with one
+    line on what it does (it shows that seat; closing the window leaves the
+    seat running), or just its name if it has none. Never send them to a
+    bare `tmux attach`. Don't answer another seat's prompt yourself.
     With prompts on, several seats may wait at once. Gather them, then tell
     the person in one message, one line per prompt: the seat, the exact
     action it asks to take (the command or file), and the choices the prompt
@@ -366,12 +395,14 @@ configurations, as below; do not take the pin from a cached page summary.
     and check the result before sending anything more; never resend an answer
     whose effect you can't see. Otherwise they answer in the seat's pane.
     Grouping can shorten the asking, not the number of prompts. If they find
-    the prompts too many, lay out their choices without picking one: keep
-    prompts on; take a prompt's own standing approval for one command when it
-    offers one; or change the team's permissions deliberately, as a separate
-    choice (`applying-a-permission-policy`, `rig seat set-permissions` for
-    later launches, or Workshop's broad-access bundle). An answer to a prompt
-    never changes a permission mode.
+    the prompts too many and haven't already chosen, make step 6's one offer,
+    named from the commands that actually asked: allow those command families
+    for this project, applied on their yes with `applying-a-permission-policy`,
+    which says how to check it took effect in the seats. Their other choices
+    stay open: keep prompts on; take a prompt's own standing approval for one
+    command when it offers one; `rig seat set-permissions` for later launches;
+    or Workshop's broad-access bundle. An answer to a prompt never changes a
+    permission mode.
 
 Avoid these:
 - launching a team without the person's yes;

skills/rigs/SKILL.md

@@ -166,7 +166,7 @@ person needs in their project or home folder and name that path.
   (never the logical ID or a guessed name) and send:
   `rig send <canonicalSessionName> 'This is the agent that installed OpenRig. The person will answer in your pane. Goal: <goal>. Project folder: <absolute path>. Branch: <branch>.'`
   If the person stays here, replace "The person will answer in your pane" with "The person stays with me; send me your questions and
-  results to relay." Carry their constraints and any declined permission choices in either handoff.
+  results to relay." Carry their constraints and any permission choice they made, chosen or declined, in either handoff.
   Or the person types the goal and folder in the operator's pane. If they give you a goal later, forward it the same
   way. The operator helps them pick a team that fits their logins, starts it (`rig up`) only on their yes to the plan it
   shows, and gives the goal to the team's lead. Before that yes, it says what launching into their folder changes for their own agent there; relay
@@ -190,7 +190,7 @@ person needs in their project or home folder and name that path.
   (`--dry-run` first). If it isn't, or you can't tell, say so and offer their choices: sign in to Claude Code, or give the
   seat a model their account can run with `rig seat set-model`, then start it again with
   `rig seat launch <seat> --fresh --stop --reason "…"` and check the model it reports. Either way the operator starts a
-  new conversation without your handoff, so send it again: the goal, folder, branch, constraints and declined choices.
+  new conversation without your handoff, so send it again: the goal, folder, branch, constraints and permission choices.
 - **Installation is finished** when the operator is ready and the person is talking to it; a healthy daemon alone isn't
   that. If they'd rather talk later, keep that choice, leave them the exact connection step and say the handoff to the
   operator is still pending.
@@ -207,6 +207,9 @@ person needs in their project or home folder and name that path.
   whole action, answer only when it's clearly inside what they said, and tell them you answered under that instruction,
   not that they said yes. Bring anything unclear or outside it back to them; a command's name or a path that looks like
   their project doesn't show what the action touches. Their instruction changes no permission setting.
+  Don't send them to a bare `tmux attach` to answer: relay their choice this way, or point them to that seat in the
+  team's terminals the operator opened. If they want fewer prompts, the operator offers once to allow the commands
+  that keep asking, for their project only (`applying-a-permission-policy`); tell it what they chose.
   Another kind of menu you can answer with
   the key that screen shows, or ask the person. Capture it again before sending anything more.
 - **Replies:** in a plain shell, other agents can't type into this session. Read work sent to you with