refined-prompt v3.9 → v3.10 released — F-spike-loop step 7 SPIKE-CANDIDATE SCAN
Released: 2026-05-04T22:10 BST (directive frontmatter lastmod); release commit cascade 6390b40..1b33cfb landed on origin/main 2026-05-04T22:25 BST.
What shipped
Single bundled improvement: F-spike-loop. New sub-bullet inside §1 step 7 FRAME of docs/superpowers/specs/2026-04-29-multi-phase-audit/refined-end-of-turn-directive.md:
- **SPIKE-CANDIDATE SCAN [v3.10 / F-spike-loop]**: during scorecard authoring, ...
Placed between the existing - 8 sensitivity perturbations. and - Claude pick ★ + reasoning. bullets — co-located with where the rule’s output (BLOCKING / DEFERABLE sections) appears in the scorecard.
Behaviour: during scorecard authoring, if the author identifies an evidence-thin question that would meaningfully change the lock if validated, surface it as a “Spike candidate” with: (1) gap description; (2) why-it-matters (which option’s score would shift, by how much); (3) cost band (≤30 min / 1-4 h / ½-1 day); (4) bootstrap prompt — runnable in another Claude session. Binary classification: lock-BLOCKING (cannot recommend a lock under current evidence) vs lock-DEFERABLE (lock can proceed; spike improves confidence later). No three-tier; no Δ-threshold; author judgment.
Two new scorecard sections: ## Spike candidates — lock-BLOCKING (N) and ## Spike candidates — lock-DEFERABLE (N). Empty sections written (none surfaced) for completeness.
Bootstrap prompt skeleton: 7 fields (Goal / Triggered by / Substrate to read first / Method / Kill condition / Closure cascade / On completion). Spike-runners inherit existing suite-mode discipline at run-time per running-spike-suites skill — no new infrastructure.
Re-entry: substrate-in-place (existing step 6 sub-letters 6a-6g pick up new T-files / Tier 2 chunks / arch-state rows naturally). No new verification gate.
What’s NOT changed
- Step 6f SPIKES preserved unchanged — its inline mandatory-before-framing spike-validate behaviour is the trivial-spike fast path. SPIKE-CANDIDATE SCAN adds the async option for non-trivial spikes that would produce T-file artefacts surfaced DURING framing.
- Step 6 sub-letters 6a-6g UNCHANGED — verified post-commit:
sed -n '/^6\. /,/^7\. /p' refined-end-of-turn-directive.md | grep -cE '^ [a-z]\.'returns 7. - Prior locks unaffected — Q-001 through Q-014 + the 22-spike + ε.ι + ζ.3 + ν.β suite outcomes stand as recorded under v3.6 / v3.7 / v3.8 / v3.9.
Placement re-decision narrative (notable for future audit reference)
The spec went through TWO placement iterations on 2026-05-04 BEFORE the fresh-session structural review settled on step 7:
| Iteration | Placement | Why corrected |
|---|---|---|
| Spec v1.0 (~19:30) | Step 6e | Wrong: existing rule is at letter f., not e.. Step 6e is WEB RESEARCH. |
| Spec v1.1 (~20:50) | Step 6g | Wrong: existing letter g. is AMAZON CHECK; would have needed 6h. |
| Spec v1.2 (today, 22:00) | Step 7 sub-bullet | The recurring sub-letter iteration was the same semantic mismatch resurfacing — step 6 is substrate-exploration BEFORE framing; the new rule fires DURING framing. Moved to step 7 where the output lives. |
Lesson for future v3.X releases: when a placement keeps requiring sub-letter bumps, step out and check the parent step. Iterating sub-letters within a wrong parent is a strong signal the rule is in the wrong region of the directive.
F4 + F6 status
F4 (closing-question boundary test, locked 2026-04-27 in project CLAUDE.md but not yet operationalised in step 7 / step 8) + F6 (research-completeness scorecard) remain queued v3.10 candidates per the v3.9 lastmod prose. They did NOT bundle into v3.10 alongside F-spike-loop because F-spike-loop’s design session completed first; F4 + F6 will land in a future v3.10.1 / v3.11 bundle when their specs are written.
Solo-bundle decision rationale
F-spike-loop ships solo (against v3.9 precedent which bundled F1+F2+F3+F5+F7+F8 = 6 fixes). Justified by timing asymmetry (one fix’s spec ready, two not), not a deliberate cadence change. Operational reason: shipping today vs holding for a 3-fix bundle delivers ~1-3 weeks of earlier value to the next ζ-Q sessions.
First production use
ζ-Q6 through ζ-Q14 are now ALL locked under v3.9 (Rich confirmed ζ-Q14 locked + submitted at 2026-05-04T22:30 BST during this session). First v3.10 production use will be ζ-Q15 = the next ζ-Q in the natural-sequence ask cycle.
Validation criteria (per implementation plan Task 5):
- Two new sections present in scorecard output, even if both
(none surfaced) - Bootstrap prompt completeness against the 7-field skeleton if any candidate surfaces
- Substrate-in-place re-entry: if an async spike fires + completes, the next refined-prompt run for the same ζ-Q picks up the new T-file / Q-NU update / arch-state row via existing step 6 sub-letters 6a-6g — no special re-entry instruction
- BLOCKING override audit trail: if Rich locks despite a BLOCKING candidate, the lock cascade records the override
If validations 1+2 pass on first use, F-spike-loop is production-validated. Validations 3+4 are opportunistic.
Commit cascade (origin/main; 5 commits)
| Commit | Subject |
|---|---|
6390b40 | spec: F-spike-loop placement re-decided — step 7 sub-bullet (was step 6g) |
f835fe4 | plan: F-spike-loop implementation re-anchored to step 7 sub-bullet |
9941e51 | audit: refined-prompt v3.9 → v3.10 — F-spike-loop step 7 SPIKE-CANDIDATE SCAN |
4cb13e3 | plan: tighten self-review step-6 grep + fix residual step-6g reference + pin bump |
1b33cfb | audit: v3.10 release record — F-spike-loop bundled solo |
Substrate files
- Spec (v1.2+):
docs/superpowers/specs/2026-05-04-spike-suggestion-design.md - Plan (v1.0+; ready):
docs/superpowers/plans/2026-05-04-f-spike-loop-implementation.md - Directive (v3.10):
docs/superpowers/specs/2026-04-29-multi-phase-audit/refined-end-of-turn-directive.md - Audit-record (v1.0):
docs/superpowers/specs/2026-04-29-multi-phase-audit/audit-records/2026-05-04-v3.10-release.md
Pin-drift hook validation (notable)
Commit 4cb13e3 was rejected on first attempt with stale version_pinned: "v3.9+ (2026-05-04T07:20)" floor-pin on companion_files.refined_prompt after the directive bumped to v3.10. python3 scripts/check-frontmatter-pins.py --fix <file> auto-bumped the pin to v3.10+ (2026-05-04T22:10); second attempt passed clean. Snapshot-pins were left untouched (correctly — they record provenance, not a live floor). This is the canonical pin-drift workflow per docs-strategy/CLAUDE.md §6 + workspace-design v1.1+ §6.
CHANGELOG
- 2026-05-04T22:35 — memory file authored at the close of v3.10 release commit cascade. Captures placement re-decision narrative + co-existence with step 6f + first-production-use trigger updated to ζ-Q15 (Rich confirmed ζ-Q14 locked + submitted in parallel session, so ζ-Q14 is NOT first v3.10 use).