Pin down structure and depth for plan execution summaries

Codifies the pattern the rewritten Step 0 entry demonstrated: one line of
context before each command snippet explaining why it was run that way,
explicit call-outs when something deviated from the plan rather than
presenting the working command as the first thing tried, and a closing
"worth noting" paragraph. Points at the Step 0 entry itself as the
reference example so future steps match its depth without re-deriving it.

Co-Authored-By: Claude <noreply@anthropic.com>

CLAUDE.md

@@ -116,8 +116,23 @@ command-line actually run, not a paraphrase. Prefer the real invocation over a
 description of it; a future reader (or a future Claude) should be able to copy the
 snippet and reproduce the step. Trim noisy stdout, but keep anything that changed the
 outcome (a flag that mattered, an unexpected error, a version that got picked
-automatically). Commit the summary update together with that step's implementation
+automatically).
-commit.
+
+**Structure each command snippet with one line of context before it** — why it was run
+that way, not just that it was run (e.g. "installed into a scratch `GOBIN` because the
+plan's install path 404s" beats a bare command with no framing). When something
+deviated from what the plan said — a flag correction, a version resolved differently
+than expected, a tool auto-running another tool — call that out explicitly rather than
+presenting the final working command as if it were the first thing tried. Close the
+entry with a short "worth noting" paragraph covering anything a future reader should
+know before touching this step's output: defaults that came out differently than
+planned, files outside the plan's scope that got touched, things deliberately left for
+a later step.
+
+Use the Step 0 entry in `docs/plans-executions/2026-08-07-1747-proxy-operator.md` as
+the reference example for the level of detail expected.
+
+Commit the summary update together with that step's implementation commit.
 
 ### Changelog