diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 88c01d4..0a16763 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "autodev", "description": "Autonomous development workflow skills for coding agents: design, review, planning, execution, monitoring, and retrospectives", - "version": "6.5.9", + "version": "6.5.10", "author": { "name": "Jon Langevin", "email": "jon@gocodealone.com" diff --git a/skills/adversarial-design-review/SKILL.md b/skills/adversarial-design-review/SKILL.md index 23305cc..74b66c2 100644 --- a/skills/adversarial-design-review/SKILL.md +++ b/skills/adversarial-design-review/SKILL.md @@ -119,6 +119,7 @@ inherits the design's blast radius) and adds: | **Plugin-loader runtime layout** | Plans that spawn or load an external plugin process must build the binary in a layout the host's discovery code accepts. For wfctl: `$WFCTL_PLUGIN_DIR//` + sibling `plugin.json`. Plans that `go build -o /tmp/single-binary` without the subdir + manifest sidecar will fail at runtime. | | **Config-validation schema rules** | Plans that create new config files validated by a schema or CLI tool must satisfy that tool's invariants (e.g., for wfctl: `checkEntryPoints` requires ≥1 entry-point module like `http.server`/`scheduler.modular`/`messaging.broker`, OR a trigger/route/subscription/job/pipeline). Plans omitting required entry-point modules pass `bash -n` but fail schema validation at CI. | | **Identifier / naming-convention match** | Config keys, flags, env vars, and command/code examples in the plan match the repo's established naming convention and the identifiers the code will actually use (grep the repo for the convention; a plan showing `snake_case` keys where the codebase uses `camelCase` = finding). **Distinct from `Config-validation schema rules`**, which checks tool-enforced schema invariants — this row checks human naming-convention consistency. Catches design-vs-code drift before code is written. | +| **Planned-code compile-validity** | When the plan **embeds Go (or other compiled) code** in prose/code-fences (struct definitions, helper functions, loop constructs), that code must be **compile-valid**, not just plausible. Two recurring slip classes: (a) **range-over-slice** written as `for t := range someSlice` (t is an int index, not the element) — must be `for _, t := range`; (b) **struct comparability** — structs containing slice/map/function fields (e.g. `FragmentSpec{ Fields []string }`) cannot be compared with `==`/`!=`; compare field-by-field. Eyeballing control flow is not enough; mentally (or actually) compile the embedded snippet. Flag any embedded code that would not compile. (2× trend: capability-assemble retro #1's range-over-slice P1 + scaffold-platform M1's `*Fragment != *Fragment` slip — both passed plan review as "embedded code clean" on inspection alone.) | ## Process