@gordon.gan/specflow 1.4.0-beta → 1.4.1

package/skills/database/redis/references/redis-conf-production.md

@@ -0,0 +1,139 @@
+# Redis 生产配置最佳实践
+
+## 推荐生产配置 (redis.conf)
+
+```conf
+# ────────────────────────────────────
+# 基础配置
+# ────────────────────────────────────
+daemonize no
+pidfile /var/run/redis_6379.pid
+port 6379
+bind 0.0.0.0                        # 生产环境改为内网 IP
+protected-mode yes
+
+# ────────────────────────────────────
+# 内存管理
+# ────────────────────────────────────
+maxmemory 4gb
+maxmemory-policy allkeys-lru
+maxmemory-samples 10                # LRU 采样样本数 (越大越精确)
+
+# ────────────────────────────────────
+# 持久化 — 混合模式
+# ────────────────────────────────────
+save 900 1
+save 300 10
+save 60 10000
+stop-writes-on-bgsave-error yes
+rdbcompression yes
+rdbchecksum yes
+dbfilename dump.rdb
+dir /data/redis/
+
+appendonly yes
+appendfilename "appendonly.aof"
+appendfsync everysec
+no-appendfsync-on-rewrite no
+auto-aof-rewrite-percentage 100
+auto-aof-rewrite-min-size 64mb
+aof-load-truncated yes
+aof-use-rdb-preamble yes             # 混合持久化 (Redis 4.0+)
+
+# ────────────────────────────────────
+# 网络与连接
+# ────────────────────────────────────
+tcp-backlog 511
+timeout 300
+tcp-keepalive 300
+maxclients 10000
+
+# ────────────────────────────────────
+# 复制
+# ────────────────────────────────────
+replica-serve-stale-data yes
+replica-read-only yes
+repl-diskless-sync no
+repl-diskless-sync-delay 5
+repl-disable-tcp-nodelay no
+replica-priority 100
+
+# ────────────────────────────────────
+# 安全
+# ────────────────────────────────────
+requirepass your-strong-password-here
+rename-command FLUSHALL ""
+rename-command FLUSHDB ""
+rename-command CONFIG ""
+rename-command SHUTDOWN ""
+rename-command DEBUG ""
+rename-command SLAVEOF ""
+
+# ────────────────────────────────────
+# 慢查询日志
+# ────────────────────────────────────
+slowlog-log-slower-than 10000       # 记录 >10ms 的命令
+slowlog-max-len 128
+
+# ────────────────────────────────────
+# 高级配置
+# ────────────────────────────────────
+hash-max-ziplist-entries 512
+hash-max-ziplist-value 64
+list-max-ziplist-size -2
+list-compress-depth 0
+set-max-intset-entries 512
+zset-max-ziplist-entries 128
+zset-max-ziplist-value 64
+
+hz 10
+dynamic-hz yes
+activedefrag yes                     # 自动碎片整理 (Redis 4.0+)
+```
+
+## Docker 部署
+
+```bash
+# 单机 Redis
+docker run -d --name redis \
+    -p 6379:6379 \
+    -v /data/redis/data:/data \
+    -v /data/redis/redis.conf:/usr/local/etc/redis/redis.conf \
+    redis:7-alpine redis-server /usr/local/etc/redis/redis.conf
+
+# Redis Cluster
+docker network create redis-cluster
+
+for port in 7000 7001 7002 7003 7004 7005; do
+    mkdir -p /data/redis/${port}
+    docker run -d --name redis-${port} \
+        --net redis-cluster \
+        -p ${port}:${port} \
+        -v /data/redis/${port}:/data \
+        redis:7-alpine redis-server \
+            --port ${port} \
+            --cluster-enabled yes \
+            --cluster-config-file nodes.conf \
+            --cluster-node-timeout 5000 \
+            --appendonly yes
+done
+
+# 创建集群
+docker exec redis-7000 redis-cli --cluster create \
+    192.168.1.100:7000 192.168.1.100:7001 192.168.1.100:7002 \
+    192.168.1.100:7003 192.168.1.100:7004 192.168.1.100:7005 \
+    --cluster-replicas 1
+```
+
+## 性能调优检查清单
+
+- [ ] `maxmemory` 设置为物理内存的 60-70%
+- [ ] `maxmemory-policy` 设为 `allkeys-lru`（缓存场景）
+- [ ] 禁用危险命令（FLUSHALL/CONFIG/EVAL...）
+- [ ] 慢查询阈值 ≤ 10ms
+- [ ] 连接池配置合理（maxTotal ≤ maxclients）
+- [ ] Big Key 已拆分或索引
+- [ ] 不分业务混用实例
+- [ ] 监控指标已接入（INFO 命令定期采集）
+- [ ] RDB + AOF 混合持久化已配置
+- [ ] 主从 / Sentinel / Cluster 已部署

