Harness spec 1.1.0: one plan, prototypes and the library shared; the CLI implements it
The spec: plan_write and plan_update (new, shared, offered in every mode) and plan_submit (now shared) keep one structured plan — findings, objectives, phases of tasks — in place of the todo list, which lives on as a former name of plan_write. The shared system text is one text for both projects, with variables for what differs; the mode texts, a prototypes block and a library block are shared. acp.md: the client hands the device what only it knows (context, library, prototypes), the plan travels as a structure (plan_state), library calls carry the chat's scope, and a client may rewind a session. loop.json says its numbers as numbers. Four conformance areas: plan, prototype, library_scope, toolcall_index. The CLI: the plan is kept per session in the store and drawn above the prompt and on the approval card; the prompt is assembled from the spec's texts with their variables filled; the link reads the instance's instructions, personalization, knowledge scope and prototype offer, sends the plan as a structure and answers rewind; library calls to the instance carry the session as scope; a prototype written in the terminal is saved as a file and named in the transcript; a tool-call fragment without an index continues the last call; the default theme is Moria; dead exports and Hermes leftovers removed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
96 files changed
+3259
-527
No files matched your search
@@ -6,6 +6,79 @@ All notable changes to LLeMbas CLI. The format follows
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
Harness spec 1.1.0: planning as one structure shared with LLeMbas.
|
||||
|
||||
### Added
|
||||
|
||||
- `plan_write` and `plan_update`, offered in every mode: the model writes its plan as a structure
|
||||
— title, summary, findings, objectives, phases of tasks — and keeps it current as it works
|
||||
(a task doing, done, or dropped with why; work added; a finding recorded). Ids (`p1`, `t3`,
|
||||
`o2`…) are given by the CLI, never by the model, and an unknown id is an error naming the known
|
||||
ones. The plan is the session's: it is stored with it, comes back on resume, and is gone on
|
||||
`/new`. The panel above the prompt shows the active phase, the task being done, what is next,
|
||||
the last two done and the count while anything is open; `/plan show` prints the whole plan
|
||||
with its ids, `/plan clear` drops it, and `/plans` says whether this session has one.
|
||||
- A `plan` block kind: a plan change is not drawn as a tool line in the transcript; the panel
|
||||
and the card follow the plan itself.
|
||||
- Over the link, an instance now hands the device what only it knows about a chat
|
||||
(`_meta.lembas` of `session/new` and `session/prompt`, capabilities `context`, `library`,
|
||||
`prototypes`): the chat's own instructions reach the prompt under `## Instructions from
|
||||
<instance>`, the account's personalization is used for that session in place of the device's,
|
||||
the knowledge bases the chat may search are named to the model, and whether it may write a
|
||||
prototype. A later prompt's context replaces the earlier one.
|
||||
- The plan travels as a structure (capability `plan_state`): the `plan` session update carries it
|
||||
as `_meta.lembas.plan` beside ACP's flat entries (null when cleared), `_lembas/plan` carries it
|
||||
with the card, `_lembas/session/status` answers it, and a session opened from the store says
|
||||
its plan at once.
|
||||
- `_lembas/session/rewind` (capability `rewind`): the web UI editing or regenerating from a turn
|
||||
takes that turn and every later one out of the conversation and the history — as `/undo`
|
||||
does, through the same store marking — without touching the files; a session a terminal runs
|
||||
is rewound there, and its transcript redrawn.
|
||||
- Prototypes in the terminal: a completed `prototype-chat` / `prototype-page` fence in a reply
|
||||
is saved as a file — the model's output as it is, under
|
||||
`~/.local/state/lembas/prototypes/<session>/<n>-<slug>.html`, never in the project — and drawn
|
||||
as one line saying where; `/prototype` lists this session's, `/prototype <n>` prints one's
|
||||
path. The prompt offers them only when the instance says so for the chat, or with
|
||||
`prototypes: true` in the global config for a terminal session.
|
||||
- The library's scope: every call to the instance's library made for a session the instance
|
||||
gave a library context carries `_meta.lembas.scope` (the session id), so the instance answers
|
||||
within that chat's bases and data group; `knowledge_search`'s `base` is read against the bases
|
||||
in scope as LLeMbas reads it — by id, then by name whatever its case, an unknown one answered
|
||||
with the bases there are (`resolveBase`).
|
||||
- Conformance areas `plan` (normalise, update, todos), `toolcall_index`, `prototype` and
|
||||
`library_scope`; an area the spec has and this implementation does not answer yet is skipped by
|
||||
name rather than failed.
|
||||
|
||||
### Changed
|
||||
|
||||
- `plan_submit` presents the plan written with `plan_write`, not a file: the card shows the plan
|
||||
with its ids, and a copy still goes under `.agent/plans/<date>-<slug>.md` for the record. Its
|
||||
`path` argument is kept for callers that send it and ignored. With no plan written it says to
|
||||
call `plan_write` first.
|
||||
- The system prompt is the spec's one shared text (`system/default.md`), with the CLI's facts
|
||||
filled into its variables — the opening line, the terminal as the surface, the file tools, the
|
||||
background-command and git sections, and the current plan with its ids on every step while one
|
||||
exists; the shared `blocks/library.md` and `blocks/prototypes.md` join it when their tools are
|
||||
offered. A bullet whose variable is empty is left out, and a variable left unfilled is an error
|
||||
rather than text sent to a model.
|
||||
- The loop's numbers come from the spec's `loop.json` (the step backstop, how many calls run
|
||||
together, how often an empty reply is asked again), and so does the wrap-up message, which now
|
||||
names the limit reached: "The time budget for this prompt has been reached…".
|
||||
- The default theme is `moria`, the LLeMbas web UI's own; `lembas` and `lembas-light` remain
|
||||
selectable. The working line is a plain braille spinner with the verb, without the faces, and
|
||||
the welcome box no longer carries the ☤ glyph.
|
||||
- A tool-call fragment streamed without an index continues the call started last, not call 0,
|
||||
so a server that numbers only the first fragment of each call no longer merges two calls.
|
||||
- A permission rule written for `todo` applies to `plan` (the key `plan_write` and `plan_update`
|
||||
are checked under), as `question` applies to `ask_user`.
|
||||
|
||||
### Removed
|
||||
|
||||
- The `todo` tool. `todo` is now a former name of `plan_write`: a call under it — from a stored
|
||||
session, an agent file, or a model trained on it — becomes one phase called "Work" with its
|
||||
items translated (pending → todo, in_progress → doing, completed → done, cancelled → dropped).
|
||||
- The `☤` glyph and the face frames of the spinner, from the TUI.
|
||||
|
||||
## [1.2.0] — 2026-10-14
|
||||
|
||||
### Added
|
||||
|
||||
Reference in new issue
Block a user