A threat model worth retiring on: the forge's security written down against intelligent adversaries, zero trust between its own parts, and the owner's operational security as a first-class concern #1149

From the owner, 2026-10-12: "Opsec has been on my mind. Once I put up cameras and such I don't want any chance of snoopers. It's going to be a scary world when people start unleashing big, superintelligent botnets. I want to be so prepared that I retire and get to start building honeypots and doing real work against evil without fear of horrible repercussions. The forge should be completely sovereign, with very high class security that doesn't get in the way, so it is used correctly and well."

Done looks like:

• [ ] docs/THREATS.md: who the adversaries are (a snooper on the network, a stolen token, a compromised vendor, a hostile agent inside a run, an intelligent automated attacker at scale), what they want, what the forge gives them today, and what stands in the way. Each line names a mechanical protection and the test that proves it, or says honestly that none exists yet.
• [ ] Zero trust between the forge's own parts: every internal call (runner to forge, cell to proxy, edge to pod, child forge to parent) is authenticated with a short-lived, scoped credential, logged, and refusable; nothing trusts a network position. The map of these calls is in the doc and the sentinel watches for an unauthenticated one.
• [ ] Security that does not get in the way: the default is the safe path and it is the easy path — sealed values, passkeys, scoped tokens, contained runs — and a person is told once, in one line, when something is less than the default.
• [ ] Honeypots as a use case, later: a kind: "honeypot" app that looks like a target, records what touches it into the dataset, and never holds anything real. Named here so the primitives (isolation, egress, the dataset) grow toward it.
• [ ] Tests: each protection in the doc points at a test; a test that goes red marks the doc's line red on the Resilience page.

Files I expect: docs/THREATS.md, src/kernel/* (internal credentials), src/apps/contain.ts, src/web/pages/resilience.ts.

Parked by the crew: the check stayed red through 2 automatic tries (pull #1214 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the run ended without a pull: declined: the part of #1149 that fits in one run is already on main, and the rest has been split into #1396, #1397 and #1398. I made no new commit, because anything more would be a guess.

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #1214 closed)
2. the run ended without a pull: declined: the part of #1149 that fits in one run is already on main, and the rest has been split into #1396, #1397 and #1398. I made no new commit, because anything more would be a guess

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Split. Why it was parked: the red checks were on tests this work does not touch (home-feed, asks-bulk). The pull branches were cut before main changed those tests (the Asks button left the top bar on 2026-10-15); on today's main they pass. Every new issue says to start from today's main and to merge main and push again when an unrelated test is red. The zero-trust parts (#1396–#1398) are closed; what is left is the doc and its proof. #1687: docs/THREATS.md, with a test that every test it cites exists (honeypots named as later inside it). #1688: the Resilience page marks each protection red when its test failed.