package/skills/specflow-approval/SKILL.md

@@ -80,28 +80,44 @@ change names, file paths, commands, and code in their original form.
    - `Cargo.toml` → Rust
    - `tsconfig.json` → TypeScript (refines Node detection)
    - If none match, set `techStack: unknown`
-5. Read `specflow/specs/` baseline if it exists (for Pass 7 baseline cross-check).
+5. **Detect database stack** (for §4.4 guidance). Follow
+   `prompts/approval/database-guidance.md` §1 — set
+   `dbStack: mysql|postgresql|oracle|redis|elasticsearch|none`. Prefer OLTP
+   (`mysql`/`postgresql`/`oracle`) over cache/search when multiple match.
+6. Read `specflow/specs/` baseline if it exists (for Pass 7 baseline cross-check).
 
-Announce: "Generating technical approval document for change `<name>` (phase=refined, language=<lang>, techStack=<stack>)."
+Announce: "Generating technical approval document for change `<name>` (phase=refined, language=<lang>, techStack=<stack>, dbStack=<db>)."
 
 ---
 
 ## Stage 2: Load Execution Instructions
 
-Read the file at `.claude/specflow/prompts/approval/generate.md` and follow its instructions.
+Read these files and follow them:
 
-That prompt file contains the complete specification for:
+1. `.claude/specflow/prompts/approval/generate.md` (or repo `prompts/approval/generate.md`)
+2. `prompts/approval/database-guidance.md` — DB skill router for **local** packs under
+   `skills/database/` (in-repo maintenance; **no remote skill dependency**). **Not an MCP
+   tool**: on `dbStack` hit, `Read` matched `SKILL.md` + focused references; on `none`,
+   LLM-only §4.4.
+
+`generate.md` + `database-guidance.md` together specify:
 
 - The 7-dimension closed-loop verification (Passes 1–7, each with AI self-prompt, verdict rules, evidence format)
 - The design quality assessment (over-engineering signals + extensibility signals)
-- The architecture design (Mermaid module-dependency/system-interaction diagrams + core-component responsibility & boundary table, with project-type adaptation)
-- The detailed design generation (data structures / interfaces / business flow / core logic / config / compatibility, with project-type adaptation and traceability rules)
-- The test strategy (layered test matrix: unit/integration/acceptance/regression/performance-security-compat, each layer mapped to acceptance criteria)
-- The deployment/release/rollback plan (deployment method/order, release strategy, rollback, monitoring; selective with "不涉及运行时部署" for pure-library projects)
+- The architecture design (Mermaid diagrams + **图要点说明** + core-component table)
+- The detailed design generation (设计要点一览 + Happy Path 完整时序 + 业务场景时序与说明 +
+  data ER/DDL + interfaces inventory/fields/examples/errors + logic/config/compat)
+- The test strategy (layered test matrix mapped to §5 acceptance criteria)
+- The deployment/release/rollback plan
 - The implementability assessment (7 dimensions with verdict rules)
 - The approval document structure and generation rules
 - Protocol-marker preservation and language policy enforcement
-- Dashboard count computation (must be precise, not AI-guessed)
+- §1 绪论与边界 (proposal + optional explore + AI; absorbs What/Impact; **no 变更摘要 chapter**;
+  pain-point diagram, User Journey, Non-Goals with reasons)
+- Document order: §1 绪论 → §2 评估 → §3 架构 → §4 详细设计 → **§5 验收标准** → §6 测试 → …
+- **Quality Gates G1–G4** + **Style & Tone** (hard rules in generate.md Part E)
+- **DB guidance router** (`database-guidance.md` + local `skills/database/`): match project
+  stack → Read in-repo skill; no hit → LLM fallback; **never** fetch remote skills / MCP wrap
 - Anchor-file extraction and code-reading rules (depth: anchor file only, no recursion)
 
 You MUST read `generate.md` before performing any analysis or writing `approval.md`. Do not
