Update docs for rewind, workflow list, daytona, and validation

Fix changelog rewind syntax to use positional args instead of flags.
Clarify Daytona snapshot note to distinguish configured-but-missing vs
unconfigured cases. Add rewind/workflow-list CLI reference sections,
checkpoints rewind guide, thread_id validation rule, and human gate
behavior details.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.claude/skills/docs/watermark

@@ -1 +1 @@
-542adbf1e1b0a9d6b3149ae25a097addf3bfb61a
+69e7f415d8a31368612cd803ac1e3b90a11055fa

docs/changelog/2026-03-14.mdx

@@ -8,7 +8,7 @@ date: "2026-03-14"
 You can now rewind a workflow run to an earlier checkpoint and resume from there. This is useful when a later stage goes off-track and you want to try again from a known-good point without restarting the entire workflow.
 
 ```bash
-fabro rewind --run-branch fabro/runs/my-run --target plan@2
+fabro rewind my-run plan@2
 ```
 
 Target a specific node by name, `node@visit` for a particular visit count, or `@ordinal` for a checkpoint index. The command rewinds both the metadata and run branch refs, and optionally pushes to the remote.

docs/execution/checkpoints.mdx

@@ -154,6 +154,23 @@ git show refs/fabro/01JKXYZ...:checkpoint.json | jq .current_node
 git show origin/fabro/meta/01JKXYZ...:checkpoint.json | jq .current_node
 ```
 
+## Rewinding to an earlier checkpoint
+
+If a later stage goes off-track, you can rewind a run to an earlier checkpoint and resume from there instead of restarting the entire workflow:
+
+```bash
+# List the checkpoint timeline
+fabro rewind <RUN_ID> --list
+
+# Rewind to a specific checkpoint
+fabro rewind <RUN_ID> plan@2
+
+# Resume from the rewound point
+fabro run --run-branch fabro/run/<RUN_ID>
+```
+
+See [`fabro rewind`](/reference/cli#fabro-rewind) for the full command reference.
+
 ## When checkpointing is active
 
 Git checkpointing activates automatically when:

docs/integrations/daytona.mdx

@@ -94,7 +94,7 @@ dockerfile = "FROM node:20-slim\nRUN apt-get update && apt-get install -y git"
 When a run starts with a snapshot configured, Fabro looks up the snapshot by name. If it doesn't exist and a `dockerfile` is provided, Fabro creates it automatically and polls until it reaches `Active` state (up to 10 minutes). If the snapshot already exists, it's reused immediately.
 
 <Note>
-If the snapshot doesn't exist and no `dockerfile` is provided, the run fails immediately. Without a snapshot, sandboxes are created from the default `ubuntu:22.04` image.
+If a snapshot is configured by name but doesn't exist and no `dockerfile` is provided, the run fails immediately. If no snapshot is configured at all, sandboxes are created from the `daytona-medium` snapshot which includes standard dev tools (git, etc.).
 </Note>
 
 ## Private repositories

docs/reference/cli.mdx

@@ -46,7 +46,7 @@ fabro run --run-branch fabro/run/abc123
 
 | Argument / Flag | Description |
 |---|---|
-| `<WORKFLOW>` | Path to a `.fabro` workflow file or `.toml` task config. Not required when using `--run-branch`. |
+| `<WORKFLOW>` | Path to a `.fabro` workflow file, `.toml` task config, or workflow name (resolved from `fabro/workflows/` in the project, then `~/.fabro/workflows/`). Not required when using `--run-branch`. |
 | `--run-dir <DIR>` | Run output directory |
 | `--dry-run` | Execute with a simulated LLM backend |
 | `--preflight` | Validate run configuration without executing |
@@ -372,6 +372,48 @@ fabro skill install --for user --dir claude
 | `--dir <DIR>` | Directory convention: `claude` (`.claude/skills/`) or `agents` (`.agents/skills/`). Required. |
 | `--force` | Overwrite an existing installation without prompting. |
 
+## `fabro rewind`
+
+Rewind a workflow run to an earlier checkpoint. This resets both the run branch and metadata branch refs so that `fabro run --run-branch` resumes from the target checkpoint.
+
+```bash
+fabro rewind <RUN_ID> [TARGET]
+fabro rewind <RUN_ID> --list
+```
+
+| Argument / Flag | Description |
+|---|---|
+| `<RUN_ID>` | Run ID or unambiguous prefix (required) |
+| `[TARGET]` | Checkpoint to rewind to: node name, `node@visit`, or `@ordinal` (1-based). Omit to show the timeline. |
+| `--list` | Show the checkpoint timeline instead of rewinding |
+| `--no-push` | Skip force-pushing rewound refs to the remote |
+
+Target formats:
+
+| Format | Example | Meaning |
+|---|---|---|
+| `node` | `plan` | Most recent visit of the named node |
+| `node@N` | `plan@2` | The 2nd visit of the named node |
+| `@N` | `@3` | The 3rd checkpoint in sequence |
+
+After rewinding, resume from the earlier point:
+
+```bash
+fabro run --run-branch fabro/run/<RUN_ID>
+```
+
+See [Checkpoints](/execution/checkpoints#rewinding-to-an-earlier-checkpoint) for background on how checkpointing works.
+
+## `fabro workflow list`
+
+List all available workflows in the current project. Shows workflows from both the project directory and user-level `~/.fabro/workflows/`, grouped by source with descriptions pulled from each workflow's goal.
+
+```bash
+fabro workflow list
+```
+
+---
+
 ## `fabro validate`
 
 Validate a workflow file without executing it. Reports errors and warnings. Accepts both `.fabro` workflow files and `.toml` run configs.

docs/reference/dot-language.mdx

@@ -341,6 +341,7 @@ Fabro validates workflows at parse time and reports diagnostics. Key rules:
 - Conditional nodes have multiple outgoing edges with conditions
 - Retry targets reference existing nodes
 - Goal gates have retry configuration
+- `thread_id` requires `fidelity="full"` (session reuse depends on full fidelity)
 - Known handler types only
 
 ## Complete example

docs/workflows/human-in-the-loop.mdx

@@ -17,7 +17,7 @@ approve -> plan      [label="[R] Revise"]
 approve -> skip      [label="[S] Skip"]
 ```
 
-When execution reaches the gate, the user sees the node's label ("Approve Plan") and the available options. In the CLI, this appears as an interactive menu. In the web UI, it appears as a set of buttons.
+When execution reaches the gate, the user sees the previous stage's output followed by the node's label ("Approve Plan") and the available options. In the CLI, this appears as an interactive menu. In the web UI, it appears as a set of buttons.
 
 ### Keyboard accelerators
 
@@ -45,6 +45,8 @@ review -> custom    [freeform=true]
 
 If the user types something that doesn't match any fixed option, their input routes to the freeform edge. The text is available to downstream nodes as `human.gate.text` in the run context.
 
+When a gate has only a freeform edge and no fixed choices, the user goes directly to a text input prompt — skipping the multiple-choice menu entirely. This is useful for conversational loops like REPL workflows where the user provides open-ended instructions each iteration.
+
 ### Default choice on timeout
 
 If a human gate has a timeout configured, you can specify a default choice using the `human.default_choice` attribute: