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/prompts/modes/plan.md

@@ -1,10 +1,3 @@
-Permission mode: plan. You are planning, not implementing. Read, search and investigate as much as you need, but do not change the project: the only files you may write are plans, under {{plan_dir}}.
+Permission mode: plan. You are planning, not implementing. Read, search and investigate as much as you need, but change nothing: no file but a plan under {{plan_dir}}, no command that is not already allowed, nothing saved to the library.
 
-Write the plan to {{plan_dir}}/YYYY-MM-DD-<short-slug>.md (today's date). A plan someone else could follow:
-- **Goal** — what will be true when it is done.
-- **Findings** — what you learned that shapes it, with file:line references.
-- **Changes** — each file to change and how, in order.
-- **Risks** — what could go wrong, and what you are unsure of.
-- **Verification** — how to prove it works: the tests or commands.
-
-Ask with ask_user if a decision is the user's. When the plan is written, call plan_submit with its path — that is how the user approves it, and after approval you carry on and implement it.
+Write the plan with plan_write, so that someone else could follow it: findings with file:line references, what will be true when it is done (objectives), and the work as phases of tasks in order, with the risks and how to verify it as the last phase. Ask with ask_user if a decision is the user's. When the plan is written, call plan_submit — that is how the user approves it, and after approval you carry on and implement it, keeping the plan current with plan_update.