implementation: reviewed-2026-09-01 reviewed-commit: 274465b

Design Intent Review

A conformance review of the implementation against the intent stated in 001-architecture.md, performed 2026-09-01 at commit 274465b (16 commits on main, all four quality gates passing, workspace line coverage 87.32 % against the 85 % gate).

Method: every intent claim in the architecture document was turned into a checkable statement, then verified against (a) the source tree and build configuration, and (b) live runtime behavior of the running sw ui process and its API. Evidence is cited per row.

What the design is for

The architecture document commits to six load-bearing intents. Everything else in it (tables, phase list) is elaboration of these:

One source of truth — the catalog is imported from ~/.ssh/config; the tool never becomes a second place where fleet knowledge lives.
Strict layering — eight crates where pure vocabulary (sw-core) sits at the bottom, SQL lives only in sw-store, process/socket I/O only in sw-ssh, and the UI is a leaf whose artifact is dist/.
System ssh reuse — reach the fleet through the system ssh binary; no embedded SSH library, no second source of truth for credentials.
Localhost trust model — loopback-only bind plus a bearer token on every non-asset request; WS routes authenticate before upgrade.
Bounded, dependency-free storage — one SQLite file in WAL mode, compile-time-embedded migrations, runtime-checked queries only, retention keeps it bounded.
Reproducible frontend/toolchain — pinned Rust and trunk, committed dist assets, so a fresh checkout builds without npm and CI never runs trunk.

Conformance findings

#	Intent (per `001-architecture.md`)	Evidence	Verdict
1	Catalog imported from `~/.ssh/config`; user-owned columns survive re-sync; removals soft-delete	`sw sync --dry-run` after deleting the `agentforge-worker` block reported `removed: 1 (marked missing)`; apply marked it `stale` and dropped it from monitoring while the row survived for history	✅
2a	`sw-core` depends on nothing internal, no async runtime, stays wasm-compatible	`crates/sw-core/Cargo.toml` `[dependencies]` = serde/thiserror/toml/directories only, with an explicit no-async comment	✅
2b	`sw-store` is the only crate that talks SQL	Runtime `sqlx::query*` calls exist only under `crates/sw-store/src/` (27 call sites)	✅
2c	`sw-ssh` is the only crate that spawns `ssh` or opens sockets	Executor/probe/metrics/PTY modules exist only in `sw-ssh`; `sw-api` and `sw-mcp` consume them	✅
2d	`sw-ui` is a leaf; nothing depends on it in Cargo	`sw-ui` internal deps = `sw-core` (DTO reuse, as designed); no crate's `[dependencies]` lists `sw-ui`; `sw-api` embeds `dist/` as a folder reference via rust-embed	✅
2e	Dependency graph matches the documented layering	Measured: store→core; ssh→core; monitor→core,ssh,store; api→core,monitor,ssh,store; mcp→core,monitor,ssh,store; cli→all	✅ (see note 1)
3	Fleet reached via system `ssh` only	All remote operations go through `SystemSshExecutor` (`ssh -o BatchMode=yes …`); no SSH library in the workspace; this session exercised it live (exec on `blog`, PTY terminal on a real host with zero residual `ssh` processes after close)	✅
4	Loopback bind + bearer token on all non-asset routes; WS authenticates before upgrade	Live checks against the running server: no-token `GET /api/v1/events` → 401; token without upgrade header → 400; never a silently dropped socket. `/healthz` and version remain unauthenticated as documented	✅
5	WAL SQLite, embedded migrations, runtime-checked queries only, retention	`sqlx::migrate!` embeds migrations; zero `query!`/`query_as!` macro uses (doc comments mentioning them are not code); WAL + busy-timeout set in `SqliteStore::open`; retention prunes raw/status/aggregate windows	✅
6	Pinned toolchain and trunk; committed dist	`rust-toolchain.toml`, `.tool-versions`, and the CI `toolchain:` input all read `1.93.1`; trunk pinned at `0.21.14` (0.22-beta MSRV conflict documented); `crates/sw-ui/dist` tracked in git (9 files incl. vendored xterm)	✅
7 (bonus)	Live updates: status flips only, metrics, syncs on a broadcast channel; `sw-monitor` holds only an `Option<Sender>`	WS client received `{"kind":"sync_completed",…}` 1.0 s after triggering `POST /api/v1/sync/ssh-config`; a 75 s quiet window emitted nothing (correct: no status flipped); `sw-monitor`'s channel is an `Option<Sender>` so MCP/tests construct without it	✅
8 (bonus)	`#![forbid(unsafe_code)]` in every crate root	Present in all 8 crate roots	✅

Notes and minor deviations

sw-mcp also depends on sw-monitor (for the sw_sync_ssh_config tool). The architecture diagram shows mcp --> store/ssh/core and omits this edge. It does not violate any stated layering rule — sw-monitor sits below both consumers — but the diagram would be strictly accurate with the edge added.
Phase status: the frontmatter of 001-architecture.md says phase-6-complete, which matches reality; the events stream (listed as "Phase 6 optional" in the original plan) landed as commit 274465b and is verified above.
Deferred work (environment, not design): git push to the gitea remote is pending external recovery of the remote host; no code change is implied.

Conclusion

The implementation conforms to every load-bearing intent of the design document. The single discrepancy found is one missing (harmless, rule-consistent) edge in the architecture diagram, noted above. No intent is partially met or silently dropped.