What carries over

What the app picks up again after it stops, and what it keeps from one conversation to the next: the work it was in the middle of, the workers it can come back to by name, and the playbooks it writes down.

These are the shipped defaults. What you can change lives in a config file you own once TESSERACT is installed, so your copy may differ, and should, once you tune it.

After a restart

When the app starts, 5 checks run in this order before anything else. Each runs on its own, so one that fails costs only its own report.

Check	What it does	Settles it on its own
workers	Finds the delegated workers that were still running and marks each one interrupted, so none is left looking busy.	yes
turns	Closes the conversation turns the previous run left mid answer, and tells you which ones were cut off.	yes
schedule	Counts the scheduled jobs that finished or failed in the last day.	no
agenda	Frees the tasks the stopped app was holding, and queues a task that was mid work to pick up again once the workers it handed out have stopped. Tasks waiting on you stay as they are.	yes
effects	Lists the calls that were cut off before their result was written. One that is safe to repeat, or can be checked first, is left to the conversation that picks the work up. One that is not, such as a sent message, waits for you to say what to do.	no

A check that settles what it finds only closes records the app itself owns. The last check exists because some work cannot be taken back: a message may already have reached somebody, so a call that is not safe to repeat is never run again unless you say so.

Workers you can come back to

A worker the assistant hands a job to can be given a name, and the name outlives the conversation. A later conversation, or the app after a restart, reaches the same worker by asking for it by name. The tools that do this are lane_named_ensure, lane_named_get and lane_named_list, listed with the rest on the Tools page.

Where each part is kept, inside your home folder:

What	Folder
A worker that is open	controller/lanes
A name and the worker it points to	controller/named-lanes
A worker that has finished	controller/lanes-archive

A finished worker is deleted after 10 days, counted from the last file written inside it, so one still being written to is never taken. The setting is lane_archives in retention.yaml.

Playbooks

A playbook is a written procedure the assistant follows. Each one is a folder of its own under workspace/skills, holding one SKILL.md.

• Versions. When a playbook is revised, the version it replaces is kept in its own history/<version> folder, so a revision that does worse can be compared with the one before and taken back.
• Waiting, and turned down. A new draft waits in workspace/skills/pending and is not used until it is approved. Where your permissions let the assistant create playbooks without asking, it is approved on the spot. One you turn down moves to workspace/skills/rejected, and a later draft under the same name is refused with your reason, if you gave one.
• Which tools it may use. A playbook can name the tools its steps may use (allowed-tools) and the ones they must never use (forbidden-tools). Both lists are checked against the playbook’s own steps, when it is written and again each time it is shown to the assistant. A draft that breaks either list is refused, and one already on disk is shown to the assistant as one it cannot run, with the reason. The lists are not checked call by call while a playbook runs.
• Written from finished work. After tasks close, the app may write down how one was done as a new playbook, or add it as more evidence to a playbook that already does the same steps. It reads only tasks whose project’s own checks decided they were done, and only ones of at least 3 steps, where several calls in a row to the same tool count as one. A task the assistant closed on its own word is never read, because a playbook written from it would be the assistant grading its own work. The step count is min_tool_steps in schedule.yaml; the first rule is not a setting.