docs(fleets): fleet chat streaming, inline final reply and runner update

[indykish]

Documents the fleet chat release in agentsfleet/agentsfleet#715 (0.51.0). Merge after #715, because the API reference reads public/openapi.json from agentsfleet main.

Session notes 1

The Sep 25 changelog entry now covers the whole release: queued steers, streamed replies at a 200 millisecond cadence, lighter reasoning text, final_reply on event_complete, the bundle download retry, and the corrected bundle-failure message. Operators are told to update each agentsfleet-runner to 0.51.0, because an older runner still completes runs but shows each reply only when the run finishes.

 page                   change
 ─────────────────────  ─────────────────────────────────────────────
 changelog.mdx          Sep 25 entry: +4 bullets, runner update note,
                        API tag
 fleets/running.mdx     copyable diagnostic; bundle retry: 3 attempts
                        in 5 s, then a runner-refusal message
 fleets/troubleshooting Copy diagnostic carries safe stream counters
 runners.mdx            limit: live replies need runner 0.51.0

Values trace to agentsfleet source: 200 ms (src/runner/daemon/forwarders.zig:25), 3 attempts in 5 s (src/runner/bundle_extract.zig:48-54), 64 KiB (rustd/crates/afd_fleet/src/lease/bracket.rs:42), refusal sentence (ui/packages/app/components/domain/fleetFailureCopy.tsx:15).

verified dates are unchanged: only the edited sections were rechecked, not the whole pages (DOC-31).

Review

Review not run as a separate skill pass. The docs checker caught DOC-02 (26-word sentence) and DOC-03 (four-sentence paragraph) on fleets/running.mdx:117; both FIXED before commit 7622146.

Make

make lint            exit 0   Documentation check passed; 3 links checked
gitleaks --staged    no leaks found

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge, with one non-blocking wording issue still outstanding.

Findings

1.  Retry count is ambiguous ▶

Fix with agent prompt

### Issue 1
changelog.mdx:undefined-61
“Retries ... up to 3 times” suggests three retries after the first download, while the running guide says there are three attempts total. That difference makes it harder for operators to know when a failed download should stop retrying. Use “up to 3 attempts” in both places.

```suggestion
  - **A brief network drop no longer fails a run before it starts** - the runner makes up to 3 attempts to download the fleet bundle within 5 seconds.
```

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR documents fleet chat streaming, resend behavior, diagnostics, runner compatibility, and related API errors.

• Adds release notes for streamed replies and idempotent message sends.
• Updates fleet guidance for failed runs, unsent messages, and runner upgrades.

_{Reviews (3) · Last reviewed commit: "docs(fleets): UZ-AGT-016 covers another ..."}

[greptile-apps]

Retry count is ambiguous
“Retries ... up to 3 times” suggests three retries after the first download, while the running guide says there are three attempts total. That difference makes it harder for operators to know when a failed download should stop retrying. Use “up to 3 attempts” in both places.

Suggested change

	- **A brief network drop no longer fails a run before it starts** — the runner retries the fleet bundle download up to 3 times within 5 seconds.
	- **A brief network drop no longer fails a run before it starts** — the runner makes up to 3 attempts to download the fleet bundle within 5 seconds.

Prompt To Fix With AI

This is a comment left during a code review.
Path: changelog.mdx
Line: 33

Comment:
**Retry count is ambiguous**
“Retries ... up to 3 times” suggests three retries after the first download, while the running guide says there are three attempts total. That difference makes it harder for operators to know when a failed download should stop retrying. Use “up to 3 attempts” in both places.

```suggestion
  - **A brief network drop no longer fails a run before it starts** — the runner makes up to 3 attempts to download the fleet bundle within 5 seconds.
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!