You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agents/codebase-insights.txt
+7Lines changed: 7 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -32,3 +32,10 @@
32
32
- Devcontainer health check: reference the procedure in `specs/devcontainer-setup.md` and `specs/devcontainer-design.md`; formalize a single entrypoint the CLI will call.
33
33
- Config layering: ensure `supported-agents` can be set in system/user/project scopes and overridden by CLI; document keys and env vars.
34
34
- Decide on fallback when multiple instruction sources exist and no `source-file` is provided (current behavior: error; alternative: prompt interactively).
35
+
36
+
## State Persistence Notes (2025-08-27)
37
+
- Local state uses a canonical SQLite DB; there is no local daemon. See docs/state-persistence.md for selection rules and SQL schema.
38
+
39
+
## Config Mapping Notes
40
+
- TOML preserves dashes in keys (e.g., `network.api-url`, `tui.default-mode`, `repo.task-runner`).
41
+
- ENV/JSON use underscores for those keys (e.g., `AGENTS_WORKFLOW_NETWORK_API_URL`). See specs/configuration.md.
This document specifies how Agents‑Workflow (AW) persists CLI/TUI state locally and how it aligns with a remote server. It defines selection rules, storage locations, and the canonical SQL schema used by the local state database and mirrored (logically) by the server.
4
+
5
+
## Overview
6
+
7
+
- AW operates against one of two backends:
8
+
-**Local SQLite**: the CLI performs state mutations directly against a per‑user SQLite database. Multiple `aw` processes may concurrently read/write this DB.
9
+
-**Remote REST**: the CLI talks to a remote server which implements the same logical schema and APIs.
10
+
11
+
Both backends share the same logical data model so behavior is consistent.
12
+
13
+
## Backend Selection
14
+
15
+
- If a `remote-server` is provided via the configuration system (or via an equivalent CLI flag), AW uses the REST API of that server.
16
+
- Otherwise, AW uses the local SQLite database.
17
+
18
+
All behavior follows standard configuration layering (CLI flags > env > project‑user > project > user > system).
SQLite is opened in WAL mode. The CLI manages `PRAGMA user_version` for migrations (see Schema Versioning).
28
+
29
+
## Relationship to Prior Drafts
30
+
31
+
Earlier drafts described PID‑like JSON session records and a local daemon. These are no longer part of the design. The SQLite database is the sole local source of truth; the CLI talks directly to it.
32
+
33
+
## SQL Schema (SQLite dialect)
34
+
35
+
This schema models repositories, workspaces, tasks, sessions, runtimes, agents, events, and filesystem snapshots. It is intentionally normalized for portability to server backends.
36
+
37
+
```sql
38
+
-- Schema versioning
39
+
PRAGMA user_version =1;
40
+
41
+
-- Repositories known to the system (local path and/or remote URL)
42
+
CREATETABLEIF NOT EXISTS repos (
43
+
id INTEGERPRIMARY KEY AUTOINCREMENT,
44
+
vcs TEXTNOT NULL, -- git|hg|pijul|...
45
+
root_path TEXT, -- local filesystem root (nullable in REST)
46
+
remote_url TEXT, -- canonical remote URL (nullable in local)
- The database uses `PRAGMA user_version` for migrations. Increment the version for any backwards‑incompatible change. A simple `migrations/` folder with `N__description.sql` files can be applied in order.
149
+
150
+
### Concurrency and Locking
151
+
152
+
- SQLite operates in WAL mode to minimize writer contention. Multiple `aw` processes can write concurrently; all writes use transactions with retry on `SQLITE_BUSY`.
153
+
154
+
### Security and Privacy
155
+
156
+
- Secrets are never stored in plaintext in this DB. Authentication with remote services uses OS‑level keychains or scoped token stores managed by the CLI and/or OS keychain helpers.
157
+
158
+
## Repo Detection
159
+
160
+
When `--repo` is not supplied, AW detects a repository by walking up from the current directory until it finds a VCS root. All supported VCS are checked (git, hg, etc.). If none is found, commands requiring a repository fail with a clear error.
161
+
162
+
## Workspaces
163
+
164
+
`--workspace` is only meaningful when speaking to a server that supports named workspaces. Local SQLite mode does not define workspaces by default. Commands that specify `--workspace` while the active backend does not support workspaces MUST fail with a clear message.
Copy file name to clipboardExpand all lines: specs/cli-spec.md
+23-51Lines changed: 23 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ The CLI honors the layered configuration model in [configuration](configuration.
10
10
11
11
- One tool for both the TUI dashboard and automation-ready commands
12
12
- First-class support for:
13
-
- Local directory mode (PID-like files for discovery)
13
+
- Local state mode (SQLite only)
14
14
- Remote REST service mode (on-prem/private cloud), aligned with `docs/rest-service.md`
15
15
- Terminal multiplexers: tmux, zellij, screen
16
16
- Devcontainers and local runtimes (including unsandboxed, policy-gated)
@@ -20,33 +20,33 @@ The CLI honors the layered configuration model in [configuration](configuration.
20
20
21
21
-`aw` (no args): Launches the TUI dashboard (default mode described below)
22
22
- Common global flags (apply to all subcommands unless noted):
23
-
-`--mode <auto|local|rest>`: Discovery/operation mode. Default: `auto` (prefer local when in a repo with `.agents/`; otherwise rest if `network.apiUrl` configured)
24
-
-`--repo <PATH|URL>`: Target repository (filesystem path in local mode; git URL otherwise)
25
-
-`--project <NAME>`: Project/workspace name (REST mode)
23
+
-`--remote-server <NAME|URL>`: If provided, use the REST API at this server (by name lookup in config or raw URL). Otherwise use local SQLite state.
24
+
-`--repo <PATH|URL>`: Target repository (filesystem path in local runs; git URL may be used by some servers). If omitted, AW auto-detects a VCS root by walking parent directories and checking all supported VCS.
25
+
-`--workspace <NAME>`: Named workspace (only valid on servers that support workspaces). Errors if unsupported by the selected server.
26
26
-`--json`: Emit machine-readable JSON
27
27
-`--quiet`: Reduce output
28
28
-`--log-level <debug|info|warn|error>`
29
29
-`--no-color`
30
30
31
-
Configuration mapping examples:
31
+
Configuration mapping examples (dashes preserved in TOML; underscores in ENV/JSON):
-`aw` or `aw tui [--mode <local|rest>] [--multiplexer <tmux|zellij|screen>]`
46
+
-`aw` or `aw tui [--multiplexer <tmux|zellij|screen>] [--remote-server <NAME|URL>]`
47
47
- Starts the dashboard and auto-attaches to the active multiplexer session (creating one if needed).
48
-
-Mode `rest`: connects to REST service to retrieve projects/repos/agents/branches and launches local (or remote via SSH) multiplexer windows for new tasks.
49
-
-Mode `local`: operates in current repository (default), discovering running tasks via PID-like files in the filesystem.
48
+
-With `--remote-server` (or configured `remote-server`), connects to the REST service to retrieve workspaces/repos/agents/branches and launches local (or remote via SSH) multiplexer windows for new tasks.
49
+
-Without `--remote-server`, operates against the local SQLite state.
- In local mode, prepares a per-task workspace using snapshot preference order (ZFS > Btrfs > Overlay > copy) and launches the agent.
68
-
- In rest mode, calls `POST /api/v1/tasks` with the provided parameters.
69
-
- Creates/updates a local PID-like session record when launching locally (see “Local Discovery”).
67
+
- With a configured/provided `remote-server`, calls the server’s REST API to create and manage the task.
68
+
- Otherwise, prepares a per-task workspace using snapshot preference order (ZFS > Btrfs > Overlay > copy) and launches the agent locally.
69
+
- Persists session/task state in the local SQLite database; see `docs/state-persistence.md`.
70
+
- Fleet resolution: when `--fleet` is provided (or a default fleet is defined in config), AW expands the fleet into one or more members. For local members, it applies the referenced sandbox profile; for `remote` members, it targets the specified server URL/name. Implementations may run members sequentially or in parallel depending on runtime limits.
70
71
- When `--browser-automation true` (default), launches site-specific browser automation (e.g., Codex) using the selected agent browser profile. When `false`, web automation is skipped.
71
72
- Codex integration: if `--browser-profile` is not specified, discovers or creates a ChatGPT profile per `docs/browser-automation/codex.md`, optionally filtered by `--chatgpt-username`. Workspace is taken from `--codex-workspace` or config; branch is taken from `--branch`.
72
73
- Branch autocompletion uses standard git protocol:
@@ -79,7 +80,7 @@ Draft flow (TUI/Web parity):
79
80
80
81
#### 3) Sessions
81
82
82
-
-`aw session list [--status <...>] [--project <...>] [--repo <...>]`
-`aw task` writes the record on successful launch and updates status transitions.
273
-
- On normal termination, the record is finalized (endedAt, final status) and moved to an archive file.
274
-
- Crash/unclean exit detection: stale PID check on startup; records marked as `failed` with reason.
247
+
Local enumeration and management of running sessions is backed by the canonical state database described in `docs/state-persistence.md`. The SQLite database is authoritative; no PID files are used.
275
248
276
249
### Multiplexer Integration
277
250
@@ -334,7 +307,7 @@ aw attach 01HVZ6K9T1N8S6M3V3Q3F0X5B7 --pane left
334
307
Run the TUI against a REST service:
335
308
336
309
```bash
337
-
aw tui --mode rest --multiplexer tmux
310
+
aw tui --remote-server office-1 --multiplexer tmux
338
311
```
339
312
340
313
Start local REST service and WebUI for a single developer:
0 commit comments