Manual verification record

These are individual command checks performed during implementation on 2026-09-06. No automated scenario test or test harness was added. The build was validated with cargo check -p silicon-dm-client, cargo check -p silicon-dm-cli and cargo build -p silicon-dm-cli.

Offline checks

An explicitly isolated SILICON_DM_HOME directory was used; normal user profiles were not changed. Automatic updates were disabled before offline commands.

Two problems found during manual checks were fixed: stopped status originally returned a raw connection error, and the initial spawned daemon inherited the shell session. Status now provides a useful stopped state; Unix daemon launch uses setsid with redirected standard streams. A deliberately selected occupied port failed to bind; a free isolated port succeeded without disturbing its owner.

Live checks

An existing real IAM test login was used with a locally running DM backend and separate live CLI state directory. Credentials remained in private runtime files and are not included here.

Live concurrency exposed a bundled SQLite Unix WAL mutex deadlock while separate connections were opened/closed concurrently. A sampled daemon stack identified the blocked SQLite routines. Queue access now uses one process-local connection guarded for short transactions, with no guard held across an async wait. The restarted daemon recovered both pending requests from its existing database. Refresh-file lock acquisition was also made asynchronous to avoid blocking a runtime worker while another task refreshes the same profile. Clippy with -D warnings passes for both new crates.

Complete leaf-command coverage

Every leaf command in the current Clap command tree was invoked individually. env is the visible alias for environments. A separate CLI-created sandbox was used for environment lifecycle commands; the primary messaging sandbox was not cleaned, deleted or rotated. Login/refresh/logout used a fresh independent Silicon token family, leaving the active Carbon sessions intact.

The initial mixed-media GIF plus 20 later separately entered GIF sends exercised retention. Recent results contained manual-finish first, manual-wave last, and excluded the original manual-gif. The commands used distinct explicit idempotency keys; no generated command loop or scenario harness was used.

Reliability observations

• Repeating a text send with the original idempotency key returned the same message ID and sequence, with no duplicate message.
• Recipient callback acceptance automatically queued Delivered, while sender copies and explicit Read remained separate.
• The relay stored a 100,000,496-byte event containing the 100-million-character message in SQLite. Its callback completed in one attempt; only lengths and IDs were inspected. The same inbox survived a subsequent daemon restart.
• A queued recipient receipt had expected_generation=1 stored independently of its original request JSON and completed against the matching sandbox.
• Parent-agent manual callback check: HTTP 200 with the wrong delivery ID kept the callback pending through five attempts and the message Sent. Restoring the correct ACK completed that retained event.
• Parent-agent slow-callback check: Bob's callback was delayed 12 seconds. A separate Silicon callback reached Delivered about 630 ms after creation while Bob remained Sent. Callback endpoints were then restored to normal.
• With the backend forcibly stopped, a new send returned a durable local ACK under request ID 7355dacd-34ad-48c0-892f-e047a8e3d128. The daemon was then killed with SIGKILL. Read-only SQLite inspection found the original pending request, idempotency key, and expected test generation intact. After restarting the API and daemon, that same request completed and reached Delivered. Direct database inspection found exactly one corresponding message, with ID 01a072fd-9cba-7761-9b4f-940b161f26a4. Session refresh and test-generation admission recovered without replacing or duplicating the queued request.
• Final daemon inspection showed all four enabled profiles connected and zero pending requests. Three retained callback events belonged to the deliberately logged-out leaf-auth profile; they had not been discarded or delivered after logout. Six failed request records were the earlier deliberate invalid-command and dependency-failure checks.

Read dependency failures originally retried indefinitely and could hold later writes. Reads now finish with structured errors; retryable writes remain durable. Requests and callbacks now use separate bounded worker pools, one in-flight item per profile, so slow profiles do not delay unrelated profiles.

These initial checks preceded registry publication. Successful Giphy trending/search results could not be checked while the configured provider was unavailable. The later release checks below supersede the initial registry limitation; these earlier provider failures remain recorded as observed.

Installed offline documentation

The rebuilt dm executable was invoked manually from /tmp, with SILICON_DM_HOME=/dev/null so a credential or state-directory lookup would fail. No repository path or login was needed by the commands.

cargo build -p silicon-dm-cli --bin dm --locked and cargo clippy -p silicon-dm-cli --all-targets -- -D warnings passed. cargo package -p silicon-dm-cli --allow-dirty --locked --list included the documentation module, all 15 Markdown files, and the OpenAPI file inside the CLI crate. Every include_str! target resides within that package. The canonical-to-package synchronization command is python3 scripts/sync-cli-docs.py; run it after guide changes and before building a release. These were direct command inspections, not automated test scenarios.

Remaining presence values and explicit key output

A final command-tree audit found these option/value branches were implemented but not explicitly recorded. Each was then invoked manually against the live backend:

Secret output was captured privately and compared without including either key in the transcript or documentation. The disposable sandbox was restored only for these checks and soft-deleted afterward. Primary messaging data and keys were unchanged.

