docs: multi-client learn hooks + Phase 2/3 command rewriting

.cargo/config.toml

@@ -48,6 +48,8 @@ rustflags = ["-C", "link-arg=-undefined", "-C", "link-arg=dynamic_lookup"]
 
 # Build configuration
 [build]
+# Fleet standard §1.3: name-keyed build-dir override.
+build-dir = "{cargo-cache-home}/build/by-project/terraphim-terraphim-ai"
 # Default target intentionally left as host; set --target explicitly (use `cross` for Linux)
 
 # Cross-compilation settings (commented out - let cross-rs handle Docker images)

.docs/adr-0006-toolchain-pin.md

@@ -0,0 +1,70 @@
+# ADR-0006: Rust toolchain pin (rust-toolchain.toml)
+
+**Status:** ADOPTED (2026-08-08)
+**Deciders:** Hermes Agent (session review of TinyClaw ↔ Hermes parity work)
+**Fleet mandate:** `rust-fleet-standard` §1.4
+
+## Context
+
+Per `rust-fleet-standard` §1.4, every fleet Rust repo MUST commit a root
+`rust-toolchain.toml` with channel + `rustfmt` + `clippy` components. Drift
+between the pin and workspace `rust-version` must be recorded explicitly
+with rationale.
+
+Before this ADR, `terraphim-ai` had no `rust-toolchain.toml`. The session
+that delivered the TinyClaw ↔ Hermes parity epic added it, but the
+initial pin (1.93) was wrong and broke the build because `sysinfo@0.39.5`
+requires `rustc >= 1.95`.
+
+## Decision
+
+Pin `channel = "1.96"` (default stable on the reference box, 2026-04-16).
+
+## MSRV trace
+
+| Step | Value | Why |
+|------|-------|-----|
+| Workspace `rust-version` (Cargo.toml `[workspace.package]`) | 1.91 | Set by prior maintainer; reflects the lowest crate's stated MSRV |
+| `sysinfo@0.39.5` transitive dep | requires `rustc >= 1.95` | Newest published version, no older 1.91-compatible line |
+| Candidate pin 1.93 | REJECT | Build breaks: `error: rustc 1.93.1 is not supported by sysinfo@0.39.5` |
+| Candidate pin 1.95 | ADOPTED (initial) | Builds clean; matches the tightest dep constraint |
+| Final pin 1.96 | ADOPTED (this revision) | Default stable on this host; probe verified all workspace deps compile |
+
+## Alternatives considered
+
+- **Pin 1.95** — builds, but ties us to an older minor. 1.96 is the
+  default on this host and the wider fleet baseline.
+- **Pin nightly** — rejected: nightly drift breaks reproducibility and
+  §1.4 specifies a stable channel.
+- **Pin MSRV (1.91)** — rejected: requires downgrading `sysinfo` to a
+  pre-0.39 line and blocking several other transitive deps. Out of
+  scope for the fleet rollout window.
+- **Set `rust-version = "1.91"` but no toolchain pin** — pre-ADR state.
+  REJECT per §1.4.
+
+## Consequences
+
+- All CI workers + dev boxes that build `terraphim-ai` MUST have
+  `rustup toolchain install 1.96` or use the auto-install path
+  (`rust-toolchain.toml` triggers this automatically when `rustup` is
+  present).
+- Workspace `rust-version` (1.91) is now intentionally LOWER than the
+  toolchain pin. This is allowed by §1.4 ("record the decision") but
+  must be flagged at next dependency audit.
+- If a new dep requires `rustc > 1.96`, this ADR must be revised and
+  re-merged.
+
+## Verification
+
+```bash
+cargo check -p terraphim_tinyclaw  # exits 0
+cargo test -p terraphim_tinyclaw --all-targets --no-fail-fast
+# Result: 349 passed, 0 failed
+```
+
+## References
+
+- `rust-fleet-standard` skill §1.4
+- `/home/alex/projects/cto-executive-system/2026-08-08-rust-fleet-standard.md`
+- `memory/2026-08-08.md` (session log of the parity work)
+- `memory/regressions.md` (rule: ADOPT/ADAPT/REJECT every fleet mandate violation in code)