@@ -150,13 +166,9 @@ Perform the 7 closed-loop passes defined in `generate.md`, in order:
 7. **Pass 7 — Baseline Cross-Check**: delta specs vs `specflow/specs/` main baseline —
    conflict detection, duplicate-definition detection, MODIFIED name matching.
 
-Each Pass must produce visible output to the user:
-
-- **Verdict**: `PASS` | `WARNING` | `FAIL` | `SKIPPED`
-- **Evidence**: concrete citations (file, section, requirement name, scenario name, line)
-
-Present each Pass's result as it completes — do not batch all 7 at the end. The user should
-see the reasoning unfold and can interject if a Pass reveals something that changes direction.
+Each Pass must produce a brief result for the conversation (verdict + one-line evidence).
+Do **not** dump full coverage matrices into chat unless the user asks or a Pass is
+`WARNING`/`FAIL`.
 
 ### Closed-Loop Overall Verdict
 
@@ -166,6 +178,10 @@ After all 7 Passes:
 - `PASS WITH WARNINGS` if no `FAIL` but at least one `WARNING`
 - `PASS` if all Passes are `PASS` (a `SKIPPED` Pass does not affect the verdict)
 
+When writing `approval.md` **§8**, use the **single compact table** only (see generate.md
+Part E §8): no per-Pass long sections, no duplicate summary table. Expand evidence only
+for ⚠️/❌ rows (max 2–3 bullets).
+
 ---
 
 ## Stage 5: Design Quality Assessment
@@ -208,61 +224,45 @@ Scan `design.md` for the 5 extensibility signals:
 
 ## Stage 6: Architecture Design
 
-Produce the **architecture design** section (approval.md §5 架构整体设计) defined in
+Produce the **architecture design** section (approval.md **§3** 架构整体设计) defined in
 `generate.md` Part E. This answers "what modules make up the system, how they depend on
 and interact with each other, and what each module's responsibility and boundary is."
 
 It is complementary to Detailed Design: architecture is about **module-to-module
 relationships** (macro), detailed design is about **module-internal implementation**
-(micro).
-
-### 5.1 Overall Architecture
+(micro). Architecture is placed **before** acceptance criteria so implementers read
+structure first.
 
-Draw a Mermaid diagram — **system interaction diagram** or **module dependency diagram**:
+### 3.1 Overall Architecture
 
-- **Module dependency / layered diagram** — `mermaid flowchart LR` (modules as nodes,
-  dependencies as edges)
-- **System interaction diagram** — `mermaid sequenceDiagram` (participants as modules/roles)
+Draw Mermaid diagram(s) — module dependency / layered and optionally system interaction:
 
 Requirements:
 
-1. **Mark changed modules** (`[新增]` / `[修改]` labels or color) so the reviewer can see
-   the change surface at a glance.
-2. Label edges with dependency direction (who depends on whom) or interaction message
-   (who calls whom, passing what).
+1. **Mark changed modules** (`[新增]` / `[修改]`) so the change surface is visible.
+2. Label edges with dependency direction or interaction messages.
 3. Project-type mapping: CLI/library → `src/core/*`, `src/cli/*`; Web → services/components;
    multi-repo → repositories/services.
-4. The diagram must be consistent with §4 decisions — every structure shown must trace to
-   a decision.
+4. Consistent with **§2** decisions.
+5. **Hard rule — 图要点说明**: every architecture diagram MUST be followed by a numbered
+   「设计说明 / 图要点」list (boundaries, invariants, reuse vs new) — not a restatement of
+   node names. Align with scenario-job-compile §3 style.
 
-### 5.2 Core Components
-
-Define each module/component's responsibility and boundary in a table:
+### 3.2 Core Components
 
 | Component | Responsibility | Boundary (does / does NOT) | Depends on | Change type |
 |-----------|---------------|----------------------------|-----------|-------------|
 
-Requirements:
-
-1. List **all involved components** (added + modified) with responsibility, boundary,
-   dependency.
-2. Boundary must state **what it does NOT do** — to keep logic in the right module (e.g.,
-   CLI does not parse slash args, core layer does not do AI reasoning).
-3. Dependency direction explicit, avoid circular dependencies.
-4. **Consistent with §5.1 diagram**: every table component appears in the diagram; table
-   dependencies match diagram edges.
-5. Each component boundary traces to a §4 decision.
+Requirements: list added+modified components;「不做什么」boundaries; 1:1 with diagram;
+trace to §2 decisions. Optional short「组件边界总原则」list.
 
