release: v6.5.10 (Planned-code compile-validity bug-class)

.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"

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/<plugin-name>/<plugin-name>` + 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