Lite docs for 2026.10.1: plugins and the session conversation - #53
Merged
Merged
Conversation
A new page, in English and Chinese, for the JavaScript plugins that ThinkWatch Lite gains in its next release: what a plugin can change, adding one (file or pasted code, review, confirmation in a system dialog, changed files), the API (manifest, hooks, request view, answer hooks, ctx), permissions, failures, limits, the security model, what the sandbox cannot prevent, and the five examples in the Core repository. Features and the overview gain the Plugins page, which makes ten pages. This ships with the release and is not to be merged before it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n is matched Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ugins The request hook now runs after routing, once for each attempt to send to an upstream: the page describes that order (route, plugins, screening, conversion and redaction, send), failover starting again from the client's original request, the new ctx fields (model as sent, requested_model, upstream for every hook), and scope matched per attempt by client, sent model and upstream. The examples give way to the six plugins that ship with the app, all off by default: what each does and its settings. Plugins that can change tool calls need a system dialog to be turned on or reconfigured. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… the answer-instance cap The page now matches the final plugin design in core: - Order: routing on the client's original request, then for each attempt placeholders, plugins, a second content check on what the plugins added, conversion, redaction and send. A plugin's model change only renames what is sent and still has to be a model the key may use. - Request hooks also run on token counts and Responses compaction; only a model change is written back there. - Request kinds: the manifest's `requests` field, the views for embeddings and legacy completions (one message per input, text-only edits, token ids read-only, their params), no answer hooks for them, undeclared kinds passing untouched whatever `on_error` says, and the load rules. - ctx gains the three new formats; scope applies to every hook. - Built-in plugins: the three that ship (answer language, WSL and Windows paths, DeepSeek request rejections), with their settings and how updates and deletions are handled. The dropped ones are gone, and the writing example no longer uses one of them. - Turning on or reconfiguring a tool-call plugin needs the system dialog; multi-line string settings; at most 32 answer instances at once and what happens when none is free. - The first launch after the update clears the request history. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Core no longer ships deepseek-flags ("Avoid DeepSeek request
rejections"); reply-language and wsl-paths remain. In both languages:
- Plugins: drop its section and its example in the introduction, and
say two built-in plugins instead of three, in the introduction, the
built-in section and the upgrade note. Only wsl-paths can change tool
calls now, so the system-dialog sentence names it.
- Features and the docs index summary: two built-in plugins.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A plugin's JS file now holds its scope, its behavior on errors and its setting values, as in core v0.59.0. - Adding and editing: one editor with Settings and Code tabs and a single Save; Settings changes are written into the manifest, code edits update the settings, and Add plugin opens the same editor on the Code tab with Import from file. Enabled stays a switch in the app. - The manifest is pure data; `on_error` joins the fields, settings take `value` instead of `default`, and a rewrite replaces only the manifest literal in one fixed style, without the comments inside it. - Confirmation: a system dialog only to install, turn on, change the code of, or approve a changed file for a plugin that can change tool calls. The config file editor and version history cannot do those steps. - A plugin that cannot run takes its scope and behavior on errors from the approved file. - Built-in plugins show their shipped manifests; settings changes do not count as editing their code when an update arrives. - Examples use the new manifest shape. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fylorn
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs for the script plugins and the session conversation that ship in ThinkWatch Lite 2026.10.1 (core v0.59.0).
_meta.tsadds the page to the Lite docs navigation.To merge when the Lite 2026.10.1 release is published.
🤖 Generated with Claude Code