# Design notes

**English** | [简体中文](./design.zh.md)

Why Whalesong Studio is shaped the way it is: how a loose list of wishes was folded into a few mechanisms, and what each decision trades away. After reading it you should be able to tell where a new requirement belongs without reading the code first.

## 1. From thirteen wishes to five questions

The starting point was a list: separate the orchestrator from the prose writer; whole-book / outline / local / world / character revision modes; one-click outline and cast from an existing manuscript; ensemble casts with character lifecycles; a world and a persona system; retrieval and long context; style; a UI to manage characters and plot, skim, search and mark what to change; a reading mode and chapters; illustrations; audiobooks; motion comics; a way to step into a scene and role-play it, perhaps as a live visual novel.

Built one by one, these become thirteen features that do not know each other. Grouped by the question each one answers, there are five:

| Question | Wishes | In the design |
|---|---|---|
| **Who writes?** | orchestrator vs writer | five roles: showrunner, writer, architect, analyst, director |
| **What is remembered while writing?** | world, persona, the lives of an ensemble, retrieval / long context, style | one canon + layered memory + a context packer |
| **How is it changed?** | the five revision modes, one-click import | one proposal mechanism at five granularities; import is digest run backwards |
| **How is it seen and handled?** | management UI, reader, chapters, marking | the Studio: a global page and a tab beside the conversation |
| **What can it become?** | illustrations, audiobook, motion comic, role-play / visual novel | the Stage: pipelines that share the audio script as their hub |

The conclusion: these are **not several creative tools but several working modes over one canon**. A mode changes what the showrunner attends to and may touch; the data is always the same data.

## 2. Who does the work: a crew

