@gordon.gan/specflow 1.0.1 → 1.0.2

package/README.md

@@ -59,17 +59,17 @@ npm link
 在有源码的机器上打包：
 ```bash
 npm run build
-npm pack          # 生成 gordon.gan-specflow-1.0.1.tgz
+npm pack          # 生成 gordon.gan-specflow-1.0.2.tgz
 ```
 在目标机器上安装：
 ```bash
-npm install -g ./gordon.gan-specflow-1.0.1.tgz
+npm install -g ./gordon.gan-specflow-1.0.2.tgz
 ```
 
 ### 验证安装
 
 ```bash
-specflow --version   # 应输出 1.0.1
+specflow --version   # 应输出 1.0.2
 specflow --help
 ```
 
@@ -125,8 +125,6 @@ specflow init
 **每阶段深度思考 → 多轮迭代精化**：每个阶段一次性产出实质内容（非占位骨架），再通过内部多轮迭代把 artifact 精化到稳态，最后进入执行。
 
 ```
-/specflow:scan    [规划中 · v0.3] 扫描已有代码生成 specs 基线；当前请直接用 /specflow:propose 描述已有行为
-       ↓
 /specflow:explore [可选] 需求模糊时：读代码、比方案、定边界 → 产出 explore.md
        ↓
 /specflow:propose    一次产出 4 个 artifact：proposal + delta specs + design + tasks（first-iteration 深度思考，非纯骨架）
@@ -231,8 +229,7 @@ cd legacy-project
 specflow init
 
 # 在 Claude Code 里：
-# 注意：/specflow:scan 当前规划在 v0.3，未实现。
-# v0.2.x 的推荐做法是：需求模糊时先 /specflow:explore；或需求清晰时直接进 plan，
+# 棕地项目：需求模糊时先 /specflow:explore；或需求清晰时直接 /specflow:propose，
 # 在 proposal Q&A 里描述已有行为 + 新增变更，让 propose 为将要改动的 capability 生成 delta spec 基线。
 /specflow:explore "描述模糊问题或不确定的改法"   # 可选
 /specflow:propose "描述已有行为 + 你这次要改的新功能"
@@ -277,7 +274,6 @@ specflow init
 
 | 命令 | 说明 |
 |---|---|
-| `/specflow:scan` | **[规划中 · v0.3]** 扫描已有代码库生成 specs 基线；v0.2.x 未实现，触发时 skill 会提示替代方案 |
 | `/specflow:explore` | **需求模糊时** 先探索：读代码、比方案、定边界，产出 `explore.md`，再 handoff 到 propose |
 | `/specflow:propose` | 需求规划：生成 proposal + delta specs |
 | `/specflow:refine` | 技术方案探讨（brainstorming + design.md） |
@@ -447,10 +443,6 @@ nvm use 20
 npm install -g @gordon.gan/specflow
 ```
 
-### code-review-graph 安装失败
-
-`/specflow:scan` 规划在 v0.3 实现时会用到 code-review-graph（当前在 optionalDependencies 里占位）。这个依赖是从 GitHub 安装的，如果网络问题导致失败，**不影响任何 v0.2.x 功能**——scan 本身在 v0.2.x 不可用，其余所有命令与此依赖无关。
-
 ---
 
 ## 来源与许可

package/dist/integrations/shared/capability-evidence.js