-**If the change does not alter architecture**: write the explicit `不涉及架构变更(单模块/
-单文件调整,模块边界无变化)` marker instead of leaving blank.
+**If no architecture change**: write explicit `不涉及架构变更(...)` marker.
 
-### 5.3 Architecture Consistency Self-check
+### 3.3 Architecture Consistency Self-check
 
-- Diagram marks added/modified modules; change surface visible at a glance.
-- Each component has a "does NOT do" boundary.
-- Diagram and table correspond 1:1.
-- Component boundaries trace to §4 decisions.
-- Uninvolved categories carry the explicit "不涉及架构变更" marker.
+- Diagrams mark added/modified modules; each has 图要点说明.
+- Each component has a "does NOT do" boundary; diagram ↔ table 1:1.
+- Boundaries trace to §2 decisions.
 
 Present the architecture design to the user as part of the confirmation summary.
 
@@ -270,138 +270,55 @@ Present the architecture design to the user as part of the confirmation summary.
 
 ## Stage 7: Detailed Design
 
-Produce the **detailed design** section (approval.md §6 方案详细设计) defined in
-`generate.md` Part E. This takes the plan from "macro decisions" to "implementer-ready
-detail".
-
-The detailed design is **selective**: cover only the categories this change actually
-involves. For each category NOT involved, write the explicit "不涉及 X" marker instead of
-leaving it blank.
+Produce the **detailed design** section (approval.md **§4** 方案详细设计) defined in
+`generate.md` Part E.
 
-Categories (from `generate.md` §6.1–6.6):
+**Selective** categories; uninvolved ones get explicit「不涉及 X」markers.
 
-1. **数据结构 / 数据模型变更** — table structures, fields, types, constraints, index
-   recommendations (query-driven), data migration. For CLI/library projects: config
-   structure, state files, YAML schema.
-2. **接口设计** — API/RPC/CLI command signatures, input params (name/type/required/valid
-   values/defaults), output shapes, error-code definitions with status-code mapping.
-3. **业务流程** — sequence description (who calls whom, order, branches, error paths) or
-   state-machine transitions (states/events/conditions/terminal). Use Mermaid
-   `sequenceDiagram` / `stateDiagram-v2` when clarifying.
-4. **核心算法 / 逻辑说明** — input/output, processing steps, complexity, boundary conditions.
-5. **配置与运行环境** — new config keys, env vars, runtime dependencies.
-6. **兼容性与迁移** — old→new behavior mapping, migration path, rollback.
+Order and hard requirements (from `generate.md` §4.1–4.8):
 
-**Traceability requirement** (hard rule): every detailed-design element must trace to a
-§3 Requirement/Scenario and a §4 decision. If an element cannot be written at
-implementer-ready detail, mark it `[待 refine 澄清: <元素>]` and report it to the user —
-this is a quality signal that the plan is not fully thought through.
+1. **设计要点一览** — P1…Pn invariants from design decisions (required).
+2. **核心业务时序 · Happy Path** — complete Mermaid `sequenceDiagram` for the main success
+   path + post-diagram「设计要点」(required).
+3. **业务场景时序** — each scenario: purpose + diagram + **设计要点说明** (required notes;
+   bare diagrams fail quality).
+4. **数据结构** — Before drafting §4.4: follow `database-guidance.md`. If `dbStack` hit,
+   `Read` `skills/database/<stack>/SKILL.md` (+ DDL/index/JSON refs as needed).
+   If `none`, LLM-only with SpecFlow §4.4 hard bar (ER + full CREATE TABLE + field tables…).
+5. **接口设计** — inventory + fields + examples + errors…
+6. **核心算法 / 配置 / 兼容性** — as applicable.
 
-**Quality self-check** after drafting:
-
-- Every involved category has real content (signatures/fields/states), no blank placeholders.
-- Every uninvolved category has the explicit "不涉及" marker.
-- Data/interface/flow elements trace to spec requirements and design decisions.
+**Traceability**: every element → **§5** Requirement/Scenario and **§2** decision.
+If not implementer-ready, mark `[待 refine 澄清: <元素>]`.
 
 Present the detailed design to the user as part of the confirmation summary.
 
 ---
 
