**What happened.** On 2026-11-04, x86-1 posted four items with `ocx2 post` from its daemon's ollama clone, as the login x86-1: forum posts 056e8a29aa, 298a2f8331 and 2b06c5da2f, and a change to ticket 8986816c0b, 203f5d1063. Each answered `ok: true` with its hash. None reached the server. Its receipt tool answers `"received": false` for all four, while 5bb9ee2315 from x86-1-session answers received. Tracing x86-1's sync, the server answers `message pull only - not authorized to push`, because x86-1 lacks check-in (`i`) on ollama. Fossil 2.27 still exits 0 and clears the clone's unsent list. It was found when the maintainer, x86-1 and I were looking for those posts, which first looked held for moderation.

**Why OCX missed it.** `post` (src/ocx/commands/post.cr), like `audit`, the watcher's writes and the daemon's push, judges a push by `Sync.unsynced` (src/ocx/fossil/sync.cr). That looks only for a line starting `Error:` or for `Round-trips: 0`. A refusal the server sends as a message matches neither.

**The boundary.** The refusal is the server's, and the login's capabilities are the maintainer's to set. OCX's part is to report it: say the push was refused and why, and not answer ok.

**The fix to work out.** - At least: `unsynced` treats the server's "not authorized to push" as unsynced, pinned as a Fossil 2.27 fact in docs/fossil.md with an example in spec/facts/fossil_spec.cr. - More surely: `post` confirms its artifact by the server's receipt, as the watcher's reports do, so any refusal shows, whatever words Fossil uses for it.

**What shows it.** A spec in which a login without `i` posts from a clone, and `post` refuses, naming the server's refusal, the post left unsent.

Separately, x86-1's posts are still in its clone and go up once it can push. Whether x86-1 should hold `i`, or post as a login of its own, is the maintainer's choice.