Published registry packages

On 2026-09-05 UTC, silicon-dm-client and silicon-dm-cli version 0.2.0 were published to crates.io in that order. The backend remained unpublished. Both retained their existing LicenseRef-Proprietary metadata, which the registry accepted. Registry checksums matched the exact uploaded archives. The client archive was verified with both default and optional runtime features; CLI package verification downloaded the published client dependency.

The following commands were selected and invoked manually from /tmp, using separate Cargo installation and DM state directories. Existing actor profiles, tokens, daemons, and the user's normal Cargo binary directory were untouched.

The 0.2.0 CLI installation was then kept with automatic updates disabled, and the SDK consumer retained its 0.2.0 lockfile, for a later real upgrade check. No automated test scenario or cargo test was run.

Actual upgrade from 0.2.0 to 0.2.1

The documentation patch was published on 2026-09-05 UTC, client first and CLI second. Backend version 0.2.0 remained unchanged and unpublished. The archive changes contained release metadata, README updates, and refreshed operating and verification guides; runtime source files were unchanged. The bundled AWS guide describes the EC2 deployment option and its acceptance procedure, rather than recording a completed cloud deployment.

cargo check -p silicon-dm-client -p silicon-dm-cli --all-targets passed. cargo package verified the client with --features runtime and verified the CLI against the newly published client. The 14-file client archive and 26-file CLI archive were checked against 43 current private credential values, including the supplied registry and provider credentials; no values or private runtime paths appeared. Both kept LicenseRef-Proprietary. The exact uploaded SHA-256 checksums matched the crates.io sparse index:

These checks used the preserved 0.2.0 fixtures from the previous section. Each command was invoked individually. Only the isolated updater timestamps were aged to make the hourly check due; no actor profiles or tokens were present in the CLI fixture.

The original 0.2.0 CLI binary and SDK lockfile backup remain available privately. The isolated installed CLI was left on 0.2.1 with updates disabled after the checks. No automated scenario suite or cargo test was run. This record was appended after publication, so it is not part of the immutable 0.2.1 archive.

Relay memory changes prepared for 0.2.2

The following checks were chosen and performed manually on 2026-09-06 in an isolated local state directory. Its single profile used deliberately invalid credentials and an unavailable loopback backend, so requests stayed queued without changing any IAM session or remote data. The new source was checked with cargo check -p silicon-dm-client -p silicon-dm-cli --all-targets, strict Clippy with -D warnings, and a CLI build. All passed; no automated scenario suite or cargo test ran.

The private daemon was stopped after these checks. Existing production and manual messaging daemons were left untouched. These observations demonstrate constant-size progress polling and compatibility with an older daemon; they do not establish a total process memory bound. The shared 128 MiB work budget limits admitted encoded queue payloads, while one larger payload can proceed alone. Socket frames, HTTP responses, parsing, and the exact full ACK/result still require additional memory.

Waiting for the testing generation

The 0.2.2 prerequisite retry correction was also checked manually in a separate native macOS fixture. A deliberately unavailable loopback backend kept its testing profile from receiving a realtime ready frame. After submitting one conversation mutation, two SQLite metadata observations eight seconds apart showed pending, awaiting_testing_generation, and zero attempts. The due time continued advancing in one-second increments rather than accumulating failure backoff.

The private daemon was then stopped, that fixture's attempt count was seeded to seven to represent earlier backend failures, and the daemon was restarted. The request remained pending with exactly seven attempts and a due time within one second. This confirmed that waiting for the prerequisite neither erases earlier failures nor adds new ones. The existing HTTP retry path was unchanged. The fixture daemon was stopped afterward; no real credentials, production state, or active messaging daemons were used for this check. The updated CLI build and strict Clippy checks passed without running automated tests.

Published 0.2.2 and actual upgrades

Both crates were published on 2026-09-05 UTC, SDK first and CLI second. The backend remains version 0.2.0 and unpublished. The SDK README and CLI's embedded guides include the 0.2.2 runtime corrections and the final cloud verification available before publication. Both packages retain LicenseRef-Proprietary.

The SDK package built with the optional runtime enabled; a separate check of the extracted package with no default features also passed. Its default feature list is empty. CLI package verification used the newly published registry SDK. All packaged source and guide files matched their release snapshots. The 14-file SDK archive and 26-file CLI archive were scanned against 132 private credential values with no matches or private local-path markers. Four public CloudFormation attribute names initially collected from Key/Value records were identified as non-credentials and excluded from that count. The uploaded checksums matched crates.io's sparse index, and both versions were non-yanked:

The following commands were invoked manually using the preserved 0.2.1 fixtures. Their policy timestamps alone were reset to make hourly checks due. The CLI fixture had no actor profiles or credentials.

The frozen 0.2.1 executables and SDK lockfile remain available privately. No existing profiles, IAM sessions, or messaging daemons were modified by these upgrade and installation checks. No automated scenario suite or cargo test ran. This section was appended after publication and is therefore absent from the immutable 0.2.2 CLI archive.