A new Agent Note owns the shipped defaults and the original apply_patch note
keeps its opt-in decision with a supersession link; the policy README, the
tool-catalog note, the filesystem page, and the fs group README state the
current defaults without evaluation figures. The PTC overlay sets
`applyPatch: false` so the SDK and Desktop PTC tool sets match without a
parity exception; the fixed-budget compaction scenarios pin the tool set in
their live patches too; the apply-patch composition drops its no-op override.
The upgrade guide scopes the change to base-backed profiles, the README
refusal example is one every composition can produce, the integration suite
names its deployments by guard, and the keyless SDK smoke edits a file the
model never read through the shipped profile.
Takes master's re-recorded plan-review, creation-recommendations, and
plugin-recommendations scenarios from the base and refreshes their headers
and schema sidecar for the enabled apply_patch tool.
Evaluation on the shipped compositions decided the defaults: the `dsh-base`
`tool-fs` row and the Web `standard` preset enable apply_patch, keeping the
SDK and Desktop `standard` tool sets equal (the SDK PTC overlay keeps the
base row while the Desktop PTC preset lists its own, which the parity
exceptions record); the `fs-observation-policy` row ships `disabled: true`,
so write, edit, and apply_patch mutate unconditionally in every profile, and
the package is classified as an optional product package.
The write and edit guidance stops citing the policy as the default and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal re-enable the row through a
per-scenario runtime.cordis.yml; the fixed-budget compaction scenarios pin
`applyPatch: false` so their recorded thresholds hold; every other sidecar
and recorded header follows. An upgrade guide records the default change.
This pull request lands the tool; switching the shipped defaults is a
separate pull request stacked on it. Every shipped `tool-fs` row states
`applyPatch: false`, the `fs-observation-policy` row stays mounted, the
write, edit, and apply_patch guidance names the policy, and every recorded
expectation outside the apply-patch scenarios returns to the master
baseline. The upgrade guide, the parity exception, and the optional
classification of the policy package move to the stacked change.
The SDK/Desktop parity check requires the `standard` tool sets to match, so
the base row enables apply_patch like the Web standard preset; the SDK PTC
overlay keeps that row while the Desktop PTC preset lists its own, which the
parity exceptions now record. fs-observation-policy, no longer mounted by
default, is classified as an optional product package.
Every headless, SDK, and ACP recording follows: sidecars and recorded headers
gain the apply_patch schema, the fixed-budget compaction scenarios pin
`applyPatch: false` so their recorded thresholds hold (model-switch-notice and
session-resume own their schema sidecars again), the parent presets that
borrow the default pin mirror the base row, and the pwsh and Python PTC pins
carry the schema and guidance.
Keeps the apply_patch toolview registration with master's file-menu inject,
takes master's shortened slot JSDoc, re-adds the seven filesystem type-equiv
manifest entries, regenerates the event matrix and client catalogs, moves the
fs-observation-policy upgrade guide under v0.2.2-alpha.2 with the matching
fs-patch version, and refreshes the two SDK scenarios master added for the
write and edit guidance change.
Evaluation on the shipped Web composition decided the defaults: the
`fs-observation-policy` row in dsh-base ships `disabled: true`, so write,
edit, and apply_patch mutate unconditionally in every profile; the Web
`standard` preset lists apply_patch; and the tool-fs `applyPatchGuard` switch
is gone, apply_patch always consulting the fs/* intent waterfalls like the
other mutating tools.
The write and edit guidance stops citing the policy as the default, and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal (fs-policy-reject and
apply-patch-rejected) re-enable the row through a per-scenario
runtime.cordis.yml; every other sidecar follows the prompt change, and the
Web standard-preset recordings gain the apply_patch schema. An upgrade guide
records the default change.
The MCP SDK answers resources/list and resources/templates/list for a
server without the resources capability with an empty page, but first
writes a console.debug line to stdout. Under the ACP profile that line
lands in the JSON-RPC stream whenever the model lists resources of a
client-supplied, tools-only MCP server. Return the same empty pages
before calling the SDK, and cover it with a unit assertion and an ACP
stdout regression test.
Replace the literal "Approval policy: ask." runtime-context sentence
with a statement parallel to the never-policy sentence, and refresh the
current-generation fixtures that persist it.
Co-authored-by: Tianyi Cui <[email protected]>
* refactor(llm-deepseek): share the /models listing machinery
Move the account route's `/models` request and decoding, its
credential-scoped listing cache, and listed-catalog resolution with the
version gate into the shared DeepSeek Messages library, so a second
route can follow the same listing. Names drop the account prefix, the
cache takes each access's endpoint settings with the call, and it gains
`invalidate()` for a forced reload. `isBuiltInCatalog()` recognizes the
catalog an uncustomized `models` setting resolves to.
The account route keeps its behavior; only its imports and the
override diagnostic wording ("model listing") change.
* feat(llm-deepseek-api-key): follow the official /models listing
While `models` equals the built-in catalog and the Messages origin is
https://api.deepseek.com, `deepseek-official` serves the official
`GET /models` listing, authenticated with the API key in `x-api-key`.
Loading, refresh, fallback, merging, and the client-version gate match
the account route: the first access waits up to `modelsTimeoutMs`, a
listing older than `modelsMaxAgeMs` refreshes in the background on the
next access, a failure keeps the last good listing or the built-in
catalog, and listed models this build cannot serve are refused before
network I/O.
A customized `models` list replaces the catalog and requests nothing.
Switching between a customized catalog and the listing discards the
cached listing, so Restore defaults reloads it on the next access.
Suites that boot the route on the official endpoint now answer the
listing themselves instead of reaching the network.
* docs: describe the official route model listing
Document when `deepseek-official` follows the official `/models`
listing, its timing fields, customization precedence, and the forced
reload after Restore defaults in the API-key README, the shared
transport README, and the provider guide. Record the decision in a new
Agent Note, keep the account note's statement of where the shared
listing code lives current, and regenerate the configuration catalog.
* test(llm-deepseek-api-key): pin the once-per-listing hidden-entry diagnostic
* docs: regenerate module and event graphs for the shared listing
* fix(llm-deepseek-api-key): report credential failures on the model request
On the official endpoint, `connect` waited for the listing view, whose
credential lookup rethrew a malformed key or a credential-store failure
before the agent loop recorded the prompt. A failed lookup now resolves
the connection from the current listing view, so `resolveAuth` reports
the failure on the model request and the turn keeps the prompt and the
failed attempt. A caller abort still rejects.
* docs(llm-deepseek-api-key): name which hidden listing entries are logged
* test: keep unit suites off the official model listing
Suites that boot the DeepSeek routes with a dummy or inherited key now
request `GET https://api.deepseek.com/models` on the official endpoint.
A unit-lane setup file rejects that request at once, so such a suite
serves the built-in catalog instead of reaching production or waiting
out the listing deadline on a network that never answers; suites that
exercise the listing answer `fetch` themselves. Other requests pass
through unchanged.
* feat(llm-deepseek): read tool_update from the model listing
Both DeepSeek routes now take a listed model's Messages tool update mode
from `api_capabilities.anthropic_messages.tool_update`, alongside the
system prompt mode. `in-history` and `addition-only` replace the
bundled mode; any other value reads as `leading-only` and removes it.
An absent or `null` mode keeps the bundled one, so a listing that does
not declare the field leaves `deepseek-flash` on `addition-only`.
`system_prompt_update: null` likewise keeps the bundled mode now; it
previously read as `leading-only`, which a serializer writing empty
values as null would have turned into a cache-unfriendly downgrade.
* fix(llm-deepseek): sync the built-in context window with the official listing
The official `/models` listing declares a 1,048,576-token context window
for `deepseek-flash` and `deepseek-v4-pro`; the built-in catalog said
1,000,000, a decimal-versus-binary mismatch. Both built-in entries now
carry the listed value, so offline starts and listing failures size the
context the same way the listing does. The Models page shows the exact
count for these rows, since 1,048,576 has no decimal K/M spelling.
`defaultContextWindow`, the fallback for model ids the catalog does not
describe, stays 1,000,000.
* test(llm-deepseek-api-key): reject the stubbed listing request with an Error
* test(cli): keep the built SDK smoke off the official model listing
The SDK profile's initialize now resolves the deepseek-official catalog,
which requests GET https://api.deepseek.com/models on the official
endpoint. With the smoke's fixture key that request answers 401 and the
route warns on stderr, so the test's empty-stderr assertion failed in the
e2e and snapshots lanes. Point the run at a loopback mock and assert it
received no model call.
* test(llm-deepseek): compose the malformed-key turn without the native executor
release/dsh-0.2.1 predates @deepseek-ai/dsh-tool-executor-native; its tool
runtime executes tools itself. Compose the official-route turn the way
account-routing.spec.ts does on this branch.
* fix(llm-deepseek-api-key): gate nothing when the credential lookup fails
The listing cache switches scope only after it reads a credential, so a
failed lookup left `connect` serving the previous credential's listing.
After a key whose listing refuses a model was replaced by a malformed one,
`admit` refused that model with CLIENT_UPGRADE_REQUIRED before the turn
recorded the prompt, instead of `resolveAuth` reporting the credential
error on the request. Serve the built-in catalog without listing gates
when the lookup fails.
* test(llm-deepseek-api-key): pin the once-per-listing diagnostic across request preparation
The hidden-entry diagnostic test repeated the same discovery assertion to
prove a second pass reports nothing new, which read as a duplicate. Assert
the single warning after the request preparations instead; they resolve
the same listing, so dropping the per-listing deduplication still fails
the test.
* docs(llm-deepseek-api-key): note that a list matching an earlier built-in catalog counts as customized
Customization is judged against the running version's built-in catalog,
so a saved `models` list equal to an earlier version's catalog stops
following the listing once the built-in catalog changes, until Restore
defaults. Record the consequence in the Agent Note and the README's known
limitations.
* fix(ui): separate navigation pins from selection and show menu icons
* fix(ui): simplify More menus and fold conversation views on resize
* test(ui): fix navigation CI regressions and refresh catalogs
* refactor(ui): render sidebar panel icons directly
* fix(ui): keep Chat visible and stop persisting navigation pins
* refactor(ui): drop unreachable pin validation from in-memory stores
