Run the Planner as a full Atomic session with questions routed to Decisions #215
The session closes after the “workflow started” reply, so later workflow questions never reach Decisions. Could we track owned workflows through `workflow_lifecycle` in `atomicTurnExtension`, then wait for them here before ending the stream or clearing `current`? Cancellation should stop those workflows and release the wait.
This needs changes in a few places, so there isn't a safe single-line replacement. Please cover the case where a workflow asks a question after the initial reply finishes.
Agreed, that was a real gap. It's fixed in the PR stacked on this one, #230, using a slightly different approach. Instead of holding the stream open until the workflow finishes, Chopin keeps the atomic Planner session and its owner binding after the turn whenever the session still owns live or paused workflow runs. It tracks them through Atomic's workflow activity stream and `workflow_lifecycle` events. So the chat turn ends normally, but later questions from the workflow still reach Decisions through the same session, and the next turn reuses it.
Cancellation is handled too: Stop Planner pauses the session's runs through `session.workflows`, and Resume Planner resumes them. The session is let go when its runs end, the owner binding ends, or the document closes. Covered by `a Planner that still owns workflow runs outlives its turn, pauses, resumes, and is let go when they finish`, plus a live run where the workflow asked its intent review well after the launch reply and was answered in Decisions.
Assistant-workflow: inline Assistant-verification: bun test passed: retention, pause/resume, and release tests in #230 Co-authored-by: Alex Lavaee <lavaman131@github.com>
Comments on earlier or unavailable lines
People need to see the supplied mockup or code before choosing. Including the preview in the description gives Decisions the missing content without changing the option labels or answers.
```suggestion description: [option.description, option.preview] .filter(value => value !== undefined) .join("\n\n"), ```
A long answer can make the saved document too large for the Planner to edit afterwards. Check it on a temporary copy first; if it doesn't fit, the real document stays unchanged and the question stays open. I checked this against the oversized-answer reproduction.
In `submit()`, replace the call to `room.projectAnswer(plan.document, msg.id, answers, settled)` with:
```ts let preview = await room.create(room.project(plan.document)); try { room.projectAnswer(preview, msg.id, answers, settled); room.validate(room.project(preview)); } finally { preview.doc.destroy(); } mutation = room.projectAnswer(plan.document, msg.id, answers, settled); ```
Confirmed and fixed in 6e7685e with your preview check. To reproduce it: with about 100 KB of prose in the document, four 50 KB edits (each under the 64 KiB edit limit) built an answer that saved a 302 KB document, past the 256 KiB limit, after which a Planner edit was refused. Now the submit is refused, the document is unchanged, and the question stays open. The new test fails without the check and passes with it.
Assistant-workflow: inline Assistant-verification: fail-before/pass-after passed: oversized answer refused with the document unchanged and the question open Co-authored-by: Alex Lavaee <lavaman131@github.com>
Applied in 6e7685e. The preview now follows the description, and the label and the returned answer are unchanged. The test checks an option with a preview and one without.
Assistant-workflow: inline Co-authored-by: Alex Lavaee <lavaman131@github.com>
Let's leave room for the date and ‘expired’ label before accepting a question. I reproduced a question fitting when it was asked, then pushing the document over its limit when it timed out. The Planner then refused a normal edit.
This suggestion reserves that room for new questions. It is only the first step: later text edits, added options, and new questions must also keep enough room for every still-open question to expire. Please add a test that makes those later edits, lets the questions expire, and checks that the Planner can still edit afterwards.
```suggestion export function fitsQuestionnaires(target: Document, values: Questionnaire[]): boolean { let tree = parse(project(target)); let at = new Date().toISOString(); // Reserve the metadata expiry adds to every card in this batch. tree.children.push(...values.map(value => questionnaireElement({ ...value, status: "expired", at }) )); return Buffer.byteLength(serialize(tree)) <= limits.MAX_SOURCE_BYTES; } ```
Fixed in b7994a8, starting with your suggestion. Asking a question now measures it, and every question already open, as if expired. The same reserve then bounds every later change: a Planner edit or replacement, a person's text edit, an added option, an accepted comment's decision, and an answer that settles one question while others stay open. A change that would leave too little room is refused and the document stays as it was. Only growth is refused, so deleting or trimming text still works when the document is already inside the reserve.
The test you asked for walks all of those in one sequence: each change is driven to just under the limit and refused, then a person's growing edit is refused while a shrinking and a fitting one are accepted. Finally every open question expires within the limit and a normal Planner edit succeeds. Reverting any one of the seven guards on its own fails it.
Assistant-verification: fail-before/pass-after passed: reverting each of the 7 reserves fails the combined test; bun test 1894 pass, 0 fail
Assistant-workflow: goal (run 6091839b-867c-4965-aec9-b583f62d4b1f) Co-authored-by: Alex Lavaee <lavaman131@github.com>