docs: note investigation order before a direct Fortress ls

CLAUDE.md

@@ -435,6 +435,20 @@ archives byte-for-byte as before. Authoritative design: `docs/RFC_incremental_v2
   by the legacy per-log `verify()`.
 - **Reship-monitor**: a run re-shipping > 25% of shards emails `[RESHIP-WATCH]`
   — the Phase-3 (leveled engine) trigger. Pure append trips ~0%.
+- **Investigating what shipped (e.g. "why did this target land as hundreds of
+  solo tars?") — check logs/manifests before querying Fortress directly.**
+  `hsi ls` is a live HPSS/tape call; the answer is almost always already
+  recorded by the run that did the archiving. Order:
+  1. The caller's nightly run report (e.g. florasense-tools'
+     `repo_backup_reports/*.txt`) — which targets archived/deferred/skipped and
+     why (first backup vs. incremental, concurrency-cap deferrals, etc.).
+  2. The per-target job stdout (e.g. `repo_backup_jobs/*.out`) — the
+     `SIZE-ROUTING COMPLETE` block this module prints: `T_small`, badge, K,
+     object count, solo/shard split, reship %.
+  3. The manifest at `{log_dir}/_vault/{badge}.manifest.json` — durable
+     per-object ground truth (arcnames per slot, fingerprints).
+  4. Only then, a direct Fortress listing (`hsi ls /group/...`) to confirm
+     against tape — last resort, not the first move.
 - **Restore** (`restore.py`, LOCAL, operator-invoked): full or selective restore
   into an **empty** dest. Gates, in order, each aborting the whole restore:
   completeness (every selected object tar on tape BEFORE any transfer), empty