A book is worked on by a small company: the **showrunner**, who talks with the author; the **writer**, who writes; and four roles that do the rest — **continuity** (场记: digests chapters into memory, reviews them, takes in manuscripts), the **planner** (策划: derives outlines and beats, drafts the bible, explores what-ifs, researches), the **director** (导演: audio scripts, storyboards, interludes) and **post-production** (后期: cuts a chapter's voice, sound and pictures into a video).

**The showrunner is the session's agent.** There is no separate orchestration service: the agent of DSH (DeepSeek Harness) already plans, calls tools, compacts context, tracks todos and asks questions. The plugin ships a preset that gives it the showrunner's instructions, the `novel_*` tools and a project digest that travels with the conversation.

**The writer is a model role, not an agent.** Prose needs no tool loop; it needs a context prepared for this one call and a stable system prompt. So the writer is one model call inside a pipeline: brief in, context packed, model called, output cleaned, text saved, memory digested.

### The other four are agents of DSH

A call is the right shape for work that is one question with one answer. Little of what these four do is that: reviewing a chapter means holding it against the chapters around it and the characters' cards; deriving an outline means reading what is already written, and now and then looking something up; finding the chapters of a scraped manuscript takes looking and trying; cutting a video takes writing a script, running it, looking at the result and correcting it. Where a rule or a single prompt has to guess, an agent can check.

So the four are **not four prompts but four agents**. What sets one role apart from another is exactly this list, and nothing in the machinery:

| | What it is | For example |
|---|---|---|
| Prompt | A persona (who it is) and standing rules (how it works in the crew) | Continuity "records and judges only by what the book actually says" |
| Skills | Guides loaded when the work calls for them, shipped in `crew/<role>/skills/` and listed for that role alone | Post-production's `novel-video-editing`, the planner's `novel-trend-research` |
| Tools | The Studio's: `book_read` / `book_search` to read the book, and the tool this piece of work is handed in with; plus those of the conversation's tools the role's work calls for | The planner has `web_search` / `web_fetch`; post-production has `bash` and file tools |
| Permissions | The permission mode of the conversation that started it, with anything that would need approval refused; the book itself changes only through the Studio's tools | Post-production writes only in its working directory |
| Model | One per role, or the conversation's | Post-production takes the model that codes most reliably |

They run on **DSH's own agent loop**, through DSH's own delegation seam: a role's run is a **subagent**, started through `ctx.subagents` under the conversation that asked for the work, by a provider this plugin registers. What DSH does for every child it then does for a role — the child joins its parent's composition (so the author's own tools, skills and instructions are within its reach), takes its parent's permissions with approval pinned to "never", counts against the delegation depth, and is **entered in the parent's catalog of subagents**: open it from the conversation's header and every step of every run is there, with its tokens and its time. What the provider adds is what makes it *this* role: persona and rules, the Studio's tools, its skills, and which of the conversation's tools it sees. Everything else a loop needs — model requests and their retries, tool calling and argument validation, a durable session log, the token meter, cancellation — is DSH's; the Studio keeps no second copy.

**Work is handed to a role in one of two shapes.**

- *Work with a deliverable* (digest a chapter, review one, derive five, direct a script, cut a storyboard…): the role gets the task and its material, the tools to read the book, whatever of the conversation's tools it may use, and **one tool to hand the result in with**. What it hands in is validated on the spot; what is wrong with it comes back as the tool's failure, and it hands in again. Handing in ends the turn — so where the material is complete, an agent's run is one request, no dearer than a call. Everywhere a pipeline used to "ask a model for a JSON", it now goes this way.
- *A task in words*: the showrunner gives a role a task with `novel_crew` ("research how the Shanghai post worked in the 1930s and propose two scenes for chapter four"); the role reads the book and looks things up, and reports in a paragraph. It does not change the book — what is taken from its report, and how, is for the showrunner and the author.

**Work that has everything in its task is one request.** What an agent is for is that it can look things up in the book. Some work has nothing to look up: cutting a chapter into an audio script, digesting a chapter, laying a storyboard over a script, fitting a prompt to what a model reads, sorting the notes an author jotted down, telling a life in a paragraph from what the digests noted, learning a style from samples, looking at open issues again after a revision, laying the foundation of a new book, parting a book into volumes from its chapters' summaries — all of it is in the task. Such work is one plain call whatever its role is set to (`Assignment.plain`): a set of tools and a dozen steps would only add to every request what it has no use for, and room to wander. Whatever reads the text or the bible — a review, the cast, ties, signature scenes, growth, deriving chapters — is an agent as before.

**When it is not an agent, that is said.** A role can be set to plain calls under *Settings → Crew* (one question, one answer: faster and cheaper, and blind to the rest of the book); and when an agent hands nothing in, or cannot run at all, the same work falls back on one plain call. Both are written on the job — who worked, in which way, in how many steps, and why — never done quietly.

**How many tools a role has is the author's call.** By default a role has its own tools and those few of the conversation's that its work calls for. *Settings → Crew* can open "all of DSH's tools" for a role — whatever the conversation has (a shell, files, the web, MCP…) — except, always, the showrunner's own `novel_*` tools and the ones that need a person in the room (questions, goals, further delegation). These settings apply to every book, or travel with one.

**Outside help.** When post-production cannot cut a video well itself, it may hand the work to another agent that writes code. That is not a wheel the Studio reinvents but DSH's own subagent: with `@deepseek-ai/dsh-subagent-claude-code` or `@deepseek-ai/dsh-subagent-codex` installed, the rows of `@deepseek-ai/dsh-tool-subagent` already mounted in the preset turn `subagent_claude_code` / `subagent_codex` into tools; without them, those rows do nothing.

The tools carry the guard rails, because a tool can check what a prompt can only ask for. Taking in a manuscript: a cleaning pattern that would delete a fifth of the book is refused; a pattern that backtracks without end is cut off after three seconds; "titles" that read like sentences are told apart by the numbering, and the report carries the correction ready to copy; a run out of steps leaves its soundest split behind. Cutting a video: a result is taken only if it passes the checks — a picture, a sound that is not silence, a length that matches the telling, no long black stretches — and a path outside the working directory cannot be handed in. Every run has a budget of tool calls; once it is spent, only the tools that close the work still answer.

Why do text models come only from DSH? Because the agent loop takes DSH's models and no others. A Studio that connected other vendors' text endpoints itself got roles that could not be agents, and models to configure in two places. So every text model comes from DSH's *Settings → Models* — connect whichever vendor there — and the Studio configures only what is its own: the models that draw, speak and search. (A role saved with an endpoint of its own by an earlier version keeps working, by plain calls only; the Settings screen says so.)

The roles take separate models because their demands conflict: the **planner** must reason and diverge (outlines, bible development), **continuity** must be fast, literal and attentive (digest, review), the **director** must be quick and keep to a format (scripts, storyboards, and you wait for it on every move of an interlude), **post-production** must code reliably. Unset roles fall back (planner → writer; director → writer or continuity) and finally to the conversation's model. "One model for everything" and "the best model for each step" are two ends of the same setting.

What is not an agent yet: the writer (by design — see above); a turn of an interlude, which is still one call of the director's — you wait for it on every move, and an interlude is itself one continuous conversation, so the shape it wants is one standing director agent per interlude, which is the next step; and the small one-line-in, one-line-out jobs (an illustration's prompt, a style sample).

The showrunner is told not to *write* manuscript prose itself: prose that bypasses the writer's pipeline bypasses the bible, the characters' current states, the style. But a conversation is full of changes that are not writing — the author dictates a sentence, pastes a paragraph of their own, wants a name put right — and routing those through a model that rewrites is slow, costs money and is not exact. So the showrunner has hands of its own for exactly that (`novel_edit`: replace, insert, append, delete, set), and uses them when the words are the author's, when the change is mechanical, or when the author asks it, in so many words, to write something itself.

### One road for every change

The first version drew the line between the showrunner and the book by prohibition: use the tools, do not touch the files. Used for real, that left the showrunner with too little it could do directly — and nothing stopped it from reaching for a raw file tool when its own tools did not fit, changing a chapter with no version kept and with memory still describing the old text. The author's words for it: the main agent "偷偷暗改", out of step with memory and the bible.

The answer is not more prohibition but one road, wide enough for everything:

- **Every kind of change has a tool**, and each tool does the bookkeeping: the text as it was becomes a version, the chapter's memory is digested again, search is re-indexed, and the result tells the showrunner where the change leads — the cards of the characters it names, the chapters written after it. What memory records wrongly can be corrected directly (`novel_memory`) rather than by hoping a second digest reads better.
- **The road around is closed, gently.** A raw `write` or `edit` (or a shell redirect) aimed at a book's own files is refused with the name of the tool that does the same thing properly. It is the author's setting, not the showrunner's, and can be loosened to "ask me" or "let it through".
- **What gets around anyway is seen.** The Studio tells its own writes from anyone else's by the state of the file, not by timing; a chapter changed by an editor, a script or a tool that was let through goes on the record and is digested again, and the showrunner's context says that it happened.
- **Nothing changes the book unseen.** The overview carries the book's record — what the showrunner did with its tools, what was done from another device, what changed from outside — with one-press undo for manuscript edits.

This is what "agent-native" comes to here: the conversation can do everything the screens can, and what it does is as visible and as reversible as what a hand does on a screen.

## 3. What is remembered

**A book is a directory.** Markdown for what a human writes, JSON for structure and machine memory, so the author can open their book in any editor, version it with git, and the agent's file tools can read it when needed. All writes go through one locked project object that also watches the directory, so outside edits show up live.

**Personas.** Beside the biography, a character card has a structured persona: traits with intensity, values in priority order, speech habits, lines never crossed, behaviour under pressure. Its purpose is concrete: voices blur in an ensemble when cards hold only adjectives; the writer needs executable constraints. The same card carries the character's appearance, design sheet and voice. Consistency of looks and voice does not rely on model memory — every call restates the same appearance and sends the same reference picture or clip (see *One look per book* below).

**A life, not a label.** A card carries no status. It once did — planned, active, offstage, retired, dead: one word for where somebody stands in the book — and the word was taken away, because a book is not one straight road. It has lines of the plot that part, and chapters written again long after the ones that follow them; "dead" holds on one line from one chapter on, and written on a card it is wrong on every other line and in every earlier chapter — and all it speaks of is how far the story has got.

**Three ways of writing a chapter.** Chosen in the settings, switched on the writing page, and laid side by side by a comparison — the same model, the same brief, a draft by each. *Packed by rule*: the Studio puts the context together by its standing rules — the nearest chapters, whoever is named, what a search turns up — and the writer writes in one request. *Prepared by the planner*: the planner looks at what the chapter needs, reads in the book, chooses, and hands the writer its material; one request. *The writer as an agent*: nobody prepares anything. The writer is given the work and what it stands on (the plan, what it was planned with, the book, the core of its world, where the chapter joins) and reads the rest for itself; it **hands the text in** with a tool, and the text is then its draft to work on — read over, a place changed, the whole of it handed in again, as often as it sees fit — until it **calls the work done**. A run that stops without that leaves what was handed in and says so; where a length is asked for, the tools say where the text stands against it. A writer whose model cannot run as an agent, or whose run hands nothing in, does not leave the chapter unwritten: it is written in one request, and the result says why.

**A chapter with beats is written by its beats.** Asked for ten thousand words at once, a model brings the chapter to its end in five thousand and stops — not cut off: done, as it sees it. And nine beats in one reply get little room each. So a chapter whose plan has beats is written in parts wherever the writer writes in one request, whatever length is asked for (`partBeats`: three beats to a part unless set; 0 is the way it was — one go, parts only where the length needs them): each request with the same material and the text so far (the head of the request stays what the provider has kept), told which beats are its own, where to stop, and — but for the last — not to close the chapter. A length asked for is shared out by beats, and what an early part fell short of is made up over the later ones; with none asked for, each part's length is the writer's to judge. Every beat gets its room, and the chapter comes out longer than one written in one go: that is the price, and the setting is there for whoever does not want it. What comes out more than 15% short of a length asked for is said, to the author and to the showrunner.

**The default way is the settings'; the writing page picks for itself.** Which of the three ways a chapter is written by is a setting — packed by rule unless the author has it otherwise (their word of 2026-10-14; for a few releases before it the planner prepared by default) — and a book may have its own, kept in its `novel.json`, which holds for it in place of the Studio's. The menu under the brief box of the writing page picks another for what is asked for from that page — kept while the page is open, said beside the menu, and no change to the setting.

**Whoever works beside the writer writes nothing where the chapter is shown.** The planner reading in the book to prepare the material, or in the references, the scribe digesting the chapter afterwards — all of it happens in the writing job, whose text is the chapter on the page. What they do is said on the job's progress line; it used to be written into that text, where a planner's `book_read chapter …` lines and a digest's reply stood in the chapter's place.

**The digest is no part of the writer's request.** What follows a chapter is a request of its own by the scribe, with the chapter's text and the lists of names; its reply is not shown where the chapter was being written (it used to be: its stream replaced the writing job's, which read as a chapter ending in a great deal of "memory"). A digest that fails leaves the text saved, and is said.

**A chapter's memory is of one draft, not of the chapter.** Beside the memory itself a digest leaves three things in the book: the blanks of the chapter's plan filled in (where that draft took place, when, who was in it, which threads it touched), a mark on every thread it planted, advanced or paid off — and a new thread for one nobody had named — and suggestions for the places and things it met. All of that says what a draft turned out to be, not what was meant for the chapter. So a chapter that is **drafted anew goes without its own memory**: the writer is handed the plan as it was meant (what a digest filled is marked `fromText`; in a plan filled before that, a synopsis, place or time that holds to the letter what the digest gives is taken for the digest's), the threads without that chapter's marks, and no thread that only its digest proposed; the planner preparing the material is shown the chapter as unwritten, and reads nothing of the old draft through its tools either. Packed by rule, two drafts of one chapter are sent the same request to the letter — what is left between them is the temperature. A chapter gone on with, revised or reviewed is taken as it stands. A chapter **digested again takes back** what the digest before it left — marks, blanks, suggestions — before it writes its own; a field of the plan the author has set since is the author's. And a memory can be **cleared** (the memory panel beside a chapter, the chapter's menu in the outline, `novel_digest forget`): the digest and the three things go, the text stays, a digest brings it back — while the chapter lists say of every chapter whether it has a memory, a stale one, or none. What cannot be told apart is left: a cast or a list of threads that an older version's digest filled into a plan carries no mark, and an entry of the bible that came of an accepted suggestion is the bible's by now.

**Who is worth a card is the planner's to say, once it has looked.** A digest notes everybody a chapter meets, the doorman as much as the rival. Each new name used to become a "new character" suggestion, and a long book buried its cast under a hundred of them. A digest proposes nobody now: every name without a card is on the list of walk-ons (read off the digests, so none is lost), and once a batch of chapters has been digested the planner looks through the names it has not looked at yet, side by side and against the book, and says of each what it is — **worth a card** (a suggestion, with its reason and how large a part), **another name** of somebody (a suggestion to fold it in), or a **walk-on** (left on the list, with why). The judgement is the planner's; there is no threshold of appearances. Unsure of somebody seen once, it leaves them a walk-on, and is asked again when they are seen in more chapters. Nothing is done for the author: a card and a folding-in are suggestions, and a walk-on can be given a card by hand at any time. What an older version proposed chapter by chapter is looked through in the same pass. The pass after digests can be switched off; the button stays.

Where somebody is in the book is a record: where they come on, the chapters they are in, where they are away, come back, leave or die. That record needs no keeping of its own: every chapter's digest already notes who was in the chapter, what they went through, how they stood at its end, and whether they came on, left, came back or died there; laid out along a line of the plot those notes are the life, and so it is always what the text says. Laid out along another line it is another life: somebody dead on one line is alive on the one that parted earlier. Beside it a card has the life told in a paragraph — continuity's to write from the digests, the author's to edit.

A digest misses things and gets things wrong, and there are things no digest can see — somebody dead before the first page. So the author can write a **mark** of their own: comes on, comes back, leaves or dies at a chapter, or was dead or gone before the story begins. It is still no label: it is an event of the life, with its chapter — it holds on every line of the plot that chapter is read on and on no other — and it holds over what the digest says of that chapter. After a death or a leaving the author wrote down, later chapters that have the person only remember them; to bring them back, the author writes a return.

What the writer sees follows from it, for the chapter in hand and along that chapter's own line: everyone's card, the same whatever the chapter (so the head of the request does not change from chapter to chapter, and a provider's cache holds) — leads and supporting parts whole, the rest a line each; for the people of the scene, their state after their last chapter and a line of theirs from the text; and a list of who is out of the story *as of the chapters before this one* — the dead, who may be mentioned and must not appear alive, and those gone for good, who do not come back unless the outline brings them. Somebody who dies in chapter 16 is alive to whoever writes chapter 5 again. Presence is computed from digests as well, so "who has been away for ten chapters" is a fact, not a recollection. In the Studio everyone's life stands in one table (People → Lives): a row a person, a column a chapter, read along the chosen line.

**Layered memory.** After each chapter the analyst extracts a one-line brief and a summary; hard facts; each character's state, place, mood, what they learned and a representative line; entities new to the bible; threads planted, advanced and paid off; the reader's open questions. Every ten chapters roll into an arc summary. Far-away story is coarse, recent story is fine, the last pages are verbatim. Memory carries a hash of the text it came from, so edited prose shows as undigested.

**Context packing — an outline of what came before, and a window of the text itself.** The story before a chapter is given in two layers. *The text*: the whole chapters closest to this one, verbatim and in order, within a budget that defaults to half of what the model can read (500,000 tokens for a model that reads a million; a figure of your own if you set one). Whole chapters only — a chapter that does not fit is left out, never cut. *The outline*: one line per chapter for everything older (ten chapters roll into an arc summary further back), with the plan's own summary standing in for a chapter that was never digested, so no written chapter is ever simply absent. While the manuscript fits, the outline layer is empty and this is "the whole book"; once it does not, near is verbatim, far is summarised, and retrieval only fetches a few passages back out of the far part. The window comes from the role's own figure, DSH, the endpoint or a table of common model families; a model nobody can place is taken to read 200,000.

*What follows is given too.* Rewriting or revising a chapter in the middle of a book, the chapters already written after it go in as well — nearest first, whole chapters, summaries for what does not fit — with the instruction that this chapter must lead into them, not contradict them and not use up what they are about to tell. The text before keeps priority; the text after keeps at least three tenths.

*The order is built for the provider's prefix cache.* A request is two blocks. The first does not depend on the chapter: book, core world, the whole cast (full cards for the leads, a line for the rest), the outline of what came before, the text. Writing the next chapter, that block only grows at its **end** by the chapter just written. The second belongs to this call alone: the text that follows, the present state of the people in this chapter, open threads, relevant lore, retrieved passages, the chapter ahead, the chapter so far, this chapter's plan, the brief and the length. Three things keep the first block still: the writer's system prompt no longer carries the length or "you are continuing"; the heading of the text says where it starts, not where it ends; and the window does **not slide by a chapter at a time** — it holds its starting chapter until the text no longer fits, lets go of the oldest quarter at once, and holds again. So nearly every chapter of a writing run is "the last request plus one chapter", and what the provider reports as read from its cache is recorded in the ledger and shown with the result.

Retrieval is hybrid: BM25 over CJK bigrams and Latin words, optional embeddings, fused by reciprocal rank. "Retrieval only" (the cheapest) and "fill the window" can still be forced in the settings.

**Length is a budget you may give — or not.** A chapter can carry a recommended length, in its plan or as a figure for the whole book; the writer is told "about N, give or take 15 %". **Give none and the writer judges**: it is told that no length is set — write each beat of the plan out fully, without padding or hurry — and how long the chapters already written run on average. New books are no longer stamped with "3,000 words a chapter", and the 3,000 (2,500 in English) nobody chose on older books no longer counts. The showrunner is told that length is the author's to give and not to invent one.

**The plot graph — a story may go more than one way.** The volumes of the outline are the **main line**: the book as it is read, exported, voiced and staged. Beside it there can be other **plot lines** — another way things could go that the planner derived, a stretch that was played in an interlude, the plan that was there before the outline was rewritten. A line **leaves** after a chapter, may carry the choice made at the fork, and may **join** another line at one of its chapters; so the plot is a graph, drawn as one under *Outline → Plot graph*.

- *Rewriting the outline asks what becomes of the old one.* Deriving chapters can start after any chapter and either append, **replace** what followed, or **open a line** so both ways stand. Replacing loses nothing written: if any replaced chapter has text, the stretch is kept as a shelved line that can be found and made the main line again; only chapters with no text are dropped.
- *Lines can be handled.* Rename one, state its choice, join it to another line, shelve it, remove it — or **make it the main line**: the chapters it runs through become the book's order, and the stretch of main line it replaces becomes a line of its own, leaving and joining at the right places.
- *Choosing a line at the next chapter.* The Write view lists one line at a time (what it shares with others is dimmed) and switches between them; after a chapter where the story forks it asks which way to write next. The showrunner asks the author in the same situation.
- *A line's chapters are chapters.* Written, digested, reviewed and staged like any other, with "what came before" being the line's own reading order. One difference: **what happens on a side line stays there** — someone who dies on a side line is not dead in the book. Cards and the main threads follow the main line; a line's memories are folded into the bible when it is made the main line.
- *The plot is a graph, and it can be re-wired by hand.* A chapter — or a run of them — moves elsewhere on its line, onto another line, or onto a line opened for it (a name, and the chapter it leaves after; none makes it a story of its own from the first page): a side story imported among the main line's chapters is parted from it so. One dialog does it, and the plot graph, the outline and the writing page all open that one. A chapter is found by its id, so its text and whatever was made from it go where it goes; lines that leave after it or arrive at it follow. A move that would tie a line into a knot — a line leaving after one of its own chapters, a way round in a circle — is not made at all, and is not offered. Where a line leaves can be said again at any time, in the line's own dialog.
- *A line reads itself.* A book may hold several stories that are apart from their first page and share one world. So whoever works on a line — the writer of its chapters, a role deriving, reviewing or staging them — is handed, and can read with its own tools, **that line** and nothing of the others: its text and digests, its people, its threads, and the world the lines share. Another line is another story as far as that work goes. Every line counts its own chapters (a line that parts counts on from where it parts); "chapter 3" read by a role is that line's third. Whose a character is needs no marking: as the card says where it says, else where they are — in a line's chapters by their digests, or cast by their plans — and a card no chapter has yet is every line's. The bible's entries are the world the lines share until they are filed — not guessed from where the text happens to spell a name out, since an entry the whole book stands on may be named on one line only. Three ways file them. The digest that finds a thing says whose it is as it reads the chapter — in a book of several lines it is told which story the chapter is of, and answers of each new thing whether it is that story's alone or the world's; a thing of the story alone is filed, when its suggestion is taken up, under the lines that read the chapter (its own, and whichever part from it later — when that is every line, under none), and is not handed to the others. Where a digest did not say, a thing found beside the main line is that line's and one found on the main line the world's. The author files a batch at once; or the Studio files a batch by the text (what every line has, or none yet, is left). The bible's pages list the line in hand: its own above, what the lines share in a group of its own, and what is filed under none on its own. A thread is the lines' that planted or advanced it, and one paid off on the main line still waits on a line that parted before. The book's premise is the main line's: a line apart from the first page is told by its own name and what the author said it is about. What crosses over is named: somebody a chapter's plan or the task itself names is given whichever line they are of, and what happened on another line is the showrunner's to read (it is kept to no line) and to pass on in its brief. Who a name is goes by the story too: a line that parts from another tells that one's story on, a line apart from the first page is another story, and a name in a chapter is somebody of that chapter's story. A narrator's "我" is a different person in every story; a proper name borne by a card of another story is the digest's to judge — come over, or a namesake — and whoever is told apart is kept under the name with their story after it. *Whose card a digest's note on somebody is, one place says* (`whose`, from `Project.castResolver`), and every reading of a digest asks it — who is on a line, a life, the walk-ons, the cast a digest fills into an empty plan, the pointing of digests at cards after a cast is consolidated. What a digest settled as it read the chapter stands (it says so on the note: `by`). An older digest left an id only — and an id is made of the name: it holds within the stories its card is of, and in another story the note goes by its name again, as that story has it. Which stories a card is of is told by what does not go by a name: the lines the author filed it under, the chapter it first appeared in, the plan of a chapter not digested yet. So two stories' narrators, mothers and bosses that an earlier "a name is whoever bears it, anywhere in the book" put on one card are told apart *as they are read* — the book is not to be digested again for it — and the one that is not the card's is, in its own story, a walk-on without a card. On the bible's pages a line shows what is filed under it, then what the lines share (what its story names, or no text names yet), and last, folded, what is filed under none while only other stories' text names it — theirs in all but the filing, with one press to file it by the text.
- *An interlude can become a line*, not only a chapter: it leaves after the chapter it was played from, the session is its first chapter and the player's first move is the choice.
- *Reading follows a line too*, and at the end of a chapter where the story forks the reader is offered the ways on, each labelled with its choice. That is the step towards a story one can choose through: the graph, the choices and the chapters on each way are already data.

**Style** is its own object: point of view, tense, tone, diction, rhythm, imagery, dialogue, rules, a "never" list, sample passages. The "never" list does the most work. Styles can be learned from a sample, tried on a test scene, and switched per book.

### Material prepared before the writing: the planner looks at the piece, the writer reads what it is handed

Context packed by rule has one fault that cannot be tuned away: it does not know what is being written. The nearest chapters go whole, whoever is named nearby goes, what a search turns up goes — most of it nothing to do with the piece, and the one line the piece turns on not always among it. The writer writes in one request and has no tools: of the book it knows what it was handed.

So where the author asks for a piece of writing — a chapter, a chapter gone on with, a selected passage rewritten, a chapter written over — **the planner looks first** (`materialBy: planner` — for every book or for one; where nothing is set a piece is packed by rule, the quicker way):

- It is told the work (the author's words, the chapter's outline, the thinking it was derived with, the passage or the chapter as it stands) and shown what the book has by name and size: every chapter's number, length and one-line summary, the names of the people, of the bible's entries, of the threads.
- As an agent it reads for itself (`book_read` / `book_search`), as far as the piece needs, and hands in the **material**: in its own words, what is asked of the writer, where the story stands, what must not come out wrong, the form, what of the voice matters this time; and by name — whose cards go whole, which entries, which threads, which chapters word for word, which in outline, which stretches of text (opening and closing copied from the chapter).
- What it hands in is checked on the spot: a name no card has, a chapter not on this line, words not found in the chapter they are said to be from, more than the budget holds — each sent back with what is wrong.
- The Studio puts what was chosen together with what goes whoever prepares it — the book's particulars, the bible's core, the chapter's outline and its derivation, the end of the chapter before, the passage or chapter worked on, the reference notes, the author's guide pictures. The writer reads the planner's task and situation first, the outline last.

**A small book lies before it whole.** Where a line's text, cards and entries come to no more than a figure (`context.plannerWholeTokens`, 32,000 unless set), all of it is in the one request the planner answers; no agent loop is run — on a book of a few thousand words the loop fetched every chapter and every card one by one, fourteen requests and some 370,000 tokens (mostly cache hits) for what one request gives. A larger book it reads in for itself.

**The old way is kept.** `materialBy: rules` is it; the line under the brief box of the writing page and the small menu beside the rewrite buttons switch on the spot. Where the planner cannot be asked, or nothing it hands in will do, that piece is packed by rule and the result says why — a piece is never left unwritten for want of preparation.

**The two can be read side by side.** With both ways ticked in the writing page's comparison every model writes a draft by each; a draft says which way it was written by and how large its material was, and *Read it* opens all its writer read (kept beside the draft's version, and gone with it). What the latest ordinary piece of writing on a chapter read is kept on the chapter (`.novel/material/<chapter>.json`).

The honest account: preparing is one more round of model calls. Writing chapter 41 of an eighty-chapter book, the rules hand the writer 436,000 tokens; the planner's material was 29,000 — and the planner itself took 23 steps in 15 requests, 720,000 input tokens of which 650,000 were cache hits. What is saved is not money: it is that what the writer reads bears on the piece.

## 4. How it is changed

| The author's mode | What happens |
|---|---|
| derive the outline | the architect reads memory and threads and proposes chapters, beats or what-if branches; you review before anything enters the outline |
| local revision | select a passage → the writer rewrites only that, with its surroundings as context → a proposal |
| chapter revision | **changed where it stands, never written again**: the writer, as an agent, reads the chapter and changes the places the instruction reaches with a find → replace tool (the settled ones in one call); what it does not touch is not output, and so cannot drift. What comes back is not "the chapter revised" but **the places that changed** — a small proposal each, settled one by one or together. A writer whose model cannot run as an agent is asked once for a list of changes, and the Studio makes them. Only a change that is of all of it (another voice, another point of view, another order of scenes) is a chapter *written over* — a menu entry of its own, and what the writer says when places will not do |
| whole-book revision | **by places too**: the planner names the places the request reaches (quoting each word for word, a sentence or two), the writer rewrites those and nothing else, each a small proposal of its own, grouped as a batch. Only where the request is one for the whole of a chapter (style, voice, point of view), or so many of its sentences change that they run together, does the planner name the chapter to be written over. Chapters the author names are the only ones the planner is shown and may change |
| world / character revision | change the bible first, then start a whole-book revision that carries the change through |
| mend what a review found | **by places, never a chapter written again for it**: an issue that quotes the text has the quoted place rewritten; one that quotes nothing (a contradiction, a missing word of explanation, pacing) has the planner settle which place mends it — a problem can usually be taken hold of in more than one, and the one that changes least is chosen, in whichever chapter — and the writer rewrites that place. A batch: tick several issues (across chapters), say a word on each, and the planner reads them side by side and names the places that change — also in chapters nobody named that tell of the same thing — each a small proposal of its own; or hand over every issue from a severity up in one click. A chapter is written over whole only when the author asks for it by name (the issue card's ⋯), or the planner says places will not do. Once proposals are accepted, the reviewer reads what is still open against the text as it now stands: what the change settled is marked, what reads differently is brought up to date. **Mendings do not lock each other out**: another can be asked for while one runs, and a small triangle beside the button says how it is taken — **in line** (the default) after the ones before it, going on from the changes they leave waiting, so that they agree; **apart** at once and by itself, for mendings that have nothing to do with each other (another line, a far part of the story) |

Shared rules: changes are **proposals** with a diff (revisions started in the Studio always; the showrunner's apply directly unless you ask to review them); the previous text is **snapshotted** before anything applies; a passage proposal goes **stale** when its target text has since changed — better that than pasting a rewrite in the wrong place; mutating tools **ask first** in read-only sessions.

**How far a mending reaches is a setting, and by default it goes through.** Mending by places began with rules that all pulled one way — *as little as will do*, *what one place mends is not mended in two*, *the sentence or two that have to change*, *this problem and nothing beside it* — and the proposals that came of them often changed one sentence: of a paragraph with three similes too many, the one the review happened to quote; of a telling that read like the bible recited, a line slipped in between two others. The author's word of 2026-10-12: the proposals are too conservative, be more active. `mendReach` has two values. **`bold`** (also where nothing is set): the problem is mended through — every place it shows; of a contradiction the end that does not hold, and both where both sit ill; what one change leaves not agreeing with it (an echo later on, how somebody answers, the same thing told again) is a place too; a place **takes in enough** — the sentences that have to move together, a paragraph that has to be written again whole; a short passage is written new where it takes one. An issue mended at its quote (style, language, pace) hands the rewriter **the paragraph the quote stands in** (`widenedPlace`: a short line of talk with the paragraph on either side; never across a picture's line; the quote alone where that would be the greater part of the chapter), told where the problem shows and that the rest of the passage may move. **`careful`**: as it was. It holds for every change by places — issues, a review led by the author, a revision through the book, a chapter gone through to an instruction — and is set on the first page of the settings, in the small menu beside the buttons that mend, in an issue card's menu and under the triangle beside *Mend the chapter*; the showrunner passes `reach` only when the author says how far this one is to go.

**Bold is not loose.** Three things hold either way. The mechanical guards: a place quoted word for word, found once in its chapter, overlapping no other, never the greater part of a chapter, a picture's line never part of it — and a proposal still narrowed to the sentences that changed, so however much was taken in, what came back as it stood is not in the diff. The plot's course is not changed under cover of a mending, and faults that have nothing to do with it stay. And **what the text taken in told is all still told, and nothing is made up**: the first two bold runs on a real chapter, turning a recited backstory into question and answer, invented a year and a surname and dropped a line the text had; said as a rule of its own — with the hand-in held against the original item by item — the third run's planner listed what it had kept. It is a sentence in a brief, not a guarantee, which is why every place is still a proposal with its diff.

**A place is a place: pinned, found once, and no wider than it has to be.** What the planner quotes of a place is all the writer may change — so, held to the least change, it is asked for the sentence or two that have to change (and, mending through, for as much as has to move); the quote has to be found once only in its chapter, and one that stands more than once ("She nodded.") is sent back at once, to be quoted with the half-sentence beside it. The writer is told that only the words inside the place change and that what the instruction does not speak of goes back as it stands. What comes back is then narrowed to **the sentences that changed** (whole sentences; where a sentence was only added or taken out, a neighbour stays in as a place to find; widened again by a sentence until it is found once). A proposal knows where its passage stood (`at`): where the same words stand twice in a chapter, the one it was made for is the one replaced, not the first.

**A chapter is revised the way a file is edited, not the way a text is rewritten.** Asked to change one chapter, the writer used to hand the whole chapter back: of a thousand words perhaps eight sentences had to move, and the other nine hundred were generated again too — slow, paid for in output, and free to drift. Now it works on a copy of the chapter with three tools: `chapter_edit` (`find` → `replace`; `find` has to stand once in the chapter, `all` changes a word throughout, `edits` takes several places in one call), `chapter_read` (the chapter as it reads now) and `submit_revision` (the hand-in, with a word on what was changed). Every call is checked on the spot — a passage that is not there, one that stands in more places than one, an entry that takes in most of the chapter, a picture added — and refused with what to do instead; a picture's line is never part of a place. Handed in, the copy is held against the text **sentence by sentence**: each stretch that differs is a place (with the sentence beside it where something was only added or taken out, and widened until it is found once), and each place is a proposal with the reason the writer gave for it — so the proposals are finer than the writer's own changes. A model that cannot run as an agent, or an agent that got nothing done, is asked once for `{"edits": [...], "note"}`, carried out by the same rules (what cannot be made is said back once). An agent that broke off after some places leaves those places standing, and the result says it may not have finished. This is one role in one run because nothing has to be traced through the book first: the places are in the chapter in front of it.

**A review can be led by the author.** A review used to be one thing: the scribe reads a chapter from its first line and lists what it sees. But an author reading their own book often *knows* what is wrong already — "his glasses come and go", "the days between chapters 3 and 4 do not add up" — and a general review is the long way round to it. So the author says it in a sentence (*Review → Issues*, the bar at the top; the same bar, kept to one chapter, in the writing page's issue panel and over the reader's page; and where the chapter is edited — *Something is wrong here…* on a selection, whose passage goes along as where the author was pointing, and *Mend the chapter* beside the brief box, which is this review of the chapter with the sentence written there; the small triangle beside it holds the other ways — the chapter gone through to a brief (the former *Revise*), the finding alone, the chapter written over), and the planner goes into the book for it. It **finds it first**: each place it shows is quoted word for word (a quote the chapter does not have is sent back), with what is wrong there and what it does not agree with, and filed as an issue of that chapter's review, marked *Yours* with the sentence that found it — only where something is wrong: of two places that do not agree, the one that is right is not filed. Then it **mends it** in the same run: the places that change, each a small proposal shown beneath the issue it is for (a change at the other end of a contradiction is listed with the batch). *Find only* files and changes nothing; nothing found files nothing and tells the author where the planner looked. It is looked for in the book as it stands — what the author noticed, they noticed in the text they have, and an issue quotes that text — so changes still waiting are not laid in first. A chapter that holds only such issues was never reviewed (`unread`): it still says *Not reviewed* and still gets its review; and a new review of a chapter keeps what the author had found there while it is open. One run finds and settles, and what the task gives whole is not read again with a tool — every tool call of an agent sends the whole task once more (a chapter's scope takes a step or two; the first version, not told so, read the four chapters it had been handed again: 27 steps). The showrunner has the same function (`novel_revise scope=lead`).

**What a job sent can be read from the job.** The author's word of 2026-10-13: a review by their own sentence showed its thinking and nothing of the request, and "in Jobs, every kind of job should let me see the request that went out". A role working as an agent makes its requests on the Harness's loop, where the record of calls did not reach; and where the book has no conversation, that run's own record cannot be opened either. So each request of a run is put on the book's record by the role runner as it goes out — the system prompt, the tools offered, what is new with this request, the reply — a step naming the step before it in place of repeating it. And the way in is the job: every row of Jobs has *Requests*, opening that job's calls and no others.

**Review and revision are one bar, under one name.** The author's word of 2026-10-13: "the page is called Review and revision; the planner judges what I ask by itself, and with nothing asked the default is a review; the same for the changes of that kind where the book is written — the many like features under the same name and the same logic." There had been two forms for one pipeline: *Review by a lead* over the issues (a fault the author noticed: found, filed, mended) and the *Book-wide revision* tab (a change the author wants: carried out) — the same sentence box, line and chapters, the same button, and a line between "fault" and "request" that an author does not draw before speaking. Now there is one (`ReviseBar`): **nothing said, a review** — the button says what it will review; **a sentence said, the planner tells what it is** (`mendTask` with `lead`) — a fault is found where it shows, filed as issues of its chapters and mended beneath them; a request is carried through the places it reaches, nothing filed, the changes one round of proposals; and its note to the author says which it took it for. The bar is the same on the review page (a line of the plot or chapters of it, with pictures to go by and a changed card or entry said for the author), in the writing page's issue panel and over the reader (the chapter in hand); the button beside the writing page's brief box is it too — *Review* while the box is empty, *Revise* once something is said — and so is *Review and revise…* on a selected passage. The names follow: what was mend / fix / change in Chinese is 修订 throughout this family, and the settings read *who writes a revision*, *how far a revision goes*. (Rewriting a selected passage and writing a chapter over are the writer's work on a text, and keep their names.)

**What a review or a revision is handed: four layers, steadiest first; claims rest on quotes; what is on file is not done again.** The author's word of 2026-10-14: a mechanism that wastes less context, keeps more in the cache, gives the model more to go by, hallucinates less in reviewing and carries out the author's intent — and that settles proposals made without knowing of the others. Every review of a chapter and every pass of the planner starts from the same four layers: the book's base (what it is, its style and what the author added for whoever writes it, the author's notes, everybody and everything of the bible a line each, the outline, the threads still open — the same for every pass of the book), the story so far as a summary a chapter (only ever added to at its end, so the head of one chapter's request is the head of the next one's; a map, not the text), the chapter in hand (its plan, where its people stood, how the chapter before ends, its text), and last what this piece of work is about. It used to start from the earlier text word for word, as much as half the window holds: on a copy of the 84-chapter *Dream of the Red Chamber*, chapter 41 began at 333k tokens and begins at 53k now; chapter 84, 503k against 74k. What a review says the chapter is at odds with (continuity, timeline, world, character) it quotes, with where it stands (`against`), and the quote is looked for there: sent back where it is not found, let go of after two sendings, and an issue that quotes nothing is filed and marked unchecked. `book_find` finds every place some words stand in one call; `context.readTokens` caps what a pass reads (40k tokens unless set). What is on file — the issues still open, the changes that wait, the changes the author turned down — is said to every pass, which files nothing on file again, proposes no refused change again, and takes in no sentence a waiting change takes in; under it, one place has one change waiting (`proposeSpan`): the same words again are no new proposal, other words take the earlier one's place. An issue on file stays through a new review unless the reviewer says the text no longer has it (`gone`) or its words are gone from the chapter; said again, it keeps its id and what waits for it. Where reviews hand their findings on, the reviewer closes each issue one of three ways: a small change written out (the proposal, no further call), a passage described for the writer (who is handed the place, what stands around it and that — nothing of the book is packed again), or another chapter's to change (the planner traces it); what is the author's to decide waits. A change accepted settles the issues it names with no call, and only issues whose words it moved are read again.

