Aniket Kumar

Thanks. That line wasn't planned. It turned up when I put all four services side by side for the write-up and noticed every one of them already had a decline path, and that I'd built each of those before the thing it guards. Wasn't a design principle, more something I'd been doing without naming it. The MCP parallel makes sense to me. One thing I'd add from living with the approval gate: read-only vs write isn't the whole boundary. The write path also has to expire. Mine holds a proposal for an hour and then voids it, because someone approving at 9am for a cluster state from midnight is approving something that doesn't exist any more. On temperature, the reason it lasted so long is that nothing failed. Ollama wants it inside options and I had it at the top level, so it got silently dropped and every call ran at 0.8. The eval harness passed 0.0 and believed it. Three runs over the same five logs, three different severity sets, and I'd been quoting that score as evidence the rubric worked.

Yeah, you're right, and your version is sharper than mine. The proof is in my own post. That rule caught three stale test counts: all three in READMEs I wrote and still maintain, each one contradicted by another line further down the same file. I'd have told you those were verified. I hadn't looked at them in weeks. Same thing bit me again yesterday, different shape. I'd changed a timeout in code to 300, the .env on the server still said 120, and I checked the deploy by reading a config file that doesn't report what the process actually loaded. So I confirmed a fix that hadn't taken. Ended up putting the value on /health so the running process has to say it out loud. Which is roughly your point in another domain, I think the number has to come out of the process itself. The queue one I've half-built and never thought of as a single failure mode, which is probably why it's still half-built. There's dedup on the alert fingerprint (1h), a proposal TTL so stale approvals void themselves, and a cap on actions per hour. But that cap is on executions, not proposals, so the queue can keep growing while nothing is allowed to act. And nothing can be dismissed. Once the dedup TTL lapses a still-broken alert comes back round, so one genuinely stuck problem works out at something like 24 proposals a day. Which is your notifier, slower. Filing that one properly. And the 94%, that's the number I least wanted to write down. I'd spent that morning tuning batch size against input I should have deleted.