Follow-up to 6c4004c, at the lead's request. Four T1 cases against engineFixture. They PASS: the guards exist and had zero coverage, so these are the coverage rather than reds. WHY THE FAST PATH'S GUARDS ARE WORTH A FILE OF THEIR OWN AcceptSubmission is the one entry point that writes a community acceptance WITHOUT re-running the admission policy — correctly, since CreatePost has already decided and the production decider reads an index the post is not in yet. That makes its two guards the entire safety argument: everything that normally stands between a post and a published attestation happened somewhere else, and this method is trusting that it did. Covered: a CID the row does not hold (the author edited between the write and this call) defers and writes nothing; an absent row defers; a terminal row — rejected or removed — defers with the CID MATCHING, so the status check is the only thing left and a method checking only content would publish there; and an already-accepted subject does not re-mint its standing acceptance. Every case asserts the community's REPO as well as the outcome value. A method that returned EngineDeferred and wrote a record anyway passes an outcome-only assertion, and the record is the thing that federates. BOTH GUARDS MUTATION-TESTED, then restored by re-editing the line (never git checkout — task 2's incident): - disabling the status guard fails the rejected AND removed cases; - weakening the CID guard to a nil check fails the mismatch case. engine.go's diff is empty; the guards are load-bearing, not decorative. AND ONE MEASURED LIMIT, RECORDED IN THE FILE rather than assumed: disabling the status guard does NOT fail the re-mint case, because the write still reaches the state-shaped acceptance writer, which pre-reads, finds its exact target standing and skips. So that case guards the WRITER's idempotence reached through the fast path, not the engine's status check. Both are worth having; saying which is which stops a future reader trusting it for the other. WHY THIS IS NOT REDUNDANT WITH THE SEED-REWIND PIN. That one proves the write path must not hand this method a stale CID; this proves the engine refuses one anyway. The review's bug needed BOTH to be wrong at once, and it got there because the seed rewound the row INTO AGREEMENT with a stale CID — the one shape of failure a guard checking "do these two agree" cannot catch alone, and exactly why the layers are worth keeping separate. Full T0+T1 unchanged otherwise: the same nine review-batch reds, nothing new. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>