8d7c4380aa
`session.history` built its projection baseline in `historyStateFor` and only then awaited `presenterScopeFor`, which is what ensures the recorded preset's standing mount. The unit table is process-wide while the units themselves are registered by preset rows, so on a first cold read the baseline was serialized before `todos` (and every other preset-owned key) existed, and every later read served a complete one. Until this branch, a web lane happened to mount a preset in `beforeAll` for unrelated reasons, which hid the ordering. The baseline is now a thunk the handler reads after the scope resolves. Also covers the roster-less early return of the unjoined-agent warning, which the per-file coverage gate reported uncovered.
preset/ — per-session agent composition
English | 中文
An agent preset is a directory holding one agent.cordis.yml. Mounting it under an agent's scope context gives that session its own tools and prompt sections while every other live session keeps its own, so one process can run several differently composed agents at once.
| Package | Role | ctx key |
|---|---|---|
agent-presets/ |
Preset vocabulary, filesystem discovery over trusted and user-authored roots, and the guarded per-agent mount | ctx.agentPresets |
persona/ |
The agent persona as a composable row, so a preset can change identity and not only tools | — |
The presets the deployment ships live in apps/cli/config/agent-presets/ — one directory each, and that directory listing is the roster. Naming them here too would be a second list to keep in step, and the first one to fall behind.
The composition split this group assumes: registries and cross-session facilities are process singletons and stay in the host composition, while a preset carries what one agent contributes to them. A preset that names a row publishing a process-global service is rejected at mount rather than allowed to collide with the next session.
Design: the per-session agent-preset note.