_Verbatim output of the review step. The page itself says what changed because of it: back to the architecture._
This is better than a hobbyist inventory, and worse than a document an ops expert will prioritise. The honest bits (§4.3, §7, the cost line in §5) earn credibility. The structure spends it: a resiliency reviewer gets 1,100 words of component inventory before reaching the only paragraph that tells them what happens when the host dies — and even that paragraph never says what dies.
What lands: the threat statement in §4.1 is crisp and correct. The cost table is real money with a real incident. §7 reads like someone who has been paged.
What costs you: the document is organised by what exists, not by what the system is for and what breaks. A Principal TAM reads §2.3 (Plausible, Open WebUI, a relay "not part of the fleet proper") and §2.4 (344 surfaces, proj <name>) and concludes you want to show the garage, not fix the car. Nowhere does the doc state the fleet's actual production function in operational terms — "Telegram answers, a daily podcast by 07:30, outbound sends" — or who notices when it stops. Without that, RTO/RPO, SLOs, and blast radius are unanswerable, and two of your ten questions are asking the reviewer to do your job.
Second credibility hit: the numbers you volunteer. Six daemons failing "for days." Two stale heartbeats. Dead-man's switch fires; nobody acts. An ops person reads this as alert fatigue is already installed — the thing you built to protect you is being ignored, and the control plane's MTTR for known failures is measured in days. Candour is good; sending the doc with the failures still live is not.
Third: "control plane built as Claude Code skills" is ambiguous in a way that matters. Does the 3-hour sentinel run unattended, or does "every session reads them" mean the control plane only exists while you are sitting at a terminal? The reviewer will ask within two minutes.
Ten questions in 45 minutes is four minutes each — the reviewer will pick, and will pick the easy ones. Keep three.
Worth asking: Q1 (blast radius with a stated constraint — good), Q5 (cutover sequencing and stop signal — concrete, decidable), Q7 (spend guardrails short of per-call approval — a real design problem). Q3 is good if reframed as "what in the IAM model does my broker reinvent badly" rather than an invitation to admire it.
Lazy: Q2 and Q6 ask the reviewer to set your RTO/RPO and SLOs. Nobody can; they derive from impact you haven't stated. Propose numbers and ask him to break them. Q4 leads the witness ("is macOS the problem?") — he will say yes in ten seconds and you'll have learned nothing. Q8 is home-networking trivia. Q9 is project management. Q10 invites the Well-Architected template; you will get the template.
Missing question: "Which failure do you expect first, and would you run this?" — the one an expert actually enjoys answering.
Definitively: lead with the single host. Three reasons. The reviewer's expertise is resiliency; the broker is a security artifact he may respect but cannot review in his domain. The broker is in shadow — leading a production-ops conversation with a component that has never carried production traffic is leading with aspiration. And candour about the damning part is what buys you the right to show the clever part; the reverse order reads as a pitch. Frame it as a decision, not a confession: "One host, deliberately, because X. Here is exactly what dies when it dies. Here is the mitigation I built and the one I am asking about."
The broker is already the piece with no LLM, fixed verbs, and every credential. It is the one component that should not live on the house box. Move it — and only it — to the smallest possible cloud footprint, credentials in a secrets manager, Mini holding zero secrets. That inverts the blast radius: the Mini becomes disposable compute you can rebuild from git; the house box losing power can no longer leak a credential. It also puts the conversation squarely in the TAM's territory, and turns Q1 from "where would you draw the line" into "I drew it here — is this the right line?"
