--mode "$MODE" [--profile ]
```
Detection (`inventory.json`) and collection (`objects/`, `events.json`, `metrics/`, `aws/`) land in one snapshot folder. The first output line `context -> ` names that folder as soon as the command starts, and the last line "saved: " repeats it when collection is done; either is this run's snapshot `$SNAP`, so read the first one while the command is still running. Measured on real clusters: a daily run takes about 135 seconds on an 8-node EKS cluster and about 120 seconds on a 2-node small k3s cluster (collectors run four at a time); a full run adds the steps marked `modes: [full]` in collect.yaml (node scripts, CloudWatch, cost, ECR, krr and the other tools) and took 730–820 seconds on EKS before collectors ran in parallel. A full EKS run may still exceed the foreground time limit most agent shells impose (600 seconds in Claude Code), so start `collect` detached (in Claude Code: the Bash tool with `run_in_background`; elsewhere `nohup … &`) (it refuses if another collection is in progress for the same context — wait for it or use `--force`), take `$SNAP` from its first output line, and wait until `$SNAP/INCOMPLETE` disappears. Wait in rounds of at most 60 seconds, each a short foreground `until` loop that gives up after 60 seconds; after every round write the first line of `INCOMPLETE` to the user as is (section 0, "Tell the user where the run is") and start the next round. Do not run the wait itself in the background: nothing would then be said until collection ends, which is the silence this rule exists to end. `collect` also prints the same `progress:` line each time a collector finishes. While collecting, do nothing else than relay progress. If the output contains "failed", remember which command failed and why for report section 7-1. Do not abort.
## 4. Summary and first-pass evaluation
```bash
$KUBEGAP/scripts/kubegap summarize --context --snapshot "$SNAP"
$KUBEGAP/scripts/kubegap evaluate --context --snapshot "$SNAP" [--profile ]
$KUBEGAP/scripts/kubegap diff --context --mode "$MODE" # no positional arguments = compare the latest snapshot of this mode with the previous one of the same mode (daily with daily, full with full). If there is none, it says so and only history.csv is updated: the report then states "No earlier snapshot to compare with." — nothing more
```
Caution: if `diff` gets a single positional argument, it is read as A (the earlier snapshot) and B becomes latest, which fails with "A and B are the same snapshot" (this has actually happened). When analyzing an older snapshot via `--snapshot`, pass both, as in `diff --context `. If `--compare A B` was given, run `diff --context `. If the `evaluate` output shows "errors N" with N not 0, list the checks with `status: error` in `findings-draft.json` `check_results` and their reasons in report section 7-2.
## 5. Analysis — reading order
From here on it is **reading and judgment**, not Bash. Everything is a file under `$SNAP/`. **Read `references/analysis-procedure-.md` now and follow it fully** (`-ko` when Korean was chosen, `-en` otherwise; the two are written separately, not translated) before opening any snapshot file — it is mandatory, not optional. It holds the reading order (`inventory.json` → `findings-draft.json` → `summary.json` → the previous snapshot and report → `diff.json`), the list of summary.json sections and the pointers to the file-shape references (`references/snapshot-files.md`, `references/summary-shape.md`). Extract only the needed parts of JSON with `python3 -I - <<'EOF' … EOF` (the files are several MB).
Scope follows the arguments from section 0: `--namespace ` narrows steps 2, 3 and 5 of the reading order to that namespace plus cluster-level items; `focus ` to that area's checks and related summary; `explain ` reads one finding to the end and writes only the explanation (not a full report). The exact definitions are in the reference.
## 6. Analysis — review
Continue with the "Review" part of `references/analysis-procedure-.md` (steps 6–10: open the raw file for every fail and warn, compare anomalies against the check definitions, `type: llm` checks and correlation, reconcile conflicting findings, apply the severity rules ①–⑤ including `symptom_linked` and `rename_suspects`), then its "Read-only commands outside the snapshot", "Severity guidance" and "Values that collection itself disturbed" paragraphs. Do not start writing until every fail and warn has been reviewed.
**A finding that appeared or disappeared because the checks changed is not a defect and not a cluster change.** `diff.json` `findings.criteria_changes` already holds them, sorted by code: checks absent or gated off on one side, checks whose rule hash differs, checks whose thresholds in force differ. Write them in section 3 as a "criteria change" and leave them out of the tool notes (7-6) and out of "new" and "resolved".
**Read-only commands outside the snapshot** are allowed only under the three conditions in the reference: read only (section 9 applies unchanged), output saved as `$SNAP/extra/.txt` and recorded in appendix 7-4, port-forwarding via `lib/collection/portfwd.PortForward` without a foreground `sleep` loop.
## 7. Writing the report
You do not write `report.md`. Separate agents do, because one agent doing analysis and writing together writes translated sentences and misses its own mistakes. **Read `references/report-writing-.md` and `references/facts-.md` now and follow them fully** — it is mandatory, not optional.
1. **Writing again from an existing snapshot.** A snapshot holds one report. If `$SNAP/report.md` already exists, as with `--snapshot`, run this first so the earlier report is kept instead of replaced, and do not open that folder: `$KUBEGAP/scripts/kubegap keep-report --context --snapshot "$SNAP"` moves it to `$SNAP/earlier-reports/