[immakermatty]

Why

Upstream decision 0169 adds a fourth kind of Environment next to the three of 0165: Automated. An Organization's automated work is done by a bot team of its persona in Lazurio MausBot (Lazurio's fork of OpenMausBot). The Environment is an Organization work VM with one responsible operator (an Owner or Admin). Its GitHub identity is the persona's own machine GitHub user account, not the operator's account and not Lazurio for GitHub. This PR is the Platform part of milestone M2 of plan DEV-6632: the workspace preset for that Environment.

Target state

hosted-organization-steward, a fifth preset that follows the naming of the other three hosted presets:

Machine kind	workspace-vm
Operator / Principal	the one responsible operator (Owner or Admin); only the operator uses SSH, for service interventions; colleagues work with the persona through GitHub
Personalspace	never; Organization repositories are mounted under organizations/<org>/ as on the other Organization presets
Provider identity	new persona-account: the persona's own machine account, signed in to gh by the operator, who holds its 2FA and recovery codes
Surfaces	launchpad, hosted-entry (already carries T3 Code), new openmausbot
Supervision	OS service manager
Bot team (new field botTeam, null on every other preset)	OMB_DEFAULT_BOT_CWD = the Lazurio Folder; the team is lazurio/teams/steward.openmaus.json from the installed release; the GitHub intake is on for the team leader, with scope organization, owners = the handover's Organization, and the Organization's infra and productionspace repositories excluded

The preset only declares the bot-team values. The service that installs and runs Lazurio MausBot applies them (a Machines workload today), and Platform applies none of them. The Folder renders them in two places: a short "Persona bot team" section in AGENTS.md and a settings table in manual/this-machine.md. Those sections also state the identity rule and the publication rule: publish only a PR assigned to the persona with an explicit /lazurio publish instruction, and a person approves the persona's own PRs.

Deriving the kind. It comes from a typed handover value, never from names. The value is a third owner.assignment kind, {kind: "automation", github_login, github_id}, which names the responsible operator exactly the way operator does. A stored binding accepts it (githubLogin, githubId) and derives the Steward preset. Any other shape still fails closed.

The vendored handover schema is not changed locally (F10 rules that out). So until Machines adds the value and Platform re-pins, a handover that declares it is refused whole (machine-context-invalid), and the operator picks the preset explicitly with folder-init --preset hosted-organization-steward. That lets the M3 pilot run on today's work-VM handovers without waiting for Machines.

Allow-list. Every workspace-vm now allows all three Organization presets, the same kind-only rule F10 already uses. I rejected the alternative of allowing Steward only on an automation handover, for two reasons:

• Nothing could choose the preset before Machines ships the value.
• A VM re-assigned from team to automation could not reach Steward through the change path, because the recorded binding would refuse it.

A test covers the re-assignment path: refresh reports preset-derivation-changed, then profile-update --preset hosted-organization-steward, then refresh succeeds.

What does not change

• For every handover that exists today, the derivation, the recorded state and the rendered bytes are identical. All 37 existing snapshots pass unchanged (the snapshot diff only adds lines), and the template revision stays base-instructions-13. Existing Folders therefore see no re-render and no drift.
• The one visible change for existing work VMs: the allow-list (the preset-ambiguous output, /api/profile, the Launchpad selector) lists a third choice.
• The vendored schema and its provenance are untouched, and so is the src/machine/binding.ts projection. persona-account does not trigger the Team gate (githubActionRefused), so gh sign-in and SSH key linking stay offered.
• Launchpad code and routes are unchanged except one label (Automated / Automatizovaný). Without it the new option would appear under the generic "Workspace preset" label.

Two small consumers follow the new assignment kind:

• src/recover/private-values.ts now withholds the responsible operator from recovery evidence, as it already does for an assigned operator. Without this change the login would have leaked into a recovery issue.
• The Launchpad's This Machine view shows the operator the same way it shows an assigned operator (no code change there).

