# Third-Party Plan Vetting — Output Format

When Rob pastes an architecture doc from a newsletter/creator, evaluate against THIS environment before adopting anything.

## Preferred output format

Present findings as a three-column table:

| Claim | Verdict | Detail |
|---|---|---|
| "... | ✅ Right / ⚠️ Partially / ❌ Wrong / ❓ Unverified | explanation |

Then a short summary of the architectural fit and what's actually needed to implement the useful parts. Rob valued this format — it lets him decide per-claim rather than accepting or rejecting the whole doc.

## Vetting protocol

1. Check each claimed command/config key against the installed version's --help and source (grep -rn -iE '<key>' /root/.hermes/venv/lib/python3.12/site-packages/hermes_cli/)
2. Check each claimed tool against Rob's actual platforms (Windows Connie, VPS Linux, Surface ARM64)
3. Check each claimed infra need against what's already running (don't rebuild live services)
4. Present the right / wrong-for-you / unverified table — NOT a flat accept or reject

## Red flags found in past docs

| Claim | Why it's wrong for this user |
|---|---|
| "Sync the vault via Dropbox/iCloud" | Inferior to already-live Syncthing (third-party cloud, slower, unnecessary) |
| "OMI for auto-capture" | Mac-only tooling — Rob is on Windows |
| "Set memory.vault_path in Hermes config" | Fabricated config key (verified absent from 0.19.0 source). Grep the venv before repeating ANY claimed config key |
| "Add the MCP URL to Claude Desktop Connectors" | Hand-waves the stdio→HTTPS+auth gap. The real work is the shim |
| "Cowork orchestration" | Doc's usage was aspirational hand-waving; real Cowork = desktop app feature with Projects |
| "Zero cost" | Vault layer yes; MCP layer no (shim code, auth design, testing) |