@@ -1,6 +1,5 @@
 import { COMMAND_IDS } from './command-catalog.js';
 const MARKER_RULES = [
-    { id: 'sub.scan.planned_v03_notice', skill: 'scan', includes: ['[PLANNED v0.3]', 'NOT YET FUNCTIONAL'] },
     { id: 'sub.explore.conversation_first', skill: 'explore', includes: ['think-before-propose', 'Do NOT write proposal'] },
     { id: 'sub.explore.handoff_propose', skill: 'explore', includes: ['explore.md', 'handoff'] },
     { id: 'sub.explore.mid_change_reexplore', skill: 'explore', includes: ['Re-explore Mid-Change', 'stuck during'] },
@@ -17,7 +16,6 @@ const MARKER_RULES = [
     { id: 'sub.archive.archive_merge', skill: 'archive', includes: ['specflow change archive', 'delta specs into main specs'] },
     { id: 'sub.fix.urgent_mode', skill: 'fix', includes: ['--urgent', 'skip'] },
     { id: 'sub.snap.posthoc', skill: 'snap', includes: ['post-hoc', 'archive'] },
-    { id: 'failure.scan.not_implemented_guard', skill: 'scan', includes: ['do NOT attempt to run `specflow scan`'] },
     { id: 'failure.explore.proposal_exists_redirect', skill: 'explore', includes: ['explore is too late', 'refine'] },
     { id: 'failure.propose.explore_draft_gate', skill: 'propose', includes: ['Status: draft', 'REFUSE to proceed'] },
     { id: 'failure.apply.phase_gate', skill: 'apply', includes: ['HARD GATE (prerequisite)', 'phase is not `refined`, REFUSE'] },

package/dist/integrations/shared/command-catalog.js

@@ -1,5 +1,4 @@
 export const COMMAND_CATALOG = [
-    { id: 'scan', description: 'Brownfield project scanner via code-review-graph' },
     { id: 'explore', description: 'Think-before-propose exploration when requirements are fuzzy' },
     { id: 'propose', description: 'Create proposal and spec artifacts for a change' },
     { id: 'refine', description: 'Refine and iterate on spec artifacts' },

package/dist/integrations/shared/parity-manifest.js

@@ -6,7 +6,6 @@ export const CAPABILITY_MANIFEST = [
         level: 'command',
         required: true,
     })),
-    { id: 'sub.scan.planned_v03_notice', commandId: 'scan', level: 'sub-capability', required: true },
     { id: 'sub.explore.conversation_first', commandId: 'explore', level: 'sub-capability', required: true },
     { id: 'sub.explore.handoff_propose', commandId: 'explore', level: 'sub-capability', required: true },
     { id: 'sub.explore.mid_change_reexplore', commandId: 'explore', level: 'sub-capability', required: true },
@@ -23,7 +22,6 @@ export const CAPABILITY_MANIFEST = [
     { id: 'sub.archive.archive_merge', commandId: 'archive', level: 'sub-capability', required: true },
     { id: 'sub.fix.urgent_mode', commandId: 'fix', level: 'sub-capability', required: true },
     { id: 'sub.snap.posthoc', commandId: 'snap', level: 'sub-capability', required: true },
-    { id: 'failure.scan.not_implemented_guard', commandId: 'scan', level: 'failure-path', required: true },
     { id: 'failure.explore.proposal_exists_redirect', commandId: 'explore', level: 'failure-path', required: true },
     { id: 'failure.propose.explore_draft_gate', commandId: 'propose', level: 'failure-path', required: true },
     { id: 'failure.apply.phase_gate', commandId: 'apply', level: 'failure-path', required: true },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gordon.gan/specflow",
-  "version": "1.0.1",
+  "version": "1.0.2",
   "type": "module",
   "description": "SpecFlow — unified spec-driven development: OpenSpec planning + Superpowers execution in one CLI and cross-IDE workflow",
   "keywords": [
@@ -60,9 +60,6 @@
     "js-yaml": "^4.1.0",
     "zod": "^3.24.4"
   },
-  "optionalDependencies": {
-    "code-review-graph": "github:tirth8205/code-review-graph"
-  },
   "devDependencies": {
     "@types/js-yaml": "^4.0.9",
     "@types/node": "^22.15.3",

package/prompts/reference/specflow/example-design.md

@@ -216,7 +216,7 @@ my-project/
 
 ### D7: Scan via code-review-graph
 
-**Choice**: `/specflow:scan` uses code-review-graph (npm dependency) to analyze codebase structure, then converts the analysis output into OpenSpec specs format.
+**Choice (deferred):** A future `/specflow:scan` may use code-review-graph to analyze codebase structure and convert output into OpenSpec specs format. Scan is **not shipped** in public releases; brownfield onboarding uses `/specflow:explore` or `/specflow:propose` instead.
 
 **Why**: Code analysis is a hard problem. Rather than building a custom AST parser for every language, leverage an existing tool that generates structured project knowledge. SpecFlow's value-add is converting that knowledge into actionable specs.
 

package/schemas/specflow/schema.yaml

@@ -1,13 +1,8 @@
 name: specflow
 version: 3
-description: SpecFlow workflow — scan → explore → propose → refine → apply → review → test → verify → archive
+description: SpecFlow workflow — explore → propose → refine → apply → review → test → verify → archive
 
 artifacts:
-  - id: scan
-    generates: "specflow/specs/**/*.md"
-    description: Brownfield project scan - generates specs baseline
-    requires: []
-
   - id: explore
     generates: "explore.md"
     description: Pre-plan exploration - problem space, options, and recommended direction

package/skills/specflow-scan/SKILL.md

@@ -1,48 +0,0 @@
----
-name: specflow-scan
-description: "[PLANNED v0.3] Brownfield project scanner -- not yet functional"
----
-
-# SpecFlow: Scan (Planned — v0.3)
-
-> **NOT YET FUNCTIONAL.** The `specflow scan` CLI subcommand does not exist in v0.2.x. Invoking this skill would immediately fail when it tries to run `specflow scan`. The skill is kept registered so its slot is reserved in the command namespace; the implementation is planned for v0.3.
-
-## Behavior in v0.2.x
-
-If the user triggers `/specflow:scan` or `$specflow-scan`, do NOT attempt to run `specflow scan` (the CLI will return an unknown-command error). Instead respond:
-
-> "`/specflow:scan` / `$specflow-scan` is planned for v0.3 and not yet implemented in v0.2.x. For a brownfield project that has no `specflow/specs/` baseline yet, the workable alternative today is:
->
-> 1. Run `specflow init --ide both` (or `--ide all` / `--ide codex`) if not already done (creates `specflow/` and IDE assets under `.cursor/`, `.claude/`, and/or `.agents/`).
-> 2. Identify one capability area you are about to change (e.g. `user-auth`, `billing`).
-> 3. Run `/specflow:explore` when requirements are fuzzy, then `/specflow:propose`. Or run `/specflow:propose` directly if you already know exactly what to build. In the proposal Q&A, describe the existing behavior in the affected area — propose will generate both the delta spec for your change and an implicit first pass at the capability's contract. After the first archive, the delta becomes the main spec baseline for that capability.
->
-> This is not a perfect substitute for a full code scan, but it keeps the spec-driven flow moving without waiting for v0.3."
-
-Then stop. Do not proceed to any Stage 1/2/3 behavior below — those describe the planned v0.3 flow.
-
-## Planned design (v0.3) — for reference, not currently executable
-
-### Planned Stage 1: Execute Scan
-
-Run `specflow scan` against the target project. If `--module` flag is provided, read the IDE-local prompt file:
-
-- Cursor: `.cursor/specflow/prompts/shared/dispatching-parallel-agents.md`
-- Claude: `.claude/specflow/prompts/shared/dispatching-parallel-agents.md`
-- Codex: `.agents/specflow/prompts/shared/dispatching-parallel-agents.md`
-
-Then scan modules in parallel; otherwise run a single pass.
-
-### Planned Stage 2: Present Results
-
-Scan produces `specflow/SCAN_REPORT.md`. Present a summary highlighting detected modules, identified specs and coverage gaps, and suggested next actions.
-
-### Planned Gate: User Confirmation
-
-Ask the user to confirm the scan results. Do NOT proceed until explicit confirmation. Confirmed results become the Source of Truth for all downstream commands.
-
-### Planned Stage 3: Finalize
-
-Once confirmed, the scan results are locked and the user can run `/specflow:propose` to begin requirements planning.
-
-The v0.3 design rationale, scope, and risks will be captured in a dedicated `openspec` change at v0.3 planning time.