Wording (issue #99). Every user-facing string this PR adds says "Environment" / "Remote Environment", never Machine, Mašina, VM or server. That covers the Folder text in cs and en, the Launchpad label and the gh instruction in docs/environment-tools.md. Czech uses the masculine form ("Automatizovaný Environment"). The persona's account is called "a bot account". Identifiers, keys and command names keep machine, and pre-existing lines are untouched. A test keeps the preset's added sections free of those words.

Verification

Tests were written first on the real consumers: preset data, binding, folder-init, refresh, rendering and the gh gate. Before the implementation, all five targeted files failed on Invalid Machine assignment. After it:

• bun run check (lint, typecheck, bun test, check:public, build:proof, smoke:proof) on HEAD 07512b1 (base a9e195f): exit 0; 1065 pass, 7 skip, 0 fail, 42 snapshots (37 match main exactly, plus 5 new steward snapshots; the snapshot diff against main adds lines only).
• New or extended tests:
  • the whole Steward composition, and the four earlier presets checked field by field;
  • the derivation table, with automation both with and without owner.team;
  • fail-closed refusal of every other assignment shape;
  • the vendored schema refusing automation today;
  • folder-init: derived on the automation binding, explicit on today's operator and Team handovers, refused on a personal VM and on a used personalspace/;
  • refresh after a re-assignment;
  • the gh gate for every preset;
  • recovery private values;
  • rendered persona/bot-team lines that appear only on this preset.
• No native run on a real VM yet.

Base, decision and template revision. The PR is rebased on main at a9e195f (after #103). The Platform decision is F27 (docs/decisions.md), with a one-line pointer left in F10.

The Folder template revision stays main's base-instructions-14. The added text renders only under the new preset, which no earlier release can record. So every Folder of the four earlier presets keeps its bytes and recorded digests, and no existing Folder is re-rendered. A bump would rewrite all 37 existing snapshots and re-render every Folder with no change in content. Only the 5 steward snapshots are new; the other snapshot entries match main exactly.

Risks and open questions

1. Machines handover change needed: the automation value in lazurio.machine.v1 plus a Platform re-pin and projection (HumanAndMachine-ai/Machines#273, private). Until then the preset is only an explicit choice.
2. Explicit choices on a Team-assigned VM (both Work and Steward) are allowed by the kind-only allow-list; narrowing them is tracked separately in Narrow explicit Organization preset choices on Team-assigned work VMs (decision 0168) #107 and is not part of this PR.
3. The persona account is not in the handover. The rendered rules say an account other than the persona's is a finding, but Platform cannot compare accounts. Should Machines also carry the persona's github_login / github_id?
4. Team file inside the release archive: tracked in Ship the Steward team file inside the release archive OpenMausBot#4. Until it ships, "import from the installed release" has nothing to import.
5. Who applies the bot-team defaults (the environment of the MausBot unit on an Automated VM) is not decided here. The preset declares them, and the rendered manual tells agents to report any difference to the operator.
6. Which approval level an unattended team may run on is an open security decision of DEV-6632 and stays out of this preset.
7. purpose stays human (a person answers for every Machine per 0169). The vocabulary sweep under 0156 is a separate step.

No release, tag or merge is part of this PR.

🤖 Generated with Claude Code

[agentrozjedemeai]

@immakermatty — APPROVED on exact head 07512b1 (DEV-6632 M2 / F27).

I traced the new preset, typed stored binding and current handover-schema refusal, explicit/derived initialization and reassignment, gh Team gate, recovery-value redaction, and cs/en Folder rendering. On this detached head, the seven targeted files passed (147/147); bun run check passed (1065 pass, 7 skip, 0 fail, 42 snapshots, plus public check, proof build and smoke). GitHub CI succeeded on ubuntu-24.04 and macos-14. git diff --check is clean.

I challenged the unchanged base-instructions-14: all 37 pre-existing snapshot entries are byte-identical to main and only five Steward entries were added; the new rendering is gated by a preset no older release could have recorded, so a global template bump is not warranted.

Scope limits remain explicit, not pilot qualifications: Machines#273 must deliver/re-pin the automation handover; Lazurio/OpenMausBot#4 must ship the team file and its service must apply the declared defaults; LazurioPlatform#107 must close the Team-assignment explicit-preset identity loophole before real Team-VM sign-in is considered safe. The persona account is not checked by Platform, and no native Automated VM run was provided. This review approves the bounded Platform declaration and rendering, not an end-to-end deployment or access change.