imccyu
eb1713f856
* fix(session-projection): keep released units in checkpoints Since the Cordis rc.11 teardown order unloads the Web layer before the base layer, Session Controller and harness-dev-context release their projection units before their live Sessions detach. The projection cache is still alive at that point and wrote a checkpoint holding only the units that were still registered, replacing the complete record. A blank Session then lost sessionListMetadata and listed as an untitled conversation after every graceful restart. A released unit now stays in the registry as a predecessor: it leaves event drives, snapshots, restores, and change notifications, while checkpoint() keeps each Session's last cell of it without advancing it. Registering the same key again replaces the predecessor and refolds the log. The projection cache keeps replacing whole records. * test(session-projection): assert frozen released units across unload tests Update the remaining unload tests that still expected a released unit to vanish from checkpoint(): user-approval, agent-loop inbox and scope lifecycle, time-context, and the agent registry now assert that the same Session keeps its pre-unload row, that a later event does not advance it, and that a Session created after the unload has no row. The token-meter and goal unload tests also append an event after the unload. Document that a retained handle read still advances a released cell that checkpoint() serves, and that restore() folds only live units, so its refreshed rows omit released units. * docs(session-projection): sync the ProjectionHandle type-equiv block * docs(session-projection): record frozen released units and their upgrade Add the upgrade guide for checkpoint() keeping a released unit's last row, update the registration-handles Agent Note with the frozen-cell decision and the retained predecessor, list both consequences under the registry README's known limitations, note in the projection cache README that a stored row can be frozen at its unit's release, and say that restoreFloor() ignores released predecessors. Update the agent-loop resource-lifecycle unload test, which read checkpoints through an alias, to the frozen-row semantics. * docs(upgrade-guide): mark the released-checkpoint snippet ignore-check * docs(session-projection): state the retained-handle path and narrow a rejected alternative * docs(upgrade-guide): re-record the released-checkpoint guide pairing
description, kind
| description | kind |
|---|---|
| Runtime API inspection, process-local runners, and historical Cordis cards. | package-group |
packages/extensions
English | 中文
Summary
The extensions group provides read-only runtime API discovery for agents, process-local runners for programmatic and browser consumers, and historical generated-plugin cards. Standard and Creator modes install persistent plugins through Plugin Manager. Choose a child package for inspection, Host execution, Client execution, or browser controls.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
tool-cordis |
Two read-only tools for runtime API discovery | registers on ctx.tools |
cordis-host-runner |
Host half: definition registry, sandboxed host-half lifecycle, and the inspect registry that answers browser queries | 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 panel and historical lifecycle tool cards | client face; registers slots |
Related documentation
- Extensions subsystem — the generated
ctx.cordisInspectandctx.dynamicCordisRunnerservice API. - Generated tool catalog — the two read-only tool schemas.
- Generated configuration catalog — the runner's accepted config fields.
- Self-referential Cordis toolset reference — 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.