diff --git a/CLAUDE.md b/CLAUDE.md
index c31447d..19782c5 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -50,22 +50,28 @@ Temporary, task-scoped specs derived from the master specs.
 
 ## Current Focus
 
-**Step3: Team Customization** (see `specs/roadmap.md`)
+**v0.1.0 Public Release Preparation** (see `specs/roadmap.md`)
+
+Step1 through Step3 are implemented. Bundle them as the initial public version `v0.1.0` and prepare the repository for public release.
 
 ### Tasks
 
-- [x] Config loading (`internal/config`, `.riskcheck.yaml`)
-- [x] Apply config to existing signals (thresholds, weights, paths, test patterns)
-- [x] S-8: high_complexity signal (`--complexity-file`)
-- [x] S-9: low_coverage signal (`--coverage-file`)
-- [x] CLI flags (`--config`, `--complexity-file`, `--coverage-file`)
-- [x] Sample `.riskcheck.yaml.example`
+- [x] Step1: Minimal (git diff scoring, S-1 to S-3, JSON/Text formatter)
+- [x] Step2: Practical (git log integration, S-4 to S-7, per-file risk)
+- [x] Step3: Team Customization (config, S-8/S-9, init command)
+- [ ] Polish README for a public audience
+- [ ] Tag `v0.1.0`
+- [ ] Make the repository public
 
 ### Exit Criteria
 
-- `.riskcheck.yaml` overrides default behavior
-- External tool output can feed into scoring
-- All existing tests still pass
+- README is self-contained for external readers
+- `v0.1.0` tag exists on `main`
+- Repository is publicly visible
+
+### Post-v0.1.0 (v0.2.0 and beyond)
+
+Discuss with codex based on public feedback and the 4 known concerns (git stderr capture, external signal config, path-matching precision, cmd-package tests). Write the outcome into `specs/roadmap.md` as Step4.
 
 ## Tech Stack
 
diff --git a/README.md b/README.md
index 9e38a2e..db2050b 100644
--- a/README.md
+++ b/README.md
@@ -201,10 +201,9 @@ make clean    # Remove bin/
 
 See [specs/roadmap.md](specs/roadmap.md) for the full implementation plan.
 
-- **v0.1.0** — Basic scoring from git diff (file count, insertions, deletions)
-- **v0.2.0** — Hotspot detection, test change detection, per-file risk
-- **v0.3.0** — Team-specific configuration, external tool integration
-- **v1.0.0** — Stable API
+- **v0.1.0** — Initial public release. Bundles git diff scoring, hotspot/test detection with per-file risk, and team-specific configuration with external tool integration (Step1 + Step2 + Step3).
+- **v0.2.0+** — Post-public iteration based on real-world feedback (Step4: TBD).
+- **v1.0.0** — Stable API, battle-tested with real projects.
 
 ## License
 
diff --git a/specs/roadmap.md b/specs/roadmap.md
index 8b7e423..e468e41 100644
--- a/specs/roadmap.md
+++ b/specs/roadmap.md
@@ -93,16 +93,40 @@ gantt
 
 ## Release Strategy
 
+Step1 through Step3 were implemented prior to the first public release. They are bundled together as the initial public version `v0.1.0`. Subsequent versions track post-public iteration.
+
 ```mermaid
 graph LR
-    S1["v0.1.0<br/>Step1: Minimal"] -->|"git diff based scoring"| S2["v0.2.0<br/>Step2: Practical"]
-    S2 -->|"git log + per-file risk"| S3["v0.3.0<br/>Step3: Customization"]
-    S3 -->|"config + external tools"| V1["v1.0.0"]
+    V01["v0.1.0<br/>Initial public release<br/>(Step1+2+3)"] -->|"polish & dogfood"| V02["v0.2.0+<br/>(Step4: TBD)"]
+    V02 -->|"stable API & battle-tested"| V1["v1.0.0"]
 ```
 
-| Version | Step | Key Value |
-|---------|------|-----------|
-| v0.1.0 | Step1 | "It runs and gives a score" |
-| v0.2.0 | Step2 | "It gives useful, actionable insights" |
-| v0.3.0 | Step3 | "It adapts to your team" |
+| Version | Scope | Key Value |
+|---------|-------|-----------|
+| v0.1.0 | Step1 + Step2 + Step3 | "It runs, gives actionable insights, and adapts to your team" |
+| v0.2.0+ | Step4 (TBD — see roadmap discussion) | Post-public iteration based on real-world feedback |
 | v1.0.0 | - | Stable API, battle-tested with real projects |
+
+## Ideas Under Consideration
+
+Design ideas that have been discussed but are not yet committed to a version. Items here may be promoted into the table above (with a target version), refined further, or dropped.
+
+### Custom evaluation functions / Lua-based rules
+
+Allow teams to define custom risk evaluation logic in Lua (e.g., `.riskcheck.lua`), going beyond the YAML-based config introduced in Step3.
+
+**Motivation**
+
+- `.riskcheck.yaml` covers thresholds, weights, paths, and patterns, but not custom logic.
+- Some teams may want rules that depend on diff content, file relationships, or domain-specific conditions that cannot be expressed in YAML.
+- An embedded Lua runtime (e.g., gopher-lua, Pure Go) keeps the "minimize external execution dependency" stance intact.
+
+**Open questions before adoption**
+
+1. **Necessity**: List 2-3 concrete rules that cannot be expressed in YAML config. If they can, Lua may not be needed.
+2. **API surface**: What does a user-defined function receive (diff stats, file list, git log, existing signal results)?
+3. **Execution model**: Are user functions full signals, or post-processing of the score?
+4. **Portability**: Confirm a Pure Go Lua runtime keeps the binary dependency-free.
+5. **Sandboxing**: Restrict file / network / exec access for `.riskcheck.lua` when running in CI.
+
+**Status**: Future consideration. Possible target: v0.3.0 or later, after the polish work in v0.2.0.