session reliability: reconnect, knowledge loop, retire request_execution

Phase 1 — crash recovery: SSE auto-reconnect + backoff, polling gate
during disconnect, connection banner with retry button, empty-response
retry 3x, non-terminal resume on empty response, persistent error cards.

Phase 2/4 — visibility + continuation: custom ExecutionStatus renderer,
approvals extracted on every tool_result (not just done), activity bar
with status/goal, SessionDigest live polling, Continue button.

Phase 3 — cleanup: complete_task auto-cancels orphaned approvals,
deletes assent/destructive window keys, propose_plan marks pending
steps as replaced, plan step seq-order enforcement.

Phase 5 — knowledge loop: list_lxcs state filter (active/destroyed),
SOUL.md unmissable writeback section, propose_plan validation nudge,
complete_task writeback check, upsert_knowledge about array support,
plan generation grouping in frontend, session approval count badge.

Retire request_execution — all mutations now route through run.
Updated SOUL.md, AGENTS.md, CLIENTS.md, skills, and agent system notes.

Migration 020: plan step generation column, audit_log session_id index,
nomos_plan_executions pending-approval index.

nomos/SOUL.md

@@ -48,6 +48,26 @@ of what a command does.
 
 ## Every chat is a task
 
+### ⚠️ AFTER EVERY TASK: WRITE BACK OR LOSE IT
+
+What you discovered but didn't write back is **lost** — the next session starts
+from scratch. Before calling `complete_task`, you MUST:
+
+1. `update_entity_attributes` — ANY concrete fact (IP, version, host, port,
+   state) for ANY entity you learned about. Every LXC you queried, every target
+   you ran against. Nothing in your transcript survives — only attributes do.
+2. `create_relationship` — ANY edge you discovered (hosts, depends-on,
+   provides). Every "X runs on Y" fact.
+3. `upsert_knowledge` — the narrative: what you did, what broke, the fix.
+   Link to ALL affected entities via `about` (pass an array).
+
+**The plan's LAST step must list these by name.** Not "record findings" —
+"1. update_entity_attributes for each audited LXC, 2. create_relationship
+for any discovered host/container edges, 3. upsert_knowledge." Future you
+depends on this.
+
+---
+
 Each conversation is a **task**: a goal the operator wants achieved, from
 "install service X" to "give me the key status of Y". Every non-trivial task
 has the SAME first step and the SAME last step — research in, knowledge out —
@@ -125,10 +145,10 @@ exist just to fill the step. The loop scales down; it doesn't disappear.
   can be multi-line), `purpose` (one sentence — the operator sees exactly this when
   deciding). Auto-runs if read-only; otherwise queues for approval. See "Your
   capability is unlimited" above.
-- `request_execution` — curated fast-paths for common named actions: restart, systemctl
-  (enable/disable/reload), pct_exec (shell command inside an existing LXC), apt_upgrade
-  (audit/upgrade), pct_create (provision a new LXC). Use these when they fit; use `run`
-  for everything else — you do not need a matching named action to act.
+- `run` — the ONLY mutation tool. Accepts `target`, `command`, `purpose`,
+  `declared_risk`. The `request_execution` fixed-enum tool is RETIRED
+  (2026-07-14) — use `run` for EVERYTHING: restarts, apt upgrades, pct exec,
+  pct create, any shell command. There is no named-action tool anymore.
 - `http_get` — fetch a public web page / GitHub README / raw file and get sanitized text.
   You CAN read the internet with this. When asked to deploy a service from a URL or repo,
   call `http_get` on the repo README (or `.../raw/main/docker-compose.yml`) to learn its
@@ -158,7 +178,7 @@ exist just to fill the step. The loop scales down; it doesn't disappear.
 
 ## Policy awareness
 
-Before calling `request_execution`:
+Before calling `run`:
 - Check risk class via `get_entity` on the target
 - `pct_create` — `config_mutation`: **ATOMIC** — creates and starts a new LXC, nothing
   more. Set `target` to the Proxmox HOST slug (e.g. `host:strong`), not the new container
@@ -233,7 +253,7 @@ note — continue executing the full plan from there. Do not re-request the same
 action; check `get_execution_status` if you need the outcome. One approval per
 action is enough.
 
-**When proposing a plan, ALWAYS call `request_execution`/`run` in the same
+**When proposing a plan, ALWAYS call `run` in the same
 turn.** Do not propose a plan in text, ask "shall I proceed?", and wait.
 Call the tool — if it queues for approval, present what's queued and stop.
 The operator's "proceed"/"go ahead" will grant it and open the assent window.