**A review hands what it found on to be mended.** The author's word of 2026-10-13: saying a sentence about a chapter comes back with the changes filled in beneath what was found, and a review — the more thorough of the two — came back with a list and nothing else, "which is odd". So a review is followed by its mending unless the author switched that off (`reviewMends`, first page of the settings and the small triangle beside the buttons that review): the open issues of the chapter that nobody was handed yet go to the planner together — the very mending *Mend together* starts, with the same settings for who writes and how far — as a job of its own, started when the review ends. The issues are there to read while it works; each says it is being mended; its ending is said. A batch of reviews is followed by one mending for all of it, which is also the better mending: one planner reads what was found across the chapters side by side. Nothing enters the text: every change is a proposal beneath its issue — and since that is where they are read, that is where they can all be taken at once (*Accept all* over the issue list beside a chapter, over a chapter of the review page, over the page).

**Who writes a change made by places is told place by place.** Two models, two prices: the crew's reads and settles, the writer's writes prose and is as a rule the dearer — and each place handed to it sends what stands around the place once more. So where nothing is set (`mendBy: auto`, the author's word of 2026-10-14: *a word or two it should not hand to the writing model — only what takes more writing*) the planner tells for each place: a small change it writes itself in the answer that names the places (`replace`), a place where a passage is to be written it hands on (`how`). It is a judgement, so it is the agent's: no count of characters in code decides it, the task says where the line runs (a sentence or two against a paragraph), and the result says how many places were whose. An issue mended at its quote is asked of the planner in one request for the same reason an agent's loop is not used: the steps would cost more than the mending. The two older ways stay as settings — every place the crew's, every place the writer's — and what follows describes them. **By the crew's model:** Mending by places was the work of two models: the planner settles the places and how each changes, and the *writer's* model rewrites each — so that finished prose stays the writer's. But a model fit to write chapters is not always fit for a small change pinned to a sentence or two. `mendBy` (the first page of the settings, and the small menu beside the buttons that mend) says who writes: the crew's (the default, the author's word of 2026-10-12) — then the planner hands in what each place *is to read* (`replace`, with a word on why) in the same answer that names the places, and that is the proposal; or the writer's model, as it was. It is told how the book is written; a place that reads as it did, or that says how to change without the finished words, is sent back. It holds for every change by places — issues mended, a review led by the author, a revision through the book, and a chapter gone through to an instruction (that agent is then the planner) — and for the quoted place of an issue. **A passage rewritten and a chapter written over are a second setting**, `rewriteBy` (the first page of the settings; the small menu beside *Rewrite* on the writing page and beside the buttons that mend): the writer's model by default — a selection polished, expanded, tightened or changed to an instruction, a chapter written over whole, and the chapters a mending says cannot be mended by places — or the crew's, for an author whose writer's model does not rewrite to an instruction well. They are two settings because they are two kinds of work: a change pinned to a sentence wants exactness, a passage or a chapter rewritten wants prose. Drafting and continuing are always the writer's. Two things came with it: what a role reads with its tool is what its hand-in is checked against (a mending that goes on from waiting changes reads the chapter with them laid in — it used to read the plain text, copy from it, be sent back, and go round); and paragraphs are parted the chapter's way (a single line break in what a model hands in becomes the empty line the chapter keeps between paragraphs).

