Skip to content

Lite docs for 2026.10.1: plugins and the session conversation - #53

Merged
fylorn merged 10 commits into
mainfrom
docs/lite-plugins
Oct 3, 2026
Merged

Lite docs for 2026.10.1: plugins and the session conversation#53
fylorn merged 10 commits into
mainfrom
docs/lite-plugins

Conversation

@fylorn

@fylorn fylorn commented Oct 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Docs for the script plugins and the session conversation that ship in ThinkWatch Lite 2026.10.1 (core v0.59.0).

  • New page Plugins (English and Chinese): adding and editing a plugin in one editor with Settings and Code tabs, the plugin ID, installing, ordering, trial runs, logs and statistics; the manifest as plain data that holds the plugin's configuration; hooks, permissions and request kinds; the placeholder bridge for secrets; what happens on errors; confirmation in a system dialog for plugins that can change tool calls; limits and risks; the two built-in plugins, both off by default.
  • Overview and Features link to the new page.
  • Features describes the new Conversation tab of a session.
  • _meta.ts adds the page to the Lite docs navigation.

To merge when the Lite 2026.10.1 release is published.

🤖 Generated with Claude Code

fylorn and others added 10 commits October 2, 2026 16:14
@fylorn @claude
Lite docs: Plugins
d89d2b7 
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>
@fylorn @claude
Lite docs: Plugins, with the app's labels and the runtime's limits
7637685 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@fylorn @claude
Lite docs: Plugins, request hooks skip token-count requests
ce72bfd 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@fylorn @claude
Lite docs: Plugins on the Responses WebSocket, and how a broken plugi…
8f61d6c 
…n is matched

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@fylorn @claude
Lite docs: Plugins with route-first request hooks and the built-in pl…
ea88ebe 
…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>
@fylorn @claude
Lite docs: Plugins with request kinds, the three built-in plugins and…
531a8fb 
… 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>
@fylorn @claude
Lite docs: Plugins with the two built-in plugins
f8e8c6f 
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>
@fylorn @claude
Lite docs: Plugins keep their configuration in their own file
2548d05 
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>
@fylorn @claude
Lite docs: Plugins, the Install button and the plugin ID
87d0745 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@fylorn @claude
Lite docs: the Conversation tab of a session
213c95f 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@fylorn fylorn changed the title Lite docs: Plugins Lite docs for 2026.10.1: plugins and the session conversation Oct 3, 2026
@fylorn
fylorn merged commit 3438f5f into main Oct 3, 2026
1 check passed
@fylorn
fylorn deleted the docs/lite-plugins branch October 3, 2026 12:47
fylorn added a commit that referenced this pull request Oct 11, 2026
@fylorn @claude
Lite docs for 2026.10.1: plugins and the session conversation (#53)
41a6d6c 
* Lite docs: Plugins

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>

* Lite docs: Plugins, with the app's labels and the runtime's limits

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Lite docs: Plugins, request hooks skip token-count requests

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Lite docs: Plugins on the Responses WebSocket, and how a broken plugin is matched

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Lite docs: Plugins with route-first request hooks and the built-in plugins

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>

* Lite docs: Plugins with request kinds, the three built-in plugins and 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>

* Lite docs: Plugins with the two built-in plugins

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>

* Lite docs: Plugins keep their configuration in their own file

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>

* Lite docs: Plugins, the Install button and the plugin ID

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Lite docs: the Conversation tab of a session

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@fylorn