docs: Record the Auto approval level, the requested-scope start, and the first-release npm-package step (#3, #5, #6)

LAZURIO.md

@@ -55,9 +55,13 @@ turn stays byte-identical to upstream.
   Import, or `POST /api/teams/import`) and point
   `OMB_GITHUB_INTAKE_BOT` at the leader. Another persona (Pablo) imports the
   same file and renames the leader; nothing in the instructions names the
-  persona. Imported bots start on Ask, so unattended work waits for
-  approvals in the app: which approval level a headless team may run on is
-  an open security decision of DEV-6632, not part of this overlay.
+  persona. Imported bots start on Ask, which would leave unattended work
+  waiting for an approval nobody gives. Steward teams run on **Auto**
+  (Organization Admin decision, issue #3): right after the import the
+  operator sets all four bots to Auto in the app. The provider's own review
+  then approves routine actions and anything else still asks. Full and
+  Custom stay desktop-only, as upstream; the overlay adds no way to raise a
+  bot above Auto.
 
 How to release, rebuild on a new upstream tag, what the overlay contains and
 how Machines consume a release:

docs/lazurio-github-intake.md

@@ -28,17 +28,23 @@ the server behaves exactly as upstream OpenMausBot.
 | `OMB_GITHUB_INTAKE_GH` | The `gh` executable; default `gh` on `PATH`. |
 
 An unknown value stops the server at start with the reason. Example for a
-Lazurio Environment whose persona reviews one Organization:
+new Lazurio Environment whose persona reviews one Organization:
 
 ```sh
 OMB_GITHUB_INTAKE=1 \
 OMB_GITHUB_INTAKE_BOT=Henry \
-OMB_GITHUB_INTAKE_SCOPE=organization \
 OMB_GITHUB_INTAKE_OWNERS=acme \
-OMB_GITHUB_INTAKE_EXCLUDE='acme/infra,acme/productionspace-*' \
 openmausbot serve
 ```
 
+**Start with `requested`** (Organization Admin decision, issue #5). A new
+Environment keeps the default scope and reviews only pull requests that
+request the account. `organization` is a later, deliberate switch: its first
+poll finds every open ready pull request the account can push to and queues
+a review for each, a wave of reviews and model cost. When switching, set
+`OMB_GITHUB_INTAKE_EXCLUDE` as well, for example
+`acme/infra,acme/productionspace-*`.
+
 **Identity.** The intake runs `gh api` as the server's user and has no token
 of its own. Sign that user in once (`gh auth login`); every GitHub action of
 the intake and of the bots is then that account's. If `gh` is missing or not
@@ -176,4 +182,6 @@ changes of state, deliveries, own pull requests and ignored instructions.
   account write only where it should review and publish; branch rules stay
   the enforcement, the team's standing instructions the process.
 - **Approval levels are unchanged.** Unattended bots run with their own
-  approval level; headless full access is a separate decision.
+  approval level. Steward teams run on Auto (issue #3): the operator sets it
+  after the import, the provider's review approves routine actions and
+  anything else waits for the operator. Headless Full access does not exist.

docs/operations/lazurio-fork-release.md

@@ -132,7 +132,8 @@ are stamped only at build time by `scripts/lazurio-release-archive.sh` and
 never committed.
 
 Deliberately not in the overlay (DEV-6632 M2 and later): approval levels
-(`full` and `custom` stay desktop-only, as upstream), the Environment preset
+(`full` and `custom` stay desktop-only, as upstream; Steward teams run on
+`auto`, set by the operator after the import, issue #3), the Environment preset
 that installs and configures the Steward team, and any UI change.
 
 ## When to release
@@ -242,7 +243,7 @@ Organization Admin can do these steps; the order matters.
    `prevent_self_review`, deployments from `main` only, variable
    `LAZURIO_OPENMAUSBOT_RELEASE_CONTROL=reviewed-v1`, variable
    `LAZURIO_RELEASE_APP_ID`, secret `LAZURIO_RELEASE_APP_PRIVATE_KEY`.
-8. **First release** `0.1.91-lazurio.1`, dispatched by the Steward. Right after it, disable `npm-package.yml`, which the release registers (Automation boundary). `sync-published-release.yml` stays latent; see Automation boundary.
+8. **First release** `0.1.91-lazurio.1`, dispatched by the Steward. Right after it, cancel the `npm-package.yml` run its tag starts and disable the workflow (Automation boundary). Done on 2026-09-30. `sync-published-release.yml` stays latent; see Automation boundary.
 
 ## Testing before a release
 
@@ -384,8 +385,11 @@ npm does not trust this repository for `openmausbot`, and the mirror needs
 `RELEASES_PAT`, which the fork does not have.
 
 - `npm-package.yml` (tag `v*`) registers with the first release. The release
-  App creates the tag, and App-created tags start workflows. Right after the
-  first release, run the disable command above.
+  App creates the tag, and App-created tags start workflows, so its first run
+  starts on that tag. Right after the first release, cancel that run and run
+  the disable command above. On `0.1.91-lazurio.1` (2026-09-30) the run was
+  cancelled before it built anything, and the workflow is now disabled;
+  later releases do not start it.
 - `sync-published-release.yml` (release published) does **not** register with
   our releases. The release workflow publishes with `GITHUB_TOKEN`, and
   GitHub starts no workflow for events that token causes. It stays latent until