**A proposal turned down is kept, and can be put back.** Turning one down only marks it; *Review → Archive* lists what was turned down (and, for the record, what was accepted), the latest first, a round together, and the writing page folds the chapter's own under the ones that wait. Each can be **put back** to wait or **accepted** after all; a round goes back in one press — for the *Reject all* that was a slip. One whose sentences are gone from the chapter says so. What a later proposal took in is not there: nobody turned it down.

**Once the text has changed, its plan may be behind.** A chapter's plan — synopsis, place, time, point of view, cast, beats — was laid out before the chapter was written; a text written otherwise than planned, edited by the author, or changed by a revision leaves it saying what the text no longer does, and it is the plan that a writer rewriting the chapter, the director cutting it into panels and the planner deriving what follows go by. So a written chapter has **Update the plan from the text** (and *Beats only* beside it): the continuity editor, in one plain request with the text and the plan there is — a beat that still fits stays word for word (its id too), one that does not is changed to the text, what the text does not say of place or time stays as planned; the chapter's purpose, the notes for its writer and its threads are not its to touch. The plan as it was is in its history. A button, not a thing done behind the author: a plan may be ahead of its text on purpose.

### A passage rewritten: what bears on it, not the book

(The author, 2026-10-12: rewriting a selection to an instruction hardly does anything now — is it how the context is laid out?) It was. Measured in a test book of eighty chapters: to rewrite one paragraph of 159 characters in chapter thirty, the request ran to **433,000 tokens** — a passage was rewritten with what a chapter is written with: half the window in the text of the twenty-nine chapters before, and the fifty after whole as well ("this chapter has to lead into them"). The author's instruction was the last line of all that, under rules that said to keep whatever it did not ask to change and never to contradict what was written. What came back was the passage, copied, with three or four phrases added.

- **The material is the size of the work** (`context.passageTokens`, 24,000 unless set; per book too): the bible's core, the people, the story around the chapter — the nearest chapters word for word as far as they fit, the rest in outline — and the passage's **own chapter** around it, 4,000 characters before and 2,000 after. A paragraph changed is not a chapter written.
- **What is asked stands where it is read**: before the passage, and once more at the end.
- **Which gives way**: the instruction is what the revision is for — what it wants different (what happens, how somebody bears themself, tone, how much is told, the way of writing) is made different, sentences rewritten where they have to be; and where it differs from the bible, the outline or the text around, it holds — that is what the author wants changed. Where it says nothing, canon holds as before.
- Run on the same paragraph, the same instruction ("make him impatient, heavy-footed, vexed at the maids dozing") and the same model: 433K → 19K input tokens, 18 s → 4 s; of the original's 21 clauses, 19 came back word for word before and 13 after, the sentences rewritten.

What it teaches: **a context is right for the work it was made for.** "The outline of what came before, and a window of the text" was set for writing a chapter; it was used as it stood for rewriting a passage because that shared a cache. A small piece of work handed a whole book is not made safer by it — the one line that says what to do is drowned.

### A chapter revised: its neighbours, not the book — and itself, always whole

The author, next: "is the mending of issues handed too much context as well?" Every way of mending was measured on an 80-chapter test book (490,000 characters, a model with a window of a million, chapter 41):

| Way | Sent | |
|---|---|---|
| A chapter written over whole | **436K** (counted) | what a chapter is written with: nearly every other chapter word for word |
| A chapter gone through in place (an agent) | the same, **again with every step** | seven steps: three million |
| A chapter reviewed | about 290K a step | the forty chapters before (500K at the last chapter) |
| An issue mended by places the planner names (one, book-wide, several together) | 30–38K a step | 23K of it a summary of every chapter of the line, 6K the chapter the issue is in |
| A review led by what the author noticed | 8K a step for a chapter, 25K for the line | |
| The quoted place alone | 22K, once | as of the section above |
| Issues checked again after a change | 6K, once | |

The planner's ways are small; the two that hand a whole chapter over were not. The rewrite sent with 436K — "change the ending: she does not fall asleep on his bed" — came back after 67 seconds **identical to the chapter, character for character**.

- **Revising a chapter has a size of its own** (`context.chapterTokens`, 60,000 unless set; per book too), for both: the chapters next to it word for word (about two before and two after at 7,000 characters a chapter), the rest in outline; people, threads and lore as the chapter touches them. **The chapter itself comes besides, whole.**
- **The chapter that is revised or reviewed always travels whole** (`ownsChapter`). Its text used to take what the side budget had left and was cut to its end when that ran out — a rule made for going on with a chapter, which is read for where it stops. With a small budget (a model with a small window; a context cut to size, as here) a rewrite or a review got the chapter's last three thousand characters. Now it does not compete: where the window is short, the other chapters' text gives way.
- Same chapter, instruction and model: 436K → 54K tokens in, 67 s → 51 s; the first 5,807 characters untouched, the ending rewritten as asked. One real run of a chapter gone through in place: 7 steps of 56–61K (412K in all, 348K of it cached), 34 s, seven small proposals.
- **Reviews are as they were**: a review holds the chapter against what came before, and the text of that is of use to it — whether it should be cut down as well is the author's to say. The planner's summary of every chapter grows with the book (23K at 80 chapters) and has no ceiling yet.

What went wrong on the way: the first version set the limit and forgot that the chapter's own text is given its place last — a real run proposed the chapter at 2,395 words for 5,456, its first half gone. It showed only when each section's size was printed. **Changing a budget, print what every section got, not the total.**

### Translation: the names first, then chapter by chapter

Hand a model a book of several hundred thousand words a chapter at a time, and the first thing to break is not the prose but the **names**: one person is Shen Heng in chapter three and Shen Hang in chapter forty; one thing has two renderings. A model does not remember, so nothing is left to its memory:

- **A glossary is what a translation goes by** (`bible/glossary.json`, one a language): people's names and what they are called, places, houses and organisations, things, the book's own words — one rendering each.
- **Settled first, translated after.** Where the book has cards, continuity settles the names off them — **who somebody is decides how their name and their forms of address come out** (a man or a woman; a nickname or a name). A book with no cards yet (a manuscript just brought in) has its proper names found in the text. What is settled stands: every pass only adds.
- **A chapter is sent with the terms it uses**, each with what it is — not with the whole glossary. A translator (the writer model) that meets a name without a rendering settles one and hands it back; it is added, and later chapters go by it.
- **Afterwards the cards learn their names**: the rendering becomes another name the card goes by. The digests, the marks on names in the text, the context of the next chapter all tell people by a card's names — so Shen Heng in the translation is still 沈蘅.
- **The author has the last word**: the glossary is read and corrected in the translate dialog; what they set is marked theirs, and no later pass writes over it. A name rendered badly is corrected in the glossary, not in a chapter.
- **The translation takes the text's place and the original is kept**: as a version of the chapter (*before it was translated*); the chapter says *From …* beside its title, and its menu puts the original back, title and all. A picture's path in the text is not touched.
- **Two ways in**: *Translate…* in a chapter's menu on the writing page (this chapter, or every written chapter of the line; a long chapter goes stretch by stretch, each in the voice the one before ends in; several chapters at a time), and *The manuscript is in* on the import form — a manuscript in another language is translated into the book's as it comes in, and digested, carded and outlined from the translation.
- When every written chapter is in the language, it is the book's language (what it was is kept on record).

### What was changed is kept: versions of everything written

A chapter's text always had versions; a character card, an entry of the bible, a style, a chapter's plan, a thread, the book's own info had none — the showrunner changed a card, the director rewrote an appearance, a field was cleared by a slip, and how it was before was gone. They now keep versions one way:

- **A version is the thing before a change**, named by when and by what changed it: the author, the showrunner, a job by its name ("before *Writing the appearance* changed it"), a version put back, a deletion. One is kept only when what the thing *says* changes — not for a picture, not for what the Studio keeps by itself (first and last appearance, where a chapter stands), not for a save that changes nothing.
- **A sitting of the author's own edits keeps one**: the thing as it was before the sitting, not one for every press of Save. What somebody else — the showrunner, a job — made of it in between is kept all the same.
- **Pictures are no part of it.** A picture stays for as long as nobody deletes it; a version put back leaves the card with the pictures it has now. A version is about words.
- **What is shown is the difference, and one field can be put back alone.** *History* lists the versions; beside them, every field in which the one chosen differs from the thing as it is now, as a diff — the whole version goes back, or one field of it. What the thing was until then is kept first, so putting back can be undone.
- **What was deleted can be had back.** A card, an entry, a style is kept as it last was when it is deleted; *Deleted…* at the foot of its list restores it — or removes it for good.
- **One control, the same everywhere** it applies: people, entries, styles, the art direction, a chapter's plan, threads, the book's info — and the showrunner reads the same record (`novel_manage action=history / restore_history`).

**Import** is digest run backwards: split chapters → digest each → merge character moments into cards and entities into world entries → rebuild the outline and threads from the summaries → learn the style. It reuses the everyday memory pipeline, so an imported book is indistinguishable from one written here.

## 5. How it is seen and handled

One component tree, two doors: a **page** in the left sidebar (the bookshelf, no session needed) and a **tab** in a session's right sidebar. The tab is where the integration lives: when the showrunner calls the writer, the chapter streams into the editor beside the conversation; a selection can be rewritten directly or handed to the conversation with its chapter reference; each `novel_*` call in the transcript reads as "which model was asked to do what" and opens the Studio at that place.

