docs: add v3.2.0 and v3.3.0 feature documentation [AUTO-DOCS-2]

This commit is contained in:
2026-04-17 09:53:07 +00:00
committed by cleveragents-auto
parent 718e433d26
commit 46fff75c1a
5 changed files with 906 additions and 2 deletions
+343
View File
@@ -0,0 +1,343 @@
# CLI Reference — v3.2.0 and v3.3.0 Features
This page provides a consolidated reference for the CLI commands introduced in the
**v3.2.0** (Decisions + Validations + Invariants) and **v3.3.0** (Corrections +
Subplans + Checkpoints) milestones.
For the full plan command reference see [`reference/plan_cli.md`](reference/plan_cli.md).
For invariant management see [`reference/invariants.md`](reference/invariants.md).
For checkpoint and rollback details see [`reference/checkpointing.md`](reference/checkpointing.md).
---
## Decision Tree Commands (v3.2.0)
### `agents plan tree`
Renders the decision tree for a plan as a visual hierarchy.
```bash
agents plan tree <PLAN_ID> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--format`, `-f` | Output format: `json`, `yaml`, `plain`, `table`, `rich` (default: `rich`) |
| `--show-superseded` | Include superseded (corrected) decisions in the tree |
| `--depth` | Maximum tree depth to render (`0` = unlimited, default: `0`) |
**Examples:**
```bash
# Render the full decision tree in rich format
agents plan tree 01HXYZ1234567890ABCDEFGH
# Include superseded decisions (useful for auditing corrections)
agents plan tree 01HXYZ1234567890ABCDEFGH --show-superseded
# Limit depth for large plans
agents plan tree 01HXYZ1234567890ABCDEFGH --depth 3
# JSON output for scripting
agents plan tree 01HXYZ1234567890ABCDEFGH --format json
```
> **Note:** Decision IDs displayed in the tree are full 26-character ULIDs (v3.8.0+),
> which can be copied directly and used in `plan explain` or `plan correct` commands.
See also: [`reference/plan_cli.md#agents-plan-tree`](reference/plan_cli.md#agents-plan-tree)
---
### `agents plan explain`
Shows detailed information about a single decision node, including the question
posed, the chosen option, alternatives considered, and optional context/reasoning.
```bash
agents plan explain <DECISION_ID> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--format`, `-f` | Output format: `json`, `yaml`, `plain`, `table`, `rich` |
| `--show-context` | Include the context snapshot captured at decision time |
| `--show-reasoning` | Include the actor's raw LLM reasoning trace |
**Examples:**
```bash
# Default rich output
agents plan explain 01HXYZ1234567890ABCDEFGH
# Full detail with context and reasoning
agents plan explain 01HXYZ1234567890ABCDEFGH --show-context --show-reasoning
# JSON for programmatic use
agents plan explain 01HXYZ1234567890ABCDEFGH --format json --show-context
```
See also: [`reference/plan_cli.md#agents-plan-explain`](reference/plan_cli.md#agents-plan-explain)
---
## Decision Correction Commands (v3.3.0)
### `agents plan correct`
Re-executes a plan from a specific decision point using one of two correction modes.
```bash
agents plan correct --mode=<MODE> <DECISION_ID> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--mode` | Correction mode: `revert` or `append` (required) |
| `--guidance` | Operator guidance text for `append` mode (required for `append`) |
| `--dry-run` | Preview the impact without making changes |
| `--yes`, `-y` | Skip the confirmation prompt |
| `--format`, `-f` | Output format: `json`, `yaml`, `plain`, `table`, `rich` |
#### `--mode=revert`
Invalidates the targeted decision and all its descendants (BFS traversal), then
re-executes the plan from that decision point. Associated artifacts are archived
and affected child plans are rolled back.
```bash
# Revert a decision and re-execute from that point
agents plan correct --mode=revert 01HXYZ1234567890ABCDEFGH
# Preview impact without making changes
agents plan correct --mode=revert 01HXYZ1234567890ABCDEFGH --dry-run
# Skip confirmation prompt
agents plan correct --mode=revert 01HXYZ1234567890ABCDEFGH --yes
```
**What happens:**
```
D1 (target) <-- revert starts here
|
+----+----+
D2 D3 <- all invalidated
|
D4 <- also invalidated
```
#### `--mode=append`
Preserves the original decision and spawns a new child plan rooted at the target
node. The child plan carries the operator's guidance and produces additional
decisions without disturbing the existing tree.
```bash
# Append a correction with guidance
agents plan correct --mode=append 01HXYZ1234567890ABCDEFGH \
--guidance "Use a safer migration strategy that avoids table locks"
# Append with dry-run to preview
agents plan correct --mode=append 01HXYZ1234567890ABCDEFGH \
--guidance "Prefer read-only operations where possible" \
--dry-run
```
**What happens:**
```
D1 (target)
|
+------+----------+
D2 (original) CP-new <- child plan appended
```
**Risk levels** (based on affected decision count):
| Affected Decisions | Risk Level |
|--------------------|------------|
| <= 3 | `low` |
| 4 - 10 | `medium` |
| > 10 | `high` |
See also: [`reference/decision_correction.md`](reference/decision_correction.md)
---
## Invariant Management Commands (v3.2.0)
Invariants are natural-language constraints that govern plan execution. They are
evaluated by the Invariant Reconciliation Actor at the start of the Strategize phase.
### `agents invariant add`
Creates a new invariant constraint.
```bash
agents invariant add <NAME> --description <TEXT> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--description`, `-d` | Invariant constraint text (required) |
| `--global` | Apply to every plan in the system (default scope) |
| `--project <NAME>` | Scope to a specific project |
| `--action <NAME>` | Scope to a specific action template |
| `--format`, `-f` | Output format |
**Examples:**
```bash
# Global invariant (applies to all plans)
agents invariant add no-prod-deletes \
--description "Never delete production data"
# Project-scoped invariant
agents invariant add api-test-coverage \
--description "All API changes need tests" \
--project myapp
# Action-scoped invariant
agents invariant add min-coverage \
--description "Minimum 80% test coverage" \
--action local/code-coverage
```
**Scope hierarchy** (highest to lowest precedence):
| Scope | Description |
|-------|-------------|
| `PLAN` | Attached directly to a specific plan (via `plan use --invariant`) |
| `PROJECT` | Applies to all plans targeting a project |
| `GLOBAL` | Applies to every plan in the system |
| `ACTION` | Defined in an action template; promoted to plan scope on `plan use` |
---
### `agents invariant list`
Lists all invariants, with optional scope filtering.
```bash
agents invariant list [REGEX] [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--global` | Show only global invariants |
| `--project <NAME>` | Show invariants for a specific project |
| `--effective --project <NAME>` | Show merged effective set for a project |
| `--format`, `-f` | Output format |
**Examples:**
```bash
# List all invariants
agents invariant list
# Filter by scope
agents invariant list --global
agents invariant list --project myapp
# Show the merged effective set (with precedence applied)
agents invariant list --effective --project myapp
# Filter by regex pattern
agents invariant list "data.*safe"
# JSON output
agents invariant list --format json
```
---
### `agents invariant remove`
Removes an invariant by its ULID.
```bash
agents invariant remove <INVARIANT_ID> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--yes`, `-y` | Skip the confirmation prompt |
| `--format`, `-f` | Output format |
**Examples:**
```bash
# Remove with confirmation prompt
agents invariant remove 01HXYZ1234567890ABCDEFGH
# Remove without confirmation (for scripts)
agents invariant remove 01HXYZ1234567890ABCDEFGH --yes
```
See also: [`reference/invariants.md`](reference/invariants.md)
---
## Checkpoint and Rollback Commands (v3.3.0)
### `agents plan rollback`
Restores sandbox state to a previously captured checkpoint.
```bash
agents plan rollback [--yes|-y] <PLAN_ID> <CHECKPOINT_ID> [OPTIONS]
```
| Option | Description |
|--------|-------------|
| `--yes`, `-y` | Skip the interactive confirmation prompt |
| `--format`, `-f` | Output format: `json`, `yaml`, `plain`, `table`, `rich` |
**Examples:**
```bash
# Rollback with confirmation prompt
agents plan rollback 01HPLAN... 01HCHECKPOINT...
# Rollback without confirmation (for scripts)
agents plan rollback --yes 01HPLAN... 01HCHECKPOINT...
# JSON output for scripting
agents plan rollback --yes 01HPLAN... 01HCHECKPOINT... --format json
```
**Guards:** Rollback is blocked if:
- The plan has already reached the `applied` terminal state.
- The sandbox has been cleaned up.
**Automatic checkpoint triggers** (v3.8.0+):
| Trigger | When |
|---------|------|
| `on_tool_write` | Before each write-tool execution |
| `on_tool_write_complete` | After each write-tool execution |
| `on_subplan_spawn` | Before first subplan execution attempt |
| `on_error` | When the Execute phase fails |
See also: [`reference/checkpointing.md`](reference/checkpointing.md)
---
## Quick Reference
| Command | Milestone | Description |
|---------|-----------|-------------|
| `agents plan tree <plan_id>` | v3.2.0 | Render decision tree |
| `agents plan explain <decision_id>` | v3.2.0 | Show decision details |
| `agents plan correct --mode=revert <decision_id>` | v3.3.0 | Re-execute from decision point |
| `agents plan correct --mode=append <decision_id> --guidance <text>` | v3.3.0 | Append guidance as child plan |
| `agents invariant add <name> --description <desc>` | v3.2.0 | Create invariant |
| `agents invariant list` | v3.2.0 | List invariants |
| `agents invariant remove <name>` | v3.2.0 | Remove invariant |
| `agents plan rollback <plan_id> <checkpoint_id>` | v3.3.0 | Rollback to checkpoint |
---
*Automated by CleverAgents Bot — Supervisor: Documentation | Agent: documentation-pool-supervisor*
+238
View File
@@ -0,0 +1,238 @@
# Decision System
The CleverAgents decision system records every choice point in a plan's lifecycle
as a persistent **Decision** node in a tree structure. This enables full auditability,
targeted correction, and replay of plan execution.
This page provides a high-level guide to the decision system. For detailed API
references see:
- [`reference/decision_model.md`](reference/decision_model.md) — Domain model
- [`reference/decision_service.md`](reference/decision_service.md) — Service API
- [`reference/decision_correction.md`](reference/decision_correction.md) — Correction subsystem
- [`reference/invariants.md`](reference/invariants.md) — Invariant constraints
---
## Overview
Every time an agent makes a meaningful choice during plan execution — selecting a
strategy, choosing which files to modify, deciding how to handle an error — that
choice is recorded as a **Decision**. Decisions form a tree rooted at the initial
`prompt_definition` decision.
```
prompt_definition (root)
├── invariant_enforced <- constraints applied at start of Strategize
├── strategy_choice <- high-level approach chosen
│ ├── implementation_choice
│ │ ├── resource_selection
│ │ └── tool_invocation
│ └── subplan_spawn <- decision to create a child plan
└── strategy_choice
```
---
## Decision Recording (v3.2.0)
### What Gets Recorded
Each decision captures:
| Field | Description |
|-------|-------------|
| `decision_id` | Unique ULID identifier |
| `plan_id` | The plan this decision belongs to |
| `decision_type` | One of 11 types (see below) |
| `question` | What question was being answered |
| `chosen_option` | The option that was selected |
| `alternatives_considered` | Other options that were evaluated |
| `confidence_score` | Confidence in the choice (0.01.0) |
| `rationale` | Human-readable explanation |
| `actor_reasoning` | Raw LLM reasoning trace |
| `context_snapshot` | Hash + reference to the context window at decision time |
| `parent_decision_id` | Parent in the tree (None for root) |
| `created_at` | UTC timestamp |
### Decision Types
| Type | Phase | Description |
|------|-------|-------------|
| `prompt_definition` | Strategize | Root decision — the plan prompt |
| `invariant_enforced` | Strategize | An invariant constraint was applied |
| `strategy_choice` | Strategize | High-level approach chosen |
| `implementation_choice` | Execute | How to implement a specific task |
| `resource_selection` | Execute | Which resources to read/modify |
| `subplan_spawn` | Strategize | Decision to create a child plan |
| `subplan_parallel_spawn` | Strategize | Spawn a group of child plans in parallel |
| `tool_invocation` | Execute | Which skill/tool to use |
| `error_recovery` | Execute | How to handle a failure |
| `validation_response` | Execute | Response to a validation failure |
| `user_intervention` | Any | User-provided guidance/correction |
---
## Tree Visualization (v3.2.0)
Use `agents plan tree` to render the decision tree for any plan:
```bash
# Rich tree view (default)
agents plan tree 01HXYZ1234567890ABCDEFGH
# Include superseded decisions
agents plan tree 01HXYZ1234567890ABCDEFGH --show-superseded
# Limit depth
agents plan tree 01HXYZ1234567890ABCDEFGH --depth 2
```
The **current tree** consists of all decisions where `superseded_by IS NULL`.
Superseded decisions are hidden by default but can be shown with `--show-superseded`
for auditing corrections.
To inspect a specific decision:
```bash
agents plan explain 01HDECISION...
agents plan explain 01HDECISION... --show-context --show-reasoning
```
---
## Invariants (v3.2.0)
Invariants are natural-language constraints that are enforced at the start of the
Strategize phase. The Invariant Reconciliation Actor evaluates each invariant and
records an `invariant_enforced` decision for each one.
### Scope Hierarchy
| Scope | Precedence | Description |
|-------|-----------|-------------|
| `PLAN` | Highest | Attached directly to a specific plan |
| `PROJECT` | Medium | Applies to all plans targeting a project |
| `GLOBAL` | Lowest | Applies to every plan in the system |
| `ACTION` | Promoted | Defined in action template; promoted to plan scope on `plan use` |
### Managing Invariants
```bash
# Add a global invariant
agents invariant add no-prod-deletes \
--description "Never delete production data"
# Add a project-scoped invariant
agents invariant add api-tests \
--description "All API changes need tests" \
--project myapp
# List all invariants
agents invariant list
# Show effective set for a project (with precedence applied)
agents invariant list --effective --project myapp
# Remove an invariant
agents invariant remove 01HINVARIANT...
```
### Violation Handling
When an invariant is violated during execution, an `InvariantViolation` is created
with a severity of `error`, `warning`, or `info`. Reconciliation failures block the
phase transition with `ReconciliationBlockedError` and emit `INVARIANT_VIOLATED` events.
---
## Correction Modes (v3.3.0)
The correction subsystem allows operators to modify a plan's decision tree after
execution. Two modes are supported:
### Revert Mode
Invalidates the targeted decision and every descendant (BFS traversal). Associated
artifacts are archived and affected child plans are rolled back. The plan then
re-executes from the corrected decision point.
```bash
# Preview impact
agents plan correct --mode=revert 01HDECISION... --dry-run
# Apply correction
agents plan correct --mode=revert 01HDECISION...
```
### Append Mode
Preserves the original decision and spawns a new child plan rooted at the target
node. The child plan carries operator guidance and produces additional decisions
without disturbing the existing tree.
```bash
agents plan correct --mode=append 01HDECISION... \
--guidance "Use a safer migration strategy that avoids table locks"
```
### Correction Lifecycle
```
PENDING -> ANALYZING -> EXECUTING -> APPLIED
-> FAILED
PENDING -> CANCELLED
ANALYZING -> CANCELLED
```
### Impact Analysis
Before executing a correction, the system performs BFS impact analysis:
| Affected Decisions | Risk Level |
|--------------------|------------|
| <= 3 | `low` |
| 4 - 10 | `medium` |
| > 10 | `high` |
Use `--dry-run` to see the full impact report before committing.
### Correction Attempts
Each execution of a correction is tracked as a `CorrectionAttemptRecord`. Multiple
attempts may exist for a single correction (e.g., if a first attempt fails and the
operator retries). See [`reference/decision_correction.md`](reference/decision_correction.md)
for the full schema.
---
## Correction Immutability
Corrections never mutate existing decisions. Instead:
1. A new `Decision` is created with `is_correction=True` and `corrects_decision_id`
pointing to the original.
2. The original decision has its `superseded_by` field set to the new decision's ID.
3. All downstream decisions of the original are also superseded.
This preserves a complete audit trail of all decisions, including those that were
later corrected.
---
## Related References
| Document | Description |
|----------|-------------|
| [`reference/decision_model.md`](reference/decision_model.md) | Full domain model with all fields and validation rules |
| [`reference/decision_service.md`](reference/decision_service.md) | Service API for recording and querying decisions |
| [`reference/decision_correction.md`](reference/decision_correction.md) | Correction subsystem, modes, and attempt tracking |
| [`reference/invariants.md`](reference/invariants.md) | Invariant scopes, enforcement, and violation model |
| [`adr/ADR-007-decision-tree-and-correction.md`](adr/ADR-007-decision-tree-and-correction.md) | Architecture decision record |
| [`adr/ADR-033-decision-recording-protocol.md`](adr/ADR-033-decision-recording-protocol.md) | Decision recording protocol |
| [`adr/ADR-016-invariant-system.md`](adr/ADR-016-invariant-system.md) | Invariant system design |
| [`cli.md`](cli.md) | CLI quick reference for all v3.2.0 and v3.3.0 commands |
---
*Automated by CleverAgents Bot — Supervisor: Documentation | Agent: documentation-pool-supervisor*
+229
View File
@@ -0,0 +1,229 @@
# Subplans and Checkpoints
CleverAgents supports decomposing complex plans into coordinated **subplans** and
capturing **checkpoints** of sandbox state for rollback. These features are part of
the **v3.3.0** (Corrections + Subplans + Checkpoints) milestone.
For detailed API references see:
- [`reference/subplans.md`](reference/subplans.md) — Execution modes and merge strategies
- [`reference/subplan_service.md`](reference/subplan_service.md) — Spawn workflow and lifecycle
- [`reference/checkpointing.md`](reference/checkpointing.md) — Checkpoint and rollback
---
## Subplans
### Overview
A **subplan** is a child plan spawned from a parent plan during the Strategize phase.
Subplans allow a parent plan to decompose work into coordinated child plans, each
running in its own sandbox. Results are merged back into the parent plan using a
configurable merge strategy.
Subplans are created when the Strategize actor records a `subplan_spawn` or
`subplan_parallel_spawn` decision. The `SubplanService` then handles the spawn
workflow: validating resource scopes, creating child plan statuses, and returning
spawn metadata.
### Execution Modes
| Mode | Description |
|------|-------------|
| `sequential` | Execute one subplan at a time in order |
| `parallel` | Execute concurrently (up to `max_parallel`, default 5) |
| `dependency_ordered` | Respect DAG dependencies via topological sort |
**Sequential mode** stops on the first failure (even without `fail_fast`).
**Parallel mode** runs subplans concurrently. When `fail_fast` is enabled,
remaining subplans are cancelled on first failure.
**Dependency-ordered mode** sorts subplans topologically. Independent subplans
within the same wave run concurrently. Circular dependencies raise a `ValueError`.
### Merge Strategies
After subplans complete, their sandbox outputs are merged:
| Strategy | Description |
|----------|-------------|
| `git_three_way` | Three-way merge via `git merge-file` |
| `sequential_apply` | Apply changes in completion order |
| `fail_on_conflict` | Raise `MergeConflictError` on any conflict |
| `last_wins` | Final subplan's output overwrites earlier ones |
### Configuration
```yaml
subplan_config:
execution_mode: parallel # sequential | parallel | dependency_ordered
merge_strategy: git_three_way # git_three_way | sequential_apply | fail_on_conflict | last_wins
max_parallel: 5 # 1-50, for parallel mode
fail_fast: false # stop all on first failure
timeout_per_subplan_seconds: ~ # optional per-subplan timeout
retry_failed: true # auto-retry failed subplans
max_retries: 2 # 0-5, max retry attempts
```
### Failure Handling
- **`fail_fast`**: Stop all subplans on first failure (any mode).
- **Retry**: Retriable errors (`TimeoutError`, `ValidationError`,
`TemporaryResourceError`, `MergeConflictError`) are retried up to `max_retries`.
- **Non-retriable**: `ConfigurationError`, `AuthenticationError`,
`MissingResourceError`, `CircularDependencyError` are never retried.
### Spawn Validation
Before any child plan is created, the `SubplanService` validates:
1. All `target_resources` exist in the available resources set.
2. A `merge_strategy` is defined on `SubplanConfig`.
3. In `PARALLEL` mode, spawn count does not exceed `max_parallel`.
4. Each entry has a non-empty `action_name`.
5. Each entry's decision is `subplan_spawn` or `subplan_parallel_spawn`.
---
## Checkpoints
### Overview
A **checkpoint** is an immutable record of sandbox state at a point in time.
Checkpoints allow operators to snapshot the sandbox during plan execution and
restore it later — useful for recovering from mistakes, reverting tool side-effects,
and supporting the decision-correction revert flow.
### Checkpoint Types
| Type | When Created |
|------|-------------|
| `pre_write` | Before a write-tool execution |
| `post_step` | After a write-tool execution |
| `manual` | Explicitly via `CheckpointService.create_checkpoint()` |
### Automatic Checkpoint Triggers (v3.8.0+)
The execution engine creates checkpoints automatically on four triggers:
| Trigger | When | Component |
|---------|------|-----------|
| `on_tool_write` | Before each write-tool execution | `ToolRunner` |
| `on_tool_write_complete` | After each write-tool execution | `ToolRunner` |
| `on_subplan_spawn` | Before first subplan execution attempt | `SubplanExecutionService` |
| `on_error` | When the Execute phase fails | `PlanExecutor` |
Configure which triggers are active:
```toml
[core.checkpoints]
auto_create_on = ["on_tool_write", "on_tool_write_complete", "on_subplan_spawn", "on_error"]
```
To disable all automatic checkpoints:
```toml
[core.checkpoints]
auto_create_on = []
```
### Retention Policy
By default, up to **50 checkpoints** are kept per plan. When `auto_prune` is
enabled (default: `true`) and the limit is exceeded, the oldest interior checkpoints
are removed. The first (earliest) and most recent checkpoints are always preserved.
| Field | Default | Range |
|-------|---------|-------|
| `max_checkpoints` | 50 | 1100 |
| `auto_prune` | `true` | |
### Rollback to a Checkpoint
Use `agents plan rollback` to restore sandbox state to a previously captured checkpoint:
```bash
# Rollback with confirmation prompt
agents plan rollback 01HPLAN... 01HCHECKPOINT...
# Rollback without confirmation (for scripts)
agents plan rollback --yes 01HPLAN... 01HCHECKPOINT...
# JSON output
agents plan rollback --yes 01HPLAN... 01HCHECKPOINT... --format json
```
**Guards:** Rollback is blocked if:
- The plan has already reached the `applied` terminal state.
- The sandbox has been cleaned up.
**JSON output envelope:**
```json
{
"rollback_summary": {
"plan_id": "...",
"from_checkpoint_id": "...",
"restored_files_count": 3
},
"changes_reverted": ["path/to/file1.py", "path/to/file2.py"],
"impact": {
"files_affected": 3
},
"post_rollback_state": {
"active_checkpoint": "...",
"plan_id": "..."
},
"timing": {
"elapsed_seconds": 0.042
},
"messages": ["Rollback completed successfully."]
}
```
### Checkpoint Metadata
Each checkpoint stores structured metadata for auditability:
| Field | Description |
|-------|-------------|
| `checkpoint_id` | Unique ULID |
| `plan_id` | The plan that owns this checkpoint |
| `sandbox_ref` | Reference to sandbox state (e.g., git commit hash) |
| `decision_id` | Optional decision ULID this checkpoint is aligned to |
| `checkpoint_type` | `pre_write`, `post_step`, or `manual` |
| `created_at` | UTC timestamp |
| `metadata` | Audit metadata: reason, source tool, phase |
---
## Relationship Between Subplans and Checkpoints
Checkpoints and subplans work together in the execution engine:
1. Before the first subplan execution attempt, an `on_subplan_spawn` checkpoint
is automatically created (if the trigger is enabled).
2. This checkpoint can be used to roll back the entire parent plan's sandbox state
if subplan execution fails catastrophically.
3. The `CorrectionService` accepts an optional `checkpoint_service` parameter as
an integration point: once wired, the correction revert flow will delegate
sandbox restoration to the checkpoint rollback mechanism.
---
## Related References
| Document | Description |
|----------|-------------|
| [`reference/subplans.md`](reference/subplans.md) | Execution modes, merge strategies, and service API |
| [`reference/subplan_service.md`](reference/subplan_service.md) | Spawn workflow, validation, and lifecycle |
| [`reference/checkpointing.md`](reference/checkpointing.md) | Checkpoint model, rollback, and database schema |
| [`reference/decision_correction.md`](reference/decision_correction.md) | Correction subsystem integration |
| [`adr/ADR-015-sandbox-and-checkpoint.md`](adr/ADR-015-sandbox-and-checkpoint.md) | Architecture decision record |
| [`cli.md`](cli.md) | CLI quick reference for all v3.2.0 and v3.3.0 commands |
---
*Automated by CleverAgents Bot — Supervisor: Documentation | Agent: documentation-pool-supervisor*