Chinesezjc
2e3cf144d5
Adding a published Python backend and reordering `flush_line` left several owning documents stating things that are no longer true. `src/invariant.ts` justified its empty installer with "ships only the fd-3 wire-protocol codec", which the subprocess execution path contradicts. The reason now states the actual one: every relation this backend maintains lives in the CPython child or on the fd-3 wire, so no same-process event sequence is observable from a listener -- the same shape the sibling worker-thread backend uses. The seam's `PORTABLE_RESERVED_WORDS` and `language` JSDoc, the code-runtime README pair, and docs/subsystems/code-runtime both said only TypeScript has a published backend. Corrected in all four, with the generated cordis catalog regenerated for the `language` change. The note attributed the 12x multiple to the settlement flush holding three copies. That stopped being true when `flush_line` was reordered to drop the pending chunks before its push: the binding worst case is the newline path's single near-budget write. Corrected in the note (both sides) and in the test comment that repeated it. The note's Testing section now registers the cases this stack added, and the Chinese side receives the O(depth) entry it never got plus the new ones -- it had drifted from the English. `INTERPRETER_BASELINE_BYTES` argued 64 MiB from a RESIDENT set while RLIMIT_AS bounds address space. It now cites the bootstrap's own measurement (30.23 MiB of mappings for `python3 -I`), making 64 MiB roughly twice the measured baseline. Also: a hardcoded `(:232-235)` comment reference becomes a reference by name, a "which now walks in O(depth) too" change narrative becomes a current-state statement, and a stray double blank line is removed.
description, kind
| description | kind |
|---|---|
| The extensions group map: model-facing tools and dual-half runners for defining, running, and removing dynamic Cordis packages, for users and maintainers navigating the group. | package-group |
packages/extensions
English | 中文
Summary
The extensions group lets a running agent modify the runtime it runs inside: the model can inspect the plugins and services loaded in the current DSH process, define a dynamic Cordis package (with a host half, a browser half, or both), run it, stop it, and remove it, and a browser panel operates every definition. Packages evolve by plugin: a plugin holds immutable package versions and can run or update between them. Definitions live only in process memory, so a DSH restart clears them and nothing here writes repository files or configuration. Four packages form the subsystem: the model-facing tools plus the host runner, and the browser runner plus the browser UI.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
tool-cordis |
Seven model-facing tools: inspect the live runtime, define, run, stop, and remove dynamic packages | registers on ctx.tools |
cordis-host-runner |
Host half: definition registry, sandboxed host-half lifecycle, and the inspect registry browser queries answer | provides ctx.dynamicCordisRunner and ctx.cordisInspect |
cordis-client-runner |
Browser half: evaluates a browser-half source into a live plugin and answers run requests | client face; provides browser ctx.dynamicCordisRunner |
ui-cordis |
Browser surfaces: the frame-wide panel, lifecycle tool cards, and the @pluginId input source |
client face; registers slots |
Related documentation
- Extensions subsystem — the generated
ctx.cordisInspectandctx.dynamicCordisRunnerservice API. - Generated tool catalog — the seven model-facing tool schemas.
- Generated configuration catalog — the runner's accepted config fields.
- Self-referential Cordis toolset Agent Note — design home for sandbox semantics, lifecycle, and composition.
- Client shells and dynamic packages Agent Note — package placement and build faces for the client halves.
Dev Note
Working context for maintainers — click to expand
The two browser-half packages live in this group rather than under packages/client/ because they are halves of this subsystem's dual-half packages; the client face compiles them through the client program, while the host program references only the host runner.