ptbk 0.119.0-79 → 0.119.0-80

package/dist/expert/_main.md

@@ -44,7 +44,7 @@ Chat primarily coordinates, checks status and creates/manages tasks; substantial
 
 [CHAT MESSAGE AUDIO](book-language/commitments/chat-message-audio.md) binds recorded user/agent speech as another representation of its originating message, not supplemental input or a second request. Finalized audio files are project chat assets committed with their bindings by default, independently of task traces; preserve overlap timing, actual played speech and interrupted/incomplete capture honestly.
 
-[Local realtime voice](cli/voice-chats.md) runs in the same chat from the terminal or the local Windows/macOS app. The terminal opens a [temporary browser surface](cli/interactive-feature-bridges.md) independent of the project HTTP server. The app presents audio, controls and captions inside the chat. The common [harness voice capability](cli/harness-voice.md) initially supports native Codex/ChatGPT login. Other adapters explicitly report unsupported, and setup guidance follows actual installed-version/account readiness. Audio interruption and task cancellation remain distinct. Chat persistence, task control, Pause and Stop retain their ordinary semantics.
+[Local realtime voice](cli/voice-chats.md) starts only from the [open chat's composer](cli/voice-chat-ui.md), including before the first message of a new chat. The user can send text during a call and return to speech in the same ordered thread, with visible voice indicators and recordings on the corresponding messages. The terminal opens a [temporary browser surface](cli/interactive-feature-bridges.md) independent of the project HTTP server. The Windows/macOS app presents audio, controls and captions inside the chat. The common [harness voice capability](cli/harness-voice.md) initially supports native Codex/ChatGPT login. Other adapters explicitly report unsupported, and setup guidance follows actual installed-version/account readiness. Audio interruption and task cancellation remain distinct. Chat persistence, task control, Pause and Stop retain their ordinary semantics.
 
 Chatter is the editable core default for human-led project conversation. New chat first offers Chatter (Enter) or another agent; only the latter expands all valid targets. Initial TEAM includes the other initialized roles; specialist advice and execution use normal consultation/tasks. Existing chats/questions retain their real authors. Human-facing messages persist immediately and use debounced scoped commits; task-internal consultations retain result attribution, and conversation-only consultations use scoped authoring persistence.
 

package/dist/expert/cli/channels.md

@@ -10,4 +10,4 @@ Actions and messages from every client use shared ownership, project authenticat
 
 See [chat UI](chat-ui.md), [service API](api.md) and [user interactions](user-interactions.md).
 
-[Local realtime voice](voice-chats.md) participates in the same Chat Book through terminal-owned controls and a temporary browser media page. Its transcripts and equivalent audio follow ordinary attribution, authority and persistence; recording/replay is not another input dispatch. This call-owned loopback bridge is independent of the project browser dashboard/HTTP server. Plain remote SSH and remote App/relay voice are outside the initial local mode.
+[Local realtime voice](voice-chats.md) participates in the same Chat Book as text and starts from the open chat view. The terminal chat controls a temporary browser media page, while the local desktop app embeds media within its chat. Transcripts and equivalent audio follow ordinary attribution, authority and persistence. Recording and replay cannot dispatch another input. The terminal's call-owned loopback bridge is independent of the project browser dashboard/HTTP server. Plain remote SSH and remote App/relay voice are outside the initial local mode.

package/dist/expert/cli/chat-ui.md

@@ -45,7 +45,7 @@ Discuss report is an explicit Chatter-targeted new-thread entry. Persist the exa
 
 ## Realtime voice entry
 
-Direct terminal chat, terminal dashboard chat and desktop chat share [voice controls](voice-chat-ui.md). Start voice in the selected thread, preserve typing, drafts and task cards, and show actual call, caption and recording state. The CLI opens a temporary media page. The local desktop app renders the same media and controls inline. Unsupported harnesses and incomplete setup have actionable shared guidance.
+Direct terminal chat, terminal dashboard chat and desktop chat share [voice controls](voice-chat-ui.md). Start voice beside the composer of the open chat, including before the first message in a new chat. The same composer accepts text during the call and the same thread shows typed and spoken messages in order. Keep drafts and task cards visible. The CLI opens a temporary media page. The local desktop app renders media, controls and captions inside the chat view. Unsupported harnesses and incomplete setup have actionable shared guidance there.
 
 ## Acceptance outcomes
 

package/dist/expert/cli/chats.md

@@ -52,7 +52,7 @@ A late user message is saved and handled normally, with new instructions evaluat
 
 Recorded speech uses [CHAT MESSAGE AUDIO](../book-language/commitments/chat-message-audio.md): the transcript and audio represent one attributed utterance. Preserve user and agent audio as finalized project chat assets and commit them with their bindings by default. This is separate from supplemental attachments and optional task traces; consumers must not feed both representations back as two user requests.
 
-[Local realtime voice](voice-chats.md) is another way to participate in this same chat, controlled from its terminal view through an ad hoc browser audio bridge. It shares authorship, routing, task-control authority and persistence with text. The [voice-capable harness](harness-voice.md) keeps one authoritative delivery path so native processing and transcript persistence cannot generate the reply twice.
+[Local realtime voice](voice-chats.md) is another way to participate in this same chat. A conversation may start with speech or text, and both forms of input share authorship, routing, task-control authority and one ordered history, including when the user sends text during a call. The [voice-capable harness](harness-voice.md) keeps one authoritative delivery path so native processing and transcript persistence cannot generate the reply twice.
 
 Accept/save messages promptly during work. Stream in-progress reply text and progress as the provider makes them available rather than buffering the complete answer until its end. Durable partial chunks belong to the same reply, not a new message per token; interruption retains an explicitly unfinished reply. Deliver available progress as it arrives, accept follow-up input during a turn and synchronize one ordered history across clients without duplicate provider work. Preserve available provider/harness progress or reasoning summaries and the complete actual conversation in the Book; private internal reasoning the provider does not expose is not a required output.
 
@@ -64,7 +64,7 @@ Messages are durable on file save and use [bounded debounced Git commits](git-pe
 
 New human-led entry without an explicit agent offers **Chat with Chatter** (default/Enter) or **Choose another agent**. Noninteractive default is Chatter; explicit targets are respected; existing questions retain their participants. Missing/invalid Chatter is diagnosed, not silently substituted or initialized by opening the picker. Closing chat leaves service/history intact.
 
-After saving the first User message, resolve the main agent's effective MODEL before its first reply. Reuse a fully specified agent choice; otherwise ordinary Router consultation fills missing constraints without a hidden extra worker. Source order is definition/members, first User message, MODEL, first reply, even when saves share a Git batch. Reopening does not reroute; mid-chat MODEL switching remains future work. A joined task agent retains its actual task context rather than inheriting the main speaker's MODEL.
+After saving the first User message, whether typed or an accepted spoken utterance, resolve the main agent's effective MODEL before its first reply. Setting up voice media may precede this first message. Reuse a fully specified agent choice; otherwise ordinary Router consultation fills missing constraints without a hidden extra worker. Source order is definition/members, first User message, MODEL, first reply, even when saves share a Git batch. Reopening does not reroute; mid-chat MODEL switching remains future work. A joined task agent retains its actual task context rather than inheriting the main speaker's MODEL.
 
 ## Migration, recovery and acceptance
 

package/dist/expert/cli/desktop.md

@@ -28,7 +28,7 @@ Reuse global observation and individual/bulk Start, Start paused, Pause, Resume,
 
 Reuse the existing graphical dashboard presentation and shared controls. Every project page has Open in terminal, opening the corresponding page of the actual CLI dashboard in xterm.js; keep the selected project and supported entity context. A general CLI/global-dashboard fallback remains available, including when the engine's HTTP server is disabled or its graphical view is unavailable. New CLI functionality must always be reachable through this fallback before bespoke graphical presentation exists.
 
-Embed [live browser tab control](browser-tab-control.md) and [realtime voice](voice-chat-ui.md) directly in their graphical dashboard pages. Use the same authorization, lifecycle and outcomes as the terminal, with local media and input in the desktop client. The [temporary browser surface](interactive-feature-bridges.md) is used when the user is in the actual CLI dashboard, including its embedded terminal presentation. Closing a graphical window ends its owned media surfaces under their individual rules.
+Embed [live browser tab control](browser-tab-control.md) in its graphical dashboard views. Place [realtime voice](voice-chat-ui.md) controls, media and captions inside the open graphical chat, with its start button beside the composer. That chat supplies the call target and handles both typing and voice. Use the same authorization, lifecycle and outcomes as the terminal, with local media and input in the desktop client. The [temporary browser surface](interactive-feature-bridges.md) is used when the user is in the actual CLI dashboard, including its embedded terminal presentation. Closing a graphical window ends its owned media surfaces under their individual rules.
 
 Harness sign-in runs its real native terminal workflow inside the application. Harness sessions retain their actual identity and the shared Observe/exclusive/shared takeover and lease rules. Open the existing session through the terminal dashboard; never represent a fresh unrelated harness invocation as the running session. Closing an observing terminal does not stop an engine or its harness work.
 
@@ -66,6 +66,6 @@ Deny renderer permission requests by default. After explicit call start, permit
 - Reboot/sign in: the tray appears without opening a window, while existing engine persistence rules remain unchanged. CLI-only/headless use never loads Electron.
 - Complete, go back, cancel and resume the same initializer from graphical presentation, with native login in its terminal and complete attachment payloads.
 - Open each page in the CLI terminal. Attach to a real session using normal observation/takeover rules; detach without ending work.
-- On Windows and macOS, start voice inside a chat and control a headless browser tab inside the app. Verify neither starts a temporary CLI server. Check microphone/clipboard permission scope, Wallet save choices and explicit browser handoff. Close the window and verify voice ends while the tab remains protected against automatic takeover.
+- On Windows and macOS, run the [voice chat UI scenarios](voice-chat-ui.md#acceptance-outcomes) and control a headless browser tab inside the app. Verify neither starts a temporary CLI server. Check microphone/clipboard permission scope, Wallet save choices and explicit browser handoff. Close the window and verify voice ends while the tab remains protected against automatic takeover.
 - Quit with live, paused, unreachable and concurrently started engines; distinguish graceful acceptance from verified completion, retain the tray on failures, and never force without explicit confirmation.
 - Reject untrusted IPC senders, arbitrary remote URLs, cross-window terminal control and invalid/stale prompt answers. Build/package checks include the native Windows PTY.

package/dist/expert/cli/interactive-feature-bridges.md

@@ -6,7 +6,7 @@ The terminal dashboard and the local Windows/macOS dashboard expose the same pro
 
 ## Shared feature operations and client presentation
 
-- The owning domain defines the target, authorization, start/attach/end operations, observed state and outcome. Browser control uses the selected browser tab and its ownership rules. Voice uses the selected chat and harness voice session.
+- The owning domain defines the target, authorization, start/attach/end operations, observed state and outcome. Browser control uses the selected browser tab and its ownership rules. Voice uses the open chat view's bound Book identity and its harness voice session. The [chat view](voice-chat-ui.md#the-chat-is-the-controller) supplies this target to the media presenter.
 - The terminal presenter uses one reusable helper for creating a temporary server, authorizing one surface, observing attachment/loss and closing the server. The CLI process rendering the dashboard or standalone interactive view starts and owns that server in process. Each operation gets a separate listener and scoped access. Feature-specific media, inputs and controls plug into the helper.
 - The desktop presenter embeds media and controls in the graphical client using the same domain operations over a trusted local client connection. It needs no terminal feature server, external browser window or duplicate feature state machine. An actual CLI view opened in the embedded terminal follows the terminal rules.
 

package/dist/expert/cli/releasing.md

@@ -12,7 +12,7 @@ Fixtures preserve the runner's tools and environment, handle canonical paths and
 
 Reviewed planning saves produce their scoped `ptbk: ` commit on every supported platform, including nested task paths and paths with spaces. Check fixtures inspect the committed contents and preserve unrelated work. A written file without the required commit is pending persistence and fails acceptance. Real browser checks allow bounded startup under runner load and retain actionable, redacted startup failure evidence.
 
-Run the focused real-browser checks (`npm run test:browser`) on Windows and macOS with Node 22 and 24. They explicitly enable the native browser cases that the broad CI suite otherwise skips; a missing browser fails this check. Cover full browser interaction, shared process lifetime and Wallet one-time-code entry. Deterministic startup fixtures also cover delayed discovery, transient readiness failures, exhausted recovery, child cleanup and redacted diagnostics.
+Run the focused real-browser checks (`npm run test:browser`) on Windows and macOS with Node 22 and 24. They explicitly enable the native browser cases that the broad CI suite otherwise skips; a missing browser fails this check. Cover full browser interaction, shared process lifetime, Wallet one-time-code entry and device-approval sign-in. Deterministic startup fixtures also cover delayed discovery, transient readiness failures, exhausted recovery, child cleanup and redacted diagnostics.
 
 ## Publish workflow
 

package/dist/expert/cli/voice-chat-ui.md

@@ -4,9 +4,11 @@
 
 ## The chat is the controller
 
-Expose a discoverable **Start voice chat** action in the existing chat, in the terminal dashboard, `ptbk chat` and the local desktop app. During the call expose **End voice chat**, microphone mute/unmute and output mute/unmute with the observed call state. Make shortcuts discoverable and keep them compatible with rich composition, paste and ordinary navigation. Retain the draft, thread selection, scroll and return location.
+Place **Start voice chat** alongside the regular composer in the open chat, both for an existing conversation and for a new chat after ordinary agent selection, even with zero messages. Use a visible button in the desktop composer and a discoverable in-chat action and shortcut in the terminal dashboard and standalone `ptbk chat`. Ordinary chat navigation is the sole way to choose the conversation. Voice entry and call controls belong exclusively to the chat view. Keep the project header, desktop feature bar and Chats list free of voice controls, voice-specific chat pickers and separate voice tabs.
 
-Show connecting, awaiting browser permission/activation, listening, speaking, muted, reconnecting, ending, ended and failed states from actual events, including the active speaker and selected tool where useful. Muting is not disconnecting or suspending provider billing. Normal text input and task cards remain available during the call. Incoming messages, captions and audio updates cannot submit text or steal focus.
+Bind the start and all subsequent voice controls to the chat displayed when the action is invoked. Navigating to another chat never retargets a pending or active call. When navigation closes the owning view, apply the normal [call cleanup](voice-chats.md#transcript-recording-and-recovery). During the call expose **End voice chat**, microphone mute/unmute and output mute/unmute in the owning chat with the observed call state. Make shortcuts compatible with rich composition, paste and ordinary navigation. Retain the draft, thread selection, scroll and return location.
+
+Show connecting, awaiting browser permission/activation, listening, speaking, muted, reconnecting, ending, ended and failed states from actual events, including the active speaker and selected tool where useful. Muting is not disconnecting or suspending provider billing. Keep the normal text composer, Send action and task cards available throughout the call. The user can submit a typed turn, then speak again without ending or restarting voice. Incoming messages, captions and audio updates cannot submit text or steal focus.
 
 Before starting, use common availability results. With no supported configured harness, explain which supported option to install/add and offer the shared Tools setup route. Distinguish login, version, entitlement and device problems with the correct next action. Do not send users through setup again merely because an unrelated registered harness lacks voice. Recheck after setup and permit a normal retry without losing the chat. Raw/noninteractive commands never launch an invisible browser call or wait for hidden permission input.
 
@@ -16,14 +18,19 @@ The media surface contains a simple animated orb or agent visual reflecting actu
 
 In the terminal, the dedicated browser page provides media and a minimal activation control for browser permissions or playback. Normal start/end/mute and transcript-presentation controls remain in the terminal. Keep the call usable with the media page in the background after setup. Closing it ends voice and the terminal reports the outcome.
 
-In the Windows/macOS app, embed the same media presentation, call controls and captions in the current chat. Obtain microphone permission for that trusted active voice surface under the [desktop permission rules](desktop.md#installation-and-isolation). The user can keep typing in the chat while speaking. Closing the owning voice surface or window ends the call and releases media.
+In the Windows/macOS app, embed the same media presentation and captions within the owning chat view alongside its call controls and composer. Obtain microphone permission for that trusted active voice surface under the [desktop permission rules](desktop.md#installation-and-isolation). Closing the owning voice surface or window ends the call and releases media.
 
 ## One visible conversation
 
-Show interim recognition as provisional; preserve final transcript messages in ordinary chat chronology with actual authors. Display **audio available**, interrupted or incomplete capture on the same message under [CHAT MESSAGE AUDIO](../book-language/commitments/chat-message-audio.md), distinct from supplemental attachment chips. Audio playback/replay is inspection and cannot resend the message. Human-facing spoken replies remain normal messages; only actual backend progress follows the usual Thinking collapse.
+Show interim recognition as provisional. Render accepted transcripts and typed messages together in ordinary chat chronology with their actual authors. Mark each spoken user or agent message with a visible **Voice** indicator, including while its recording finalizes. Use the existing [CHAT MESSAGE AUDIO](../book-language/commitments/chat-message-audio.md) binding as the durable indicator for recorded speech. Show the actual capture state (including interrupted, incomplete or unavailable capture) and replay for playable segments on that message. A typed message sent during a call keeps its ordinary presentation, and supplemental audio attachments keep their own attachment controls. Audio replay cannot resend the message. Only actual backend progress follows the usual Thinking collapse.
 
 When microphone access or playback needs action, identify it in the controlling chat. The terminal points to the existing media page and restores interaction focus to the same chat where the platform permits. The desktop presents the permission or activation in place. Speech interruption remains responsive while task status/results update. End/failure restores the ordinary text-chat presentation and keeps any draft.
 
 ## Acceptance outcomes
 
-Use start/end and both mute controls from dashboard chat, standalone chat and the desktop chat, including narrow terminals, composition, resize and preserved drafts. Verify actual states, speaker attribution, provisional/final captions, recording indication and reduced motion. Verify permission/activation guidance and confirm that closing the page or desktop voice view releases media without cancelling independent work. Replaying archived audio does not execute its transcript.
+Run the following from the actual chat screens in the terminal dashboard, standalone `ptbk chat` and the Windows and macOS apps.
+
+- Open chat B through normal navigation while another chat with the same agent exists. Start from B's composer and verify only B gets the call, transcript and audio. The chat view is the only launch location and ordinary chat navigation is the only chat selection. Changing views during connection cannot attach the call to a different chat.
+- Open a new chat using ordinary agent selection and start voice with an empty history. Verify media setup leaves the history empty and dispatches no reply. Speak the first user message and verify one normal Chat Book, the selected agent, normal first-message routing and a visible recording on the spoken message. Repeat with an unsent draft and with retry after a call setup failure, checking draft and Book identity.
+- In an existing chat, send text, start voice, speak, send another typed turn during the active call and then speak again. End voice, send text and start voice again. Verify one chronological history, each accepted input routed once and the new call aware of intervening text. Reopen the chat and verify that both speakers' recorded messages retain their indicators and replay, while typed messages have no voice indicator.
+- Use start/end and both mute controls with narrow terminals, composition, resize and preserved drafts. Verify actual states, speaker attribution, provisional/final captions, recording indication and reduced motion. Verify permission/activation guidance and that closing the page or desktop voice view releases media without cancelling independent work. Replaying archived audio does not execute its transcript.

package/dist/expert/cli/voice-chats.md

@@ -4,7 +4,9 @@
 
 ## Scope and entry
 
-Explicitly start realtime voice in the **existing Chat Book** from the terminal project dashboard, standalone `ptbk chat` or the local Windows/macOS app. New chats use the ordinary entry/agent selection first. Switching between typing and speech retains the same name, participants, instructions, messages, linked work and question state. No voice-only conversation store, replacement chat or implicit task is created.
+Realtime voice is an input and output mode of an ordinary chat. In the terminal project dashboard, standalone `ptbk chat` and the local Windows/macOS app, [start voice from the open chat](voice-chat-ui.md#the-chat-is-the-controller). That chat's stable Book identity determines the target for the whole call. Opening, ending or restarting voice preserves the chat's name, participants, instructions, messages, linked work and pending questions.
+
+Both a reopened chat and a new chat with its ordinary agent selection complete offer the same start action. In a new chat, the first input may be speech. If its Book has yet to be saved, create it through ordinary chat creation and [naming](generated-names.md) before attaching media. Voice start and first text send share a single creation for that new chat view, including concurrent actions and retries. Only an actual submitted message or accepted utterance enters history and triggers ordinary [first-message routing and MODEL resolution](chats.md#entry-and-model-chronology).
 
 The client, audio devices and project engine are on the same computer. A plain SSH session to a VPS does not carry the local microphone. Explain the limitation and keep text chat available. Remote App/relay media is a future integration.
 
@@ -22,6 +24,8 @@ Observe liveness of the controlling client and media surface. Restore focus to t
 
 Support listening and speaking concurrently, natural pauses and the user speaking over an answer, while backend work continues. The initial requirement is a live conversation comparable in interaction to ChatGPT Voice, not alternating record/upload/play turns. Latency and Czech speech quality must be checked with a real microphone/provider rather than inferred from a text fixture.
 
+Accept typed messages through the ordinary composer while voice is live. A submitted text message participates in the same routing, questions and work as any other user message and reaches the live session once as part of the shared history. Subsequent turns use accepted text and speech transcripts as context in either mode. Restarting voice uses the current chat history, including messages sent while voice was off. Typing, changing focus or toggling voice preserves the unsent draft.
+
 Barge-in promptly stops spoken playback; the adapter reconciles the actually heard boundary. It does **not** itself cancel a task, revert files or undo a remote action. Interpret the added speech in context through the responsible agent and ordinary [task control](task-control.md): a correction may steer work, a cancellation may stop it, and a request to listen may only stop speaking. Keep Saved/Delivered/Applied and confirmed/pending cancellation truthful. Do not ask for repeated task authorization solely because the channel changed to voice.
 
 Use normal agent/persona instructions, participants, delegation and substantive-work boundaries. A task's progress/result can reach the conversation without blocking further speech; the spoken agent must not report completion that the backend has not established. Preserve actual authors when another agent joins or asks a question. Voice is an explicit chat interaction during engine Pause, like text chat; task work and task-advancing continuations remain paused. Stop/force stop/panic remain authoritative.
@@ -38,6 +42,6 @@ Ending the call or closing or losing its media surface or controlling client sto
 
 ## Acceptance outcomes
 
-Start from an existing terminal dashboard chat, standalone chat and the Windows/macOS app. Type, speak, interrupt and return to typing in the same Book. Verify one shared history, live two-way Czech speech, relevant task management, actual authors and continued independent work. In Pause, voice discussion works while task execution stays paused. Stop/panic ends capture and provider voice resources. Reject unsupported/SSH cases actionably without exposing remote audio or starting hidden work.
+Run the [chat UI scenarios](voice-chat-ui.md#acceptance-outcomes) through the normal entry points. Verify voice-first creation, text sent during a live call and later calls all use one ordered Book and one dispatch per accepted input. Verify live two-way Czech speech, relevant task management, actual authors and continued independent work. In Pause, voice discussion works while task execution stays paused. Stop/panic ends capture and provider voice resources. Reject unsupported/SSH cases actionably without exposing remote audio or starting hidden work.
 
 Run the terminal flow with the project HTTP dashboard/server absent and the desktop flow without a temporary feature server. Exercise microphone permission/autoplay/device denial, duplicate viewers, reload/closure, client failure, network/provider loss and explicit end with no orphan microphone, call or listener. Recover partial recordings, late finalization, disk/Git failure and a long call with bounded commits. Check default Git contains the actual user/agent audio and Book bindings, overlap/interruption is honest, and reconnect/transcript/media replay never duplicates messages, tasks or external effects.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "ptbk",
-    "version": "0.119.0-79",
+    "version": "0.119.0-80",
     "description": "Autonomous AI agendas on your machine. Readable agents, your choice of models, and Git history under your control.",
     "private": false,
     "sideEffects": false,