docs: restore sqb recall output in Recall step 09

Author: kvlonge

src/sqlbuild/.agents/skills/sqlbuild/references/docs/concepts/observability/recall.md

@@ -50,7 +50,20 @@ run                         | outcome | violation_count | status    | exit_code
 
 The audit started warning on the latest build, and that build still exited 0, so nothing alerted.
 
-Then check what is true in the warehouse now, with the same command:
+See what that build printed, exactly as the scheduler saw it:
+
+```bash
+sqb recall output last --tail 4
+```
+
+```
+  daily_revenue
+    audit revenue_is_non_negative returned 1 row
+
+✓ Completed with warnings  PASS=89  WARN=1  FAIL=0  INSUFFICIENT=0  SKIP=0  TOTAL=90  (3.08s)
+```
+
+Then check what is true in the warehouse now, with `sqb recall query` again:
 
 ```bash
 sqb recall query --backend warehouse --format table \
@@ -66,8 +79,8 @@ payment_id | order_id | amount_cents | paid_at
 ```
 
 Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can
-follow the same steps: every answer is a SQL query over the [views](#querying-history), with the
-same output in `--json`.
+follow the same steps: the history is SQL over the [views](#querying-history), and every query can
+return `--json`.
 
 ## What is recorded
 

website/public/index.html

@@ -380,6 +380,11 @@ <h3>Find out what happened, then check what's true now</h3>
 2026-10-20T00:00  <span class="dim">|</span> <span class="ok">pass</span>    <span class="dim">|</span> 0               <span class="dim">|</span> completed <span class="dim">|</span> 0
 2026-10-19T23:59  <span class="dim">|</span> <span class="ok">pass</span>    <span class="dim">|</span> 0               <span class="dim">|</span> completed <span class="dim">|</span> 0
 
+<span class="cmd">sqb recall output last --tail 4</span>
+  daily_revenue
+    audit revenue_is_non_negative returned 1 row
+<span class="warn strong">✓ Completed with warnings</span>  PASS=89  WARN=1  FAIL=0  <span class="dim">…</span>
+
 <span class="cmd">sqb recall query --backend warehouse &quot;SELECT payment_id, order_id, amount_cents, paid_at
   FROM prod.stg_payments WHERE amount_cents &lt; 0&quot;</span>
 payment_id <span class="dim">|</span> order_id <span class="dim">|</span> amount_cents <span class="dim">|</span> paid_at
@@ -390,7 +395,7 @@ <h3>Find out what happened, then check what's true now</h3>
 						Real output from SQLBuild's example project, trimmed to the relevant lines. During a migration the old
 						table is never modified, archives can be renamed back until they expire, and every move is recorded.
 						In step 09 the audit started warning on the latest run, the build still exited 0, and the cause
-						is still in prod: a refund recorded as a negative payment. Two queries, no log digging.
+						is still in prod: a refund recorded as a negative payment. Three commands, no log digging.
 						History stays in a SQLite file in your project, or in ClickHouse for a team. No service, no
 						account, no paid tier.
 						<a href="/docs/concepts/models/migrations/">How migrations work</a> ·

website/src/content/docs/docs/concepts/observability/recall.mdx

@@ -34,7 +34,20 @@ run                         | outcome | violation_count | status    | exit_code
 
 The audit started warning on the latest build, and that build still exited 0, so nothing alerted.
 
-Then check what is true in the warehouse now, with the same command:
+See what that build printed, exactly as the scheduler saw it:
+
+```bash
+sqb recall output last --tail 4
+```
+
+```
+  daily_revenue
+    audit revenue_is_non_negative returned 1 row
+
+✓ Completed with warnings  PASS=89  WARN=1  FAIL=0  INSUFFICIENT=0  SKIP=0  TOTAL=90  (3.08s)
+```
+
+Then check what is true in the warehouse now, with `sqb recall query` again:
 
 ```bash
 sqb recall query --backend warehouse --format table \
@@ -50,8 +63,8 @@ payment_id | order_id | amount_cents | paid_at
 ```
 
 Payment 9 is a refund recorded as a negative payment, and it is still in prod. A coding agent can
-follow the same steps: every answer is a SQL query over the [views](#querying-history), with the
-same output in `--json`.
+follow the same steps: the history is SQL over the [views](#querying-history), and every query can
+return `--json`.
 
 ## What is recorded