Saved Project knowledge plans opened as an empty editor whenever the
viewer could not resolve the owning project from the current directory:
managed chats (openchamber:chats is not a registered project), worktrees
outside the repo path, and plan tabs restored after a reload. Titles
still rendered because the list reads the manifest through the correct
owner.
- Thread the owner explicitly (savedProjectPlan = { projectRef, planId })
from the panel, mobile surfaces, and persisted context tabs; PlanView
no longer guesses the project.
- An unrecognized directory resolves to no owner instead of borrowing
the active project's knowledge.
- Serialize plan writes per document (planSaveQueue) so close/switch
within the autosave debounce no longer drops the last edits, saves
cannot land out of order, and a recovered save clears the error banner.
- Send saved-plan contents inline in Improve/Implement prompts (they
have no file path); disable those actions for managed-chat plans,
which have no project directory to create a session in.
- Drop persisted plan tabs that carry an id without an owner rather than
reopening them against a guessed project.
`useBtwPanelState` already subscribes to the composer's own session — it is
what the fork link is derived from — so asking `useSession` for the same
session and directory a second time in `ChatInput` was a duplicate
subscription for a value already in hand. Expose it as `parentSession` and
read the promoted flag from there.
No behavior change.
Review catch: `promoteBtwSession` removes the btw metadata, but the
boundary instruction is persisted on every message the session sent while
it was a side conversation, and there is no API to delete a message part
after the fact. A promoted session therefore keeps reading "no sub-agents,
do not touch the workspace" out of its own history, in a session that is
no longer a side conversation.
Promotion cannot delete those lines, so it answers them instead:
`withoutBtwSessionMarker` now leaves `openchamber.btwPromoted`, and the
composer sends `BTW_PROMOTION_NOTICE` with every message in a session
carrying it — stating that the session is now the main thread and the
usual tool, sub-agent and workspace permissions are in force.
It rides with every send for the same reason the boundary does: the
instructions it revokes are re-read on every turn, so a one-shot notice
would lose its position relative to them as the conversation grows.
`btwPromoted` is additive and optional. A session that never went through
`/btw` never has it, and one promoted before this change simply keeps the
old behavior.
Two related fixes to what a btw session inherits and shows.
**Fork point.** `/btw` is typically typed *while* the main thread is
working — that is the moment a side question comes up. Forking at HEAD
then clones a turn that is still streaming, so the fork inherits a
truncated assistant message and the user instruction that provoked it as
the newest, most salient thing in its context. Fork at the parent's last
completed assistant turn instead, read from the sync store with no extra
round-trip. A parent with no completed turn yet keeps the previous
fork-at-HEAD behavior.
**Boundary.** `filterBtwTailMessages` shows every inherited message when
the boundary is `null`, and the boundary is `null` whenever the
newest-cloned read comes back empty. That is correct for a fork of an
empty parent, but it also turns an empty read into "nothing was
inherited" for a fork that demonstrably did inherit history — the panel
then opens with the parent's whole transcript in it. Having picked a
fork point proves the parent had turns, so fall back to that id instead
of `null`. The fork's own messages are created later and still sort
after it, so its tail stays complete either way.
`/btw` forks the session, so the model receives the parent's whole
conversation — including whatever plan was in flight when the user typed
the command. Nothing tells it that this history is context rather than
its own task, so the fork frequently carries on with the parent's work
instead of answering the side question, which is the opposite of what
`/btw` is for.
Send a boundary instruction as a synthetic part with every message in a
btw session: with the first question in `startBtwSession`, and with each
later send while the panel is expanded and the composer is talking to the
fork.
The wording is deliberately position-independent — it names the history
inherited from the parent thread rather than "everything before this
boundary". The instruction rides along with each send instead of being
pinned once at fork time, so a positional phrasing would be re-anchored
every turn and would end up telling the model to disregard the btw
session's own earlier turns.
The part is synthetic, so it is filtered out of the rendered transcript
whenever the message also carries user text — which is always the case
here. No visual change.
Bohdan Triapitsyn