docs: update configuration and diagnostics

docs/src/architecture.md

@@ -39,7 +39,7 @@ kaptan-config-mavlink ──► state-only ConfigProtocol
                       ├── one ConfigManager ──► kaptan-config ──► flight schema/store
                       └── one bounded MAVLink log-sink queue
                                  │
-                   kaptan-log-mavlink payload adapter
+              kaptan-diagnostics-mavlink payload adapter
                                  │
                  platform-owned sole encoder / DMA TX link
 ```
@@ -48,17 +48,17 @@ The generated dialect is intentionally custom rather than a `PARAM_*` or QGC
 adapter. The core uses numeric field IDs and typed scalar values; descriptor
 text is metadata, not a wire identity. Discovery/value reads, exact-index
 descriptor and enum-option requests, and structured results are custom-dialect
-records. Runtime logs use one bounded text message with MAVLink severity and
-flags. Remote writes use only schema-described typed scalar setters. The core
+records. Runtime logs use one bounded text message with a conventional level
+and flags. Remote writes use only schema-described typed scalar setters. The core
 owns one RAM transaction and the distinction
 between boot-active, committed, and editable candidate snapshots. In the
 current P1 policy a commit is restart-only. It cannot mutate controller or
 estimator state in flight.
 
 Target-owned stores may serialize one bounded complete CBOR snapshot. SITL
-supplies the host file adapter and persists a private nonzero storage sequence
-alongside that snapshot. The serialization and sequence are not configuration
-state and are never exposed by the MAVLink protocol.
+supplies the host file adapter and atomically replaces that snapshot through a
+same-directory temporary file. The serialization is not configuration state
+and is never exposed by the MAVLink protocol.
 Motor allocation/mixer topology is immutable compiled vehicle capability data,
 never a scalar field or CBOR candidate member. F722 now recovers operational
 settings from a generic two-slot journal before constructing consumers. Its
@@ -74,18 +74,22 @@ option request. The first accepted transaction binds one source principal
 through a bounded post-terminal replay lease; foreign traffic cannot evict a
 lost result before that lease expires.
 
-The MAVLink dialect root includes `kaptan/config.xml`, `kaptan/log.xml`,
-`kaptan/error.xml`, and `kaptan/shutdown.xml`.
+The MAVLink dialect root includes `kaptan/config.xml`, `kaptan/log.xml`, and
+`kaptan/error.xml`.
 The build watches every fragment and generates one `message::kaptan` module;
 fragments are never separately generated Rust modules. `kaptan-log` itself has
-no MAVLink, platform, time, allocation, filesystem, or configuration
-dependency. Event creation is independent from sink filtering, allowing a
-future blackbox and MAVLink to select different policies. Each sink owns
-bounded Critical and BestEffort queues. The platform drains a MAVLink record
-only after TX admission. `KAPTAN_LOG` carries
-severity plus one bounded text field; `KAPTAN_ERROR` carries exact error
-severity and flags plus bounded path and additional-information fields. Local saturation accounting remains
-inside the sink queue, facade, and producer mailboxes; heartbeat and safety
+no MAVLink, platform, time, allocation, or filesystem dependency; its sole
+configuration coupling is compile-time enum metadata for `LevelFilter`.
+`kaptan-err-propagate` independently owns explicitly assigned typed-error identity,
+function-boundary propagation, and a bounded nonblocking ingress; it has
+no logging, MAVLink, platform, filesystem, or clock dependency. Event creation
+is independent from sink filtering, allowing a future blackbox and MAVLink to
+select different policies. The platform drains typed errors before its bounded
+critical and best-effort log queues and removes a pending record only after TX
+admission. `KAPTAN_LOG` carries one conventional level plus one bounded text
+field; `KAPTAN_ERROR` carries an explicitly assigned 16-bit ID and the bounded
+`file:line` of the reporting boundary. Its
+message kind already identifies a typed firmware error. Heartbeat and safety
 telemetry remain separate from diagnostics.
 
 See [Configuration](configuration.md) for the deployment matrix and GCS transaction