-## Stage 8: Test Strategy
-
-Produce the **test strategy** section (approval.md §7 测试策略) defined in `generate.md`
-Part E. This upgrades "is §3 acceptance verifiable" into "**how will layered tests prove
-the plan is correct**." It answers: which test layer covers each acceptance criterion
-(WHEN/THEN), with what tool, proving what.
-
-### 8.1 Layered Test Matrix
-
-Produce a layered test matrix:
-
-| Test layer | Covers | Tool/framework | Goal (proves what) | Acceptance criteria covered |
-|-----------|--------|---------------|--------------------|----------------------------|
-
-Layers (selective — only those this change actually needs):
-
-- **Unit tests** — core functions/classes/internal logic
-- **Integration tests** — module interactions, interface contracts, external deps
-- **Acceptance tests** — spec WHEN/THEN user-visible behavior (E2E / CLI tests)
-- **Regression tests** — main-spec baseline + existing behavior
-- **Performance / security / compatibility** — NFR goals (as applicable)
-
-Requirements:
-
-1. Each test layer **maps to §3 acceptance criteria** (cite specific Scenario names) — this
-   closes the loop between test strategy and acceptance criteria.
-2. Each layer annotates **tool/framework** (echoing full-stack-skills' phase→skill mapping:
-   test phase → test-writer/playwright/pytest).
-3. **Goals must be verifiable** ("prove P95 < 200ms", not "test performance").
-4. Distinguish **new tests** vs **modifications to existing tests**.
-
-### 8.2 Test Environment & Data
-
-Cover: test environment (local tmpdir / isolated CI), fixture/seed data (incl. Chinese/
-English samples), parallelism/isolation, coverage target.
-
-### 8.3 Test Strategy Self-check
-
-- Every §3 acceptance criterion is covered by ≥1 test layer (closed loop).
-- Every test layer has a tool and a verifiable goal.
-- Existing behavior is protected by regression tests (corresponds to Pass 7 baseline).
-- New tests vs modifications to existing tests are distinguished.
+## Stage 8: Acceptance Criteria (after design)
 
-**If the change needs no testing**: write the explicit `不涉及测试变更(纯文档/配置变更,无
-行为逻辑需要测试)` marker.
-
-Present the test strategy to the user as part of the confirmation summary.
+Produce **§5 验收标准** only **after** §3 architecture and §4 detailed design are drafted
+in the document order. Exhaustive Requirement + Scenario list with 3-level testability.
+Do not place acceptance before the design chapters.
 
 ---
 
-## Stage 9: Deployment & Release
-
-Produce the **deployment / release / rollback** section (approval.md §8 部署/发布/回滚方案)
-defined in `generate.md` Part E. This answers "how does the change go live, how is it
-released, how do we roll back if something breaks, and how do we monitor it after launch."
-
-**Selective**: mandatory for projects with a running system; pure library/CLI/documentation
-projects write the explicit `不涉及运行时部署(纯库/CLI/文档项目,无服务上线,变更通过包发布/
-版本发布交付)` marker.
-
-### 9.1 Deployment Plan
+## Stage 9: Test Strategy
 
-Cover: deployment target (prod/staging/multi-env), deployment method (image/package/code/
-config; CI pipeline steps), deployment order (e.g. DB migration before app deploy), config
-management (new keys per env, secrets), environment differences.
+Produce the **test strategy** section (approval.md **§6** 测试策略). Every §5 acceptance
+criterion maps to ≥1 test layer with tools and verifiable goals.
 
-### 9.2 Release Strategy
-
-Cover: release method (blue-green / canary / rolling / direct replace + rationale), release
-window / canary ratio, old-new compatibility during coexistence (API versioning, DB compat).
-
-### 9.3 Rollback Plan
-
-Cover: rollback trigger conditions (error rate / metric thresholds), rollback method (image
-revert / code revert / data rollback; auto or manual), data consistency on rollback
-(if data migration), rollback verification.
-
-### 9.4 Monitoring & Observability
-
-Cover: key metrics to monitor post-launch, logging/tracing, alert thresholds & owner.
-
-### 9.5 Deployment Self-check
+---
 
