From 652f155baf74389ae208066e49a5008b72404851 Mon Sep 17 00:00:00 2001 From: Jan Novak Date: Fri, 7 Aug 2026 20:38:03 +0200 Subject: [PATCH] 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 --- CLAUDE.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 1224782..58794ed 100644 --- a/CLAUDE.md +++ b/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 -commit. +automatically). + +**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