[immakermatty]

Motivation

Real Machines are being handed over with /etc/lazurio/lazurio.machine.json, and the Principal decided (2026-09-22) how the Lazurio Folder on them is configured: three hosted workspace presets with exact names, derived from the handover instead of chosen from a free list, an immutable/mutable split in the Launchpad, and folder-init that adopts the Folder real Machines already have instead of demanding an empty layout. Nothing was implemented under the earlier names (hosted-private, hosted-team), so they are renamed without compatibility.

What changes

• Schema re-pin — src/machine/lazurio-machine.v1.schema.json is byte-for-byte Machines v0.12.59 (commit dd0dbfaab4807f197f5f65f102fc74bd22496499): a oneOf with the Organization workspace-VM branch and the new personal-VM branch (machine.kind "personal-vm", owner {kind "principal", github_login, github_id}, host {kind "provider-estate", …}, required tailnet). MachineContext is the union; conformance tests cover both branches and every cross-branch mix.
• Presets as data (src/folder/presets.ts): local, hosted-personal, hosted-organization-personal, hosted-organization-team — name, version 1, fixed axes, communication defaults, Personalspace policy, provider identity mode, surfaces, supervision. Validated as a whole; unknown name/version/combination fails before any mutation.
• Derivation and allow-list: personal-vm → hosted-personal; workspace-vm with owner.team → hosted-organization-team; without → hosted-organization-personal; workstation → local. A personal VM never takes an Organization preset and vice versa. lazurio machine folder-init [--preset] records the derived preset by default and an allowed override as an explicit choice.
• Preferences schema 2: preset reference (name, version, selection: derived|explicit) + immutable Machine binding projected from the handover (null on a workstation) + profile, under the existing revision discipline — the local state a future "set preset reference" typed request needs.
• One change path: CLI profile-preview/profile-update --preset and the Launchpad send {expectedRevision, preset?, profile} to the same preview → apply use case. preset-not-allowed and preset-composition are blocked plans, never writes.
• Adoption: the Folder owns exactly AGENTS.md and .lazurio/; organizations/ and personalspace/ may be non-empty and are never traversed, listed beyond existence, moved or written; launchpad.gen3.json/launchpad.gen3.local.json tolerated by name; any other top-level entry fails closed naming it. Organization presets accept the empty personalspace/ that Machines' workspace_baseline precreates and refuse a used one without deleting anything. Re-run → already-adopted, nothing changed.
• Rendered AGENTS.md: short and factual, from preset + binding + profile — which Machine, whose, who the Principal is here, Personalspace boundary, where Organization repos live, identity mode, how work is done, pointer to Organization AGENTS.md and the Lazurio root rules. A relationships section renders only when the binding carries one.
• Launchpad: "This Machine" shown read-only; preset (from the allow-list) and locale/detail/coordination changeable; access/purpose are no longer controls.
• CLI reporting (found on the native run, fixed here): a group- or world-writable ~/Lazurio, organizations/ or personalspace/ (Ubuntu's default umask 0002) is refused before any mutation as {"kind":"blocked","reason":"folder-directory-shared","entry":…} with exit 2 instead of the generic failure; a wrong machine invocation (--json, duplicate/invalid choice, unknown preset) is a usage error printing the machine help on stderr with exit 2.
• Docs: workspace-presets.md, machine-handover.md (re-pin, adoption, the exact resident command, JSON shapes, the mode 0755/0700 precondition), F10 amended 2026-09-22, acceptance and references renamed, docs/evidence/presets-linux-arm64-2026-09-22.md.

What deliberately does not change

• No Dashboard / typed owner request transport — only the local state that makes it possible.
• No relationships field in the vendored schema (upstream has none); the renderer path exists and is tested with a synthetic binding.
• No persona (decision 0156 sweep pending); the purpose axis keeps its values until that sweep.
• No enforcement of access: a preset records context and grants nothing; provider identity, surfaces and supervision are declared for their owners, not enforced by the preset.
• personalspace/ presence for Organization presets is judged by existence and emptiness only (one opendir read, names never returned) — the minimum that makes the Principal's rule operable on the layout Machines delivers.

Verification

• bun run check at head 41f0461 under a temporary HOME/XDG_*: biome clean, tsc clean, 496 pass / 4 skip / 0 fail (500 tests, 69 files), public-policy guard, proof build and smoke pass. No new dependencies.
• Table-driven tests: derivation/allow-list, whole-composition validation, adoption (used work dirs, legacy files, foreign entries by name, group-writable directories by name, idempotence, personalspace conflict, binding changed, unrecognized state, interruption/resume, concurrency), both handover branches, rendered AGENTS.md snapshots per preset × locale, Launchpad immutable section / preset change / disallowed preset (409), machine usage errors (exit 2 + help).
• Native run done (2026-09-22, fresh Tart clone of Ubuntu 24.04.4 ARM64, CLI compiled from 6481a4c, root-owned fixture handovers of all three kinds): derived presets, explicit allowed override with cs/technical, adoption of non-empty organizations/ + personalspace/ with launchpad.gen3.json present, already-adopted re-run with AGENTS.md byte-identical and personalspace/ untouched, preset-not-allowed, folder-foreign-entry, folder-personalspace-conflict with nothing deleted — verbatim log in docs/evidence/presets-linux-arm64-2026-09-22.md.

Not proven

• A real Machines-delivered VM (the native run used fixture handovers written by hand as root).
• A Launchpad preset change natively on a VM (covered by unit tests only).
• The two CLI reporting fixes on the VM (they landed after the log was taken; covered by unit tests at head).

🤖 Generated with Claude Code

Note

Add hosted workspace presets, Machine binding, and existing-Folder adoption

• Adds a fixed catalog of four workspace presets (local, hosted-personal, hosted-organization-personal, hosted-organization-team) with fixed access/purpose axes, personalspace policy, and provider identity, derived from the typed Machine handover context.
• Bumps FolderPreferences state to schema version 2, adding a validated preset reference and immutable nullable MachineBinding; schema-1 state is now rejected.
• Changes folder initialization from empty-folder-only to adopting an existing delivered Folder, preserving non-empty work directories and tolerated legacy files while refusing foreign entries, symlinks, shared-writable directories, and organization-preset personalspace conflicts.
• Updates instruction rendering to template revision base-instructions-2 with a new InstructionSource (preset + Machine + profile), adds localized Machine sections, and replaces the Launchpad access/purpose controls with machine details and a preset selector.
• Updates the CLI folder-init entrypoint to derive and authorize presets from observed handover, apply preset defaults with optional overrides, and report structured adoption refusals.
• Risk: retireIncompletePreparation in retire-preparation.ts and validatePreparation in validate-preparation.ts pass a two-field preview object missing machine, which the updated previewFolder parser rejects; these calls throw a validation error instead of producing output.

^{Macroscope summarized 41f0461.}

[agentrozjedemeai]

@immakermatty

Exact-head QA: APPROVED

Reviewed SHA: 41f04611f0cbe4791d7f303e90f2ffeecedfbf8b

Evidence:

• The requested decision contract matches the implementation: handover-only derivation, the personal/workstation versus Organization allow-list boundary, explicit Organization-preset selection, and whole-composition validation are enforced in the state and shared profile-change path.
• Folder adoption treats only AGENTS.md and .lazurio/ as owned. The implementation and focused tests preserve existing work in organizations/ and personalspace/, tolerate the two named legacy launchpad files, and refuse foreign, used-Personalspace, symlink, changed-layout and shared-directory cases before mutation.
• Schema 1 preferences are refused; schema 2 stores a validated preset reference, immutable Machine binding and profile. The Launchpad exposes the binding read-only and sends only {expectedRevision, preset?, profile} through preview then apply. Local browser smoke exercised an allowed Organization preset change plus all three communication axes; revision advanced from 1 to 2 while the binding stayed unchanged and access/purpose remained absent from the controls.
• The vendored schema is byte-identical to HumanAndMachine-ai/Machines commit dd0dbfaab4807f197f5f65f102fc74bd22496499; its SHA-256 is 2dc6dd3dd3b62c35e2ece4d6b48f4ea65d6e2f9f838db1e684a7628a9b7e9da1. GitHub Release v0.12.59 targets that same commit.
• Local focused gate: 79 pass / 0 fail across handover, preset, state, change-profile, Launchpad and Machine-context suites. Full bun run check: 496 pass / 4 platform skips / 0 fail; lint, TypeScript, public-policy guard, proof build and proof smoke passed.
• CI was rechecked on this exact SHA: check (ubuntu-24.04) and check (macos-14) are SUCCESS. No active review threads.
• The native Ubuntu ARM64 evidence accurately distinguishes its fixture-handover scope from unproven real-Machines, native-Launchpad and post-log reporting-fix claims.

Conclusion: the requested local preset-model and existing-Folder adoption scope is coherent with F10 and has reproducible exact-head evidence.

[agentrozjedemeai]

P1 — handover recovery přijme nový cizí top-level vstup

resumeInitialization u handoveru ověří pouze zaznamenané identity root / organizations / případně personalspace přes verifyHandoverLayout (src/folder/resume-initialization.ts:102–103, src/folder/handover-layout.ts:129–136). Nevolá však znovu requireAdoptableLayout a tedy před dalším zápisem nevynutí top-level allow-list.

Reprodukce na tomto exact headu:

1. vytvořím validní organizační handover Folder;
2. initializeHandoverFolder přeruším na checkpointu journal;
3. do rootu Folderu zapíšu stray.txt;
4. resumeInitialization vrátí { "kind": "recovered", "revision": 1 }, vytvoří AGENTS.md a stray.txt ponechá.

To odporuje explicitnímu kontraktu, že jakýkoli jiný top-level vstup Folderu initialization zastaví a pojmenuje. Zde recovery dále zapisuje do Folderu, který by fresh handover odmítl.

Prosím doplňte při handover recovery před jakýmkoli doplněním výstupu/archivací stejnou claimed allow-list kontrolu jako při initializaci — s Personalspace policy odvozenou z již validovaných preferences — a kontraktní test pro přerušení po journalu + nově přidaný stray.txt. Očekávání: named foreign-entry, žádný nový AGENTS.md ani jiný recovery zápis.

Lokálně jinak prošlo bun run check, focused handover/recovery 35/35, plná sériová sada 496 pass / 4 explicitní platformní skip / 0 fail a git diff --check; právě proto je třeba přidat chybějící regresní scénář.