# BobNet OS Product And System Spec

## One-Sentence Definition

BobNet OS is a local Windows desktop operating surface for turning owner intent into durable kanban work that Codex agents can run, review, retry, and audit.

## User-Facing Surfaces

### Main Desktop App

The app must ship as `BobNetOS.exe` and open to a dark, modern, readable command-center UI.

The left side is the navigation and command rail:

- Board selector and new board button.
- Compact board summary list.
- Workspace tabs: `Board`, `Office Space`, `Chat`, `Options`.
- Contextual card commands.
- Flow/dispatcher commands.
- Agent/automation/alert commands.
- Store/status footer.

The main area changes by selected workspace tab:

- `Board`: kanban columns and board goal.
- `Office Space`: agent status room, idle/working indicators, editable agents.
- `Chat`: BobNet OS chat transcript, prompt suggestions, copyable messages, send controls, activity indicator.
- `Options`: settings and future provider/runtime configuration.

Card editing lives in a popout editor, not crammed into the main board.

### Kanban Board

Core columns:

```text
Backlog
Ready
In Progress
Blocked
Review
Done
```

Cards must show at least:

- Title.
- Status/assignee.
- Short body/summary preview.
- Counts for comments, dependencies, attachments, runs, or other activity when available.

Cards must support:

- Create/edit/delete with destructive confirmation.
- Move between statuses.
- Assign an agent/profile.
- Workspace mode: Direct, Scratch, Worktree.
- Dependencies.
- Comments.
- Attachments/evidence.
- Run history.
- Review approve/request changes.
- Archive/show archived.

### Agent Floor

The agent floor is a status surface, not the source of truth. Source of truth remains profile files and board/run state.

It should show:

- Existing agents from editable profiles.
- Empty chairs for adding agents.
- Current assignment when an agent is working.
- Idle/roaming state when no active card is assigned.
- Click agent or empty chair to open the profile editor.
- Recent log/status output below or beside the room.

### Chat

Chat is a first-class main tab. It is not a tiny side console.

The chat must:

- Welcome the user when opened.
- Offer quick prompts such as `Explain how this system works`, `What would you like to do today?`, and `Summarize this board`.
- Accept copy/paste.
- Send on Shift+Enter as requested by the owner.
- Show activity while the local model or host executor is working.
- Persist or at least retain transcript for the current app session.
- Be board-aware when a board is open.
- Be selected-card-aware when a card is selected.
- Ask the local model to plan unknown/new workflows, not rely only on deterministic keyword routing.
- Preview proposed board/card mutations before applying them.

## System Roles

### Owner

The human operator. The owner can create boards, approve plans, run cards, inspect results, and override/delete with confirmation.

### Agent Profile

A named worker identity. In the current implementation profiles are markdown/file-backed. Do not move prompts into the database unless explicitly planned.

### Dispatcher

A loop that claims eligible Ready cards, creates a run, launches the worker path, parses result JSON, updates status, and logs events.

### Worker

Currently Codex CLI/Desktop driven. It reads the card context, performs work in the selected workspace mode, and writes `BOBNETOS_RESULT.json`.

### Chat Planner

A local model-facing planner. It converts ambiguous owner intent into a structured plan envelope. It does not execute directly.

### Host Validator/Executor

Deterministic BobNet OS code. It validates model proposals, maps them to safe host actions, shows previews, requires confirmations, and performs mutations through board services.

## Required Safety Rules

- SQLite is the default durable store.
- Legacy JSON import is explicit only.
- Do not silently migrate user data on normal launch.
- Free-form chat text cannot create/delete/update cards.
- Model-proposed JSON must be parsed, validated, previewed, and confirmed.
- Destructive board/card deletion requires a separate confirmation dialog with a hold-to-delete delay.
- Codex execution requires confirmation showing card, assignee, workspace mode, sandbox mode, and command route.
- Scratch/worktree cleanup must only delete BobNet OS-generated folders.
- Worktree removal must use git worktree commands, not blind recursive delete.

## Naming Rules

Public branding:

```text
Product: BobNet OS
Executable: BobNetOS.exe
Database: bobnetos.db
Result file: BOBNETOS_RESULT.json
Context file: BOBNETOS_CARD_CONTEXT.md
Environment variable: BOBNETOS_DATA_DIR
Store environment variable: BOBNETOS_STORE
```

Avoid new public `CodeBoard` strings. Existing internal class names can remain until a dedicated refactor.