Specs follow #1667: no decide-alone mode, a cloud session's gates are a local agent's gates

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CSM4FVUbnP4PJJ9sawMfLb

Author: claude

packages/chrome-extension/SPEC.md

@@ -2,7 +2,7 @@ The extension half of the Claude web bridge: a Chrome extension that carries the
 
 It exists because an agent with run target `web` is hands-off: the daemon hands the whole task to a cloud session on claude.ai and the agent ends at the hand-off. When that session later parks on a gate, nothing streams back — the question is stranded on a claude.ai page nobody may be looking at. The daemon cannot reach claude.ai itself, but the user's own browser is already signed in there, so the extension turns that browser into the bridge's far end, with the daemon's `/_bridge/*` endpoints as the near end.
 
-The bridge being on is also what makes such a session ask at all: a hand-off is told to decide alone whenever the bridge is off, since a question it stopped on could reach nobody, and is told its gates work when the bridge is on. Which of the two it is is settled once, when the task is handed off.
+A cloud session asks the same way a local agent does — its gates are never framed away. The bridge is what carries the question home; with the bridge off, the question simply waits in the session on claude.ai until the user finds it there.
 
 Four parts: the content script (the page half — reads claude.ai, types answers), the service worker (the daemon half — holds the token, makes every daemon call, manages tabs), the options page (setup and connection proof), and an offline check harness that proves the reading and typing against synthetic pages without a browser.
 

packages/the-framework/prompts/protocols/SPEC.md

@@ -1,9 +1,9 @@
-The protocols appended to every agent's system channel: how an agent signals to The Framework. They pin the exact shape of an awaited choice, of the session name and the ready-for-merge signal, and they tell an agent what this particular agent can do — whether it has a browser, whether it has to land its own work, and whether anybody can answer the questions it stops to ask.
+The protocols appended to every agent's system channel: how an agent signals to The Framework. They pin the exact shape of an awaited choice, of the session name and the ready-for-merge signal, and they tell an agent what this particular agent can do — whether it has a browser, and whether it has to land its own work.
 
 ## User story
 
 - The user drives coding agents through The Framework's dashboard: answering their questions, watching them name their work, and merging it when they say it is done. All of that only works if an agent's message can be recognized as a question, a name, or a finished-signal.
-- The user turns on a browser for an agent, or hands a task to a place nothing local can steer. The agent has to be told which of those it is in — including whether a question it asks from there can still reach the user.
+- The user turns on a browser for an agent, or hands a task to a place nothing local can steer. The agent has to be told which of those it is in.
 
 ## Glossary
 
@@ -15,9 +15,8 @@ The protocols appended to every agent's system channel: how an agent signals to
 - **Awaiting** - one block shape for every question an agent stops to ask, including handing a stuck browser to a human, plus a non-blocking way to show a document.
 - **Signalling** - the non-blocking blocks: the session name, ready for merge, the pull request to open, and an error only the user can fix.
 - **Browser** - added only when this agent has a real browser, telling it so and when to prefer the browser over plain page fetching.
-- **Unattended** - added only when nothing can answer this agent's gates, replacing them with "decide alone".
 - **Hands-off** - added to every agent handed somewhere nothing local can steer, requiring it to land everything as a pull request.
-- **Order is fixed** - the browser section comes first, then awaiting, then unattended amending it, then hands-off, and signalling stays last.
+- **Order is fixed** - the browser section comes first, then awaiting, then hands-off, and signalling stays last.
 
 ## Business logic
 
@@ -42,10 +41,9 @@ See `## User story`.
 - **Awaiting** — how an agent parks at a gate: one block ending the turn, in one shape for an approval, a multi-select, a plan sign-off or handing a stuck browser to a human, carrying which option is safe to take when nobody answers and which option ends the agent instead of resuming it. It also covers pushing a document to the dashboard without stopping.
 - **Signalling** — the blocks an agent emits mid-turn without stopping: the session name it chose, the ready-for-merge declaration, the title and description of the pull request The Framework then opens for it, and errors only the user can fix.
 - **Browser** — added only to an agent that has a real browser: that it has one, that the browser is for what it must see or act on while plain fetching remains better for reading, and that it should stay within one page so the user can watch.
