fix: correct the partial-success guidance and the changelog's Foundation split

AGENTS.md

@@ -81,12 +81,20 @@ Unset (default) → no-op tracer, zero overhead, no network IO.
 | 4 | preflight failure (missing dependency on target) | DO NOT retry — present `missing_components` array to user; offer `trond bootstrap` |
 | 10 | `HUMAN_REQUIRED` — destructive op needs explicit confirmation | DO NOT silently retry with `--auto-approve` / `--confirm` unless the user has authorised that for this session |
 
-There is no exit code for partial success. A multi-node command where some
-nodes succeeded and others failed exits **1** with `error_code:
-"PARTIAL_SUCCESS"` and a `failed` array naming the nodes — so branch on
-`error_code`, not on the exit status alone, before retrying. Re-running the
-whole command is usually wrong: the nodes that succeeded are already in the
-requested state.
+There is no exit code for partial success — branch on `error_code`, not on
+the exit status alone. One command emits a partial result today:
+`network destroy` exits **1** with `error_code: "PARTIAL_SUCCESS"`, a
+`removed` array and a `failed` array naming the nodes whose teardown failed.
+
+**Do not retry it.** The message says `state cleaned up regardless`: trond has
+already dropped every node from its state, so a second `network destroy`
+returns `NETWORK_NOT_FOUND`. The `failed` entries are containers or units
+still running on the target with nothing tracking them — surface that list to
+the user for manual cleanup rather than retrying.
+
+The other multi-node commands do not partially report: `network create` stops
+at the first failed node with `DEPLOY_ERROR`, and `network upgrade` with
+`UPGRADE_FAILED`, both exit 1.
 
 Every error JSON has the same shape:
 

CHANGELOG.md

@@ -28,20 +28,26 @@ The agent-ergonomics arc landed across four sequenced PRs:
 
 ### Added
 
+The release ships **40 top-level commands** plus their subcommands, across
+lifecycle (apply / plan / stop / start / restart / upgrade / rollback /
+remove), configuration (config validate / render / diff / docs,
+verify-config), observability (status / list / logs / health / diagnose /
+verify / inspect / events / doctor), the test-harness SDK (exec / files /
+wait), chaos primitives (disconnect / connect / partition / heal /
+auto-heal), private networks (network create / add / status / destroy /
+upgrade), snapshots (download / clone / list / sources / jobs / logs / stop /
+prune), builds from source (build / list / inspect / prune), shadow-fork
+(mutate), agent interfaces (schema / mcp / recipe list / show / validate /
+run), environment (preflight / bootstrap), the knowledge base, and meta
+(version / completion / help). `trond schema` emits the whole surface as
+structured data; **Foundation** and **Since** below split it by when it
+landed.
+
 **Foundation**
 
-- 40 top-level CLI commands (plus subcommands) across lifecycle (apply /
-  plan / stop / start / restart / upgrade / rollback / remove), configuration
-  (config validate / render / diff / docs, verify-config), observability
-  (status / list / logs / health / diagnose / verify / inspect / events /
-  doctor), test-harness SDK (exec / files / wait), chaos primitives
-  (disconnect / connect / partition / heal / auto-heal), private networks
-  (network create / add / status / destroy / upgrade), snapshots (download /
-  clone / list / sources / jobs / logs / stop / prune), builds from source
-  (build / list / inspect / prune), shadow-fork (mutate), agent interfaces
-  (schema / mcp / recipe list / show / validate / run), environment
-  (preflight / bootstrap), knowledge base, and meta (version / completion /
-  help)
+- The CLI itself: lifecycle, configuration, observability, the test-harness
+  SDK, chaos primitives, private networks, environment setup and the
+  knowledge base — the command groups the project launched with
 - Declarative intent.yaml schema covering ~50 fields:
   target (local/ssh, runtime, auto_ports), node (type, version, image, ports,
   resources, jvm, storage, restart, extra_env, extra_args, labels, networks,

internal/output/exitcode.go

@@ -8,10 +8,10 @@ const (
 	ExitValidationError   = 2 // Intent file or config validation failed
 	ExitTargetUnreachable = 3 // SSH connection failed or Docker not available
 	ExitPreflightFailure  = 4 // Target does not meet requirements
-	// No code 5. A multi-node command that partially succeeds returns
-	// ExitGeneralError with `error_code: "PARTIAL_SUCCESS"` in the JSON
-	// (see cmd/network/destroy.go) — the machine-readable distinction lives
-	// in the payload, not the exit status. A `ExitPartialSuccess = 5`
+	// No code 5. `network destroy` — the one command with a partial result
+	// today — returns ExitGeneralError with `error_code: "PARTIAL_SUCCESS"`
+	// and a `failed` array, so the machine-readable distinction lives in the
+	// payload, not the exit status. A `ExitPartialSuccess = 5`
 	// constant sat here unreferenced by any command; callers that branched
 	// on 5 would have waited forever for a code nothing emitted. 5 is left
 	// unassigned rather than reused, so it stays available if the split is

specs/001-trond-cli-platform/contracts/cli-contract.md

@@ -26,7 +26,7 @@ Every command accepts:
 | 2 | VALIDATION_ERROR | Intent file or config validation failed |
 | 3 | TARGET_UNREACHABLE | SSH connection failed or Docker not available |
 | 4 | PREFLIGHT_FAILURE | Target does not meet requirements |
-| _(5 unassigned)_ | — | Reserved. Partial multi-node results exit 1 with `error_code: "PARTIAL_SUCCESS"`; the distinction is in the JSON payload, not the exit status |
+| _(5 unassigned)_ | — | Reserved. `network destroy` reports a partial result as exit 1 with `error_code: "PARTIAL_SUCCESS"` plus a `failed` array; the distinction is in the JSON payload, not the exit status |
 | 10 | HUMAN_REQUIRED | Destructive change in non-interactive mode without --auto-approve |
 
 Exit codes are stable across minor versions. New codes may be added in minor releases;