proxy-operator: Kubernetes operator for crawling-proxy fleets #1
19
CLAUDE.md
19
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user