-- **Unattended** — added only to an agent nothing can answer: the gates just taught have nobody attached to take them, so instead of parking it takes the most plausible reading and says in one line which assumption it made. The non-blocking blocks are unaffected.
 - **Hands-off** — added to every agent handed somewhere nothing local can steer: no machine here sees its workspace, so it must commit its work and open a pull request for it, and write any analysis, plan or decision into committed files, because the conversation reaches nobody.
 
-Being handed off and being unanswerable used to be the same thing, and are now decided separately: every agent handed off is told to land its work, while only one whose questions cannot reach the user is told to decide alone.
+An agent's gates are the same everywhere: a hands-off agent asks exactly the way a local one does, and the Claude web bridge is what carries a cloud session's question to the user.
 
 ### Order is fixed
 
@@ -55,7 +53,7 @@ The dashboard shows the user the exact system channel an agent will receive, and
 
 #### Business logic
 
-The browser section goes ahead of the rest; the await protocol follows; the unattended protocol comes immediately after it, because it amends what that protocol just taught — the gates are described and then declared unanswerable, which keeps the shape intact for The Framework's parser while telling the agent not to reach for it. The hands-off protocol comes after those, and the signal protocol is always last in the channel.
+The browser section goes ahead of the rest; the await protocol follows; the hands-off protocol comes after it, and the signal protocol is always last in the channel.
 
 ## Before modifying/creating SPEC.md files
 

packages/the-framework/prompts/protocols/hands_off.SPEC.md

@@ -30,7 +30,7 @@ Ending without a pull request is allowed only when the task genuinely required n
 
 #### Rationale
 
-This is the whole of what a hands-off agent is told about being detached. Whether it may also stop and ask the user a question is a separate matter, decided per agent by whether the Claude web bridge is on, and carried by its own protocol.
+This is the whole of what a hands-off agent is told about being detached. Its gates are the same as any agent's: whether a question it stops on reaches the user is the Claude web bridge's business, not this prompt's.
 
 ## Before modifying/creating SPEC.md files
 

packages/the-framework/prompts/protocols/unattended.SPEC.md

@@ -15,7 +15,7 @@ The user gives The Framework a task. From there the agent runs unattended: it wo
 - **The agent queue is worked after the opening exchange settles** - a build then consumes the confirmed backlog one gated entry per turn until it is empty.
 - **Live chat comes last** - a build takes the user's own messages once its backlog is worked; a one-prompt agent takes them straight after its opening exchange.
 - **A hands-off agent is its opening prompt and nothing else** - the work leaves this machine, so every later phase is dropped, the agent is told to land its own work, and it says so before ending.
-- **A hands-off agent decides alone only when nothing can answer it** - with the Claude web bridge on, its framing leaves the gates in place, because the bridge carries its question to the dashboard and types the answer back.
+- **A hands-off agent keeps a local agent's gates** - its framing adds only the land-everything rule; whether a question it stops on reaches the user is the Claude web bridge's business, not the framing's.
 - **The agent always ends with a verdict** - success, stopped, or failed with the reason, and the coding agent's session is always closed.
 
 ## Glossary

packages/the-framework/src/agent.SPEC.md