-- Deployment target / method / order explicit.
-- Release strategy with compatibility.
-- Rollback trigger / method / data consistency / verification explicit.
-- Post-launch monitoring metrics & alerts explicit.
+## Stage 10: Deployment & Release
 
-Present the deployment plan to the user as part of the confirmation summary.
+Produce the **deployment / release / rollback** section (approval.md **§7**).
 
 ---
 
-## Stage 10: Implementability Assessment
+## Stage 11: Implementability Assessment
 
-Perform the 7 implementability dimensions defined in `generate.md` Part C:
+Perform the 7 implementability dimensions defined in `generate.md` Part C.
 
 1. **Completeness** — no TODOs, placeholders, vague tasks
 2. **Spec Alignment** — tasks cover all spec requirements, no scope creep
@@ -421,30 +338,32 @@ Each dimension produces a verdict (`READY` | `NEEDS REFINEMENT` | `BLOCKED`) wit
 
 ---
 
-## Stage 11: Generate approval.md
+## Stage 12: Generate approval.md
 
 Following the document structure and generation rules in `generate.md` Part E, produce
 `approval.md` inside the change directory at `specflow/changes/<name>/approval.md`.
 
+Document chapter order (hard):
+
+1. §1 绪论与边界 (proposal + optional explore + AI; includes What/Impact; **no 变更摘要**)
+2. §2 技术方案评估
+3. §3 架构整体设计 (图 + **图要点说明** + 组件)
+4. §4 方案详细设计 (设计要点 + Happy Path + 业务场景说明 + 数据/接口…)
+5. §5 验收标准 (**after** design)
+6. §6 测试策略 → §7 部署 → §8 闭环 → §9 可实施性 → §10 审批
+
 Key rules:
 
-- Dashboard counts (capability count, requirement count, scenario count, task count, anchor
-  file count, baseline spec count) MUST be computed by reading the actual files, not
-  estimated. If a count is uncertain, say so explicitly rather than guessing.
-- The "Decision Review" table must include every decision found in `design.md`.
-- The "Acceptance Criteria" section must include every Requirement and Scenario from all
-  delta specs, with 3-level testability grading.
-- The "Detailed Design" section must be selective: real content for involved categories,
-  explicit "不涉及" markers for uninvolved ones, every element traceable to spec + decision.
-- The "Test Strategy" section must be a layered matrix where every §3 acceptance criterion
-  is covered by ≥1 layer (closed loop), with tools and verifiable goals.
-- The "Deployment/Release/Rollback" section must be selective: real plan for running
-  systems, explicit "不涉及运行时部署" marker for pure-library/CLI/documentation projects.
-- The "Code Grounding" section (Pass 6 evidence) must cite actual file paths read and
-  concrete findings (function signatures, module structure, compatibility assessment).
-- The human sign-off table must be empty (blank fields for the approver to fill).
-- AI pre-approval recommendation must be grounded in all three verdicts (closed-loop,
-  design quality, implementability) — never recommend "approve" if any verdict is `FAIL`.
+- §1 truthful: pains from proposal/design/confirmed explore; User Journey → §5; Non-Goals with reasons; What/Impact in §1.2.
+- Decision Review includes every `design.md` decision.
+- §5 Acceptance exhaustive with 3-level testability; placed after §3/§4.
+- §3 every architecture diagram has「设计说明 / 图要点」; component table with「不做什么」.
+- §4 has 设计要点一览, complete Happy Path sequence + notes, each business scenario with 设计要点; DB/API hard bars (§4.4/§4.5).
+- **Quality Gates G1–G4**: >5-line prose flow → Mermaid; interfaces need failure examples; JSON/new-column need存量填充策略; rollback data compatibility explicit.
+- **Style & Tone**: plain language; gloss obscure abbreviations on first use; ban「尽量/大概/一般情况下」; use「必须/禁止/采用 XX 方案」.
+- **§8 闭环**: one compact table only; PASS one line; ⚠️/❌ ≤3 bullets; no per-Pass essays.
+- Test Strategy maps every §5 criterion to ≥1 layer.
+- Deployment selective; Code Grounding cites real files; sign-off blank; never recommend approve if any verdict is `FAIL`.
 
 ---
 
@@ -473,7 +392,7 @@ On confirmation:
 
 ---
 
-## Stage 12: Next-Step Suggestions
+## Stage 13: Next-Step Suggestions
 
 Based on the assessment results: