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>

harness/README.md

@@ -15,8 +15,8 @@ page [Harness-parity](https://git.houmeres.sk/LLeMbas/LLeMbas-CLI/wiki/Harness-p
 |---|---|
 | `VERSION` | The spec's own version, apart from LLeMbas CLI's |
 | `purpose.json` | The `purpose` argument added to a tool whose calls say what they are for |
-| `tools/<name>.json` | One tool each: name, `scope`, `risk`, `exclusive`, `block` (how a call is shown: `shell`, `edit`, `read`, `search`, `web`, `task`, `hidden`, `tool`), `purpose`, former names (`aliases`, per project), renamed arguments, the description and the JSON Schema of its parameters — exactly what a model is sent |
-| `prompts/` | The prompt texts; `prompts/index.json` says which are shared and which LLeMbas fragment each one is. `prompts/personality/` holds the personality presets both offer |
+| `tools/<name>.json` | One tool each: name, `scope`, `risk`, `exclusive`, `block` (how a call is shown: `shell`, `edit`, `read`, `search`, `web`, `task`, `plan` — not drawn, the plan card refreshes — `hidden`, `tool`), `purpose`, former names (`aliases`, per project), renamed arguments, the description and the JSON Schema of its parameters — exactly what a model is sent |
+| `prompts/` | The prompt texts; `prompts/index.json` says which are shared, which LLeMbas fragment each one is, and what each `{{variable}}` in a text means. `prompts/personality/` holds the personality presets both offer |
 | `permission/hardline.json` | The floor: commands refused in every mode, protected paths, and how a command is spelled plainly before it is checked again |
 | `permission/arity.json` | How much of a command an "always allow" covers |
 | `permission/defaults.json` | The rules every session starts from |
@@ -35,7 +35,27 @@ page [Harness-parity](https://git.houmeres.sk/LLeMbas/LLeMbas-CLI/wiki/Harness-p
 - **Scopes:** `shared` — both projects implement it; `cli` or `llembas` — only that one. The same
   two names key what is per project elsewhere: a tool's `aliases`, `loop.json`'s budgets, a
   protected path's `scope`.
-- A tool's other names, per project, are listed in its `aliases` and work as the tool.
+- A tool's other names, per project, are listed in its `aliases` and work as the tool. A former
+  name may have taken different arguments; the project converts them. The one such case:
+  **`todo` → `plan_write`**, `todos[]` becoming one phase called "Work" (`pending` → `todo`,
+  `in_progress` → `doing`, `completed` → `done`, `cancelled` → `dropped`; `conformance/plan.json`).
+- **The plan** (`plan_write`, `plan_update`, `plan_submit`) is one structure both keep per session —
+  title, summary, findings, objectives, phases of tasks with a status each, ids given by the
+  implementation and never by the model — shown as a card in every UI and put into the prompt
+  (`{{plan_context}}`) on every step while it exists. `plan_write` and `plan_update` are offered in
+  every mode; `plan_submit` only in plan mode, where it is the approval. Their permission key is
+  `plan` (`permission/defaults.json`), which a rule written for the former `todo` key still reaches.
+
+## 1.1.0
+
+Planning as one shared structure: `plan_write` and `plan_update` (new, shared, in every mode) and
+`plan_submit` now shared; `todo` folded into `plan_write` as a former name. The shared system text
+(`system/default.md`) is now one text for both projects, with variables for what differs;
+`modes/*.md` shared; `blocks/prototypes.md` and `blocks/library.md` new and shared. `acp.md`: the
+client hands the device what only it knows (`context`, `library`, `prototypes`), the plan travels
+as a structure (`plan_state`), the device scopes library calls to the chat (`_meta.lembas.scope`),
+and a client may rewind a session (`rewind`). `loop.json` says its numbers as numbers. Four
+conformance areas: `plan`, `prototype`, `library_scope`, `toolcall_index`.
 
 ## 1.0.1
 
@@ -52,17 +72,23 @@ default rules and the four modes; model metadata; the loop; the quirks of real s
 conformance cases; and `acp.md`, the link between the two projects (`_lembas` protocol 2, every
 feature beyond protocol 1 gated on its capability string).
 
-## Variables in a description
+## Variables in a description, and in a prompt text
 
 A description may hold `{{name}}` where the two projects differ in a fact, not in design — a
 timeout's default, whether commands may run in the background, which subagents exist. The tool's
 `variables` says what each one means; each project fills them before sending the description, and
 none may reach a model unfilled.
 
+A prompt text may hold them too, declared in `prompts/index.json` under its entry. The same rule,
+and one more: **a line that is nothing but a bullet and a variable (`- {{name}}`) disappears when the
+variable is empty**, so one text serves a project that has the fact and one that does not.
+
 ## Changing it
 
 1. Change the spec first, and bump `VERSION`: **patch** for a text or a new conformance case,
-   **minor** for a new tool, rule or field, **major** for a rename or a removed tool.
+   **minor** for a new tool, rule or field, **major** for a rename or a removed tool. A tool folded
+   into another, its name kept as an alias that still runs, is minor: nothing stored or trained
+   breaks.
 2. A fix comes with a **conformance case** that fails without it. In LLeMbas CLI,
    `bun run harness record` fills in the expected result of a new case from the implementation,
    and `bun run harness record --all` shows every case whose result would change.