M7.1: extract nisse-core

What isn't the dev agent's moves to nisse-core, unchanged in behaviour,
with its tests: canonical, render, render_anthropic, llm, catalog, probe,
context, views, state, reconcile, worker, cancel, dump, transport, matrix,
execution, testing, vault, memory, oplog, envfile and gitea (whole).

- nisse_core.state.StateStore holds the tables every agent has; an
  agent's subclass adds its tables (version, migrations), roles and
  views. nisse_dev.state.StateStore adds the build VM blocks (v5).
- views.project takes what each role is shown, rather than a fixed table.
- Vault takes the agent's name (agent=), for provenance.
- A test that nisse_core never imports an agent.
- The loop, config, git, delegation, expert, tools and evals stay in
  nisse-dev until nisse-ops has a loop to share.

Docs: the Development Plan marks M7.1 done and notes that Phase 6 waits on
the agent host and Terraform; Architecture Part L names the package.

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

docs/Architecture.md

@@ -131,7 +131,13 @@ naming a milestone (D4).
 
 ## Part L — The shared library (`nisse-core`)
 
-Everything in this part is used by every agent.
+Everything in this part is used by every agent. In code it is the `nisse_core`
+package: the transcript (L7) and its renderers, the LLM client and model catalog
+(L9), context fitting and per-role views (L6), the state store and reconciliation
+(L8), transports (L5), SSH execution (L13), the vault and memory (L10, L6.4),
+logging and secrets loading (L12), and the Gitea client (L1). An agent extends
+the store with its own tables, roles and views; the loop is still `nisse-dev`'s
+until a second agent shares it.
 
 ### L1. The work model
 

docs/Development-Plan.md

@@ -535,6 +535,11 @@ Authelia.
 
 ### Phase 6 — Production
 
+*Waiting on infrastructure (2026-10-13):* the agent host doesn't exist yet, and
+Terraform isn't running; the operator is planning both, Terraform with
+`nisse-ops`. Until then M5.4 and M6.1–M6.4 wait, and the build VMs stay made by
+hand (Ubuntu 24 now, 26 soon), with `vm ready` for a rebuilt one's host key.
+
 **M6.1 The agent host.** *Needs discussion.* Containers, volumes, snapshots,
 per-agent networks (X1, X2, X4).
 
@@ -550,7 +555,26 @@ LLDAP principal (L12).
 
 ### Phase 7 — `nisse-core` and `nisse-ops`
 
-**M7.1 Extract `nisse-core`.** **M7.2 MCP servers** (#37). **M7.3 Approved step
+**M7.1 Extract `nisse-core`.** *Done.* What isn't the dev agent's moved to
+`nisse-core`, unchanged in behaviour, with its tests: the transcript and its
+renderers, the LLM client and model catalog, context fitting and views, the state
+store, reconciliation, the worker and `stop`, transports (Matrix), SSH execution,
+the vault and memory, logging, `.env` loading, and the Gitea client (whole: L1
+makes Gitea every agent's tracker). `nisse-core` never imports an agent (a test
+says so).
+
+- `nisse_core.state.StateStore` holds the tables every agent has; an agent's
+  subclass adds its own tables (with their schema version and migrations), its
+  model roles, and what each role is shown of the others (`views`).
+  `nisse_dev.state.StateStore` adds the build VM blocks (D3); stores already at
+  version 5 open unchanged.
+- The vault names whose writes it records (`agent`), rather than assuming one.
+- Deferred until `nisse-ops` has a loop to share: splitting the loop (`loop/*`)
+  and configuration into a common part and the dev agent's. The dev agent's
+  `git`, delegation, `ask_expert`, executor tools and evaluation capture stay
+  in `nisse-dev`.
+
+**M7.2 MCP servers** (#37). **M7.3 Approved step
 sequences** (O2). **M7.4 Ops intake and duties** from the infrastructure
 repository (O5). **M7.5 The ops tool VM and deployment** (O6). **M7.6 Requests
 between agents:** `nisse-dev` asking for build VMs (L1, O5). All *needs discussion*