A plan it can see is a plan it can keep

Plan mode produced a flat list of steps and then forgot it. Nothing told the
model to look before proposing, nothing let it ask when the scope was
ambiguous, and -- worst -- once execution started the plan was not in the prompt
at all, so it could not have kept it current if it had wanted to.

The shape is findings, objectives and phases of tasks now. Findings are the part
people skip and the part that makes a plan worth reading: what is actually
there, what surprised you, what the plan is working around. Plan mode is told to
research first and to ask with ask_user when the scope is genuinely ambiguous,
in one question rather than three.

steps is still always written, flattened from every phase in order. That is the
whole of the compatibility story: execute_plan reads it and needed no change,
and every row already on disk still works. services/plans.py:normalise is the
only place that knows version 1 existed -- a {title, steps} row comes back as
one phase, so the card, the harness and the Execute button have one shape to
deal with rather than two.

Chat.plan_message_id is what puts the plan in front of the model each turn, with
one primary-key lookup rather than a scan for "the newest message carrying a
plan" -- context_variables is synchronous and sits on the request path.
plan_update is offered only once there is a plan, because a tool for changing
something that does not exist costs a round to find out.

It is RISK_READ, and that sits in tension with notes_edit being RISK_WRITE, so:
risk is what a tool does to the world, and the world the four modes govern is
the machine. This cannot touch it. RISK_WRITE would put an approval card on
screen every time a task was ticked off -- four cards to carry out a four-task
plan, each approving a bookkeeping entry -- which is exactly the interruption
batching exists to prevent. A note is a durable artefact of the reader's that
outlives the chat; this is the chat's own record of what it is doing, nearer to
generation.status. An administrator who disagrees puts it in deny_default.

One thing that nearly went wrong quietly. A runner cannot write the message row,
since _persist is the single writer -- so plan_update returns the merged plan on
its event and the loop carries it. Both calls in a round would then have read
the same stale plan from the database and the second would have won. They merge
into AgentContext.plan instead, the snapshot seeded once when the context is
resolved. Both tools write event["plan"] so _persist stays one writer with one
rule; only plan_submit sets plan_final, which is what withdraws the tools.

The card does not re-render in place. The newest bubble carries the current plan
and older ones carry the plan as it was then -- that is what a transcript is
for, it needs no streaming machinery, and it makes "what did it think at step
three" answerable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/db/models/chat.py

@@ -144,6 +144,13 @@ class Chat(UUIDPrimaryKey, Timestamps, Base):
     # somebody's real working tree and deleting their work would be far worse
     # than an inconsistency -- so the harness says so instead.
     rewound_at: Mapped[datetime | None] = mapped_column(DateTime(timezone=True))
+    # Which message carries the plan currently in force. A plain id and not a
+    # ForeignKey, for the reason `compacted_through_id` below gives; validated
+    # on read. It exists so the harness can put the plan in front of the model
+    # with one `db.get` by primary key rather than a scan for "the newest
+    # message with a plan" -- `context_variables` is synchronous and on the
+    # request path. A plan a model cannot see is a plan it cannot keep current.
+    plan_message_id: Mapped[str | None] = mapped_column(String(32))
 
     # --- Compaction ----------------------------------------------------------
     # A summary of the turns up to `compacted_through_id`, sent in their place.
@@ -210,9 +217,11 @@ class Message(UUIDPrimaryKey, Timestamps, Base):
     tool_calls_json: Mapped[list[Any]] = mapped_column(JSONList, default=list)
     usage_json: Mapped[dict[str, Any]] = mapped_column(JSONDict, default=dict)
 
-    # A plan produced in Plan mode: {"title": str, "steps": [str, ...]}. Marked
-    # on the row rather than parsed back out of the prose, so the Execute button
-    # sends exactly what was proposed and not an approximation of it.
+    # A plan produced in Plan mode, or the state of one being carried out. See
+    # services/plans.py for the shape. Marked on the row rather than parsed back
+    # out of the prose, so the Execute button sends exactly what was proposed
+    # and not an approximation of it. Read through the `plan` property below,
+    # never directly: rows written before version 2 hold `{title, steps}`.
     plan_json: Mapped[dict[str, Any]] = mapped_column(JSONDict, default=dict)
 
     # Non-empty when generation failed. Rendered as a styled error in the
@@ -246,5 +255,18 @@ class Message(UUIDPrimaryKey, Timestamps, Base):
     def documents(self) -> list:
         return [a for a in self.attachments if not a.is_image]
 
+    @property
+    def plan(self) -> dict:
+        """The plan, always in the current shape.
+
+        A property for the reason `images` and `documents` are: a message bubble
+        is rendered from four different handlers, and every one of them would
+        otherwise have to remember to normalise. Rows written before version 2
+        hold `{title, steps}` and come back through here as one phase.
+        """
+        from lembas.services import plans
+
+        return plans.normalise(self.plan_json)
+
     def __repr__(self) -> str:
         return f"<Message {self.role} {self.content[:40]!r}>"