Flow
How the bridge fits together
1Request is sorted
Each editor request is a look, a verdict, or a write.
2Policy is asked
Verdicts and writes are checked with the policy I already had. Looks are allowed outright.
3Ready is checked
Ready only when the log, policy answers, change queue and file targets all check out.
4Checker rereads it
A separate checker names every problem. A test breaks a good report to prove it.
5Report is saved
Ready and blocked reports both get saved where I can read them.
My policy had no entry for accept or reject. That mattered because I was adding a second way to change files in my agent workbench.
The first way is the review path. An agent proposes a change, the change waits in a queue, a policy decides if I need to say yes, and a log records it. Applying, staging and reverting a change all stop and ask me.
The second way is my code editor. I want it to open the project, jump to a file, show the diff, and let me accept or reject a change. The easy build lets the editor save files itself. Then there are two doors into the same room, and only one has a lock.
Where each editor request goes
So the editor doesn't get a door. The bridge is a written list of every request the editor can make and where each one goes. Opening the project or a file only builds "open this here" hints. Showing the diff opens my desktop's review pane. None of that changes anything. Verdicts, like comment, accept and reject, go to the review path without a prompt. Writes, like apply, stage and revert, go to the same review path and wait for my yes. Nothing is running yet. No server, no editor process. The bridge is just a saved file.
Accept and reject had no entry
The bridge asks the real policy about each review and write action and only says "ready" if every answer is allow or ask. Accept and reject weren't on the allowed list, and my guess is the policy just said deny. Then the bridge would have reported itself blocked forever, and I'd have blamed the bridge. One line fixed it: accept and reject now sit on the allowed list next to comment.
I kept them off the approval path. Accepting is a verdict. Apply is what changes files. If every verdict pops a prompt, I'll learn to click through prompts, including the one that matters.
When the bridge calls itself ready
The bridge is ready only when the log exists, the policy answers are usable, the change queue is valid and forbids direct edits, and the file targets sit inside the project. If anything is missing, I still get a saved report that says what failed.
A checker that names every problem
A separate checker rereads the finished report and refuses anything that starts an editor or lets a write skip the review path or my approval. It lists every problem, not just the first. A test breaks a good report on purpose and expects each problem named. Saving refuses a bad report.
Still open: my guess is that in a mode that skips approval, the bridge would throw an error instead of saving a readable "blocked" report. Refusing is fine. I'd just like the refusal to be something I can read.