Principles that run through the eight views (overview; people — everyone's card together with the table of lives, the relationship graph and the walk-ons, so that whatever is about people is on one page; bible — world, prose style, art direction; outline; write; read; review; stage):

- tell the author the next step — the overview is a to-do list, not a dashboard;
- selection is the entry point to change — not "enter a mode, then find the place";
- model output is a suggestion by default — bible suggestions, revision proposals, derived plans all wait for a yes;
- long work is visible and stoppable — and stopping a draft keeps what was written when that overwrites nothing;
- narrow rooms are first-class — layouts follow the container's width, because the tab is often 450 px wide.

### One click, and many at once

Doing a thing to one chapter is a button; doing it to fifty by pressing fifty buttons is a punishment. Whatever is "the same thing for many chapters, people or places" is therefore **one job**:

- **Stage → Produce**: a table of every chapter's progress (script, voice, sound, storyboard, pictures, video); tick the steps and the chapters and press once. When a chapter's script is set, its voice, its sound and its storyboard go on together; pictures follow the storyboard; the video is cut when all of it is there. Several chapters move down the line at once, the first started finishing first.
- **Write → Write a run**: chapter after chapter — beats derived where there are none, each chapter digested before the next begins, so every chapter has read what the last one just wrote. Without writing, beats, digests and reviews run for many chapters at once.
- **Gallery → Draw a batch**: design sheets and place sheets first; portraits, chapter illustrations and the cover wait for them and are drawn from them; each character's own voice can be made in the same go.
- One chapter has its one click too: "Make the audiobook" (script + voice + sound) on the audio page, "Produce this chapter" (everything) on the comic page.

Three rules hold for every batch. **Only what is missing**: each step looks for work before starting, so a batch that was stopped, or that had failures, is finished by running it again. **A failure breaks only what depends on it**: the steps of that chapter that needed the failed one do not start; every other chapter goes on, and the job ends with a list of what was not made and why. **All of it is visible**: every step of every chapter is a cell of one live table, and the agents' runs are listed under the conversation as always. The showrunner does the same with `novel_batch`.

**Concurrency is something else, and it lives in one place.** How many requests are out at once is not decided per job but by four gates — speech, pictures, sound, text — each counting everything that uses it, whichever chapter or job it belongs to. The default is 8, the ceiling 256, both in the settings. When a service answers "too fast" the gate slows itself (halves, pauses), sends the refused requests again instead of dropping them, and climbs back a step at a time once things go through — saying so on screen while it lasts ("speech is being rate-limited: 8 → 4"). The figure can therefore be set high without fear: the real limit is the account's quota at that service, and it is found by running into it, not guessed.

### Conversation first; screens for seeing and fine-tuning

This is an agent-native application, so the most direct way to use it is not to click through screens but to talk to the showrunner in a session. Three rules follow:

- **Whatever a screen can do, the conversation can do.** Every operation behind a screen has a tool, including the settings (`novel_settings`: read and change the model roles, run a one-click setup, edit the book's own information) and the small hand edits (`novel_manage`: restore a version, change a line of the audio script or a panel of the storyboard, settle a review issue…). A screen is not the only door to a feature; it is where a person **sees, checks and fine-tunes**.
- **The showrunner can show you a screen.** `novel_show` opens a screen, a chapter or a tab of the stage in the author's window — "show me the outline" opens it rather than describing where to click. The Studio appears beside the conversation the first time the showrunner goes to work; after that, keeping it open is the author's call.
- **What is on the right can be seen on the left.** A picture opened large in the Studio has *Quote to chat*: what it is and its path land in the conversation's composer (`〔图：立绘 · 沈蘅｜assets/images/….png〕`; copied, where the Studio is not beside a conversation). The showrunner looks at it by that path with `novel_look`: the picture is read through the Studio and handed to the model as an image block beside the tool's words — the way DSH's own `read_image` does it — so **a picture of a sealed book, or of one on the private shelf, is seen too**, where the file on disk is ciphertext that can neither be copied out nor opened by a file tool. Where the conversation's model takes no pictures, the model set up to look at them says in words what each shows. One thing to know: a picture looked at is kept by DSH's attachment store, unencrypted, like any picture attached to a conversation; the conversation itself is sealed with its book, that copy is not.
- **A dialog waits for its author.** One that asks for a direction or a number does not start the work the moment it opens — *Derive the next chapters* on the writing page once did, before anything could be filled in.
- **What is shown first does not live in the window that shows it.** Chapters derived "to be looked at first" used to be held by the form that asked for them: close it while the planner worked, or forget to press *Add*, and the plan was gone. It is now **kept with the book** (`.novel/derived.json`) until it is added to the outline or discarded: Derive opened again — the Outline's panel and the writing page's dialog are the same form — shows it; a derivation still at work is followed by whichever form is open; the buttons that open the form say that chapters wait; a finished derivation in the list of jobs leads back to it. Nothing is added to the outline for the author: they have not read it.
- **A word about a plan goes on from it.** Beneath a plan that waits is *What to change*. The planner adjusts that plan: what the author spoke of changes, the chapters and beats they did not speak of go back as they were. It is **the planner that derived it**, in the conversation it derived it in — what it read of the book is still in its context: the Studio keeps that agent (half an hour; let go when the plan is added or discarded) and says to it, as the next message, what it handed in (the JSON), what the author wants changed, and to hand it in again. Only where it is gone is somebody new handed the plan and the word whole; the result says which. This is a capability of the role runner (`keep` / `resume`), there for any work that is handed in for the author to read and may get a word back.
- **A plan set by its text is read anew, not checked off.** The first version showed the scribe the beats there were and told it to leave the ones that "still fit" word for word — and a model hands such a list back as it stands: a scene the text had gained since (a knock at the door closing a chapter) went without a beat. Now the beats there were are not shown at all: the text is gone through from its first line to its last, a beat a scene, the opening and the closing one too; and the synopsis, **what the chapter is for** (by what the text really does, against the synopses of the chapters on either side), place, time, point of view and cast are written by the text, the old ones beside it for comparison only. A beat that comes back in the same words keeps its id. The notes for the writer and the threads are not touched; the plan as it was is in its history.
- **A plan is the author's design: text does not become the plan unasked.** (The author, 2026-10-12: unless I press for it, the synopsis is not to follow the content by itself — that turns what the AI wrote into the outline, and the book may leave what was designed.) In release 105 *Update the plan from the text* was made to run by itself — a chapter digested before and changed had its plan read off its text a moment later — on the reasoning that a plan falls behind exactly when nobody thinks of pressing the button. That looked at one side only: where a plan and its text differ, it is not always the plan that is wrong. The text is a model's; where it went astray, a plan that follows it makes the stray thing the design, and what comes after — derivations, beats, writing — goes by that, a chapter at a time away from what the author laid down. So now **nothing changes without a press**: the buttons on a chapter's plan (the whole plan, or the beats alone) and in the Outline's multi-select stand as they were; the automatic one is off unless the author switches it on, under *Done by itself* (`plansFollow`). The older switch `planFollowsText` is retired and read no more — unset it meant yes, and every save of the settings page wrote it out as `true`, so a changed default would not have reached the author. The showrunner is held to the same: it does not set a plan by its text on its own, and where the two differ it says so and asks which gives way. Switched on, the automatic one works as before: several chapters in one job, the plan as it was in its history, a word on what changed; not at a first digest, and not twice from the same text.
- **One beat can be touched by itself.** Deriving a chapter's beats, and reading them off its text, both lay every beat out anew — so an author who wanted one scene more, or the third one different, lost the ones they were content with (the author, 2026-10-12: a beat from a sentence, or one or several beats changed — "as it is, changing anything changes all of them"). Above the beats there is now a line for a sentence: **with no beat ticked it adds one** (first, after a given beat, or — where nothing is said — where the planner sees it belongs by the order of things in the chapter), **with beats ticked it changes those and no other** (one that by the sentence goes into another, or goes, may be taken out). One plain request: the planner is shown all the beats and hands in only the one it made or the ones it was to change; the others keep their words and their ids, and what is handed in for a beat nobody ticked is not taken. Ticks stand before each beat on the outline page and in the writing page's plan panel; the showrunner has `novel_derive kind=beat`. The plan as it was is in its history.
- **What the showrunner derives to be looked at is the plan the page shows.** Chapters the showrunner derives with `novel_derive apply=false` wait with the book like the page's, with their planner kept; what the author says of them goes to **that** planner (`feedback`) instead of a new derivation, and adding or dropping the plan is one call each (`waiting=add / discard`). Page and showrunner go through one function of the Host.
- **What the Studio does by itself can be switched off where the author looks first — and stays off.** Digesting a written chapter, the planner's look through new names, settling suggestions, a plan following its text, issues read again after a revision: each is model calls nobody pressed a button for, so each has a switch on the first page of the settings (*Done by itself*), not among the advanced options where the digest's stood. A switch that is off is off everywhere: a run of chapters no longer forces its digest step (written without it, each chapter goes by the text before it; rounds review without taking memory), the overview and the memory panel say that digests are off and lead to the switch, and the showrunner is no longer told to digest after every change — a saving the author chose is not an agent's to spend. What still digests is what the author asks for: the button, a ticked step, an import.
- **A Host half that was replaced opens nothing.** The Studio's *Restart* puts a new Host half in the old one's place; a request the old one was still answering would open the book again after it had been taken down — with a file watcher nobody closes, which took every write of the new half for a change from outside. A core that was taken down now refuses to open a book, and the page asks the new half again when it gets that answer.
- **Pictures for a model that takes none count by what they are called.** Where the working model takes no pictures and no model is set up to look at them, work with guide pictures is not refused: it goes by each picture's title — what the book records of it, what the author said of it — is told that this is all it has, and its result says so. (It was refused at first; the author's word, 2026-10-12: titles by default.)
- **Full screen is the host's.** The right sidebar already has a full-screen mode; the Studio only puts the same switch in its own header, closer to where the author is looking. No overlay of its own, hence no second copy of the state.

The one thing that does not go through the conversation is a key: the showrunner neither takes nor repeats one; it opens the settings and lets the author paste it.

### One conversation, one book in play

A workspace holds several books; a conversation and the Studio beside it must not each have their own idea of which one is meant. So there is one fact — **the book in play of a session** — and both sides read and write it.

- *Changing book in the Studio moves the conversation.* The alternative, a panel that can look at one book while the showrunner works on another, makes every "write the next chapter" ambiguous. Looking is switching; the Studio says so when it happens.
- *The showrunner must be told, durably.* The Harness turns a changed runtime context into a message in the conversation's own history, so the switch is on record where the earlier turns are: which book is in play now, which one the turns before were about, and that leftovers of the earlier book are to be finished by naming it, not carried across. It survives compaction because it is restated with every digest.
- *A call acts on the book its model was last told about* — not on whatever is in play at the instant it runs. An author who opens another book while the showrunner is mid-step has not redirected the calls it already decided on; the next step tells it, and it decides anew.
- *An agent at work for a conversation is on the book that work is about* — never on whatever book its folder happens to be. A role's run, or a subagent the showrunner sends out, is a new conversation handed its parent's folder; and a folder can be a book of its own with other books inside it (the first book made in an empty workspace becomes the folder, the next ones go inside). So for a child the folder is asked last: first the book its task names, then the book of the conversation it works for. Asked first, the folder put the Studio beside a scribe at work on the inner book onto the outer one, and told a helper the wrong book was in play.
- *Several books in one conversation remain possible* — by naming, not by guessing. Every tool takes an optional `book`; the row in the transcript shows it; once a conversation has been on more than one book, every result says which book it is about. Reaching outside the conversation's workspace to change a book asks first.

### Nothing fails quietly

Most buttons start a job and return. A job nobody waits on that fails must still reach the author, least of all silently when the cause is that something was never set up. Two rules: the ending of every job this Studio saw start is reported; and a failure that means "not set up" — no speech model, no key, a subscription not signed in — is not an error message but a prompt with the way forward (one-click setup, or the settings opened at the right section). Long jobs say what they are doing: voicing a chapter shows the lines done, the line in the booth, time taken and time left.

The same goes for the half-second scale. A button that starts work shows itself working, in words, until the work ends; and one bar at the foot of the Studio lists everything in progress for the book — requests the Host has not answered yet, and running jobs whoever started them — with what each is doing, for how long, and a way to stop it. A click that seems to do nothing is a bug, whatever the code behind it was doing.

And for degraded results. A step that could not do its job properly and fell back on something lesser — a passage of an audio script cut by rule because the model's reply was cut off — writes that into what it produced, with the reason, and the screen shows it. The Studio also sets no cap of its own on how long a model's reply may run: a model that reasons spends its reasoning out of the same allowance, and a cap sized for the answer silently truncates it. That one mistake had produced scripts without speakers and storyboards of two panels, both looking like finished work.

### What is looked at is made like a beautiful game

It is called a writing tool, and it is at least as much a thing for an author to enjoy their own work in: turning the pages of a cast, of a world, is a pleasure of its own. So looking good is a requirement here, not a finish. Every page that is for looking — reading, listening, the motion comic, people, places and things, the world, the home page — is held to the standard of a beautiful game: large pictures, the picture first wherever there is one, somewhere to step into and wander (from a city to a house to a person), movement where it helps — not tables and forms. Nothing of the editing is taken away; it sits behind *Edit* and *Produce*: what is there otherwise is the finished thing, and the tools come when there is work to do. The looking and the changing of one thing are two faces of one address, a step apart from either side.

**The viewer is one application, used in three places.** What a reader is given — the text (read, heard, watched as a motion comic), the people, the world — is one set of pages (`client/reader/`) fed by answers made in one place (`core/reader.ts`). It stands in the Studio's navigation as *View*, it is the page other devices are served, and it is what a published site consists of. So nothing looks one way in the Studio and another once it is out. The three differ in two things only: the author's own viewer also shows who and what the text has not come to yet (a plan, which a reader is not given), and on the author's side every page has *Edit* at its top right, a step to where that thing is made, with *View* on that page a step back. Of a card a reader is given what a collection of settings prints; what somebody wants and lacks, the change planned for them, their secrets, the notes, and how they are written, drawn and voiced stay with the author.

**The reader says how large pictures stand, and a picture pressed is as large as it can be.** A picture of the text or of the script stands, left alone, **as wide as the text** — an illustration, a moment's portrait, a picture in the script alike, none with a cap of its own. *Pictures* in the reading settings is a stepper, − [Standard] +: smaller is 80%, 65%, 50% of the text's width; larger is 125%, 150% — the picture standing out of the column on both sides — and at most as wide as the screen it is read on (*Screen*). It steps **by what changes on the page being looked at**: on a narrow pane (a phone, where the text is nearly the screen's width) 125%, 150% and the screen are one width, and "+" goes there in one press instead of three with nothing to see; the word in the middle goes back to the standard. (The author, 2026-10-11: the standard is the text's width, to be made larger or smaller — the release before had made "as wide as the text" the largest of five named sizes and capped the standard.) Kept on the device like the type size, and carried into a published site with the author's other settings; a size kept while sizes had names reads as the nearest step. Any picture in the text — an illustration, a moment's portrait, one in the script, one in the album — fills the window when pressed (in proportion, a small one enlarged), and is put away by another press or Escape; in full screen, Escape puts the picture away before it leaves full screen. The large view is put at the top of the window (inside the full-screen layer while there is one), not where the page has it: a page laid out by its own width is a containing box, and what is fixed inside it is as tall as the page.

### Connecting models: one click, or slot by slot

Setup serves two kinds of people. **Those who would rather not study it**: the first time the Studio opens with nothing configured, it opens on a guide — pick a service, paste one key, click once, and writing, images, speech and retrieval are set as recommended; the key is checked against the service first, and a refused key changes nothing. **Those who want to decide**: every slot (four roles, images, speech, retrieval) names its own service, endpoint, key, model and reasoning level; a text role may use a model configured in the Harness or point straight at any OpenAI-compatible endpoint.

Keys are kept **per endpoint host**, one record each, in the Harness credential store. Several capabilities of one service therefore need the key once — and a key only ever travels to the host it was entered for: moving a slot's address elsewhere does not carry the key along.

**What is recommended is data, and it is published.** Models move faster than code is released: the image model a service is best used with, the models worth offering beside a field, the window of a model family all age by the month. None of it is in the code; it is `recommended.json`, an issue with a number and a date that goes out with every version. An author's settings follow it as far as the author wants: a setting that still is what an issue recommended moves to what the next one recommends, a setting the author chose is never touched, and whatever moved is said — with the old and the new value, and a way to take it back. An author who does not follow is told what an issue would change, and nothing is changed. Nothing about a model being superseded is ever done in silence.

**The settings page starts short.** Two models to choose — the writer's, and one for the crew — and one line each for pictures, speech, sound and retrieval. Everything a role can be told beyond its model lives on that role's own block under *Advanced*: its way of working, its tools and its steps are not a second table somewhere else on the page.

A ChatGPT subscription is the odd one out: it can write and draw, but it has no API key. The Studio adds no sign-in of its own and rides on one that exists. DSH can sign in to ChatGPT itself — its model adapter carries the flow for the `openai-codex` route — but none of DSH's pages starts it, so the guide page's ChatGPT card does: the attempt is DSH's, through DSH's authorization seam, the grant goes to DSH's credential store, and the Studio only shows the page to open and the box to paste into. One sign-in, and the card adds the route to DSH's model settings, gives the roles its models, and draws through it — the text and the pictures on the same sign-in, as a subscriber would expect. Codex Connect's image service and a Codex CLI already signed in on the machine remain other ways to the pictures. A subscription has no embedding or speech endpoint, and the Studio says so instead of pretending.

### What the interface says: what a thing is, and no more

A hint answers the question the author has at that spot: what this is, what happens on a click. It does not tell how things work behind it, does not repeat what the button beside it says, and adds no aside in brackets. A hint is one short sentence at most and none where none is needed; a tooltip is a phrase; a confirmation says what will happen and whether it can be undone. The mechanics are in the documents. The measure for new screens: an explanation the author would do without is not there.

## 6. What it can become

Five things share one model, with the **audio script** as the hub:

```
manuscript ──director──▶ audio script (per line: narration/dialogue/thought, speaker, delivery;
                │                       per scene: ambience)
                ├── speech ──▶ audio drama   (a clip per line, one voice per character)
                └── director ──▶ storyboard ──pictures──▶ motion comic (a panel per few lines + a camera move)
                                                              │
                              voice + sound + pictures ──post-production──▶ video (one MP4)
```

- **Audio drama.** A speaker's voice is resolved in a fixed order: the voice on the card → a voice designed for them → a voice cast by gender and age. What is cast is written into the book's voice sheet and read from it ever after, so casting does not depend on who happens to speak first in a chapter, and speakers without a card get a lasting voice too. Clips are cached by a hash of provider, voice, direction and text, so editing three lines re-renders three lines. Speech providers implement one small interface.
- **Listening without ears.** A generative speech model does not always do what it was asked: a line comes back in another voice, cut short, or twice as loud as its neighbour — and it is at its least steady on lines of a few syllables. The pipeline therefore measures every take (duration against the words, level, median pitch against the voice's reference clip or its own long lines), takes a failing line again, keeps the best take, marks what still stands out, and brings every kept line to one level. The script helps from its side: narration is kept whole rather than chopped into fragments, and delivery notes are not reinvented on every line. None of this needs another model, and none of it claims more than it measures: a syllable says more about its tone than about its speaker, so very short lines are not judged on pitch.
- **Ambience** uses no model: the browser synthesizes it with Web Audio — filtered noise as the bed, slow modulation for breath, scheduled one-shots (thunder, crackle, drips, crickets). The script only says "this scene is a rainy night".
- **Motion comic.** The script is cut into beats — a short line whole, a long one sentence by sentence — and the storyboard director arranges beats into panels, so a panel may change in the middle of half a minute of narration. How many panels is the author's call (a density that names how long a picture stays, or `auto`, and a ceiling that always holds), because every panel is a picture to pay for. The chapter is boarded a window at a time; a director that stops early is asked for the rest instead of having its last panel stretched over everything left. Prompts include each character's appearance and the book's art direction, and each panel is drawn against the design sheets of the people in it; playback follows the lines with slow camera moves.

- **Video.** The motion comic is put together by the Studio as it plays; the video is a file, and it is **not assembled by rule**. What the chapter already has — a voice for every line, sound cues, a picture for every panel — is material: the Studio lays it out on one timeline (every line's start and end, every panel's, every cue's moment), in the forms a shell takes easily as well (one voice track already aligned, subtitles cut for the screen, tables of panels and cues, a base script that makes a plain first cut), and hands it to the **post-production agent**. How to cut it is the agent's business: it reads the material, finds out what this computer's ffmpeg can do, writes its own script, runs it, checks, corrects — and calls in outside help when the work is beyond it. What the Studio keeps for itself is the judging: a picture, a sound that is not silence, a length that matches the telling, no long black stretches, the lines where a viewer gets them; only then is the file taken. Subtitles show where that line runs: the Studio gives the lines cut and timed, says the viewer must see them, and checks that they are in the picture or carried as a track — and writes no tool to put them there. The first time a cut came back with its words only as a track (this computer's ffmpeg draws no text), the tempting fix was a small native program of the Studio's own that draws them. The author refused it on two counts that are now rules: **work an agent can do is not done for it by a deterministic helper** — material, a clear ask and a check are the Studio's part, the commands are the agent's; and **the plugin is bound to no system while an agent is bound by nothing** — the plugin runs wherever DSH runs and so carries no code of one system, whereas an agent at work faces exactly one computer and may use anything that computer has.

### Enter sends a form — not the Enter that takes a word from an input method

Chinese, Japanese and Korean are typed through an input method, and the Enter that picks a candidate reaches a text field as a key like any other. Every field that goes on Enter (changing a picture, a brief for the writer, how a passage should change, a new person…) goes on a plain Enter only (`plainEnter`), or its author's sentence would leave half typed. A new field of the kind uses the same check.

### One page to read and to listen

The audio drama used to be a tab on the stage, away from the reader. But listening is reading by ear: it is the same chapter, and what a listener wants on screen is the text, not a table of takes. So the reader is where a chapter is heard — and, since the motion comic is the same chapter over the same script, where it is watched. It has three faces (the prose, the script line by line, the comic) and one player under the first two: listening is not a mode but a button, and the chapter is at the same place whichever face is open. Over the prose each script line is located in it (lines ignore paragraph breaks and dialogue has lost its quotation marks, so the match leaves white space out and falls back on how a line begins and ends), the sentence being spoken is lit, and any sentence starts playback. The author's tools — make, check and repair, export, the tools on every line of the script — are on the same page instead of on another screen, but not in the way: they come when *Produce* is pressed, and what is there otherwise is what a reader would have.

The same page is what a phone gets. A reader served to other devices cannot be the Harness (which stays on its machine, behind its own authentication), so the plugin runs a small server of its own for it: off until switched on for a book, read-only by construction (there is no route that writes or reaches a model, a key or an unshared book), and addressed by a random token that can be replaced. It is assembled from the very components the Studio's reader uses, so the two cannot drift apart.

### One look per book, and none of it hidden

Two things go wrong when a book is illustrated one prompt at a time. Words mean something else to an image model — a story's "church" becomes a cathedral, "white armour" a crusader — and a model that has never seen a character draws a new person each time. And the fixes tend to be hidden: a style phrase appended behind the author's back decides the look of a whole book without ever being shown.

So the look of a book is made of parts the author can read, and every picture records which parts it was made of:

- an **art direction** per book, and only per book: a noir of the 1920s and a space opera are not painted alike, so the look is a page of the book's bible, not a setting of the Studio. The director settles it from the book itself — its period and place, the temper of its prose, its leads — when a manuscript is imported and when a bible is drafted, and again whenever the author asks. A book from before this, with none of its own, starts from the built-in direction (or the one once entered Studio-wide), and its first picture writes that text into the book, where it is shown with its origin and can be changed. A default that shapes everything is a default that must be on record;
- **avoid lists** — per Studio, book, character and call — for what the setting does not have. They go to the image model as the negative prompt and to the model that writes scene descriptions, which is also told to replace loaded proper nouns with what the thing actually looks like;
- one **appearance** per character — and nothing beside it. The writer writes the person by it and every picture of them is drawn by it. There used to be a second text, a *visual anchor* written for image models alone; two texts of one thing drift apart, so it is gone (a card that still has one is drawn from it, as before, until it is folded into the appearance — the director writes one paragraph, the anchor holding where the two differ — or the author rewrites the appearance or drops it). An appearance is a paragraph of prose in the book's language, of what can be seen; where somebody stands and what is behind them is not their appearance — written into it, it turns up in every picture of them. It is written with the art direction in hand. An art direction can say more than how to paint — "dress and buildings of the Ming" — and appended after a subject it only colours what the subject already said: an appearance that follows the novel's own words to "one thick queue" is drawn with a queue under any art direction. So the period and the forms the author settled belong *in the appearance*, and whoever writes it is told they hold over the source text — the form replaced, not blended, and what is the person's own carried onto it;
- **design sheets**: the same person from the front, the side and the back, sent with every later picture of them as a reference image. Outfits are *looks* with sheets derived from the main one — the same face in other clothes — and places have reference art of their own.

The order matters and the Studio says so: direction and avoid list, then appearances and sheets, then pictures.

*A portrait is not an identity photograph.* Asked for with nothing said of it, it shows the person in the moment a reader remembers them by — and which moment that is cannot be computed: it is a judgement about the book, so the director makes it, reading the text, and writes it onto the card where the author can overrule it. The Studio's part is the frame around that judgement: what a portrait is (this person as its subject, one instant held still), that the choice is said and kept, and that nothing is picked where the book has nothing yet. Two things follow from its being a judgement. What the author asks of a portrait — brighter, the night of the fire — is *guidance to whoever judges*, not a replacement for the judging: the director picks the moment that answers to it. And which moments are fit to be shown is not the Studio's to decide by kind: a book's Christ is on the cross and its general in the thick of the fight; the author says what their book does not show, on its avoid list or in what they ask. (A first version listed kinds of moment never to pick. It kept the director from a boy's love scene, and from the crucifixion with it.)

*Signature scenes are a list in plain sight, not a decision made out of it.* The director finds not one moment but several, and they sit on the card by weight: which moment, which chapter, the picture, why it is theirs. The author sees them, rewrites them and chooses among them before anything is drawn — which is why nobody is stopped to be asked first.

*Words lead, pictures follow.* A reference picture is the strongest thing a prompt carries: told to match one, an image model returns it. So which way references run is a decision, and it runs one way only — from the words to the sheet, from the sheet to everything else. The main sheet is drawn from the appearance and the art direction alone, never against an older picture of the person: a sheet held against the sheet before could not change, whatever the author changed, and nothing on the screen would say why. A portrait, a scene, a panel are held against the sheet; a look against the main sheet, with the prompt saying what the reference is for (the face, not the clothes). To change how somebody looks, change the words and draw the sheet again — then what was drawn against the old one says so. And a prompt speaks of a reference only where one goes. How many a service takes is the service's to say — a server of the author's own in its model list (`reference_images.max_count`), OpenRouter in its listing, ComfyUI by having a workflow for them — and never the Studio's to tell from a model's name: a server learns to take pictures, and a guess that it does not outlives the day it was true. Where the service says, the prompt is written for that many and what stayed behind is kept with the picture; where nothing says, the pictures are sent, and a service that will not have them is asked for the picture again from the words alone — the prompt written anew, with not a word of any picture — with what it answered kept on the record. "Match your reference" with no reference behind it is an instruction about nothing, paid for out of what room the prompt has. And what a service did not take is said *after* the picture is there, with the picture — never before, as a warning about a picture not yet drawn: what was true of a service an hour ago is not a thing to tell the author, and what happened to this picture is. Which of a person's two pictures leads is the author's choice (`image.lead`): the design sheet (words → sheet → portrait and the rest), the portrait (words → portrait → sheet → the rest; such a portrait is never drawn against the sheet), or neither. That is the standing choice; beside the two buttons on a person's page each picture has its own — *the portrait from: the sheet / the words alone*, *the sheet from: the portrait / the words alone* — which starts out as the setting has it and holds for what is drawn from that page (`from`, on the request). The way from a portrait the author likes to a sheet that matches it is then one choice away, where the pictures are, whichever of the two leads. Whichever it is, the line runs one way, and nothing already drawn is redrawn because what it was held against changed — the page says which has fallen behind, and the author redraws it.

*A picture is a picture, whichever page drew it.* A panel of a motion comic is on record, in the gallery and in the same viewer as a portrait or a scene; and any picture the book has can be placed after any paragraph of its text — from the picture (*Place in the text…*) or from a passage selected on the writing page. Nothing is drawn for that; the text changes at that one spot.

*A design sheet goes along as its front view.* Handed all three figures of a sheet, an image model draws three people, and words do not talk it out of it (tried); so every picture but a sheet itself is held against the first figure, cut out of the sheet.

*A panel's prompt has two halves.* The director writes what happens in the frame and names who is in it, what they wear there and which things it shows; how each of those looks is put after the director's words by the Studio when the panel is drawn — from the bible as it stands, in full, never as a storyboard once abridged it.

*One control for a picture, wherever one is shown.* Opened large — from the gallery, a person's page, an entry of the bible — a picture has its record beside it and, under it, what can be done with a picture, the same everywhere: keep a copy; *rewrite its words and draw it again* (the art direction, what it kept out and the references it had go along as before); *change one thing in it* (the image model gets the picture and the author's words for what to change, and nothing else — the picture already says what it shows, in what manner, and what has no place in it; said again in words that would only lengthen the prompt. It keeps the frame the picture has. Only where the image service takes no picture do the picture's words stand in for it, the change after them, and the record says the picture stayed behind. What the picture shows in words is kept on its record, unsent, for when its words are rewritten later); take it out of the book. The viewer does not close when a picture has been drawn again: it stays where it is and shows the one that came of it (its author asked for the change to look at it, and as likely as not wants another); while it is drawn, the form stays put. The picture drawn again takes the old one's place wherever that hangs — a design sheet, a look, a stretch of a life, the portrait of a moment, an entry's art, the cover — and the old one stays in the gallery; portraits are kept side by side, the newest first as the face, for the author to order and to thin out. A picture taken away is let go of in all those places. A house or an organisation has design art as a place or a thing has: the one picture that stands for it.

*A picture can be traced.* "Every picture records its parts" is worth what the author can do with it when a picture comes out wrong. Opened large, a picture is shown with its record beside it: the parts of its prompt in the order they were sent and where each is changed, the reference pictures that went with it — each opening its own record, so a look can be followed back from picture to picture —, the words the image model got, exactly, and how all of it stands against the book as it is now (an appearance or an art direction changed since; a portrait drawn against a sheet that has been drawn again). A braid nobody asked for is then a word in the appearance, a picture that was sent along, or the model's own habit — and the author can tell which without asking anyone.

**One brief for every picture.** Every prompt is laid out the same way — a line a part under its name, in one order: the picture, its framing, the people, the place, the things, what was asked of this one, the art direction, the reference pictures by number, what must not appear. **A brief holds what is in the picture** — the author took two lines out by that rule (2026-10-12). One was the first line of a portrait, a picture in the text, a panel, a picture of the author's own prompt: what the picture was for ("a character portrait for a novel: so-and-so in their signature scene"), which says nothing a model draws. A first line of that name remains only where it names a form the picture has to take — a design sheet (turnaround or front view), the design art of a place, a house or a thing, a cover; that a plain likeness shows one person alone is a matter of its framing, and is said there. The other was the sentence after the list of reference pictures on which gives way to which ("faces follow the pictures; clothes follow the words where those say otherwise… nothing is redesigned"): where a picture is followed the lines above already point to it, and where it is not they already say so in words. The line now says which picture shows whom, and something more only where something has to be said of these pictures in particular — a sheet drawn after a portrait leaves the portrait's scene behind, a place at another time is not drawn whole, what the author asked of a picture they gave, which of several is the one to change. A picture's record keeps both lines as they were sent; drawn again — its prompt handed over to be rewritten, tried with another service — it goes without them. It is what the makers of the image models most used here ask for, and it reads the same to a strong model and a weak one, so there is one layout and no strategy per service. The brief goes as it is; the director writes it out only where it does not fit the model, or where the author has every prompt written. Somebody whose picture goes along is pointed to ("see Image 1") rather than described again — a look restated beside a moment in other clothes pulls the picture back to the look — and the words not sent are kept on the picture's record, for when it is drawn again where no picture can go. There is no exception to this (the author's word, twice): the ones there were — the words changed after the sheet, a stretch of their life with a look of its own, a look just amended from the author's notes — each wrote the whole look out again, and in a book that has been worked on they are the rule. Beside the pointer goes only what the picture does not show, and only that: what a stretch says is different then ("see Image 1; at this time (recovered): colour back in his face, a jade at the belt"), an outfit with no sheet of its own, what the author has just said. Where the words moved on after the sheet, the sheet is what the drawing goes by and the picture's record says so; to have the change in pictures the sheet is drawn again. The frame the director makes of a moment says what is worn only where it is not as usual.

**A portrait is a pair, and what stands for a moment is chosen.** Asked for with nothing said, a portrait is a plain likeness (the person's face, standing where they first come on) and their signature scene (standing where the chapter tells it); where the two places are the same or near, the scene alone stands there. A moment drawn more than once lists every picture of it, and the author says which is the moment's. Which moment a picture is of is read off the picture's own record — never off a note beside the moment, which a chapter digested again, a comparison or an older card can lose.

**The picture of a passage is an agent's to frame.** Who "she" is, where they are, what is in their hands is known only from the text before and the bible: the director reads, names the people, the place and the things, and writes the picture; the Studio lays the brief out from that.

**Design art is kept side by side too.** The art of a place, a house or a thing follows the rule of the design sheets: drawn again, the picture before stays on the entry — one is the *main picture* (what pictures that show it are held against, and what stands for it in the lists and the viewer), the rest are kept without being in use; ones drawn to compare and not taken, and earlier ones the gallery still has, are in the same row on the entry's page. Which is the main one is the author's to say; once chosen, a picture drawn after waits, and with no choice made the newest is the main one; where the main one is deleted, the one behind it is next.

**What is asked of one picture is worked into its prompt, not put after it.** A sentence the author adds to a design sheet or a plain likeness ("a cane in the right hand", "a snowy night, no glasses") used to be one more line of the brief — under a line that said "arms at the sides". The director, who writes prompts, now works it in, in one plain call: each part it speaks of is changed — the pose in the picture (a sheet has no such part: in the half of the framing that says how they stand), weather and light in the surroundings, what is worn in *wearing now* — and what the brief said against it goes; somebody pointed to by a reference picture and asked to differ from it has that said in their line. No other part is touched. A portrait of a moment does not take this step: there what the author asked already went into choosing and framing the moment. Where the author has prompts sent as laid out (`promptWrite: 'never'`), the line stays a line.

**A picture the author gives to go by: what they ask of it is the picture's to settle, and the words give way.** A design sheet and the design art of a place, a house or a thing can be given pictures — chosen among the book's own or brought in from the computer (`assets/guides/`) — each with a word on what is wanted of it ("the cut of the dress and the knot of hair as here", "only the pattern on the lid"). They go after whatever the Studio itself holds the picture against (the portrait where portraits lead, the main sheet for an outfit) and are named as the author's. The first real run showed what a line cannot do: **a line saying "as in the picture" loses to a paragraph of words** — the more closely the look is written beside it, the more the image model draws the words, and the picture is left with the outline and the angle. So there are two cases. Where the author said what is wanted of a picture, the director who writes prompts (a plain call; it does not see the picture) takes the words that speak of the same thing out of the brief, writes "as in Image N" where they stood, and hands back the phrases it took out — a prompt that still holds one of them is sent back, and the record of the picture names them. Where nothing was said, the whole look is the picture's: the line of that person or thing points to it ("see Image N"), and its words are kept on the record unsent (written out all the same under `image.looks: always`). Where the director cannot be had, what was asked goes as a line in the author's words and the record says so.

**In a picture, somebody is held against a sheet — not against a portrait of one stretch of their life.** A chapter's pictures show people as that chapter has them, and a stretch of somebody's life may have a look, a sheet and a portrait of its own. What goes along as their reference is a sheet: the stretch's, else the card's main one, with what the stretch says of their look written out in words (the face and the build from the picture, the rest from the text). The stretch's portrait is a picture *of* that time — often a scene, with a room and other people in it — and a reference made of it carries all of that into every picture after. It stands in only for somebody who has no sheet at all.

**Somebody else's sheet lends a likeness, not a person.** Given to the drawing of a design sheet, another person's sheet (the character page has a way to pick the person; one chosen among the book's pictures is known for whose it is all the same) is called what it is — another person's, by name, with what the cards say the two are to each other. With nothing said of what is wanted of it, what is wanted is not the whole look, which would draw the same person again, but the cut of the face: plainly of one family, with age, hair, build and clothing as the card of whoever is drawn has them. And what goes to the image model is the head and shoulders of that sheet's front view alone — with the figure whole its clothes came along down to the pattern on a cuff, and with the sheet whole the side view wore the other's hair (both seen in pictures drawn). Where the author says what is wanted of it instead, that holds, and the front view goes whole.

**A moment is framed before it is drawn.** A signature scene on a card is told as a story is told — "she puts the draft into the brazier" — and drawn from that, an image model knows neither what she wears at that point nor what is around her, while the telling is full of words that cannot be drawn. So the director, as an agent, reads the paragraphs of the chapter that tell the moment and frames it: the action in a short sentence, what she wears *then* (by the text; her usual clothes where it says nothing), the surroundings, who and what is there with her. The frame is kept on the moment and used while the moment's words stand; the brief of the portrait is the picture (that sentence) → surroundings → framing → the person (by their sheet) → what they wear now. A brief holds what is in the picture and nothing addressed to the model about how to read it. Where the director cannot be had the moment is drawn as told, and the result says so.

**Every button that draws offers several models.** Portraits, sheets, design art, the cover, the picture of a passage, panels, a new picture in the gallery, batches, one-click production: one small button, one dialog — several image services (or several models of one), a picture each, side by side, and nothing counts until one is taken; a picture taken lands where a plain draw would have put it (on the card, the entry, the panel, after the passage). Many pictures at once — a chapter's panels, a batch of portraits — are a *round*: taken whole by service, or one by one under *Stage → Illustrations → Waiting to be taken*.

**Nothing drawn to be compared is lost, and it is chosen whenever the author comes back.** A picture takes ten seconds or minutes; nobody sits before a dialog for that. So the dialog can be closed and the job draws on; every picture it makes is kept, and says itself where it goes once taken (whose card, which entry, which panel, after which passage — and, of a picture there was that several services drew again, "in the place of that one"). They are found again in three places that show the same pictures: *To take · N* in the header (there when something waits, on every page), *Waiting to be taken* at the top of the gallery, and **the same dialog opened again** — what was drawn of the thing before and not taken is in it, what is still being drawn goes on showing, and a round of many things can still be taken whole. A job that ends with its dialog closed is announced, with where to look. Taking one leaves the others (deleting them is a tick); a second one taken of the same comparison takes the place from the first.

**A picture may come from outside.** Wherever a picture is drawn, the same place can be taken by a file of the author's own — a photograph, a drawing, something made with another tool. Beside the buttons that draw a portrait or a design sheet (of a person, a stretch of their life, an outfit, one of their moments), the design art of a place, a house or a thing (and the picture of one turn of its course), and the cover, is *Import*: the picture is hung and recorded like one that was drawn (marked as imported — it has no prompt, so nothing to redraw from), and it follows the same rules — one more among those kept, the one in use unless the author chose another. Where a picture is *chosen* among the book's — to go into a chapter's text, to take another's place there — the chooser has the same way in: brought in, it is one of the book's pictures and is chosen at once. And the gallery takes many at a time, said first what they are: pictures of the gallery that hang nowhere, or the design art of an entry, or somebody's sheets or portraits. A sheet brought in is told as three views or the front alone by its shape; a photograph is often wider than tall and of one person, so what it shows can be said on the sheet itself.

**What a picture is for can be said anew, of any picture.** What a picture was drawn as (or brought in as) is not all it can be: a scene may be the best likeness there is of somebody, and one of the photographs brought into the gallery is the design art of a place. Any picture opened large has *Use as…*: whose it is and as what — somebody's portrait (of one of their moments, where said), their design sheet, the design art of a place, a house or a thing, a picture of a chapter's, or nobody's — and whether it is the book's cover. It is taken down from the card or the entry that held it, hung where it is said to belong, and filed as that in the gallery, by the rules of the pictures it joins (the main one unless the author chose another; then it waits). Where the text shows it, the panel of a storyboard it is the picture of, and its being the cover do not change by this. A picture drawn here and put to another use keeps on its record what it was drawn as: its prompt and its references are of then, and are not measured against whose it is now. Where a picture hangs is read off the cards and the entries (`shared/hung.ts`), not off the word on its record.

**The pictures in a text are the author's, and whoever changes the words may not lose them.** (The author, 2026-10-11: revisions kept dropping the pictures placed in the text — tell it not to.) A picture stands in a chapter as a line of its own, `![caption](path)`, and a model asked to rewrite — a passage, a chapter, a mending, a book-wide revision — often hands the text back without it. Two things: it is *told* what such a line is and to hand it back where it stood; and what comes back is *held against the original* — a picture left out goes back (after the line that the one it followed became; in a fresh draft or a translation, where nothing reads alike, as far down the text as it stood), a spoilt path is put right, a picture line of the model's own making comes out, the caption stays the author's. A chapter drafted over keeps the pictures it had; text the showrunner puts in the place of text keeps the ones that stood there, and a picture goes out only by deleting its own line. The story so far travels to the writer as prose, without picture lines, so it writes none. Whatever was put back or taken out is said on the proposal and in the result.

**A picture can be set straight by hand — cut, turned, mirrored — and the picture it was made of stays.** (The author, 2026-10-11: basic edits such as cropping and rotating belong in the gallery, the original kept.) A picture drawn a little askew, a photograph that came in on its side, one figure wanted out of two: none of it is worth asking a model again. Any picture opened large has *Crop · rotate…*: a quarter turn either way, a mirroring left to right or top to bottom, a box dragged over the part to keep (free, the picture's own shape, or one of the usual ones). What is saved is **a picture of its own** that stands wherever the one worked on stood — the portrait that stands for somebody, the main sheet, the main design art, a moment's picture, a panel, the cover: the rule of a picture changed in one thing — with that one kept after it. A picture's file is never rewritten once written (names by content, caches, published sites all rest on it), so nothing is edited in place. The new picture's record is the other's, with what was done beside it (`edited`: the picture it was made of, mirrored or not, quarter turns, the part kept); prompt, references and the size asked for remain those of the picture it came of. **Worked on again, it starts from that picture**, the box and the turn laid out as they were left — a cut can be widened, and cutting twice loses nothing twice; what is made stands in for the earlier one, which goes out of the book (all of it is in the original and those numbers) unless a chapter's text still shows it. Everything reset and saved is the original brought back. A sheet of three views cut down to one figure is a sheet of the front view from there on. The pixels are drawn in the page (`client/AdjustPicture.tsx`, on a canvas; the arithmetic shared with the Host in `shared/edit.ts`) and the Host keeps what it is handed (`image.adjust`); like bringing a file in and saying what a picture is for, it is the author's to do on the page — no agent has a tool for it. Once the original is removed, the picture made of it is a picture on its own.

**Brought in and drawn here can be told apart.** The gallery and the chooser have a row for where pictures came from — drawn here, brought in — used together with the kind and with whose they are; a picture brought in carries a small mark in the gallery.

**These two are the author's, on the page — not the showrunner's.** Bringing a file of this computer into the book, and saying what a picture is for, have no tool: neither the showrunner nor the crew can do either (the author's word, 2026-10-11; `tests/author-only.test.ts` keeps it so).

**References can be changed for a redraw.** Under the two fields of *Rewrite the prompt and redraw* are the reference pictures the picture went with: any can be taken away, others added from the book or the computer; the numbers the prompt points by and its line on references follow, and somebody whose picture was taken away is written out in words.

**The pictures of a chapter show where it is written.** Beside the editor is a list of the pictures the chapter's text carries, in order, each with the sentence before it: moved up or down, moved to after the paragraph the caret is in, taken out (the picture stays in the gallery), or another put in from the gallery. It edits the line in the text — saved and versioned like any edit. Portraits placed by rule are not in the text and are not listed here.

**Where the text is written, a picture is a picture.** The text is plain text and a picture in it is one line of markup — in a text box, a path and nothing to look at. So the writing page lays a chapter out in turn: prose in text boxes as tall as their words, and a picture's line as the picture, its caption under it. Opened there it is the same panel as anywhere (how it was made, redrawn from its prompt, changed, compared), and what is drawn from there is the one the text has. Replacing it with another of the book's, its caption, a line up or down, taking it out — all under the picture; one whose file is no longer in the book says so and keeps the way to take its line out. The chapter's file is what it was: one plain text, with places, find, the marked passage and the editor's keys counted across the boxes, and the arrow keys stepping past a picture from the end of one stretch into the next. One thing does not reach: a selection does not run across a picture.

**Rewriting a prompt means the whole prompt.** What the author rewrites to draw a picture again is everything the model was sent — with its art direction and its line on the reference pictures — and, apart from it, everything that was kept out; what goes again is those two fields, to the letter. A picture that is another one changed was sent something else: that picture, and one sentence. Its prompt is that sentence, and rewriting it changes the same picture again — the picture it came from goes with the sentence as it now reads, and nothing made of words is put in its place. (Drawn from words it can be, where the author says so, and is where the picture it came from is gone.)

**A picture is changed with other pictures to go by.** Where a sentence cannot say *which* dress, *which* brush, *whose* hair, the picture of that thing goes with it: the picture to change is Image 1, what the author adds follows from Image 2 — each with a word on what is wanted of it — and the sentence speaks of them by number. Then one line follows the sentence: which is the one to change, that it alone is changed, and that of the others only what is spoken of is taken. With nothing added the picture and the sentence are still all that goes. What was added is kept with the picture that came of it: changed again, it goes with them, until the author names others.

### References: other books to go by, read by the crew

A book may go by other books — a book of the shelf, consulted as it is organised there and as far as the author opens it; or a manuscript taken in for this book alone, as plain text (to have it organised first, it is imported as a book of the shelf: no half-organised middle is built here). Nothing of a reference is put into a task whole: the crew reads in them with tools kept to what is open, with the author's line on how to go by each. The writer has no tools, so the planner reads for a chapter before it is written and leaves notes on its plan, which the author sees and corrects; where the planner cannot run as an agent, that is said — notes are never made up.

How a reference is gone by is the author's to say, in their own words, at two levels: one line **for all of them** — which book for the world, which for the way of writing, whether people may be borrowed — said to everybody who works with the references at hand, and one line for each. Both hold; where they are at odds, a reference's own wins.

Whether to look is not left to a role's guess. A role that has the tools need not use them: "look where the work touches them" hands the model the question of whether it does, and a model that thinks not never looks. So three kinds of work **look first**: writing (the planner's notes, above), deriving (chapters, beats, a what-if) and reviewing. A derivation and a review are told to, and what they hand in is not taken until they have read or searched in a reference — sent back twice at most, so that a role that will not look is not kept from handing in for ever. What was read is counted off the calls the role made, not off what it says of itself, and is in the result. Each kind can be turned off, which leaves it to the role again; a role that works in plain calls has no tools to look with, and the result says so. A review is also handed the notes the chapter's writer was given, and files what is at odds with the references as issues.

### Interludes, and why this is not a role-play front end

In a role-play tool the chat is the product and the story a by-product. Here it is the reverse: the story is the product and playing is a way to probe it — rehearse a confrontation before writing it, or try the branch where she never left.

So an interlude is a fork off the canon. It is anchored after a chapter, and the director knows the canon only up to there. You play one character or direct from outside ("someone knocks"). Each turn the director returns narration, lines with actions, optional choices, scene changes (place, time, mood, ambience) and the variables it tracks. The Studio presents it as a visual novel — background, portrait, dialogue box, choices, voice, ambience — with pictures and speech generated on demand. When it ends it is discarded, kept as a side story, or **novelized**: the writer turns the transcript into a chapter in the book's style. Only the last changes the canon, and that chapter is digested like any other.

### Jottings: what is not thought through yet, kept

The outline and the bible hold what is settled. An author also has thoughts that are not — *maybe he comes in a chapter later*, *there should be a well behind the shop* — too early to write into either, and lost if written nowhere. (The author, 2026-10-12: a way to jot down an outline or a setting not thought through, found by the other agents by default, with a way to keep one of them, or all, from being found.) Jottings are kept with the book (`jottings/index.json`, sealed with it), written on *Bible → Jottings* or from the header of any page; each says what it is about (plot, setting, other), may have a title, and one taken away can be put back.

- **Found by default.** A jotting is a source of the book's search (`jotting`) — the crew's `book_search`, the showrunner's `novel_search`, the search panel — and `book_read what=jottings` lists them and reads one. A role at work as an agent is told among its rules that the book has some, and how they are read.
- **The ones that bear on a chapter go along.** Where a chapter is planned or written, up to three jottings that the same search finds for it — and that share three terms or more with what the chapter is about — are a part of what the work is given, so a writer that has no tools sees them too. Reviews and revisions do not take them: those hold text against canon, and a jotting is none.
- **An idea, never canon.** Said wherever one is handed over: where it is at odds with the bible or with text already written, those hold; and whoever went by one says which. (Run for real: the planner laid a beat out of a jotting about an old red umbrella at the docks — and left open what the jotting said was not thought through.)
- **Kept back by the author — one, or all.** Each jotting has *Found / Kept back*, and the page a switch for all of them. One kept back is in no index and in no list an agent reads — the showrunner's included, which can neither read nor change it. The author sees them all.
- **Settled, it is a jotting no more.** The showrunner may jot a thing down in the author's words when they say "note that" or think aloud (`novel_jot`), and moves a settled idea to where it belongs; whether jottings are found is set on the page only.
- **No other book reads them.** A book taken as a reference opens its world, people, style, plot and text; its jottings are not among them.

### Derivation records: what a stretch was meant to be, kept — and handed to whoever writes it

An outline says **what happens**. What a stretch of the story **was meant to be** — where it goes, light or heavy, whose it is — is said in the direction the author gives when it is derived, and in what the planner says of what it hands in. The outline is then edited, moved, read off the text again; with those two texts gone there is a result and no reason. (The author, 2026-10-12: the records of how the outline was derived should be there to read, so the thinking it came of is not forgotten; and the text should be written with that thinking, told plainly which part of it this piece of writing covers — so that the key set for a stretch, glad or dark, is understood. Found on looking: neither was there. The direction and the rationale lived in the plan that waited and were removed with it; the writer was handed the outline, the text before, the bible — and nothing of what was said.)

- **A record a derivation** (`derivations/index.json`, sealed with the book): chapters derived, a chapter's beats laid out, a beat added or changed by a sentence, a what-if, the idea a book began with. It holds the author's words, every hand-in with what the planner said of it (one more for each time the author had it adjusted), which chapters of the outline it became, and whether it still waits, entered the outline or was let go. One let go stays: that was thought too.
- **Read** on *Outline → Derivation records*; on a chapter's plan and beneath the brief box of the writing page a line says whether anything goes along when the chapter is written, and of which stretch. The showrunner and the crew read them with their read tool (`what=derivations`).
- **Handed on, with what it covers.** Where a chapter's beats are laid out, where it is written or revised, the record its stretch came of is a part of what the work is given: "this thinking covers chapters 6–10, five chapters; the chapter in hand is chapter 7 — number 2 of them", a line a chapter (written, in hand, not written yet), then the direction, what the author then wanted changed, what the planner said, what the author added. The writer also reads what was said when the chapter's beats were laid out. Whoever plans what comes next on a line reads its latest stretches.
- **Which holds where is said.** The outline for what happens (it is edited after it was derived); this for the key — where that differs from the mood the book's style names or from the emotion marked on a beat, these chapters go by it; the writer's closing ask names it again. Ways the planner mentions and did not take are said not to count.
- **Chapters with no record can be given one.** What was planned before records were kept has none: the author writes one down (*Write one down*: from which chapter to which, what they were meant to be), and it goes along like any other.
- **The author's to rule.** Each can be added to, kept back, taken away (and put back). What was said at a derivation is not edited — it is a record; a note of the author's own is.

Two things the runs showed. **The key is set in the outline and the beats, mostly.** A chapter derived under "make these glad" came out a farce with or without its record; a chapter whose beats were laid out cold did not change key for a note added afterwards, three times over (the writer follows its beats) — so where this thinking has to act is where the beats are laid out (there the planner's rationale began "this chapter goes light, as the author asked"), not as a last-minute turn in the writing. And **a derivation has to be told which chapter it follows**: with a chapter planned and not written at the end of the outline, the planner took "the next two chapters" to start after the last one written and planned that chapter a second time — the task now names the last chapter the outline has, and says no chapter there is planned again.

### What it costs

Staging is where the money goes, and a writer's model at a million tokens of context is not free either. The Studio keeps a ledger of every model call it makes — tokens per role, pictures, seconds of speech — and adds it up by model, role, book and day. It counts and does not guess prices: money appears for the models the author has priced, in the currency they entered, and an unpriced model is reported as unpriced. The showrunner's own turns belong to the Harness's count and are named as the one thing the ledger leaves out.

### What a call was sent, and what it said

The ledger counts. But when a passage comes out wrong, or one chapter written twice comes out as two unlike texts, the thing to look at is not a count: it is what the model was handed that time. It writes from what it is sent and knows nothing else.

So the Studio keeps every call it makes to a text model: the rules of the role and the style, the stretch that opens the request and stays the same over a run of calls, this call's material and what was asked last, the reply as it came back — with the model, its reasoning level, temperature and output limit, the tokens the provider counted, how long it took and how it ended (a failure with its reason, a stopped call with what it had said). A call is filed under its job, its chapter and, in a batch, its step.

- **Kept in the book** (`.novel/calls/`), not in DSH's folders: a sealed book's record is sealed with it, and no copy of a book's text lies in the open anywhere else.
- **A long stretch sent again and again is kept once.** Chapters written in a row, a chapter gone on with after it was cut short, several models compared on one chapter all send the same rules and the same story so far: stored by content, named by every call that sent it.
- **How much is kept is the author's setting** (`callsMb`: 200 MB a book unless set, the oldest going first, 0 for none); calls can be removed one by one or all at once.
- **Where it is read.** *Calls* in the panel beside a chapter is that chapter's; *Record of calls* under *Jobs* and *Usage* is the book's. A row pressed is that call whole, part by part in the order it was sent; two ticked are read against each other — first how each was set, then for each part whether the two were the same to the letter or where they differ; several ticked are laid side by side with the control every comparison uses.
- **What a role works out step by step is not in it.** A planner or a scribe running as an agent is a conversation of DSH's, opened from its job as before. This record is of the Studio's own question-and-answer calls — a writer writing a chapter is one.

Two drafts differ for one of three reasons: they were sent different things, they were set differently, or neither — one request answered twice at the writer's temperature of 0.85 is two texts. With the record, the three are told apart at a glance.

## 7. Fitting into the Harness

- **One npm package, three entry points**: Host (project, pipelines, jobs, API), agent (tools, prompt, command — mounted inside the preset), browser (the Studio). It ships its own configuration patch.
- **Official seams only.** Text model calls go through DSH's model runtime, so every route under *Settings → Models* works; roles run as agents through `ctx.subagents` (the plugin registers a provider of its own); outside help is DSH's own `dsh-tool-subagent`; keys go through the credential store; UI registers through slots; browser and Host talk over the Harness connection, so Web and Desktop behave the same.
- **What the Harness gives its agent, a plugin's own calls do not get.** Retrying a failed request is done by `dsh-llm-retry` on the agent loop; a call made through `ctx.llm.stream` gets the first failure as the last. The Studio therefore runs the provider's retry policy itself for the calls that are still calls, and moves work that is more than a call onto the agent loop, where none of this needs a second implementation.
- **Two prompt layers.** A fixed description of the division of labour sits in the system prompt (cache-friendly); the project digest and the working mode are dynamic context, re-sent only when they change.
- **Working mode is session state** — ideate, bible, outline, draft, revise, review, stage, play — switched in the Studio or by the showrunner.

### Sealed books

A book is plain files so that anything can read it; a sealed book is one its author does not want read by anything — a backup, a sync service, whoever opens the folder. Encrypting "the manuscript" would not be enough: a portrait, a voiced line, a memory digest, the name of a character's file say as much. So sealing is done underneath everything else: every read and write of a book goes through one small interface, and a sealed book's implementation of it encrypts content and names alike. The rest of the code neither knows nor cares.

**The conversations about the book are sealed with it.** DSH keeps every conversation as a log on disk, readable by whoever reads the disk, and a conversation with the showrunner about a book contains the book: the chapters it read, the plot the author talked through, what each agent looked up. DSH has no call to encrypt or delete a conversation, so the Studio **takes them away** when the book is locked: each log is encrypted into the Studio's own directory and the plain copy is removed from DSH's session store (with the title and summary DSH had derived from it); unlocking puts them back as they were, and the conversation can go on. "About the book" means: conversations bound to it, conversations in which a showrunner tool touched it, the runs of the agents that worked on it, and every child of those. So that a conversation can be put away while the book is **locked** — one that was still open at the moment of locking has to wait until it is closed — a sealed book's `novel.json` carries a public key that only takes in: anyone can add, only the book's key takes out. A conversation in use is never pulled from under DSH; it is sealed once DSH lets go of it, at the latest when DSH next starts. The plain copy is removed only after the encrypted one is on disk (and, when the key is at hand, opened and compared).

**So are the pictures a model was shown.** A picture reaches a model through DSH's attachment service, which keeps a copy of every one — plain, for good, with no call to take one back. A picture of a sealed book that a model saw once (the showrunner looking at it, a guide picture, the model set up to look at pictures) therefore lies outside the book's seal. So **pictures follow the conversations**: the Studio notes which copies it caused (by the hash of their content only — a file's name may spell somebody's), reads off a conversation's log which ones it holds as the log goes under the seal, and while the book is locked takes those objects out of the store: each encrypted into the Studio's own directory, the plain object removed, and DSH's cache of request-sized versions cleared (which of them were this book's cannot be told, and they are worked out again when asked for). Order matters: a copy no conversation holds goes at once; one a conversation shows goes only when the book's conversations have gone — a conversation still open must still find its pictures. Unlocking puts the pictures back before the conversations. As with conversations, a plain object is removed only after its sealed copy is on disk and, while the key is at hand, has been opened again and compared. One thing cannot be told apart and is said plainly: the store keeps a picture by its content, so the same picture used by another book or another conversation is missing there too while this book is locked.

The book's key is random and exists unwrapped only in the memory of a running Harness. On disk it is wrapped once per way of opening the book — a password, a computer's own unlock, a device that showed the password once — in the one file that stays readable. Presence is asked of the operating system (Touch ID, Windows Hello, the computer's password) through the script host the system comes with — `osascript` on a Mac, PowerShell on Windows — by a few lines that answer yes or no and hold no secret; the secret they gate sits in the account's credential store. Nothing is compiled or shipped for it: the plugin is the same files wherever DSH runs, and where a system offers no such check (Linux, for now) a book opens with its password. DSH itself has no owner check a plugin could call — its desktop shell exposes none, and a page of the shell cannot use WebAuthn, which browsers keep to https and localhost — or the Studio would use that. The showrunner is on the outside of all of this by design: it can lock a book, never unlock one, and a password is never typed into a conversation.

## 8. Deliberately not done

Collaborative editing (one author per book); bundled models or keys; calling a video-generation model (a chapter's video is cut by the post-production agent from voice and pictures that already exist; the motion comic is a moving storyboard); a rich-text editor (chapters must stay plain text you can open anywhere — the writing page shows a picture's line as the picture, which is how it lays the text out, not something added to the file); encryption in transit for the reader on other devices (it is plain HTTP inside the local network, and says so — a certificate a phone trusts is not something a plugin can conjure).