Add a bring-up script and a transcript dump; let nisse-dev install on its own VM (M0.2)

Development Plan M0.2.

- scripts/bringup.sh: start [REF] sets the previous run aside under
  /root/nisse-e2e/runs/, exports the ref under test and starts the agent
  as the transient systemd unit nisse-bringup, so it outlives the shell
  that started it; stop (SIGTERM, clean shutdown), status, logs, and
  collect (the journal log and a readable transcript).
- nisse_dev.dump (python -m nisse_dev.dump STATE_DB [--full]): a readable
  dump of a state store's state, pending intents and canonical log. Opens
  the store read-only, so it is safe against a live agent.
- The agent runs as root on this development VM, as it will on its own
  VM. Architecture D3/D6/D7 corrected to match the operator's intent:
  installing packages and toolchains on its own VM is class 2, recorded
  so the environment can be rebuilt (it was class 3 with provisioning an
  open question); egress names OS package mirrors. The plan's M0.2, M4.1,
  M4.2 and bring-up guards follow.

Acceptance: a smoke run started, answered status in the test room,
stopped cleanly, and collect produced the log and transcript.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

docs/Architecture.md

@@ -93,7 +93,7 @@ Every action any agent can take falls into one of three classes:
 |---|---|---|---|
 | **1. No side effects** | Observes; changes nothing outside a disposable sandbox | Reading files, querying APIs, searching, viewing logs and metrics, running a build or tests in a throwaway environment | Always allowed |
 | **2. Contained side effects** | Changes something, but the change stays within the agent's own area or has a known undo | Editing the workspace, committing to the agent's branch, opening a PR, writing the agent's own notes, starting a test container; for ops, a step with a known undo inside an approved plan | Allowed when in scope; logged and reported |
-| **3. Dangerous** | Irreversible, visible beyond the agent's own area, or outside what was agreed | Merging to a default branch, deleting data, changing a firewall, installing software on a host, contacting third parties, spending beyond a budget | Needs discussion, unless an approved plan names the exact action |
+| **3. Dangerous** | Irreversible, visible beyond the agent's own area, or outside what was agreed | Merging to a default branch, deleting data, changing a firewall, installing software on a host the agent doesn't own, contacting third parties, spending beyond a budget | Needs discussion, unless an approved plan names the exact action |
 
 **"In scope"** means within what the operator agreed to: the work item's task,
 an approved plan, a pre-approved milestone (D2), or an approved step sequence
@@ -716,12 +716,15 @@ other, often before earlier PRs are merged.
 **Toolchain preflight.** When the workspace is prepared, the agent determines what
 the project needs (from its files, e.g. `Cargo.toml`, `pyproject.toml`,
 `package.json`, or a declaration in the repo) and checks it is available. A gap is
-reported **before any planning**, with the options. The environment's toolchain
-versions become facts in the transcript (L6), so plans match reality.
+installed **before any planning**. The environment's toolchain versions become
+facts in the transcript (L6), so plans match reality.
 