.docs/adr-0007-cargo-deny-gate.md

@@ -0,0 +1,67 @@
+# ADR-0007: Cargo-deny gate activation
+
+**Status:** ADOPTED (2026-08-08)
+**Deciders:** Hermes Agent (session review of TinyClaw ↔ Hermes parity work)
+**Fleet mandate:** `rust-fleet-standard` §1.5
+
+## Context
+
+Per `rust-fleet-standard` §1.5, every PR gate must include `cargo deny check`. The configuration file `deny.toml` was committed to the repo but **cargo-deny itself was never installed** and the gate had never been run.
+
+Running `cargo deny check` for the first time on 2026-08-08 against `terraphim-ai` workspace revealed:
+
+```
+advisories FAILED, bans ok, licenses FAILED, sources ok
+```
+
+Two real findings of fleet-standard significance:
+
+1. **Unlicensed path-deps introduced by Wave 4 of this session.** `jmap_client` (1.0.0) and `haystack_core` (0.2.0) — both from `terraphim-private` workspace — do not declare a `license` field in their Cargo.toml. **This is a supply-chain hygiene gap I introduced by adding `jmap_client` as a path dep without first verifying the sibling's license metadata.**
+
+2. **Cargo.lock vulnerability in `crossbeam-epoch 0.9.18`** (CVE in `fmt::Pointer` impl for `Atomic`/`Shared`). Dev-only dep via `criterion` → `rayon`. Not in our runtime, but still flagged by the gate.
+
+## Decision
+
+**Activate the cargo-deny gate.** Block merge on FAILED status. Document the current state and the path to green.
+
+## Action items (in priority order)
+
+1. **File Gitea issue** in `terraphim-private` asking for `license = "Apache-2.0 OR MIT"` to be added to `jmap_client` and `haystack_core` Cargo.toml files. **(fleet-standard supply-chain fix)**
+
+2. **Add `MIT-0` to `deny.toml` allow list** (single-line cleanup, lets `borrow-or-share 0.2.4` pass).
+
+3. **Verify `quick-xml 0.38.4` vulnerability status** — the deny output is ambiguous because the CVE is filed against 0.37.5. If 0.38.4 is also flagged, bump opendal. If only 0.37.5 is flagged, no action needed.
+
+4. **Clean up stale `ignore` entries** in `deny.toml` (5 RUSTSEC IDs no longer match anything in the dep graph).
+
+5. **Track as fleet-rollout issue** in `terraphim-ai` per §1.6 (issue → gitea-robot claim → design gate → fix).
+
+## Verification
+
+```bash
+cargo install cargo-deny --locked  # ~3 min compile
+cargo deny check 2>&1 | tail -3
+# Current: advisories FAILED, bans ok, licenses FAILED, sources ok
+# Target:  all 4 sections ok
+```
+
+## What This Means for the Merge Bar
+
+**Workspace is NOT currently fleet-standard §1.5 compliant.** All previous PRs (including this session's Wave 4 Hermes parity work) bypassed the cargo-deny gate because the gate was never wired.
+
+The 355-test pass + clippy clean + fmt clean is necessary but **not sufficient**.
+
+## Lessons Learned
+
+1. **The fleet standard is right.** This is exactly the kind of issue the standard was designed to catch — a new path-dep was added without verifying supply-chain metadata. Without cargo-deny in the merge gate, this would have shipped uncorrected.
+
+2. **Configuration is not enforcement.** `deny.toml` was committed but `cargo deny` was never installed. The gate existed in form but not in function. **A standard is only as strong as its enforcement.**
+
+3. **Audit-before-implement.** I should have run `cargo deny check` BEFORE adding `jmap_client` as a path dep, not after. The discipline pattern: check the store before adding to the cart.
+
+## References
+
+- `/home/alex/projects/cto-executive-system/2026-08-08-cargo-deny-findings.md` — full findings report
+- `deny.toml` — gate config (untouched, gated work is at the action items above)
+- `rust-fleet-standard` skill §1.5 (validation stack mandate)
+- `memory/regressions.md` §5 (claim-sudo-without-checking) — sister "audit before action" lesson