` that bypasses markdown and linkify, so its text never contained NBSP. Rich-paste targets could still pick up the HTML flavour of the selection, which no longer goes on the clipboard. - The External MCP Servers panels in the MCP status modal show each server's name again, and say where it came from (`frontend/src/components/MCPStatusModal.tsx`, `app/mcp/manager.py` `server_sources` / `get_server_sources()`, `app/routes/mcp_routes.py` `/api/mcp/status` gains `server_sources`; tests `tests/test_mcp_server_sources.py` and `frontend/src/components/__tests__/mcpStatusModalServerName.test.tsx`, new). The header showed the one-line description *instead of* the `mcp_config.json` key whenever a description existed, so a registry-installed server had no visible name. The header now shows the name in bold with the description beside it. The expanded panel gains a Source row: built-in (and whether a config file overrides it), contributed by a plugin, installed from a registry (provider and service id), or declared in a config file (with its path). It also notes when the stanza uses keys Kiro, Q Developer or Claude Code write (`transportType`, `disabled`). Provenance is held beside `server_configs`, not inside it, so it is never written back to the config or shown in the Config Stanza tab. A stanza another tool wrote in Ziya's own format can't be told apart from a hand-written one. - The phantom-diff correction pass can no longer close with "no diff is needed" while the turn's own tool output still names the error (`app/utils/phantom_diff.py` `find_unresolved_errors`, `app/utils/diff_validation_hook.py` `tool_outputs=`/`phantom_evidence`, `app/server.py`; tests in `tests/test_phantom_diff_reference.py`, +9). Incident 2026-10-25: a turn's `tsc` run reported `error TS18004 ... 'stave'` and its jest run `ReferenceError: stave is not defined`, the response said "once the stave-scope diff above is applied" and ended, the detector fired — and the correction pass grepped for the symbols of *earlier* diffs, found them, and answered that nothing needed re-emitting. Two causes. The pass was blind: `server.py` appended only the feedback as a new user turn, never the assistant turn being corrected, so the sanitizer merged the feedback into the user's previous message and the model had no record of what "the diff above" referred to; the response being corrected is now appended as an `AIMessage` first. And the feedback offered the lazy exit unconditionally: compiler / type-checker / test-runner error lines (`path(l,c): error ...`, `ReferenceError: ...`, `XError: ...`) from this turn's tool results are now collected and quoted in the correction request, which then withdraws "no diff needed" and accepts only the fence, or a quote of the later tool output showing the error gone. Without such evidence the wording is unchanged. - Bead tools now act on the conversation's real home record when the conversation is driven from a window open on another project (`app/storage/beads.py` `_resolve_chat_storage`; test `tests/test_bead_cross_project_home.py`, new). A global conversation surfaced into another project's sidebar is stored under its own project, but bead storage resolved the record by the window's project and found nothing there, so every bead read and write went to the standalone fallback file: the model saw an empty tree, "closed out" the same stale beads turn after turn, and they came back parked; a later turn from the home window then rewrote the record and deleted the fallback with the other window's writes in it (incident 2026-10-25, conversation 31fa660d). The 2026-10-02 `resolve_chat_home` rule already used by context tools, auto-context and handoff is now applied to beads too. - The probationary proposal log is now safe under concurrent Ziya processes (`app/storage/proposals.py`; test `tests/test_proposals_store_cross_process_lock.py`, new). The log is encrypted as one envelope, so every append is a full read-decrypt-rewrite, and it was guarded by an in-process `RLock` only — the store's own docstring said cross-process coordination was "not provided". With 10+ servers on one `~/.ziya`, two appends in the same window both read N events and both wrote N+1: the second rename won and the first process's event was gone, and because both used the same `.jsonl.tmp` path the loser crashed on a rename of a file the winner had already moved. A six-process test reproduced both the crash and the lost updates; the live log carried the other fingerprint, a duplicate `record` event for one id. An `fcntl` advisory lock on `probationary.jsonl.lock` now wraps every read-modify-write (`_append`, `prune_terminal`). It only serialises — nothing about which events are written changes — and the test asserts every append is present exactly once afterwards. - Memory extraction no longer re-runs every earlier window of a conversation on every turn (`app/memory/extraction_cursor.py`, new; `app/memory/extractor.py`; tests `tests/test_extraction_window_cursor.py`, new). The server dispatches extraction after every stream with the full non-muted history, and topic windows are prefix-stable, so a 200-turn conversation paid triage plus ~25 extraction calls per turn for output dedup then discarded. Each conversation now records the hash of every window it has extracted (one file per conversation under `~/.ziya/memory/extraction_cursors/`, so concurrent servers never race); an unchanged window is skipped, and a window whose text changed — the trailing window growing, or a turn being muted — is extracted again. Lost or corrupt cursor state only costs a re-extraction. - Every timestamp the model is shown now carries its UTC offset, in one form (`app/utils/session_context_prompt.py` `format_prompt_timestamp`, new; `app/utils/precision_prompt_system.py`; `app/utils/project_change_note.py`; test `tests/test_prompt_timestamps_carry_offset.py`, new). ``, `` and the per-message `` tags were naive local wall-clock times (`2026-10-23 23:51:04`) with nothing saying which clock they were on, while the project-change note in the same transcript was stamped UTC and tool output (`date`, git, file mtimes) carried its own zones; a model asked to reason about elapsed time had to guess the zone and spent turns reconciling them. All four now read `2026-10-23 23:51:04-07:00` (local time with offset) and the "Message Timing" paragraph in the system prompt says so. An aware `now=` passed by a caller keeps its own offset rather than being converted to the machine's. - Reloading a browser tab now reopens the project that tab had open (`frontend/src/context/ProjectContext.tsx`, `frontend/src/utils/tabState.ts`; test `frontend/src/context/__tests__/tabProjectStickiness.test.ts`, new). The conversation id was already per-tab, but the project was remembered only browser-wide (`ZIYA_LAST_PROJECT_ID` in localStorage), so switching projects in one tab and reloading another moved the second tab to the first tab's project — and then off its saved conversation, which belonged to the original project. A per-tab, instance-scoped `ZIYA_TAB_PROJECT_ID` in sessionStorage is now consulted first on init and by `readLastProjectId()` (which ChatContext uses to scope the startup conversation list); new tabs still open the browser-wide last project, and a stored id the server no longer knows is dropped. A tab's own project also outranks the `--root`/`--directory` startup project on reload: that rule is for new sessions. - The streaming Bedrock client never recovered from "input length and `max_tokens` exceed context limit", although `CustomBedrockClient` documents that it shrinks `max_tokens` and retries (`app/utils/custom_bedrock.py`; tests `tests/backend_system_tests/model/test_custom_bedrock.py`). The reduction sat in an `elif` reachable only with a conversation id, on an extended-context model, for an error that was NOT an overflow — so it never ran for the one error it parses. It now runs after the extended-context branches. The non-streaming path was unaffected. - `ziya chat` on `--endpoint openai` with a GPT-5.x / 6.x model failed its no-tools path and the `/quit` tangent summary with `400 Unsupported parameter: 'max_tokens'` (`app/agents/wrappers/openai_direct.py` (`DirectOpenAIModel(max_tokens_param=)`), `app/agents/models.py` (`_initialize_openai_model`); test `tests/test_openai_direct_max_tokens_param.py` (new)). The provider path already sent the model's `max_tokens_param`; the legacy wrapper `ModelManager.initialize_model` builds hard-coded `max_tokens`. Found by the real-API capability tests. - Stale tests under `tests/backend_system_tests/model/`: ten Nova wrapper modules imported `app.agents.nova_wrapper`, which moved to `app.agents.wrappers.nova_wrapper` in 0.3, and two computed the source path from the wrong directory; `test_ziya_bedrock.py` followed the server-default model, so once that became Sonnet 5.5 (no sampling parameters) its temperature/top_k checks failed. The Nova suites go from 0 to 31 passing; the rest is listed in the session notes, not fixed. - `tests/backend_system_tests/model/test_model_connections.py` asserted nothing (every test patched `ModelManager.__init__` and read back what it had just set) and errored on fixtures no conftest has defined since `01c97e40`. It now resolves every configured model, every alias (against its target) and every endpoint default through the real `ModelManager.get_model_config`, offline: 160 tests. - `get_skill_details` could not load any project or user skill by name (`app/mcp/tools/skill_tools.py`; covered by the previously failing `tests/test_project_skill_wiring.py` and `tests/test_skill_resources.py`). The lookup called an undefined `_request_project_root()`; the `NameError` was caught and logged at debug level, so the model was told "Skill 'X' not found" and offered only the built-ins. It now uses `get_project_root_or_none()`. - Skills inside grouping folders are actually discovered (`app/services/skill_discovery.py` (`iter_skill_dirs`, `MAX_SKILL_DEPTH`), `app/services/skill_sources.py` (`LocalFolderSource._dir_for`, `_version_of`); `tests/test_nested_skill_discovery.py` now collects and passes). The 0.8.10.0 entry and `Docs/Skills.md` described this, but the walker was never committed, so every scanner still read only a root's immediate children and the test module failed at import. A local or git skill source also now finds a skill by leaf name instead of `root / skill_id`, which no longer resolves a `../` id outside the source. - `tests/backend_system_tests/model/test_model_connections.py` and `test_model_transactions.py` failed at collection with `KeyError: 'sonnet'`; they now resolve the alias through `MODEL_ALIASES`. Their tests still error at run time on fixtures (`mock_aws_credentials`, `setup_test_environment`) that no conftest has defined since refactor `01c97e40`. - Memory relation extraction threw away the most connected batches (`app/memory/organizer.py` (`RELATION_MAX_TOKENS`, `_salvage_json_array`); tests in `tests/test_memory_organizer.py`). The relation reply was capped at 1024 tokens. With memory ids that dense, that is about 29 relations, and a 20-memory batch often returns more. The reply was cut off mid-string, `json.loads` rejected the whole array, and the batch stored nothing, which showed up as `Relation extraction: JSON parse failed: Unterminated string …` on roughly one batch in five. The cap is now 4096 tokens. A reply that is still cut off keeps every complete relation before the cut and logs `reply truncated … kept N complete relations`. A reply that is not JSON at all still logs the original warning. - On a fresh install, dragging a skill onto the Bench's on-hand lane failed with "Could not move …" and a `404` on `PUT /bench/place` (`app/api/bench.py` (`_view_model` now takes `project_id`), `app/services/bench.py` (`conversation_known`); tests in `tests/test_bench_api.py`). The hub opens on the conversation lens whenever a chat is open and relies on the server's `lenses` list to fall back to `project` when that chat has no record, but the view model listed the lens whenever an id was *passed*, not when the chat *existed*. A brand-new "New Conversation" is an empty shell the client never sends to the server, so every drop wrote to a conversation layer that `ChatNotFound`-ed. The lens is now offered only for a chat the server holds; an unsaved chat lands placements at the project layer, and the conversation lens appears once the chat has a message. - A long list of always-on skills filled the top of every sidebar tab (`frontend/src/components/ActiveContextBar.tsx`; test `frontend/src/components/__tests__/ActiveContextBar.stack.test.tsx` (new)). The active-context bar is mounted above the file tree, the skills tab, the chat list and the backlog, so sixteen on-hand skills wrapped into six rows of pills on each tab and pushed the chat list below the fold on a laptop screen. The bar now shows the first four always-on skill pills and stacks the rest behind one `+N skills ▸` chip whose tooltip names them; clicking it unstacks (restoring each pill's X). A `▴` control folds the whole row to one line — a colour dot per always-on skill (twelve, then `+N`), a dashed ring per skill the model loaded on demand this turn, and a `16 on hand · 1 ✦` count; clicking the line returns to whichever of capped/all was in use. Both choices are remembered per project. With four or fewer always-on skills nothing stacks and neither control appears. Solid pills still mean "sent with every turn"; a dashed ✦ pickup is never stacked. - The model was intermittently shown doubled braces in the file context — `{{a,b}}` for `{a,b}`, `${{x}}` for a TS template literal `${x}` — and could carry them into its answers and diffs (`app/utils/precision_prompt_system.py`; test `tests/test_codebase_braces_not_escaped.py` (new)). The codebase was brace-escaped before being passed as the `{codebase}` template *variable*, but `str.format` never re-parses substituted values, so the escape protected nothing and reached the model verbatim. A guard skipped it whenever any file in context already contained a `{{` (JSX `style={{…}}`), so the corruption appeared and vanished with the set of files in context: a markdown-only context was corrupted, the same file beside a `.tsx` was not. The escape is removed. - Conversation search silently returned partial results ("missing terms") (`app/utils/chat_search_index.py` (new), `app/storage/chat_search.py` (`_candidate_files`), `frontend/src/components/MUIChatHistory.tsx` (`performSearch`), `frontend/src/utils/db.ts` (`lastSearchSource`); tests `tests/test_chat_search_index.py` (new), `frontend/src/components/__tests__/chatSearchStaleAndFallback.test.ts` (new)). Every search opened, decrypted and parsed every chat file in scope, which on a 2,350-chat install took 8.9 s for one all-projects search. The sidebar starts a search per debounced keystroke and never cancelled the earlier ones, so overlapping scans went past the browser's 25 s deadline, and the client then fell back to scanning IndexedDB, which only holds the bodies of conversations opened in that browser. Search now goes through an in-memory filter: one 6.3 KB bitmap per chat of the character trigrams in its text, built on first search and refreshed by file mtime and size, so writes by other processes are picked up. Only chats that can contain the query are read, and the matcher is unchanged, so results are identical to a full scan; warm, the filter takes about 20 ms. Queries with no three-letter run of `[a-z0-9_]` (for example `2.1%`) still scan in full. Concurrent searches wait for one build instead of each scanning. A response superseded by a later keystroke no longer overwrites the newer results, and a result from the local fallback now shows a warning that it may be incomplete. Kill switch: `ZIYA_DISABLE_CHAT_SEARCH_INDEX=1`. - Reading another conversation by id took minutes when its turns were tool-heavy or it lived in another project (`app/mcp/tools/chat_history_tools.py`, `app/storage/chat_search.py` (`_candidate_files`), `app/utils/tool_history_rewrite.py` (`collapse_tool_blocks`); tests `tests/test_chat_read_tool_heavy_and_scoped_search.py` (new), `tests/test_chat_search_conversation_ids.py`). In the case that exposed it, one assistant message was 534,000 characters, nearly all tool output, and `chat_read` truncation kept only the first tool body, so the model never saw that turn's conclusions. Its fallback, `chat_search` with `conversation_ids`, found nothing until `all_projects=true` was added, and then every call decrypted every chat file in every project before applying the id filter (7–22 s per call, about 70 calls). `chat_read` now collapses tool blocks to one-line stubs by default (`tool_results="summary"`; `"full"` restores the raw view). Ids passed to `chat_search` are looked up directly through the chat index, in whichever project owns them, and only those files are read. - A handed-off conversation showed two rows at its end, "The model drafted a handoff document" and "Handed off to …", both with the same "Continue in …" link. Once the "Handed off to …" notice exists, the drafted-document notice is no longer shown (`isSupersededHandoffNotice` in `frontend/src/components/HandoffNotice.tsx`, applied in `Conversation.tsx`). A conversation handed off before that notice existed still shows the drafted notice as its forward link. - A parallel tool group's container swallowed every later tool call and paragraph of the message. The server relay dropped the `tool_group_end` event, so no group was ever closed. The relay now forwards it in both the main and the diff-validation retry loop, and a group whose end marker is missing now closes once all its members have arrived, which also repairs messages already recorded without it. - **The release sweep no longer blocks a release on a group whose work already shipped, or defers files over a previous release's triage** (`scripts/release_plan.py` (`batches` mode), `design/sweep-orchestrated.task-card.json` (P0, P3a, commit loop, P5); tests `tests/test_release_plan_batches.py` (+2), `tests/test_sweep_orchestrated_card.py` (+2)). Run cli-188224db41e6 committed 222 groups, then stopped at the release gate for two reasons. First, one commit also carried a file the plan assigned to another group. That group then found nothing to stage, took the "already committed" exit without recording its id, and the gate kept treating it as outstanding. A group whose content is already at HEAD (whole files clean, or every patch reverse-applies) is now recorded with the commit that carries it, by the commit loop and again by the residue stage. Second, 56 paths were deferred because triage batches from the previous release still counted them as triaged, although their verdicts named entries the current Unreleased section lacks. P0 now archives triage batches older than the last release tag, and `release_plan.py batches` re-batches any `assign` verdict whose entry is no longer in the index, listing it under `stale_assigns`. The next run (cli-db2df7ec03ba) then stopped at P4a because every entry was already committed or deferred and the commit-plan contract demanded at least one group; the contract now also accepts an empty roster carrying a non-empty `already_committed_entries` list, so the run reaches P6, which is the stage that reports the deferral. The commit loop and residue sweep also carry a `time_budget_secs` (600 s and 900 s), after one Bedrock stream in the serial loop sat silent for 26 minutes (cli-4d15fd5c2684) before the 900 s thinking ceiling and 300 s socket timeout released it. (`design/sweep-orchestrated.md`; tests `tests/test_sweep_orchestrated_card.py` (+2)) - **Moving the conversation you are viewing to another project now takes you with it** (`frontend/src/context/ChatContext.tsx`, `frontend/src/components/MUIChatHistory.tsx`; test `frontend/src/context/__tests__/moveFollowsConversation.test.ts`). Previously the move dropped the conversation from view and selected a different conversation in the source project. Now the move saves locally and on the server, switches to the target project, and keeps the conversation on screen and selected while the rest of that project loads. Moving any other conversation works as before. A moved conversation that was global now has the flag cleared on the server as part of the move. The sidebar used to run a separate toggle after the move, and with the conversation now kept in view that toggle would have made it global again. - **Shell env-prefix bypasses closed** (`app/mcp_servers/shell_server.py`; test `tests/test_shell_env_prefix_path.py`). `PATH=/tmp ls` was accepted because the allowlist matched `ls`, but the child resolved it through the prefixed PATH and ran `/tmp/ls`. A `PATH=` prefix is now allowed only when it resolves the command to the same file the normal PATH does, so `PATH=/opt/x:$PATH cmd` still works; a PATH built from any other expansion is refused. Inside `if`/`while`/`for` bodies, a segment starting with `NAME=value` was skipped as an assignment, so `FOO=1 anycmd` ran anything and `LD_PRELOAD=` escaped the loader-hijack block. The prefix is now peeled and the command behind it checked, as at top level. - **Startup warns about the obsolete PyPI `asyncio` backport** (`app/utils/asyncio_backport_check.py`, wired in `app/main.py`; test `tests/test_asyncio_backport_check.py`). `asyncio` 3.4.3 from PyPI (declared by some third-party packages, e.g. `mcp-shell-server`) does not parse on Python 3.7+. Any environment that puts site-packages ahead of the standard library imports it and fails with `SyntaxError: tasks.async(...)` inside an unrelated import. The server now prints its location and the `pip uninstall asyncio` command at startup. Warning only. - **Shell allowlist accepts `read`, and quoted or absolute command words** (`app/mcp_servers/shell_server.py`, `app/config/shell_config.py`; test `tests/test_shell_command_word_and_read.py`). `… | while read line; do …; done` was refused with `'read' is not allowed`. `read` is now in the built-in floor; both `sh -c` routes run with stdin closed, so it can only read what the command itself pipes in. `"ls" -la` and `/bin/ls -la` were refused although `ls` is allowed. The command word is now unquoted, and an absolute path counts as its basename only when PATH lookup resolves to that same file, so a copy written elsewhere (`/tmp/ls`) is still refused. The aws, curl and IaC guards see the normalized word, so `"/usr/bin/curl" ` is refused exactly like `curl `. Refusals now name the whole command (`'/Applications/Google Chrome.app/…/Google Chrome' is not allowed` rather than `'"/Applications/Google'`). - **`~/.ziya/file_states.json` backups are bounded, and the state file is written atomically** (`app/utils/file_state_manager.py`; test `app/utils/tests/test_file_state_backups.py`). When the state file couldn't be read at load, it was moved to `file_states.json.backup.` and tracking was reset. Nothing ever read or deleted those backups, and one install had 476 of them (3.6 GB, the largest 1 GB). Only the newest 5 are now kept, and older ones are pruned at the next server start. The state file was also written in place, so a second server sharing `~/.ziya`, or this server's own next load, could read a half-written file, fail to decrypt it and discard the live state as "corrupted". Saves now write a temp file and rename it over the original. - **Production frontend builds drop `console.log` / `console.debug` / `console.trace`** (`frontend/craco.config.js`, `frontend/src/context/ChatContext.tsx`, `frontend/src/plugins/d3/vegaLitePlugin.ts`; test `frontend/src/utils/__tests__/consoleStripBuild.test.ts`). About 1,500 log calls shipped, several on per-flush and per-save paths, and once DevTools has been opened the console keeps every logged object alive for the life of the page. Terser `pure_funcs` now removes the calls in production builds; arguments with side effects still run. `console.warn`, `console.error` and `console.info` are kept, and development builds are unchanged. `window.debugChatContext()`, `debugIndexedDB()` and `debugVegaLite.inspect()` print through `console.info`, so they still work in production. Three temporary `console.trace` diagnostics were removed, including one that ran on every save. The server's end-of-turn `COMPLETE MODEL RESPONSE` log is Python logging and is unaffected. - **The production console strip now catches the log calls it missed, and keeps `render_diagram`'s rewrite notes** (`frontend/craco.config.js`, `frontend/src/utils/colorUtils.ts`, `ChatContext.tsx`, `StopStreamButton.tsx`, `StreamedContent.tsx`, `plugins/d3/*`, `D3Renderer.tsx`, `utils/diagramUtils.ts`; codemod `scripts/console_info_rewrites.py`; tests `frontend/src/utils/__tests__/consoleStripBuild.test.ts`, `frontend/src/utils/__tests__/rewriteNotesSurviveStrip.test.ts`, `tests/test_console_info_rewrites_codemod.py`). Terser's `pure_funcs` only drops a literal `console.log` whose value is unused, so two shapes survived: an alias (`colorUtils`' `const log = debug ? console.log : …`, which printed every mermaid/graphviz/drawio contrast line, about 230 lines per stream end) and expression-bodied arrows (`m => console.log(m)`). Both are now block-bodied, `console.group`/`groupCollapsed`/`groupEnd` are stripped too, and a source scan fails the build's tests if either shape comes back. Stripping `console.log` had also silenced the `🔧 TAG: …` lines the headless renderer reads to tell the model how preprocessing changed its spec, because `/render` loads the production bundle. The 177 such reporters in the diagram code now print through `console.info`, which survives the strip; the other 🔧 logs (chat, sync, sidebar) stay stripped. - **Collapsed tool results no longer highlight or parse their body on mount** (`frontend/src/components/MarkdownRenderer.tsx`; test `frontend/src/components/__tests__/toolBlockLazyHighlight.test.tsx`). `GenericToolBlock` shows only the digest preview while collapsed, yet ran Prism and `marked.parse` over the full payload on mount and kept the HTML in state, for every file read and MCP result in history. Its header effect also inline-parsed the whole payload when there was no summary, for a header only hierarchical search results display. Both body effects now wait for the first expand, and the header parse runs only for hierarchical results. Short results that never collapse still highlight on mount, and the 150 K-character highlight cap stays for expanded results. Shell and shadow output render through `TerminalPane` and are unaffected. - **Saves and cross-tab updates no longer read the whole IndexedDB store** (`frontend/src/context/ChatContext.tsx`, new `frontend/src/utils/idbTargetedRead.ts`; test `frontend/src/utils/__tests__/idbTargetedRead.test.ts`). `queueSave` read every conversation in every project, with full message bodies, as the base for its merge on effectively every save (React state almost always holds deferred shells, which disabled the cached path), and the `conversations-changed` broadcast handler did the same in every other open tab on every save. Both now read only the conversation ids they act on (`changedIds` / the broadcast's `ids`), which produces the same written records because nothing outside those ids reaches the write. Saves without `changedIds` still read the whole store. The 5-minute other-project cache, whose branch became unreachable, is removed. - **A reloaded tab reopens its conversation even when IndexedDB holds no conversation list** (`frontend/src/context/ChatContext.tsx`, `ProjectContext.tsx`; test `frontend/src/context/__tests__/restoreAfterPlaceholder.test.ts`; diagnostic `scripts/mem_probe/startdiag.mjs`). With no IndexedDB shells (cleared site data, an IndexedDB repair, a restored tab whose session storage outlived its IndexedDB), startup ended with an empty list and set a placeholder id; the restore effect only ran when there was no current id, so the saved conversation was never selected and the tab showed "No messages in this conversation yet" until, 60 s later, recovery switched to the most recent conversation instead. The placeholder is now recorded and replaced by the restore while unused, and the restore opens the conversation through `loadConversation` so a deferred shell loads its messages. The startup project filter and server fallback also read the instance-scoped last-project key (new `readLastProjectId()`); the unscoped key they read before is never written. - **Committed diffs no longer rebuild when another turn starts or ends streaming** (`frontend/src/components/MarkdownRenderer.tsx` `DiffViewWrapper`; test `frontend/src/components/__tests__/committedDiffStreamingRemount.test.tsx`; probe `scripts/mem_probe/probe.mjs --domtrace`). `DiffViewWrapper` chose between two render branches with different element trees using the conversation-wide streaming flag, which flips for every message at send and at stream end. On a 100-message conversation with 12 diff-bearing messages, each flip tore down and rebuilt ~23 K elements of history and the tab's DOM node count briefly went from 65 K to 139 K at send and 180 K at stream end, with nothing on screen changing. The wrapper now follows the streaming state of the message that owns the diff, which is always false for history, so only the diff still arriving in the live turn takes the streaming branch. - **A reader scrolled up is no longer pulled to the bottom when a reply finishes** (`frontend/src/hooks/useScrollManager.ts`; test `hooks/__tests__/useScrollManagerNotify.test.tsx`). When a stream ended, its streamed-content entry was cleared and the scroll manager read the length dropping to 0 as "a new user message was sent": it forced a scroll to the end 100 ms later and cleared the "completed while you were away" indicator the moment it appeared. Measured with `scripts/mem_probe/streamend.mjs --where reading`, the message being read moved 3,465 px in 11 jumps. The drop now only re-baselines the length, so the reader stays put and the indicator stays until they scroll down or click it; the next turn's "new content below" indicator also works when the reply is shorter than the previous one. Sending a message and switching conversation still scroll to the end (`App.tsx`), and a user pinned to the bottom is still held there while the finished message settles. - **Streaming no longer re-renders the whole app on every flush** (`frontend/src/context/StreamedContentContext.tsx` new; `ActiveChatContext.tsx`, `ChatContext.tsx`, `hooks/useScrollManager.ts`, `hooks/useSendPayload.ts`, `components/App.tsx`, `Conversation.tsx`, `StreamedContent.tsx`, `SendChatContainer.tsx`, `ExportConversationModal.tsx`, `RawMarkdownView.tsx`, `MarkdownRenderer.tsx`; tests `context/__tests__/streamedContentIsolation.test.tsx`, `hooks/__tests__/useScrollManagerNotify.test.tsx`). `streamedContentMap` (replaced every 150 ms) and `reasoningContentMap` (replaced on every thinking delta) were part of the `ActiveChatContext` and `ChatContext` values, and `App` read the map directly, so every flush re-rendered `App`, the sidebar, the modals and every history message. A sampled heap profile of one 100 s stream measured 18.4 GB allocated (~180 MB/s), almost all antd/MUI styling and React bookkeeping, and V8 old space filled with the promoted garbage (108 → 471 MB in 80 s) faster than it was collected — the main cause of browser windows growing to tens of GB with a few streaming tabs. The maps now live in their own context: only `StreamedContent`, live thinking blocks and an open raw view subscribe; `Conversation` reads a presence set that changes only when a stream starts or ends; send and export read the maps at call time through a ref; and `App`'s scroll manager is fed by a child watcher (`useScrollManager` gains a stable `notifyContentLength`; `contentLength` is now optional). A second per-chunk trigger went through the same contexts: `chatApi` calls `setProcessingState('idle')` on every content chunk, and `updateProcessingState` built a new Map each time even when the state was unchanged, giving `getProcessingState` a new identity and re-rendering the sidebar, header and closed modals per chunk. It now returns the existing Map when the state is unchanged (test `context/__tests__/processingStateNoOp.test.ts`). Same stream, same 100-message conversation, before → after both changes: 18.4 GB → 0.5 GB sampled allocations (186 → 4.9 MB/s), JS heap peak 575 → 159 MB, renderer RSS peak 1.43 → 0.90 GB. - **Launching delegates no longer downloads every message in the project** (`frontend/src/utils/delegateLaunchSync.ts` new; `frontend/src/components/DelegateLaunchButton.tsx`; test `frontend/src/utils/__tests__/delegateLaunchSync.test.ts`). After a launch, the button refreshed the sidebar by calling `listChats(projectId, true)`, which returns every chat in the project with its full message history (363 MB and 25–33 s on a large project), and parsed all of it in the tab to find the few new chats. The launch response already names them (`orchestrator_id` and `conversation_ids`), so only those ids are now fetched with `bulkGetChats`. If the fetch fails, the periodic sync picks the chats up. - **Streaming code blocks no longer rebuild their DOM on every flush** (`frontend/src/components/MarkdownRenderer.tsx` `CodeBlock`, `renderTokens`; test `frontend/src/components/__tests__/codeBlockStreamingDomChurn.test.tsx`; probe `scripts/mem_probe/probe.mjs`). Browser windows with a few Ziya tabs swelled to tens of GB. Measured with a headless CDP probe: idle tabs allocate ~0.2 MB/100 s, but a streaming tab's renderer RSS sawtoothed 0.4 → 2 GB while its JS heap stayed under 300 MB — the growth was Blink-side DOM garbage. Each 150 ms flush re-ran Prism on the still-open code block and wrote it via `dangerouslySetInnerHTML`, then an effect ran Prism again, serialized `innerHTML` and wiped/rebuilt the subtree a second time, destroying and recreating every highlighted span; closed blocks earlier in the message also re-ran Prism on every flush. The arriving block now renders as a single text node (updated in place) and is highlighted once when it closes, settled blocks memoize their highlight on the text, and tool results over 150 K characters are shown unhighlighted (a 300 KB result blocked the main thread for 34 s). - **Autoscroll lands on the real end, not the top of the last block** (`frontend/src/hooks/useScrollManager.ts`; test `frontend/src/hooks/__tests__/useScrollManagerFollow.test.tsx`, new). Follow mode pinned to the bottom in a rAF when the streamed text changed, but a tool fence or thinking block renders its body a frame later, and while "Waiting for model response…" nothing changes the text at all, so the view sat on the block's header with the body hidden beneath the sticky composer dock. The hook now also observes the content box with a `ResizeObserver` and re-pins on any layout growth while following — during the stream and for 1.5 s after it ends — and no longer reads the browser clamping `scrollTop` after a shrink (a thinking block collapsing) as the user scrolling away. Scrolling up still leaves follow mode; returning to the bottom re-enters it. - **Header's signature poll no longer floods the log with "escalation denied"** (`app/utils/scope_approvals.py` `is_scope_authorized_with_reason(log=)`, `app/api/task_cards.py` `_escalation_rows`; tests `tests/test_scope_authz_query_path_is_quiet.py`). The server log repeated dozens of `SCOPE_AUTHZ: no approval record for task 'b-…' — escalation denied` lines every few seconds although no task was escalating: the Task Cards header indicator polls `/task-cards/signature-summary` on every window focus from every open tab, and that read-only query asked the approval predicate about every escalating block of every card, which logged each "not signed" answer as a refused escalation. The two UI queries (`/signature-summary`, `/{id}/scope-status`) now ask with `log=False`; the reason code they display is unchanged, and the runtime gate (`is_scope_authorized`, used by the task runner, `ziya-approve` and the scope audit) still logs every real denial. - **Offline no longer reported as a credential failure** (`app/providers/bedrock_client_cache.py`, `app/utils/custom_exceptions.py` `ProviderUnreachableException`, `app/utils/infra_errors.py` `is_auth_failure`, `app/server.py`; tests `tests/test_bedrock_client_cache.py` `TestCredentialPreflightClassification`, `tests/test_infra_errors_credential_network.py`). With DNS or the network down, the Bedrock client's STS pre-flight raised `EndpointConnectionError`, which was rewrapped as "AWS credentials check failed: Could not connect to the endpoint URL" and shown in chat as the re-authenticate banner. A network-shaped pre-flight failure now raises `ProviderUnreachableException` (a `KnownCredentialException` subclass, so the startup handlers still keep the server up) whose message names the STS host and says to check the network; `is_auth_failure` returns False for it and the stream emits `error_type: connection_error`, which the frontend renders as *Connection Failed* with a retry button. Expired/invalid tokens still classify as auth. - **Local model server out of memory gets its own banner** (`app/utils/provider_error_chunks.py` new, `app/streaming_tool_executor.py`, `frontend/src/utils/modelMemoryErrorBanner.ts` new, `frontend/src/apis/chatApi.ts`; tests `tests/test_provider_error_chunks.py`, `frontend/src/apis/__tests__/chatApiModelMemoryError.test.ts`). An oMLX prefill memory-guard rejection (or a llama.cpp / Ollama OOM) arrived as an untagged error chunk, so the server relayed `error_type: unknown` and the chat showed the generic collapsed "Error Details" block with the raw text. Non-auth provider errors are now shaped by `build_provider_error_chunk`, which tags recognised memory-ceiling messages `model_memory_error`; the frontend renders *Model Server Out of Memory* with the server's needed-vs-limit figures pulled out, the three remedies (shrink the prompt, free RAM, raise the server's ceiling) and a retry button, with the raw text under *Technical details*. Checked ahead of the context-size banner, since the oMLX text also says "reduce context length"; unrecognised messages keep the previous untagged shape. - **Model picker re-reads local servers and marks the loaded model** (`app/utils/local_models.py` `SCAN_UI_MAX_AGE_S`, `scan_is_stale`, `choose_default_model`; `app/routes/model_routes.py`; `frontend/src/components/ModelConfigModal.tsx`; tests `tests/test_local_picker_refresh.py`). Models added to an oMLX library never appeared in the model modal: a non-empty local-server scan was kept for the life of the process (only an empty scan had a TTL), and the picker routes asked for the memoised registration. `/api/available-models` and `/api/endpoints` now request a scan no older than 2 s, so opening the modal re-reads the server while the several requests one open makes share one scan; chat-turn callers keep the never-expires contract and are never stalled by a port probe. A rescan also re-runs per-model discovery, so the server's `loaded` state (oMLX `/v1/models/status`, LM Studio `state`) lands on the model entry, is relayed per model, and the picker lists loaded models first with a green *loaded* tag. The endpoint's default model prefers the loaded one, so switching to a local endpoint does not evict a 100 GB model; `ZIYA_LOCAL_MODEL` still wins. - **A redirection on a compound closer was refused as a command** (`app/mcp_servers/shell_server.py` `_validate_compound_body`; test `tests/test_shell_compound_closer_redirect.py`, new). `for f in *.md; do …; done 2>/dev/null | head` was blocked with `'2>/dev/null' is not allowed`: the compound validator strips the `done` keyword from the segment and then treats the next word as the command, so the loop's own redirection (`done 2>/dev/null`, `fi 2>&1`, `} > /dev/null`, `done < file`) became a bogus command word. Redirection tokens are now skipped before the allowlist match; a closer carrying only redirections has no command to check. The redirection target is unchanged in effect — the write policy's independent `_redirection` scan still refuses `done > app/out.txt` and permits `.ziya/` and `/dev/null`. - **Non-prefill continuation prompts carried the answer twice, and the open-fence verdict is now taken from the complete text** (`app/streaming_tool_executor.py` inject branches, `_fence_open_in_full_text`; test `tests/test_no_prefill_continue_conversation_shape.py`, new). On a model without assistant prefill, each of the `max_tokens` / intent / block-completion continuation branches appended `assistant_text` after the iteration-end block had already appended that turn; the pre-send coalesce merged the pair into one `assistant[text,text]` message, so the model saw its own reply duplicated ("the text was accidentally printed twice") before the `[System: …]` prompt. The branches now append only when no assistant turn is already last. Separately, the "cut off mid-code-block" decision used the incremental streaming tracker's `in_block`, which has reported an open fence on complete responses (a closed ```` ```mermaid ```` block, `transitions=1`); the verdict is now re-derived in one pass over the finished text, and a `FENCE_STATE_DIVERGENCE` warning records the incremental state when the two disagree so the next case is attributable. Known, not yet fixed: after a block-completion continuation the next iteration's tracker starts fresh, so the model's bare closer is read as an opener and a further continuation fires (bounded by the stall cap). - **Service calls on a local endpoint evicted the chat model** (`app/services/model_resolver.py` `_local_service_model`; test `tests/test_local_service_model_affinity.py`, new). Memory triage, extraction, the intent judge and the tier-declared `improve_judge` resolved to the local server's *default* model — its first listed one — rather than the model the conversation was running. Observed on oMLX: after turn 1 on a 94 GB Qwen, triage asked for GLM-5.3 (103 GB), oMLX evicted Qwen to load it, and turn 2 failed with 507 "Cannot load … projected memory would exceed the ceiling". Local endpoints now use `ZIYA_MODEL` for every service category when the server lists it (env overrides such as `ZIYA_MEMORY_EXTRACTION_MODEL` still win); the server default applies only to a model the server does not have. - **Complete reply judged "cut off mid-code-block" on fine-grained streams** (`app/text_delta_processor.py` viz-block flush, `app/streaming_tool_executor.py` tool_use flush; test `tests/test_fence_tracker_viz_flush_seam.py`, new). The content optimizer's `flush_remaining()` before a ```` ```mermaid ```` (or other viz) block and before a `tool_use` block yielded the held text to the user but never fed it to the fence tracker. With small deltas (claude-fable-5-1) the tracker was left holding a stale partial line (`## What `), glued the whole viz buffer onto it (`## What ```mermaid`), missed the opener and read the closer as a bare opener — `in_block=True, transitions=1` at a clean `end_turn`, so `NO_PREFILL_BLOCK_CONTINUE` asked the model to finish a block it had closed, and the reply gained a paragraph explaining nothing was cut off. Both flushes now feed the tracker first, matching every other optimizer drain. - **Three diff-applier defects behind one docs-edit failure** (`app/utils/diff_utils/pipeline/pipeline_manager.py`, `application/git_diff.py`, `application/patch_apply.py`, `validation/validators.py`; test `tests/test_diff_countless_header_backtick_escape.py`, new). A three-file documentation patch had two files rejected as "Malformed hunk detected" and the third reported applied while it kept a removed line and dropped a kept one. (1) The difflib stage, the atomic git path and `_is_valid_hunk_header` required four numbers in the hunk header, so the count-less single-line form `@@ -63 +63 @@` — valid unified diff, and the form the system prompt asks the model to use — was rejected; the parser had accepted it all along. (2) The `\`` transport escaping the model is told to preserve was never undone before the `patch` and `git apply` stages (the frontend forwards the fence verbatim), so every hunk touching a line with a backtick failed those stages and reached difflib as its last chance. The pipeline now unescapes at entry, grounded in the target file so a template literal's genuine `\`` is kept. (3) difflib's context-preservation walk, entered whenever old and new line counts happen to be equal, consumed at most one old line per added line; a hunk that adds one line and replaces two with one misaligned by one and copied its trailing context from the wrong file line, with the stage reporting success. The walk now follows the hunk's raw `' '`/`-`/`+` markers. The streaming verifier's rejection of the third file was correct — it saw the corrupted result — and now reads "already applied" after a clean apply. - **Overlapping-hunk merge sized its region by header counts, duplicating lines past an undercounted header** (`app/utils/diff_utils/application/overlapping_hunks_fix.py` `merge_overlapping_hunks`; test `tests/test_diff_overlap_merge_undercounted_header.py`, new). Found while chasing the follow-up from the fix above: on the live fallthrough path (patch and git apply both failed) the difflib stage receives the model's header counts unrecounted, and the parser repairs an undercount only when it is 2+ lines on both sides. When two hunks are merged as overlapping, the merged old region ended at the header-declared count of the hunk that started last, while the per-hunk splice replaced `len(old_block)` lines — so a body that ran one line past its header count pushed the splice off the end of the region and every line past it came out twice. The stage reported success, and a re-apply reported "already applied", so the streaming verifier could not catch it. The region now ends at the furthest of each hunk's declared-or-actual extent. A survey of the other `old_count` consumers in the stage (search windows, truncation rescue, already-applied probes) found no further divergence between recounted and raw headers across 20 single- and two-hunk miscount shapes. - **Out-of-policy write approvals now actually learn, and say what they remember** (`app/utils/consent_grants.py` (new), `app/utils/consent_gate.py`, `app/utils/consent_ledger.py`, `app/api/consent.py`, `frontend/src/utils/consentStore.ts`, `frontend/src/components/ConsentPanel.tsx`, `frontend/src/components/WriteGrantsChip.tsx` (new), `SendChatContainer.tsx`; tests `tests/test_consent_grants.py` (new), `tests/test_consent_grants_api.py` (new), `ConsentPanel.test.tsx`; `design/scope-consent.md` D1–D4, `Docs/Capabilities.md`). Approving a write "for this conversation" or "always" felt like it remembered nothing: grants matched the exact file only (every new file asked again), lived in process memory (a restart forgot them, "always" included), and the panel's dropdown chose *how long* while fine print silently fixed *what*. The panel is now `Approve · for [scope ▾] [duration ▾]`: the scope dropdown walks from the file up its ancestors to the whole project, duration is this call / this conversation / this project, and any remembering choice shows the server-produced rule sentence that is stored verbatim. Grants match by prefix at the chosen rung, persist in `/.ziya/consent-grants.json`, never cover the floor (`.git`, install dir, outside root), and are listed and revocable from a *write grants* chip next to the input box. The panel reopens at the rung last chosen in the conversation. `session` and `always` scopes are retired (the API returns 422). - **Parallel tool calls in one turn were almost never actually parallel** (`app/tool_batch.py`, `app/mcp/client.py`; tests `tests/test_tool_batch_classifier_quotes.py`, `tests/test_mcp_client_rate_limit_builtin.py`, both new). The per-turn batch runner overlaps consecutive read-only calls, but its shell classifier split commands on `|` *inside quotes*, so every `grep "a\|b"` became a serial barrier; measured, three ~50 ms greps took ~5 s. Classification now tokenises shell-style (quoted operators are arguments), understands `rg`, `jq`, `xargs `, `timeout N `, `time ` and `git check-ignore`, and treats observing builtins (`render_diagram`, `analyze`, `dataset_*`, `job_status`/`job_read`, `task_run_read`, `ledger_query`, `view_image`, `shadow_wait`, …) as overlappable. The MCP client's 2 s per-tool rate limit no longer applies to the builtin shell server (external servers keep it; `rate_limit_seconds` in a server config overrides either way). Audit data (2026-10-15..20) showed the runner does overlap co-issued reads but rarely gets any: 77% of tool batches were a single call and the median model round-trip between them was 9.3 s against sub-second tools. A per-stream tracker (`app/utils/serial_reads_nudge.py`) now attaches a system note to the tool-result turn on the second consecutive message holding exactly one read-only call (repeating every third message while the streak lasts), telling the model its reads would have run concurrently had it issued them together; any batched or non-read message resets it (`tests/test_serial_reads_nudge.py`, new). External `mcp_*` tools, previously always serial, now overlap when they only observe: by `permissions.json` (`parallel.read_only_tools` / `parallel.serial_tools`), by the server's `readOnlyHint` annotation (now carried from `tools/list` through `MCPTool` and `SecureMCPTool.metadata`), by the absence of a write-target argument (`savePath`, `output_file`, …) and finally by name, where any mutating word (`update`, `post`, `download`, `run`, …) beats any observing one (`get`, `search`, `read`, `list`, …); anything unclassified stays a barrier (`app/mcp/client.py`, `app/mcp/enhanced_tools.py`; tests `tests/test_tool_batch_external_tools.py`, new). - A valid Mermaid flowchart failed with `Expecting 'SQE' ... got 'STR'` when a quoted label contained JSON-ish text such as `{backlog:[…], done:[…]}` (`frontend/src/plugins/d3/mermaidEnhancer.ts`; test `mermaidQuotedLabelColonBracket.test.ts`, new). The `colon-in-node-id-fix` pass scans for `id-with-colon[` and restarts after every `[` it consumes, so inside the quoted label it resumed at `done:` — a clean token none of its substring guards rejected — and quoted it as a node ID. Both the scan and the replacement now skip positions inside an open double-quoted string on the line. - The two gantt label-colon passes now agree on one encoding (`mermaidEnhancer.ts` `gantt-label-colon-fix`; test `mermaidGanttLabelColon.test.ts`). The stricter `gantt-task-name-colon-escape` (priority 140) runs first and emits `#58;`, which mermaid decodes back to a real colon; the older fallback still emitted a fullwidth colon (U+FF1A, a lookalike glyph) for the lines whose data section the strict grammar rejects, and its suite had been red since the strict pass landed. The fallback now emits `#58;` too, and the suite asserts the chain's output plus a case only the fallback handles. - Vega-Lite interval bars (`x`/`x2`, or `y`/`y2`) rendered nothing (`frontend/src/plugins/d3/vegaLitePlugin.ts` `applyRangedBarFixes`, new; tests `vegaRangedBar.test.ts` and `vegaRangedBarRender.test.ts`, both new — the latter compiles and renders through the real Vega-Lite/Vega pipeline and counts visible bars: 0 before the fix, one per episode after). Two Vega-Lite semantics models reliably get wrong: a `timeUnit` on the primary channel is a bucketing transform that moves `x` into the 2012 reference year while `x2` stays in the data's year (decade-wide axis, bars off-screen) and floors sub-unit intervals to zero width; and once `x2` is set, `y` is a point position, so a quantitative `y` with no `y2` is a default-thickness sliver that `cornerRadius` erases. The timeUnit is now translated to `axis.format` (`utc*` → utc scale) on every layer sharing the scale, and a quantitative height on an x-ranged bar gets `y2: {datum: 0}`. Gantt bars (nominal y), explicit `y2`, log scales and the y-ranged mirror are left alone. - ```` ```chord ````, ```` ```force-directed ```` and ```` ```network ```` fences were shown as raw JSON: the fence scanner and plugin registry knew the languages but `determineTokenType` only routed the literal `d3` language. A shared `d3FenceLang` map now routes them to the D3 renderer and supplies the spec `type` when the body omits it; `chord-directed` is also marked atomic in the fence scanner. - **Muting a message is now a versioned change, so it can no longer be silently undone by sync** (`frontend/src/context/ChatContext.tsx` (`toggleMessageMute`); test `frontend/src/context/__tests__/muteBumpsVersionWiring.test.ts` (new)). Mute was the one conversation mutation that did not stamp `_version`. Every place that decides whose copy wins is version-gated: the server's bulk-sync keeps its on-disk copy of matched messages when the push is older than the record, and the client reconcile lets a fetched copy replace the in-memory one on a version tie. A mute pushed while the server's version was ahead (routine after a streamed turn) was dropped, and the unmuted copy flowed back in, so the muted turn still rendered as muted but was sent to the model again. Observed as a fork of a conversation with a muted 225k-token response being rejected at over 1M tokens; toggling the mute off and on in the fork restored the smaller request. - **A flamegraph, railroad or wavedrom block missing its closing fence no longer swallows the next diagram** (`frontend/src/components/fenceScanner.ts` (`ATOMIC_FENCE_LANGS`); test `frontend/src/components/__tests__/atomicFenceLangCoverage.test.ts` (new)). A `flamegraph` fence followed directly by a `mermaid` fence with no close in between was read as one flamegraph block, which failed with "line 11 has no trailing sample count" on the escaped mermaid opener. `repairAtomicFenceRuns` already closes a diagram block at the next column-0 opener, but its language set had not been extended when these three renderers (and their aliases) were added. The new test reads the diagram aliases out of `determineTokenType`, so a renderer added there without the repair now fails a test. - **Mermaid xychart with time labels on the x-axis renders** (`frontend/src/plugins/d3/mermaidXychartAxisLabels.ts` (new), `mermaidEnhancer.ts` (`xychart-axis-label-quote`); test `__tests__/mermaidXychartAxisLabels.test.ts`). `x-axis [05:54:15, 05:54:16, ...]` failed with "Expecting ... got 'COLON'": the xychart lexer reads a bare band label as letters, digits and `+=*#_.&-` only. Band labels outside that set (colons, inner spaces) are now wrapped in double quotes; labels mermaid already parses are unchanged. The pass is registered for both `xychart` and `xychart-beta`; the existing xychart passes match `xychart` only, so none of them ran for a `xychart-beta` header. - **Mermaid state diagrams with colons or semicolons in labels render.** A time in a note or transition label (`note right of X : at 05:54:19`) failed with "got 'DESCR'"; label colons and prose semicolons are now escaped and still display as written. The state-shape pass no longer declares phantom states taken from label text (`05`, `54`), and a `;` between statements or at the end of one no longer creates a state named `;` or `B;`. - **Search-result lists choose raw code vs. markdown per row.** The first row's language used to decide for every row, so one markdown row made line-numbered code rows render as mangled markdown, and vice versa. - **Escaped backticks and dollars inside double-quoted shell arguments now reach the program as bash would deliver them** (`app/mcp_servers/shell_server.py`). Bash removes the backslash before `$`, `` ` ``, `"` and `\` inside double quotes; the executor's `shlex` tokenizer did so only for `"` and `\`, so a SQL quoted identifier in `python3 graf_q.py "SELECT ... FROM \`table\` ..."` arrived as `` \`table\` `` and ClickHouse refused it, and `"\$HOME"` was expanded by the pre-tokenize variable pass instead of being delivered literally. The escaped pair is now swapped for a placeholder before expansion and restored per token; `$?`/`$$` expansion skips an escaped `$` too. The "write the query to a file first" workaround is no longer needed. Tests: `tests/test_shell_double_quote_escapes.py`. - **A model could not retract a memory proposal it made last turn** (`app/mcp/tools/memory_tools.py`). `memory_propose` returned the `prop_*` id only as a sibling field; the chat record keeps just the message line, so on the next turn the model had no id to hand to `memory_retract_proposal` and fell back to "reject it when you review proposals". The message line now names the id, and `memory_retract_proposal` also accepts the proposal's `content` (exact match, or a unique substring among this conversation's own open proposals) and lists this conversation's open proposals when it cannot resolve a request. Same-conversation retraction has no gate; proposals from other conversations remain the user's to review. - **Zero-argument external MCP tools rejected with "EMPTY ARGUMENTS"** (`app/streaming_tool_executor.py`). Tools such as a Jira server's `refresh_jira_auth` / `get_jira_myself` (schema `required: []`) were bounced client-side before reaching the server. `SecureMCPTool` carries the server's JSON schema only in `metadata['input_schema']` and has no pydantic `args_schema`, so the `optional_only_tools` probe (pydantic only) never classified any external tool; separately, the set stored `mcp_` while the gate compares the `mcp_`-stripped name. The probe now reads the dict schema first and registers both spellings. - **document_authoring skill pointed at a hard-coded port.** The export recipe said `localhost:6969`; a task-card stage copied it, got a non-200 from a port nothing listened on, declared the export server unreachable and fell back to pandoc while the real server (on another port) was answering `%PDF` the whole time. The skill now addresses `localhost:$ZIYA_PORT` (the server publishes its bound port into the shell tool's environment), requires a `head -c 5` → `%PDF` check, and only permits an "unreachable" conclusion after every `lsof`-discovered port has been tried and recorded. Docs/DocumentAuthoring.md mirrors the recipe. - Rendered images inlined into tool blocks as `data:` URIs are elided from history before it is sent, so a conversation with several renders is no longer re-uploaded image by image on every turn or rejected by the request-size limit before the server's own elision runs (`frontend/src/utils/elideInlineImages.ts`, new; test `frontend/src/utils/__tests__/elideInlineImages.test.ts`). ### Changed - Ziya's remote (HTTP/SSE) MCP client works with both `mcp` 1.x and 2.x, and new installs resolve to 2.x (`pyproject.toml` `mcp = ">=1.23.0,<3"`). SDK objects are read through `app/utils/mcp_sdk_compat.py`, which handles the 2.x snake_case renames and builds the HTTP client type the transport expects (`httpx` on 1.x, `httpx2` on 2.x). This fixes remote servers such as chorus-mcp failing with `'InitializeResult' object has no attribute 'protocolVersion'` when `mcp` 2.x was present. It also fixes three reads that 2.x would have broken without any error: tool errors (`isError`) reported as success, image MIME types reset to `image/png`, and `readOnlyHint` annotations dropped. Audio content is no longer labelled as an image. `RemoteAuthProvider` plugins declare `http_libraries` and build their client with `mcp_sdk_compat.http_module()`. A provider that cannot build the type the installed SDK needs is refused before connecting, with the reason (`remote_auth_sdk_mismatch`). Tests: `tests/test_mcp_sdk_compat.py`, `tests/test_mcp_remote_sdk_e2e.py` (a real in-process server; run under each SDK). The stdio client and built-in servers do not use the SDK and are unaffected. - The Bedrock default model is Opus 5.5 again (`opus5.5`), replacing Sonnet 5.5. This affects only users who haven't picked a model; a model set with `--model`, `ZIYA_MODEL` or in saved settings still wins (`app/config/models_config.py` `DEFAULT_MODELS`). - Mermaid upgraded from 11 to 12.2.0, and building the frontend now needs Node 22.12 or later (`.nvmrc` and `mise.toml` pin 24). Mermaid 12 changes the default look (`neo`) and lays graph diagrams out with ELK; Ziya pins the classic look so existing diagrams keep their appearance, and chooses the layout engine per diagram type. `scripts/mermaid_layout_eval.py` (new) renders a set of hard diagrams under both dagre and ELK in headless Chromium and scores each from the SVG (edge crossings, edges through nodes or labels, overlapping labels, size); results go to `.ziya/layout-eval/` (`frontend/package.json`, `frontend/src/plugins/d3/mermaidPlugin.ts`). - Four music test suites that had gone stale against already-shipped renderer rules now follow them: `musicSystemWrap` (D-140 grows an undersized pinned width; D-138 ignores a pin past the legibility limit, with its own test), `musicOrnamentation` (a below chord symbol is compared with a bare note, since D-438 reserves a band for above symbols too), and the `musicWrapParity` snapshots (stave ink #6b6b6b from 2186d44f, grace-note slashes, ledger and chord-symbol headroom). Each was confirmed to fail identically on HEAD's renderer before it was changed. - Within-reach MCP loads are cache-stable and can be per tool (`design/mcp-on-demand.md`, revision 2026-10-25; `app/utils/mcp_ondemand.py`, `app/utils/bench_prompt.py` `mcp_filter_for_root` / `apply_mcp_filter`, `app/models/chat.py` `loadedMcp`, `app/mcp/tools/mcp_loader_tools.py`, `app/streaming_tool_executor.py`, `app/api/bench.py`, frontend `CapabilityCard.tsx`; tests `tests/test_mcp_ondemand.py`, `test_bench_prompt_seam.py`, `frontend/.../benchLoadedChip.test.tsx`). The first cut derived "loaded" from a marker in history, so tributary folding or muting the loading turn un-loaded the server and the next use cost a second full-prefix cache miss; its catalog listed only connected servers, so a server connecting after turn 1 moved the system prompt; and a loaded server's tools were inserted mid-array. Now the loaded set is stored on the chat record (a fork copies it; the bench card shows "loaded" / "N tools loaded"), the catalog is built from placement and config alone, and the tool array is ordered builtins → on-hand servers by name → loaded servers in load order, so a load only appends. New `search_server_tools(query, server?)` ranks a within-reach server's tools without loading anything, and `load_server_tools` takes an optional `tools` list, cumulative per conversation, so one tool of a hundred-tool server can be loaded without the other ninety-nine. - A task card's Schedule block no longer puts the card on the scheduler by itself; the user registers the card, and the registration (not the card) is what fires (`app/agents/schedule_registry.py`, new; `app/agents/task_scheduler.py` `_enumerate_scheduled_cards`; `app/api/schedules.py`, new; `app/server.py`; `app/api/task_cards.py` `/schedule-state` gains `registered` / `enabled`; `app/data/built_in_skills.py`; tests `tests/test_schedule_registry.py`, new, and `tests/test_task_scheduler.py`). The scheduler listed deck cards with an enabled Schedule block, so a card the model staged in chat (conversation-only) ran once on Run and never fired again, with nothing saying so; pausing meant editing the card. Now `POST /api/v1/projects/{pid}/schedules/{card_id}` registers a card with a `registered_at` time, copying the cadence from its Schedule block (or a daily 09:00 default for a card without one; the whole card is then the body) with the request body's edits on top; `PATCH` enables/disables it or changes the time and frequency, re-projecting the next fire at once; `DELETE` unregisters and drops the fire history; `GET` lists registrations with next fire, last outcome, fires, skips and `exhausted` (max runs reached), plus cards that carry a Schedule block nobody has registered, and `GET /api/v1/scheduler/status` reports which process holds `~/.ziya/scheduler.lock`. None of these touch the card (no version bump, nothing in its export). One registration per card; `/schedule_registrations.json`. Cards the old rules had armed (a `schedule_state.json` record whose card still has a Schedule block) are migrated once into registrations, paused if the block was disabled; a card with a Schedule block and no record was never armed and is listed as unregistered. The task-card skill no longer tells the model that launching a Schedule-rooted card registers it. The management UI (Scheduled list with register / pause / edit) is not in this change. - The bench's Within reach and Shelved lanes list MCP servers and skills most recently used first (`app/utils/capability_usage.py`, new; `app/mcp/tools/skill_tools.py`, `app/mcp/manager.py` `call_tool`, `app/api/bench.py` (items gain `last_used`), `frontend/src/apis/benchApi.ts`, `frontend/src/components/Bench/laneFold.ts`, `BenchBoard.tsx`; tests `tests/test_capability_usage.py`, `frontend/src/components/Bench/__tests__/benchBoardRecency.test.tsx`, new, and `laneFold.test.ts`). They were in the server's catalog order, which reads as random. A use is a successful `get_skill_details` load or a call to one of a server's tools that passes the quarantine and permission checks; the time is kept per user in `~/.ziya/state/capability_usage.json` under a file lock, only ever moves forward, and is written at most once a minute per item per process. Never-used items follow in the previous order. On hand is unchanged. Built-in skills at their default still fold into the "N built-in skills" row, now ordered by recency inside it. `Skill.lastUsedAt` was not usable for this: it records creation and edits, not use. - The MCP status modal lists External MCP Servers (or the "No external MCP servers configured" notice) above Builtin Tools and the builtin servers (`frontend/src/components/MCPStatusModal.tsx`; test `frontend/src/components/__tests__/mcpStatusModalSectionOrder.test.tsx`, new). The servers a user configured were below the builtin ones they rarely change. - The handoff drawer's "Ask the model to draft it" now runs on the standard `medium` model tier by default, with a selector for another tier or the conversation's own model (`frontend/src/utils/handoffDraftModel.ts`, new; `frontend/src/hooks/useHandoffDraftRequest.ts`; `frontend/src/components/HandoffDrawer.tsx`; tests `frontend/src/utils/__tests__/handoffDraftModel.test.ts`, new, and `frontend/src/hooks/__tests__/useHandoffDraftRequest.test.tsx`). The drafting turn inherited the conversation's model pin, so a conversation pinned to a frontier model paid frontier rates for a summary the user then edits. The tier resolves through `/api/model-tiers` for the active endpoint (the same table Task Card blocks use) and pins the background turn per request; the choice is remembered per browser, and an unreadable tier table falls back to the conversation's pin rather than failing the request. The automatic draft written under context pressure is unchanged — it is part of the model's own turn. - `test_large_context` calls models through the production provider path (`app/providers/factory.create_provider`) instead of the legacy LangChain wrapper, names provider errors and refusals, and uses a benign needle — Claude Sonnet 4.6 refused "find the secret code" with `stop_reason=refusal`. Real-API result: 65 passed; remaining failures are Google (402, prepaid credits exhausted), `bedrock/grok-4.6` (stream stall), and `openai/gpt-5.5-pro` / `gpt-5.4-pro` (Responses-only models on a Chat Completions endpoint — a product gap, not a test issue). - The tributary fold is now gated on context pressure (`app/utils/tool_history_rewrite.py` (`FoldSettings.pressure_ratio`, `FoldPressure`, `FOLD_PRESSURE_HYSTERESIS`, `plan_folds(pressure=)`, `fold_pressure_for`, `record_fold_savings`), `app/utils/handoff_prelude.py` (`get_context_pressure_detail`), `app/models/project.py` (`contextManagement.fold_pressure_ratio`, default `0.8`), `app/server.py` (passes `conversation_id` to the rewrite), `app/utils/session_context_prompt.py`; tests in `tests/test_tributary_fold.py`). Folding every eligible hunt as soon as two turns had passed cost the model verbatim text it still had in view — the exact lines a diff's context is built from, the exact path a follow-up edits — long before the window was under any pressure, and it had to notice the loss to recall it. Nothing now folds until the conversation's *unfolded* replay reaches 80% of the context limit (the same per-conversation measurement the handoff nudge uses); then the oldest eligible turns fold first, until the projected size is back under 65%. The gate compares the unfolded size (the measured size plus what the previous turn's folds removed), so a fold never lowers the pressure that justified it: the folded set is a prefix that only grows, each placeholder is written once and stays in the cached prompt prefix, and a conversation never flaps between folded and unfolded. Unknown pressure (first turn after a restart) folds nothing. `fold_pressure_ratio: 0` restores the old fold-everything behaviour. The "Folded tool turns" paragraph in the Session Context no longer asserts that earlier turns *are* folded, since below pressure none are. - **File-write results render as a real diff.** The body of a `file write:` tool block (a `file_write` patch) now goes through the same renderer as a chat diff fence — file header, unified/split and line-number controls, Prism syntax highlighting inside the add/remove colouring — with the "already written to disk" caption and no Apply button (`ToolDiffPreview` → `ReadOnlyDiffView` in `frontend/src/components/MarkdownRenderer.tsx`). The previous react-diff-view rendering drew removed and added lines interleaved, struck through and uncoloured; its palette in `styles/toolDiffApplied.css` is reduced to the caption. Test: `components/__tests__/toolDiffPreview.test.tsx`. - **Steer record-shaped work to the dataset tools.** A review of task-card runs found the model building bespoke JSON stores and `python3 + json` aggregation scripts (5,000 snapshot copies of one backlog, 1,700 JSON files for one matrix) while `analyze` went uncalled. The shared session-context prompt now carries a standing `### Working with data` section (chat and task blocks alike, gated on the `datasets` category); the `dataset_register` / `analyze` descriptions open with when to reach for them; the `task_cards` skill's blackboard recipe is an append-only JSONL log read by `analyze` instead of a rewritten state object; and the card validator warns when a task's instructions maintain a hand-built JSON store and name no data tool. - `dataset_register` / `analyze` accept the JSON shapes models actually write: an object of objects becomes rows keyed by `_key`, an object with one array-of-objects member reads that member, and `record_path=` (or `path#member` in `analyze` inputs) selects one when several qualify. Previously any top-level JSON object failed with a pandas "All arrays must be of the same length" error. - **Shell `aws` subcommand policy narrowed and made explainable.** `aws s3 cp` / `aws s3 sync` are blocked only when they write *into* S3 (upload, bucket-to-bucket); a download to a local path (`aws s3 cp s3://bucket/key /tmp/x`) is the same read as `s3api get-object` and now passes. `mv`/`rm`/`rb`/`mb` and the IAM/STS/deploy legs are unchanged. The refusal now says it comes from Ziya's built-in subcommand policy, not the command allowlist, so an approved `aws` in Shell Configuration no longer looks like a broken allowlist. And the policy defers to an explicit grant: if the verified allowlist names `aws`, `aws ` or `aws ` itself, the user asked for it and the hardening steps aside. The grant is read from the signature-checked scope env, so an unsigned `aws` hand-written into `mcp_config.json` does not lift it. - The context-budget bar in the sidebar footer and the collapsed strip is one shared component, stacked by what is spending the budget (files · chat · tools · ast), so the two can no longer disagree on colour or proportion; the track turns red past the danger threshold (`frontend/src/components/TokenBreakdownBar.tsx`, new; `frontend/src/components/TokenCountDisplay.tsx`; test `frontend/src/components/__tests__/tokenBreakdownBar.test.tsx`). - Packet and force-directed graphs use the shared Open / Source / Save diagram actions, and every plugin's action cluster is styled by one CSS rule set, hidden until the diagram is hovered (`frontend/src/plugins/d3/diagramActions.ts`, `packetPlugin.ts`, `forceDirectedPlugin.ts`, `frontend/src/index.css`). ### Removed - Removed obsolete tests under `tests/backend_system_tests/model/`: seven near-duplicate Nova wrapper modules (import, syntax, LangChain type-hint and runtime copies of `test_nova_wrapper.py`), a reproduction of a long-gone LangChain `AgentFinish` error (`test_nova_lite_streaming.py`), and five methods asserting `ZiyaString` / `ZiyaMessageChunk` behaviour those classes no longer have; also the one-off 2025 migration scripts `tests/strategic_integration_plan.py` and `tests/execute_integration.py`. `test_nova_wrapper.py` now follows the live `NovaWrapper` (base of `NovaBedrock`): its stream test stubbed `converse` while `_astream` calls `converse_stream`. `test_ziya_bedrock.py` follows the client wrapping moving to ModelManager. Model suite, offline: 19 failures to 0, apart from the bug above. ## [0.8.10.0] - 2026-10-14 ### Added - **The `git` tool can amend the top commit and force-push, and asks you every time.** Until now a stacked-change hand-off ended with "my git tool can't --amend or force-push" and two commands for you to type. `commit` now takes `amend: true`: it replaces HEAD with HEAD plus what's staged (or exactly `paths`), and keeps HEAD's message if none is given. The approval names the replaced commit and warns when it's already on a remote branch. `push` now takes `force: true`, which is `--force-with-lease=refs/heads/:` on the remote-tracking sha shown in the approval and never a bare `--force`. The approval lists every remote commit that would be dropped, a remote that moved since your last fetch is refused by git with a hint to `fetch`, and forcing the remote's default branch is refused outright. Both run under their own consent ops, `commit_amend` and `push_force`, declared in the new `consent_human_only_ops`. For those ops the gate always asks: a `permissions.json` `always`, an autonomous project, or a conversation or session grant doesn't skip the prompt, and the panel offers "once" only. Approving `commit` or `push` therefore never approves a history rewrite. `git_ops.truthy` reads the flag the same way for dispatch and for the consent op, so `amend: "false"` is a plain commit in both places (plain `bool("false")` would ask about a commit and then amend). (`app/utils/git_ops.py`, `app/utils/consent_gate.py`, `app/mcp/tools/git_tool.py`, `app/utils/git_grant_hazards.py`, `design/git-tool.md`, `Docs/Capabilities.md`; tests `tests/test_git_ops_amend_force.py` (new), `tests/test_git_ops_fixup.py`) - **The Conversation Info dialog's Cost row lists the spend per model.** Each ledger row already records the model that answered that call and is priced at that model's rate, so a conversation that switched models mid-way was summed correctly — but only the total was shown, beside no model at all, which read as "priced at the current model". The row now shows one line per model (`global.anthropic.claude-opus-5-5 · $48.07 · 288 calls`, …) under the total. The conversation rollup is grouped by model instead of status; the estimate/actual split the row needs comes from `totals`, so nothing was lost. (`frontend/src/api/usageApi.ts` — `fetchConversationCost`, new `modelGroupLabel`; `frontend/src/components/ConversationInfoModal.tsx`; test `frontend/src/api/__tests__/usageApi.test.ts`) - **Task cards can be exported to a file and imported into another deck.** The deck has **Export** on each card's `⋯` menu and in the editor toolbar, **Export all** and **Import** beside New/Refresh; `GET /task-cards/export[?ids=…]`, `GET /task-cards/{id}/export` and `POST /task-cards/import` back them. The file (`.ziya-task-cards.json`) is the card's *definition* only: `id`, run history, `version`, `draft` and `source` are stripped, as are every default-valued and null field, so a 4-block card is a few hundred bytes of readable tree rather than 8 KB with ~190 `null`s and a task block claiming `schedule_enabled: true`. An `about` list in the envelope explains the block vocabulary, `{{sibling("ID")}}` and what `scope` means, for a reader (or another tasking agent) with no Ziya knowledge. Import remints every block id and rewrites `sibling()` references to follow — the same reason Duplicate remints: approvals key on block id, so a signature from another machine must not authorize anything here, and an imported escalating card shows **Unsigned** until signed in this deck. An import is all-or-nothing; a name collision (a `call` by name resolves the first match) and launch-validator findings are reported as warnings, not refusals. A bare card object or a list of cards imports too. Also carries the card's `requires` block through create, which `TaskCardCreate` previously dropped. (`app/storage/task_cards.py`, `app/api/task_cards.py`, `app/models/task_card.py`, `frontend/src/services/taskCardApi.ts`, `frontend/src/components/TaskCard/TaskCardsLibrary.tsx`; tests `tests/test_task_card_export_import.py` (new, 32)) - **`git` tool `fixup` op: fix a commit in the middle of the stack** (`app/utils/git_ops.py` (`plan_fixup`, `op_fixup`; `_commit_files` / `_record_commit` factored out of `commit`), `app/mcp/tools/git_tool.py` (`target` argument), `frontend/src/components/ConsentPreflight.tsx` (summary sentence); tests `tests/test_git_ops_fixup.py` (new, 15), `tests/test_git_tool_schema_parity.py` (+1), `__tests__/ConsentPreflight.test.tsx` (+1); `Docs/Capabilities.md`, `design/git-tool.md`). The tool could only commit on top of HEAD, so a fix that belonged in an earlier commit had no route through it. `git(op="fixup", target=)` commits the staged changes (or exactly `paths`) as `fixup! ` and returns `fold_in`, the `git rebase -i --autosquash` command that folds it into the target. The tool never runs the rebase, so it still never rewrites history. The approval shows the target, the files and the commits after it, and warns when the target is already on a remote branch or a merge commit is in the way. A target that isn't an ancestor of HEAD is refused. - **Tool-consent prompts render the plan, not JSON** (`frontend/src/components/ConsentPreflight.tsx` (new), `consent-preflight.css` (new), `ConsentPanel.tsx`; standard recorded in `Docs/BrandGuide.md` "Consent & Approval Panels"; tests `__tests__/ConsentPreflight.test.tsx` (new, 4), `__tests__/ConsentPanel.test.tsx` (+1)). The "Allow git push?" panel dumped the preflight as `JSON.stringify` in an amber box borrowed from the task-card Ask panel. It now shows a one-sentence summary for every `git_ops` plan (push/commit/add/unstage/stash/fetch/switch/checkout/clone), a labelled detail grid (humanized keys, SHAs highlighted, booleans as words, `{path, change}` rows readable), the raw plan behind a toggle, and a footer split into Approve+scope and reason+Reject. The chrome is teal on both themes with the question in a header band; the amber stays with task-card Ask panels, where it means *awaiting_input*. - **The block editor can mark a block optional** (`frontend/src/components/TaskCard/RequiredToggle.tsx` (new), mounted in `TaskBlockEditor`, `CallBlockEditor`, `ParallelBlockEditor`, `RepeatBlockEditor`, `UntilBlockEditor`; `runMapModel.ts` (`blockConfigLines` shows `Required: no`); test `TaskCard/__tests__/requiredToggle.test.tsx` (new, 8)). `Block.required` existed on the model and in the executor but no editor surface could set it, so `required: false` was reachable only by hand-editing a card's JSON. Every non-root block header now carries a `required` checkbox; unchecking writes `required: false` (shown amber as "optional"), re-checking removes the key so a saved card stays minimal. The root has no toggle — the field is ignored there. - **Pre-launch warning for a required Task under `on_failure: stop` with no output contract** (`app/utils/task_card_validation.py` (`_has_effective_contract`, `_walk` `parent_stops`); tests `tests/test_task_card_validation.py::TestRequiredUnderStopWithoutContract` (7, the positive case fails on the old validator)). Such a task's only verdict is the model's self-assessment, and the executor fails it on `partial` alone — which under `stop` halts every later sibling (a nightly card lost its second half to one "partial: lane 1B skipped"). The validator now warns, naming both exits: an `output_contract` (a satisfied required contract overrides `partial`) or `required: false`. A State's `output_contract_defaults` in scope silences it; children of a Parallel are not warned, since `_execute_parallel` never reads `on_failure`. - **`scope.cwd` is documented, settable on every block layer, and checked before launch** (`app/data/built_in_skills.py` (`task_cards` grammar — Scope section), `app/utils/task_card_validation.py` (`_check_cwd`), `frontend/src/components/TaskCard/BlockScopeButton.tsx` (working-directory row), `runMapModel.ts` (`blockConfigLines` Scope line); tests `tests/test_task_card_validation.py::TestCwdConfinedToProject` (10), `TaskCard/__tests__/scopeCwdAllLayers.test.tsx` (new, 3)). `merge_scopes` already carried a container's `cwd` down to its leaves (innermost wins, like `model_tier`) and the executor already confined it to the project root — but the grammar never mentioned `cwd` and said scope "does NOT cascade", only the Task editor could set it, and an escaping or nonexistent `cwd` was discovered at run time as a silent fall-back to the project root. Models may now put `"scope": {"cwd": "services/api"}` on a Group, Parallel, Repeat, Until, Schedule or the card root. The validator errors on a `cwd` that escapes the root (`../x`, or an absolute path elsewhere) and warns on one that does not exist yet; container editors show and set it; the run map's Configuration names it. Not a privilege — no signature involved. - **The focused-block panel says why a block failed** (`frontend/src/components/TaskCard/failureReason.ts` (new: `failureReasonOf`), `BlockDetailPanel.tsx`, `frontend/src/types/task_card.ts` (`Artifact.self_assessment`); tests `TaskCard/__tests__/failureReason.test.ts` (new, 4), `detailFailureReason.test.tsx` (new, 3)). A failed block or iteration showed `failed` as a status word and a summary that often read like success; the rationale lived in the un-rendered `self_assessment` field or deep in the decisions list. The panel now opens the output with a "Why it failed" box carrying the same string `task_finished.failure_reason` and the `task_run_read` tool produce — `self_assessment objective_met=partial: lane 1B skipped`, `empty_summary: no prose`, `output_contract: …` — derived from the persisted artifact so a run opened days later reads the same as one watched live. - **Shell and shadow-terminal results render as one terminal pane** (`frontend/src/components/TerminalPane.tsx` (new), `frontend/src/utils/terminalPane.ts` (new), `MarkdownRenderer.tsx` (`ToolBlock` dispatch); tests `utils/__tests__/terminalPane.test.ts` (new, 24), `components/__tests__/terminalPane.test.tsx` (new, 8, including the ToolBlock seam)). A `run_shell_command` result was a raw `$ cmd` transcript in the generic tool chrome, and a `shadow_send` / `shadow_wait` / `shadow_read` result was a JSON tree whose transcript sat in one field among `ok`, `idle`, `next_seq` and the lease record. Both now share one shape: a header with a `REMOTE` badge (or a `LOCAL` one, shown only while a shadow session is attached to the conversation or the conversation contains a shadow tool call — otherwise every command is local and the tag distinguishes nothing; `frontend/src/utils/shadowPresence.ts` (new), test `utils/__tests__/shadowPresence.test.ts` (new, 3)), the working directory, the command, and status chips (`✓ exit 0` / `✗ exit N` / `⏱ still running` / line count and elapsed), over the transcript. The indicator colour tells them apart — teal for a command the server ran, fuchsia for one driven through a `ziya shadow` session (not amber or red, which already mean warning and error). Remote panes carry a seq gutter (the number `shadow_read(from_seq=…)` takes) and fold the lease overlay, the echoed command line and the shell prompt into a "N journal events hidden" row. The working directory is read from the `cd X &&` prefix or, for remote results, from the prompt line when it matches a known shape (`(date) [~/path]`, `user@host:~/path$`, `[user@host ~/path]$`, `~/path ❯`); the `` in the first of those also supplies the exit status when the journal reports none. Long output is clipped to 8 rows with an expand control. Blocked commands and failed shadow results keep the generic block. - **A file-operation block's file can be dragged into other applications** (`frontend/src/utils/fileDrag.ts` (new: `attachFileDrag`, `textToDataUrl`), `frontend/src/components/FileDragChip.tsx` (new, `filePathFromHeader`), `frontend/src/components/MarkdownRenderer.tsx` (chip in the `GenericToolBlock` header for `file read:` / `file write:` blocks), `app/api/drag_helper.py` (`GET /api/v1/drag/file`), `app/utils/drag_file_source.py` (new: `resolve_drag_file`, confined like `file_read`, 8 MB cap), `app/utils/drag_pasteboard_helper.py` (generic `` carrier beside the PNG one: `extract_drag_payload`, `dest_path_for`, `safe_filename`; the helper keeps the file's own name in a per-drag subdirectory, and `cleanup_stale` sweeps those too); tests `tests/test_drag_file_source.py` (new, 8), `tests/test_drag_pasteboard_helper.py` (+7), `frontend/src/utils/__tests__/fileDrag.test.ts` (new, 4), `frontend/src/components/__tests__/fileDragChip.test.tsx` (new, 2)). The header of a `file_write` / `file_read` result names a file but holds no bytes (a patch-mode write carries one hunk, a read may be a window, history drops tool inputs), so a `⠿ name.md` chip in that header fetches the file from the server on press and publishes it at dragstart as a real named file (`DownloadURL` + File item), its text (`text/plain`) and the helper carrier (`text/html`). Finder / Explorer / browser drop zones get the file; on macOS with the native helper, Slack desktop does too, under its own name. The chip is a separate element so the header text beside it stays selectable. - **Diagrams and tables dragged out of the chat drop into Slack desktop (macOS)** (`app/utils/drag_pasteboard_helper.py` (new: `plan_rewrite`, `extract_png_data_url`, pyobjc poll loop `main`, `HelperSupervisor`), `app/api/drag_helper.py` (new: `POST /api/v1/drag/arm`, `GET /api/v1/drag/status`), `app/server.py` (spawn on startup, stop on shutdown), `app/utils/install_extras.py` (`--drag`; included by `--all` and the no-target default on macOS via `default_python_extras`, skipped when `AppKit` is already importable so the default run never needs the package index just to re-check it — `python_extra_installed`; tests `tests/test_install_extras_data.py` (+4)), `pyproject.toml` (`ziya[drag]` = `pyobjc-framework-Cocoa`), `frontend/src/utils/nativeDragArm.ts` (new), `frontend/src/utils/diagramDrag.ts` / `tableDrag.ts` (PNG carrier comment in `text/html`; prepare + arm on `pointerdown`); tests `tests/test_drag_pasteboard_helper.py` (new, 13), `frontend/src/utils/__tests__/nativeDragArm.test.ts` (new, 5), `diagramDrag.test.ts` (+1), `tableDrag.test.ts` (+1); `Docs/EnvironmentVariables.md` (`ZIYA_NATIVE_DRAG`)). A web page cannot put a file on a drag, and Slack desktop — an Electron receiver — accepts a drop only when the drag pasteboard carries a real `public.file-url`; it ignores Chromium's file promise, inline PNG bytes and data URLs, and strips every filename when it sees the `org.chromium.chromium-renderer-initiated-drag` marker. A small helper process (spawned only on macOS with pyobjc installed via `ziya-install-extras --drag`; `ZIYA_NATIVE_DRAG=0` disables) watches the system drag pasteboard and, for a drag whose renderer origin is this Ziya page, re-declares the item without the Chromium markers and with a `public.file-url` to a PNG it writes under `~/.ziya/tmp/drag/` (stale files are swept). The PNG is read off the pasteboard itself: the frontend prefixes the drag's `text/html` with an `` comment (Chromium publishes it as `public.html`), which the helper strips again so rich-text targets still receive the plain `` or ``. The frontend arms the helper with a throttled fire-and-forget POST on `pointerdown`, which also prepares the PNG immediately — fixing a drag from a cold diagram or table shipping the SVG fallback because the hover-delayed rasterization had not finished. Every other drag on the machine is untouched; the route was confirmed with `scripts/drag_pasteboard_probe.swift` / `drag_pasteboard_inject.swift`. - **Clicking the chart handle copies it as an image** (`frontend/src/utils/diagramDrag.ts` (`copyImageToClipboard`, `dataUrlToBytes`, `copySource`/`onCopied` options), `frontend/src/utils/tableDrag.ts` (same options), `frontend/src/components/D3Renderer.tsx`; tests in `diagramDrag.test.ts` (+3), `tableDrag.test.ts` (+1)). The hover handle on pointer-interactive charts (Plotly, Vega, Joint, DrawIO, force-directed) is also a copy button: click writes the PNG as an `image/png` `ClipboardItem` (handed a `Promise` so the write stays inside the click gesture while rasterization finishes) and a toast confirms. Static diagrams and tables have no handle at all — the whole diagram, or any press on a table beside its text, is the drag source — so nothing sits over content. The handle exists only where a plugin owns the pointer and a drag on the chart itself must keep panning/zooming it. Also fixes the table drag always shipping the SVG fallback: arming `table.draggable` at `pointerdown` changed `outerHTML` and invalidated the prepared-PNG fingerprint, so the fingerprint now uses `innerHTML` and the exported markup drops the `draggable` attribute. - **Markdown tables can be dragged into other applications** (`frontend/src/utils/tableDrag.ts` (new), `frontend/src/components/DraggableTable.tsx` (new), `frontend/src/components/MarkdownRenderer.tsx` (table case wrapped); tests `frontend/src/utils/__tests__/tableDrag.test.ts` (new, 7) and `frontend/src/components/__tests__/draggableTable.test.tsx` (new, 1)). A rendered table can be dragged from any press that lands beside its text — cell padding, gridlines, empty cells — decided per gesture at `pointerdown` by hit-testing the caret position against the text node's line boxes (`isPointOverText`), so a press on the words still selects text; a hover-revealed handle (top-right) remains as the discoverable fallback. The table travels in three forms at once: a PNG of the table as rendered via Chromium's `DownloadURL` (Slack, Finder, Explorer receive an image), the `
` itself with computed styles inlined as `text/html` (Docs, Word, Confluence and Sheets paste a real table), and the markdown source as `text/plain`. The PNG is made by wrapping the styled table in an SVG `foreignObject` and painting it through the diagram rasterizer; a drag that starts before it is ready carries the SVG. Also hardens `d3RendererVizCleanup.test.tsx` against CRA's `resetMocks`, which was silently wiping its `newPlot` implementation. - **Rendered diagrams can be dragged into other applications as images** (`frontend/src/utils/diagramDrag.ts` (new), `frontend/src/components/D3Renderer.tsx` (drag-out effect on the plugin container), `frontend/src/types/d3.ts` (`D3RenderPlugin.pointerInteractive`), opted out in the Plotly, Vega, Vega-Lite, force-directed, Joint and DrawIO plugins; tests `frontend/src/utils/__tests__/diagramDrag.test.ts` (new, 10) and `frontend/src/components/__tests__/d3RendererDiagramDrag.test.tsx` (new, 2; the packet case fails on the old renderer, whose container was never a drag source)). Dragging a rendered Mermaid, Graphviz, packet, LaTeX or other static diagram did nothing: browsers only put image bytes on the drag pasteboard for a native `` drag, and an inline `` drag uses — so Slack, Finder/Explorer and documents receive a real `.png` that renders inline rather than an attachment, plus a `text/html` `` for rich-text web targets. The PNG is prepared when the pointer rests on the diagram and cached against the SVG's content; a drag that starts before it is ready carries the SVG instead. Plugins that own pointer gestures (zoom, brush, pan, node drag) set `pointerInteractive`; for those the renderer shows a small hover-revealed handle at the diagram's bottom-left that is the drag source instead, so dragging the chart itself still pans/zooms. Plotly supplies its own PNG via `Plotly.toImage` (`__vizExportPng` on its render root) because its SVG layers omit WebGL traces. Also fixes a pre-existing test-environment gap: `frontend/craco.config.js` now maps `d3` to its UMD bundle under jest, so any test that drives `D3Renderer` through `import('d3')` (including the existing `d3RendererVizCleanup` test) runs instead of failing on d3's ESM entry. - **The Schedule editor shows what the scheduler did with the card** (`app/api/task_cards.py` (`get_schedule_state` adds `last_run`), `app/utils/task_run_read.py` (`last_run_summary`), `frontend/src/components/TaskCard/ScheduleHistory.tsx` (new: `ScheduleHistory`, `ScheduleCardContext`), `scheduleSummary.ts` (new: `summarizeScheduleState`, `formatRelative`), `ScheduleBlockEditor.tsx`, `TaskCardEditor.tsx` (provides the context), `frontend/src/services/taskCardApi.ts` (`scheduleState`, `ScheduleStateRecord`), `task-card-editor.css`; tests `tests/test_task_cards_schedule_api.py::test_enriches_with_last_run_outcome_and_skips`, `TaskCard/__tests__/scheduleHistory.test.ts` (new, 6)). A skipped slot and a failed last fire were recorded in `schedule_state.json` and the server log but on no screen; a skipped 03:05 night was discovered at 08:00 by opening the run. The Schedule block now carries a status line — "fired 47 times · last 22h ago: failed — self_assessment objective_met=partial: lane 1B skipped · skipped 1 slot (6h ago: run abcdef12 still live) · next in 2h" — refreshed every 30 s, amber with a ⚠ when a skip, a queued slot, or a failed/held last run needs attention. The endpoint resolves the newest still-existing run in `run_ids` to `{status, failed, failure_reason, held_reason}` using the same rule `task_run_read` applies, so a deleted run is skipped rather than reported. - **`task_run_read` tool: a run's outcome is readable without the browser** (`app/mcp/tools/task_run_read.py` (new), `app/utils/task_run_read.py` (new: `summarize_run`, `list_runs`, `read_journal_events`, `failure_reason_of`, `resolve_card_id`), `app/mcp/builtin_tools.py` (`task_cards` category), `app/mcp/tools/task_card_launch.py` (description no longer points at "task-run views" that no tool exposed); tests `tests/test_task_run_read.py` (new, 6), `tests/test_task_run_read_tool.py` (new, 3)). Run records are encrypted at rest and the live journal was read only by the UI, so a model — or an operator working through one — diagnosing a failed scheduled run had to reconstruct the verdict from text deltas in `events.jsonl`. The tool lists a project's or a card's runs newest first (card by id or name), reads one run (or `run_id='latest'` for a card) and returns bounded, payload-free facts: status and hold reason, the card name/version from the launch snapshot and whether it was a scheduled fire, every block's status with its `failure_signature` / `self_assessment` / one-line `failure_reason`, a `failures` list naming which block failed and why, an index of emitted outputs, the verdict-bearing journal events (`task_finished`, holds, asks — text and tool traffic are counted, never returned), and the card's schedule-state with fires and skips. `block_id` drills into one block's full decisions and iteration summaries. `failure_reason_of` applies the executor's rule to the stored artifact, so runs whose journal predates the `failure_reason` field get the same answer. - **A container's child can be marked `required: false`** (`app/models/task_card.py` (`Block.required`), `app/agents/block_executor.py` (`_execute_parallel`, `_execute_sequence`), `app/data/built_in_skills.py` (`task_cards` grammar), `frontend/src/types/task_card.ts`; tests `tests/test_block_required_false.py` (new, 9; the positive cases fail on the old executor, which counted every child)). A Parallel reported failed whenever any child failed, and under `Group(stop)` that halted the run, so a fan-out of `{1A baseline, 1B known-issues}` had no way to say that 1A must pass and 1B may not. An optional child's failure now neither trips an enclosing `on_failure: "stop"`, nor makes a Parallel report failed, nor — as the last child of a sequence — fails the sequence's own artifact; a child that raises is treated the same way. It is recorded, not hidden: the container's `decisions` carry "optional child failed … (required=false)" with the child's signature, the child's own stage evidence still reads failed, and the next sibling still receives the failed artifact as `{{previous_sibling}}`. Default `true`, so every existing card is unchanged. Also corrects the grammar text added earlier in this release, which said `on_failure` on a Parallel governs sibling cancellation: `_execute_parallel` does not read it at all. - **A satisfied output contract outranks a `partial` self-assessment** (`app/agents/task_executor.py` (verdict/contract reconciliation after the contract check), `app/utils/completion_check.py` (`is_failure` docstring), `app/data/built_in_skills.py` (`task_cards` grammar); tests `tests/test_output_contract_overrides_partial.py` (new, 6; the positive case fails on the old executor, whose contract check could only add failure and never clear it)). A task that emitted every `required` entry of its `output_contract`, each validating against its pinned schema, and then closed with `objective_met="partial"` was recorded failed — and under `Group(stop)` halted the run — on the strength of its own self-report. The contract tests the thing the verdict exists to catch ("did this task abandon its goal mid-run?") directly, so when a required contract is fully satisfied the task is now recorded ok and the verdict kept as a warning: in `decisions` with the model's rationale, and as `self_assessment` on the artifact and the `task_finished` event. Unchanged: a task with no contract or an all-optional contract (the verdict is the only evidence), a `false` verdict (a model that says false with every output present is contradicting itself), an unmet contract, and the empty/truncated-stream failures, which stand even with outputs present. - **A Schedule says what a due slot does while a run of its card is still live** (`app/models/task_card.py` (`Block.schedule_concurrency`), `app/agents/task_scheduler.py` (`_tick_card`, `_concurrency_gate`, `_live_runs_for_card`; the fire pass is extracted from the loop body so the decision is testable), `app/data/built_in_skills.py` (`task_cards` grammar), `frontend/src/types/task_card.ts`, `frontend/src/components/TaskCard/ScheduleBlockEditor.tsx` ("if still running" selector); tests `tests/test_task_scheduler.py` (7 added — the default-skip case fails on the old scheduler, which fired). The scheduler had no notion of overlap: a slot fired while a previous fire, or a hand-launched run of the same card, was still running the same workspace, and a laptop waking at 09:00 fired the missed 03:00 catch-up slot on top of a run started by hand at 08:00. `schedule_concurrency` is `skip` (default: the slot is dropped, `next_fire_at` advances, and the skip is recorded in the card's schedule-state as `skips[]` / `skips_so_far` / `last_skip_at` with the live run's id, so GET …/schedule-state shows "skipped: run still live" instead of silence), `queue` (the slot is held with `deferred_since` and fires on the first tick after the live run ends, bypassing the catch-up gate since a deferral is a decision to run late, not a missed slot), or `parallel` (the previous behaviour). The gate runs before the catch-up gate, so catch-up fires are subject to it; only `LIVE_RUN_STATUSES` count, so a failed, held or partial predecessor does not block. - **`task_finished` carries the verdict, not just `ok`** (`app/agents/task_executor.py` (`_failure_reason`); tests `tests/test_task_executor_finished_verdict.py` (new, 4)). The event now has `self_assessment` (the parsed `objective_met`/`rationale`, or null), `failure_signature` (`self_assessment_partial`, `empty_summary`, `truncated_summary`, `output_contract:`) and a one-line `failure_reason`. Run records are encrypted at rest and events.jsonl was the readable trace, so an operator diagnosing a failed night had to reassemble the model's closing tag from text deltas. - **The task-card grammar says how a Task is judged** (`app/data/built_in_skills.py`, `task_cards` skill — also what `task_card_stage` returns as the grammar). States in so many words that `objective_met="partial"` records the task as failed, lists the other three executor-imposed failures (empty summary, truncated summary, missing contracted output), and that a Parallel reports failed to its parent whenever any child failed regardless of its own `on_failure`, which only governs sibling cancellation — so `Parallel(continue)` inside `Group(stop)` halts the Group. - **A staged task card can be inspected and edited before it runs** (`frontend/src/components/TaskCard/TaskCardInlineTile.tsx` (`StagedCardTile`), `TaskCardsLibrary.tsx` (`handleSave`, `handleAddToDeck`), `frontend/src/hooks/useTaskBindings.ts` (new `TASK_CARD_SAVED_EVENT`), `task-card-inline-tile.css`; tests `TaskCard/__tests__/stagedTileFullInspect.test.ts` (4 of its 5 cases failed against the old tile; 4 added)). A card staged into a conversation — by the model's `task_card_stage`, by `/goal`, or by the deck's *Copy to conversation* — showed only its name, a collapsed Instructions box holding the first task's text, and Run / Save to deck / Discard; nothing of a loop's mode, stop condition, scope or later blocks was visible, and there was no way to change any of it short of discarding. The tile now renders the same block outline the deck uses, in edit mode, beside a definition pane for the selected block (type, instructions, loop mode and count, until-condition, state variables, on-failure, scope), and has an **Edit** button that opens the card in the deck editor via the same backlink the launched tile uses. The deck announces a save (plain Save and *Add to deck*) with the card id, and a staged tile showing that card refetches it and re-checks its signature status, so the edit appears in the tile and a card just added to the deck stops offering *Save to deck*. The outline stylesheet is loaded by the tile itself, since previously it only arrived once the deck had been opened. The launched tile is unchanged on purpose: it displays `run.card_snapshot`, so a later edit does not rewrite what a finished run is shown to have executed. - **Tool results are previewed by shape, not by their first 200 bytes** (`frontend/src/utils/toolDigest.ts` (new: `digestToolResult`, `formatBytes`), `frontend/src/components/ToolDigestView.tsx` (new: `DigestPreview`, `ToolResultViewer`, `chooseBody`), `frontend/src/components/MarkdownRenderer.tsx` (`GenericToolBlock` collapsed and expanded bodies, `DIGEST_EXEMPT_TOOLS`); tests `utils/__tests__/toolDigest.test.ts` (new, 17), `components/__tests__/toolDigestView.test.tsx` (new, 12)). A collapsed tool block showed the first line of the payload, which for pretty-printed JSON was a lone `{`, for compact JSON a run of keys, for a shell transcript the command echoed back, and for a result like `{"message": "...\n..."}` a sentence trapped in escaped JSON. The block now derives a digest from the payload's shape with no per-tool knowledge: a wrapper with `total` and an array becomes "225 issues matched, showing 100 (NETREL-600 → NETREL-699)" with status-histogram and distinct-assignee chips; a single object becomes its name plus a key/value grid of scalar fields; an object whose payload is one string is unwrapped into prose, with the URL as a link button and any failure line in an amber strip; a shell transcript previews its output lines and a non-zero `[Exit code: N]` as a chip, never the command; truncated JSON reports the keys and total it could scan. The header byline reads "102 KB · JSON" instead of a pretty-print line count. Expanded, a collection opens on a Table tab (identifier column first, hidden columns and rows beyond 50 revealed on request, copy as CSV), a record on a collapsible Tree, a message as prose, with Raw always one tab away and the digest headline pinned above. Diffs, memory cards, hierarchical search results and the file/AST/memory tools keep their existing bodies. A payload the MCP server cut off mid-object (Jira search pages near 100 KB) is closed after its last complete element (`salvageTruncatedJson`), so it still digests as "225 issues matched, showing 57" with an *output truncated* chip and a Table, instead of a list of the keys it saw. A message that is a list of entries (memory search's `[id] (layer) …` paragraphs) reads as "N entries" with the first entries previewed, and only a message's opening lines can raise the amber warning, so a memory containing "cannot" no longer looks like a failure. A diff (file write) headlines its file and `+N −M` and previews changed lines rather than its `---`/`+++`/`@@` headers; a file or markdown body headlines its first line with words, without `/**` or `#`. - **Skills in grouping folders are discovered** (`app/services/skill_discovery.py` (`iter_skill_dirs`, `MAX_SKILL_DEPTH`; all three scanners use it), `app/services/skill_sources.py` (`LocalFolderSource._dirs`, `_dir_for`), `app/utils/skill_resources.py` (`readable_skill_dirs`); test `tests/test_nested_skill_discovery.py` (new, 11); `Docs/Skills.md`). Every scanner looked only at the immediate children of a skills root, so `.agents/skills/frontend/react-patterns/SKILL.md` was skipped with no warning (only name problems log). A subdirectory with no `SKILL.md` of its own is now a grouping folder and is searched further, to three levels below the root; a directory that has a `SKILL.md` is a skill and is never searched inside. The agentskills.io spec constrains only the skill directory (`name` must match the parent directory of `SKILL.md`, which stays the leaf), so this is compliant; the Vercel `skills` CLI added the same bounded recursion behind `--full-depth`. Skill ids are keyed on root and name, not path, so moving a skill into a folder keeps its id. The read-tool allowlist resolves symlinked skills at any depth, and a local or git skill source lists and installs grouped skills by leaf name. - **Managed job runner: start a long command, wait on it by condition, kill its whole process tree, and record what it produced** (`app/jobs/wrap.py`, `app/jobs/policy.py`, `app/jobs/manager.py` (new), `app/utils/journal_wait.py` (new; the `shadow_wait` condition matcher lifted out of `app/shadow/sock_server.py` (`_op_wait`), which now calls it), `app/mcp/tools/job_tools.py` (new: `job_start` / `job_wait` / `job_status` / `job_read` / `job_kill`), `app/mcp/builtin_tools.py` (`jobs` category), `app/mcp_servers/shell_server.py` (`ShellServer(env=…)`; timeout message points at `job_start`), `app/agents/task_executor.py` and `app/api/task_cards.py` (kill owned jobs at block end / run end, not on hold), `pyproject.toml` (`ziya-jobwrap`); tests `tests/test_job_runner.py` (new, 27), `tests/test_job_runner_task_ownership.py` (new); `Docs/FeatureInventory.md`; design `design/job-runner.md`). The 2026-10-02 network scan needed five attempts to start one background query job: `nohup` and `pkill` are off the allowlist, the write checker (rightly) refuses an opaque `subprocess.Popen` script, the `mkdir` for the output directory was part of a refused compound command so the job failed at its last write, and the only way to wait was `sleep 75; cat log`. None of that is a policy bug; what was missing was a supported way to background. A job is admitted by an in-process `ShellServer` built over the exact env the MCP manager hands the shell subprocess, so the allowlist, interpreters, write policy, YOLO and the verify-or-clamp gate apply identically and the floor cannot be lowered from here; background operators are refused on top; declared outputs must be writable (and never server-only); and a refusal at any step creates nothing. The job runs under a stdlib wrapper in its own session with a credential-stripped env, journals to `.ziya/jobs//` (a `server_only_paths` entry), survives a server restart (pid + start-time guarded re-attach; a `-9`'d wrapper reads `lost`), is TERM'd then KILL'd as a group at `max_runtime_s` or on `job_kill`, and on exit records a ledger `command` observation with exit code, duration and the SHA-256 of each declared output (`outputs_missing` for ones never written). `job_start(wait_s=…)` returns a short job's result in one call, and a first `job_wait` with no `from_seq` replays the whole job journal rather than starting at the tail (a job's journal is its own, unlike a shadow session's). `keep_awake=true` (`app/jobs/inhibit.py`, new) holds `caffeinate -i -w ` / `systemd-inhibit` for the job's lifetime — spawned by the server with a fixed argv, never adjudicated as a job command — and reports `held` / `unavailable` / `failed`. `ziya jobs list | tail | kill | gc` (`app/cli.py` (`cmd_jobs`)) reads the job directories directly so it works with no server; `gc` keeps running and ledger-cited jobs and refuses when the ledger is unreadable rather than treating "unreadable" as "uncited". Jobs re-attach at server startup (`app/server.py` lifespan). The ledger observation is `inline` (store-`attested: false`), which the docs state. Journal rotation (50 MB files, 200 MB per job) is in the wrapper. The runner is advertised where a model decides how to run a command, not only in the refusal it gets afterwards: the built-in Task Cards skill's "Long-running commands" section (`app/data/built_in_skills.py`) now steers to `job_start`/`job_wait` first (with `detach="run"`, `keep_awake`, and the refused operators named) and keeps `scope.shell_timeout_secs` as the fallback for a step that must stay synchronous; and the Session Context block every chat and task turn sees (`app/utils/session_context_prompt.py` (`_format_jobs_section`)) carries a two-line version, gated on the `jobs` builtin category being enabled. Tests add `tests/test_job_runner_cli_inhibit.py` (new, 6) and `tests/test_job_runner_guidance.py` (new, 4). - **Task Card runs now feed memory** (`app/agents/run_memory_harvest.py` (new; `harvest_run_memories`, `build_run_text`, `schedule_harvest`), `app/agents/task_scheduler.py` (scheduled fires), `app/api/task_cards.py` (`/launch` runs), `app/cli_card_runner.py` (`ziya task --card`, `/card`); tests `tests/test_run_memory_harvest.py` (new, 13); `Docs/FeatureInventory.md`, `Docs/EnvironmentVariables.md`). Until now memory extraction only ran on the web chat stream, and it dropped the task results injected into chat because they arrive as `system` messages. Research done in cards never reached memory at all. A run that finishes `done` or `partial` now has its root result, decisions, text outputs and passed stage summaries sent through a run-specific extraction prompt, which treats the report as data, keeps only established facts and drops facts about the run itself. The resulting facts go into the probationary store under stricter rules than chat extraction. Every run of one card is a single corroboration source, so a 60-way fan-out or an hourly schedule cannot promote its own finding; a chat or a different card has to agree. Proposals never fast-track on quality; the grade is kept as `run_quality`. A run never rewrites an active memory, it only bumps the corroboration of one it agrees with. A contradiction of a pending proposal is recorded as `contradicted`. Neither the activity counter nor the domain clocks advance, so frequent automated runs do not age the user's probationary memories. Opt out with the card tag `no-memory` or `ZIYA_MEMORY_HARVEST_RUNS=0`. - **Memory export: a bounded, previewed, audited slice of memory for another user** (`app/utils/memory_export.py` (new; `ExportSelection`, `export_options`, `plan_export`, `build_bundle`, `scan_memory`, `fingerprint_ids`), `app/api/memory.py` (`GET /api/v1/memory/export/options`, `POST /api/v1/memory/export/preview`, `POST /api/v1/memory/export`), `frontend/src/api/memoryApi.ts` (`exportReadiness`, `runExport`), `frontend/src/components/MemoryExportPanel.tsx` (new), `MemoryBrowser.tsx` (Export tab); tests `tests/test_memory_export.py` (new, 16), `tests/test_api_memory_export.py` (new, 6), `frontend/src/api/__tests__/memoryExportHelpers.test.ts` (new, 8); `Docs/FeatureInventory.md`). The design doc says memory is "never shared without explicit user action"; this is that action. The Export tab selects by mind-map domain (a node takes its subtree), includes or excludes projects (exclusion wins, so a memory scoped to both an included and an excluded project is held back), and filters layers and statuses. A live preview shows the exact count, a breakdown by layer, domain and project, each reason memories were held back, and a leak scan of the content that reuses the shadow redactor's credential shapes plus home-directory paths and email addresses; flagged items must be acknowledged before the button enables. Every exported memory is rebuilt from a field whitelist — conversation ids, retrieval telemetry and access dates are dropped and project paths reduced to folder names unless the user opts in — and relations are pruned to ids inside the bundle. The export request carries the preview's fingerprint of the selected id set; the server re-resolves the selection and refuses with 409 when the store no longer matches and 412 when warnings are unacknowledged, and logs `memory_exported` / `memory_export_refused` to the security audit trail. The bundle header honours anonymization too (the first test run caught raw paths in the per-project counts). - **Task cards declare the skills, tools and MCP servers they need, and are checked before they run** (`app/models/task_card.py` (`CardRequirements`, `TaskCard.requires`), `app/utils/task_card_preflight.py` (new; `collect_requirements`, `check_requirements`, `run_preflight`), `app/cli_card_runner.py` (`run_card(strict=)`), `app/cli.py` (`ziya task --strict`), `app/api/task_cards.py` (launch preflight, 412 on a strict card), `app/data/built_in_skills.py` (task_cards skill: `requires`); test `tests/test_task_card_preflight.py` (new, 8)). A card run on a host that lacks an MCP server or a skill used to find out when the executor reached the task that wanted it, as one line in that task's artifact decisions; for a batch run that is an hour in, from a confused model. A card can now carry `requires: {skills, mcp_servers, tools, strict}`, and before the first model call every requirement — plus every skill and tool named in any scope of the card — is checked against the live environment (stored skills and `.ziya/skills` discovery, loaded tools, `MCPManager.get_server_status()`). Missing, unconfigured, disconnected and quarantined items are reported with the block that needs them. By default the card still runs (a warning); `requires.strict` on the card, or `ziya task --strict`, refuses — exit 3 from the CLI, 412 from the launch endpoint. Floor tools (`emit_artifact`, `render_diagram`, beads) are never reported missing. - **A headless run's implicit memory store is removed at exit** (`app/config/environment.py` (`_setup_memory_store`); test `tests/test_memory_reference_mode.py`). `--memory-bundle` without `--memory-dir` created a `ziya-memory-*` temp directory per run and never removed it. It is now registered with `atexit`; pass `--memory-dir` to keep a store across runs. - **Memory import, and headless runs against a reference memory set** (`app/utils/memory_import.py` (new; `ImportOptions`, `load_bundle`, `plan_import`, `apply_import`, `seed_store`), `app/utils/paths.py` (`get_memory_dir`, `memory_writes_allowed`), `app/api/memory.py` (`POST /api/v1/memory/import/preview`, `POST /api/v1/memory/import`), `app/config/common_args.py` + `app/config/environment.py` (`--memory-dir`, `--memory-bundle`, `--memory-readonly`), writers in `app/storage/memory.py`, `app/storage/proposals.py`, `app/services/embedding_service.py`, `app/utils/memory_clock.py`, `app/memory/feedback.py`, `app/memory/organize_history.py`, `app/memory/extractor.py`; `frontend/src/components/MemoryImportPanel.tsx` (new), `MemoryBrowser.tsx` (Export / Import tab), `memoryApi.ts` (`importReadiness`, `runImport`); tests `tests/test_memory_import.py` (new, 12), `tests/test_api_memory_import.py` (new, 3), `tests/test_memory_reference_mode.py` (new, 3), `frontend/src/api/__tests__/memoryImportHelpers.test.ts` (new, 6); `Docs/FeatureInventory.md`). Two ways to use another user's bundle. Interactively: the Import side of the Memory Browser's transfer tab classifies every memory in the bundle against your store — new, already present (same id and content), duplicate content under another id (skipped, with references redirected to yours), or an id collision resolved by *keep both* (incoming memory renamed and every reference to it rewritten), *keep mine* or *take theirs* — merges the bundle's mind-map nodes into yours (your handle wins, member lists union), and tags each imported memory `imported` and `from:` with an `imported_from` record. The import echoes fingerprints of both the bundle and the store's current state; the server refuses with 409 if either moved and logs `memory_imported`. Headless: `ziya ask … --memory-bundle ref.json --memory-readonly` runs with the bundle as its only memory and writes nothing — the six modules that each computed `~/.ziya/memory` now resolve through `get_memory_dir()`, every writer (store, proposals, embedding cache, activity clock, feedback stats, organize history) is a no-op under `ZIYA_MEMORY_READONLY`, and post-conversation extraction returns before any model call. `--memory-dir DIR` instead keeps the seeded store and what the job learns across runs. Import never embeds (a 2,000-memory bundle would be 2,000 provider calls at startup); the panel offers the existing backfill after a successful import. - **Claude 5+ prompt treats the context window as unlimited** (`app/extensions/prompt_extensions/claude_extensions.py` (`_CONTEXT_BUDGET_INSTRUCTION`, `_claude_major_version`), `tests/test_claude_context_budget_extension.py` (new)). For Claude models with major version 5 or later, `claude_family_extension` adds a short CONTEXT BUDGET instruction: don't behave as if context is about to run out (estimating what remains, cutting work short, suggesting a new conversation) unless the user says it is a constraint. Being economical with reads on their merits is still allowed. The version comes from the request's model name, so unversioned aliases (`sonnet`, `haiku`) don't get it. - **The system prompt states the user's language locale, taken from the browser** (`app/utils/user_locale.py` (new), `app/utils/session_context_prompt.py`, `app/middleware/project_context.py`; test `tests/test_user_locale.py` (new, 22)). With no locale to go on, the model often wrote British spellings for US users. Browsers send `Accept-Language` on every request. The middleware now records the preferred tag (highest `q`; a bare `en` becomes `en-US` when the header also lists it), and the Session Context gets `` plus a line asking for that regional variety in spelling, vocabulary and date and number formats. Quoted text, identifiers and existing file content keep their own spelling, and an explicit instruction from the user overrides the default. Without a browser (CLI, headless task runs), the locale comes from `LC_ALL` / `LC_MESSAGES` / `LANG`, ignoring `C` and `POSIX`. The header is client text that ends up in the prompt, so only well-formed tags of at most 35 characters are accepted. The line doesn't change between turns, so it stays in the cached system prefix. There's no settings dialog to override it yet. - **Output contracts: a task output can be checked against a schema at the moment it is emitted** (`app/utils/output_contracts.py` (new), `app/utils/output_schemas/{number,distribution,per-entity-table,finding,text}_v1.json` (new), `app/utils/task_artifacts.py` (`start_artifact_collection(contracts=, claim_lookup=)`, `emit_part`, `active_contracts`, `collected_parts`); test `tests/test_output_contracts.py` (new, 31); `design/typed-findings.md` Implementation notes 7–17). In a multi-lane investigation card a per-unit reporting rule had to be written into five places and nothing checked that any lane's JSON carried the fields. A contract names an `emit_artifact` part and a schema: shipped (`ziya:finding/v1`, `ziya:distribution/v1`, `ziya:number/v1`, `ziya:per-entity-table/v1`, `ziya:text/v1`), project (`.ziya/schemas/.json`, usually extending a shipped one with `allOf`) or inline (up to 16 KB). `$ref` may name only those registries, so validation never fetches anything, and a card's schemas are pinned with their SHA-256 so an edit mid-run does not change the check. A contracted part that fails is not recorded, and the tool result lists each problem as a JSON pointer with the field's description, e.g. `/impact/per_unit/sd: required (standard deviation per unit)`. Cross-field rules use a fixed set of checks (`ordered`, `range`, `subset`, `reconciles`), not an expression language. Numbers are evidence-ledger claim references or literals; with `require_claims` literals are rejected, an unknown or refuted claim is rejected, and the resolved value, status and version are copied onto the part. Parts whose names no contract declares are recorded as before. A Task block declares `output_contract: [{name, schema, required, max_count, require_claims}]` (`app/models/task_card.py` (`OutputContract`, `GatherContract`, `Block.output_contract` / `gather_contract` / `output_contract_defaults` / `gather_contract_defaults`), `pyproject.toml` (`jsonschema`)). In a run (`app/agents/task_executor.py`, `app/agents/block_executor.py` (`execute_block` pins the run's schemas), `app/utils/permissions_snapshot.py` (records them at launch as `output_schemas`); test `tests/test_output_contract_task_seam.py` (new, 11)): the task's prompt gains a *Required outputs* section generated from the schema; a task that finishes without a required output gets exactly one correction turn naming it, and if it is still missing the task fails with signature `output_contract:`; the schemas checked are the ones pinned when the run was launched, even if `.ziya/schemas/` changes mid-run; and when a State block sets `evidence_namespace`, numbers must be ledger claims. A State block's `output_contract_defaults` apply, merged by name, to every Task after it in the same body (and their subtrees), so a reporting rule is declared once rather than in every lane; a Task's own entry of the same name wins, `"output_contract": []` opts out, the defaults do not leak out of the body that holds the State or cross into a Called card, and each concurrent iteration of a parallel loop has its own (`app/utils/output_contracts.py` (`merge_contract_defaults`), `app/agents/block_executor.py` (`ExecutionContext.contract_defaults`)). Card validation, and so launch (422, no run), now checks contracts before any model call (`app/utils/task_card_validation.py`, `app/utils/output_contracts.py` (`field_path_problem`); test `tests/test_output_contract_validation.py` (new, 12)): every contract schema must resolve, with an unknown shipped schema naming the ones that exist; and a reference like `{{sibling("lane").outputs.finding.impact.per_unitt}}` to a Task whose contract (own or inherited from a State) covers `finding` must name a field the schema has, the error listing the fields that do exist, while a `for_each` source must name a list. Containers enforce `gather_contract: [{name, schema, per: child|iteration|total, min, max, producer}]` (`app/agents/block_executor.py` (`_check_gather`, push-down at dispatch), `app/context.py` (iteration context `path`), `app/utils/task_artifacts.py` (`iteration_path` on parts), `app/utils/output_contracts.py`; tests `tests/test_gather_contract_seam.py` (new, 9), gather cases in `tests/test_output_contract_validation.py`): the producer task of each child or iteration gets the contract as a required output, with its one correction turn, other tasks have parts of that name validated but owe nothing, and when the container finishes any child, iteration (named by roster key for `for_each`) or total short of `min` or over `max` valid parts fails it with signature `gather_contract:` and a `contract_shortfall` event. Parts emitted in a nested loop are credited to the outer iteration through `iteration_path`. A State block's `gather_contract_defaults` apply to matching containers in its scope. Validation refuses a child of several tasks with no `producer`, producers outside the container or of the wrong kind, a `per` that does not suit the container, a task contract that conflicts with the gather schema, and `rerun_missing` where re-running is not allowed; it also type-checks references to a gathered container's outputs. `rerun_missing: 1` on a Parallel or Repeat gather contract re-runs each short child or iteration once, with the same item and `{{previous}}`, prefixing its tasks with why the first attempt fell short; the re-run's parts replace the first attempt's, a `unit_rerun` event names the units, and a unit still short fails the container with `contract_shortfall.rerun_attempted: true` (test `tests/test_gather_rerun_seam.py` (new, 7)). A re-run iteration is recorded as attempt 2 next to attempt 1 (`IterationSummary.attempt`, per-attempt artifact files in `app/storage/task_runs.py`), and resume, replay and run outcome read the highest attempt (`app/utils/iteration_attempts.py` (new)). The `task_cards` skill documents output contracts, so a model authoring a card learns them when it loads the skill. The run inspector draws a contracted `ziya:finding/*` part, or one whose project schema extends it, as a finding card instead of JSON: verdict, impact rows, mechanism, cross-validation and evidence, with each number marked as a ledger claim (status and claim id on hover) or a literal, and the raw JSON one click away (`frontend/src/components/TaskCard/FindingCard.tsx`, `frontend/src/utils/findingView.ts` (both new), `ArtifactViewer.tsx`, parts stamped with `schema_lineage`; test `FindingCard.test.tsx` (new, 7)). Ordinary conversations get the same check through a new `validate_output` tool (`app/mcp/tools/output_tools.py` (new), `app/mcp/builtin_tools.py` (`output_contracts` category, on by default), `app/utils/output_contracts.check_value`; test `tests/test_validate_output_tool.py` (new, 6)): give it a schema and a value and it returns the field-level errors, cross-field checks and resolved ledger claims a card would apply, or with no value the schema's fields; `store_output` does the same check and, when it passes, appends the value to the project's output store, `.ziya/outputs/.jsonl`, one file per schema family (`app/utils/output_store.py` (new); test `tests/test_output_store.py` (new, 6)). Findings emitted under a contract inside a Task Card run land in the same file, so one `analyze` query (`inputs={"f": ".ziya/outputs/finding.jsonl"}`) covers a run's findings and a conversation's, with nested access (`data.impact.fleet_total.mid.value`); re-storing a value with the same `data.id` is a new version. Fixed on the way (`app/utils/dataset_store.py` (`ensure_parquet`)): a JSONL file with nested objects registered as a dataset lost its structure when converted to Parquet (every object became a string, so `data.verdict` would not bind); conversion now goes through DuckDB's `read_json` when a column holds objects, and flat data keeps its former types. Live run 33d141aa then showed a lane emitting `alpha_finding` for a required `finding`, being told "recorded", and staying short through its correction turn and re-run; a part emitted under a name no contract declares now says which required outputs it does not satisfy and that the exact name is what counts, the prompt section says the same, the store's timestamp column is `stored_at` (`at` is a DuckDB reserved word, so `ORDER BY at` failed), and the run-side store hook writes to the card's project (the ledger root) and never to the process cwd, which test collectors opened without a request had been doing (`app/utils/task_artifacts.py`, `app/utils/output_contracts.py`, `app/utils/output_store.py`). Research harness M2 complete. - **Evidence ledger: where a reported number came from, and citations that export from it** (`app/utils/evidence/{store,verify,refs,service,citations}.py` (new), `app/mcp/tools/ledger_tools.py` (new; `ledger_record`, `ledger_query`, `ledger_verify`), `app/mcp/builtin_tools.py` (`evidence` category), `app/utils/document_ir.py` (`evidence:` front-matter kept), `app/services/pdf_exporter.py`, `app/routes/export_routes.py`, `app/data/built_in_skills.py` (document_authoring rule 6); tests `tests/test_evidence_ledger.py` (23), `tests/test_evidence_service.py` (6), `tests/test_ledger_tool_seam.py` (3), `tests/test_evidence_citations.py` (11); `Docs/DocumentAuthoring.md`, `Docs/Capabilities.md`; `design/evidence-ledger.md` Decisions 5–13). In a long investigation run the numbers were the product, but nothing linked a figure in the report to the query or file that produced it, a stale total survived next to its correction, and a per-incident statistic was computed from the wrong column with no record of which. The ledger keeps observations (a query, file or command and the SHA-256 of its result), claims (a named `namespace.key` value with its population, the column and expression it came from, and a tolerance) and verdicts, as HMAC-signed append-only JSONL under `/.ziya/ledger/` (a per-user key in `~/.ziya/ledger.key`; a hand-edited or unsigned line is skipped). A claim must name a source that exists; recording an id again appends a version that supersedes the old one; status (recorded, verified, drifted, refuted, superseded) is derived from the latest verdict. `ledger_verify` re-hashes a claim's sources (`rehash`) or re-evaluates its expression from the current input claims (`computed`); `rerun` waits for the job runner. Documents declare `evidence: {namespace, policy}` and cite `{{claim:key|fmt=.2%|unit}}`; export substitutes the value, appends an Evidence appendix, records each citation, reports hand-typed numbers in `X-Ziya-Evidence`, and under `policy: strict` refuses (400, listing ids) to publish an unknown, drifted or refuted claim. The write policy already refused tool writes into `.ziya/ledger/`; parallel writers are serialised with `flock` (10 processes × 200 records: no duplicate versions, 878 without the lock). Numbers produced inside shell scripts can be recorded too (`app/utils/evidence/scope.py`, `app/api/ledger.py` (new; `/api/ledger/record|query|verify`), `app/mcp/manager.py`, `app/mcp_servers/shell_server.py`, `app/utils/ziya_ledger_client.py` (new, stdlib-only), `app/cli.py` (`ziya ledger observe|claim|query|verify`); test `tests/test_ledger_shell_seam.py` (8)): every shell command the shell server runs gets `ZIYA_LEDGER_URL` and a signed, expiring `ZIYA_LEDGER_SCOPE` token naming the project and the conversation, run and block it was issued from; the routes accept nothing else and take provenance from the token, so a claim recorded by `ziya ledger claim` inside a Task Card names its block. Inside a Task Card (`app/agents/task_executor.py`, `app/agents/block_executor.py`, `app/context.py` (`evidence_namespace`, `ledger_root`), `app/utils/evidence/service.py`; test `tests/test_ledger_task_provenance.py` (5)): claims carry the run, block and enclosing loop iteration; a State variable `evidence_namespace` is the default namespace for the tools and the shell token; a task whose scope sets `cwd` still records into the project's ledger rather than a stray `/.ziya/ledger/`; and each task's artifact gains an "Evidence ledger claims" data part listing the claim versions it recorded. Acceptance (`tests/test_analyze_ledger_acceptance.py` (new, 4)): per-entity figures computed with `analyze` over synthetic CSVs are recorded as attested file and `analyze`-result observations plus claims, the reconciliation table is rebuilt from ledger claims alone, every claim re-hashes unchanged, and a changed raw CSV drifts exactly the claims derived from it. Research harness M1 complete. - **`ziya-install-extras --data/--stats` explains a failed install behind a private package mirror** (`app/utils/install_extras.py` (`_configured_index`, `_index_failure_hint`, `index_failure_hook`); tests in `tests/test_install_extras_data.py`). When pip is configured to use a private mirror whose login has expired, pip fails with a 401 followed by "no matching distribution", which reads like a missing package. When `pip install` fails, the installer now checks which index pip was set to use (`PIP_INDEX_URL`, otherwise pip's config). If that is not public PyPI, it names the mirror's host and prints the `PIP_INDEX_URL=https://pypi.org/simple/ ziya-install-extras …` retry command. Only the host is printed, because such URLs often contain the token. An edition can set `index_failure_hook` to replace that advice with its own. If the hook reports that it renewed access, the install is retried once. Successful installs are unchanged. - **`analyze`: read-only SQL over datasets, with primitives for telemetry analysis** (`app/utils/analytics/{__init__,guard,engine,primitives,analyze}.py` (new), `app/mcp/tools/dataset_tools.py` (`AnalyzeTool`), `app/mcp/builtin_tools.py` (`datasets` category), `app/server.py` (dataset routes mounted), `app/utils/dataset_store.py` (Parquet storage, lineage), `app/utils/install_extras.py` (`--data`, `--stats`), `pyproject.toml` (`data`, `stats` extras); tests `tests/test_analytics_{guard,engine,primitives,analyze,no_engine}.py`, `tests/test_analyze_tool_seam.py`, `tests/backend/test_dataset_parquet.py`, `tests/test_install_extras_data.py` (all new); `design/local-analytics.md`). Computation over registered data used to happen in the model's head, a Vega-Lite transform, or a `python3 -c` one-liner that was never kept. `analyze` runs one DuckDB query per call on a fresh connection that can read only the query's inputs: a sqlglot allowlist accepts a single `SELECT`, and DuckDB itself runs with external access off, the input files in `allowed_paths` and its configuration locked, with 120 s, 2 GB and 500,000-row limits. Eight table macros encode rules that are easy to get wrong by hand: `bin_with_coverage` (a silent bin is unknown, not zero), `counter_deltas` (a decrease is a reset), `intervals_union`/`_intersect`/`_subtract`/`interval_duration` (overlaps count once), `runs`, and `entity_distribution`. Every result is stored as a dataset whose `meta.json` records the SQL, each input's id and SHA-256 and the engine version; small results are returned inline, and a result with one entity column carries a per-entity distribution of each numeric column. Datasets are now stored as Parquet when DuckDB is installed; existing JSONL datasets convert on first use and the JSONL is removed only after the Parquet copy reads back with the same rows and columns. Needs `ziya-install-extras --data`; without it `analyze` says so and every other dataset tool works as before. This also wires up the phase-1 `dataset_*` tools and `/api/datasets` routes, which existed but were never registered or mounted. Acceptance: `tests/test_analyze_ledger_acceptance.py` recomputes per-entity distributions and totals from synthetic CSVs with `analyze` and checks that each distribution reconciles to its total. `ziya-install-extras --data` is handled in `install_extras.run()`, the entry point the internal edition's wrapper calls; it was first handled only in `main()`, which that wrapper never calls. - **Fork children carry a fork marker in the sidebar** (`frontend/src/components/ForkGlyph.tsx` (new), `frontend/src/components/MUIChatHistory.tsx` (`isForkChild`); test `frontend/src/components/__tests__/forkGlyph.test.tsx` (new, 6)). A plain fork (`lineageKind: 'fork'`) is nested under its source the same way a handoff continuation is, but only continuations were marked (⛓), so a fork read as an ordinary conversation one level down. Fork rows now show a small fork glyph before the title. It is an inline SVG drawn in the text colour, so it follows the theme and the selected-row colour. Bead branches (`lineageKind: 'branch'`) are not marked. - **`render_diagram` reports the rewrites preprocessing applied to the spec** (`app/utils/chart_rewrites.py` (new), `app/services/diagram_renderer.py` (`_classify_console_log` → `rewrites`, diagnostics `console_rewrites`), `app/mcp/tools/diagram_render.py`; `tests/test_chart_rewrites.py` (new, 6); `Docs/Capabilities.md`). The frontend fix-up passes log each change they make as a `🔧 TAG: …` console line, and the headless renderer already captured the console, but only warnings and errors were reported, so after a render the model could only guess why the image differed from its spec (the 2026-10-02 log-scale investigation spent several renders on exactly that). Those lines are now listed in the tool result under "Preprocessing changed the spec before rendering", with execution traces (`*-DEBUG`, `ENHANCER-INPUT`, `VEGA-EMBED`) and progress lines dropped, duplicates removed and the list capped at 25. Rendering is unchanged. Not yet done: listing the rewrites in the chart's own UI for the user. Research harness M0 (`design/harness-small-items.md` item 3). - **`show_document`: show a file to the user without the model retyping it** (`app/mcp/tools/show_document.py` (new), `app/utils/show_document.py` (new), `app/mcp/builtin_tools.py`, `app/tool_execution.py`, `app/streaming_tool_executor.py`, `app/utils/tool_history_rewrite.py`, `frontend/src/utils/renderToolPart.ts`, `frontend/src/components/MarkdownRenderer.tsx`; tests `tests/test_show_document.py` (new, 15), `frontend/src/utils/__tests__/showDocumentRender.test.tsx` (new); `Docs/Capabilities.md`). Asked to render a report inline, the model's only option was to retype it, which the parroting detector correctly interrupted. The server now reads the file (same path rules as `file_read`), the user sees it as an expanded rendered block captioned with path, line range, size and SHA-256, and the model receives only a summary (path, lines, sha256, headings). The document is taken off the result after signature verification, so it never reaches the model, the sanitizer or the parroting index, and replayed history carries a one-line note instead of the body. `heading` shows one section and `start_line`/`end_line` a range; selections over 512 KB are refused with the heading list; lines of four or more backticks are rewritten to tildes so they cannot close the chat's tool fence. PDFs show name and page count; images are refused. Research harness M0 (`design/harness-small-items.md` item 1). - **`memory_delete` tool, with consent decided by who created the memory** (`app/mcp/tools/memory_tools.py` (`MemoryDeleteTool`), `app/mcp/builtin_tools.py`, `app/utils/consent_gate.py` (`op_for_call` gains a `consent_op_for(args, conversation_id)` tool hook and a `conversation_id` argument), `app/tool_execution.py`; tests `tests/test_memory_delete_tool.py` (new, 16); `Docs/ArchitectureOverview.md`). The agent could save and propose memories but not remove one, so a memory it had just made redundant stayed until the user found it in the panel. A memory saved with `memory_save` in the current conversation is deleted without a prompt (the agent undoing its own unreviewed action, as `memory_retract_proposal` does for proposals). Any other memory — promoted from the proposal queue, auto-extracted, REM-synthesised, or from another conversation — opens the consent panel with the memory's text. Ownership is not an argument, so the gate's op is now derivable by a tool hook; with no conversation id the op is the least-trusted one, so a broken gate refuses rather than deletes. Deletion is the UI's `MemoryStorage.delete`, which also drops mind-map refs and the embedding. - **Task rail and task update feed: running tasks come out of the thread** (`frontend/src/components/TaskCard/TaskRail.tsx`, `TaskUpdateFeed.tsx`, `taskSurfacing.ts`, `task-surfacing.css` (all new), `frontend/src/components/Conversation.tsx`; tests `frontend/src/components/TaskCard/__tests__/taskSurfacing.test.ts`, `taskSurfacingWiring.test.ts` (new); `design/task-cards.md` §In-flight state). An inline tile auto-collapses to a one-line receipt and scrolls away with its turn, so in a long conversation a run that finished — or stopped waiting on a decision — was lost among the noise. A sticky **task rail** under the chat header now shows one chip per task of this conversation that is live or waiting on you (attention first; an open Ask on a reconciled-`held` run reads as "waiting on you"); a chip scrolls to the tile and flashes it. A **task update feed** posts a card at the bottom of the thread when a bound run moves into done / partial / failed / cancelled / held / awaiting_input while you are there, with the status hint and **Go to task**; one card per run, withdrawn when the run goes live again, never for the first status seen on load or for a tile already at the bottom. The rail shows standing state and never finished work; the feed shows transitions and never nags about a run that is merely still running. Every tile mount carries a `data-task-binding-id` slot as the scroll target. - **Explicit `git _{` shell grants now warn about what they admit and point to the `git` tool** (`app/utils/git_grant_hazards.py` (new), `app/mcp_servers/shell_server.py` (startup warning in `_build_safe_command_patterns`, replacing the bare-`git` line), `app/cli.py` (`_print_git_grant_warning` on `/shell git `, `/shell git all`, `/shell add`; help text names the risky flags), `app/routes/mcp_routes.py` (`POST /api/mcp/git-grant-hazards`), `frontend/src/components/ShellConfigModal.tsx` (warning before Save); tests `tests/test_git_grant_hazards.py` (new, 68), `frontend/src/components/__tests__/shellGitGrantWarning.test.ts` (new, 3)). design/git-tool.md step 6, revised from "deprecate" to "warn and redirect": the grants are signed and kept. A grant like `git push` becomes `^git\s+push(\s+.*)?$`, so it also admits `--force`, `--delete` and `:`; `git checkout` admits `checkout -- .`. One catalogue of 35 subcommands feeds every surface, and `TestClaimsAreTrue` checks the headline claims against the pattern the shell server really builds, with a control showing the forms are refused without the grant. Explicit `log`/`diff`/`show`/`blame` grants are flagged because they bypass the new `--output` guard. The read-only tier's own entries are not flagged.
- **`git` tool: the first approval panel no longer waits ~6.5 s** (`app/mcp/tools/git_tool.py` `_model_alias`). The provenance trailer's model name was read via `app.agents.models`, whose import (LangChain included) ran inside the consent preflight in a fresh process. It now reads `ZIYA_MODEL` and uses `ModelManager` only if already loaded.
- **Per-project tool modes: a project can run `git` disabled, gated (approve each call) or autonomous** (`app/utils/project_tool_modes.py` (new), `app/models/project.py` (`ProjectSettings.toolModes`), `app/utils/consent_gate.py` (project mode consulted before `permissions.json`), `app/streaming_tool_executor.py` (per-project add/remove in the tool loader), `frontend/src/types/project.ts`, `frontend/src/components/ProjectManagerModal.tsx` (Git tool control); `tests/test_project_tool_modes.py` (new, 16, incl. a seam through `_load_and_prepare_tools`), `frontend/src/api/__tests__/projectToolModesSave.test.ts` (new, 4)). design/git-tool.md step 5. Stored as `settings.toolModes = {tool: mode}`; unset inherits. `disabled` removes the tool from that project's tool list and refuses any call that still arrives. `gated` asks for every op the tool considers mutating (`status` still runs unprompted) and overrides a global `always`. `autonomous` runs unattended, including from task-card steps, which previously couldn't use `git` at all. Gated and autonomous make `git` available in that project even when the category is off globally. No signature is required (decided 2026-09-25). Documented as accepted residual risk 7 in `Docs/ThreatModel.md`: the agent can reach the local API from the shell, so approval and project mode protect against a model that makes mistakes, not a hostile one. The tool's structural limits hold regardless.
- **`git` builtin tool: the model can stage, commit, stash, push and switch branches, with each mutating call approved by you** (`app/utils/git_ops.py` (new), `app/mcp/tools/git_tool.py` (new), `app/mcp/builtin_tools.py` (category `git`, off by default), `app/config/env_registry.py` (`ZIYA_GIT_PROVENANCE_TRAILER`), `app/utils/consent_gate.py` (`declared_mode`, `consent_op_defaults`, `fails_closed`, preflight receives the execution project root), `app/tool_execution.py` (fail-closed gate, `project_root` passed to the gate); tests `tests/test_git_ops.py` (new, 50, real temporary repos + bare remote), `tests/test_git_tool_seam.py` (new, 4), `tests/test_consent_gate.py` (+6)). design/git-tool.md step 2, the first consumer of the consent runtime, and the replacement for the retracted shell `WRITE_GIT_OPERATIONS` regex tier. Structured arguments only: `--force`, `--amend`, `--no-verify` and `-c` overrides can't be expressed, and reset / clean / restore / rm / mv / rebase / merge / cherry-pick / ref deletion / force push aren't offered at any level. They remain behind the shell's signed bare-`git` grant. `add` expands the paths and checks each file against the same write gate `file_write` uses. Permitted files are staged and the rest are returned as `refused`; a still-conflicted file is refused. `commit` requires a message, commits the index (or, with `paths`, exactly those tracked files, all-or-nothing against the policy), reports `partially_committed` files, always runs hooks, and appends `Co-authored-by: Ziya` / `Ziya-Model:` trailers. `push` pushes only the current branch with a non-`+` refspec and warns about uncommitted work. `switch` refuses a dirty tree. Git runs with `shell=False`, literal pathspecs, prompts, editors and pagers disabled, and `GIT_DIR`/`GIT_WORK_TREE`/`GIT_CONFIG_*` stripped. Every op except `status` is `ask`. The approval panel shows the op's real plan, computed against the conversation's project root (previously a tool preflight would have resolved against the server's cwd), and the plan is recomputed at execution. Two gate changes apply to every tool: a permissions read error now falls back to the tool's declared mode instead of `off`, and a gate failure for an op the tool declares `ask` now refuses the call instead of dispatching it unattended. Enable with `ZIYA_ENABLE_GIT=true` or the builtin-tools toggle. This needs no signature, because no mutating call runs without an approval. Known gaps: a task-card step calling `git` is refused (no conversation to ask in), and "Always" is still a session grant.
- **Files a conversation writes now join its context, or are tracked when too large** (`app/utils/auto_context.py` (new), `app/mcp/tools/fileio.py`, `app/mcp/tools/context_management.py`, `app/routes/diff_routes.py`, `app/server.py`, `frontend/src/apis/chatApi.ts`, `frontend/src/components/MarkdownRenderer.tsx`, `tests/test_auto_context_writes.py` (new, 18), `design/auto-context-tiers.md` phase 1). Before this, neither the apply button (its request carried no `conversation_id`) nor the `file_write` tool told the conversation anything, so the files a conversation changed got no change markers. On 2026-09-24 that led the model to report an already-fixed `pyproject.toml` as broken. Now a successful write of a project file under the project's `auto_add_token_limit` (default 12,500 tokens) adds it to the chat's `additionalFiles` with a new owner, `auto` (`_autoAddedFiles`), so the existing model-pinned merge puts it in the next prompt. Auto-added files live only on that conversation's chat record and are deliberately NOT pushed into the file tree's selection: that selection is per browser tab, not per conversation, so syncing into it would send the file with every conversation opened in the tab. A larger file is not added: `_autoTrackedFiles` records its pre-write and post-write hashes and size, and each turn the model gets one line per tracked file (when this conversation last wrote it, and whether it changed on disk since), never the content. That notice goes on the final user message with the handoff turn part, not in the cached system prompt. Files the user pinned or the model added keep their owner. `.ziya/` and paths outside the project are ignored. No chat record is created as a side effect. `context_remove_file` can now remove `auto` files, and `context_list_files` reports the `auto` owner and the tracked list. Recording is best-effort and never turns a successful write into a failure. Not yet: decay (an `auto` file stays until removed), the file-index "tracked" badge, and the CLI diff applicator path.
- **Server instance identity, and no more phantom projects from a stale `~/.ziya`** (`app/utils/instance_id.py` (new), `app/utils/bind_check.py` (new), `app/middleware/instance_header.py` (new), `app/models/project.py`, `app/api/projects.py`, `app/server.py`, `app/main.py`, `tests/test_instance_identity.py` (new, 18)). Everything the browser persists — IndexedDB, localStorage, BroadcastChannel names, Web Locks — is keyed by origin (`localhost:PORT`), and an origin says nothing about which server is behind it. Two incidents: a port that had served a local Ziya was later reached through `ssh -L` to another host, and `lsof` showed *both* still listening — the tunnel had bound `[::1]:8888` after its `127.0.0.1` bind failed against the local server, with only a one-line ssh warning — so `localhost:8888` was two backends selected per connection, and a stale tab's `knownServerConversationIds`, dual-write pushes and shared `ziya-project-` broadcast channel operated across both; and a user returning after a year was dropped into a project whose directory no longer existed, because nothing on the server ever checked `project.path` before handing it out, so every `X-Project-Root` the tab then sent was silently rejected while the UI claimed to be in that project. This is the server half of the fix. Each installation gets a stable id in `~/.ziya/instance_id` (created on first boot; it lives with the data, not the package, so an upgrade or a reinstall that keeps `~/.ziya` is a non-event and a wiped `~/.ziya` correctly reads as a different installation); every HTTP response carries it as `X-Ziya-Instance` via a raw-ASGI middleware that touches only `http.response.start` (SSE bodies pass through byte-identical), and `/api/v1/projects/startup` reports it as `instanceId`. `/last-accessed` now skips records whose directory is gone and returns 404 rather than auto-creating when none remain; `/{id}` refuses a project whose directory is gone (the list endpoint is unchanged so the record stays visible to repoint or delete). At startup the server probes the other loopback family and prints a warning when `127.0.0.1:PORT` and `::1:PORT` are about to be served by different processes, naming `ssh -L 127.0.0.1:PORT:...` as the fix. The client half — namespacing all origin-scoped storage by instance id with no adoption path for an unowned cache, and a per-response latch that halts a tab whose backend changes underneath it — is the entry below.
- **Browser storage is scoped to the server instance; a tab whose backend changes underneath it stops writing** (`frontend/src/utils/instanceIdentity.ts` (new), `frontend/src/index.tsx`, `frontend/src/context/ProjectContext.tsx`, `frontend/src/context/ChatContext.tsx`, `frontend/src/utils/db.ts`, `frontend/src/utils/projectSync.ts`, `frontend/src/utils/retentionPurge.ts`, `frontend/src/types/project.ts`, `frontend/src/utils/__tests__/instanceIdentity.test.ts` (new, 14), `projectSyncInstanceScope.test.ts` (new, 5), `noUnscopedOriginNames.test.ts` (new static guard, 4)). Every origin-shared name the client uses — the IndexedDB database and its promotion key, `ZIYA_LAST_PROJECT_ID`, the per-project lens keys, the `ziya-project-` BroadcastChannel, and the three `ziya-db-*` Web Locks — now carries the connected server's `instanceId` as a suffix. Two tabs on the same port talking to different installations therefore share nothing: not a database, not a broadcast (the most plausible mechanism for the 7123 tab's conversations vanishing live and returning on refresh was a `conversation-deleted` crossing the shared `ziya-project-` channel from the half-bound 8888 tab), and not a lock (previously a hung foreign tab could stall this one into the 30s "another Ziya tab is blocking" path). There is deliberately **no adoption path** for an unowned pre-upgrade `ZiyaDB`: a stale cache from a dead server and one's own pre-upgrade cache are indistinguishable, and that ambiguity is exactly the door both incidents walked through — so the first load after upgrade is a re-pull from the server per browser per instance, and the old database is left untouched for a later explicit-review surface. A `window.fetch` wrapper installed before any module fetches latches the first `X-Ziya-Instance` seen and, on any response carrying a different one, halts the tab: non-GET `/api` requests are refused, the periodic sync loop bails before reading a possibly-mixed list, and one persistent error names both ids and the likely cause (a port conflict such as an `ssh -L` tunnel). Reads still flow so the UI can render. A server that reports no id keeps every name unsuffixed — byte-identical to pre-feature behaviour — and `null` never overrides a real id. `db.init()` now resolves its names asynchronously (awaiting the id) while still assigning `initPromise` synchronously so concurrent callers share one init; `projectSync.join()` likewise waits, with an epoch guard so a project switch during the wait opens nothing for the old project. `ProjectContext` shows the first-run picker whenever startup context exists and no usable project was found (the server now refuses projects whose directory is gone, so "projects exist but none is usable" is a real state that previously fell to `/projects/current` → 400 → no project and no picker). The static guard fails on any literal lock/channel/DB name outside `instanceIdentity`, and was confirmed red against the unpatched tree with exactly the 13 sites this change rewrote.
- **Closing a tab inside the 2-second dual-write debounce no longer strands the last writes in IndexedDB** (`frontend/src/utils/pagehideFlush.ts` (new), `frontend/src/context/ChatContext.tsx`, `frontend/src/utils/__tests__/pagehideFlush.test.ts` (new, 10)). ChatContext writes to IndexedDB immediately but pushes to the server on a 2s debounce; `beforeunload` only warned about an in-flight stream and flushed nothing, and the code's "will retry next sync" assumed a tab that no longer existed. With browser storage now scoped per server instance and never adopted, "it reached the server" is what makes a cache droppable, so this was the most common remaining way a conversation could end up cache-only. A `pagehide` listener now cancels the timer and sends the pending set with `fetch(..., { keepalive: true })`. Scope is deliberately narrow: the debounce filter (active, not a shell, not an empty "New Conversation") is extracted to `selectDirtyConversations` and both existing timers call it, so the flush cannot push anything the timer would not have pushed two seconds later, and the server's version/regression guards apply unchanged. It refuses when the instance latch has halted the tab, and when the body exceeds the browser's 64 KiB keepalive cap it logs and leaves the ids pending rather than claiming success. The anchor test is a stale record in the pending set producing zero requests; a seam test asserts the inline filter copy is gone from ChatContext so a partial apply fails loudly.
- **Shadow line control: "approve all" at the confirm banner, and plain-English grant/confirm prompts** (`app/shadow/lease.py`, `app/shadow/sock_server.py`, `app/shadow/pty_host.py`, `tests/test_shadow_approve_all.py` (new, 3)). Under a `gated` or `supervised` lease every not-allowed command produced a y/n banner with no way to say "yes to all of them", and the banners read as protocol (`requests line control · gated · policy builtin · [g] grant · [n] deny`) rather than telling the human what they were deciding. The confirm banner now offers `[y] run it · [a] run it and stop asking for this chat · [n] refuse · [x] refuse and revoke control`; `a` sets a lease-scoped `auto_approve` flag (journaled as `control_auto_approve`; each command it waves through as `control_auto_approved`), which ends with the lease and shows as "active, approve-all" in the `C-x C-z` menu where `[r]` still revokes. The grant banner explains the request in words (`describe_restriction`: "read-only commands run freely; anything that writes or is off the allowlist asks you first") with `[g] allow it · [n] refuse`. Authority is unchanged: both are keystrokes at the physical terminal, never socket ops.

### Fixed
- **Until-condition judge now reads emitted text parts, and treats "is committed / is listed" as a state, not an action** (`app/agents/until_evaluator.py`, `app/utils/self_improve.py` (`render_text_parts_for_judge`, `JUDGE_TEXT_CHARS_CAP`), `tests/test_until_evaluator_evidence.py` (+5)). The judge's prompt showed data parts' contents but only *counted* text parts ("1 text"), while its rules of evidence said a condition naming a list or report is true only if DATA or OUTPUTS shows it. A body whose contracted deliverable is a `ziya:text` part therefore could never pass a condition about that list: sweep run cli-c72ef56d7591's P5 loop was refused three times for "DATA is empty" with the 46-path residue accounting sitting in the `residue` text part, and once for "no commits were made this iteration" against a condition that says "is now committed". Text parts are now rendered (labelled, capped at 6 KB) in a TEXT PARTS section, the evidence rule admits them, and the prompt says a state-shaped condition is judged on the end state, so a no-op pass satisfies it when the state already holds.
- **The release sweep no longer leaves hundreds of files uncommitted after a file is edited between runs.** Two leaks combined. First, `release_hunks.py reconcile` counted a contended file as attributed when its hunk count was unchanged and its saved patches still passed `git apply --cached --check`. An edit made after the split inside or beside an existing hunk passes both checks, since `--cached` checks against HEAD, not the working tree. So the file was skipped by re-attribution, its patches covered only part of its diff, and the commit plan then dropped every group depending on it. One run lost 31 groups and about 300 paths this way from 4 such files. Reconcile now also requires each patch to hold exactly the current hunks attributed to its entry. Second, `release_plan.py batches` counted an `exclude` verdict on a tracked modification as triaged, although the commit plan rejects that verdict, so those paths were never triaged again. They are now re-batched and listed under `rejected_excludes`, and the sweep card's triage prompt states that only untracked files can be excluded. (`scripts/release_hunks.py`, `scripts/release_plan.py`; tests `tests/test_release_hunks_reconcile.py`, `tests/test_release_plan_batches.py`, `tests/test_release_tooling.py`)
- **Card-level permissions set in the deck now save.** Skills (or any other field) added under a card's **Card Permissions** showed as "n skills" on the card, then disappeared after switching to another card and back, even after pressing Save in the dialog and on the card. The editor put the new scope on the in-memory draft, but the deck's three save calls (Save, Add to deck, and the save before launching to a chat) sent name, description, root and tags and left out `scope`. Updates are partial, so the server kept the old scope, and reopening the card loaded it back. All three now send `scope`. The save from the chat's task-card button already did. (`frontend/src/components/TaskCard/TaskCardsLibrary.tsx`; test `frontend/src/components/TaskCard/__tests__/deckSavesCardScope.test.ts`)
- **A response that cites a diff it never emitted is now sent back for the diff before the turn ends.** The pattern: a turn writes its tests and changelog through direct-write tool calls, the one change that has to be a *text* `diff` fence (a non-writable path) is decided in reasoning and never written, and the prose — even the changelog entry — says "(diff above)". It recurred in eight conversations since 2026-09-19 and was caught every time by the user asking "did you apply it?". The harness already catches the two neighbours of this failure (a narrated tool call that was never made; a diff that does not apply) but nothing covered a narrated diff. The post-stream validation hook now also checks for a diff *reference* ("the diff above/below", "apply the diff", "the diff I provided") in prose outside fences and reasoning when the response carries no diff fence at all, and uses the existing feedback-and-restart pass to ask for the fence — or for one sentence saying the change was a direct write, so a false positive costs a sentence. The restart prompt is worded for this case rather than claiming a diff "failed to apply". The system prompt's pre-diff checks keep their "silent" wording but now say the diff itself is never silent, give the "do not generate the diff yet" rule a resumption (read the file, then generate it in this response), and exempt a merely-described diff from the "do not re-emit" rule. (`app/utils/phantom_diff.py` (new), `app/utils/diff_validation_hook.py`, `app/server.py`, `app/agents/prompts.py`; tests `tests/test_phantom_diff_reference.py` (new, 23), including the stored turn that motivated it)
- **A headless task run no longer freezes on a tool that is waiting for a human to approve it.** `ziya task sweep` sat four hours after printing `⚙ mcp_run_shell_command`: the model had reached for the `[DIRECT] git` builtin to commit, that tool declares `consent_default = "ask"`, and the consent gate parked the call in the ledger (24 h TTL) for an answer the terminal has no way to give — the CLI event sink has no branch for `consent_opened`, so nothing was printed. Every prior CLI sweep run had the same open `git add`/`git commit` request. Rather than teach the gate to refuse, a run with nobody on it — the CLI card runner (`ExecutionContext.headless`) or a scheduler fire persisted as `launch_context="headless"` — now withholds every `ask`-mode builtin from the tool payload, so the model never sees a `git` tool and uses the shell `git` the task instructions prescribe. Applied where the payload is built (`tool_denylist` into `StreamingToolExecutor._load_and_prepare_tools`, before the scope allowlist, so a scope naming `git` cannot restore it) and recorded in the task's `decisions`. A project that set the tool `autonomous` keeps it. GUI task tiles, which have an approval panel, are unchanged. (`app/utils/task_tool_floor.py` (`unattended_denied_tools`), `app/agents/task_executor.py`, `app/agents/block_executor.py`, `app/cli_card_runner.py`, `app/streaming_tool_executor.py`; tests `tests/test_task_executor_headless_tool_denial.py` (new, 8))
- **The model no longer sees dispatch-routing keys in its own prior tool calls, so it stops inventing them.** `execute_single_tool` adds `_workspace_path`, `conversation_id` and `_task_scope` to a call's arguments for dispatch; it did so in place on the dict the streaming executor later serialises as the assistant's `tool_use.input`. From the second turn on the model was shown parameters it never wrote and imitated them, and weaker models mangled them turn by turn — the release sweep's triage tasks sent `conversion_id`, `project_root`, `workspace_path_alt2`, `task_scope_3` on every shell call, each an `Unknown parameter` warning and, for a schema-validated tool, a rejected call. The args are now copied before any routing key is added; a human's approval-panel edit (a rewritten commit message) is applied before the copy, so the recorded call still shows what actually ran. (`app/tool_execution.py`; tests `tests/test_tool_args_not_leaked_to_model.py` (new, 2))
- **A task run that is waiting for a human now says so on the terminal, and each finished task stream releases its feedback monitor.** Two findings from the same lldb dump of the frozen sweep. (1) The consent gate's `consent_opened` chunk had no branch in `task_executor`'s chunk loop, so it reached no sink: a CLI run blocked on an approval printed nothing. It is now forwarded as a `task_hold` event (tool, op, request id, plus a `waiting for approval: git commit` progress note), and the CLI sink prints `⏸ waiting for approval: git commit` with the ledger location, and `⏵ … : approve|reject` when answered; `ask_opened`/`ask_answered` from an Ask block render the same way. (2) 46 `_feedback_monitor` tasks were alive, one per completed task iteration: the monitor's cancel sites all sat on explicit return paths after the iteration loop, and a consumer that breaks on `stream_end` (the CLI, `task_executor`) never reaches them. The cancel moved to `stream_with_tools`'s `finally`, fed by a holder the impl fills, and `task_executor` now closes the generators it breaks out of (`contextlib.aclosing`) so that `finally` runs on the way out rather than whenever the asyncgen GC hook gets to it. (`app/agents/task_executor.py`, `app/cli_card_runner.py`, `app/streaming_tool_executor.py`; tests `tests/test_task_hold_event.py` (new, 2), `tests/test_feedback_monitor_lifetime.py` (new, 4)). Closing the stream promptly exposed a third: the Bedrock parser stays suspended after `message_stop` with the HTTP body still open past the last event, so a prompt close finalized urllib3's generator un-drained and printed `Exception ignored in: ` / `ValueError: I/O operation on closed file` to stderr once per model call. `_parse_stream` is now a wrapper that closes the body before the parser's frame unwinds (the ordering the CancelledError branch already used), and `stream_response` closes the parser in the consumer's own task; the body is also released on a normally exhausted stream, which it never was. (`app/providers/bedrock.py`; tests `tests/test_bedrock_stream_prompt_close.py` (new, 2))
- **A `VAR=$(…)` whose output has more than one line (or spaces, quotes or `>`) no longer runs the second line as a command.** `LB=$(aws elbv2 describe-load-balancers … --output text); aws … --load-balancer-arn "$LB"` with two matching load balancers failed the whole tool call with `[Errno 2] No such file or directory: 'arn:aws:…'`. The executor splices a substitution's stdout back into the segment text and re-tokenizes it, so `LB=arn1\narn2` was peeled as `LB=arn1` and `arn2` became argv[0]. Output is now re-quoted when the substitution sits in an assignment value (`LB=$(…)`, `A=1 B=pre$(…) cmd`) or inside double quotes (`"$(…)"`), matching bash, where neither position word-splits; an unquoted argument position still splits as before. Separately, a missing executable now reports `name: command not found` with exit 127 (126 for a permission error) and the pipeline continues, instead of the `FileNotFoundError` escaping as an opaque tool error. (`app/mcp_servers/shell_server.py` (`_subst_context`, `_quote_subst_output`, `_resolve_substitutions`, `_execute_pipeline`); tests `tests/test_shell_substitution_output_quoting.py` (new, 14))
- **`task_card_write` edits can now set any scope field, so a model no longer has a reason to rewrite the deck file by hand.** `edits` accepted only `scope.cwd`; every other `scope.*` key, including `tools`, `skills`, `model_tier`, `service_tier` and `shell_timeout_secs`, which the signing hash does not even cover, was refused with "ask the user". A model that needed to change a block's scope read that as "the tool can't", and reached for a `python3` one-liner against the deck JSON. That gains nothing (grants are authorized by a root-signed approval matching the block's current scope, not by the card file), but the refusal was teaching the workaround. `scope.` now works for every `TaskScope` field, validated through the model; the merged tree is then checked by each leaf task's *escalation block* (own scope plus ancestors, the same union the runtime gate hashes) rather than full-scope equality. A grant may stay the same or narrow but never widen: a new `shell_command` or out-of-floor writable path is refused with a message that states the mechanism and the sanctioned path (`ziya-approve` via the editor's escalation panel) and says outright that editing the deck file elsewhere gains nothing. A narrowing edit saves and reports `resign_required` with the block ids whose approval no longer matches. The whole-`root` path keeps the existing exact-scope guard, with its remedy text now pointing at `edits`. The tool-side half (calling `escalation_changes` on the edited tree instead of the whole-root guard, reporting `resign_required`, and correcting the tool description that still said scope fields other than `cwd` were not editable) landed later. Until it did, a model told "scope.cwd only" concluded that adding `document_authoring` to two stages' `scope.skills` meant reserializing a ~114 KB card it could not read in full. (`app/utils/task_card_edits.py`, `app/utils/task_card_write_guard.py`, `app/mcp/tools/task_card_tools.py`; tests `tests/test_task_card_edits.py`)
- **`task_card_read` can return one block or an outline instead of the whole card.** `block_id` returns just that block's subtree. `outline=true` returns the skeleton: each block's id, type, name, non-empty scope fields and a 120-character preview of its instructions. On a card too large to read in one response, a model can now find the id it needs and read or edit that block alone (`app/mcp/tools/task_card_tools.py`; tests `tests/test_task_card_edits.py`).
- **`ziya shadow --allow-control` is the grant; the per-lease `[g]` banner is gone.** Running with `--allow-control` (or setting the ceiling from the `C-x C-z` menu) already meant "chats may drive this terminal", yet a chat's `shadow_control` then put up a second prompt — *chat X wants to type commands… [g] allow / [n] refuse* — and under `gated` the first off-list command asked a third time. The second prompt also only accepted `g`: `y` counted as "any other key" and *refused*, and a chat that remembered a session id kept requesting in a window the user had left, so `shadow_send` sat on `lease_pending` and the model waited on a journal that could never move. The lease is now active on acquire for every session with a ceiling (`control_disabled` for none, as before). The terminal announces it instead of asking — *chat 41c2 now has control of this terminal (gated: read-only commands run freely; anything that writes or is off the allowlist asks you first; allowlist: builtin) — C-x C-z, r to revoke* — and deepens the tint, so delegation is visible without capturing the keyboard. The per-command confirm (`y` / `a` stop asking / `n` / `x` revoke) is unchanged: it is what `gated` means, and `--allow-control`'s help now says so, with `supervised` and `unrestricted` as the alternatives. `pending_grant` is dropped from the wire reply and the tool's note. The earlier `[Unreleased]` entry describing tty-naming, sibling-window announcements and a `g`/`y`/`a` grant banner shipped only its tests and design text; those tests are replaced by this behaviour's. (`app/shadow/sock_server.py`, `app/shadow/pty_host.py`, `app/cli.py`, `app/mcp/tools/shadow_tools.py`, `Docs/design/shadow-sessions.md` §6.1; tests `tests/test_shadow_grant_confirm.py` (rewritten), `tests/test_shadow_control_tools.py`, `tests/test_shadow_approve_all.py`, `tests/test_shadow_tint.py`, `tests/test_shadow_security_control.py`, `tests/test_shadow_control_audit.py`)
- **Stray blank lines no longer appear mid-word after a diagram block** (`app/utils/streaming_optimizer.py`, `tests/test_whitespace_displaced_across_viz_block.py` (new)). A whitespace-only streaming delta (the `\n\n` before a fence) was left in the content optimizer's buffer because `flush_remaining()` only returned a buffer with visible text. The viz path drains the optimizer with that call before emitting a `mermaid`/`vega-lite`/… block from its own buffer, so the blank line vanished from before the fence, sat there while the block streamed past, and was prepended to the next word — `lives:```mermaid … Guard\n\nian`. The same drain runs at a tool_use start. `flush_remaining()` now returns whatever the buffer holds; every caller already guards on a non-empty result.
- **A colon in a gantt task name no longer breaks the whole chart** (`frontend/src/plugins/d3/mermaidGanttTaskColons.ts` (new), `frontend/src/plugins/d3/mermaidEnhancer.ts`, `frontend/src/plugins/d3/__tests__/mermaidGanttTaskColons.test.ts` (new)). Mermaid ends a task name at its first colon, so `In service (contacts from 04:29) :10-10 02:16, 10-11 07:00` failed with "Invalid date:29) :10-10 02:16". Colons before the real separator (the first colon followed by valid task data) are now rewritten to `#58;`, which renders as `:`. Lines that already parse are left unchanged.
- **The model no longer tells you the context is filling up, or winds its work down because of it.** Two prompt injections produced that behaviour. The handoff feature's prelude nudged the model from 70% of the context limit, on every turn until a draft existed, with "consider starting a handoff draft … a suggestion to raise with the user"; and the streaming executor staged a "Context Size Notice" at 85/90/95% ("consider wrapping up large reads", "stop reading new content and summarize now") that it injected into the conversation. Together they made every long conversation end with the model announcing context pressure and refusing ordinary reads in exactly the last stretch of the window where the work gets done. The Context Size Notice is removed. The handoff trigger is kept but made late and silent: at 90% of the limit (`ZIYA_HANDOFF_NUDGE_RATIO`, was 0.7) the model is told to write the draft that turn and explicitly not to mention the draft, context size or wrapping up, and to carry on exactly as it otherwise would; the same instruction is in the living-draft prelude once a draft exists. The pressure figure still feeds the drawer's "context N%", but `handoff_read` no longer hands it to the model. (`app/utils/handoff_prelude.py`, `app/mcp/tools/handoff_tools.py`, `app/streaming_tool_executor.py`; tests `tests/test_handoff_draft_prelude.py`, `tests/test_handoff_tools.py`, `tests/test_context_size_notice_tiers.py`)
- **Vega-Lite charts that format a string date with `timeFormat` no longer collapse to "NaN".** A `calculate` such as `timeFormat(datum.t,'%m-%d')` over an ISO-string field produced `NaN-NaN` for every row, because Vega-Lite only parses a field into a date when it is encoded `temporal`; a heatmap's 30 columns merged into one. The preprocessor now wraps the argument of `timeFormat`/`utcFormat` in `toDate()` inside expression strings (`calculate`, `filter`, `labelExpr`, `test`, `expr`, nested views included), normalises `+datum.t`, `toNumber(datum.t)` and `datetime(datum.t)` there, leaves epoch-number fields alone, and switches to `utcFormat` when every value of the field is a date-only string (which `timeFormat` would show as the previous day west of UTC) or states UTC explicitly with a trailing `Z` or zero offset. Offset-less, mixed and non-zero-offset values keep `timeFormat`. (`frontend/src/plugins/d3/vegaDateExpr.ts`, `frontend/src/plugins/d3/vegaLitePlugin.ts`, `frontend/src/plugins/d3/__tests__/vegaDateExprRepair.test.ts`)
- **A wide top/bottom legend in a narrow hconcat panel no longer pushes the panels apart.** Vega sizes each concat column by its cell's full bounds, legend included, so a 14px colour stripe with a three-column bottom legend got a 525px column, and the panels beside it started 500px late. The renderer now narrows the legend's column count to fit the cell. If even one column won't fit, it lays the row out with `bounds: "flush"` and fits the legend into the space before the next panel's own legend. Flush is skipped if a neighbouring panel has a side axis or side legend that would overlap, and an authored `bounds` is never changed (`frontend/src/plugins/d3/vegaLegendPlacement.ts`, `fitNarrowConcatCellLegends`).
- **Sweep triage stages no longer overflow Haiku's 200k context.** The two P3 triage tasks in `design/sweep-orchestrated.task-card.json` run at `model_tier: small` (haiku-4.5 on Bedrock, 200k). With no tools allowlist, every task started at about 126k tokens of tool definitions, and one batch failed with `prompt is too long: 200825 tokens > 200000` (run cli-7b1daa542f37). P3a is now limited to `run_shell_command` and `file_read`, and P3b to those two plus `file_write`. The always-available floor (`emit_artifact` and similar) is still added on top. `tests/test_sweep_orchestrated_card.py` checks that every small-tier task has an allowlist and that the allowlist keeps the tools each stage's instructions use, using the real filter.
- **Token-calibration saves no longer stall the event loop.** `TokenCalibrator.record_actual_usage` and baseline establishment saved `~/.ziya/token_calibration.json` inline on every early sample. Each save took a cross-process file lock (up to 10 s) and rewrote the whole file, from `StreamingToolExecutor._handle_usage_event` on the server's event loop. They now call `request_save()`, which coalesces requests onto one daemon writer thread and flushes at exit. `_save_calibration_data()` stays synchronous for explicit callers. (`app/utils/token_calibrator.py`, `app/streaming_tool_executor.py`, `tests/test_calibration_save_off_loop.py`)
- **A model stream that closes without a terminal event is re-issued instead of ending the turn** (`app/streaming_tool_executor.py` (`_decide_no_tool_outcome`: new `dropped_stream_retry` branch); tests `tests/test_decide_no_tool_outcome.py` (`TestDroppedStream`, 8), `tests/test_stream_loop_recovery_seam.py` (`TestDroppedStreamRetry`, 3)). `last_stop_reason` is reset each iteration and set only from a `StreamEnd`, and every provider's `StreamEnd` carries a concrete reason, so `None` means the transport closed with no terminal event. It used to be treated as a clean `end_turn`. After tool results that cost the single empty-after-tools nudge, or ended the turn once the nudge was spent: iteration 48 of a 48-round Bedrock run returned one metrics chunk then EOF, and the turn ended with no answer. A drop with no text is now re-sent unchanged, sharing the two-attempt empty-completion budget, so a provider that drops every request falls through to the normal ladder. A drop after text has streamed is not re-sent, since that text is already on screen. The tests were committed on 2026-09-11 without this executor change, so they failed until now.
- **An interrupted release sweep re-attributes only the files it did not finish** (`scripts/release_hunks.py` (`reconcile` mode), `design/sweep-orchestrated.task-card.json` (P2a), `design/sweep-orchestrated.md`; tests `tests/test_release_hunks_reconcile.py` (new, 7), `tests/test_sweep_orchestrated_card.py` (+1)). A sweep that died during hunk attribution had to redo every contended file on rerun, and the commit plan read the whole patch directory, so patches from an earlier run (renamed entries, hunks already committed) could reach the commit loop. `release_hunks.py reconcile` counts a file as done only when its merge record names current entries, or its attribution maps every current hunk to a current entry and every patch passes `git apply --cached --check`. P2a fans out just the pending files and moves every other artifact under `.ziya/sweep/stale`. On the run that prompted this, 68 of 130 files were done and 62 pending: 13 of those had attributions from an earlier run whose patches no longer applied. The next run (cli-81921cb9b5eb) exposed four more resume faults, now fixed (`scripts/release_plan.py` (`batches` mode), `scripts/release_hunks.py` (whole-file and `new:` attributions); tests `tests/test_release_plan_batches.py` (new, 4), `tests/test_release_hunks_reconcile.py` (+3), `tests/test_sweep_orchestrated_card.py` (+4)). Triage batches were built by the model, which dropped 25 paths and put 8 in two batches, and verdict files were named by position, so one iteration overwrote another's; `release_plan.py batches` now batches every untriaged path exactly once and names each file by a hash of its paths, so a rerun triages only what is missing. The commit-plan gate refused but P4a reported done, so P4b ran an empty roster and P5 committed 13 entries outside the plan; P4a now has an output contract requiring a ready plan with at least one group, and P5 refuses to commit without one. A new untracked file mapped to one entry no longer fails `split` (it ships whole), and a hunk no entry describes is mapped to `new:` with a drafted entry instead of an invented slug that `reconcile` rejected on every rerun. A third run stopped at the commit plan over one entry with no code while ~100 entries were committable; an item that cannot be resolved (missing code, pending attribution, no verdict, a failing patch, or an exclusion of a tracked or imported file) is now deferred, the groups depending on it are dropped, the rest commits, and the fan-outs and commit loop are `required: false` so one bad iteration no longer halts the run. P6 refuses to finalize the release while anything is deferred. A fourth run (cli-462ad587602c) committed almost nothing for a different reason: 16 paths were staged in the index before it started, and every commit iteration refused a dirty index, so all 160 of them failed; the residue stage then landed only whole-file groups because it had no `git apply` grant. The staged hunks were also invisible to `git diff`, so two contended files were recorded as unsplittable merges. P0 now unstages a leftover index at the start of a run and re-queues those files for attribution, the commit loop clears a dirty index instead of failing and leaves the index empty on every exit, and both it and the residue stage carry `git apply` plus an anchored index-only grant, `re:^git restore --staged -- \S.*$` (the one `restore` form admitted: it never touches the working tree). Stages are also told to query the ledger with a script rather than `file_read` it whole, which was costing ~160K tokens per request. A fifth run (cli-6815dceb40c7) then stopped in P0 after P0 had done its work: it rated itself `partial` for skipping one re-check, and a required block with no output contract fails on `partial` alone - the warning the validator had raised on nine blocks since the card was written. Every stage now carries an output contract on the artifact it already emits (`resume`, `release`, `contended`, `unclaimed`, `residue`, `headings`, `bump`, `tag`, `push`), so a satisfied contract overrides the self-assessment, and the card validates with no warnings.
- **Saving the shell-config modal no longer demands a re-sign for edits that add no privilege** (`app/routes/mcp_routes.py` (`update_shell_config`, `_carry_file_signature`), `app/config/scope_canonical.py` (`rebind_signature`, `bundle_signature`, `delta_is_subset`; `verify_delta_signature` accepts bundles), `frontend/src/components/ShellConfigModal.tsx` (banner text); tests `tests/test_shell_config_save_floor_edit_keeps_signature.py` (new, 20; 14 fail on the old code)). With a signed escalation in the config, ticking a git operation already in the default floor voided `ZIYA_SCOPE_SIG`: the save compared raw field values, while the signature covers only the delta beyond the floor. It now compares deltas. Removing one signed command also forced a re-sign, because a signature verified only against its exact delta; such a save now stores a bundled signature (`v2..`) that the verifier accepts for any subset of what root signed. Nothing new is signed — a bundle repackages a signature that already verifies, and fails if its delta was not the one signed. Adding anything beyond what was signed still requires `sudo ziya-approve`, and restoring the full signed set restores the plain signature. `ziya-approve` output is unchanged.
- **Output that merely quotes `🚫 SECURITY BLOCK` no longer renders as a "Command Blocked" alert** (`frontend/src/utils/blockedCommand.ts` (new), `MarkdownRenderer.tsx` (both sites); tests in `utils/__tests__/terminalPane.test.ts`, `components/__tests__/terminalPane.test.tsx`). The renderer tested for the shell-policy sentinel anywhere in a tool result, so a `file_write` echoing a test fixture that contained it, or a grep over the renderer's own source, was replaced wholesale by the amber alert. The check is now anchored at the start of the message — the whole result, or the `message` of an `{'error': True, …}` dict — which is where the shell server puts a real refusal.
- **A diff that patches a fenced markdown file streams through intact** (`app/streaming_tool_executor.py` (`_update_code_block_tracker`, `_normalize_fence_spacing`); test `tests/test_fence_chunk_boundary.py` (new, 15; eight fail on the old code, including the end-to-end `process_text_delta` drive)). A ```` ```diff ```` whose context lines held ` ```bash` / ` ``` ` came out with one of those lines rewritten to ` ` + blank line + column-0 ```` ```bash ````, which the frontend's diff-aware fence scanner could not pair, and the turn ended with a spurious "unclosed fence" continuation ("The code block is already closed; nothing remains to emit"). Two causes. The content optimizer re-chunks on whitespace, so the tracker received `"\n "` and then ```` "```bash" ````: measured alone the second fragment is a column-0 fence, the diff-body guard missed it, and the tracker wandered out of the diff — ending on a phantom open bare fence at the diff's real closer. The tracker now remembers each chunk's unterminated last line with the state it was read from, rewinds, and re-reads the whole line when the next chunk completes it (single-call behaviour is unchanged; an external reset between chunks is honoured). With the tracker wrongly closed, the fence-spacing normaliser then treated the single leading space of ` ```bash` as prose glued to an opener and inserted the blank line; an indented fence line (or diff context line) is now left alone, while `layers:```mermaid` is still normalised. The same normaliser's single-newline rule used a lookbehind that holds trivially at the start of a chunk, so `"file.\n"` | `"\n```diff"` — already a blank line — gained a third newline; it now consults the preceding text (tests `TestNormalizerSingleNewlineAcrossChunks` (3) and an every-split-point `process_text_delta` drive, 2 of which fail on the old code).
- **Memory tools, extraction, feedback and maintenance no longer make Bedrock embedding calls on the event loop** (`app/mcp/tools/memory_tools.py`, `app/memory/{extractor,feedback,organizer,rem}.py`, `app/agents/run_memory_harvest.py`, `app/storage/memory.py`, `app/server.py`, `app/api/memory.py`, `app/services/embedding_service.py`; test `tests/test_memory_embed_not_event_loop_blocking.py` (new, 22); `tests/test_memory_zeros_fixes.py`, `tests/test_memory_rem_phase.py` updated). Follow-on to the lifecycle fix below: an audit of every coroutine that reaches an embedding call found the same defect in many more places. All seven memory MCP tools were `async def` with no awaits, so `memory_search`, `memory_save` and `memory_propose` embedded on the loop; extraction's `deduplicate` embedded every candidate there; three call sites ran the first-call provider smoke test there. Those now run on worker threads. Two storage changes cut the number of calls: `save`/`save_many` no longer re-embed when content is unchanged and a vector is cached (a `memory_search` returning 10 results made 11 Bedrock calls, now 1; per-response feedback re-embedded every loaded memory, now 0), and a new `MemoryStorage.patch_many` updates counter and status fields on the stored record under the file lock, so a bump made off the loop cannot write back a stale copy and resurrect a memory deleted in between.
- **Proposal-store reads and writes in extraction and run harvest moved off the event loop** (`app/memory/extractor.py`, `app/agents/run_memory_harvest.py`; guard extended in `tests/test_memory_embed_not_event_loop_blocking.py`). `ProposalsStore.get`, `record_signal` and `corroborate_by_id` read, decrypt and rewrite the proposals event log; both coroutines called them inline. They now run under `asyncio.to_thread`. The extractor's UPDATE branch also no longer embeds the new content twice (`store.save` already re-embeds on a content change).
- **The memory lifecycle sweep no longer stalls the server on embedding calls** (`app/memory/lifecycle.py`; test `tests/test_lifecycle_not_event_loop_blocking.py` (new, 3)). `run_lifecycle_pass` was `async def` with no awaits, so the whole sweep ran on the event loop, including one synchronous Bedrock `invoke_model` per promoted proposal (`_promote_proposal -> embed_and_cache`). The stall watchdog caught the loop parked in the SSL read. The sweep now runs under `asyncio.to_thread`. Because passes can now overlap (the post-extraction pass and the 30-minute system job), a process-wide lock serializes them; without it two passes could both save an active memory for the same proposal before either marked it promoted. One test runs two passes concurrently and fails with the lock removed.
- **`chat_search` / `chat_read` / `chat_list` no longer stall the server while they read chat files** (`app/mcp/tools/chat_history_tools.py`; test `tests/test_chat_history_tools_not_event_loop_blocking.py` (new, 4)). The three tools are `async def` but awaited nothing, so a search walked every chat file in scope (read, decrypt, scan) on the event loop; the stall watchdog caught the loop inside `search_chats -> _read_chat_data -> read_bytes`, with every other request parked behind it. The disk-bound call in each tool (`search_chats`, `_load_chat`, `ChatStorage.list_summaries`) now runs under `asyncio.to_thread`. The test drives each tool's real `execute()` with the callee swapped for a probe that records its thread, and fails against the previous file.
- **Inline flowchart edge labels on dotted, thick and hyphenated solid edges render instead of failing the lexer** (`frontend/src/plugins/d3/mermaidEnhancer.ts` (`pipe-syntax-fix`); test `frontend/src/plugins/d3/__tests__/mermaidDottedEdgeInlineLabel.test.ts` (new, 14; the positive cases fail on the old pass)). Mermaid ends an inline label `A -. text .-> B` at the first `.->`, and its lexer reads a literal `.` in the text as the start of that terminator: `C2 -. PG-table miss
+38.5k drops .-> D2` failed with "Lexical error on line 7 … +38.5k" while the dot-free sibling edge rendered. The pass rewrote only `-- text -->`, and even there excluded `-` from the label, so a hyphenated label stayed inline. It now rewrites `-. text .->`, `== text ==>` and hyphenated solid labels to pipe syntax, and every rewrite emits a quoted, `#quot;`-escaped label — this pass runs after both quoting passes, so a bare `|say "hi"|` it produced was never quoted later and is a parse error in mermaid 11.17.2 (verified against the real parser). Idempotent; unlabelled `-.->` / `==>` / `-.-` are untouched.
- **Startup no longer serves nothing while memory embeddings backfill** (`app/services/embedding_service.py` (`backfill_embeddings`); test `tests/test_backfill_embeddings_not_event_loop_blocking.py` (new, fails on the old code: the loop ticks once); `tests/test_memory_embedding_integration.py` (assertion follows the 2026-09-11 proposals-backfill call)). Attributed with `py-spy dump` on a live server: the MainThread — the asyncio event loop — was inside `ssl.read` under botocore under `embed_text`, called inline from `_initialize_memory_background` once per memory lacking a vector (thousands on a mature install). While parked there no request was served at all — not `/chats`, not any config GET — which was the startup "limbo" long attributed to the folder scan (not running in either dump): the sidebar lived off its IndexedDB shells, config dialogs would not open, and the eventual sync flashed in minutes later. Each batch now runs in a worker thread (`asyncio.to_thread`) and the loop only does the bookkeeping. The same function backs the manual `POST /api/memory/.../backfill`, so that path is covered too.
- **Three more request handlers no longer park the event loop under startup load** (`app/routes/folder_routes.py` (`get_default_included_folders`: the documentation walk now runs via `asyncio.to_thread`), `app/api/task_runs.py` (13 zero-await handlers `async def` → `def`; `cancel` and the two `resume-from` launches stay async), `app/api/bench.py` (9 zero-await handlers `async def` → `def`; `get_browse` / `put_place` stay async); tests `tests/test_default_included_folders_not_event_loop_blocking.py` (new, 2), `tests/test_task_runs_api_not_event_loop_blocking.py` (new, 7), `tests/test_bench_api_not_event_loop_blocking.py` (new, 6) — each fails on the unpatched file, naming the offending handlers). Found one dump at a time with the in-process stall watchdog (below) after the embedding fix above: `GET /api/default-included-folders` ran `os.walk` over the whole project tree inline on the loop on every load and project switch; `GET /task-runs` read, decrypted and parsed every run record (508 files / 483 MB on one install) on the loop, and the frontend polls it; `GET …/bench` read every skill file on the loop on every conversation open. The bench store is only 252 KB, which is the point: the stall is not volume but GIL contention — with two folder scans and two AST indexers running, a coroutine that never awaits cannot get out of their way, so any zero-await `async def` doing disk I/O is a multi-second stall under startup load regardless of how cheap it looks. Symptom was the log's "nothing, then everything at once": no `200 OK` for up to three minutes, then every queued response in one burst, during which config modals would not open and the file browser appeared to block everything.
- **Every remaining zero-await async route handler now runs off the event loop** (`app/routes/ast_routes.py` (`get_status` / `get_resolutions`, caught by the stall watchdog regenerating the full AST context on every `/api/ast/status` poll while indexing ran), `app/api/task_cards.py` (`get_signature_summary`, re-polled on every window focus, opening every approval record); then the sweep: 134 zero-await handlers across 26 files (`app/api/backlog.py`, `beads.py`, `consent.py`, `contexts.py`, `delegates.py`, `drag_helper.py`, `handoff.py`, `memory.py`, `projects.py`, `skills.py`, `task_bindings.py`, `tokens.py`, `app/routes/builtin_tools_routes.py`, `cache_routes.py`, `conversation_routes.py`, `debug_routes.py`, `export_routes.py`, `file_validation.py`, `folder_routes.py` (its remaining 8), `graph_routes.py`, `mcp_registry_routes.py`, `mcp_routes.py`, `misc_routes.py`, `page_routes.py`, `token_routes.py`, `transcription_routes.py`) converted from `async def` to plain `def`, with `asyncio.to_thread` kept only where a handler genuinely needed the running loop; 26 new per-module guard tests (`tests/test__not_event_loop_blocking.py`) plus `tests/test_no_zero_await_handlers.py` (new: scans every file under `app/api/` and `app/routes/`, non-vacuous floors of 20 files / 150 handlers)). Finishes the class the stall watchdog opened above: every one of these handlers was `async def` with no `await` in its body, so under the GIL contention of a folder scan or AST indexer any disk read on it — 252 KB or 483 MB, size never mattered — parked the event loop and served no request at all until it returned. The repo-wide guard now fails if a zero-await `async def` handler is added anywhere under `app/api/` or `app/routes/`, so the class cannot recur unnoticed.
- **Stall watchdog for attributing "the server serves nothing" episodes** (`app/utils/stall_watchdog.py` (new), `app/server.py` (started from the lifespan; also registers a `faulthandler` all-thread dump on `SIGUSR1`); tests `tests/test_stall_watchdog.py` (new, 4)). Set `ZIYA_STALL_DUMP=`: a daemon thread pings the loop once a second and reads the default executor census; when the loop does not answer within the threshold, or the `to_thread` pool is saturated with queued work for that long, it logs one report per episode — the trigger, the census, and every thread's Python stack via `sys._current_frames()`, with the event-loop thread tagged. Exists because the two external options both crashed the server on macOS: `py-spy dump` segfaulted the process on attach before it reached the stalled state, and `faulthandler`'s all-thread dump segfaulted on its second use while formatting another thread's frame. `sys._current_frames()` takes the GIL like any Python code, so it cannot crash the process and cannot miss the stalls that matter (inline I/O releases the GIL). Known gap: on uvicorn's loop the executor census reports `created: 0` even while the `to_thread` pool is busy, so only the loop-stall half is currently reliable.
- **The handoff drawer's document editor fills the viewport** (`frontend/src/components/HandoffDrawer.tsx`). The textarea had `autoSize={{ maxRows: 24 }}`, so on a tall screen a long handoff document scrolled inside a ~24-line box while the lower half of the drawer sat blank. The drawer body is now a flex column; the document section is the one that grows (`minHeight: 0` so it yields to the fixed-size sections below instead of overflowing), with a 10-row floor for short viewports.
- **Scheduled fires record `card_snapshot` and `permissions_snapshot`** (`app/agents/task_scheduler.py` (`_fire_one`); test `tests/test_task_scheduler.py::test_fire_one_records_card_and_permissions_snapshot`, fails on the old code at its first assertion). The interactive launch path captured both at launch; the scheduler captured neither, so a scheduled run had no record of which card definition it executed (the scheduler re-reads the card each tick, so the live card may since have changed) and resume-from-block — which walks `card_snapshot.root` — could not work on scheduled runs at all. The snapshot tree is the schedule's resolved body, the same tree `block_states` are keyed by, with `schedule_block_id` naming the wrapper that is absent from it. The permissions snapshot folds the Schedule block's own `scope` into the card layer, because `_go()` seeds that scope onto the executor's stack even though the block is not in the body tree.
- **Reload Config and the MCP server status panel are reachable from the Bench again** (`frontend/src/components/Bench/BenchPanel.tsx` (`bench-mcp-servers` button), `frontend/src/hooks/useBench.ts` (`MCP_STATUS_CHANGED_EVENT` listener); tests `Bench/__tests__/benchActions.test.tsx`, `hooks/__tests__/useBenchMcpReload.test.tsx` (new); `Docs/UserConfigurationFiles.md`). When the Bench absorbed the MCP Servers toolbar button (slice 6b) the status panel — config path, per-server startup logs, permissions and **Reload Config** — kept only one way in: the "logs, permissions, reauthorize ▸" link inside a server card's drawer. A server just added to `mcp_config.json` has no card yet, so after editing the config there was no way to say "reload the servers" or to see why one failed to start. The board now has its own *MCP servers · status, logs, reload config* button beside *Find more*, and `useBench` refetches on the panel's `mcpStatusChanged` event, so a reloaded server gets a card without closing and reopening the Bench.
- **A patch on a file that an earlier diff in the same response creates is refused with the right correction** (`app/utils/diff_validation_hook.py` (`created_in_response`, `reader_reason`), test `tests/test_diff_validation_pending_new_file.py` (new, 4)). The refusal was already correct — every fence must apply on its own against the live file — but the feedback said "mark as new file creation", which would recreate the file from a fragment, so the model re-emitted the same patch and the turn was wasted. The hook now remembers the files a response's `--- /dev/null` fences create and, for a later patch on one of them, tells the model to re-emit one complete new-file diff; the chat notice says the target is created by an earlier, unapplied diff. An ordinary missing target keeps the old wording.
- **A second window on the same project no longer ends, or re-ends, a turn it doesn't own; a new send no longer aborts itself** (`frontend/src/context/ChatContext.tsx` (`handleStreamingEnded`, `removeStreamingConversation` gains `{ broadcast }`, eager `streamingConversationsRef` sync in add/remove and the chunk/state handlers), `frontend/src/apis/chatApi.ts` (`sendPayload` abort handshake and `finally`); tests `frontend/src/context/__tests__/streamingEndedEcho.test.ts` (new, 6), `frontend/src/apis/__tests__/sendPayloadAbortOrdering.test.ts` (new, 3)). When tab A finished a turn and broadcast `streaming-ended`, a mirroring tab B released its copy by calling `removeStreamingConversation`, which re-broadcast the same event, so A received an echo of its own end-of-turn. If A had already begun its next turn (feedback recovery resubmits in the same tick) the echo deleted that turn's streaming mark: the reply streamed with no spinner or Stop button, the question above it got the orange needs-response bar although it was being answered, and at completion the idempotency guard returned before clearing `streamedContentMap`. The next send then saw "Stream already active" and dispatched `abortStream` — after registering its own listener and after removing the old one — so it aborted its own `AbortController`, `POST /api/chat` failed at once, and the message was left unanswered. The guard also read a ref refreshed only in a `useEffect`, so while B was busy every queued echo passed it and re-broadcast, and the tabs ping-ponged dozens of times per turn. `handleStreamingEnded` now acts only on a stream the tab is mirroring and releases it without re-broadcasting; the ref is updated when the set changes, not at the next commit; `removeStreamingConversation` clears the content map before the set guard; `sendPayload` aborts the previous stream before registering its listener, finalizes the aborted stream so a queued flush can't re-insert its content, and only clears the shared `window.abortListener_` slot when it still owns it.
- **Shell heredocs: a compound command may end in a heredoc, and what the shell runs from an unquoted body is validated** (`app/mcp_servers/write_policy.py` (`_heredoc_spans`, `_heredoc_body_commands`, `_strip_heredoc_bodies`, `ShellWriteChecker._check`), `app/mcp_servers/shell_server.py` (`_validate_compound_body`, `is_command_allowed`); test `tests/test_shell_heredoc_bodies.py` (new, 32)). Three defects at one seam. `for …; done; python3 - <<'EOF' … EOF` was refused with `'import' is not allowed`: the compound route validated the raw command, so every Python line was checked as a shell command, and the model had to spend extra turns writing the script to a file. It now strips heredoc bodies as the plain heredoc route already did. In the other direction, both gates stripped bodies wholesale, but with an unquoted delimiter (`<`. The field takes a folder or a file path, and `~` or a relative path resolves against home. The server writes the file and returns its absolute path, which appears in a warning toast at the top of the screen for 20 seconds. An existing file is not overwritten unless you confirm it (the server returns 409 `file_exists` first), a missing folder returns 422, and the saved path is logged as `saved_to` on the `memory_exported` audit event. The browser download is still available in the dialog, and its toast names the file and the browser's download folder.
- **A model pinned to one conversation no longer inherits a session region it can't be served from** (`app/utils/model_region.py` (new, `region_for_model`), `app/streaming_tool_executor.py` (`StreamingToolExecutor.__init__`); test `tests/test_pinned_model_region.py` (new, 5)). Requests were sent to the server's single session region, which is resolved for the process-wide `--model`. On 2026-10-07 the session model opus5.5 was running in eu-west-1, and a conversation pinned to fable5.1 was sent there too. fable5.1 has only `us`/`global` profiles and is available in us-east-1/us-west-2, so Bedrock rejected it with `data retention mode 'default' is not available`, because eu-west-1's retention switch had never been set. The executor now uses the model's `preferred_region` when the session region is outside the model's `available_regions` and the model has no profile for that geography. It logs `🌍 REGION` when it does. Models with an `eu` profile keep EU regions.
- **A region-router failover no longer moves the whole server to the failover region** (`app/utils/custom_bedrock.py` (`CustomBedrockClient.__init__`); test `tests/test_custom_bedrock_region_isolation.py` (new, 2)). `CustomBedrockClient` wrote its client's region to `os.environ["AWS_REGION"]`, and `BedrockRegionRouter` builds one for every failover region. `get_current_region()` reads that variable, so after a failover, any later code that read it got the failover region. On 2026-10-07 an opus5.5 `ServiceUnavailable` in us-west-2 failed over to eu-west-1 and left `AWS_REGION=eu-west-1` in the server. Later, some (not all) fable5.1 requests were sent to eu-west-1 and rejected with `data retention mode 'default' is not available`, because the retention switch there had never been set. CloudTrail shows fable calls in us-west-2 between those failures, so the region is resolved per request. Whether this write is what fed those requests is not yet confirmed.
- **Data-retention rejections name the region and account** (`app/providers/bedrock.py`, `app/utils/retention_diagnostics.py`; tests `tests/test_bedrock_retention_heal.py`, `tests/test_retention_diagnostics.py`). The provider's error names neither the region nor the account. CloudTrail logs the rejected call only in the region it was sent to. A rejection now logs `🔐 RETENTION_GATE model=… region=… profile=…` and a `🔐 RETENTION_DIAG` line with the account, the regions the inference profile can route to, and the switch in each of them. The user-facing error names the region the call was sent to and lists the regions below the required mode, instead of asking the user to restart.
- **`shadow_wait(cmd_seq=…)` no longer sleeps to its timeout on shells without OSC 133** (`app/shadow/segmenter.py` (`_finish_command`), `app/shadow/journal.py` (`JournalWriter.exit`, `searchable_text`), `app/shadow/client.py` (`format_records`), `app/mcp/tools/shadow_tools.py` (`ShadowWaitInput.until`); test `tests/test_shadow_heuristic_exit.py` (new, 7); `Docs/design/shadow-sessions.md` §4.1, `design/shadow-wait.md`). In prompt-heuristic segmentation (any ssh'd shell, the common case) the segmenter detected each command's end but journaled nothing, and only an OSC 133 `D` produced an `exit` record. A wait on `until=['exit']`, which is the default with `cmd_seq` and the call `shadow_send`'s `next` hint asks for, could therefore never fire. Every wait ran the full 240 s default, even on commands that returned at once. When the prompt returns the segmenter now writes `exit` with `code: null`, so the wait wakes about 0.5 s after completion and reports `exit_code: null`. The same happens when osc133 skips `D` before the next `A`. Transcripts show `→ done (exit code unknown)`.
- **Raw-segmentation shadow sessions no longer fold every command into the first, or send `shadow_wait` to its timeout** (`app/shadow/segmenter.py` (`_heuristic_enter`, `_prompt_returned`), `app/mcp/tools/shadow_tools.py` (`ShadowSendTool` hint, `ShadowWaitTool` `no_exit_signal`); test `tests/test_shadow_raw_mode.py` (new, 11); `Docs/design/shadow-sessions.md` §4.1, `design/shadow-wait.md`). With no learnable prompt (one ending in a letter, or with no trailing space), the first Enter opened a command that never closed. Every later command was journaled as output of the first, `send_line` returned `cmd_seq: null`, and `shadow_send` then suggested `shadow_wait(cmd_seq=None, until=['exit'])`, which waits for an exit record a raw session never writes. Each raw Enter now opens its own group and still returns no `cmd_seq`. The send hint uses `until=['quiet']` unless it has a `cmd_seq` or the session is osc133, and `shadow_wait` refuses an exit-only wait on a raw session at once. Separately, a prompt that came back with the next command already echoed after it (typed or pasted inside the 0.5 s idle window) was taken for input to the still-running previous command, which swallowed the new command and never closed the old one. Both commands are now recorded and the first is closed.
- **A long reply followed by a tool call is no longer written twice** (`app/streaming_tool_executor.py` (`_should_note_already_shown`, `_already_shown_note`, `ALREADY_SHOWN_MIN_CHARS`), `app/utils/handoff_prelude.py` (`render_draft_prelude`); test `tests/test_already_shown_note.py` (new, 9)). Claude treats text before a tool call as a working note and the message after the last tool result as the real answer. When a finished reply was followed by a bookkeeping call (`handoff_write`, `memory_propose`, `bead_*`, a `file_write` of what was just explained), the next iteration rewrote the whole answer and the user saw it twice, reworded. The living handoff-draft prelude made this common: it asked for `handoff_write` "before finishing", which put the call after the answer. Now an iteration that streams at least 1,500 characters of prose and then calls tools gets a note in its tool_result turn saying that text is already displayed and must not be repeated (continuing unfinished work is still allowed), and the prelude asks for the draft update together with the other tool calls, before the reply. The post-stream diff re-do already carried the same "already shown" constraint and is unchanged.
- **`[external]` folders are read only when you open them: restarts no longer walk every saved external tree, and Refresh shows files added since** (`app/utils/external_tree.py` (new), `app/services/folder_service.py` (`add_external_path_to_cache(mode=)`, `load_external_dir`, `refresh_external_listings`, `is_under_external_path`, `restore_external_paths_for_project`), `app/routes/folder_routes.py` (`GET /api/external-dir`, `/api/folders?refresh`, `/api/add-explicit-paths`), `frontend/src/utils/folderUtil.ts`, `frontend/src/context/FolderContext.tsx` (`loadExternalDir`), `frontend/src/components/MUIFileExplorer.tsx`, `frontend/src/utils/types.ts`; tests `tests/test_external_lazy_tree.py` (new, 9), `frontend/src/utils/__tests__/externalLazyTree.test.ts` (new, 6), `tests/test_external_path_cache.py` (updated)). Every server start walked each saved external path in full (up to 10,000 entries and 15 s each, with a token estimate per file that opens every PDF) before the first file-tree response, which made restarts of projects with external paths take minutes. And because that snapshot was never re-read, files copied into an added folder (here, PDFs beside `Aldrin 3XL` in `Vendor Specs`) stayed hidden until a restart. Now startup reads no external directory: saved paths return as folders to expand. Expanding a folder lists that one level, Refresh re-lists only the folders you have opened, and adding a folder lists its top level (the AGENTS.md/README.md lookup no longer walks ten levels down). A bounded whole-folder read happens only when you check a folder that is not fully listed, or add one straight into context; a folder that read could not finish stays expandable instead of looking empty, with a warning that some subfolders were not selected. After a restart, folders on the path to a checked external file are listed so its checkboxes stay correct. Token totals for folders not yet listed show as 0.
- **A shell write after `cd ` and a `;` is no longer refused** (`app/mcp_servers/write_policy.py` (`_simulate_cwds`, `_is_plain_assignment`), `tests/test_shell_cwd_aware_write_policy.py` (+5, 3 updated)). `cd /tmp/x && S=…; cmd 2>err.txt` was blocked because, across `;`, a failed `cd` leaves the project root as the cwd, so the validator judged `err.txt` under both directories. The executor's `cd` succeeds exactly when the target is a directory, and validation runs just before execution, so a literal `cd` into an existing directory now counts as certain. It must also be reached only through earlier certain `cd`s and plain assignments with no substitutions, `||` or pipes. Anything earlier that could remove the directory (`rm -rf D; cd D; …`, `X=$(rmdir D); …`) or skip the `cd` still gets the union check.
- **Long answers full of charts are no longer cut off mid-chart, and a real repetition loop now stops the model instead of hiding its output** (`app/utils/repetition_guard.py` (new; `SentenceRepetitionGuard`, `StoppableStream`, `REPETITION_NOTICE`), `app/streaming_tool_executor.py` (stream loop, `_decide_no_tool_outcome(repetition_stopped=)`); tests `tests/test_repetition_guard_unit.py` (new, 18), `tests/test_stream_repetition_guard.py` (new; one case per rendered fence type, read from `frontend/src/constants/visualizationTypes.ts`), `tests/test_decide_no_tool_outcome.py` (+10)). The guard that stops a model repeating itself was cutting real content. It decided whether text was inside a fence from the code-block tracker, but the tracker only sees text after viz buffering and the content optimizer release it. Those can hold a whole fence and release it in one piece, so the tracker reported "outside a fence" while a vega-lite or tikz body streamed. In a gallery of charts sharing one expression, the third copy of a JS ternary (`? ` reads as a sentence end) counted as a repeated sentence and the reply stopped mid-JSON. Four further problems are fixed with it:
- The guard now tracks fences itself on the raw stream (backtick and tilde fences, CommonMark length rules), so no fence type depends on which renderer lists it.
- A sentence counts as a loop only when the text between its copies repeats exactly, or when it fills 5 of the last 12 sentences. Previously any 20+ character sentence seen three times was a loop, which cut refrains and per-section checklists.
- On a loop, the provider stream is now closed, so the model stops generating and being billed for text nobody sees. Previously everything after the cut was still generated and silently dropped.
- Text after the cut used to reach the model's own record of the turn but not the user. The model then believed its answer was complete, and the automatic "you were cut off" prompt made it claim the user's copy was the problem. The turn now ends with a visible "Output stopped" note, so neither the user nor the model's next turn mistakes the cut for a complete answer.
- **The green "ready" checkmark no longer reappears on a conversation you just left** (`frontend/src/utils/chatTreeHash.ts` (`computeStructuralHash` hashes `hasUnreadResponse`); tests in `frontend/src/utils/__tests__/chatTreeHash.test.ts`). Opening a conversation clears `hasUnreadResponse` without bumping `_version`, and the sidebar's tree cache only rebuilds when its structural hash changes. The flag was not in the hash, so the cached row kept `true`. The row hides the mark only while it is the current conversation, so switching between two marked conversations kept bringing the mark back on the other one until an unrelated sync rebuilt the tree, about two minutes later.
- **A conversation you have read stays read after a reload** (`frontend/src/utils/unreadState.ts` (new; `withUnreadCleared`, `clearUnreadInShellSnapshot`), `frontend/src/utils/db.ts` (`markConversationRead`), `frontend/src/context/ChatContext.tsx` (`loadConversation`); test `frontend/src/utils/__tests__/unreadState.test.ts` (new)). The cleared flag lived only in React state. IndexedDB writes cover just the conversation being saved, so the flag reached IndexedDB only when that same conversation was saved again. A conversation you opened and read without replying kept `true` in IndexedDB and in the localStorage shell snapshot, and its checkmark came back on reload. Opening a conversation that is marked unread now patches that one record in IndexedDB, the in-memory shell cache and the localStorage snapshot. `_version` and `lastAccessedAt` are left alone, so the sidebar order doesn't change. The server copy is still cleared only by the next real save of that conversation, so another browser can still show the mark until then.
- **`show_document` renders the document's own diagram and code fences** (`frontend/src/utils/renderToolPart.ts` (`unescapeNestedFenceEntities`, used by `parseDocumentCaption`); test `frontend/src/utils/__tests__/showDocumentNestedFences.test.ts` (new, 4)). The document travels inside the chat's four-backtick tool fence, and the outer render escapes the leading backtick run of every line inside a backtick fence to ``` entities so it cannot close that fence early. Those lines are the document's own ```` ```mermaid ````, ```` ```vega-lite ```` and code fences, so the shown document displayed every diagram and code block as literal text. The document body now has those leading runs decoded before it is rendered as markdown.
- **Approving an out-of-policy write for the conversation or session no longer asks again for the same file** (`app/utils/consent_gate.py` (`GrantCache.remember_paths`/`covers_paths`), `app/utils/write_grants.py` (`grant_key`), `frontend/src/components/ConsentPanel.tsx`; tests in `tests/test_scope_consent.py` (+12), `tests/test_scope_consent_seam.py`; `design/scope-consent.md` C2, `Docs/Capabilities.md`). The panel offered conversation/session/always scopes, but they were recorded only for the (tool, op), and `file_write` has consent mode `off`, so that record was never read and every write to the same file asked again. An approval with a standing scope now also remembers the exact files shown, per tool, keyed on the resolved path; a later call by that tool writing only remembered files gets a per-call grant without a panel. A new file, another tool, or (for conversation scope) another conversation still asks; `once` and rejections remember nothing; the floor (`.git`, outside the project, install extensions, server-only directories) is re-checked at every lookup; memory is in-process only. Trade-off: repeat writes to a remembered file no longer show a diff first.
- **The X on a skill chip unloads the skill** (`frontend/src/components/ActiveContextBar.tsx` (`unloadPlacement`); test `frontend/src/components/__tests__/ActiveContextBar.unload.test.tsx` (new, 7)). The chips render from the bench's always-set, but the X only removed the skill from the legacy active-skill list, which the bench migration had already emptied, so clicking it did nothing. It now writes a bench placement at the layer that pinned the skill: it clears that pin, or writes the skill's default there when a lower layer also pins it to always.
- **Mermaid class diagrams written with doubled braces render** (`frontend/src/plugins/d3/mermaidClassDoubleBraces.ts` (new), `frontend/src/plugins/d3/mermaidEnhancer.ts` (preprocessor `class-diagram-double-brace-collapse`, priority 750); test `frontend/src/plugins/d3/__tests__/mermaidClassDoubleBraces.test.ts` (new, 11)). Models sometimes carry an f-string or template habit into a diagram and write `class Foo {{ ... }}`. Mermaid accepts only one `{` and `}` there, so the whole diagram failed with "Expecting 'STRUCT_STOP', 'MEMBER', got 'OPEN_IN_STRUCT'". A brace run at the end of a `class` or `namespace` header, and a line holding only closing braces inside such a block, are now reduced to one brace. Member lines, quoted labels, `%%` comments and other diagram types (where a flowchart `{{hexagon}}` node is valid) are left as they were.
- **Mermaid ER diagrams written with doubled braces render** (`frontend/src/plugins/d3/mermaidClassDoubleBraces.ts` (`collapseErDiagramDoubleBraces`), `frontend/src/plugins/d3/mermaidEnhancer.ts` (preprocessor `er-diagram-double-brace-collapse`, priority 750); test `frontend/src/plugins/d3/__tests__/mermaidErDoubleBraces.test.ts` (new, 10)). The same habit in an `erDiagram` (`ENTITY {{ ... }}`, `||--o{{`) failed with "Expecting 'BLOCK_STOP', 'ATTRIBUTE_WORD', got '{'". Valid ER syntax never has two adjacent braces, so any run of braces outside quoted strings and `%%` lines is now reduced to one, covering entity blocks and crow's-foot markers alike.
- **JSON diagrams written with doubled braces render** (`frontend/src/utils/d3SpecParser.ts` (`collapseUniformDoubleBraces`, `withBraceCollapse`); adopted by `lenientParse`/`parseD3Spec`, `plugins/d3/packetPlugin.ts`, `forceDirectedPlugin.ts` (also chord), `networkDiagram.ts`, `vegaRecovery.ts` (vega, vega-lite), `plotlyPreprocessor.ts`, `jointPlugin.ts`, `utils/d3Plugins/flamegraphPlugin.ts`, `utils/d3Plugins/wavedromPlugin.ts`, `utils/d3Plugins/railroadPlugin.ts` and `utils/d3Plugins/timelinePlugin.ts` (`lenientJsonParse`, which is also the railroad streaming completeness check); tests `frontend/src/utils/__tests__/braceCollapse.test.ts` (new), `frontend/src/plugins/d3/__tests__/packetDoubleBraces.test.ts` (new)). A JSON spec written with every `{` as `{{` and every `}` as `}}` failed with "Invalid JSON in definition", since neither JSON nor JSON5 accepts `{{`. When a renderer's parser fails and the text both starts and ends with doubled braces, the braces are collapsed and the same parser runs once more, so its own repairs (semicolons, Python literals, missing commas) still apply. Valid input never reaches the retry, and text-format diagrams (mermaid, LaTeX), where `{{` is legal, are not touched. The per-plugin copies of the markdown-fence stripper and smart-quote normaliser in the packet, network, force-directed, plotly and joint plugins now delegate to the shared ones in `d3SpecParser.ts`.
- **Chord diagrams with ragged matrices, packet specs given as flat fields, and nested JointJS containers render correctly again** (`frontend/src/plugins/d3/chordPlugin.ts` (`sanitizeChordMatrix` (new, exported) replaces `sanitizeMatrix`), `frontend/src/utils/d3Plugins/packetPlugin.ts` (`normalizePacketSpec`), `frontend/src/plugins/d3/jointPlugin.ts` (`computeJointElementStyle`); tests `chordSpecRecovery.test.ts` (rewritten against source), `diagramErrorMarkerContract.test.ts`, `jointG48.test.ts` (new ramp-order case)). Chord: a matrix with a short row drew `NaN` geometry and no arcs. The fix had been hot-patched into the served bundle and its test read minified helpers out of that bundle, but only `resolveChordSpec` reached the source, so a rebuild would have reverted it and the minified names already had; `sanitizeChordMatrix` now pads every row to a square grid in source, and the test imports it and checks that render calls it. Packet: a `{type: 'packet', fields: [...]}` spec without a title got the "requires a sections array" error card, because a default title was only made up when `sections` was present. JointJS: D-417's lift of author fills that match the page also caught the dark container ramp, raising the outermost container above its children (`#2e3440` → `#585d66`); it now applies only to author-supplied fills. Test-side only: `objectDefinitionUnwrap` re-installs its spy implementations after CRA's `resetMocks`; `musicTitleBlockFitD165` and `vegaLegendPlacement` turn off the 8 px-per-character canvas stub they were not written against; `networkG28` selects circle fills by element instead of by position (the D-448 self-loop path shifted it); `drawioG60` pinned `getOptimalTextColor`'s old white-on-cornflowerblue mis-pick, which the shared helper has since fixed; `drawioFitGuard` checks for an unusable view rather than NaN (maxGraph 0.23 returns a negative scale for a zero-size container) and searches the whole `safeFitCenter` body; `jointG48` expects D-417's light-theme nudge of a page-matching pale fill.
- **Vega-Lite concat panels no longer lose their bar colours to a sibling's pinned domain** (`frontend/src/plugins/d3/vegaRecovery.ts` (`resolveConcatScaleConflicts` (new)), `frontend/src/plugins/d3/vegaLitePlugin.ts` (called before `sanitizeResolveScale`); tests `frontend/src/plugins/d3/__tests__/vegaConcatScaleResolve.test.ts` (wiring check added), `vegaG22.test.ts`, `vegaLegendPlacement.test.ts`). A `vconcat`/`hconcat` shares its colour (and other non-positional) scales across panels, so one panel's explicit `scale.domain` became every panel's domain and a sibling's categories outside it were drawn with no fill. The new pass sets `resolve.scale. = "independent"` only when the spec proves the conflict: a categorical domain in one panel that lacks an inline value of another panel's field, or two panels pinning different ranges. Quantitative domains, URL data, and an author's own resolve are left alone. Its test was committed in `297855e3` (2026-09-11) without the source change; the function is rebuilt from that test, which now also checks the plugin calls it. Three other vega suites were failing for test-side reasons only: `vegaG22` read `range.scheme` after `sanitizeVegaSchemes` had (correctly) removed the emptied `range`, and its vega-embed mock was a `jest.fn` that CRA's `resetMocks` wiped before every test after the first (the plugin imports vega-embed lazily); `vegaLegendPlacement` ran under the `setupTests.ts` canvas stub, which measures every font at 8px per character, and now uses the deterministic text-width fallback it was written against.
- **Mermaid init directives with curly quotes keep their theme, and the fallback render measures labels at zoom 1** (`frontend/src/plugins/d3/mermaidEnhancer.ts` (`normalizeInitDirectiveJson`, enhanced `render` fallback path, `balanceSubgraphEnds` doc comment); tests `frontend/src/plugins/d3/__tests__/mermaidInitCurlyQuoteG20.test.ts`, `mermaidUnzoomedMeasureHost.test.ts`, `mermaidG59Recovery.test.ts`). A `%%{init: {‘theme’: ‘forest’}}%%` directive written with smart quotes was left unparseable: the init repair (priority 820) did not handle smart quotes, and the unicode pass that straightens them runs later (490), so the requested theme and colours were dropped. The repair now straightens smart quotes before its other rewrites. Separately, when `mermaidAPI.render` failed and the enhancer fell back to the original `render`, the fallback rendered with no container, so mermaid measured labels under the narrow-viewport body zoom and clipped multi-line labels; it now renders inside the same zoom-neutral host as the primary path. Like the empty-SVG retry below, the smart-quote fix had been written into its test but never applied to the source. `mermaidG59Recovery` still asserted that a missing subgraph `end` is appended at end of file, which D-426 replaced with insertion where the subgraph's indentation ends; it now asserts the D-426 placement, and the function's doc comment no longer describes the old behaviour.
- **An empty Mermaid render is retried once and no longer reported as a syntax error** (`frontend/src/plugins/d3/mermaidPlugin.ts` (`MERMAID_EMPTY_SVG`, `MERMAID_MALFORMED_SVG`, `isRetryableMermaidFailure`, `describeMermaidRenderFailure`, `renderMermaidWithRetry`; `renderSingleDiagram` renders through them); test `frontend/src/plugins/d3/__tests__/mermaidEmptySvgRetry.test.ts`). Mermaid sometimes returns an empty or truncated SVG for a valid definition, and the same definition renders on a later attempt. The plugin reported that as "This usually indicates syntax errors in the diagram definition." An empty or malformed result is now retried once with a fresh element id; a real parse or syntax error is not retried and is reported unchanged; a second empty result is described as a likely transient renderer failure. The test landed in commit `1d4d26b0` under this fix's title, but the `mermaidPlugin.ts` change never did, so its 10 tests had failed ever since. Its wiring check searched a fixed 8000-character slice of `renderSingleDiagram`, which the function had outgrown; it now searches the whole function body.
- **Layered Vega-Lite charts that fold columns draw their data again** (`frontend/src/plugins/d3/vegaLitePlugin.ts` (`layersNeedingPreTransformData` (new), FOLD-DATA-FIX block); test `frontend/src/plugins/d3/__tests__/vegaLiteFoldLayerData.test.ts` (new, 8)). FOLD-DATA-FIX gave a layer its own copy of the raw rows whenever it referenced any unfolded field, such as the x-axis date. A layer with its own data does not get the parent's transform, so the fold's `key`/`value` and any `calculate` output vanished from that layer and it drew nothing; the axes, rule and labels still rendered. Fold keeps every unfolded field, so the raw rows are now given only to a layer that plots a folded field directly and uses no transform output, and that has no data or transform of its own.
- **Vega-Lite "Open" popup no longer shows an empty window** (`frontend/src/plugins/d3/vegaLitePlugin.ts`; test `frontend/src/plugins/d3/__tests__/vegaLitePopupScriptParses.test.ts` (new, 8)). The popup script declared `let currentScale` and then interpolated `getZoomScript()`, which declares it again. A duplicate `let` is a parse-time SyntaxError, so none of the script ran: the chart was never rendered and Zoom/Download did nothing. This affected every Vega-Lite chart. The interpolation is removed; the popup's own zoom functions, which look up the SVG at click time, remain. The same empty window also appeared whenever `vega-embed` could not be loaded from cdn.jsdelivr.net: the popup cleared the pane before the import, and nothing caught the rejected import. The popup now opens with the inline chart's SVG and replaces it only after a successful live render, drawn into an attached hidden overlay so `width: "container"` still measures the pane. On failure the current chart stays and the error is logged; this includes a theme switch, which keeps the old-theme chart when offline. The embedded SVG escapes `<`. Test file now 8 tests, run in jsdom with the CDN import stubbed.
- **A reply that only reached the browser no longer flickers in and out every sync and never reaches the server** (`app/api/chats.py` (`bulk_sync_chats`, older-version branch), `frontend/src/utils/syncMerge.ts` (`applyHydratedChat`, `hydrationWouldDropMessages` (new)), `frontend/src/context/ChatContext.tsx` (bulk hydration); tests `tests/test_bulk_sync_stale_version_append.py` (new, 4), `frontend/src/utils/__tests__/hydrationShrinkGuard.test.ts` (new, 11)). Backend writers (`handoff_write`, bead tools, context auto-vivify) re-stamp a chat's `_version` on the messages already on disk, which can be missing the assistant reply that just streamed to the browser. `bulk_sync` then skipped the browser's push of that reply because its version was older. Each 30 s pull replaced the on-screen conversation with the shorter server copy, POST_SYNC restored it from IndexedDB, and the cycle repeated indefinitely. Server: an older push now contributes the messages it adds (through `merge_messages`, so tombstones are honoured and existing server messages and record fields stay as on disk) and moves `_version` past the server's; a push that adds nothing is still skipped. Browser: bulk hydration keeps the in-memory message list when adopting the server copy would drop messages that the server's tombstones don't account for, while still taking the server's metadata and `_version`, so the next push goes out instead of being suppressed as "server shrank".
- **A combined diff no longer merges two files that share a basename** (`app/utils/diff_utils/pipeline/pipeline_manager.py` (`select_diffs_for_target`), `tests/test_pipeline_target_selection.py` (new, 7)). `apply_diff_pipeline` picks its target's block(s) out of a combined diff, and accepted a basename match alongside an exact one, so a diff touching both `app/config/write_policy.py` and `app/mcp_servers/write_policy.py` merged the two and applied the sibling's hunks to the target. Matching is now tiered (exact path, then path suffix, then basename only when nothing better matches); two blocks for the same file still merge. The end-to-end test asserts on the files on disk and fails against the old logic.
- **File explorer folders showed `0/N` while their checked files showed real counts** (`frontend/src/context/FolderContext.tsx`, `app/routes/token_routes.py`, `app/utils/directory_util.py`, `frontend/src/components/MUIFileExplorer.tsx`; tests `tests/test_accurate_token_count_project_scope.py` (new, 4), `frontend/src/context/__tests__/accurateTokenCountRequest.test.ts` (new)). Both browser calls to `/api/accurate-token-count` omitted `X-Project-Root`, so the server resolved paths against its launch directory and answered "File not found" for every file in any other project; the browser stored those errors as counts of 0, which the folder rollup trusted while the file row fell back to the estimate. The same missing header made the auto-add size check treat every file as unmeasurable and hold it back. Error results are no longer stored as counts. The server's background count cache was one flat table overwritten by whichever project finished last, and a request that partly hit it returned only the cached files; it is now keyed per project and misses are computed. The background pass uses `get_accurate_token_count`, so its numbers match on-demand counts. The file row's ✓ now appears only for a positive count.
- **Checking or unchecking a file reopened every folder holding a selected file** (`frontend/src/components/MUIFileExplorer.tsx`; test `frontend/src/components/__tests__/fileExplorerAutoExpand.test.ts` (new)). The auto-expand effect re-ran over the whole selection on any change. It now expands ancestors of newly added keys only, and not at all for a click in the tree; restored selections and model/context-sync additions still reveal their folders. Checking a folder no longer opens its subfolders.
- **macOS `sed -i '' …` was refused even on writable paths** (`app/mcp_servers/write_policy.py` (`_inplace_targets`); test `tests/test_inplace_bsd_sed_suffix.py` (new, 3)). The empty BSD backup-suffix argument was read as the script and the script as the target file.
- **New conversations reverted to "New Conversation" after the first send derived their title** (`frontend/src/utils/conversationTitle.ts` (`mergeTitle`), `frontend/src/utils/syncMerge.ts` (server-newer branch), `frontend/src/context/ChatContext.tsx` (bulk hydration; shell-recovery append now derives the title), `app/utils/chat_title.py` (new: `PLACEHOLDER_TITLES`, `merge_title`), `app/api/chats.py` (bulk-sync update branch); tests `frontend/src/utils/__tests__/titlePlaceholderMerge.test.ts` (new, 7), `tests/test_bulk_sync_title_guard.py` (new, 7)). Backend writers — context-tool auto-vivify, bead, handoff and auto-context writes — create or re-stamp a chat record with the placeholder and a fresh `_version`. Three merges then let that placeholder replace the derived title: the server-newer summary merge (`sc.title || local.title`), bulk hydration (`...full`), and bulk-sync on the server, which took a newer client copy's title wholesale. A first message that landed on a shell record was applied by the recovery path, which never derived a title at all. Derivation only fires while no human message exists, so the placeholder was permanent. Every merge now keeps a real title over an incoming placeholder while still adopting a real incoming title (a rename), and the recovery path derives the title. The frontend and backend placeholder sets are asserted equal. Conversations already stuck keep their placeholder until renamed. Accepted trade-off: renaming a conversation to exactly "New Conversation" in another window no longer propagates.
- **A model-staged task tile landed at the start of its turn, above the reply that staged it** (`frontend/src/utils/taskBindingPlacement.ts` (new; the untracked test `taskBindingPlacement.test.ts` that pinned the rule finally has its module), `frontend/src/components/Conversation.tsx`, `frontend/src/components/StreamedContent.tsx` (in-flight slot), `app/utils/binding_placement.py` (new), `app/server.py` (`_inject_task_results`); tests `tests/test_binding_placement.py` (new, 10)). A tile created by `task_card_stage` / `task_card_launch` has no anchor message and was placed after the last message timestamped at or before `created_at` — the human prompt, since the reply is only timestamped when the stream finishes. It now lands at the end of the turn that built it, walking past every non-human message of that turn; while the reply is still streaming it renders after the live stream and moves into the thread when the reply persists. The model-facing synthetic status line is spliced by the same rule, so the model's view of where a card sits matches the user's.
- **Server-only directories in the write policy** (`app/config/write_policy.py` (`SERVER_ONLY_PATHS`, `is_server_only_path`), `app/mcp/tools/fileio.py`, `app/mcp_servers/write_policy.py`, `app/utils/write_grants.py`; `tests/test_server_only_paths.py` (new, 13); `Docs/Capabilities.md`). The write policy was allow-only and `.ziya/` is a safe path, so `.ziya/ledger/` — where the evidence ledger will record what tools did — was writable by any tool. `.ziya/ledger/`, `.ziya/jobs/` and `~/.ziya/datasources/` (Ziya home, `ZIYA_HOME` honoured) are now a hard floor alongside the install extension directory: refused before any allow rule, `direct_write_mode`, YOLO mode or task-card grant, at every sink — the manager, `file_write`'s pre-check (where YOLO and task scope previously returned before the manager was consulted), the shell write checker (before its task-scope fallback) and the out-of-policy approval floor. Matching resolves symlinks and `..` and is case-folded for case-insensitive filesystems. The list is a constant rather than a policy key so no override can remove an entry; server code writes these directories with ordinary file I/O. Shell YOLO mode, which bypasses the whole shell allowlist including the extension floor, is unchanged. First milestone of the research harness (`design/research-harness.md`, conflict 1).
- **Writes outside the write policy ask for approval instead of failing; a git approval can no longer be refused on scope afterwards** (`app/utils/write_grants.py` (new: per-call grant, floor, `check`/`classify`, diff preview), `app/utils/consent_gate.py` (preflight refusal returns with no panel; `outside_policy` always asks; `write_grant` on the decision; `_display_args`), `app/tool_execution.py` (activates the grant around `execute()`), `app/mcp/tools/fileio.py` (`FileWriteTool.preflight`, `scope_preflight`, grant-aware check), `app/utils/git_ops.py` (`_split_policy`, `_require_granted`; `add`/`commit` drop the policy check), `app/mcp/tools/git_tool.py`, `frontend/src/components/ConsentPanel.tsx`, `frontend/src/utils/consentStore.ts`; tests `tests/test_scope_consent.py` (new), `tests/test_scope_consent_seam.py` (new), `tests/test_git_ops.py`, `tests/test_git_ops_stash_fetch_clone.py`, `frontend/src/components/__tests__/ConsentPanel.test.tsx`; `design/scope-consent.md` (new), `design/git-tool.md`, `Docs/Capabilities.md`, `Docs/ThreatModel.md` §6.7). Before this, the git approval panel opened for calls whose own plan already knew the write policy would refuse them, so approving did nothing. `file_write` outside the policy just failed. Now: `add`, `unstage`, `commit`, `stash_push`, `fetch` and `push` don't consult the write policy, because they record existing content and the approval lists every file. For `checkout` with paths, `stash_pop`, `clone` and `file_write`, a target outside the policy is shown in the panel, with a diff for `file_write`. Approving allows exactly those paths for that call only. The chosen scope never covers paths, and autonomous project mode still asks. The install extension directory, anything outside the project root (symlinks resolved) and `.git` are never grantable. With no conversation to ask in, the write is refused and the reason names the paths. A call whose preflight says it can't run now returns "`` was not run: …" without opening a panel. Previously that case read "the user declined". Shell writes are unchanged. Accepted trade-off: consent can be answered over loopback, so for builtin writes inside the project the write policy is now as strong as consent rather than as strong as a signature.
- **`git` tool: `stash_pop`, `fetch`, `clone`, and `stash` as an alias of `stash_push`** (`app/utils/git_ops.py` (`plan_/op_stash_pop`, `plan_/op_fetch`, `plan_/op_clone`, `OP_ALIASES`, `git_env(restrict_protocols=)`, status `stashes`), `app/mcp/tools/git_tool.py` (schema: `index`, `url`, `dest`), `app/utils/git_grant_hazards.py` (`clone` hazards; `stash`/`fetch`/`clone` redirect to the tool); tests `tests/test_git_ops_stash_fetch_clone.py` (new), `tests/test_git_tool_schema_parity.py` (new), `tests/test_git_ops.py`, `tests/test_git_grant_hazards.py`; `design/git-tool.md`, `Docs/Capabilities.md`). All three new ops ask for approval. `stash_pop` needs a clean tree, lists every file the stash will write (including its untracked-files commit), refuses files outside the project or the write policy and never overwrites an untracked file; on a conflict the stash is kept and the conflicted files are reported. `fetch` accepts only a configured remote (defaulting to the branch's upstream, then `origin`), always passes `--no-prune`, takes no refspec, and reports new/updated remote-tracking refs and ahead/behind. `clone` accepts `https://`, `ssh://`, `git://` and `user@host:path` URLs only. `GIT_ALLOW_PROTOCOL` is set for clone so git refuses other transports on redirect or submodule. It clones into a new, policy-allowed directory inside the project, without submodules. Also: `run_op`/`preflight` no longer fall through to `switch` for an op without a branch. That case now refuses.
- **Skills can ship helper scripts, references and assets, disclosed per the agentskills.io integration guide** (`app/utils/skill_resources.py` (new), `app/services/skill_discovery.py` (`user_skill_roots`, `resourceManifest`), `app/models/skill.py`, `app/mcp/tools/skill_tools.py`, `app/services/bench.py`, `app/agents/task_executor.py`, `app/agents/delegate_manager.py`, `app/mcp/tools/fileio.py`, `frontend/src/utils/skillPrompt.ts` (new), `frontend/src/context/ProjectContext.tsx`, `frontend/src/types/skill.ts`; tests `tests/test_skill_resources.py` (new, 21), `frontend/src/utils/__tests__/skillPrompt.test.ts` (new, 3); `Docs/Skills.md`). Discovery already recorded `hasScripts`, but every activation path sent only the SKILL.md body, so "run `scripts/x.py`" had no anchor: the model could guess `.skills//` for a project skill and had no way to find a user-global one. An activated file-backed skill now ends with `Skill directory: `, the spec's "relative paths are relative to the skill directory" line, and a `` list of bundled files (listed, not read; capped at 50 with an omitted count). One formatter serves all five paths: `get_skill_details`, bench "always" placements, task cards, delegates, and the client-assembled prompt, which reads it from the new `Skill.resourceManifest` field on `GET /skills/{id}`. Following the guide's permission-allowlisting step, the read tools now accept user-global skill roots and the resolved targets of symlinked skills, which `npx skills add -g` creates. Built-in and stored-JSON skills are unchanged. Not done: the `[Skill: …]` / `[Active Skill: …]` headers are kept rather than switched to the guide's optional `` wrapper, because `capability_events` keys on them.
- **Model tables and prices for Bedrock, Anthropic, OpenAI, z.ai and Meta brought to parity with the providers' pages; deprecated and phantom models removed** (`app/config/models_config.py`, `app/config/pricing.py` (`CATALOG_REVISION` → `2026-10-01.2`, `_openai_card`, `meta` section), `app/plugins/default_providers.py`, `app/utils/precision_prompt_system.py`; tests `tests/test_provider_catalog_2026_10.py` (new, 90), `tests/test_openai_gpt55_models.py`, `tests/test_zai_provider_routing.py`, `tests/test_global_inference_profiles.py`, `tests/backend/test_cost_model.py`; `Docs/FeatureInventory.md`, `Docs/CostAccounting.md`). Sources: each provider's deprecations / models / pricing pages plus the Bedrock model cards, all read 2026‑10‑01, and the live `/models` endpoint of OpenAI, Anthropic, z.ai and Meta — which the new test embeds as data so every shipped id is asserted against what the provider actually serves. The headline defect: `gpt-5.5-mini` and `gpt-5.5-nano` never existed (OpenAI lists only `gpt-5.5` and `gpt-5.5-pro`), yet they were the OpenAI `small`/`xsmall` rungs and the endpoint's service default, so every background task on that endpoint 404'd; they are aliases to `gpt-6-luna` now. **Removed → alias:** Bedrock `haiku` (Claude 3 Haiku, EOL 2026‑09‑10), `sonnet` (Claude 3 Sonnet, EOL passed), `sonnet4.0` (EOL 2026‑10‑14), `opus4.1` (Legacy; provider-set extended-access pricing from 2026‑10‑08); OpenAI `o3`, `o3-mini`, `o4-mini`, `gpt-4o` (shutdowns 2026‑10‑23 / 12‑11), `gpt-5.4-nano` (2027‑04‑01); Anthropic `claude-sonnet-4-5` (retires 2026‑11‑30). The Bedrock `haiku`/`sonnet` entry names had been shadowing the aliases of the same name, so "haiku" selected the dead Claude 3 model; the alias now wins. **Added:** Bedrock `sonnet5.5` (new `medium`), `mythos5.1` (us./global. CRIS profiles, unlike mantle-only Mythos 5) and `gpt-6.1-sol`; Anthropic `claude-sonnet-5-5` (new default and `medium`) and `claude-mythos-5-1`; OpenAI `gpt-6-astra` (`large`), `gpt-6.1-sol` (default, `medium`), `gpt-6-sol`, `gpt-6-luna` (`small`; `xsmall` rounds up), and `gpt-5.6-sol/terra/luna`; z.ai `glm-5.3` (default, `medium`) and `glm-5.3-flash` (`xsmall`); Meta `muse-spark-1.3` (default, `medium`) and its contributor tier. Anthropic Sonnet 5 corrected to its real 1M / 128K envelope and, with 5.5, declares `unsupported_parameters` since Anthropic now 400s on non-default sampling params for 4.7-and-later. **Priced:** the whole OpenAI 5.4 / 5.5 / 5.6 / 6 line with the 272K step-up (2× input and cache, 1.5× output), GPT‑6 cache writes at 1.25× input, Batch/Flex 0.5× and Fast 2×; z.ai GLM‑4.7 → 5.3 (exact names, since `glm-5.3` must not swallow `-flash`/`-flashx`); Meta Standard and Contributor tiers with order-independent globs. Bedrock ids for the three new entries come from the model cards, not an invoke probe (no live AWS session); Mythos 5.1 is restricted-access and not on this account's `/models`. Not changed: Bedrock `sonnet4.5` stays (Anthropic deprecated it, Bedrock has not moved it to Legacy); the z.ai service default stays on `glm-4.6`; Bedrock-side GPT‑6 / 5.6 pricing is still unknown. **Completed 2026-10-09** (the config and pricing half of this pass had never been applied; only its tests and docs had landed, with 70 of the catalog tests red), re-verified against every provider's live `/models` and a one-token call per new id, and extended: Bedrock `haiku-5.5`, `grok-4.7`, `glm-5.3` (profile-only, so Converse rather than the `glm` family's invoke wrapper) and Anthropic `claude-haiku-5-5`, all untiered pending a decision on moving the Haiku rungs and service pins; Bedrock ids are now invoke-verified except restricted `mythos5.1`. Two seams fixed (`app/providers/openai_direct.py`, `app/services/model_resolver.py`): every request on `--endpoint openai` 400'd because GPT‑5.x/6.x reject `max_tokens` (the endpoint now declares `max_tokens_param: max_completion_tokens`), and service calls always sent `temperature`, which every 5.5+/6.x model rejects; both paths now honour `unsupported_parameters`. Pricing: Sonnet 5.5 cache read corrected to $0.10 (0.05×; it had shared Sonnet 5's card), Haiku 5.5 priced with its >100K-prompt step-up (`CATALOG_REVISION` → `2026-10-09`). Tests: `tests/test_provider_catalog_2026_10.py` (+8 cases).
- **`shadow_wait`: event-driven waiting on a shadow session, with waits up to 24 h** (`app/shadow/sock_server.py` (`_op_wait`, `WAIT_CAP_MS`), `app/shadow/client.py` (`wait`, `WAIT_CHUNK_MS`), `app/mcp/tools/shadow_tools.py` (`ShadowWaitTool`; `shadow_send` gains `still_running` + a `next` hint), `app/mcp/tools/base.py` (`BaseMCPTool.exec_timeout_for`), `app/tool_execution.py` (lifts `TOOL_EXEC_TIMEOUT` to a tool's declared need), `app/mcp/builtin_tools.py`; tests `tests/test_shadow_wait.py` (new, 16), `tests/test_shadow_tools.py`; `design/shadow-wait.md` (new), `Docs/design/shadow-sessions.md` §5/§9). The line-control loop's only pacing primitive was `wait_idle`, which resolves on output *silence* — so a quiet build looked finished and a chatty one never did — and models fell back to `sleep 600` in the local shell before dumping the whole transcript. `shadow_wait(until=[exit|change|pattern|lines|quiet|ask])` returns on whichever fires first (the exit code of `cmd_seq`, any new record, a regex hit with the matching line, N new lines, quiescence, or a human ask) plus the last `tail_lines` of new output, so one call is both the wait and a selective read; a timeout is a checkpoint with the tail so far. Server side is a journal listener on a `threading.Event` (clear-before-drain, replay from `from_seq` so an exit in the gap after `shadow_send` fires at once), capped at 60 s per socket request; the tool chains hops to the requested budget so a user stop takes effect within one hop, and declares its own need through `exec_timeout_for` so the executor's 300 s guard is raised rather than killing a legitimate hour-long wait (the undeclared case still times out — pinned).
- **A diff fence covering several files is validated file by file, so a correct diff is no longer reported as "did not apply"** (`app/utils/diff_validation_hook.py` (`detect_completed_diffs`, `_split_by_file`); `tests/test_diff_validation_multifile_fence.py` (new, 4)). The mid-stream validator took the first file's path for the whole fence and ran the pipeline on a temp copy named by that file's basename. Later files in the fence were never checked, and a later file sharing the first one's basename (`app/config/write_policy.py` and `app/mcp_servers/write_policy.py`) had its hunks merged into the first file by the pipeline's basename fallback. Every hunk then failed, the post-apply language check rolled back the rest, and the chat showed "hunks 1–6 of 6 did not match" for a diff the frontend applied in full, because the frontend applies each file against its real path. The model, told its diff had failed, then invented a reason and re-issued it. Each file in a fence is now its own validation unit, and rejections still carry the whole fence's hash so the frontend marks the right block. The off-by-N tolerance was never the cause: a hunk with a start line off by 3 still passes, and a test pins that.
- **Vega-Lite preprocess helpers are tested against the shipped code, and definition completeness returns a real boolean** (`frontend/src/plugins/d3/vegaLitePlugin.ts`, `frontend/src/plugins/d3/__tests__/vegaLitePreprocess.test.ts`). The test suite had carried hand-copied replicas of the render-closure helpers, and the copies had drifted from the plugin while still passing. The test now imports the real helpers, so `fixDatumFieldSwap`, `fixInvalidColorSchemeInArcs` (with `generateColorPalette`), `fixLayeredChartsWithMismatchedScales` and `fixBarLogScaleBaseline` move from `render()` to module scope unchanged, and the inline error-suppression decision becomes `shouldSuppressVegaLiteError(spec, error)`. A wiring block asserts that the render path calls each one and that each is defined exactly once. Testing the real code exposed a defect: `isVegaLiteDefinitionComplete` is typed `boolean` but returned the matched value itself (`"bar"`, a facet object). Callers coerced it, so behaviour was unchanged, but any strict comparison was wrong. It now returns `Boolean(...)`. It also did not recognise `hconcat` / `vconcat` as a view, so a finished side-by-side or stacked chart counted as still streaming and a real compile error in it was hidden behind the "waiting" placeholder; both now count. Fix 10's duplicate `resolve` assignment and second, redundant axis-orientation loop are removed, with a test pinning the resulting axis layout.
- **A task run's live stream no longer delivers every event twice on reconnect, and a sibling server's catch-up arrives collapsed** (`app/agents/task_run_stream_relay.py` (`_journal` advances `_tail_offsets`; `connect` folds the journal backlog into history before the snapshot; `_tail_running`, `_schedule_drop`); tests `tests/test_task_run_stream_relay_journal.py` (2 new; one assertion corrected to the documented contract); `design/task-cards.md` §Live observation). The tail began reading at `_tail_offsets.get(run_id, 0)`, and only the reader ever set that offset. So the server that executed a run, after closing its journal but still inside the 5-minute history grace window, re-read the journal from byte 0 when a client reconnected: every event landed in history and on the socket a second time. The offset is now "journal bytes already in this process's history", and the writer advances it. On a server that didn't launch the run, the journal backlog used to stream as raw deltas after an empty replay. It's now folded into history first, so a late client gets the collapsed replay and then raw deltas, the same as on the origin. A run whose backlog already ends in `run_completed` starts no tail. These tests had failed since the tail was added.
- **Duplicating a task card rewrites its `sibling("id")` references to the clone's new block ids** (`app/storage/task_cards.py` (`_SIBLING_REF_RE`, `_rewrite_sibling_refs`, `_assign_block_ids(remap=)`); tests `tests/test_task_card_storage.py`). `duplicate()` remints every block id, which is correct, but it left each `sibling("old-id")` pointing at a block that exists only in the original. In the clone those references rendered empty and a `for_each` over them ran zero iterations. design/task-cards.md already described the rewrite, but it was never implemented. Ids not in the clone (for example a calling card's block) are left as they are, the author's quote style is kept, and fill-only saves rewrite nothing. The storage regex matches exactly what the launch validator's does, and a test checks the two agree.
- **Resuming a task run that stopped inside a parallel no longer discards the other branches** (`app/utils/resume_targets.py` (`concurrent_resume_block`, `outermost_parallel_ancestor`, `banked_parallel_children`, `REPLAY_MISSING_PREFIX`), `app/storage/task_runs.py` (`_innermost_running_block`, `_resumable_hold_block`, `mark_held`), `app/api/task_runs.py` (resume-from: `rerun` mode, parallel raise, `resume_banked_ids`), `app/api/task_cards.py`, `app/agents/block_executor.py` (`ExecutionContext.resume_banked_ids`, banked gate, `_replay_artifact` persists the original record), `frontend/src/components/TaskCard/{runMapModel.ts,TaskRunMap.tsx,TaskCardInlineTile.tsx}`, `frontend/src/services/taskRunApi.ts`; tests `tests/test_resume_target_fanout.py` (new), `tests/test_resume_parallel_endpoint.py` (new), `frontend/src/components/TaskCard/__tests__/parallelResumeControls.test.ts` (new); `Docs/Capabilities.md`). After a server restart with four lanes of a parallel running, the reconciler held at "the running block with the latest start", and the banner offered "Retry Lane D". The resume gate is a single skip flag and a parallel starts its children in body order, so that retry would have replayed Lanes A–C as empty "no recorded result" markers, re-run only D, and run verification on the gap. Now a hold, whether from a restart, a force-stop or an infra fault in one branch, names the outermost enclosing parallel. Resuming a parallel replays each finished branch (a direct child with a passing record, including one banked by an earlier resume) and runs the rest. The new `rerun` mode (**⟲ fresh** on a parallel row) runs every branch again. Resume requests that target inside a parallel are moved up to it server-side, a `continue` past a branch banks that branch instead of skipping its siblings, and the per-row buttons on branch rows are disabled. A replayed block's persisted record now keeps its original `failed` flag (only the in-run control-flow copy is cleared), so a later resume can't bank a failure as a finished branch.
- **Vega-Lite preprocessing no longer deletes an authored log scale** (`frontend/src/plugins/d3/vegaLitePlugin.ts` (`fixLogScales`, `convertManualLogAxes`, both now exported module-level passes); test `frontend/src/plugins/d3/__tests__/vegaLogScaleFix.test.ts` (new, 20); `design/harness-small-items.md` §3). Fix 3.7 removed `scale.type: "log"` whenever max/min of the channel's own `field` was below 100. It ignored `x2`/`y2` and the other layers sharing the scale, so a rule from 5 to 25,000 was judged by its low ends (4×) and drawn on a linear axis. Layers inside concat children were never visited. The range rule is gone: log becomes symlog only when some value on the scale is ≤ 0, counted across `field`, `x2`/`y2`, numeric datums and every layer sharing the scale (`resolve.scale: "independent"` splits them), with concat, facet and repeat children each handled as their own scale. Fix 3.8, which turns a pre-logged field on a small domain back into a log scale, now leaves an axis with `axis.labelExpr` alone. Each pass returns its rewrite messages, which the next item (visible chart rewrites) will surface to the model.
- **`vegaLitePreprocess.test.ts` tests the plugin's own preprocessing helpers instead of local copies, which had drifted** (`frontend/src/plugins/d3/vegaLitePlugin.ts` (exports `fixDatumFieldSwap`, `fixInvalidColorSchemeInArcs`, `fixLayeredChartsWithMismatchedScales`, `fixBarLogScaleBaseline`, `isVegaLiteDefinitionComplete`, and the new `shouldSuppressVegaLiteError` drawn out of the render catch block); test `frontend/src/plugins/d3/__tests__/vegaLitePreprocess.test.ts`). The file re-implemented six helpers that lived inside `render()`, and three no longer matched the plugin. Error suppression finds data anywhere in a spec, not only at top level. Definition completeness accepts facet, concat and repeat specs and rejects a truncated `$schema` URL. Fix 10 also strips conflicting layer domains and turns nominal x into ordinal. The suite kept passing throughout. The helpers are now module-level with unchanged bodies. The test imports them, adds one case per drift (each fails against the old copy), and checks that the render path calls each helper and defines it once. Two describes went with them: one asserted an explicit-width SVG branch, the other a post-render `scale()` transform. The plugin had removed both on purpose. Also: `isVegaLiteDefinitionComplete` is declared `boolean` but returned the spec's `mark`/`facet` value; it now returns a boolean (callers only test truthiness).
- **SKILL.md frontmatter with multi-line values is parsed instead of truncated** (`app/utils/skill_frontmatter.py` (new), `app/services/skill_discovery.py`; tests `tests/test_skill_frontmatter.py` (new, 20)). The frontmatter parser read only flat `key: value` lines, so a `description:` continued on indented lines kept just its first line, `description: |` and `description: >-` came back as the literal `"|"` / `">-"`, and an indented continuation line containing a colon (` Sources: the Atlas API …`) was mistaken for a new top-level key. `compatibility` was cut the same way. Plain continuations, literal and folded block scalars (with chomping/indentation indicators) are now read per the agentskills.io guide's lenient-parsing advice; output shape is unchanged (string values, one-level maps flattened to `k=v,…`). Found on three real installed skills, whose fixtures the tests use.
- **The source of each request's `max_output_tokens` is logged and named in the oversized-output error; Bedrock max_tokens stops report where the budget went** (`app/streaming_tool_executor.py` (`_max_tokens_source`, `MAX_TOKENS_SOURCE` log, `_max_tokens_source_hint`), `app/providers/bedrock.py` (`CUTOFF_CENSUS`); tests `tests/test_decide_no_tool_outcome.py` (`TestMaxTokensSource`), `tests/test_stream_loop_recovery_seam.py` (`TestMaxTokensSourceSeam`), `tests/test_bedrock_cutoff_census.py` (new); `Docs/EnvironmentVariables.md` §Known Conflicts). The incident behind the oversized-output fix sent `max_tokens=4096` to a model with a much larger limit, and nothing in the log said why. The limit can come from a skill override, `ZIYA_MAX_OUTPUT_TOKENS` (which saving Model Settings writes for the whole server process), the model config, or a throttle reduction that lasts the rest of the turn. A `🎚️ MAX_TOKENS_SOURCE` line now records the source and value whenever either changes. The error shown after two cap hits names that source: it points at Model Settings only when the env variable set the limit, and otherwise at the skill override, the throttle reduction, or the model's own limit. On every Bedrock `max_tokens`/`length` stop, `✂️ CUTOFF_CENSUS` logs the characters of text, tool-argument JSON and thinking received, and any tool_use block still open at `message_stop`. An open block is one cut mid-arguments, which never gets a `ToolUseEnd`. Neither line changes the events the provider yields.
- **An output-cap hit that delivers nothing is corrected once, then ends the turn visibly, instead of being silently re-issued** (`app/streaming_tool_executor.py` (`_decide_no_tool_outcome` verdict `correct_oversized_output`, `_oversized_output_note`, `_append_to_last_user_turn`, `oversized_output_used`); tests `tests/test_decide_no_tool_outcome.py` (`TestOversizedOutput`, `TestOversizedOutputHelpers`), `tests/test_stream_loop_recovery_seam.py` (`TestOversizedOutputSeam`)). Observed live: with `max_tokens=4096`, two consecutive iterations each spent the full 4096 output tokens on a tool call whose arguments were cut mid-JSON and produced no text. The no-text branch treated both as transient empty completions and re-issued the identical request, which was cut at the same cap, then ended the turn with nothing shown. A `max_tokens`/`length` stop whose `output_tokens` is at (≥90% of) the cap now appends one note to the last user turn telling the model the limit and to split the work. If it happens again with no clean tool progress in between, the turn ends with an error naming the cap and pointing at Model Settings / `ZIYA_MAX_OUTPUT_TOKENS`. After tool results this replaces the "you did not synthesize an answer" nudge, which was the wrong diagnosis. A `max_tokens` stop that reports near-zero output keeps the existing retry ladder. The INCOMPLETE_JSON tool error now also names the output limit and says not to resend the same oversized call.
- **`shadow_send` no longer blocks the event loop** (`app/mcp/tools/shadow_tools.py`; `tests/test_shadow_wait.py::test_shadow_send_runs_blocking_client_calls_off_the_loop`). Its `async execute` called the synchronous `client.send_line` (socket timeout 85 s at a gated confirm) and `client.wait_idle` (up to 125 s) directly on the asyncio loop, so every other request in the process — window polling, the sidebar, other conversations — stalled while a shadow command ran. Both now run under `asyncio.to_thread`, the same fix `/api/shadow/attached` received.
- **The `git` builtin tool gains `grep` (read-only) and `checkout` (consented)** (`app/utils/git_ops.py` (`op_grep`, `plan_checkout`/`op_checkout`, `_valid_rev`), `app/mcp/tools/git_tool.py` (`pattern`, `ignore_case`, `rev` args; `consent_op_defaults["grep"] = "off"`), `app/utils/git_grant_hazards.py` (shell `git checkout`/`git restore` grants now point at `op=checkout`); tests `tests/test_git_ops.py` (15 new), `tests/test_git_tool_seam.py` (2 new), `tests/test_git_grant_hazards.py`; `design/git-tool.md` §Op set, `Docs/Capabilities.md`). `grep` joins `status` in the no-approval set: it searches the worktree (tracked and untracked files) or a commit and returns structured path/line/text matches, with the pattern passed under `-e` so `-O`/`--open-files-in-pager`, the one form of `git grep` that runs a program, is inexpressible rather than regex-refused. `checkout` reverses a v1 exclusion, deliberately: with `paths` it rewrites those files from the index or from `rev` and is the first op that discards uncommitted edits — offered because, unlike `reset --hard` or `clean`, its blast radius can be itemised before the fact. The plan lists `to_write` and the subset `discards_uncommitted`, the human approves that exact list, every written path must pass the write policy (all-or-nothing, as for `commit` with paths), and a target that is currently untracked is a refusal, so "never overwrite an untracked file" still holds. With `rev` alone it detaches HEAD at a commit under the same clean-tree rule as `switch`; a local branch name is redirected to `switch`. Revisions are validated before git sees them (no leading `-`, no whitespace, must resolve as a commit).
- **Release sweep planning tooling is release-agnostic and the orchestrated sweep card drives it** (`scripts/release_plan.py` (rewritten), `scripts/release_hunks.py` (rewritten), `design/sweep-orchestrated.task-card.json`, `design/sweep-orchestrated.md`, `Docs/CLITasks.md`, `tests/test_release_tooling.py` (new), `tests/test_sweep_orchestrated_card.py`) — `release_plan.py index` derives the `## [Unreleased]` entry index (stable slug `entry_id`s; every dirty path partitioned into claimed / contended / unclaimed; stale citations and already-shipped entries reported) from `CHANGELOG.md` and `git status` alone, and `release_hunks.py dump | split | merge` lists a contended file's hunks by number, turns a `{hunk index: entry_id}` mapping into per-entry patches validated with `git apply --cached --check`, and records a merge escape that refuses a generic reason. The previous `release_plan.py` hardcoded the v0.8.7.0 target, an exclusion list naming that release's files and ~80 affinity rules keyed on changelog entry *index*; run against the v0.8.9.0 tree it would have mapped the wrong hunks to the wrong entries, so the sweep agent correctly refused it and then had no non-interactive way to split `app/server.py` across the eleven entries claiming it. The card's P2a/P2b stages now run these scripts, so the agent's output per contended file is a small JSON mapping rather than a hand-written diff. Also: `ziya task ` falls through to a deck card of that name (case-insensitive, or by id) when no `tasks.yaml` task matches (`app/cli.py` (`cmd_task`), `tests/test_cli_task_runner.py`), so the card is callable as `ziya task "Sweep (orchestrated)"` — or as `ziya task sweep` once the linear entry is removed from a local `tasks.yaml` and the deck card carries that name. `tests/test_sweep_commit_grouping.py` now skips, rather than erroring, when no linear `sweep` prompt exists.
- **Gemini direct models and prices brought to parity with Google's published pages, including a provisional Gemini 4 Argon entry** (`app/config/models_config.py`, `app/config/pricing.py` (`CATALOG_REVISION` → `2026-10-01`, `_GOOGLE_TIERS`), `app/providers/google_direct.py`, `app/agents/wrappers/google_direct.py`; tests `tests/test_gemini_catalog_2026_10.py` (new, 27), `tests/backend/test_cost_model.py` (revision pin); `Docs/CostAccounting.md`, `Docs/FeatureInventory.md`). Sources: ai.google.dev/gemini-api/docs/{models,pricing} and the per-model pages, read 2026‑10‑01, plus the 2026‑09‑30 Argon announcement. The Google table gains 3.8/3.7/3.6/3.5 Flash, 3.5 and 3.1 Flash‑Lite (3.1 Flash‑Lite, the cheapest live Gemini, is the new `xsmall` rung and the google service default) and `gemini-4-argon` (1M output, `argon` alias); `gemini-2.0-flash(-lite)`, shut down by Google, leave the table but keep resolving as aliases, and the memory‑extraction / intent‑judge service overrides that pointed at them move to 3.8 Flash. `gemini-3.5-flash` moves to the `gemini-3` family so its thinking level is actually published (the `gemini-flash` family declares no `thinking_level` parameter). Pricing: every shipped Gemini id now has a built-in rate (3.1 Pro, 3 Flash and 3.5 Flash were unpriced); 2.5 Pro cache read corrected from $0.31 / $0.625 to Google's $0.125 / $0.25; Batch = Flex = 0.5× and Priority = 1.8× on every 2.5/3.x text model; the 3.6–3.8 Flash introductory rate ($0.75 / $3.75 / $0.075) is a dated row that expires 2026‑12‑31 with the doubled rate taking over on 2027‑01‑01, so history reprices correctly across the boundary; globs use `[!l]` / `[!lt]` to stay disjoint from the `-lite` / `-live` / `-tts` / `-image` siblings instead of relying on catalog list order. Argon is priced at its announced introductory $2 / $10 with cached input at 95% off from 2026‑09‑30, is deliberately not tier‑tagged (no background task should route to a model most keys cannot reach yet), and both the entry and the glob are marked provisional because the endpoint is not yet on the API models page. The two provider‑side `thinking_level` gates keyed on the substring `gemini-3` now also accept `gemini-4`. Known gap, documented: Google does not halve the 3.1 Pro Batch cache-read rate, which the uniform tier factor cannot express. `gemini-pro-latest` (the `gemini-latest` alias) is a floating pointer and stays unpriced by design.
- **The Bench shows and clears MCP rug-pull quarantine** (`app/services/bench.py` (`health.gate`, `reauthorize_mcp`, held servers list their tools), `app/api/bench.py` (`POST /bench/reauthorize`, held items excluded from weight), `frontend/src/components/Bench/CapabilityCard.tsx` (⛔ chip, hatched face), `CapabilityDetail.tsx` ("Definitions changed" section with Re-authorize and the "Re-authorize anyway" override on a blocking refusal), `WeightGauge.tsx`, `hooks/useBench.ts` (`reauthorize`), `apis/benchApi.ts`, `utils/headerAttention.ts`; tests `tests/test_bench_gates.py`, `Bench/__tests__/benchGates.test.tsx`). The Bench absorbed the MCP Servers toolbar button but not its re-authorize action, and a quarantined server showed as "not connected" because the manager withholds its tools from `get_all_tools()`. A gate is now distinct from a placement: the card keeps its lane, is marked held, costs nothing on the gauge, and is re-authorized from its drawer; the header message now points at the Bench.
- **Skills and MCP servers are marked by kind wherever the bench mixes them** (`frontend/src/components/Bench/KindMark.tsx` (new), used by `CapabilityCard`, `CapabilityDetail`, `BenchPalette`, `BenchFind`; `Bench/__tests__/KindMark.test.tsx` (new)). First users of the combined bench found a skill and a server in the same lane hard to tell apart: the only cue was a faint grey word. Each surface now carries one chip with a glyph, a colour and the word (◆ blue *skill*, ⚙ lime *MCP*), and every Find column wears its kind's colour along its top. The colours are distinct from the provenance spine (grey/teal/berry/amber), so the left edge still says where an item came from and the chip says what it is; the test asserts that separation.
- **Bench "find" view: skills and MCP servers are searched per source, never listed** (`app/services/bench_find.py` (new), `app/services/skill_sources.py` (`search`, `SearchResult`, `enumerable`, `support_level`/`matched` on listings), `app/api/bench.py` (`GET /bench/browse` re-shaped), `frontend/src/components/Bench/BenchFind.tsx` (new), `BenchPanel.tsx` (arrange | find toggle), `hooks/useBench.ts` (`find`, `install`), `apis/benchApi.ts`; tests `tests/test_skill_sources.py`, `Bench/__tests__/BenchFind.test.tsx`). The sources behind the bench hold tens of thousands of skills and servers, so browse is a query: with no query the view shows only what this bench implies — installed skills whose `requires:` name a server the config lacks, installed skills whose source now reports a newer version, and skills in the local/git sources whose requirements the servers on hand already satisfy. A query fans out concurrently to every skill source and the MCP registry and renders one column per source with the top hits, the source's total ("+M more") and a link to the full registry. Install fetches, writes and places at the current lens's layer in one call. There is no curated default and a registry support level is a badge, not a gate. Internal Edition: the AIM skill source now searches via `aim capabilities search` (hits grouped by package), lists every support level, and is excluded from any listing path.
- **Reasoning selector in the model configuration modal replaces the on/off Thinking Mode switch, with per-backend option sets** (`app/utils/thinking_options.py` (new), `app/providers/base.py` (`ThinkingConfig.display`), `app/providers/bedrock.py`, `app/providers/anthropic_direct.py`, `app/providers/openai_responses_mantle.py`, `app/providers/google_direct.py`, `app/providers/nova_bedrock.py`, `app/streaming_tool_executor.py`, `app/routes/model_routes.py`, `app/config/env_registry.py` (`ZIYA_THINKING_DISPLAY`), `app/config/models_config.py`, `frontend/src/utils/thinkingDisplay.ts` (new), `frontend/src/components/ModelConfigModal.tsx`, `frontend/src/components/ModelConfigButton.tsx`; tests `tests/test_thinking_display_options.py` (new, 29), `frontend/src/utils/__tests__/thinkingDisplay.test.ts` (new, 16); `Docs/Capabilities.md`, `Docs/EnvironmentVariables.md`). One setting, `ZIYA_THINKING_DISPLAY` (`quiet` / `summary` / `full`), says how much reasoning streams back; each provider maps it to its own knob and `/api/model-capabilities` publishes the honest subset per model so the selector never offers a tier the backend cannot honour: adaptive Claude gets Off / quiet / summary (`thinking.display: omitted|summarized` — the API has no full-text tier), the OpenAI Responses API gets quiet / summary / detailed (`reasoning.summary`), Gemini gets quiet / summary (`include_thoughts`), raw chain-of-thought providers (DeepSeek, z.ai, Kimi, Ollama, Chat Completions) get Off / hidden / full with Ziya dropping the deltas at hidden, and budget-thinking Claude and Converse models stay Off / On. A model entry may pin its own list (`thinking_display_options`; Meta Muse Spark, which bills for reasoning it never streams, offers only Off / On). Effort and level pulldowns grey out when reasoning is Off. The control is published even while thinking is off, so it no longer disappears once the user picks Off.
- **A handoff from a global conversation could put the continuation in the wrong project and lose its first turn** (`frontend/src/api/handoffApi.ts`, `frontend/src/components/HandoffDrawer.tsx`, `frontend/src/components/HandoffBanner.tsx`, `app/api/handoff.py` (`_resolve_source`), `app/utils/chat_home.py` (new, `resolve_chat_home`), `app/mcp/tools/context_management.py` (`_resolve_chat_for_request`), `app/utils/auto_context.py` (`_open_chat`), `frontend/src/utils/heldMessageStore.ts` (new), `frontend/src/context/ChatContext.tsx` (SHELL_GUARD, push filter), `app/models/chat.py` (`ChatUpdate.handedOffTo`); tests `tests/test_chat_home.py`, `tests/test_handoff_source_resolution.py`, `frontend/src/api/__tests__/handoffApiProjectRouting.test.ts`, `frontend/src/utils/__tests__/heldMessageStore.test.ts`, `frontend/src/utils/__tests__/handoffCrossProjectSeams.test.ts` (all new)). Every handoff call routed by the window's current project (or `default` when unset), not the conversation's own. A global conversation worked from a window on another project was committed against a stale 0-message copy there: the continuation was written into that project with a document claiming a 0-message source, the forward link landed on the copy, and the first send in the continuation armed SHELL_GUARD (the drawer inserted it as a shell), whose recovery looked in the conversation's real project, got 404, and held the whole 13-minute agent turn in memory, where a reload discarded it. The drawer now routes by the source's projectId and inserts the continuation as a complete (empty) record; the endpoints use the fullest sibling copy when the requested one has no messages, and the child inherits the source's `isGlobal`; a held message is persisted to localStorage and re-applied by the next successful recovery; the periodic sync no longer pushes a conversation owned by another project, which the server skips by design and which logged `msg-count divergence (local=60 server=0) — pushing` every 30 s; and `handedOffTo` can be repaired through PUT. The stale copy itself came from the context tools (`context_add_file`, `context_list_files`, and `handoff_write`, which shares their resolver): they looked a conversation up only in the window's project and, not finding a global one homed elsewhere, created an empty same-id record there with no `projectId`. They, the auto-context write tracker, and every handoff endpoint (including editing a continuation's document from the banner) now go through `resolve_chat_home`: a local copy with messages is used, an empty one gives way to the fullest copy in another project, and with no local copy any copy elsewhere is used, so a continuation (empty by construction) is found from any window.
- **The release sweep's announce stages no longer post for a release that did not land** (`design/sweep-orchestrated.task-card.json` (P9, P10a, P10b, state block), `design/sweep-orchestrated.md`, `tests/test_sweep_orchestrated_card.py`) — a sweep run that never finished committing still posted its Slack announcement. The card's root is `on_failure: stop`, but that fires only when the push stage *marks* its artifact failed; a stage that narrates a failed push and ends its turn succeeded lets the announce group run. Each announce stage now opens with a PUSH GATE that verifies from git — `git tag -l v` lists the tag, `git status -sb` shows the branch is not ahead of its upstream, `git log -1` is the `chore: bump version` commit — plus `mode == 'pushed'` in the ledger, and posts nothing and fails if any check fails; the gate precedes the first external action and is stated as independent of any earlier stage's prose. P9 is told to fail its block, not merely report, when the push does not land, and the state block carries the rule as ANNOUNCE RULE so a stage added to the group later inherits it.
- **Kimi, GPT-6 (Sol/Astra/Luna), MiniMax, GLM and Nova no longer fail on Bedrock with `Invalid 'tools': missing field `type``** (`app/providers/base.py` (`LLMProvider.measure_baseline_tokens`, default `None`), `app/providers/bedrock.py` (owns the Claude invoke_model probe and its error handling), `app/providers/anthropic_direct.py` (delegates to its `count_tokens` pre-flight; `BedrockMantleProvider` inherits the heuristic), `app/streaming_tool_executor.py`; test `tests/test_provider_baseline_measurement.py` (new, 7)). The one-time token-calibration baseline hand-built an Anthropic Messages body in the executor and fired it at a raw boto3 client whenever a Bedrock client existed, so every non-Claude Bedrock family received a tools array in the wrong wire format, and because botocore's `ClientError` was outside the executor's except tuple the rejection killed the user's stream. The probe now lives behind a provider method: providers that cannot measure return `None` and the executor estimates from JSON size; a probe that fails or reports an implausible count also falls back to the estimate instead of re-firing on every request. The executor no longer references any wire format (guarded by a source-level test); per-family persistence in `token_calibration.json` is unchanged.
- **Mermaid multi-line labels were clipped to their first line on narrow windows (< ~1300 CSS px) in every browser** (`frontend/src/utils/uiScale.ts` (`neutralizeUiZoom`, `createUnzoomedMeasureHost`, `withUnzoomedMeasureHost`), `frontend/src/plugins/d3/mermaidEnhancer.ts` (both render paths), `frontend/src/index.css` (`foreignObject p` scope), `frontend/src/utils/__tests__/uiScaleMeasureHost.test.ts` (new, 6), `frontend/src/plugins/d3/__tests__/mermaidUnzoomedMeasureHost.test.ts` (new, 5), `tests/test_mermaid_label_zoom_e2e.py` (new, 2, integration)). Reported on a small-screen Firefox Mac but reproduced identically in Chromium: each `
` label showed line 1 centred in a two-line-tall node with a 2–3 px sliver of line 2 beneath it, and resizing the window did nothing. Cause: the narrow-viewport UI zoom (above) is CSS `zoom` on ``, and mermaid sizes htmlLabels from `getBoundingClientRect()` of a scratch div it appends to that body. The rect is in viewport px, so at zoom 0.67 a 200×48 label measured 134×16 and mermaid wrote 134×16 back as the `foreignObject` clip box; `localStorage.ZIYA_UI_ZOOM='off'` restored 200×48 (the discriminator). Resizing did not help because the factor is decided once at boot. Fix, generalized: `uiScale.ts` now exposes a zoom-neutral measurement host (its own `zoom` is 1/z, and nested zoom multiplies back to 1 — verified in Firefox 156 and Chromium 145: a 247 CSS-px span measures 165.7 in the zoomed body and 247.25 inside the host). The mermaid enhancer renders through `withUnzoomedMeasureHost`, passing the host as mermaid's container on both the direct-API and fallback paths, so measurement and display agree and the finished SVG is zoomed uniformly with the page; an explicitly supplied container is passed through. Any other renderer that lays out from measured DOM text should wrap its call the same way. Separately, `.message .message-content p { white-space: normal }` (and the wrap affordances in `messageContentOverflow.css`) no longer reach into `` label markup, which had been turning the horizontal overflow into a wrapped-then-clipped second line. The `/render` capture harness is zoom-exempt and could never see this; the new e2e test drives the real chat at a 900-px viewport, asserts the body really zoomed, and asserts every node's `foreignObject` covers its label's unzoomed `offsetWidth/offsetHeight` — it fails against the prior build with `fo 134×16 vs div 134×48`.
- **Periodic sync re-pushed a stale longer local copy every 30 s after a server-side rewind or delete** (`frontend/src/utils/syncMerge.ts` (`serverShrankPastLocal`), `frontend/src/context/ChatContext.tsx` (push candidate filter); test `utils/__tests__/syncPushServerShrank.test.ts`). The "msg-count divergence — pushing" rule sent any local conversation with more messages than the server regardless of version. A server record only shrinks through an explicit rewind/delete, which bumps its `_version`, so a server that is newer *and* shorter means local's extras were removed there; pushing re-sent tombstoned messages, `bulk_sync_chats` dropped them and bumped `_version` again, and the rule re-fired on the next cycle (`local=18 server=13` logged indefinitely for one conversation). The push now defers to the pull side (`shouldFetchFull`'s `serverShrank`) in that one case; a same-version local that is genuinely ahead still pushes as before.
- **Every new reply vanished right after streaming in an older conversation that had been edit-and-resubmitted** (`frontend/src/utils/messageFingerprint.ts` (new), `frontend/src/utils/syncMerge.ts` (`addTombstones`, `tombstonedFps`, `droppedMessages`, `shrinkExplainedByTombstones`, `growthExplainedByTombstones`), `frontend/src/context/ChatContext.tsx` (`replaceMessages`); tests `utils/__tests__/messageFingerprint.test.ts`, `utils/__tests__/idbShrinkGuardIdlessMessages.test.ts`). The stream completed and the reply entered state, then `FAST_PATH_TOMBSTONE` kept IndexedDB's longer pre-edit copy, the next sync pushed and re-hydrated that copy, and the reply was gone — on every send. Cause: the browser tombstoned removed messages by id only, while the early messages of an older conversation have no id (they predate per-message ids), so an edit that cut them was never explainable to the IDB guards, and the shrink check also refused on any id-less message even when it was kept. The browser now writes the same content fingerprints the server does (`sha1(role\0content)`) for every removed message, matches id-less and push-minted `msg-…` messages by fingerprint in both guards, and tombstones the old content of an id-less message edited in place. Server-written `fps` tombstones are honoured by the client for the first time. A conversation already stuck this way may still need its stale IndexedDB record cleared once (DevTools → Application → IndexedDB); the condition no longer recurs.
- **Edit-and-resubmit near the top of a long conversation: the removed history came back under the new answer** (`frontend/src/utils/syncMerge.ts` (`shouldRehydrateActiveFromFuller`, `growthExplainedByTombstones` new), `frontend/src/context/ChatContext.tsx` (post-sync active-conversation rehydration, both the IndexedDB and the server hop), `frontend/src/components/EditSection.tsx` (`handleSave` awaits the PATCH); tests `frontend/src/utils/__tests__/postSyncRehydrationGuard.test.ts` (new, 13), `frontend/src/components/__tests__/editSectionSaveReportsServerFailure.test.tsx` (new, 4)). Editing the first message and pressing Submit truncated the list to one message and sent the truncated request, but the display then showed the whole old history with the new answer appended. `syncWithServer`'s `finally` re-hydrates the active conversation whenever it holds two or fewer messages, adopting any LONGER copy from IndexedDB or the server; it runs even on the early "streaming" return and on the stream-end sync, and a deliberate truncation looks exactly like the hydration gap it was written for. This block has existed since April (IDB hop) and August (server hop); the stream-end sync added in September made it fire on every first-message edit rather than only when a 30s tick happened to land mid-stream. A longer copy is now adopted only when the local record is a shell, or is no newer than the copy and does not tombstone the copy's extra messages, and never while the conversation is streaming. Underneath that, the truncation never reached IndexedDB at all: all three IDB write guards (`FAST_PATH_TOMBSTONE`, `IDB_WRITE_GUARD`, `SAVE_GUARD` in `frontend/src/utils/db.ts`) refuse any write that lowers a message count above 2, keeping the existing messages and stamping the incoming `_version` — so IDB held the whole old history under the truncation's version, longer than state and no older, and every IDB reader adopted it about a second later. The guards predate explicit delete/rewind, when a shorter list could only mean a stale copy. They now decide through `syncMerge.shouldPreserveExistingMessages`, which lets a shrink through when every dropped message is tombstoned on the incoming record (the same test `decideCrossTabMerge` uses); an untombstoned shrink is still refused (test `frontend/src/utils/__tests__/idbShrinkGuardHonorsTombstones.test.ts`, new, 9). This also means the earlier "`replaceMessages` persists to IndexedDB" fix only now does so for a shrink. Separately, edit-in-place ("Save") fired its server PATCH without waiting; a failed PATCH left the server on the old text with no indication. It now awaits the call and warns when it fails (404, chat not yet synced, stays silent).
- **Editing a message could not be completed: the textarea reset to the stored text every ~30 seconds** (`frontend/src/components/EditSection.tsx` (draft seeding keyed on the edit session, not on the message array); test `frontend/src/components/__tests__/editSectionDraftSurvivesSync.test.tsx` (new, 4)). `ChatContext.syncWithServer` polls every 30s and can replace the active conversation's message array with a new one of identical content. `EditSection` seeded its draft in an effect that listed `currentMessages` as a dependency, so each tick re-ran it and overwrote whatever had been typed with `currentMessages[index].content`. The draft is now seeded once per edit session (`conversationId:index`) — when editing starts or the target changes — and a background refresh of the array leaves it alone. Cancelling and re-editing, or switching conversation with an editor open, still re-seeds.
- **The token bar's Chat figure counted assistant history as saved, not as sent — one rendered image showed as ~9,000 tokens the model never receives** (`app/routes/token_routes.py` (`/api/token-count` runs the active messages through `rewrite_tool_history` before counting; `TokenCountMessage.role`), `frontend/src/components/TokenCountDisplay.tsx` (sends `role`); test `tests/test_token_count_route_replay_aware.py` (new, 4)). The estimate now measures the replayed form — tool blocks re-encoded, inline `data:image` tags reduced to their one-line note, redundant bodies elided — so it matches what `server.py` builds. User messages, and requests from a frontend that sends no role, are counted as before.
- **Every image a `view_image`, `render_diagram` or `recall_image` call produced was re-sent to the model as base64 text on every later turn** (`app/utils/tool_history_rewrite.py` (`elide_inline_images`, `INLINE_IMAGE_NOTE`, applied in `rewrite_assistant_text` and kept on under the rewrite kill switch); test `tests/test_tool_history_inline_image_elision.py` (new, 9)). The frontend shows the picture by prepending `` to the tool block in the assistant message, and history is replayed as saved, so from the second turn on the model received tens of thousands of tokens of base64 per image that it could not see as an image at all. The in-turn compaction window (`image_result_compaction.py`) never covered this: it only sweeps the tool_result content blocks of the live turn. The model sees the real image once, in the turn it was produced; on replay the tag is now a one-line note saying so.
- **Document PDF export fitted figures and tables against the transcript export's page width, not the document's own margins** (`app/services/pdf_exporter.py` (`build_document_print_payload` gains `page_box`; `export_document_pdf` sends the box it paginates with), `frontend/src/utils/printContentBox.ts` (new), `frontend/src/components/PrintRenderPage.tsx` (`fitOversizedFigures` / `fitOverwideTables` take the resolved box); tests `frontend/src/utils/__tests__/printContentBox.test.ts` (new), `tests/test_document_export.py`). The `/print` page hardcoded the printable box as A4 minus `capture_pdf`'s 10mm side margins (~718px), but a document paginates at its front-matter margins (19mm sides by default, ~650px). A figure between those widths passed the oversize check untouched and was squeezed by the `max-width: 100%` stylesheet rule instead, with its height reservation and flow shrink computed for the wrong width. The payload now carries `page.contentWidthPx` / `contentHeightPx`, the page measures against them, and the 10mm constants survive only as the transcript fallback.
- **A fixed-width Vega-Lite chart with a default right-hand legend was shrunk whole to fit the PDF text column — plot and labels included, with an empty band beside a short legend** (`frontend/src/plugins/d3/vegaLegendPlacement.ts` (new), `frontend/src/plugins/d3/vegaLitePlugin.ts` (called after `optimizeLegendLayout`); test `frontend/src/plugins/d3/__tests__/vegaLegendPlacement.test.ts` (new)). A `vconcat` keeps its authored per-view pixel width, and Vega draws the y-axis and legend outside it, so a 620px view with a three-column colour legend is a ~920px SVG; in a ~650px print column the export's figure-fit pass scaled it to ~0.7x with axis labels at 6-7pt. `optimizeLegendLayout` never visited concat sub-views and reacted only to entry count. The new pass is width-driven: when the estimated chart + axis + side legend exceeds the pane and no legend orientation was authored, the legend moves below the plot with a column count fitted to the plot width. A `container`-sized chart (autosize `fit-x`, which subtracts the legend from the pane and starves the plot) relocates when the side legend would take more than a quarter of the pane; a wide chat pane, an authored `orient`, or a hidden legend leave the spec unchanged. The relocated legend also gets a `labelLimit` fitted to its per-column room, so long labels are no longer ellipsised at Vega's 160px default.
- **Inline markdown was lost from any block that also contained inline math — list items printed `**bold**` and `` `code` `` with their markers, paragraphs silently dropped the styling** (`frontend/src/components/MarkdownRenderer.tsx` (`renderTokens`, `paragraph` and `text` cases); test `frontend/src/components/__tests__/listItemInlineMathMarkdown.test.tsx` (new, 4)). Noticed first in a PDF export, but the defect is in the shared renderer and affects chat too. Both cases took a "math fast path" that flattened the token's children to text before splitting on math markers: a tight list item arrives from `marked` as a `text` token whose `.text` is the raw inline markdown, so the markers were emitted literally; a styled paragraph child's `.text` is its bare inner text, so bold and code disappeared without a trace, and math nested inside a bold span (`**… $w$ …**`) was dropped outright. The `text` case now descends into parsed children before considering the raw string, and the paragraph shortcut applies only when every child is a plain text leaf; each leaf renders its own markers, so the math itself is unchanged.
- **Mermaid flowchart labels containing a second bracket group were corrupted by the quote-consolidator** (`frontend/src/plugins/d3/mermaidEnhancer.ts`; test `frontend/src/plugins/d3/__tests__/mermaidQuotedLabelBracketMasking.test.ts` (new)). On `A["full_sync()
clear(&transaction)"]` the lazy, line-wide node-definition regex skipped the label's first bracket pair (it opened with a quote) and then resumed scanning inside the same label, treating `clear(&transaction)` as a node with content `&transaction`; the `&` tripped the needs-quotes rule and it emitted `clear("&transaction")`, nesting quotes inside an already-quoted label so Mermaid failed with `got 'STR'` and rendered nothing. Complete author-quoted labels (`["…"]`, `("…")`, `{"…"}`) are now masked as a unit before the node scan, the same way edge labels already were.
- **Thinking Mode "Off" was a no-op on every adaptive Claude model, and "On" did nothing for Converse models** (`app/streaming_tool_executor.py`, `app/providers/nova_bedrock.py`). `_build_provider_config` built an adaptive `ThinkingConfig` whenever the model declared `supports_adaptive_thinking`, without consulting `ZIYA_THINKING_MODE`; toggling the switch only tore the model down and rebuilt it. An explicit Off (the settings route writes `ZIYA_THINKING_MODE=0`) now omits the thinking block — an unset variable keeps the model default, so a server whose settings were never saved behaves as before. Nova and the other Converse-API models ignored thinking entirely on the provider path; the legacy wrapper's step-by-step system-prompt instruction is now applied there when thinking is on, and the UI labels that group "Step-by-step prompting" so nobody expects a thinking panel.
- **Cost accounting, phase 2: a "Usage & cost" view and a per-conversation cost line** (`frontend/src/api/usageApi.ts` (new), `frontend/src/components/UsageCostModal.tsx` (new), `frontend/src/components/ProjectManagerModal.tsx` (footer link), `frontend/src/components/ConversationInfoModal.tsx` (`Cost` row), `frontend/src/api/__tests__/usageApi.test.ts` (new, 14), `Docs/CostAccounting.md`). The phase-1 ledger had been recording for two weeks with no way to look at it except `curl`. Manage Projects → *Usage & cost* groups the ledger by month / day / project / model / source / tier / conversation over a chosen window, scoped to the current project or all of them, and the conversation Info popup shows that conversation's total. Rendering follows `design/CostModel.md`: a figure whose every line is provider-reported is **bold**, one that includes a pre-flight estimate is *italic*, a null cost reads `unpriced` (never `$0.00` — zero is a real price, for local models), and `*` marks a total with unpriced dimensions; a banner states the share of records with no rate rather than letting a smaller total pass for the whole. The API is global (`/api/usage`), so the client uses `fetch` rather than the `/api/v1` project client. **Off by default, per scope** (`costDisplay` on `Chat` / `ChatGroup` / `ProjectSettings` (+ `ChatGroupUpdate`, TS mirrors, `folderSyncApi.ts`), `frontend/src/utils/costDisplay.ts` (new), `frontend/src/hooks/useResolvedCostDisplay.ts` (new), `ChatContext.setConversationCostDisplay`, `ModelConfigModal.tsx`, `ModelConfigButton.tsx`, `frontend/src/utils/__tests__/costDisplay.test.ts` (new, 11)): the Manage Projects footer link was removed — cost display stays out of sight until a user asks, and the answer is the model configuration modal, where a **Show cost for this <scope>** checkbox sits under the *Apply model to* radio and writes to the selected project / folder / conversation record through the same paths as the saved model pin. Resolution mirrors the pin (conversation → folder → project) with no server layer, so an unset chain is hidden and the checkbox is disabled at *Server default*; the row shows the effective value and which scope decided it, and the *Usage & cost…* link appears there and nowhere else. Display only — the ledger records tokens regardless, and a conversation hidden inside a shown project still counts toward the project's totals.
- **A handed-off conversation's last transcript item links forward to the continuation** (`frontend/src/components/HandoffNotice.tsx` (new), `Conversation.tsx`, `HandoffDrawer.tsx`, `utils/types.ts` (`Message.handoffNotice`); test `frontend/src/components/__tests__/HandoffNotice.test.tsx` (new)). After "Ask the model to draft it" and a commit, the source segment ended on "The model drafted a handoff document for this conversation." with only a "Review handoff" link — nothing at the end of the transcript said where the track went (the sticky banner at the top did, but a reader at the bottom never saw it). The notice row is now its own component: once a continuation exists it shows **Continue in "‹child title›" ⇢** instead, resolving the target from the notice's own `targetId` first and the source record's `handedOffTo` second, so a `drafted` notice written before the commit also picks up the link. Committing from the drawer additionally appends a `handed_off` notice to the source (same local, muted, never-sent-to-the-model shape), so a handoff that never had a manually requested draft also leaves a forward-linked last item.
- **The model can link to a project, a conversation, or a specific turn, and the link opens it in place** (`app/utils/ziya_links.py` (new), `frontend/src/utils/ziyaLinks.ts` (new), `frontend/src/components/ZiyaLinkNavigator.tsx` (new), `app/mcp/tools/chat_history_tools.py`, `app/api/chats.py`, `frontend/src/components/AppProviders.tsx`, `frontend/src/components/MarkdownRenderer.tsx`, `tests/test_ziya_links.py` (new, 11), `frontend/src/utils/__tests__/ziyaLinks.test.ts` (new), `frontend/src/components/__tests__/ziyaLinkNavigator.test.tsx` (new, 6), `Docs/ArchitectureOverview.md`, `Docs/FeatureInventory.md`). `chat_search` / `chat_read` / `chat_list` already hand the model conversation ids and 0-based message indices; there was no way to hand them back to the user as anything but text. A `ziya://` href now addresses the three things the model can name: `ziya://project/`, `ziya://chat/`, `ziya://chat//`. Written as an ordinary markdown link, it renders with an ↪ marker; a document-level click handler (`ZiyaLinkNavigator`, mounted in the provider stack so it covers marked links, raw HTML and tool widgets alike) swallows the click and drives the same path the sidebar search uses — switch project if the conversation lives elsewhere, then `loadConversationAndScrollToMessage`. A chat link deliberately carries no project id (conversations move between projects); the owning project comes from state, else from the new `GET /api/v1/chats/{id}/locate`, which resolves through the cross-project chat index and 404s for path-like ids. The chat-history tools attach a ready-made `link` to every conversation, match and message they return (and `projectLink` on the chat_read header), and their descriptions carry the one-sentence format hint, so the model learns the href exactly where it receives the ids.
- **Moving a conversation to another project no longer loses its task card, and a deleted conversation no longer leaves its task bindings behind** (`app/api/task_bindings.py`, `app/storage/chats.py` (`move_to`, `_remove_orphaned_bindings`), `app/api/chats.py` (`POST /chats/{id}/move`), `frontend/src/api/conversationSyncApi.ts` (`moveChat`), `frontend/src/context/ChatContext.tsx`; tests `tests/test_api_task_bindings_cross_project.py` (+1), `tests/test_chat_move_and_binding_cleanup.py` (new, 8)). A card launched in a conversation — including a live run — vanished from the inline view the moment the conversation was dragged to another project: only the chat file moved, while the binding file, the conversation-only card and the run stayed under the project the card was launched in, and `GET /task-bindings` looked only at the viewing project and at the chat's indexed owner (now the destination). The endpoint now also checks every other project for a bindings file (one `stat` each, only when the local list is empty) and stamps each binding with the project it lives in, so the tile's card / run / cancel calls go where the assets are. The move itself was two best-effort client calls, bulk-sync-to-target then DELETE-from-source: bulk-sync silently drops a shell (partially loaded) conversation and reports success, after which the delete ran anyway, and bulk-sync never updated the cross-project chat index. It is now one server call that rewrites ownership (`projectId`; `isGlobal`, `groupId`, `folderId` cleared — folders are per-project, and a source folder id dangled in the target), keeps the index current, and leaves the bindings with the card and run; a failure is reported in the UI instead of logged as "non-fatal". `ChatStorage.delete` (and retention purge) now removes `chats/{id}.bindings.json` — unless the same chat exists in a sibling project, which is a move in progress, not a delete — so a conversation-only card whose conversation is gone becomes prunable.
- **Firefox: scrolling up a long conversation no longer snaps back to the bottom** (`frontend/src/index.css`). `.message` carries `content-visibility: auto`, so the browser lays out off-screen messages at a remembered size and swaps to the real one as they approach the viewport. In Firefox that swap was unstable for some messages (observed ~500px deltas that flipped back within a frame), and scroll anchoring added the difference to `scrollTop` each time, so a normal-speed scroll up netted zero movement and only a fling escaped. Diagnosed from the console: no JS wrote `scrollTop` during the jitter; `ResizeObserver` showed three messages oscillating between two heights; setting `contentVisibility: visible` on the messages stopped it instantly. Firefox now gets `content-visibility: visible` via `@supports (-moz-appearance: none)`; other browsers are unchanged. Off-screen mount cost is still handled by `LazyMarkdownRenderer`'s placeholder shells, so this only gives up the paint-skip on Firefox.
- **The shipped pricing catalog now prices the Claude models people actually run** (`app/config/pricing.py` (`CATALOG_REVISION` 2026-09-28), `Docs/CostAccounting.md`, `tests/backend/test_cost_model.py` (+1, sentinel model renamed)). The built-in table is the only price source a normal install has — `~/.ziya/pricing.json` is an override for internal rates, not something a user can be expected to write — yet it stopped at the 4.5 generation, so on a ledger dominated by Fable 5.1 and Opus 4.8 the "Usage & cost" view priced 974 of 45,000 rows. Added, from Anthropic's platform pricing page: Fable 5 / 5.1, Mythos 5 / 5.1, Opus 4.6 / 4.7 / 4.8 / 5 / 5.5, Sonnet 4.6 / 5 / 5.5, with the per-generation cache-read rates (0.025× on the 5.1 models, 0.05× on Opus 5.5) and no >200k step-up, since 4.6+ bill the full 1M context at the standard rate. Globs for `-5` vs `-5-1` / `-5-5` ids are disjoint on purpose: equal-specificity entries tie-break on list order.
- **Usage ledger rows recorded the *requested* service tier, not the one billed** (`app/utils/service_tier.py` (`note_call`, `billed_tier`, `clear_resolved_tier`, `normalize_tier`), `app/providers/{bedrock,nova_bedrock,openai_bedrock}.py`, `app/cost/meter.py`, `app/storage/usage_ledger.py` (`actualize(tier=)`), `app/streaming_tool_executor.py`, `scripts/usage_ledger_relabel_tier.py` (new), `tests/backend/test_cost_model.py` (+4)). The meter copied the Task Card run's `flex` request into the row at dispatch and never revisited it, but Bedrock rejects Flex for Claude and the provider retries at standard — so every Claude task row (18,673 in one two-week ledger) said `flex` while billed at standard, and because the pricer correctly refuses to price a tier the catalog has no factor for, all of them came back *unknown* even for models the catalog covers. Providers now report the tier a call ran at once it succeeds — the tier the service echoes (`x-amzn-bedrock-service-tier` / `serviceTier`), else the tier actually sent, else standard, with Bedrock's `default` normalised to the catalog's `standard` — through a ContextVar the meter reads when it actualises the row; async generators share their consumer's context, which is what makes the provider→executor hop work and is pinned by a test. The negative cache already set before the retry means the answer is right even when nothing is echoed. Existing rows are relabelled with the new script (dry-run by default, backs up the database first).
- **`reasoning_additive` pricing entries billed reasoning tokens as unpriced** (`app/cost/pricer.py`, one failing test in `tests/backend/test_cost_model.py` now passes). The Sep 11 commit with this title did not contain the change. When an entry opts into additive reasoning and lists no explicit `reasoning` rate, the tokens now bill at the output rate — the meaning of "billed as output tokens, on top of output" — in both the effective and the list-price branches.
- **Context-overflow estimates and the handoff nudge use the calibrated ratio, and a failed call records the provider's own count** (`app/utils/context_debug.py`, `app/utils/handoff_prelude.py`, `app/utils/token_calibrator.py` (`estimate_tokens_from_chars`), `tests/test_context_overflow_estimation.py` (new, 6), `tests/test_context_debug.py`). Conversation 793a72aa (2026-09-28) was rejected by Bedrock at 1,017,040 tokens > 1,000,000 while the debug panel showed the failed call as 509,517 "(est.)" and no handoff nudge had ever fired. Both numbers came from a hardcoded `chars // 4`: the model's learned ratio on line-numbered code is ~2.4 chars/token, and the ~168k tool-schema baseline is not in the messages at all, so the nudge read the payload as 51% of the limit right up to the failure. `estimate_messages_tokens` and `record_failure` now go through the calibrator (learned ratio for the model family plus measured baseline; `chars/4` only if the calibrator cannot load). A Bedrock "prompt is too long: N tokens > M maximum" rejection carries the real count and limit; `record_failure` parses them and records that figure with `is_estimated: false` instead of any estimate, so the panel agrees with the error beside it. The `_MAX_ITERATIONS_PER_CONVERSATION` test was updated to the per-request buffer it now tests.
- **A memory pause now recovers on its own** (`app/utils/memory_pause.py`, `app/agents/system_jobs.py`, `frontend/src/api/memoryApi.ts`, `frontend/src/components/MemoryBrowser.tsx`, `tests/test_memory_pause_on_infra.py` (+2), `Docs/ArchitectureOverview.md`). The pause written when a memory pass hits an infrastructure outage had no automatic recovery: a five-minute network blip silenced extraction, feedback and the lifecycle jobs until someone found the Resume button in the Memory Browser's Health tab. It is now a circuit breaker: after a probe wait (5 min, doubling per consecutive failure, capped at 1 h) the next entry point runs for real, success clears the pause, another outage re-arms it. Resume only skips the wait. The system prompt notice, banner and tooltip say so.
- **Auth-retry cleanup reaches the server, in-app link bounds check uses local state, plain-text auth classifier tightened** (`frontend/src/components/StreamedContent.tsx`, `frontend/src/components/ZiyaLinkNavigator.tsx`, `frontend/src/apis/chatApi.ts`). Retry after an auth banner removed the banner and the interrupted partial from React state only; bulk-sync never removes messages, so they came back on the next pull — both are now deleted through the message DELETE endpoint. A `ziya://chat//` click on a conversation already in state checks `n` against its (shell-aware) message count instead of skipping the check. A non-JSON SSE line containing the bare word `authentication` was classified as an auth error; it now needs the server's marker or an explicit expired-credential phrasing, and never a network-shaped line.
- **A network drop during credential refresh is no longer reported as expired credentials** (`app/utils/infra_errors.py`, `app/plugins/interfaces.py`, `app/server.py`, `app/streaming_tool_executor.py`, `app/utils/aws_utils.py`, `tests/test_infra_errors_credential_network.py` (new, 4)). ada's midway refresh failing on the network produces `CredentialRetrievalError: … failed to initialize iibs client: Request to IDP URL https://…`. The base `AuthProvider.is_auth_error` excluded that shape, but the enterprise auth plugin overrides the method with a bare indicator list (`credential`, its IdP host, `CredentialRetrievalError`) and the three core call sites trusted its answer, so a connectivity blip showed the "Authentication Required — run mwinit" banner in chat, and `infra_kind` (which matched `credential` before anything else) paused memory as `authentication_error`. The network exclusion now lives in `infra_errors.NETWORK_FAILURE_INDICATORS` and is applied by the core (`is_auth_failure`) *before* the provider is consulted, so a plugin override cannot bypass it; `infra_kind` reports `connection_error` for the same shape; the server's connectivity branch uses the same list. A genuinely expired token still classifies as auth. If memory is currently paused with `kind: authentication_error` from this, press **Resume memory** in the Health tab.
- **A repeated short prompt is no longer dropped from the conversation** (`frontend/src/utils/messageDedup.ts` (new), `frontend/src/context/ChatContext.tsx`, `frontend/src/utils/__tests__/messageDedup.test.ts` (new, 6)). `addMessageToConversation`'s DUPLICATE_GUARD skipped any message whose role+content already appeared anywhere in the conversation. Typing `applied` (or `yes`, `continue`) a second time was therefore dropped from state and never persisted, while the request still went to the model, leaving the record assistant→assistant with the human turn missing. The guard exists to break history-replay loops, and a replayed message carries the id (or at least the timestamp) of the original; a fresh submission carries neither. It now matches on the id a message *arrived* with, else treats identical role+content as a duplicate only when it is plausibly the same event: identical `_timestamp`, or the existing copy landed within 5 s (a double-submit). A retype minutes later is kept.
- **Memory tool results now actually render as a memory card** (`frontend/src/components/MemoryCard.tsx` (new), `frontend/src/utils/mcpFormatter.ts`, `frontend/src/components/MarkdownRenderer.tsx`). The 0.8.8.8 entry "Memory tool results render as a memory card instead of a raw JSON tool block" described code that never landed: the tests (`MemoryCard.test.tsx`, `mcpFormatterMemory.test.ts`, commit `b11953c7`) and the changelog line were written in 2026-09-22 conversation `fb407de1`, but the three frontend diffs from that turn were not applied, and the test commit's message asserted the component was "already at HEAD". 17 of the 18 committed tests had been failing since. The backend echo half (`memory_propose` / `memory_save` returning `content`/`layer`/`tags`) was re-done separately on 09-27. This entry lands the frontend half as designed then (A1: fixed teal accent, layer as a neutral chip, `LAYER_COLORS` deliberately unused), re-anchored to the current files; `ToolBlock` also now parses the Python-repr result with `parsePythonLiteral` before the lossy quote-swap fallback. All 18 tests pass under `craco test`.
- **The Memory Browser's Health tab now shows the review it fetches, and can resume a paused memory system** (`frontend/src/api/memoryApi.ts`, `frontend/src/components/MemoryBrowser.tsx`, `frontend/src/api/__tests__/memoryHealthHelpers.test.ts` (new, 8), `Docs/ArchitectureOverview.md`). `GET /api/v1/memory/review` returns `stale_memories` / `orphan_memories` / `large_nodes`; the tab read `stale` / `orphans` / `oversized_nodes`. Nothing renamed them, so every section rendered "all healthy", the Dashboard's "Needs Review" card read 0 and the orphan-threshold status line read 0 regardless of the store. `getReview` now normalises the payload at the one fetch site (`normalizeReview`) and the component hydrates the endpoint's slices (id, 100-char content, tags) from the full records it already holds (`hydrateReview`), since `MemoryCard` renders `layer`, `importance` and `last_accessed`, which the orphan entries lack. Separately, the Resume button promised by the memory-pause entry below is in: the Health tab loads `GET /api/v1/memory/pause`, shows ⏸ in its label and a warning banner (`memoryPauseLabel`: kind, passes that failed, time since, repeat count, raw error) with a **Resume memory** button calling `POST /api/v1/memory/resume`. All 8 new tests fail on the previous `memoryApi.ts` (the helpers did not exist).
- **Memory follow-ups: proposal lineage, tool echo, and part C behind a flag** (`app/storage/proposals.py`, `app/mcp/tools/memory_tools.py`, `app/storage/memory.py`, `app/utils/memory_collections.py`, `tests/test_memory_proposals_lineage.py` (new, 1), `tests/test_memory_node_tags_from_members.py` (new, 3), `tests/test_memory_mindmap_integrity.py`, `Docs/ArchitectureOverview.md`). (1) `ProposalsStore` projection now carries `target_memory_id` from `mark_promoted` and `archive_reason` from `mark_archived`; both were written to the event and dropped on read, which is why the cleanup restore had to match proposals by text. (2) `memory_save` and `memory_propose` echo `content`, `layer`, `tags` (and `pending_count` for propose) so the model can confirm what was stored; this makes the pre-existing `test_memory_tool_result_echo.py` pass. (3) Gravity-well part C, node tags derived from members instead of accreted, is implemented as repair pass 2d behind `MemoryStorage.NODE_TAGS_FROM_MEMBERS` (default off, so the frozen replay arms are unaffected): tags shared by ≥50% of a node's members (cap 12, `derive_tags` fallback). With it on, a 500-tag root collapses to its members' shared tag and `maybe_divide_node` can split it again; the replay measures it as an ablation before it is enabled. Docs no longer claim organize is not time-scheduled (the `memory_organize` job runs every 6 h).
- **Memory pauses on an infrastructure outage instead of guessing, and stays paused until a human resumes it** (`app/utils/infra_errors.py` (new), `app/utils/memory_pause.py` (new), `app/utils/memory_clock.py`, `app/services/model_resolver.py`, `app/services/embedding_service.py`, `app/memory/extractor.py`, `app/memory/feedback.py`, `app/memory/maintenance.py`, `app/agents/system_jobs.py`, `app/memory/prompt.py`, `app/api/memory.py`, `scripts/memory_replay/llmcache.py`, `tests/test_memory_pause_on_infra.py` (new, 6)). `app/memory` has 12 service-model call sites behind 34 `except Exception` handlers whose documented fallbacks are permissive: contradiction classify → AGREES, comparison → ADD, extraction → nothing, embedding `None` → no dedup. So in the hours between a credential expiring and the next `mwinit`, or on a dropped connection, the store kept changing on answers nobody gave, the domain clock counted sessions that never ran, and the log said `warning`. The replay harness's cache-poisoning bug (entry below) was a copy of this behaviour. Now one classifier (`infra_errors.is_infra_error`, shared with the task system's `infra_kind` vocabulary and the replay harness) decides what is an outage; `call_service_model` and `BedrockTitanProvider.embed_text` raise `ServiceInfraError` for it, a `BaseException` so every fail-open handler passes it through to the subsystem entry point. The entry points (post-stream extraction, retrieval feedback, post-save maintenance, the lifecycle and organize jobs) abandon the pass with nothing recorded, undo the session tick, and write `~/.ziya/memory/paused.json`. While that file exists they return `{"skipped": true, "reason": "memory_paused"}` without calling anything, the system jobs' gates decline, and the system prompt carries a one-line notice. `GET /api/v1/memory/pause` reports it; `POST /api/v1/memory/resume` clears it, the next turn extracts normally and the lifecycle job's next tick catches up. No automatic recovery by design: memory's failure mode is silent, so off-until-confirmed is the safe default. Genuine model-side failures are unchanged. Consequence for task cards: an outage inside a task-level service-model call (until/improve evaluators) now surfaces as an infra hold rather than a silent "condition not met". The Health-tab Resume button landed in the entry above. The outage test checks the store is byte-identical to before the turn and the clock unchanged; 5 of 6 new tests fail on the previous code.
- **The memory replay no longer records network or credential outages as model answers, and a chunk that dies early keeps its work** (`scripts/memory_replay/llmcache.py`, `scripts/memory_replay/engine.py`, `scripts/memory_replay/reset_contaminated.py` (new), `tests/test_memory_replay_infra_outage.py` (new, 6)). The replay's model-call cache stored any failure that survived three quick retries as an `error` entry and replayed it indefinitely. It also stored embedding calls that returned `None` (which the live provider does only when the call fails) as "no embedding". On 2026-09-27 a credential expiry (07:54) and a train dropout (18:36) left 21 `CredentialRetrievalError` entries and 4 `none` embeddings, which were served to every arm sharing the namespace. The memory code fails open on both (contradiction check → AGREES, no embedding → no dedup), so those runs silently took the network-down path, and the engine's error counter stayed at `{}`. Infrastructure failures (credential, connection, timeout and throttling errors, matched by type and message, and `None` embeddings) are now never cached. Each call waits the outage out for up to `--infra-wait-s` (default 900 s), then raises `ReplayInfraError`, a `BaseException` so fail-open handlers cannot swallow it. It is also counted, so an outage inside a background task stops the chunk too. The engine then exits 5 **without** checkpointing the half-finished event, and `--resume` continues from the last clean checkpoint. Genuine model-side failures are still cached, which keeps strict replays deterministic. Entries recorded as outages by the old code are dropped on read. The engine now also checkpoints every `--checkpoint-every-s` (default 300 s) as well as every 200 events: a chunk that ended before its first 200-event checkpoint used to lose everything, and `sep-current` went through three chunks that way. `reset_contaminated.py` reports and purges outage entries and quarantines runs that consumed them; it refuses a run whose engine still holds the lock. The outage-and-resume test checks that the resumed store is byte-identical to a clean run paused at the same point; 5 of the 6 new tests fail on the previous harness for behavioural reasons.
- **A task-card run launched without an `X-Project-Root` header now works in its project's directory** (`app/api/task_cards.py`, `app/utils/launch_root.py` (new), `tests/test_task_launch_root_fallback.py` (new, 3)). `_launch_run_for_card`, which every launch path goes through (resume, continue, `task_card_launch`, commands, bindings), took the run's root only from the request header. A caller that sends none, such as a script, `curl` or a model tool call, got `None`, and the run's tasks resolved paths against the server process's cwd. On 2026-09-27 a resume of the memory-replay card (run `ecf5fa24`) launched that way ran in a different repository and reported the card's own scripts absent. A missing header now falls back to the project record's `path` when that directory exists; an explicit header still wins. The headerless-launch test fails on the previous code.
- **A loop nested in a for_each iteration no longer blanks `{{item}}`, and parallel iterations are told what they own** (`app/agents/block_executor.py`, `app/agents/task_executor.py`, `app/context.py`, `app/utils/fanout_notice.py` (new), `scripts/memory_replay/engine.py`, `tests/test_nested_loop_item_inheritance.py` (new, 5), `tests/test_parallel_fanout_ownership.py` (new, 3), `tests/test_memory_replay_run_lock.py` (new, 2)). On the memory-replay card (run `8c5deca5`, 2026-09-27) an iteration that owned `sep-current-aa` advanced `sep-baseline` instead. The root cause was not the agent: the fan-out's body was an Until, and both Until and a nested count Repeat pushed bindings with `item=None`, shadowing the enclosing item, so every task under them was told "Run id: ." and picked a run itself. The Until's `until_condition` ("run {{item}} reached…") was also passed to the evaluator unrendered. Nested loops now inherit the enclosing item and the condition is rendered against the enclosing bindings. Separately, every Task under a parallel iteration (however deeply nested) gets a system-prompt notice naming its own item and its concurrently running peers' items, telling it not to act on them; the descriptor rides the iteration context and survives nested loops, and the context keeps its old shape outside a fan-out. The replay engine also takes an exclusive `flock` on its run directory and exits 4, naming the holder, if a second engine tries to advance the same run. All three behaviour tests fail on the previous code.
- **Resuming a fan-out that held on an infrastructure fault no longer treats its cancelled peers as finished** (`app/agents/block_executor.py`, `app/api/task_runs.py`, `app/utils/resume_targets.py`, `tests/test_resume_gate_cancelled_siblings.py` (new, 5)). When one iteration of a parallel loop hits an infra fault, the gate cancels the other running iterations, and the executor synthesizes a deliberately non-failed artifact for each one. `_record_iteration` knew only `failed` / `passed`, so those peers were persisted as **passed**. `parallel_replay_indices` banks passed iterations, so "retry from" re-ran only the iteration that faulted and replayed the killed peers as done. On the memory-replay card (run `daf6eedd` → `8c5deca5`, 2026-09-27), 2 of 3 replay runs therefore never executed: one had been stopped at event 149 of 2,149 and the other had not started. The persisted status is now `cancelled` (already a valid `IterationStatus`), derived from the artifact so no caller or test double changes signature. The resume launcher also refuses to bank the cancellation marker, whether it comes from a source's legacy `passed` record or is carried forward by a resume chain, so runs already in this state resume correctly. Existing tests replaced `_record_iteration` and checked only `artifact.failed`; the new tests use the real recorder, the real banking function and the real `resume-from` route, and all three seam tests fail on the previous code.
- **Memory cleanup merges can no longer fuse distinct facts into one memory** (`app/memory/organizer.py`, `scripts/split_fused_memories.py` (new), `tests/test_memory_merge_bound.py` (new, 6)). One memory on a live store had grown to 2,777 chars and 146 tags. It held ~15 unrelated facts plus test-bench state (which rigs were up or down), and that state reached every prompt in that project. Extraction caps content at 500 chars and 4 tags, and the only path that concatenates is `cleanup_corpus`. That path wrote the service model's (Nova Lite) `merged_content` verbatim and unioned tags without a cap. Because the merged memory re-entered every later ~6-hourly batch, it kept absorbing (~10 merges per run in `organize_history.json`). A merge now applies only when its result is at most 500 chars and at most 1.2× the longer input. The tag union is capped at `max(6, keep's count)`. The prompt states that two different facts about one subject are not duplicates. A rejected merge leaves both memories active and is counted as `merges_rejected`. `scripts/split_fused_memories.py` repairs memories that already grew. The service model splits each into atomic facts and marks as droppable anything true only now or only of one rig (up/down state, bench topology, schedules, task status). Kept parts go through `extractor.quality_gate`, and the original is archived with `archive_reason: split_into:`. `--model` overrides the service model for the run. Nova Lite self-graded every part 1.0 and copied fragments verbatim, while Sonnet 4.6 resolved references and dropped all three rig-specific facts. Applied to that memory on the live store (13 parts kept, 3 dropped). The 3 merge-bound tests fail against the unbounded organizer. ~19 other active memories remain over 500 chars; run the script in dry-run mode to review them.
- **Deleted, resubmitted and edited messages no longer come back** (`frontend/src/context/ChatContext.tsx`, `frontend/src/context/ActiveChatContext.tsx`, `frontend/src/components/Conversation.tsx`, `frontend/src/components/EditSection.tsx`, `frontend/src/utils/syncMerge.ts`, `frontend/src/context/__tests__/removeMessagePersistsWiring.test.ts` (new, 4), `frontend/src/context/__tests__/replaceMessagesPersistsWiring.test.ts` (new, 6), `frontend/src/utils/__tests__/syncMergeTombstones.test.ts` (new, 12)). Deleting a muted message made it disappear and then reappear. The delete button, resubmit, edit-in-place and edit-and-resubmit all changed React state and sent the right server call, but none of them wrote to IndexedDB. IDB kept the old list, and every path that reads it back (sync shells, hydration, cross-tab reload, reopening the chat) restored it. The console shows this as `POST_SYNC: Re-hydrated active conversation with 3 messages`, followed by `msg-count divergence (local=3 server=2) — pushing` on every sync cycle, where the server's tombstone dropped the push each time. New `removeMessage` and `replaceMessages` in ChatContext update state and IDB together (`queueSave`, `_version` bump), and all four call sites use them. They also record removed message ids in the same `_deletedMessages` field the server uses; the server never takes that field from a client. That fixes a count guard that could not tell a deliberate shrink from a stale copy: `decideCrossTabMerge` kept tab B's longer list after tab A deleted a message, so tab B wrote the message back on its next save. It now adopts a shorter remote list only when every missing message is tombstoned; any other shortfall still keeps local. `shouldFetchFull` also now pulls again when the server record is newer and shorter, even if it was already fetched this session, so a delete made in another browser settles instead of looping. 8 of the 12 tombstone tests fail against the `HEAD` `syncMerge.ts`; the other 4 are controls (stale copy still kept, streaming never adopts remote messages, equal counts still skip, unknown count is not treated as a shrink).
- **Stale server-only chats titled "New Conversation" are no longer deleted from the server when they have messages; dead full-body merge branches removed** (`frontend/src/utils/syncMerge.ts`, `frontend/src/context/ChatContext.tsx`, `frontend/src/utils/__tests__/syncMerge.test.ts`, `forkLineage.test.ts`, `syncHydrationTargets.test.ts`, `syncMergeTombstones.test.ts`, `Docs/ArchitectureOverview.md`). `mergeServerChat` took a `full` body argument that its only call site always passed as `undefined` (`fullFetchMap` was created and never filled; bodies arrive through bulk hydration). Its `full` branches, including the message-count `SYNC_GUARD`, never ran, and 9 tests covered only them. They are removed along with the parameter. The dead argument also decided emptiness: `isEmptyShell` checked `full.messages`, so it reduced to `title === 'New Conversation'`, and any chat that existed only on the server, still had the placeholder title and was over an hour old was queued for the server-side empty-shell GC delete, whatever it held. The existing tests asserted exactly that (their summary said `messageCount: 4`). Emptiness now comes from the summary's `messageCount === 0`; an unknown count is not empty. Two new regression tests: a stale "New Conversation" with messages is kept as a shell and not delete-eligible, and one with no count is kept.
- **Memory cleanup reviews each memory once, with hard limits in code** (`app/memory/organizer.py`, `tests/test_memory_cleanup_once.py` (new, 5), `Docs/ArchitectureOverview.md`). The `memory_organize` system job runs about every 6 hours whenever any orphan memory exists (217 runs on the live store by 2026-09-26), and each run started with `cleanup_corpus` over the entire corpus. So every memory went before the LLM judge about four times a day indefinitely, and even a low false-positive rate compounded: one project's memories fell from 172 to 48 between 09-22 and 09-26. Now a memory the judge keeps is stamped `cleanup_reviewed_at` and never re-reviewed, and a failed model call stamps nothing. `decision` and `negative_constraint` memories are never removed as junk and are absorbed only into a memory of the same layer; ids outside the batch are ignored; at most 25% of a batch (rounded up) is removed per call. The prompt no longer invites removing facts the model "suspects are outdated", only text that says it is time-bound. All 481 active memories on the live store were stamped as reviewed, since each had already been judged about 200 times. Duplicates between a new memory and an already-reviewed one are no longer caught here; extraction's embedding dedup still catches paraphrases.
- **Probationary memories age only with work in their own domain** (`app/utils/memory_clock.py` (new), `app/memory/lifecycle.py`, `app/memory/extractor.py`, `app/mcp/tools/memory_tools.py`, `app/api/memory.py`, `tests/test_memory_domain_clock.py` (new, 9), `Docs/ArchitectureOverview.md`). The activity counter was global and advanced on every streamed response in every project. On the live store (2026-09-24..26) that was ~44 ticks per active day, 85% of them from Ziya projects, so `ARCHIVAL_AGE_THRESHOLD`=7 meant about four hours of any work, and a proposal from another project, made on a Ziya-heavy day, decayed before a conversation in that project could confirm it. Now each project has a clock that advances at most once per (conversation, day). Extraction ticks it, and every proposal is stamped with a snapshot of all clocks. The lifecycle hands its evaluators `activity_count_at_proposal + sessions since the stamp across the proposal's collection`, so the promotion and archival rules and thresholds are unchanged but measured in domain sessions. Proposals with no project use the global session count. A proposal whose domain has had no session for 90 days archives as `dormant`. Unstamped proposals keep the global counter. `GET /api/v1/memory/proposals` now computes `age`, `expires_in` and `would_promote` with the same counter; `would_promote` was always false for fast-track promotions because the counter was never passed. The anchor test drives `run_lifecycle_pass`: a project-B proposal survives 50 project-A sessions (archived as `decayed` on the previous code) and decays after 7 project-B sessions. On the live store all 564 open proposals were stamped and their legacy age reset to 0.
- **Memories lost to the cleanup hard-delete can be re-queued for reprocessing** (`scripts/requeue_lost_memories.py` (new), `scripts/grade_requeued_proposals.py` (new), `tests/test_grade_requeued_proposals.py` (new, 4)). The grading script asks the memory service model for the extraction prompt's three self-grades and runs them through `extractor.quality_gate` unchanged, writing the result into each proposal's canonical `record` event so the lifecycle's own fast track sees it (the anchor test goes through `ProposalsStore` and `_evaluate_promotion`). On the live store it graded all 655 re-queued audit texts: the gate rejected 112, and 104 are fast-track eligible (31 of the 334 from one project). The rest are in non-fast-track layers (mostly `domain_context`) or graded 0.7 against the 0.75 threshold, so they still decay unless corroborated or used. Collects text that is not live (exactly, or ≥0.6 token containment), not already an open proposal, and not duplicated across sources, from two places: promoted rows in `probationary.jsonl` (kept with their layer, tags, scope and quality grade) and `memory_propose`/`memory_save` arguments in `~/.ziya/audit/tool_audit_*.jsonl` (scope recovered from the conversation's project; quality left unset, as `memory_propose` creates it). Everything re-enters as an open proposal at the current activity counter, so the lifecycle judges it again instead of restoring earlier verdicts as facts. It writes all events in one read-modify-write, because `ProposalsStore`'s lock is per-process. Dry run by default. A proposal id is a content hash and the projection keeps the first `record` for an id, so a text that already had a terminal row has to be reopened with a `status: open` event; that event keeps the row's original activity stamp. On the live store (2026-09-26): 655 audit-log texts re-queued (about 335 from one project), and 147 graded proposal-log rows reopened, all eligible for the fast track on the next lifecycle pass. 7 audit texts whose ids had already been archived were left alone.
- **Memory cleanup archives instead of deleting; placement gates on inferred collections and splits foreign groups out of a node; "Run Maintenance" runs repair** (`app/memory/organizer.py`, `app/storage/memory.py`, `app/api/memory.py`, `app/utils/memory_collections.py` (new), `scripts/restore_cleanup_deleted_memories.py` (new), `tests/test_memory_collections.py` (new, 13), `tests/test_memory_organizer_well.py` (new, 4), `tests/test_api_memory_maintenance_repair.py` (new, 1), `tests/test_memory_organizer.py`, `tests/test_memory_mindmap_integrity.py`, `Docs/ArchitectureOverview.md`). Follow-up to the entry below, which made things worse on the live store: gating on the raw project path judged a topic spread across three repos (18.6%/2.7%/1.8% of its root) incompatible with its own node, while `ziya-0.4.0.1` at 54% passed, so the root's Ziya share rose from 65% to 77%. (1) **Cleanup data loss.** `cleanup_corpus` runs about every six hours and called `store.delete` on everything an LLM batch flagged, throwing away the reason. On 2026-09-25..26 it removed 89 memories and merged 33. Sampling the deleted set found mostly durable decisions, install and security constraints, and 31 negative constraints. Removals and merge absorptions now set `status: archived` with `archive_reason`, which is equally invisible to the model but recoverable. `scripts/restore_cleanup_deleted_memories.py` finds deleted memories whose text survives in promoted probationary rows (not live, and not merged into a survivor by ≥0.6 token containment) and restores them through the API with their scope: 148 on the live store, dry run by default. (2) **Collections.** Projects whose memories co-locate in small nodes are inferred to be one collection (min-count weight ≥2 over nodes of ≤12 members, each project holding ≥25% of the node). This was verified on the live store, where it produced {ziya, ZiyaInternal} and {repo-c} and kept one-memory strays from fusing them. Placement compatibility and the rebalance use collection share. (3) **Split.** New repair pass 2c moves a group of ≥2 members whose collection is not the node's owner (the plurality of its descendants, else of its members) only when the group outnumbers the owner's own members there: to a tag-matching node that collection owns, or into a new root built from the group's tags. The catch-all `domain_general` is never a rebalance or split destination. A first version split every foreign group, which on the live store would have moved two sibling repos' memories out of their topic (collection inference cannot tie them to the third repo, since they never share a small node), and the rebalance would have pulled one of them into the catch-all; `TestLiveTopicLayout` reproduces those counts and fails on that version. On a copy of the live store all 48 of that topic's memories stay on its nodes, 3 strays return from Ziya nodes, the 47 Ziya memories leave its root (64 → 20), and a fourth repair makes no moves. (4) A child is scored only on tags its parent lacks, because cell division copies parent tags onto children and they were pulling generic memories into arbitrary children. (5) `_find_matching_node` scales tag overlap by `sqrt(|domain tags|/|node tags|)`, closing the organizer's own route into the well. (6) `POST /api/v1/memory/maintenance` now runs `repair_mindmap` first and returns its counts as `repaired`. 6 of the new behaviour tests fail on the previous code. Still open: node tags still only accrete (that root keeps 513); the handle of a split-out root is machine-made from tags; cleanup's aggressiveness itself is unchanged; the proposals projection drops `target_memory_id`.
- **Mind-map placement no longer rewards mass; misplaced memories migrate out on repair** (`app/storage/memory.py`, `tests/test_memory_mindmap_placement.py` (new, 13), `tests/test_memory_mindmap_integrity.py`, `Docs/ArchitectureOverview.md`). The live store (2026-09-25) had one root holding 145 of 252 memories with a 509-tag tag set (next largest: 68), and 65% of its members came from a project with a dozen roots of its own. Three mechanisms fed each other: `place_memory_in_mindmap` scored raw `|mem ∩ node|`, which is monotone in node size; node tags only ever accreted (every organizer/merge/enrichment path unions, nothing prunes); and `maybe_divide_node` excludes any split tag already on the parent, so a 509-tag parent could not divide. Provenance (`scope.project_paths`, set on every memory) was never consulted. Now the score is `overlap / sqrt(|node_tags|)`, so mass is a cost; and placement prefers nodes whose members share the memory's project (≥20% share), falling back to the best topical node when none is compatible so a project's first memory still lands. `repair_mindmap` gained a rebalance pass (`rebalanced` in its result) that moves a placed memory when its node is provenance-incompatible or a compatible node out-scores it by ≥2× — near-ties stay put so it does not churn organizer placement, and memories with no tag overlap to their node (organizer-placed) move only on provenance. 10 of the 13 new tests fail against the raw-overlap placer; the other three are positive controls the old and new code agree on. Not yet done: deriving node tags from member frequency instead of accreting them, which is what would let cell division bite on a fat root.
- **Message edits and deletes now reach the server, and a tab that missed an answer can no longer overwrite it** (`app/utils/chat_message_ops.py` (new), `app/api/chats.py`, `frontend/src/api/conversationSyncApi.ts`, `frontend/src/components/Conversation.tsx`, `frontend/src/components/EditSection.tsx`, `tests/test_chat_message_ops.py` (new, 18), `tests/test_chat_message_endpoints.py` (new, 11), `frontend/src/api/__tests__/messageOps.test.ts` (new, 10), `tests/test_api_chats.py`). An audit found no server endpoint for truncating, deleting or editing a message. All three shrink actions (edit and resubmit, resubmit, delete a muted or unanswered message) changed only the browser's copy and relied on bulk-sync. bulk-sync blocked any push that lowered the message count while still accepting the push's newer `_version`, so the disk record kept the pre-edit history and looked newer than the browser. Neither side noticed the disagreement. Every server-side reader saw the old history: another browser, `chat_search`/`chat_read`, handoff documents, memory extraction and export. Separately, bulk-sync replaced `messages` wholesale whenever the count did not drop. A tab holding `[… q2]` that never received `a2`, whose user then asked `q3`, pushed the same count and silently overwrote `a2`. The fix: new `POST /chats/{id}/rewind`, `DELETE /chats/{id}/messages/{mid}` and `PATCH /chats/{id}/messages/{mid}` endpoints, which the frontend now calls. Resubmit and edit await the rewind before starting the new turn. bulk-sync now merges by message id: it adds messages it hasn't seen, placed after any server messages the client missed; takes client-owned metadata (mute, feedback flags); and never removes a message or changes its content. That replaces the count and content-length guards. Removed messages are tombstoned so a stale tab cannot resurrect them. Legacy local messages without an id (which got a fresh random id on every push) are matched by content and adopt the server id, and the version bump makes the client pick those ids up. Record read-modify-writes now hold a file lock, since two servers can share `~/.ziya`. The seam tests reproduce both defects against the unpatched router and fail there (10 of 11; the eleventh is the positive control for a normal append); `test_message_regression_blocked_even_for_tiny_conversations` now asserts the originals are kept *and* the unseen pushed message is added. First step of "Turn authorship" in `design/conversation-single-writer.md`, the prerequisite for server-authored turns and model-spawned subthreads.
- **Shell: the read-only git tier no longer admits `--output=`, which let nine "read-only" commands write or overwrite any file** (`app/mcp_servers/shell_server.py` (`_GIT_NO_OUTPUT_FILE`, `_refuse_output_file`, applied to every `git_patterns` entry), `tests/test_shell_git_no_output_file.py` (new, 31)). `--output` is a diff/revision option. Probed against real git, `diff`, `log`, `show`, `whatchanged`, `rev-list`, `shortlog`, `reflog`, `blame` and `stash list` all wrote the named path, including over an untracked file. Git accepts neither abbreviations nor a short form, so rejecting a literal `--output` (not followed by `-`, which keeps `--output-indicator-*`) anywhere in the segment closes it, quoted forms included. The guard is applied in the pattern-table loop, so an op added later inherits it. Collateral: a `git grep` / `--grep` search for the literal text `--output` is refused. Flagged 2026-09-10, fixed now.
- **Diff apply: fuzzy position search crashed on its own debug log line, taking down the hybrid-forced fallback stage** (`app/utils/diff_utils/application/fuzzy_match.py`, `tests/test_fuzzy_match_debug_format.py` (new, 2)). `calculate_enhanced_similarity` appends a ratio only for the strategies that apply, then logged them by fixed name as `{ratios[i] if len(ratios) > i else 'N/A':.3f}`. The f-string is evaluated at every log level, and `'N/A'` can't take `:.3f`, so any search window where a whitespace-dependent strategy was skipped raised `ValueError: Unknown format code 'f' for object of type 'str'`. A blank line under a one-line hunk is enough. The only caller is the hybrid-forced difflib stage, which then failed the whole apply. The line now logs the applicable ratios as a list, only when debug is enabled. The old per-name labels were also wrong whenever a strategy was skipped, because the list positions shift.
- **Undo of a zero-context deletion put the line back one position early and reported success** (`app/utils/diff_utils/pipeline/reverse_pipeline.py` `_try_patch_reverse`, `app/utils/diff_utils/core/diff_reverser.py` `reverse_diff`, `tests/test_diff_reverse_zero_context.py` (new, 9), `tests/test_diff_unterminated_final_line.py` (reverse assertion tightened to byte-equality)). `git diff -U0` writes a deletion of line 3 as `@@ -3 +2,0 @@`. Apple `patch -R` re-inserts it after line 1 and exits 0. `/api/unapply-changes` calls the reverse pipeline with no `expected_content`, so Stage 1's output was accepted unverified. The reverse fixture runner could never catch this, because it always passes the expected content and so rejects Stage 1's wrong output. When a hunk's new side is empty, Stage 1 now reverses the diff text itself and applies it with forward `patch`, which places that shape correctly. All other diffs keep `patch -R`. A second defect sat in the same path: `reverse_diff` matched only `-a,b +c,d` and `-a +c` headers, so mixed forms such as `-3 +2,0` were left unswapped. That affected Stages 3–4 too. One pattern now covers all four forms. Fixture suites were unchanged in all three modes (normal 151/167, `--force-difflib` 138/167, `--reverse` 132/162, row-identical to the pre-fix baseline).
- **`test_file_state_tracking::test_declined_diff_scenario` had failed since it was written** (`app/utils/tests/test_file_state_tracking.py`). It stripped the `[NNN ] ` annotation prefix with `line[6:]`, but the prefix is 7 characters (the format the system prompt documents, unchanged since 2025-02), so every line kept a leading space. The test now strips the prefix by pattern and checks that each line carries it. `get_annotated_content` was correct.
- **Diff apply: a diff whose text ends without a newline no longer fuses its last line with the next line of the file while reporting success** (`app/utils/diff_utils/core/text_normalization.py` (`terminate_diff_text` new), called at the top of `apply_diff_pipeline` (`pipeline/pipeline_manager.py`), `apply_reverse_diff_pipeline` (`pipeline/reverse_pipeline.py`) and the CLI's `apply_diff_atomically` (`application/git_diff.py`); `tests/diff_test_cases/MRE_unterminated_final_add_joins_next_line/` (new fixture, `apply_twice`), `tests/test_diff_unterminated_final_line.py` (new, 8)). Incident (2026-09-24): a zero-context two-hunk diff to `pyproject.toml`, applied from a chat fence whose body had lost its final newline, produced `keywords = [...]classifiers = [` on one line. Poetry could no longer parse the file, and the pipeline had reported success. Cause: the system `patch` stage reads an unterminated final `+` line as "this line has no newline" even when it replaces a line in the middle of the file, then exits 0. It is the patch stage specifically, because the same fixture passes with `--force-difflib` on unpatched code. In unified-diff format a missing newline is expressed only by an explicit `\ No newline at end of file` marker, so a diff text with no final newline carries no meaning. Every public entry point now terminates it before any stage sees it. The explicit-marker case at true EOF is still honoured (control test). The reverse (undo) path has the mirror-image hazard: an unterminated final `-` line is written without its newline, giving `legacy = truename = "x"`. An unterminated final `+` line does not affect undo, since it's only matched. The tests cover both. Verified against real HEAD, not only by monkeypatching the helper: the fixture suite went from 150/167 to 151/167, with the only change being the new case passing and the 16 pre-existing failures identical before and after. The change cannot alter any other fixture in any mode, because the new case is the only one of 162 whose `changes.diff` lacks a final newline. Found in passing, not fixed here: undoing a zero-context deletion hunk (`@@ -3 +2,0 @@`) reinserts the line one position early and still reports success, independent of the trailing newline.
- **Parroted replay envelopes were invisible to every hallucination layer** (`app/text_delta_processor.py`, `app/utils/tool_history_rewrite.py`, `tests/test_text_delta_processor.py` (+4), `tests/test_tool_history_rewrite.py` (+4)). The tool-history rewrite re-encodes prior tool results for the model as a U+2039-bracketed `tool_result` envelope, and stripped the `|🔐` badge so the replay would stop teaching the old fence shape — but no detector was ever taught the new shape. In a live session the model emitted six such envelopes with invented bodies (a fabricated Jira 400, a "file write" whose body was the file content, a tool that does not exist) and nothing fired: the RAW layer only knew `TOOL_MARKER`, the BACKEND layer keyed on the very badge the rewrite removes, Layers B/C require a fenced block, and the fabrication was then replayed verbatim on the next turn as accepted history. A line-initial envelope opener/closer (U+2039 or its Latin-1 mojibake, which appeared in the sample) is now a RAW fabrication signature — abort, strip the contaminated paragraph, retry — anchored to line start so unified-diff body lines never match. The rewrite also defangs envelope lookalikes in bare assistant prose, not just inside real block bodies, so a persisted fabrication is neutralised before it reaches the model. Consequence: the rewrite is deliberately no longer idempotent (a bare envelope is never legitimate input); the old idempotency test was vacuous anyway — its fence was mid-line and never parsed.
- **`file_write` patch results rendered as a raw diff on re-render, in the wrong colours** (`frontend/src/utils/mcpFormatter.ts`, `frontend/src/apis/chatApi.ts`, `frontend/src/components/MarkdownRenderer.tsx`, `frontend/src/styles/toolDiffApplied.css` (new), `frontend/src/utils/__tests__/mcpFormatterFileWrite.test.ts` (+4)). The formatter synthesises a unified diff for a patch-mode write and flags it `renderAs: 'diff'`, but chatApi persists only the diff text (flag dropped, fence syntax left as the file's language). On reload the formatter received a non-JSON string, fell through as plain text, and Prism highlighted the diff as Python/TSX. It now recognises its own diff shape and routes it back to the diff renderer, and the persisted fence is tagged `diff`. Because every diff in a tool block has already been written, `ToolDiffPreview` now renders in a neutral grey/slate palette with an "already written to disk — nothing to apply" caption instead of the red/green used for diffs the user is still being asked to apply.
- **A lazily loaded modal that fails to load no longer takes down the app** (`frontend/src/components/App.tsx` (`LazyChunkBoundary`, `isChunkFailure`)). When the code-split chunk for the Shell Configuration, MCP Status or MCP Registry modal failed to load and the recovery reload in `lazyWithRetry.ts` never landed, the rejection climbed to `RootErrorBoundary` and pressing the button blanked the whole page. A boundary around those modals now catches only chunk-load failures, shows the error as a message, and resets the modal's open flag so the button works again; any other error propagates as before.

### Changed
- **Until blocks record why the judge said no, and tell the next iteration** (`app/agents/until_evaluator.py` (`UntilVerdict`, `evaluate_condition_verdict`, `parse_verdict`; two-line reply, `max_tokens` 4 → 160), `app/agents/block_executor.py` (`_execute_until`: `until_evaluated` event, per-iteration decisions, exhaustion decision carries the last reason, `signature="until_condition_unmet"`, `_until_output_signature`, unreachable-condition exit; `_build_iteration_context`), `app/agents/task_templating.py` (`{{until.condition}}`, `{{until.last_rationale}}`), `app/utils/task_run_read.py` (`until_evaluated` is a verdict event; `failure_reason_of` reads the signature); tests `tests/test_until_rationale_feedback.py` (new, 19); `Docs/Capabilities.md`). Run 7dfb90f6 (2026-10-10): an Until's three iterations all passed, the evaluator answered "no" three times, and the block failed with `failure_reason: "failed"` — the evaluator was capped at 4 output tokens so it could not say why, nothing recorded its verdict, and the body re-did the same work each pass because it was never told what the judge objected to. The evaluator now returns a one-sentence reason with its verdict; the executor emits `until_evaluated {index, satisfied, rationale}`, records each verdict as a block decision, puts the last reason in the exhaustion decision (so `task_run_read` reports it as the block's `failure_reason`), and prepends it to the next iteration's instructions. An iteration that was given the reason and handed back an identical pass (summary, decisions, data parts and files unchanged) ends the loop early as `condition unreachable` instead of burning `until_max`; that rule needs both halves, so a repeated summary alone still never ends an explicitly-conditioned loop (the stall-breaker contract is unchanged).
- **The commit message in a `git` approval panel is editable** (`app/utils/consent_gate.py` (`editable_args`, `sanitize_edits`), `app/utils/consent_ledger.py` (`make_answer(edits=)`), `app/api/consent.py`, `app/tool_execution.py`, `app/mcp/tools/git_tool.py` (`consent_editable_args`), `frontend/src/components/ConsentPreflight.tsx`, `frontend/src/components/ConsentPanel.tsx`, `frontend/src/utils/consentStore.ts`; tests `tests/test_consent_arg_edits.py` (new, 6), `ConsentPreflight.test.tsx`, `ConsentPanel.test.tsx`). A tool lists `consent_editable_args = {op: (arg, ...)}`; the panel renders those preflight blocks as text boxes, and Approve sends the changed values. The API refuses (422) an edit to an argument the request did not list or longer than 20,000 characters, the gate re-filters, and the call runs with the human's text for that call only (a standing grant never carries edits). The model's result carries `edited_by_user`. For git: `commit`, `stash` and `stash_push` messages. Approve is disabled while an edited message is blank.
- **`git` tool commits no longer credit a fake `ziya@noreply.invalid` co-author** (`app/utils/git_ops.py` (`provenance_line`, `with_provenance`), `tests/test_git_ops.py`). The two trailers `Co-authored-by: Ziya ` and `Ziya-Model: ` are replaced by one line, `Co-authored-by: Ziya v (/)`, e.g. `Co-authored-by: Ziya v0.8.10.0 (opus5.5/bedrock)`. Hosts showed the placeholder address as an unknown co-author. Parts that can't be determined are left out. `ZIYA_GIT_PROVENANCE_TRAILER=false` still disables the trailer.
- **Test fixtures, prompts and design notes no longer carry one investigation's data** (`tests/test_analyze_ledger_acceptance.py` (new, 5; replaces three scripts and two tests that read evidence outside the repository), `app/utils/output_schemas/finding_v1.json`, `frontend/src/components/TaskCard/FindingCard.tsx`, `app/utils/analytics/analyze.py`, `app/data/built_in_skills.py`, `app/memory/extractor.py`, `design/*.md`, ~40 test files). The analytics, evidence-ledger and output-contract work was accepted against a real operational investigation, and its vocabulary, table names, figures and account identifiers had spread into shipped prompts, the finding schema and fixtures. The finding schema's `per_ct` / `incidents_per_ct_day` / `per_ct_sum` fields are now `per_unit` / `incidents_per_unit_day` / `per_unit_sum` (the schema had not been published; no migration), the `analyze` entity heuristic no longer special-cases a `ct` prefix, and every fixture uses invented values. The same pass covered already-committed files: ~45 tests, `app/utils/memory_collections.py` comments, `scripts/memory_replay/metrics.py` (the reporting-group map was hard-coded to two internal project names; it now defaults to `ziya`/`other` and takes extra groups from `ZIYA_REPLAY_GROUPS="name=prefix,prefix;…"`), `design/{capabilities-hub,memory-replay,structured-memory-system}.md`, and user paths and aliases in test fixtures.
- **The first mid-turn Context Size Notice now fires at 85% of the model's input limit instead of 75%** (`app/streaming_tool_executor.py`, `_handle_usage_event`; `tests/test_context_size_notice_tiers.py` (new, 4)). Tiers are now 85% / 90% / 95%, each still firing once per turn. At 75% the model was told to start wrapping up while a quarter of the window was still free, which cut investigations short with no risk of an input-limit failure. The iteration-budget tiers (75/90/95/99% of iterations) are unchanged.
- **Tool results in the chat are built by one shared function, ready for server-saved turns** (`frontend/src/utils/renderToolPart.ts` (new), `frontend/src/apis/chatApi.ts`, `frontend/src/utils/types.ts`, `app/utils/chat_message_ops.py`, `frontend/src/utils/__tests__/renderToolPart.test.ts` (new, 9), `tests/test_chat_message_ops.py`). No visible change. The code in `chatApi.ts`'s `tool_display` handler that turns a tool result into the rendered block (header, `$ cmd` line, 🔐 verified mark, formatter, fence or `TOOL_BLOCK` markers, inline image) is moved into `renderToolPart(part, contentSoFar)`, and the live stream now builds a `ToolPart` from the event and calls it. The live-only placeholder splice stays in `chatApi.ts`. This is step 1 of "save facts, render at display time" in `design/conversation-single-writer.md`: the server will save an assistant turn as `parts`, and the saved-message renderer will call the same function, so a message is identical live and after reload by construction. During extraction the function was compared with the verbatim original across 95 event and preceding-text combinations and matched on all of them; four planted mutations were each caught. The permanent test pins golden strings taken from the original, not from the new function. `Message` gains optional `parts`/`turnStatus` types, and bulk-sync's id-merge now treats both as server-owned, so a stale or stripped browser copy can neither replace nor drop them.
- **Competitive-landscape study: Cloudflare OS seeded into the roster, and the CL2→CL3 hand-off no longer drops a late-added competitor** (`.ziya/complandscape/20-competitors/roster.json` (new `cloudflare-os` entry, category `company-ai-workspace`, `_meta.seeded_additions`, `_meta.known_roster_holes_for_next_run`), task cards `CL2: Competitive Field Survey` (Stage 1 STEP 0 carry-forward of `seeded.carry_forward=true` entries; Stage 3 gate checks seeds have dossiers) and `CL3: Capability Matrix` (Stage 1 STEP 2b appends every rostered-and-dossiered slug missing from the space's `tools` array before planning), `tests/test_complandscape_roster_seed.py` (new, 4)). The roster was frozen 2026-08-19, before Cloudflare OS's 2026-08 v2 release; an off-roster comparison surfaced it as the reference implementation for the two capabilities the s1-20260910 synthesis ranked hardest for Ziya (kernel-sandboxed execution, ARCHITECTURAL; the declined multiuser trust model). Seeding alone was not durable: CL2 Stage 1 regenerates `roster.json` from web research, and CL3 reads its tool axis from the matrix's `tools` array rather than the roster — the same two seams that lost aider in the first run and had to be hand-patched by the CL-delta card. Both are now closed in the card instructions; the matrix itself is untouched (adding the column early would make the grid "incomplete" and trip CL6's partial-grid refusal). Card scopes are unchanged — no new tool grants.
- **Default-permit for safe work is now stated as a deliberate design position** (`README.md`, `Docs/DesignPhilosophy.md` "Security Is Load-Bearing", `.ziya/complandscape/00-method.md` §0a, `roster.json` `cloudflare-os.design_positions_not_gaps`, `tests/test_complandscape_roster_seed.py` (+1)). The docs said safe operations are "trusted from the start" but not why, so readers (and the Cloudflare OS comparison) took default-deny tool introductions as something Ziya lacks. The reason is now written down: gating everything leads to approval fatigue and blanket auto-approve, so keeping safe work unprompted is what keeps the exceptions worth reading, and it only holds because anything past the floor needs a signed escalation. The study's method contract now tells every CL agent to record default-deny vs default-permit as a design position and compare on whether prompts stay rare enough to read, rather than scoring it as a Ziya gap. The seeded Cloudflare OS entry no longer lists default-deny under `likely_beats_ziya_on`. Its runtime-sandbox lead is still listed.
- **FeatureInventory §12 no longer says Ziya has no tiered permissions** (`Docs/FeatureInventory.md` §12a/§12c, `tests/test_docs_ledger_conformance.py` (+1)). Three gap rows were false. "Permission modes" said there was no tiered system, even though `direct_write_mode`, session and persistent allowlists, YOLO, the always-blocked floor and signed escalation all exist. That row now describes the tiers and says the real gap is a single named mode selector. "Plan / Act" said users can't review changes before they're written; review-before-write is the default for project files (diffs you apply). The remaining gap is a toggle that also suppresses the safe floor. "Filesystem / network sandbox" said the allowlist is "the only guardrail". It now lists the process-level controls and still states the missing kernel confinement as a real gap. The two permission rows link to the default-permit rationale.
- **README orientation for new users, and the rest of FeatureInventory §12 reconciled with the ledger** (`README.md`, `Docs/FeatureInventory.md` §12, `tests/test_docs_ledger_conformance.py` (+2)). README: a scannable "At a glance" block at the top (six concrete things you can do on day one, plus links); a no-cloud-account path in Quick start (`ollama pull …` / `ziya --endpoint local`); a "Coming from another tool?" table that maps chat-UI, CLI-agent, IDE-agent and hosted-assistant users onto Ziya's vocabulary and describes only Ziya; and concrete bullets under "What it deliberately isn't" (not an editor, single user, no auto-compaction, no kernel sandbox, no prompts for safe work). §12: dropped the "as of v0.6.x" heading and pointed to the design positions that aren't gaps. Removed the "Persistent cross-session memory" row, which contradicted the shipped memory subsystem. Marked three rows **Partial** and said what ships for each: per-profile tool selection (skills with tool subsets and model overrides), Figma/design import (image attachments to vision models), and compliance audit log (the append-only MCP tool-execution log under `~/.ziya/audit/`). The new test also rejects backslash-escaped backticks in README, which broke code fences in an intermediate edit without any error.
- **README pitch rewritten around checkable claims** (`README.md` "Why Ziya", `tests/test_docs_ledger_conformance.py`). Seven long voice paragraphs are now one problem statement (chat UIs can't change your files; coding agents live in one sidebar and forget) followed by five short bolded points: both halves in one local tool, used hard (two years, hundreds of daily users, diff engine hardened against real model output, signed tool results), built for big long work, stays out of your way, a good base for experiments. Unverifiable superlatives ("not a wrapper and not a toy", "nothing else does the job as well") were removed, and the docs test now rejects them.
- **README: new "Working on a dozen things at once" section** (`README.md`, `tests/test_docs_ledger_conformance.py`). The multitasking workflow, the strongest reason people keep using Ziya, was buried in the feature list. It now has its own section right after "Why Ziya", plus the first "At a glance" bullet. It covers: organising parallel work however you like (a window per project or per thread, a server per project, or one combined view of foreground and background threads); green check marks that stay until you look, so work finished while you were away is waiting when you return; beads tracking the branches you didn't follow as a backlog; and resuming a months-old thread with the model told how long it's been, which files changed, and whether the discussed changes were applied, with cross-conversation search and memory carrying over work done elsewhere.
- **Conversation handoff: continuations nest under their source in the chat list, and every segment of a chain shows its position** (`frontend/src/components/MUIChatHistory.tsx`, `frontend/src/utils/lineage.ts` (`handoffSegmentOrdinals` new; `buildHandoffChains` removed), `frontend/src/components/HandoffDrawerHost.tsx`, `design/conversation-handoff.md`; tests `frontend/src/utils/__tests__/handoffOrdinals.test.ts` (new), `frontend/src/utils/__tests__/handoffChains.test.ts` (removed)). 0.8.8.8 collapsed a handoff chain A→B→C into one row owned by the newest segment, with an "N segments" pill hiding the predecessors. In use the source appeared to vanish from the list, the opposite of the visible trail handoff exists to provide. A continuation is now a ⛓-marked child row of the conversation it continues, and the source stays in the list dimmed with ⇢ — the same placement fork and branch-from-bead already use. Each segment of a chain carries an ordinal badge (`1/3 ⇢`, `⛓ 2/3`, `⛓ 3/3`) so the sequence is explicit without hiding any row; a superseded second continuation is unnumbered and simply nests.

## [0.8.8.8] - 2026-09-23

### Fixed
- **Viewing a running task card from a server other than the one that launched it now shows the live run detail (text deltas, tool calls, block/iteration events), not just the REST summary** (`app/agents/task_run_stream_relay.py` (new `open_journal` / `close_journal` writer side, `_tail_journal` / `_maybe_start_tail` reader side; `connect` takes optional `journal`/`alive`; `push` appends to the journal), `app/storage/task_runs.py` (`journal_path` → `task_runs//events.jsonl`, inside the directory `delete()` already removes), `app/api/task_cards.py` (launch path opens the journal after `mark_active`, closes it in the executor's `finally`), `app/server.py` (`/ws/task-runs/{run_id}` reads `?project_id=` to locate the journal and an `executor_alive` probe), `frontend/src/hooks/useTaskRunStream.ts` (sends `project_id` on the WS URL), `tests/test_task_run_stream_relay_journal.py` (new, 11)). The relay's history buffer is process-local: the executing server fanned events out to its own sockets and kept a ring buffer for reconnects, but nothing reached disk, so a sibling server's relay had never seen the run and stayed silent — the tile got the disk-backed `GET /task-runs/{id}` snapshot and nothing else. The executing process now journals every raw event; a server whose relay has no history for the run tails the journal through its normal `push` path (folding deltas exactly as the live path does, populating its own buffer for later connectors), stopping on `run_completed`, when the last local observer leaves (offset retained so a restart never re-delivers), or when the executor lock is gone and the file is quiet. A completed run's detail is thereby also viewable from any server past the origin's 5-minute grace window. Journaling is best-effort and never blocks execution; a client that omits `project_id` gets the prior in-memory-only behaviour.
- **Diff apply: an undercounted `@@` header no longer reports success while silently dropping the tail of the hunk, and re-applying onto the half-applied result no longer duplicates the replaced lines** (`app/utils/diff_utils/application/git_diff.py` (`_repair_undercounted_hunk_headers` new; wired into `sanitize_patch_for_git_apply` and the whatthepatch-failure branch of `normalize_patch_with_whatthepatch`), `app/utils/diff_utils/application/patch_apply.py` (`_apply_changes_by_structure` widens its rebuild region over leading/trailing removal runs, or declines when the file does not hold them adjacent to the anchors), `app/utils/diff_utils/pipeline/pipeline_manager.py` (comment only: why the preprocessor recount is *not* propagated to `original_diff`), `tests/diff_test_cases/undercounted_hunk_header_{false_success,second_apply_duplicates,control_correct_counts}/` (new fixtures, the first with `apply_twice`), `tests/test_diff_undercounted_hunk_header.py` (new, 17)). Incident (2026-09-23, `models_config.py` kimi-k3): a model-authored hunk declared `-N,6 +N,9` over a 13/16-line body (3 ctx, 3 add, 7 ctx, 3 remove, 3 add — the model stopped counting after the first change block). Two defects compounded. (1) `preprocess_diff` recounts headers at pipeline entry, but only the additive-to-replace conversion is propagated to `pipeline.original_diff`, which is what `extract_remaining_hunks()` feeds the git_apply stage — so git received the raw header, parsed exactly six old lines, treated the trailing `-256000/+1048576` replacement as garbage, and exited 0; the pipeline reported success with the comment inserted and the old values untouched. The recount is now enforced as a **pure, one-directional** repair on the text handed to git: undercounts are raised to the body's counts, overcounts (truncated hunks) are left alone because git rejects them loudly and the difflib fallback already handles them — propagating the preprocessor's full output instead was tried and regressed `MRE_hunk_header_parsing_error`, `mcp_registry_test_connection`, `prompts_manager_log_level_change` via its blank-removal and truncation heuristics. (2) On the user's re-click, git apply failed (the truncated portion was already present) and the difflib content-based fallback took `_apply_changes_by_structure`, which anchors only on context lines and rebuilds the span between the first and last anchor — a replacement that is the hunk's tail sits *outside* that span, so the `+` lines were inserted and the `-` lines kept: duplicate dict keys, and Python's last-wins rule kept the old value. Removal runs before the first / after the last anchor are now consumed when the file holds them adjacent; when it does not (file drifted, or that part already applied) the function returns `None` so the caller's already-applied guard decides. The same guard fixes a latent third defect: at HEAD, re-applying an already fully-applied straddling hunk duplicated its new lines. Full fixture suite: the same 16 pre-existing failures before and after, no new ones.
- **Absolute diff paths now round-trip faithfully through the viewer and every apply site** (`app/utils/diff_utils/parsing/diff_parser.py` (new `restore_leading_slash` + `_ABSOLUTE_PATH_ROOTS`; `extract_target_file_from_diff` routes all four header branches through it), `app/utils/diff_utils/file_ops/file_handlers.py` (`create_new_file` restores before the `os.path.join` write sink), `app/utils/diff_utils/pipeline/pipeline_manager.py` and `app/utils/diff_utils/application/git_diff.py` and `app/utils/diff_utils/application/separate_hunk_apply.py` (each dropped its own ad-hoc parse for the shared restore), `frontend/src/components/renderFileHeader.tsx` (matching `restoreLeadingSlash` applied in `quickExtractFilename`, `extractPathFromUnifiedHeader`, and the git-header branch), `app/utils/diff_utils/tests/test_path_restore.py` (new, 9)). Git folds a path's leading slash into the `a/`/`b/` prefix, so `/Users/x/y.py` becomes `+++ b/Users/x/y.py` — indistinguishable from a project-relative `Users/x/y.py`. Six independent parsers each guessed differently: the viewer header never restored the slash (so the diff *displayed* with it stripped), while the apply sites either restored it only when `os.path.exists()` happened to be true or not at all — so a new-file creation at an absolute path (which by definition does not exist yet) was silently nested under the project root as `/Users/.../file.py`, and a modify's restored path depended on unrelated files on disk. All sites now share one deterministic restore keyed on a fixed filesystem-root allowlist (kept in sync between the Python and TypeScript copies), so display and apply always agree on the path the author expressed. This is strictly path fidelity; the separate out-of-project containment gate (`is_path_explicitly_allowed`) is unchanged.

### Added
- **Non-Claude Bedrock flagships: GPT-6 (Sol/Astra/Luna), Grok 4.6, Kimi K3** (`app/config/models_config.py` (bedrock entries `gpt-6-sol`/`gpt-6-astra`/`gpt-6-luna`, `grok-4.6`, `kimi-k3`), `tests/test_bedrock_non_claude_2026_09.py` (new, 51)). Live-probed against bedrock-runtime 2026-09-23: all five are invocable via the Converse API with `us.`/`global.` CRIS profiles in us-east-1 + us-west-2, accept TEXT+IMAGE input, and reject `temperature`/`topP` with a 400 (so all carry `unsupported_parameters: [temperature, top_k, top_p]`). Probed output ceilings: GPT-6 131072, Kimi K3 128000, Grok 4.6 ≥200000. Context windows were LIVE-PROBED (not inferred) by binary-searching real inputs to each model's explicit limit: all three GPT-6 variants behave identically (900,005-token input accepted, 950,005 rejected → 1,048,576 total window minus the reserved 131072 output budget); Grok 4.6 returns "prompt tokens (900019) exceed model maximum (524288)" → 524288; Kimi K3 returns "maximum (1048576)" → 1048576. So GPT-6 and Kimi K3 carry `token_limit`/`max_input_tokens`/`context_window` = 1048576 and Grok 4.6 = 524288. Three earlier first-cut inferences were all disproven by the probe: GPT-6 at 272k (from the gpt-5.6 sibling), and Grok 4.6 / Kimi K3 both at 256k (from their older-family siblings). All route through `NovaBedrockProvider` (Converse) via the llama4 pattern — no `wrapper_class`, non-`claude` family — which the added tests pin as the routing seam. Notably GPT-6 is served natively on bedrock-runtime, unlike the `gpt-5.6` family which needs the mantle OpenAI Responses gateway; Grok 4.6 is the first xAI model in Ziya. Added untagged (no tier) so they don't collide with the existing tier ladder. `supports_thinking` is set (all emit `reasoningContent` server-side by default) but that reasoning does not yet render on the Converse path — a separate follow-up.
- **Claude Opus 5.5 on Bedrock and Anthropic direct** (`app/config/models_config.py` (`opus5.5` bedrock entry, `claude-opus-5-5` anthropic entry, `opus` alias re-pointed on both endpoints, `large` tier tag moved off `opus4.8`/`opus5` and `claude-opus-4-8`/`claude-opus-5` onto the 5.5 entries), `tests/test_opus_5_5_models.py` (new, 8)). Verified live against Bedrock 2026-09-23: `anthropic.claude-opus-5-5` ("Claude Opus 5.5") is a foundation model with `us.`/`eu.`/`global.` inference profiles in us-east-1/us-west-2/eu-west-1 and TEXT+IMAGE input; a full listing cross-check found nothing in the config deprecated. Mirrors the `opus5` envelope (1M context / 128k output, vision, adaptive thinking, `temperature`/`top_p`/`top_k` rejected with 400). Thinking is always on and cannot be disabled, so `none` is deliberately absent from the effort set. The `opus` alias and the `large` tier now track the newest Opus on both endpoints — fixing a latent staleness from the earlier `opus5` addition, which left both `opus4.8` and `opus5` tagged `large` so first-match tier resolution silently pinned `large` to `opus4.8`; a new per-endpoint "no duplicate tier tag" invariant guards the seam.
- **Model-facing MCP self-inspection: the `mcp_server_status` builtin tool** (`app/mcp/tools/mcp_diagnostics.py` (new, `McpServerStatusTool`), `app/mcp/builtin_tools.py` (`mcp_diagnostics` category + `get_mcp_diagnostics_tools` getter + `tool_getters` wiring), `tests/test_mcp_server_status_tool.py` (new, 13), `Docs/Capabilities.md` and `Docs/FeatureInventory.md` under `mcp-startup-diagnostics`). The per-server startup logs, `startup_stage`, and preflight/startup failure diagnostics live only in the running manager's in-memory `MCPClient` objects and were reachable solely through the browser Logs tab's status route (`app/routes/mcp_routes.py`); the model had no accessor, so when a user asked Ziya *in chat* why their MCP server failed to start, it could only ask them to paste the panel. The new DIRECT tool reads the same `get_mcp_manager()` the route reads and returns, per server, the connected/quarantined flags, startup stage, preflight/startup failure diagnostic, tool/resource/prompt counts, and a bounded log tail. Called with no arguments it reports every configured server (including ones that failed to start and never produced a client); `server_name` narrows to one, `log_lines` bounds the per-server tail (`0` = whole buffer). Read-only — never starts, stops, or mutates a server. Model-callable, category `mcp_diagnostics`, enabled by default (`ZIYA_ENABLE_MCP_DIAGNOSTICS=false` to disable).

### Fixed
- **Narrow viewports (< 1300 CSS px) now get an automatic browser-like zoom-out instead of needing three Cmd-minus presses** (`frontend/src/utils/uiScale.ts` (new), `frontend/src/index.tsx` (`initUiZoom()` before first render), `frontend/src/index.css` (`--ui-zoom`, `--viewport-height/width`; `html, body { height: 100% }` replaces the `100vh` body pin; `.container`, `.chat-container`, `.folder-tree-panel`, `.panel-toggle` use the corrected lengths), `GraphPanel.css`, `App.tsx`, `PanelResizer.tsx`, `GraphPanel.tsx`, `MemoryBrowser.tsx`, `TaskCardsLibrary.tsx`, `MUIChatHistory.tsx`, `frontend/src/utils/__tests__/uiScale.test.ts` (new, 23), `frontend/src/components/__tests__/panelResizerUiZoom.test.tsx` (new, 2)). Field data: a MacBook Air on macOS "Larger Text" scaling presents a 1024-px CSS viewport, where the 33%-wide folder panel leaves a ~680-px chat column; the user found 80% zoom (≈1300 px) the first usable width. Browser page zoom is not scriptable, so at boot the app snaps `innerWidth / 1300` to the nearest of {1, .9, .8, .67} and applies it as CSS `zoom` on `` (1024 → 80%; every stock 1366+ laptop → unchanged; a user who already set 80% browser zoom reads as wide enough and is not zoomed twice). Decided once, not on resize, so the user's own Cmd-minus/plus composes for the session. Two spec consequences are handled (css-viewport §4): `zoom` pre-multiplies `vh`/`vw` but not percentages, so structural layout uses `calc(100vh / var(--ui-zoom))`; and `clientX`/`window.innerWidth` stay in unzoomed viewport px while layout is zoomed, so every drag handler and the `innerWidth`-derived panel geometry convert through `toLayoutPx()` / `layoutViewportWidth()` (otherwise the panel lags the cursor by the zoom factor). `/render`, `/print` and `/print-spike` are exempt so export geometry is unchanged. Debugging: `localStorage.ZIYA_UI_ZOOM = 'off'` disables, a number (0.3–3) forces a factor. Left at raw `vh` deliberately: ~55 `max-height: 50–70vh` popover/modal caps, which merely render proportionally shorter under zoom.
- **Bedrock: `NoRegionError: You must specify a region` on the first request for users with no region in their AWS profile** (`app/server.py` (`stream_chunks` resolves the region via `get_current_region()` when `ModelManager._state['aws_region']` is `None`), `app/providers/bedrock_client_cache.py` (`get_persistent_bedrock_client` never passes a `None` region to boto3), `tests/test_bedrock_client_cache.py` (+3)). `ModelManager._state['aws_region']` is `None` until a model has been (re)initialised in the process, and the direct streaming path read it with a `.get()` default that never applied because the key exists. The `None` reached `session.client("bedrock-runtime", region_name=None)`. Existing users were unaffected only because boto3 filled the region in from their profile or `AWS_DEFAULT_REGION` — botocore does not read the `AWS_REGION` variable Ziya's startup sets — so a new user with neither hit the error on every request while the log claimed a region was in use. The STS credential check in the same function succeeded because STS has a partition endpoint; bedrock-runtime does not.
- **`--region` is no longer silently dropped on the first model switch** (`app/config/environment.py` (`setup_environment` records an explicit `--region` as `ZIYA_AWS_REGION`), `app/agents/models.py` (`_reset_state` restores it instead of deleting `AWS_REGION` unconditionally), `tests/test_model_reset_region_and_settings.py` (new, 9)). `_reset_state()` deleted `AWS_REGION` on every model change and settings update so a model-default region could be re-selected, but it could not tell an explicit user choice from a default, so `ziya --region eu-west-1` reverted to the model config's region or `us-west-2` after the first switch. A model-default region is still cleared as before.
- **Model settings: the state reset for a `thinking_mode` change now happens inside the locked route handler, not the middleware** (`app/middleware/request_size.py`, `app/routes/model_routes.py` (`_update_model_settings_locked` resets when `thinking_mode` was supplied)). `ModelSettingsMiddleware` called `ModelManager._reset_state()` before the request reached `/api/model-settings` and outside `_model_mutation_lock`; if the route's reinit then failed the process was left with blank model state (and no `AWS_REGION`) until something else reinitialised. The middleware's `top_k` / `thinking_mode` capability normalisation was also nested under the `max_input_tokens` branch and only ran because the frontend always posts the whole form; each is now handled whenever present.
- **Chat renderer: raw HTML inside a `` widget no longer renders as literal tag text** (`frontend/src/utils/markdownDialects.ts` (`inlineToHtml` protects HTML tags, `normalizeDetailsBlocks` keeps ``/`` attributes and does not ``-wrap a block body), `frontend/src/utils/__tests__/markdownDialectsD017.test.ts` (+6)). The D-017 `
` normaliser re-rendered the summary and body through a small inline-markdown converter that escaped every `<`/`>`, so a styled error widget — `` icons in the summary, a styled `` body — came out as `<span>Error Details</span> …` tag soup, and the `style` attributes on ``/`` were dropped. Tags are now passed through to the raw-HTML token path (DOMPurify remains the sanitising boundary; `*`/`_` inside attribute values are no longer misread as emphasis), and literal `a < b` text is still escaped.
- **Shell-config routes: saving the modal no longer discards a still-valid `ZIYA_SCOPE_SIG`, and no longer silently demotes the shell server to global scope on a pip install** (`app/routes/mcp_routes.py` (`_build_shell_server_config`, `_carry_file_signature` new; used by `POST /shell-config`, `/shell-config/restart`, `/shell-config/apply-session-grant`), `tests/test_shell_config_route_env_rebuild.py` (new, 10)). Two defects in the same in-memory config rebuild. (1) `POST /shell-config` assembled the spawn `env` from the request fields only, so when no privileged field changed the file kept its signature but the respawned subprocess received none: escalation present, no signature, clamped to the floor with the "no signature accompanied the escalated values" notice — while the modal, which reads the file, reported "authorized". The file's signature is now carried forward when the new env's escalation *delta* (the object the signature actually covers) equals the file's, so a reorder or a non-privileged edit (timeout, git toggle) keeps it and any widening or narrowing drops it; an incoming signature is never trusted and the subprocess still re-verifies. (2) None of the three rebuilt configs set `workspace_scoped: True`, so `_is_workspace_scoped` fell back to keyword auto-detection over the script path — which matched on a dev checkout under `.../workspace/...` by accident and not on `site-packages/app/mcp_servers/shell_server.py`. After any shell-config save on an installed server the shell became global-scoped and ran commands in the server's cwd instead of the project. One constructor now builds the config for all three routes. Previously masked by the loader bug below, which meant the file env never reached the subprocess at all.
- **MCP: idle per-conversation shell subprocesses are now actually reaped** (`app/mcp/manager.py` (`_ensure_workspace_reaper`, `_workspace_reaper_loop` new; `cleanup_stale_workspace_instances` skips instances with a request in flight; `_shutdown_locked` cancels the loop), `tests/test_workspace_instance_reaper.py` (new, 7)). Every conversation gets its own shell subprocess (instance key `workspace::session_id`) and a 5-minute idle reaper existed, but its only trigger was `time.time() % 60 < 1` after a tool call — firing only when a call happened to land in the first second of a wall-clock minute (~1.7% of calls) and never while the user was idle, which is exactly when instances go stale. Observed: ten `shell_server.py` processes from the previous day still alive under three running servers. A background loop (60 s) now starts when the first workspace instance is created and is cancelled on shutdown; the opportunistic post-call trigger is a deterministic throttle instead of a wall-clock coincidence. An instance whose `_pending` map is non-empty is never reaped, since `last_used` is stamped at hand-out rather than return and a long command started just under the timeout would otherwise be killed mid-run.
- **Shell allowlist: additions saved from the Shell Configuration modal (or `ziya-approve` / CLI `/shell … save`) now actually reach the shell subprocess** (`app/mcp/manager.py` (`_initialize_locked` launch-key guard), `tests/test_mcp_builtin_override_without_command.py` (new, 2)). The on-disk `mcpServers.shell` stanza that `shell_config._ensure_shell_env` writes has no `command`/`args` — only `enabled`/`description`/`env` — which is also the exact shape the validator's `builtin_launch_keys_ignored` advice tells users to keep. The loader's "no way to launch this server" guard ran before the built-in-override merge and silently skipped the stanza (one INFO log line), so on every server start the shell subprocess was spawned from the bare built-in definition: floor allowlist, no `ZIYA_SCOPE_SIG`, and — because no escalation was ever seen — no clamp warning either. Meanwhile `GET /shell-config` merges the file env over the live one for display, so the modal showed the signed additions (`ada`, `aws`) as active and "authorized" while every such command was refused with the generic BLOCKED message. Confirmed from inside the running subprocess (`ALLOW_COMMANDS` unset) and via `/api/mcp/status` (`server_configs.shell` had no `env`). A stanza whose name matches a built-in server is now exempt from the launch-key requirement; the built-in branch already re-asserts `command`/`args`, and a non-built-in stanza without a launch key is still rejected (pinned by test). Requires a full server restart, not just a shell-server restart — the merge happens at startup.
- **Task run map: a loop nested inside another loop keeps every pass, shown as one bracketed strip per pass instead of a flattened "30/20"** (`app/models/task_run.py` (`IterationSummary.pass_key`), `app/storage/task_runs.py` (`_iteration_file`/`write_iteration_artifact`/`read_iteration_artifact` take `pass_key`), `app/agents/block_executor.py` (`_pass_key` new; `_begin_loop_pass` now resets only the per-pass artifact-retention budget), `app/api/task_runs.py` (`?pass_key=` on the iteration-artifact endpoint), `frontend/src/components/TaskCard/IterationDotStrip.tsx` (new), `runMapModel.ts` (`buildDotPasses`, `collapsePasses`, `PASS_WINDOW`), `TaskRunMap.tsx`, `TaskCardInlineTile.tsx`, `taskRunApi.ts`, `task_run.ts`, `tests/test_nested_loop_pass_key.py` (new, 6), `frontend/.../__tests__/runMapPasses.test.ts` (new, 8)). A nested loop runs its roster once per outer iteration and `append_iteration_summary` only appends, so GFX Stage 2 run 5d0b198c's 20-engine Repeat inside an Until recorded 0..19, 0..19: the map read "30/20", clicking engine 3 lit two dots (focus was keyed by index alone), and — worse — the artifact files `{block}_{index}` were overwritten each pass, so pass 0's output was already gone. Each summary now carries the enclosing pass (`"1"`, or `"1.3"` two levels deep; absent for a top-level loop, so existing runs and every resume path are untouched) and artifacts are filed `{block}_p{pass}_{index}`. The map renders one `pass k [ ●●● ] n/m` line per pass, oldest first; more than four collapse to the first pass, a `⋯ N more ▸` toggle, the previous pass and the current one. Focus is `(block, pass, index)`, so one click lights one dot and fetches that pass's artifact. The 50-pass artifact retention cap is per pass rather than cumulative, or a nested loop's 51st pass overall would keep nothing.
- **Shell write policy: a multi-line quoted script is one argument, not many commands — fixes a `Redirection to '1:' blocked` false positive and closes the bypass behind it** (`app/mcp_servers/write_policy.py` (`_split_unquoted_lines` new; `_check` uses it instead of `str.split`), `tests/test_shell_multiline_quoted_script.py` (new, 24)). `ShellWriteChecker._check` pre-split the command on every raw newline before the quote-aware operator splitter saw it, so for `python3 -c "…"` the opening quote stayed on line 1 and every body line arrived at `_redirection` with no quote context: `if len(pp)>1:` in Python source read as a shell redirect to a file named `1:`. The same shredding was a gate bypass, not only a nuisance. `_interpreter` inspects only a segment whose first token is an allowed interpreter; after the split the interpreter line was the bare `python3 -c "` and the body lines were segments starting with `import`/`os.system(…)` that it skipped — so `os.system`, `subprocess(shell=True)` [PenPal #157] and `shutil.rmtree` on any line after the first passed both the allowlist gate and the write checker (confirmed against the pre-fix code). Lines are now split only on unquoted newlines, mirroring the quote-state walker `ShellServer._split_unquoted_lines` already uses for the allowlist route. An unquoted newline, `;`, heredoc terminator and `\`-continuation still separate commands, and heredoc bodies are still stripped before the split so an unbalanced quote in a body cannot swallow what follows it. An unterminated quote now leaves the remainder as data to the write checker; that is safe only because `is_command_allowed` refuses open quotes first, and the new tests pin that gate as load-bearing.
- **Model-staged / model-launched task cards: the tile now appears mid-turn — the payload-to-JSON fix lands where the payload actually passes** (`app/mcp/signing.py` (`sign_tool_result` wraps a bare payload dict with `json.dumps(..., default=str)` instead of `str()`), `tests/test_signing_payload_shape.py` (new, 4)). The earlier fix in `tool_execution._process_result` was correct in isolation and inert in the product: for a builtin, `sign_tool_result` runs first and wraps any dict lacking a `content` key with `str(result)`, so `_process_result` received a content envelope whose text was already Python repr and its new branch was never reached. The unit tests certified a branch the real payload does not hit; the new test drives the actual sign → process chain and parses the output, and fails against the unpatched signing module with `JSONDecodeError`. Signature verification is asserted to round-trip on the new text (the canonical form is computed over `content` after the wrap).
- **Task cards: a card staged or launched by the model mid-turn now shows its tile in the conversation without a reload** (`app/tool_execution.py` (`_process_result`), `tests/test_tool_execution.py` (+2)). The binding was written and served correctly — `GET …/task-bindings` returned it — but `useTaskBindings` only re-fetches on the `task-binding-created` window event, and `chatApi.ts` fires that event only after `JSON.parse` of the tool's `tool_display` result succeeds. `_process_result` fell through to `str(result)` for any payload dict without a `content` envelope, which is the shape every task-card builtin returns, so the frontend received Python repr (`{'success': True, …}` — visible verbatim in the tool output panel), the parse returned null, and the tile did not appear until the next chat switch or reload. Structured results are now serialised with `json.dumps(..., default=str)`; the `content`-envelope, error and plain-string branches are unchanged. The new test asserts `json.loads` round-trips a stage-shaped payload and was confirmed to fail with the old fallback.
- **Chat turn relay: a provider exception mid-turn left the subscriber hanging instead of ending the stream** (`app/agents/chat_turn_relay.py`). The error path imported `sanitize_client_error` from a module that does not exist (`app.utils.error_sanitizer`; it lives in `app.utils.error_handlers`), so the `except` block itself raised and neither the error frame nor `stream_end` was published. Caught by the relay's lazy-import seam test, which the original commit landed red.
- **Mermaid diagrams: sizing now anchors on the smallest visible text, not the largest** (`frontend/src/plugins/d3/mermaidPlugin.ts` (`findDeclaredFontRange` replaces `findMaxDeclaredFontSize`; `chooseEffectiveWidth` new, exported), `frontend/src/plugins/d3/__tests__/mermaidFillWidthScaling.test.ts` (new, 13)). `applyEffectiveFontScaling` chose the rendered width so the LARGEST declared font landed at 14px. For any diagram whose largest text is a title — timeline, gantt, journey, titled pie — every body label came out proportionally smaller (a 22px title over 14px labels rendered the labels at ~9px) and, since the width was derived from the font rather than the pane, the diagram sat narrow and centred in empty space. Both symptoms were one number. The width is now chosen so the smallest legible text aims for 14px and never drops below 12px; the 18px cap on the largest text is honoured only while that floor holds; the container width remains absolute. Hidden nodes (`display:none`, `visibility:hidden`, `opacity:0`), whitespace-only nodes and sub-4px layout probes are excluded from the range so a measurement stub cannot inflate the diagram. The Safari path (`transform: scale` from the rendered rect) is unchanged. Rendered geometry moves for every title-vs-label diagram, so GFX goldens need a re-judge.

### Added
- **Memory tool results render as a memory card instead of a raw JSON tool block** (`frontend/src/components/MemoryCard.tsx` (new), `frontend/src/utils/mcpFormatter.ts` (`parsePythonLiteral`, `coerceToolResultObject`, `formatMemoryResult`; `FormattedOutput.renderAs` gains `'memory'`), `frontend/src/components/MarkdownRenderer.tsx` (`ToolBlock` routes `renderAs === 'memory'` to the card; the Python-repr fallback now parses the literal before falling back to the quote-swap), `app/mcp/tools/memory_tools.py` (`memory_propose` / `memory_save` echo `content`, `layer`, `tags`, and `pending_count` for propose), `tests/test_memory_tool_result_echo.py` (new, 3), `frontend/src/utils/__tests__/mcpFormatterMemory.test.ts` (new, 13), `frontend/src/components/__tests__/MemoryCard.test.tsx` (new, 5)). `memory_propose` and `memory_save` used to appear in chat as the generic purple tool block with a collapsed `{'success': True, 'message': 'Memory proposed for review (13 pending).', …}` body — nothing about what was proposed was visible, because `ToolBlock` never receives the tool input and the result did not echo it. The card shows the memory text, a neutral icon+label chip for the layer, the tags, the short id, and (for proposals) the probation count, with an ⓘ tooltip explaining the state. The accent is one fixed teal for every layer: `LAYER_COLORS` is deliberately not used, since the decision layer is amber and the chat surface reserves that for warnings/errors. Results persisted before the echo existed still render their plain message line. Tool results arrive as Python `repr`, so a real literal parser replaces the quote-swap fallback that corrupted any prose containing a quote or the words True/False/None.
- **Task cards: say something to a running block — operator steer notes, delivered before the block's next model round** (`app/utils/task_steer.py` (new: `steer_key`, `resolve_steer_target`, note bookkeeping), `app/models/task_run.py` (`TaskRun.steer_notes`), `app/storage/task_runs.py` (`enqueue_steer` / `mark_steer_delivered` / `expire_steers`), `app/streaming_tool_executor.py` (`stream_with_tools(feedback_key=…)`, defaulting to `conversation_id`), `app/agents/task_executor.py` (passes the per-block key; settles notes on `feedback_delivered`; expires the rest when the stream ends), `app/api/task_runs.py` (`POST /task-runs/{id}/steer`), `frontend/src/components/TaskCard/SteerComposer.tsx` (new), `TaskRunInspector.tsx` (composer under the Live output tab), `TaskCardInlineTile.tsx` (`💬 say something` / `N queued` chip on the progress line, `handleSteer`), `useTaskRunStream.ts` (refetch on `task_steer_*`), `taskRunApi.ts`, `task_run.ts`, `task-card-inline-tile.css`; tests `tests/test_task_steer.py` (new, 22), `frontend/.../__tests__/SteerComposer.test.tsx` (new, 9), `steerWiring.test.tsx` (new, 6)). Until now the only inbound signals to a live run were pause / step / cancel and an author-placed Ask; there was no way to *tell* a running block anything. A steer note is the chat mid-stream feedback channel with a target: the executor already drains a pending-feedback list at the top of every tool round and injects each item as a `[User feedback]` user turn, but every task in a run shares `conversation_id=run_id`, so a note keyed on it would have reached whichever parallel iteration drained first. `feedback_key` decouples the list from the conversation; task runs bind it to `steer:{run}:{block}:{index}`, and the endpoint enqueues on that key after resolving the target server-side against `card_snapshot` (an index is required for a loop block and discarded for a bare task, whose tile bucket carries a synthetic 0). Delivery is bounded, not instant, and the UI says so: a note is `queued` until a round starts, `delivered` when injected, `expired` if the block finished first — all persisted on the run record. **Send & hold** is Send plus the existing step credit, so the run holds at the next block boundary for the operator to read the reaction; no third control mechanism. Chat feedback is unchanged (the key defaults to the conversation id).
- **Consent runtime: a tool call can now pause for per-invocation human approval, in chat, surviving reload and answerable from any window** (`app/utils/consent_ledger.py` (new: `ConsentLedger`, `TaskRunConsentStore`, `FileConsentStore`), `app/utils/consent_gate.py` (new), `app/api/consent.py` (new), `app/tool_execution.py` (`execute_single_tool` gate), `app/agents/block_executor.py` (`_execute_ask` is now an adapter over the ledger), `app/server.py` (SSE pass-through of `consent_opened`/`consent_answered`), `frontend/src/utils/consentStore.ts` (new), `frontend/src/components/ConsentPanel.tsx` (new), `StreamedContent.tsx`, `apis/chatApi.ts`; tests `tests/test_consent_ledger.py` (22), `test_execute_ask_over_ledger.py` (5), `test_consent_gate.py` (12), `test_consent_gate_seam.py` (5), `frontend/.../consentStore.test.ts` (10), `ConsentPanel.test.tsx` (8)). This is design/consent-runtime.md steps 2–3, the prerequisite for the structured `git` tool (design/git-tool.md): "the agent proposes a commit, you approve it" needs a runtime that can hold a chat turn on a decision, and `ask` was a permission level with none (removed Feb 2026). The task-card Ask block's mailbox (`pending_ask`/`ask_answers`, first-answer-wins, restart-safe) is extracted into a shared `ConsentLedger`; `_execute_ask` keeps byte-identical run-record behaviour through it, and chat consents get a file store under `~/.ziya/consents/`. The executor gates a call whose tool is in `ask` mode (`permissions.json → consent.tools.`, or a tool-declared default) and has no standing grant: it emits `consent_opened` with the tool's preflight payload — you approve what will happen, not the request text — holds the server-owned turn so the disconnect grace timer cannot cancel it, and resumes on `POST /api/consent/{request_id}` with `approve`/`reject` and a scope (once / this conversation / this session; `always` is honoured as a session grant and flagged for the signed widening still to come). A rejection is returned to the model as a refusal, so the tool_use/tool_result contract holds. The `ConsentPanel` renders at the streaming message, fetches `GET /api/consent/open` on mount so a reloaded tab or a second window sees a request whose stream frame it never received, and keeps a live frame that lands while that fetch is in flight. Grants are per (tool, op): approving `commit` never approves `push`. No tool is in `ask` mode by default, so nothing changes until a tool opts in or `permissions.json` sets it. The TaskCard tile still answers Ask blocks through its own endpoint over the same ledger.
- **Task card editor: the header shows the definition version and when the card was last edited** (`frontend/src/components/TaskCard/cardVersionLabel.ts` (new), `TaskCardEditor.tsx`, `task-card-editor.css`, `app/storage/task_cards.py` (`record_run`), `frontend/src/components/TaskCard/__tests__/cardVersionLabel.test.ts` (new), `tests/test_task_card_versioning.py` (+2 assertions)). `TaskCard.version` — bumped only when the block tree or scope changes, and stamped into every run's `card_snapshot` — was returned by the API and rendered nowhere, so after editing a card through the API there was no way to confirm the edit had landed short of expanding the tree and counting blocks. The bare `saved` indicator now reads `v9 · edited 8h ago`, with a hover explaining what bumps the version. Making the timestamp honest required a storage fix: `record_run` stamped `updated_at = last_run_at`, so every launch read as an edit; it now touches only `last_run_at` / `run_count`. The deck sorts by name and folder, so nothing depended on runs moving `updated_at`. Browsable revision history is not included — the storage overwrites the card file in place and retains no prior definitions; that needs a revisions store first.
- **Task cards: the Permissions dialog's Shell tab exposes `shell_timeout_secs`** (`frontend/src/components/Permissions/PermissionsDialog.tsx`, `frontend/src/components/Permissions/shellTimeout.ts` (new), `BlockScopeButton.tsx`, `TaskBlockEditor.tsx`, `frontend/src/types/task_card.ts`, `frontend/src/components/Permissions/__tests__/shellTimeout.test.tsx` (new, 6)). The per-task shell ceiling existed on the backend model and could be set only through the API or a staged card; both block editors saved through `PermissionsDialog`, whose payload carried `shellCommands` and nothing about the timeout, so a task that needed more than the 300 s base (a production build, a full-corpus render sweep) had no control to give it one — and `task_card_write` refuses scope edits by design. The Shell tab now has a numeric field beneath the grants; blank, zero, negative or non-numeric saves `null` (inherit), and both editors forward the value. The GFX Stage 2 pixel-check task needed 5400 s and was the first user.
- **Task cards: an `until` loop that exhausts without meeting its condition now fails, and the condition judge sees evidence rather than the agent's summary** (`app/agents/block_executor.py` (`_execute_until`), `app/agents/until_evaluator.py` (`_build_user_message`, system prompt), `app/utils/self_improve.py` (`stage_evidence` records `tool_calls`; `render_stages_for_judge` flags `NO TOOL CALLS`; `render_data_parts_for_judge` new), `tests/test_until_exhaustion.py` (new, 3), `tests/test_until_evaluator_evidence.py` (new)). GFX Stage 2 run `3068d3d0` reported `done` with 93 unverified defects and every verification child `queued`. Three harness gaps lined up. (1) `_execute_until` returned the body's last-pass `failed` flag on exhaustion, so an explicit model-condition that the evaluator answered "no" to `until_max` times fell out of the loop as success; it now records `condition_failed` when an explicit `model`-mode condition is never satisfied (or the stall breaker fires) and ORs it into the artifact's `failed`, while the no-condition goal path keeps `until_max` as a safety net unchanged. (2) The evaluator was shown only `SUMMARY` + five decisions, so a condition naming a count or a ledger status was judged from the agent's prose — the same "a summary is a claim, not a measurement" gap the self-improve judge closed in 0.8.8.6, one layer up. It now reuses that judge's `render_stages_for_judge` / `render_data_parts_for_judge` / `render_outputs_for_judge`, so the condition judge sees per-stage outcomes, the JSON of emitted data parts (a condition like "no defect is still-broken" is checkable only from `{"still_broken": 0}`), and named file outputs, with a system prompt that treats the summary as a claim and absent evidence as "no". (3) `stage_evidence` now records each leaf's `tool_calls`, and the stage renderer flags a stage that ran zero tools — so a "Rebuild the frontend bundle" stage that invoked no shell command is visible to both judges as unsupported. This makes the un-evaluable condition fail honestly; the card-side fix (a body step that emits the ledger counts as a data part the condition can name) is separate.
- **Task-run map: blocks inside a loop body show what happened to them after a reload, instead of a bare `queued`** (`app/models/task_run.py` (`IterationSummary.stages`), `app/utils/self_improve.py` (`stage_digest`), `app/agents/block_executor.py` (`_record_iteration`), `frontend/src/types/task_run.ts` (`StageDigestEntry`), `frontend/src/components/TaskCard/runMapModel.ts` (`flattenBlocks` tags body rows with `LoopPosition`; `resolveBlockStatus` falls back to the loop's latest iteration digest), `TaskRunMap.tsx`, `tests/test_iteration_summary_stages.py` (new, 6), `frontend/src/components/TaskCard/__tests__/runMapBodyStatus.test.ts` (new, 8)). The executor persists `block_states` only for structural blocks — by design, so a 10,000-iteration loop does not rewrite the run file twice per inner block per iteration — which left a loop's body children with no durable status at all; the per-child outcomes lived only in the per-iteration artifact FILE the map never reads. On run `3068d3d0` a `done` `until` block over four never-executed children rendered as four bare `queued` rows and the shape of the failure was invisible. Each `IterationSummary` now carries a bounded digest, `{index, label, status, tool_calls}` per body block including a `skipped` entry for a sibling `on_failure=stop` never reached, taken from the `stages` the executor already computes. The map matches a direct body child to `latest_iteration.stages[position]` (latest by `index`, not array order — a resumed run's replayed prefix is seeded out of sequence) and paints passed/failed/skipped/cancelled; a live event or a real `block_states` entry still wins, and a record without a digest stays `queued` rather than inventing an outcome. Children of a group inside the body are not tagged: the executor records the group as one stage. `recoveryTarget` is unchanged — only the loop is a valid resume point.
- **Shadow line control: §6.3 security audit — 45 hostile-input tests, three findings fixed** (`tests/test_shadow_control_audit.py` (new), `app/shadow/sock_server.py`, `app/shadow/client.py`, `app/mcp/tools/shadow_tools.py`, `app/shadow/prompt_marker.py`). The audit throws 36 policy-bypass shapes (redirection variants, `<(…)`/`<>`, substitutions, chained/env-prefixed/`exec`/`eval`/`command`/`nohup`/`time`-wrapped destructive verbs, path-qualified and quote-split `sudo`, NBSP/fullwidth operators, embedded `\n`/`\r`, in-place `sed`, interpreter one-liners, `source`), named-policy traversal/schema/always-blocked escalation, lease/confirm forgery, grant with a stale lease id, spawn argv smuggling (`ProxyCommand` runs a *local* shell), kill ownership, symlinked rc files, and OSC injection via label. 40 held on first run. Fixed: (1) **the lease id was journaled in the clear** in every control meta record — and `send_line` accepts the id alone as a bearer token, while the journal is `shadow_read`-able by every same-UID chat, so any conversation could lift another's token and type under its lease; the journal now records `lease_ref` (sha256 prefix) so audit correlation survives and the token never touches disk. (2) **`control_release` accepted any lease id** without the holder's `conversation_id`, letting a same-UID caller tear down another chat's control; it now requires both (client/tool wrappers updated). (3) **`prompt_marker.install` followed a symlinked `~/.zshrc`**, turning the human's one keystroke into an append to an arbitrary file; it refuses symlinks. Two audit premises were wrong and were corrected rather than the code: plain input redirection (`cat < f`) is allowed by design (it is `cat f`; paths are opaque), and `policy=none` on a `gated` ceiling is already refused by an existing guard. `control_status` no longer exposes `lease_id` (earlier hardening, now pinned by test).

### Fixed
- **Conversation handoff: the drawer is now reachable from the token bar, and the model-side nudge measures against the same ceiling the bar does** (`frontend/src/utils/handoffOpen.ts` (new), `frontend/src/components/TokenCountDisplay.tsx`, `frontend/src/components/MUIChatHistory.tsx`, `app/server.py`; test `frontend/src/utils/__tests__/handoffOpen.test.ts`). The Hand off drawer shipped reachable only from a sidebar row's context menu — a user watching the context bar turn red had nothing to click, and the pressure affordance shown in the design mock was never built. The bar now shows "⇢ Hand off…" from the 70% warning threshold (red styling at 90%), opening the same drawer through a document event. Separately the backend pressure measurement used the static `token_limit` (1,000,000 for a 1M-context model) while the frontend bar uses the user's Max Input Tokens setting, so the model's `[Context pressure]` nudge never fired at the point the bar reported 90%; both now use `max_input_tokens` first, `token_limit` as fallback.
- **Shell Command Configuration: the persistent and session-only escalation banners no longer render side by side** (`frontend/src/components/ShellConfigModal.tsx`; `frontend/src/components/__tests__/shellConfigEscalationUX.test.ts` (+3)). With unsigned extras in `~/.ziya/mcp_config.json` and a session-only request staged for the same delta, both yellow banners appeared at once, each with its own "To activate" command (`sudo ziya-approve` vs `sudo ziya-approve --session`); after **Apply now** the persistent banner stayed next to the green active-grant banner while claiming the server was "running at the default floor". `signatureStatus` is computed from the on-disk config only, by design, so it cannot see the session path — the modal now gates the persistent banner on the session path not being engaged (staged or active), and the session banners carry a one-line note that the persistent config still holds unsigned extras.
- **Conversation handoff: the living draft and pressure nudge no longer bust the prompt cache every turn, and a stale client sync can no longer revert the model's draft writes** (`app/utils/handoff_prelude.py` (`split_handoff_prelude`, `append_handoff_turn_prelude`, `render_inherited_prelude`/`render_open_threads`, percentage removed from the nudge), `app/server.py` (`build_messages_for_streaming`), `app/api/chats.py` (bulk-sync guard), `frontend/src/api/conversationSyncApi.ts` (`conversationToServerChat`); tests `tests/test_handoff_draft_prelude.py::TestCacheStability` (+5), `tests/test_handoff_prelude.py`, `tests/test_handoff_tools.py::TestBulkSyncPreservesDraft` (rewritten, +2), `frontend/src/api/__tests__/conversationToServerChat.test.ts` (+1); `design/conversation-handoff.md`). Two defects found in review of the unreleased handoff work. (1) The whole prelude — including the living draft the model is told to merge into *every turn*, the live open-bead list, and a nudge that embedded the exact context percentage — was appended to the system prompt, which is where providers place the `cache_control` marker; from the first `handoff_write` onward every turn re-billed the entire cached prefix, on exactly the large-context conversations handoff exists to relieve. The prelude is now split: the stable inherited document stays in the system prompt; the volatile parts ride on the final user message behind a `[Ziya — handoff status for this turn]` marker, and the nudge text is byte-identical across turns. A mid-history system-role message was rejected as the alternative because the Anthropic wrapper overwrites `system_content` with it and the Bedrock wrapper merges it into the leading block. (2) The bulk-sync guard protected `handoffDraft` only when the client *omitted* the key, but after a full fetch the client carries a copy (`...full` spread), so an end-of-turn sync with a newer `_version` and the stale copy present silently overwrote a draft the model had merged mid-turn — the original test covered only the omitted-key case. `handoffDraft`/`handoff`/`handedOffTo` are now server-owned like `_beads`: stripped from the outgoing payload and carried forward from disk unconditionally; clearing is the PATCH with an empty document, not a null through sync. `lineageKind` keeps the omitted-vs-cleared rule because the client authors it on a fork.
- MCP config validation no longer tells users to "use an absolute path" for the built-in `shell`/`time` servers. The loader always replaces a built-in entry's `command`/`args` with its own interpreter and packaged script path, so the F-024 relative-path warning was a false positive with unfollowable advice. Built-in entries carrying `command`/`args` now get a `builtin_launch_keys_ignored` warning explaining that those keys are discarded and only `env`/`enabled`/`description` take effect.

### Added
- **Conversation handoff: "Ask the model to draft it" is a background, non-persisted turn** (`frontend/src/apis/chatApi.ts` (`runBackgroundTurn`), `frontend/src/hooks/useHandoffDraftRequest.ts` (new), `HandoffDrawer.tsx`, `Conversation.tsx`, `utils/types.ts` (`Message.handoffNotice`); test `frontend/src/hooks/__tests__/useHandoffDraftRequest.test.tsx`). Previously the button dropped an unsent prompt into the composer. It now sends the drafting instruction through the normal `/api/chat` path with the conversation's full live context (history, checked files, skills, model pin) and drains the stream client-side, so nothing enters the transcript; the model's `handoff_write` is the turn's only durable effect. The drawer shows a spinner and the draft appears in place; the transcript gets a local notice — role `system`, `muted: true`, so no send path ever includes it — with a "Review handoff" link. Disabled while the conversation is streaming or when the drawer targets a non-active conversation.
- **Shadow sessions: first-run prompt-marker recommendation** (`app/shadow/prompt_marker.py` (new), `app/shadow/pty_host.py`, `tests/test_shadow_prompt_marker.py` (new, 3)). The tint and title mark the terminal; a `⏺` in the prompt marks every line and survives scrollback search — but it needs one line in the user's rc file. On the first interactive `ziya shadow` whose wrapped shell is zsh or bash and whose `~/.zshrc` / `~/.bashrc` does not mention `ZIYA_SHADOW_SESSION`, the start banner is followed once by a tip showing the exact snippet, and the `C-x C-z` menu gains `[p]` which appends it (shown only while it is missing). The keystroke at the user's own terminal is the consent — nothing is written to a dotfile silently — and the install is journaled. The hint is one-time per install (`~/.ziya/shadow/prompt_hint_shown`); non-shell children (`ssh`, `sh`) never see it. Verified on a real PTY end to end (hint → `p` → rc updated).
- **Conversation handoff: the living draft — `handoff_read` / `handoff_write` tools and a context-pressure nudge** (`app/utils/handoff_prelude.py` (draft states, `merge_draft`, in-process pressure cache), `app/mcp/tools/handoff_tools.py` (new), `app/mcp/builtin_tools.py` (`chat_history` category), `app/models/chat.py` (`Chat.handoffDraft`), `app/server.py` (assembled-size measurement after `build_messages`), `app/api/chats.py` (bulk-sync carries handoff fields forward when the client omits them; honours an explicit clear via `model_fields_set`); tests `tests/test_handoff_draft_prelude.py` (20), `tests/test_handoff_tools.py` (6); `design/conversation-handoff.md`). Models already do this on their own as context tightens — they start maintaining a handoff file with a made-up name and path. The draft now lives on the conversation record and is written through a standard tool: `handoff_write(sections={objective,state,decisions,gotchas,references}, mode='merge'|'replace')`. Prelude states per turn: no draft and pressure below `ZIYA_HANDOFF_NUDGE_RATIO` (default 0.7, the frontend's orange threshold) → nothing; above it → a nudge to start a draft; draft present → the draft plus an instruction to merge in anything relevant that changed this turn; a continuation child carrying an inherited handoff gets **no** drafting instruction until asked or nudged. Pressure is a chars/4 estimate of the messages actually assembled, cached in-process for the next turn — one turn stale, never written to the record. Nothing is automatic: the nudge is text and the user commits the handoff.
- **Task cards: iteration headers in the Inspect drawer show what each `{{placeholder}}` expanded to** (`app/agents/task_templating.py` `list_placeholders`/`resolve_placeholders`, `app/agents/block_executor.py` `_emit_task_bindings` + shared `_templating_active`/`_task_bindings`, `frontend/src/components/TaskCard/IterationBindings.tsx` (new), `eventLog.ts`, `useTaskRunStream.ts`, `TaskRunInspector.tsx`, `task-card-inline-tile.css`; tests `tests/test_task_bindings_event.py`, `frontend/.../__tests__/iterationBindings.test.tsx`; `Docs/Capabilities.md`). A new `task_bindings` event is emitted at task dispatch — tagged with the iteration owner's block_id/index exactly like the streaming deltas — carrying every distinct placeholder in the task's instructions with the value the renderer substituted, or `resolved: false` when the model saw the braces literally (unknown head, or rendering skipped outside a loop). All three tabs (Live output, Tool calls, Events) render it as a highlighted box at the top of the iteration body and promote `{{item}}` into the collapsed row as a chip. Values are capped at 2,000 chars on the wire (`truncated`/`length`) and collapse behind "show all" past 200 in the UI. The resolver is a companion to `render` built on the same `_resolve`, so the event cannot disagree with what the model received; the emitter and renderer share one guard so they cannot disagree about whether substitution happened.
- **Task cards: the run map's focused-iteration panel shows "Resolved for iteration #N", and executor prose renders `{{item}}` in block names** (`app/models/task_card.py` (`TemplateBinding`, `TemplateResolution`, `Artifact.template_resolutions`), `app/agents/task_templating.py` (`IterationBindings.resolutions`), `app/agents/block_executor.py` (`_task_resolution`, `_emit_task_bindings` now also records, `_attach_resolutions` on repeat/until iterations, `_block_label` at the three name-derived prose sites), `frontend/src/types/task_card.ts`, `frontend/src/components/TaskCard/BlockDetailPanel.tsx` (`ResolutionSection`, `resolutionsFor`), `task-card-inline-tile.css`; tests `tests/test_template_resolution_record.py` (new, 8), `frontend/.../__tests__/detailResolution.test.tsx` (new, 4); `Docs/Capabilities.md`). Reconstructs the 2026-08-27 design that was approved but never landed — that turn attempted to apply its edits through a Python script, which the shell write policy blocks for project files, so `BlockDetailPanel.tsx` was still at the diff's base blob a month later. The live `task_bindings` event is gone once the relay's ring buffer rolls; the durable half is a `TemplateResolution` (authored/resolved name, bindings, instructions as sent, capped at 6,000 chars) on each templated task's artifact and, one per body task, on each loop iteration's artifact — the same file the `/iterations/{block}/{index}` endpoint already serves the panel from. Focusing an iteration dot now heads the panel with the resolved name and the same bindings box the inspector uses, and collapses the authored Configuration beneath it; a focused loop block with no iteration selected shows none, because its block artifact is the last iteration's. The "trivially fixed" half from the same conversation: `sequence stopped: step 2/4 (Wave 3 ({{item}})) failed`, a raising child's summary, and per-stage evidence labels now render the name against the iteration's bindings. Also fixed in this session's own tests: the earlier `iterationBindings.test.tsx` lacked the repo's `@jest-environment jsdom` docblock and `test_task_bindings_event.py` used a newline-separated for_each source where the parser requires a JSON array — both were test defects, not feature defects, confirmed before fixing. Follow-on: the resolved name is duplicated onto `IterationSummary.resolved_name` (`app/models/task_run.py`, `_record_iteration`; `frontend/src/types/task_run.ts`, `runMapModel.buildDots` `label`, `TaskRunMap.tsx` dot tooltips, `BlockDetailPanel.tsx` name-only fallback header + output label), because the summary is kept for every iteration while the artifact is dropped past the 50-pass retention cap — so a 200-iteration for_each names dots 51+ too (`tests/test_template_resolution_record.py` +2, `detailResolution.test.tsx` +3). A `detailResolution` assertion that expected the body task's `{{item}}` text under the loop's Authored configuration was wrong — a focused iteration's panel block is the loop, whose configuration is mode/source — and was corrected.
- **Shadow sessions: a shadowed terminal is now unmistakable — background tint for the session, deeper tint plus amber cursor while a chat holds control** (`app/shadow/pty_host.py`, `tests/test_shadow_tint.py` (new, 2), `tests/test_shadow_host_e2e.py` (stub updated for the `[c]` key), `Docs/design/shadow-sessions.md` §8, `Docs/NewUser.md`). The only prior indicators were the window title (invisible when the emulator hides its title bar, as ghostty often does) and the start banner (gone as soon as it scrolls) — the user reported the only way to tell a terminal was shadowed was that `C-x C-z` answered. The frontend now sets the *local* emulator's background (OSC 11) at start and restores it (OSC 111) on exit; a granted control lease deepens the tint and recolours the cursor (OSC 12/112), reverting on revoke/release. Because it is the local emulator's state it survives scrolling, `clear` and ssh hops. iTerm2 and ghostty honour all four sequences. Display path only — the journal never sees the bytes. Overridable via `ZIYA_SHADOW_TINT` / `ZIYA_SHADOW_TINT_CONTROL` / `ZIYA_SHADOW_CURSOR_CONTROL` (`#rrggbb`), disabled with `ZIYA_SHADOW_TINT=off`; a malformed colour yields no tint rather than a broken sequence. The real-PTY test asserts the observe tint at start, the control tint after `g`, the revert after menu `[r]`, and OSC 111/112 on exit. A `ZIYA_SHADOW_SESSION`-based prompt-marker recipe is documented as the dotfile-side complement (it does not follow an ssh hop, which is where the tint takes over).

- **Conversation handoff, steps 1–2 of 5: lineage discriminator, handoff record fields, per-turn handoff prelude, and `chat_search(conversation_ids=…)`** (`design/conversation-handoff.md` (new); `app/models/chat.py` (`HandoffDoc`, `Chat.lineageKind/handoff/handedOffTo`, `ChatSummary.lineageKind/handedOffTo/hasHandoff`), `app/storage/chats.py`, `app/storage/global_items.py`, `app/api/chats.py`, `app/api/beads.py`, `app/utils/handoff_prelude.py` (new), `app/server.py` (`build_messages_for_streaming`), `app/storage/chat_search.py`, `app/mcp/tools/chat_history_tools.py`; `frontend/src/utils/types.ts`, `frontend/src/utils/lineage.ts` (`forkLineageFields`), `frontend/src/context/ChatContext.tsx`, `frontend/src/utils/syncMerge.ts`; tests `tests/test_handoff_lineage_fields.py`, `tests/test_handoff_prelude.py`, `tests/test_chat_search_conversation_ids.py`, `frontend/src/utils/__tests__/forkLineage.test.ts`). A handoff is a *deliberate* move from one conversation segment to the next — the opposite of auto-compaction: the source stays whole and searchable, the child starts with an empty transcript and a user-editable handoff document stored on its record (not as a message), injected as a system-prompt prelude on every turn so edits take effect on the next turn. The prelude names the predecessor segment ids, tells the model to retrieve prior turns at full fidelity with `chat_read` / `chat_search`, and renders the *open threads* section live from the lineage's shared bead tree (b2) — a bead closed in any segment is closed everywhere and never shows as open. All three lineage constructs now share one edge model: every fork/branch/handoff sets `branchedFrom` plus `lineageKind` (`fork` | `branch` | `handoff`). **A plain fork now nests under its parent in the sidebar and shows the LineageBar** (previously only branch-from-bead did); existing forks are untouched (new forks only), and a fork of a branch no longer inherits the branch's seam label. `chat_search` gains a general `conversation_ids` filter — there was previously no way to restrict a transcript search to one conversation — and an explicitly listed id is searched even when it is the current conversation; `chat_read`'s header reports `lineageKind`/`handedOffTo`. Remaining steps (draft/commit endpoints + drawer, source banner/dimming, chat-list chain row, optional second-agent coverage check) are tracked in the design doc.
- **Conversation handoff, step 5 of 6: a handoff chain is one chat-list row** (`frontend/src/utils/lineage.ts` (`buildHandoffChains`), `frontend/src/components/MUIChatHistory.tsx` (`flattenVisibleNodes`, tree assembly, `ChatTreeItem` pill); test `frontend/src/utils/__tests__/handoffChains.test.ts`; `design/conversation-handoff.md`). Continuation is linear, so A→B→C now collapses to a single row owned by the newest segment with a "N segments ▸" pill that expands the earlier ones beneath it (dimmed, ⇢), instead of nesting each hop a level deeper like a fork. A link needs all three fields to agree (`lineageKind='handoff'`, `branchedFrom`, and the source's `handedOffTo`), so a superseded second continuation still nests under its parent as before. Chain-placed ids are skipped by the generic `branchedFrom` nesting pass, which would otherwise nest the tail under a predecessor that is now its own child.
- **Conversation handoff, step 4 of 6: endpoints, the Hand off drawer, source banner, continuation card** (`app/api/handoff.py` (new), `app/server.py` (router registration); `frontend/src/api/handoffApi.ts` (new), `frontend/src/components/HandoffDrawer.tsx` (new), `frontend/src/components/HandoffBanner.tsx` (new), `frontend/src/components/Conversation.tsx`, `frontend/src/components/MUIChatHistory.tsx`, `frontend/src/utils/types.ts`; tests `tests/test_handoff_api.py` (new, 12), `frontend/src/components/__tests__/HandoffBanner.test.tsx` (new, 4), `tests/test_chat_history_tools.py` (registration assertion follows the two new tools); `design/conversation-handoff.md`). A conversation's row menu gains **Hand off…**, opening a drawer that shows the living draft (model-maintained via `handoff_write`, editable here — an empty save clears it), the open threads from the shared bead tree (read-only: the continuation shares them rather than copying), and the working set; **Create continuation** writes a child with an empty transcript, the document as its per-turn prelude, `lineageKind=handoff`, the same `lineageRootId`, and links the source forward via `handedOffTo`. Chained handoffs auto-title "(2)", "(3)", …; a continuation's own handoff starts from *its* draft, not the inherited document. With no draft yet, **Ask the model to draft it** places a `handoff_write` request in the composer as an ordinary turn. The source shows a "continued in →" banner and is dimmed (⇢) in the sidebar but never locked — it still accepts sends; a continuation shows a ⛓ card in the LineageBar slot with the inherited document behind Show/Edit, where an edit takes effect on the next turn without creating a message. The API test asserts the seam end-to-end: after commit, the child's assembled prelude carries the document, the predecessor id and the source's open beads, and completing a bead through the child drops the source's `openBeadCount` on the summary listing.
- **Server-side bench assembly: activation model, lens view, header attention, and a `/context-estimate` endpoint** (`app/models/activation.py` + `app/services/activation.py` (new; placement resolution), `app/services/bench.py` + `app/utils/bench_prompt.py` + `app/api/bench.py` (new; `GET /bench` resolves the always-on skill set into prompt text, `modelOverrides` and `preferredToolIds`, merged in `stream_chunks` so the hub and the model agree), `app/storage/json_state.py` (new; JSON-state backing), `app/routes/token_routes.py` + `app/services/context_estimate.py` (new; `/context-estimate` estimates a turn's assembled context via the token calibrator), `frontend/src/context/LensContext.tsx` + `apis/benchApi.ts` + `utils/benchMigration.ts` + `hooks/useBench.ts` (bench/lens view), `frontend/src/utils/contextTokenTotals.ts` + `utils/headerAttention.ts` + `hooks/useHeaderAttention.ts` (context-bar totals + header attention), `ActiveContextBar.tsx`/`App.tsx`/`FolderContext.tsx`/`ProjectContext.tsx`; tests `tests/test_bench_api.py`, `test_bench_prompt_seam.py`, `test_context_estimate.py`, `test_activation_resolver.py` (+ `activation_cases.json`), and the `activationParity`/`benchMigration`/`contextTokenTotals`/`headerAttention`/`lensView`/`ActiveContextBar.bench` frontend tests). The "bench" is the resolved set of always-on skills/placements; resolving it server-side means `GET /bench` returns exactly what the model receives, with the client-supplied fields kept as a one-release fallback.
- **Consecutive tool calls in one iteration are dispatched as a single batch** (`app/streaming_tool_executor.py` (`pending_tool_ctxs` collected and dispatched after the iteration's content blocks close), `tests/test_tool_batch_seam.py`). Consecutive read-only calls now overlap instead of running strictly serially; the per-call execute path is unchanged. This is also where the task-card steer feature's `feedback_key` parameter rides on the `stream_with_tools` loop.

### Fixed
- **MCP: a server's `timeout` config key is now honoured** (`app/mcp/client.py`, `tests/test_mcp_server_timeout_key.py`). The key was already accepted by config validation and written by the manager for npx/uvx servers, but `MCPClient` read a never-written `tool_timeout`, so a server proxying a slow backend (leolens-mcp streaming AgentCore for 20–60 s) was abandoned at the 30/60 s name heuristic while its answer was still arriving; the client now reads `timeout`.
- **MCP: the fingerprint-change quarantine log points to the Re-authorize button, not a private method** (`app/mcp/manager.py`, `tests/test_mcp_quarantine_log_guidance.py`). The SECURITY error told users to "see `reauthorize_server()`" — an internal method with no user-facing path; it now directs them to the MCP Servers panel (plug icon) and its Re-authorize action, or to leave the server quarantined and inspect it.
- **Diff viewer: a server diff-rejection marker no longer prints as literal comment text** (`frontend/src/utils/diffUtils.ts` (`isDiffRejectedMarkerBlock` new), `frontend/src/components/MarkdownRenderer.tsx`, `frontend/src/utils/__tests__/diffRejectedMarker.test.ts`). The rejection marker is consumed by the diff pre-pass; the `html` token branch now returns null for it instead of falling through the tag-allowlist test and rendering the marker comment verbatim.
- **Token accounting: per-model calibration buckets and auto-add context-limit accuracy** (`app/utils/token_calibrator.py`, `frontend/src/utils/autoAddTokenLimit.ts`; tests `tests/test_calibration_model_buckets.py`, `tests/test_accurate_token_count_large_file.py`, and the `autoAddTokenLimit`/`autoAddAggregateBudget`/`measureForAutoAdd` frontend tests). The calibrator refines per-model buckets and large-file counting; the auto-add-to-context budget and aggregate limit are computed against measured token totals.
- **Diagram rendering: a broad hardening pass across the d3 plugins, LaTeX ink, and capture sizing, with the GFX corpus goldens re-judged** (`frontend/src/plugins/d3/*` (basicChart, chord, d2, drawio + enhancer, force-directed, joint + link-routing, network, packet, plotly + preprocessor, vega/vega-lite + sanitizer + layer-defaults, mermaidEnhancer), `frontend/src/utils/d3Plugins/{musicPlugin,packetPlugin}.ts`, `frontend/src/components/D3Renderer.tsx`, `frontend/src/utils/pluginDimensions.ts` — fit/viewbox/label/marker/anchor/overlap fixes pinned by ~40 new d3 `__tests__`; `app/utils/latex_color.py` + `app/services/latex_profiles.py` — fill/ink pairing, opacity-aware fill and `tikzset` `definecolor`, pinned by 7 new `test_latex_*`; `app/services/diagram_renderer.py` — capture-extent / fit-rewrite fixes (`test_diagram_capture_*`); `tests/gfx_corpus/*/expectations.json` re-judged across all 19 renderers plus new corpus fixtures). (Mermaid sizing, above, is its own entry.)

### Changed
- **Document authoring: a preprocess pass and tightened authoring guidance** (`app/utils/document_preprocess.py` (new, called from `document_ir.preprocess_document_body`), `app/data/built_in_skills.py`, `tests/test_document_export.py`, `tests/test_document_preprocess.py`). The document body is normalised before IR conversion; the document-authoring skill now states that `author` is a person or team only and that local session context (repo/workspace/project/model names, `.ziya/` paths, conversation IDs) is not document content.
- **Internal refinements to path/dir utils, the diff-validation hook, and prompt assembly** (`app/utils/paths.py`, `app/utils/directory_util.py`, `app/utils/diff_validation_hook.py`, `app/utils/precision_prompt_system.py`, `app/utils/skill_catalog_prompt.py`; frontend `chatTreeFolderBadge` test). No user-facing behaviour change beyond these assembly seams.
- **Note on organization:** this section preserves the per-change `### Added`/`### Fixed` blocks as they were authored during development (they alternate rather than being merged into one block per category); every entry above corresponds to a committed change and no entry was reordered, to avoid corrupting the forensic bodies.

## Older releases

0.8.8.7 and older are in [CHANGELOG.1.md](CHANGELOG.1.md).}