-**Toolchains come from the environment, not from the agent improvising.**
-Installing software is class 3 (P3). How toolchains are provided (project dev
-containers on the VM's Docker daemon, or the VM image) is an open question (Q).
+**The agent installs what it needs on its own VM.** The VM is disposable and is
+the boundary (D7), so installing packages and toolchains there is class 2 (P3): a
+contained side effect. Every install is recorded as a fact (L6) and in the
+project's scope memory, so the environment can be rebuilt; toolchains that keep
+being needed are baked into the VM image (X4). Installing on any host other than
+its own stays class 3.
 
 **Repairing the environment is in scope.** Within a task, the agent may clean
 caches and build artifacts or reinstall project dependencies to fix a broken
@@ -771,8 +774,8 @@ a corrupt `.pyc`.
 | Class | Examples |
 |---|---|
 | 1 | Reading the repo, running tests and builds in the workspace or a test container, querying Gitea |
-| 2 (in scope) | Editing the workspace, committing to milestone branches, pushing them, opening and updating PRs, commenting on its issues and PRs, cleaning caches, installing project dependencies from package registries |
-| 3 | Merging to the default branch (unless the trust dial allows), deleting remote branches or others' work, installing system software, changing repository settings, anything outside the work item's repo |
+| 2 (in scope) | Editing the workspace, committing to milestone branches, pushing them, opening and updating PRs, commenting on its issues and PRs, cleaning caches, installing project dependencies, packages and toolchains on its own VM |
+| 3 | Merging to the default branch (unless the trust dial allows), deleting remote branches or others' work, changing repository settings, anything outside the work item's repo or its own VM |
 
 Its scope sources are the approved architecture, the build plan and each
 milestone's marking.
@@ -782,7 +785,7 @@ milestone's marking.
 - **Its own VM** (X1), with a real Docker daemon, because it builds and runs
   containers. The VM is the trust boundary for unattended command execution.
 - **Sealed:** its egress allowlist (X2) permits only LiteLLM, Gitea and package
-  registries; there is no ingress. Denial covers RFC1918 (except the specific
+  sources (language registries and OS package mirrors); there is no ingress. Denial covers RFC1918 (except the specific
   LiteLLM and Gitea addresses) and the tailnet's `100.64.0.0/10`, so it can't reach
   the NAS, Proxmox or the gateways. The inference host sits behind LiteLLM, so it is
   not a second exception.
@@ -959,8 +962,6 @@ it uses; nothing is shared between agents.
   way a misread must default to asking (L5).
 - **How far the local driver goes.** Which kinds of work it handles well and where
   a frontier driver is needed, measured on real tasks, not assumed (P7).
-- **Providing toolchains** for `nisse-dev`: project dev containers on its Docker
-  daemon, or the VM image, or both (D3).
 - **One local model for every agent.** The inference host keeps one model resident;
   different models per agent would reload weights on every switch. Preferred: one
   model good enough for every local role. Fallback: agents take turns holding the

docs/Development-Plan.md

@@ -80,10 +80,9 @@ test Matrix room, a budget-capped LiteLLM key; configuration in `~/nisse-e2e/`.
 - **A bring-up run on this box ends each phase** where it can be run live. What it
   finds is filed as issues and fixed before the next phase starts, or explicitly
   deferred.
-- **Bring-up guards on this box** (it isn't the sealed VM): the agent runs as an
-  unprivileged user, touches only test resources, and keeps today's structural
-  gates on in its bring-up configuration until the classifier and trust dial are
-  proven (Phase 3).
+- **Bring-up runs on this development VM,** as root, like production. Guards: it
+  touches only test resources, and keeps today's structural gates on in its
+  bring-up configuration until the classifier and trust dial are proven (Phase 3).
 - **This plan is revised as we go:** a milestone's scope may move once work shows
   its real shape, recorded here in the same PR.
 
@@ -100,10 +99,15 @@ test Matrix room, a budget-capped LiteLLM key; configuration in `~/nisse-e2e/`.
   section table this plan carried for the purpose.
 - Acceptance: `grep` finds no reference to the old spec or its section numbers.
 
-**M0.2 A bring-up script, and an unprivileged agent user on this box.** *Pre-approved.*
-- One script: set aside the previous run's state, workspace and log; start the agent
-  as an unprivileged user; collect logs and the transcript afterwards.
-- Acceptance: a smoke run starts, answers `status`, and stops cleanly as that user.
+**M0.2 A bring-up script.** *Pre-approved.*
+- `scripts/bringup.sh`: set aside the previous run's state, workspace and log;
+  export the ref under test; start the agent as a systemd unit, so it outlives the
+  shell that started it; collect the log and a readable transcript
+  (`python -m nisse_dev.dump`) afterwards.
+- The agent runs as root on this development VM, as it will on its own VM in
+  production (D7), so installing packages works as it will there.
+- Acceptance: a smoke run starts, answers `status`, stops cleanly, and `collect`
+  produces the log and transcript.
 
 ### Phase 1 — Foundations the new loop needs
 
@@ -211,11 +215,13 @@ on, then deliberately loosened in the bring-up configuration.
 
 ### Phase 4 — The environment
 
-**M4.1 Toolchain preflight.** *Pre-approved.* Detect, check, report before planning;
-toolchain facts in the transcript (D3).
+**M4.1 Toolchain preflight.** *Pre-approved.* Detect what the project needs, check
+it, and install what's missing before planning; toolchain facts in the transcript
+(D3).
 
-**M4.2 Providing toolchains.** *Needs discussion.* Decide dev containers vs the VM
-image (Q), then build it.
+**M4.2 Recording installs.** *Pre-approved.* Every package or toolchain the agent
+installs is recorded as a fact and in the project's scope memory, so the
+environment can be rebuilt; recurring ones are noted for the VM image (D3, X4).
 
 **M4.3 Environment repair.** *Pre-approved.* The driver may clean caches and
 reinstall project dependencies within a task, and reports it (D3).