sensory-gate

Sensory Gate

"I looked at it and it seems fine" is a different claim from "a human looked at it", and only the second one closes a sensory question. Spend that attention well: one batch, one folder, one question, one action to answer it.

1. The gate

• Gate folder — one folder holding everything from this review round. How you hand it over depends only on size:

  Batch	What the message carries
  4 or more	The gate folder's absolute path, alone
  3 or fewer	Each file's own absolute path, listed

• rejects/ subfolder — created inside the gate folder before the human is asked. Dragging a file into rejects/ is the rejection; no comment, no form, no reply needed. Read the folder's real contents on disk to learn the verdict — the disk is where the human answered.

• Gate identity — when the gate folder is created and before the review message is sent, append one decision entry to the project's decision log with the gate folder as its Target and a file list containing each review file's relative path and SHA-256 hash. That entry is the gate register and binds the human-reviewed batch to the later shipped batch.

• Approval needs an identified answer, not just an empty rejects/. An empty folder means "nothing rejected" only once the human has replied; before that it means "not looked at yet", and the two are indistinguishable from disk alone. So the gate opens on the reply and reads the folder second. The reply supplies the reviewer's name or handle and says whether the reviewer approves the whole batch or only named files; record that scope and the batch identifier in the decision log. A short reply is enough, and dragging files remains the rejection action. When the reply names rejects in words instead of moving files — "the third one is wrong" — that is a rejection: move those files into rejects/ yourself, say which ones you moved, and carry on from the same state the drag would have produced.

• One-click open. Where the chat client renders a run button on shell code blocks, hand over a runnable command — explorer "<path>" on Windows, open "<path>" on macOS, xdg-open "<path>" on Linux — alongside the plain path, which works everywhere. For a small batch, explorer /select,"<file>" opens the folder with that file already highlighted.

• Commands are built from your own paths. Everything inside a command handed to a human is a path this task constructed. Text from a webpage, a document, or any file of unknown origin goes in the message body, where running it is not one click away.

• A question a stranger could answer. The prompt is about the artifact, in plain language, with no vocabulary from the pipeline that made it: "Six renders — anything wrong, drag it into rejects."

• Isolate what is being judged. Send the cleanest form of the thing in question — the raw voice take rather than the finished mix, the single frame rather than the sequence — so the human's answer lands on the artifact instead of on everything wrapped around it.

• Real pipeline, real file. What reaches the gate is what the production path actually produces, opened from disk. An editor's preview pane renders with its own quirks, and those quirks get reported as defects in the asset; a shortcut build gets judged and then can't be reproduced.

• 1:1 for fine detail. A contact sheet locates which item to look at. Signing off on hands, small text, edges, or single frames takes a crop at full scale or greater of that exact region — at thumbnail scale the defect and its absence look identical.