From 9a89f274655db2dd5e525c48d6d8eed8357eca75 Mon Sep 17 00:00:00 2001 From: Jon Langevin Date: Mon, 29 Jun 2026 15:31:20 -0400 Subject: [PATCH 1/2] feat(adversarial-design-review): add Planned-code compile-validity bug-class MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 2x trend of embedded-Go compile bugs passing plan review as 'embedded code clean' on inspection: capability-assemble retro #1's range-over-slice P1 (`for t := range someSlice`) + scaffold-platform M1's `*Fragment != *Fragment` (FragmentSpec holds a []string → structs with slice fields aren't !=-comparable). The new plan-phase bug-class requires embedded code be compile-valid, not just plausible — covering range-over-slice + struct comparability. Source: docs/retros/2026-06-29-scaffold-platform-m1-retro.md (plugin follow-up). --- skills/adversarial-design-review/SKILL.md | 1 + 1 file changed, 1 insertion(+) 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 From 86e8ff4887596c97b9aad0e7986215e920b5d09b Mon Sep 17 00:00:00 2001 From: Jon Langevin Date: Mon, 29 Jun 2026 16:04:14 -0400 Subject: [PATCH 2/2] release: v6.5.10 (Planned-code compile-validity bug-class) --- .claude-plugin/plugin.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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"