Proof, not promises

Why replies end with a disk check

A model can write "done" whether or not the file landed. Mori treats her own reply as a claim to check, not a fact to believe. After a turn that changed something, files written, folders made, dev servers started, she checks each change against your machine and adds one line to the reply. The checks are plain code on your computer: your own disk read again, your own ports probed. A turn that changed nothing checkable gets no line, because nothing needed proving.

The line

The check covers the files Mori wrote (create_file, write_file, update_file, edit_file, append_to_file, zips, documents, sheets and slides), the folders she made and the dev servers she started, up to twelve checks and three seconds per probe. Up to three names are shown, then how many more. The line always says what it does not prove:

✓ Disk check: 2 files I wrote are on disk (a.ts, b.ts); 1 folder I made exists (src); 1 dev server answers (http://localhost:5173). Says nothing about whether the rest of this answer is right. ⚠️ Disk check: 2 of 3 passed; not as expected on disk: index.html. Says nothing about whether the rest of this answer is right.

The line is not evidence

The line is read out of the reply before it is spoken aloud and before it is kept in a bot's history, so Mori's own check can never be recycled as proof of anything. A failing check goes back to her on the next turn, marked as a note from the app and not your words.

She never says she did what she did not

A reply that claims a send that never ran is corrected in the reply itself, not argued with underneath. It leads with what is true: "I haven't sent this email: no send ran, so what follows is only a draft.", or simply "Nothing was sent: no send ran."

The same holds for any finished work a reply claims when nothing ran: "Nothing was done yet: no step ran in this reply.", "Nothing was done yet: the steps in this reply only looked.", or "I haven't done that: I can't from here." Either the work is done for real, or the reply says plainly that it was not.

Check before stopping

"It should work now" is not evidence, so a turn may not end on it. When a turn edited code and nothing passing ran after the last edit, a build, a typecheck, a test, a clean run, the app sends Mori one internal check, marked as not from you: run the check now and report the real result, or name the blocker. It names the files, catches failing checks as well as missing ones, fires at most once a turn, and never breaks the reply.

Every step, in the open

Each tool call is a row in the turn ("Edited Hero.tsx › +17 −35 1.1s") that opens into a box with what it did. An edit's box shows the real before and after, worked out from the bytes on disk before and after the write, not from what the model said it wrote. Diffs show up to 400 lines; a file over 6,000 lines shows its counts instead. Thinking shows as a "Thought for 12s" step, and the turn ends on how long it worked.

Output that was cut short

A reply that hits its output limit can end mid-call. Tool calls cut off that way are refused, with a note to send the work in smaller pieces, on every provider. A plain file write that was cut keeps its complete lines and says where the file stops. On a text reply that hit the limit, say "continue" and Mori picks up where she stopped.

A self-test on the real machine

Ask Mori to "test yourself" or "run diagnostics" and run_self_test checks each part of her toolbox on your actual computer: the shell, reading and writing a file, the keyboard and mouse through her input helper and Accessibility, app detection, the active window, screen capture, and her dispatcher reaching git, Python and the dev server tools. Each check passes or fails with one line on why.