Workspaces · Zorai

The model

Workspaces sit above threads and goals. A workspace task is the board card: it owns status, priority, assignment, review, history, and deletion state. The task target is either a thread or a goal.

Thread

A persisted conversation and tool-use surface.

Goal

A durable autonomous run with planning, execution, replanning, and reflection.

Workspace task

A board-owned item whose implementation target is a thread or goal.

Queue entry

Lower-level daemon execution machinery, not an operator-facing workspace task.

Board flow

Todo
  |
  v
In Progress
  |
  v
In Review
  |
  +-- pass --> Done
  |
  +-- fail --> In Progress + failed-review.md + new target

New tasks land at the bottom of Todo. Running a task starts its reserved thread or goal and moves the card to In Progress. Completion moves it to review or done depending on reviewer settings.

Task fields

Field	Purpose
Title	Required board label and target title.
Task type	`thread` or `goal`, selected at creation.
Description	Required work request passed to the assignee.
Definition of done	Optional acceptance criteria for completion and review.
Priority	Defaults to `low`.
Assignee	User, Svarog, or a configured agent/subagent. Required before run.
Reviewer	User or agent/subagent that validates completion.
Reporter	Automatically set to the user or Svarog.

Run and review

Task creation reserves a thread_id or goal_id immediately, but the target is not executed until the task is run, dragged into In Progress, or picked up by the workspace operator.

Assignees receive the title, description, definition of done, workspace id, task id, and completion instructions.
Agent reviewers receive a review-specific target, not another run of the original task.
User reviewers move the card through explicit review actions.
Failed review writes task-<id>/failed-review.md, reopens work, and preserves older targets in history.

Operator mode

Each workspace has one operator setting. User mode makes runs and transitions explicit. Svarog mode lets the daemon operate eligible board work automatically.

Why it matters: the same board can start as a user-controlled planning surface and later become an automatic Svarog-operated backlog without changing the task model.

Persistence

Workspace state lives in SQLite and is mirrored into the Zorai install directory:

<zorai install dir>/workspaces/workspace-<id>/
  workspace.json
  task-<id>/
    failed-review.md

The database is the authoritative structured store. The file mirror gives operators and external apps a readable local copy of board metadata, task state, history, and review artifacts.

Benefits

Threads and goals become deliverables instead of scattered conversations.
Review and retry loops are explicit and auditable.
Svarog can operate a board when the operator switches to auto mode.
External tools can watch workspace.json.
History keeps old thread and goal attempts available without hiding the active target.

Where it fits

Use a standalone thread for conversational work. Use a standalone goal for durable autonomy. Use a workspace when you need board ownership, assignment, review, status, and a local task mirror around those threads and goals.