diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
index 46e8904..4a6d966 100644
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.0.3",
+  "version": "0.0.4",
   "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
   "skills": "./skills",
   "author": {
diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json
index 91aae39..039436f 100644
--- a/.codex-plugin/plugin.json
+++ b/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.0.3",
+  "version": "0.0.4",
   "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
   "skills": "./skills"
 }
diff --git a/README.md b/README.md
index e121310..8961b8f 100644
--- a/README.md
+++ b/README.md
@@ -36,7 +36,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安
 
 ### `maintain`
 
-維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。
+維護：讀取維護期內的專案，每個專案一個 sub agent：切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。僅適用於維護期內已交付的專案；尚在實作中或未登記於 `MAINTAIN_CONTENTS` 的專案不適用。
 
 <!-- JSC-SKILLS:END -->
 
@@ -55,7 +55,7 @@ Marketplace 統一為 `jsc`（https://gitea.jsc.idv.tw/plugins/jsc.git），安
 
 Wiki 位置：`PLAN_{HASH}` / `PLAN_CONTENTS` 只讀 `JSC_WIKI_REPO_PLAN`，再退回 `JSC_WIKI_REPO`；`ANALYZE_{HASH}` / `ANALYZE_CONTENTS` 只讀 `JSC_WIKI_REPO_ANALYZE`，再退回 `JSC_WIKI_REPO`；`REPO_{HASH}` / `REPO_CONTENTS` 只讀 `JSC_WIKI_REPO_REPO`，再退回 `JSC_WIKI_REPO`；`MAINTAIN_CONTENTS` 只讀 `JSC_WIKI_REPO_MAINTAIN`，再退回 `JSC_WIKI_REPO`。不同類型不可互相代用；兩者都未設定才詢問（見 `jsc-gitea`）。
 
-HASH 規則：一律先算 `{owner}/{repo}` 的 SHA-1 前 8 碼並轉大寫；若第一碼是數字，或 `A`、`B`、`C`，就改成 `H` 加上原 SHA-1 前 7 碼，總長維持 8 碼。
+HASH 規則：`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/hash-id` 計算（見 `jsc-gitea:wiki`），此 domain 不重複實作演算法。
 
 ## 相關 domain
 
diff --git a/plugin.json b/plugin.json
index 1a89807..a0ca998 100644
--- a/plugin.json
+++ b/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "jsc-sdlc",
-  "version": "0.0.3",
+  "version": "0.0.4",
   "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）",
   "skills": "./skills/"
 }
diff --git a/skills/analyze/SKILL.md b/skills/analyze/SKILL.md
index ea19d5c..0bc991c 100644
--- a/skills/analyze/SKILL.md
+++ b/skills/analyze/SKILL.md
@@ -8,13 +8,13 @@ description: SDLC analysis stage. Gate on the designated model (model-config) or
 Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`.
 This skill is a **logic-only** stage: never output code, and **never modify any file**.
 
-`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
+`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `ANALYZE_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
 All wiki reads and writes go through `jsc-gitea:wiki`.
 
 ## Steps
 
 1. **Model gate and stage lock**:
-   1. Resolve the analyze stage's designated model chain: run `jsc-cli/tools/model-config.sh get analyze`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag).
+   1. Run `jsc-cli/tools/model-config.sh resolve analyze` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high tag).
    2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
    3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md
index 6f29dea..9fa2a66 100644
--- a/skills/implement/SKILL.md
+++ b/skills/implement/SKILL.md
@@ -11,18 +11,17 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
 ## Steps
 
 1. **Model gate and stage lock**:
-   1. Resolve the implement stage's designated model chain: run `jsc-cli/tools/model-config.sh get implement`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag).
+   1. Run `jsc-cli/tools/model-config.sh resolve implement` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag).
    2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
    3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock implement {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
-2. **Resolve environment first**: inspect `JSC_WIKI_REPO_ANALYZE`, `JSC_WIKI_REPO`, `JSC_WIKI_REPO_QUESTION`, `GITEA_HOST`, and `GITEA_TOKEN` before asking the user anything. Use inherited shell values first. If the env vars are present but the tool cannot read them, check the current shell environment before asking.
-3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. Use the shared wiki hash for `{owner}/{repo}` for `{HASH}`: take the first 8 uppercase hex chars of its SHA-1, then replace a leading digit or `A`/`B`/`C` with `H` plus the next 7 chars. Try to rename the current session to the ticket name (skip when the CLI does not support it).
-4. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**.
-5. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.**
-6. List every open item of the work package and implement them **one at a time**:
+2. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it).
+3. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**.
+4. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.**
+5. List every open item of the work package and implement them **one at a time**:
    - Follow the TDD loop: red before green, one slice at a time; rules and anti-patterns in `references/tdd.md` (refactoring belongs to the review stage).
    - After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item.
-7. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
-8. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time.
+6. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
+7. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time.
 
 ## Rules
 
diff --git a/skills/maintain/SKILL.md b/skills/maintain/SKILL.md
index 06499c2..6083262 100644
--- a/skills/maintain/SKILL.md
+++ b/skills/maintain/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: maintain
-description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects.
+description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS.
 ---
 
 # maintain
@@ -11,7 +11,7 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
 ## Steps
 
 1. **Model gate and stage lock**:
-   1. Resolve the maintain stage's designated model chain: run `jsc-cli/tools/model-config.sh get maintain`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance).
+   1. Run `jsc-cli/tools/model-config.sh resolve maintain` to get the required model; if it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance).
    2. If the current model is not the required model, or is missing from the mapping table, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
    3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock maintain {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
    4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects.
diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md
index e01b3a3..59d57d2 100644
--- a/skills/plan/SKILL.md
+++ b/skills/plan/SKILL.md
@@ -8,13 +8,13 @@ description: SDLC planning stage. Gate on the designated model (model-config) or
 Goal: create or extend the wiki plan page `PLAN_{HASH}`.
 This skill is a **logic-only** stage: never output code, and **never modify any file**.
 
-`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
+`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `PLAN_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
 All wiki reads and writes go through `jsc-gitea:wiki`.
 
 ## Steps
 
 1. **Model gate and stage lock**:
-   1. Resolve the plan stage's designated model chain: run `jsc-cli/tools/model-config.sh get plan`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag).
+   1. Run `jsc-cli/tools/model-config.sh resolve plan` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high tag).
    2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
    3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock plan {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.