@@ -8,7 +8,7 @@ What the tests cover, running whole agents against a scripted offline driver:
 - **The gate loop** - each answer re-prompts with one shared continuation wording built from the question and the pick, and every turn — the asking turn included — goes through the turn-signal parsing. An agent that keeps asking is cut off at the await limit and reported as exhausted; a deliberate stop is reported as a stop and never also as exhausted; an agent that hit the limit but has live chat wired is not reported as exhausted either, since it ends because chat closed rather than at the limit.
 - **The agent queue** - the fake driver works no backlog by default, keeping the offline demo deterministic; opted in, a build works the queue on the data branch after its opening turn and before its ending, draining the open entry and reporting how the loop ended. A one-prompt agent runs its text with no framing and works no backlog at all, even in a project whose queue has entries.
 - **Build framing** - a build against a workspace that already has content is framed to extend the existing codebase, never to rebuild it; a build against an empty workspace is framed to build from scratch. A build that leaves the workspace empty is re-prompted once with a hard from-scratch directive and the retry's result becomes the agent's result; a build that produced files is not re-prompted.
-- **Hands-off agents** - a `web` agent's opening prompt is the whole agent: no later phase runs, so nothing reads the hand-off note as a reply, the agent queue is left untouched and unasked about even when the backlog loop was explicitly opted into, no gate is ever raised, and the agent says it was handed off before ending. Its framing always tells the coding agent to land everything itself, and tells it to decide alone only when the Claude web bridge is off; with the bridge on it keeps the same gates a local agent has. A local agent gets neither instruction. It never waits for chat messages, which would never arrive.
+- **Hands-off agents** - a `web` agent's opening prompt is the whole agent: no later phase runs, so nothing reads the hand-off note as a reply, the agent queue is left untouched and unasked about even when the backlog loop was explicitly opted into, no gate is ever raised, and the agent says it was handed off before ending. Its framing always tells the coding agent to land everything itself and leaves its gates exactly as a local agent's; a local agent is not told to land its own work. It never waits for chat messages, which would never arrive.
 - **Continuations** - resuming a stopped agent resumes the coding agent's prior conversation rather than starting a new one, sends the user's message verbatim with no build framing added, and still runs the rest of the flow.
 - **Parked announcements** - an agent whose own terminal is its only surface announces every time it parks waiting for the user — after its opening work settles and again after each chat turn — so a dashboard can stop showing it as running the moment it stops working.
 

packages/the-framework/src/agent.test.SPEC.md

@@ -166,16 +166,12 @@ For the `actions` target, the repository's owner and name come from its GitHub o
 
 For the `web` target nothing is resolved: the wrapped CLI holds the account the cloud session runs under. The agent announces the hand-off and, when the repository has no GitHub remote, that a bundle of it will be uploaded instead. It also states plainly that the cloud session clones the remote at its current branch, so local commits that were never pushed are not in it.
 
-The `web` target also decides there and then whether the cloud session may stop to ask: the Claude web bridge preference is read once, at the hand-off, and passed to the agent, which frames the session either as one whose questions reach the dashboard or as one that must decide its own. Either way the user is told which of the two they are getting, in the same announcement.
-
 The framework launches Chrome itself for a browser-enabled agent rather than letting the driver's browser tooling launch its own, because that is what lets the preview attach to the same page. It does so only for a local agent: the browser tools are wired on this machine, so a remote agent could never reach them, and launching Chrome would leak a headless browser per agent. A browser asked for on a remote target, or on a machine with no Chrome, is reported as having no effect rather than failing the agent. Whether the system prompt may claim the agent has a browser is narrower still than the setting: it must be a local, real, Claude Code agent.
 
 The preview stream of that Chrome is opened alongside it and is stopped with the agent, so no headless browser outlives it.
 
 #### Rationale
 
-The bridge preference is read at the hand-off rather than consulted later because a cloud session's instructions are fixed the moment it is created: nothing can revise them afterwards, so turning the bridge on or off later cannot reach a session already handed off.
-
 An abort that happens after the agent meta already says "running" but before the normal ending machinery is in place must close itself out by hand — say why, record the failure, release the handles — or the agent is recorded as running forever and the dashboard shows work that never moves. Persistence is best-effort even there: a store that cannot write its own failure must still let the process exit.
 
 The preview is opened even while the page is still, because it costs nothing: Chrome emits a frame only on a change.