diff --git a/DEVELOPMENT_PLAN.md b/DEVELOPMENT_PLAN.md
index baa9b13..81ecff9 100644
--- a/DEVELOPMENT_PLAN.md
+++ b/DEVELOPMENT_PLAN.md
@@ -279,7 +279,7 @@ POST /monitor/server/heartbeat-v2
   Body:
     identifier: string
     openclaw_version: string        # 远程主机上的 OpenClaw 版本
-    plugin_version: string          # harborforge-monitor 插件版本
+    plugin_version: string          # harbor-forge 插件版本
     cpu_pct: float
     mem_pct: float
     disk_pct: float
@@ -602,16 +602,22 @@ services:
 ### 9.2 监控插件部署
 
 ```bash
-# 1. 在 Monitor 注册服务器，获取 challenge_uuid
+# 1. 在 Monitor 注册服务器并生成 API Key
 # 2. 在服务器安装插件
 node scripts/install.mjs
 
 # 3. 配置 ~/.openclaw/openclaw.json
 {
   "plugins": {
-    "harborforge-monitor": {
-      "enabled": true,
-      "challengeUuid": "YOUR_CHALLENGE_UUID"
+    "entries": {
+      "harbor-forge": {
+        "enabled": true,
+        "config": {
+          "enabled": true,
+          "apiKey": "YOUR_API_KEY",
+          "monitor_port": 9100
+        }
+      }
     }
   }
 }
diff --git a/HarborForge.Backend b/HarborForge.Backend
index 271d514..88931d8 160000
--- a/HarborForge.Backend
+++ b/HarborForge.Backend
@@ -1 +1 @@
-Subproject commit 271d5140e63a7c961b6a964b8aed91e6d30b40b4
+Subproject commit 88931d822dbf595ea34f430202973f62c02caa90
diff --git a/HarborForge.Cli b/HarborForge.Cli
index ddaea1c..b306373 160000
--- a/HarborForge.Cli
+++ b/HarborForge.Cli
@@ -1 +1 @@
-Subproject commit ddaea1c15b8735851b808da26a36b1205508592d
+Subproject commit b3063733a9f8130ef13de24297c1daa98cf7cce2
diff --git a/HarborForge.Frontend b/HarborForge.Frontend
index fd28bb6..ce07ee9 160000
--- a/HarborForge.Frontend
+++ b/HarborForge.Frontend
@@ -1 +1 @@
-Subproject commit fd28bb6b6f580110fa9338f6b72da9fa53b41d3c
+Subproject commit ce07ee902135748f99bc5b4337eb153f91acdbfd
diff --git a/HarborForge.Monitor b/HarborForge.Monitor
index 739b8fc..dc05fa0 160000
--- a/HarborForge.Monitor
+++ b/HarborForge.Monitor
@@ -1 +1 @@
-Subproject commit 739b8fcd742c80760f0f3ef23aa6edad77cc053a
+Subproject commit dc05fa01d11a9b13d537bf0361dac1e56b6b7f87
diff --git a/HarborForge.OpenclawPlugin b/HarborForge.OpenclawPlugin
index afdbc46..e7ba982 160000
--- a/HarborForge.OpenclawPlugin
+++ b/HarborForge.OpenclawPlugin
@@ -1 +1 @@
-Subproject commit afdbc469ad845b8b19b3714e8e0b2c86f8c6cc69
+Subproject commit e7ba98212827010ab459a656c7cf142d2ef0c056
diff --git a/plans/automation/cron/hf-bootstrap-2026-03-21-state.json b/plans/automation/cron/hf-bootstrap-2026-03-21-state.json
new file mode 100644
index 0000000..7d40d6e
--- /dev/null
+++ b/plans/automation/cron/hf-bootstrap-2026-03-21-state.json
@@ -0,0 +1,5 @@
+{
+  "wakeCount": 4,
+  "createdAt": "2026-03-21T12:25:00Z",
+  "updatedAt": "2026-03-21T13:29:00Z"
+}
diff --git a/plans/automation/cron/hf-bootstrap-2026-03-21.prompt.md b/plans/automation/cron/hf-bootstrap-2026-03-21.prompt.md
new file mode 100644
index 0000000..0a663e7
--- /dev/null
+++ b/plans/automation/cron/hf-bootstrap-2026-03-21.prompt.md
@@ -0,0 +1,54 @@
+你是 developer agent 的一个 15 分钟编排 cron 任务。
+
+请在每次被唤醒时，维护并读取下面这个状态文件：
+`/root/.openclaw/workspace/workspace-developer/HarborForge/plans/automation/cron/hf-bootstrap-2026-03-21-state.json`
+
+规则：
+1. 读取 `wakeCount`。
+2. 将其 +1 并写回文件。
+3. 根据新的 wakeCount 执行对应动作。
+4. 每次执行结束后，向 Discord 频道 `1474327736242798612` announce 汇报执行结果。
+
+动作定义：
+
+## 第 1 次唤醒
+执行：
+- 把 HarborForge 主仓和所有子模块从 `main` 拉取最新代码
+- 给所有子模块创建开发分支：`dev-2026-03-21`
+- 如分支已存在，则切换到该分支并确保它基于最新 main
+
+## 第 2 次唤醒
+执行：
+- 创建第二个 cron 定时任务：`hf-dev-kimi-2026-03-21`
+- 频率：每 30 分钟一次
+- agent：`developer`
+- model：`kimi-coding/k2p5`
+- session：`isolated`
+- announce：开启
+- channel：`discord`
+- to：`1474327736242798612`
+- message 内容使用文件：
+  `/root/.openclaw/workspace/workspace-developer/HarborForge/plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md`
+- 如果同名任务已存在，则不要重复创建
+
+## 第 3 次唤醒
+执行：
+- 创建第三个 cron 定时任务：`hf-dev-opus-2026-03-21`
+- 频率：每 30 分钟一次
+- agent：`developer`
+- model：`anthropic/claude-opus-4-6`
+- 其余参数与第二个任务完全一致
+- message 内容使用文件：
+  `/root/.openclaw/workspace/workspace-developer/HarborForge/plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md`
+- 如果同名任务已存在，则不要重复创建
+
+## 第 4 次唤醒
+执行：
+- 删除你自己这个 cron 定时任务
+- 先通过 `openclaw cron list --json` 找到名称为 `hf-bootstrap-2026-03-21` 的 job id
+- 然后执行 `openclaw cron remove <jobId>`
+
+额外要求：
+- 执行中可以使用 shell / openclaw CLI 完成 cron 管理
+- 如果某一步失败，要在 announce 中说明失败原因
+- 不要跳步；严格按 wakeCount 对应动作执行
diff --git a/plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md b/plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md
new file mode 100644
index 0000000..ac9a973
--- /dev/null
+++ b/plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md
@@ -0,0 +1,25 @@
+你是 developer agent 的一个 cron 定时开发任务。
+
+目标：参考 HarborForge 主仓中的开发计划与 TODO list，寻找当前可以推进的任务并进行开发。
+
+严格要求：
+1. 工作目录以 `/root/.openclaw/workspace/workspace-developer/HarborForge` 为主。
+2. 优先参考：
+   - `plans/harborforge-cli-go-plan.md`
+   - `plans/hf-cross-project-todo.md`
+3. 只做当前明确可推进的任务，不要凭空发散。
+4. 无需做 Test 子模块下的复杂测试。
+5. 尤其禁止运行：`run-test-frontend`。
+6. 可以做轻量验证，例如：编译、lint、py_compile、类型检查、局部单测、静态检查等。
+7. 每次完成后，把所有脏模块分别提交并 push 到分支：`dev-2026-03-21`。
+8. 如果发现 todo list 中所有待办都已完成，则删除你自己这个 cron 定时任务。
+   - 先通过 `openclaw cron list --json` 找到名称为 `hf-dev-kimi-2026-03-21` 的 job id
+   - 然后执行 `openclaw cron remove <jobId>`
+9. 每次运行结束前，给 Discord 频道 `1474327736242798612` 做 announce 汇报。
+
+建议汇报内容：
+- 本次选择的 TODO
+- 修改了哪些子模块
+- 做了哪些轻量验证
+- push 了哪些分支/提交
+- 是否发现阻塞
diff --git a/plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md b/plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md
new file mode 100644
index 0000000..1650bf6
--- /dev/null
+++ b/plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md
@@ -0,0 +1,25 @@
+你是 developer agent 的一个 cron 定时开发任务。
+
+目标：参考 HarborForge 主仓中的开发计划与 TODO list，寻找当前可以推进的任务并进行开发。
+
+严格要求：
+1. 工作目录以 `/root/.openclaw/workspace/workspace-developer/HarborForge` 为主。
+2. 优先参考：
+   - `plans/harborforge-cli-go-plan.md`
+   - `plans/hf-cross-project-todo.md`
+3. 只做当前明确可推进的任务，不要凭空发散。
+4. 无需做 Test 子模块下的复杂测试。
+5. 尤其禁止运行：`run-test-frontend`。
+6. 可以做轻量验证，例如：编译、lint、py_compile、类型检查、局部单测、静态检查等。
+7. 每次完成后，把所有脏模块分别提交并 push 到分支：`dev-2026-03-21`。
+8. 如果发现 todo list 中所有待办都已完成，则删除你自己这个 cron 定时任务。
+   - 先通过 `openclaw cron list --json` 找到名称为 `hf-dev-opus-2026-03-21` 的 job id
+   - 然后执行 `openclaw cron remove <jobId>`
+9. 每次运行结束前，给 Discord 频道 `1474327736242798612` 做 announce 汇报。
+
+建议汇报内容：
+- 本次选择的 TODO
+- 修改了哪些子模块
+- 做了哪些轻量验证
+- push 了哪些分支/提交
+- 是否发现阻塞
diff --git a/plans/harborforge-cli-go-plan.md b/plans/harborforge-cli-go-plan.md
index 6daa338..507fa17 100644
--- a/plans/harborforge-cli-go-plan.md
+++ b/plans/harborforge-cli-go-plan.md
@@ -423,6 +423,54 @@ For leaf commands, this behaves the same as `--help`:
 
 ---
 
+## Permission Introspection Strategy
+
+The permission introspection strategy is now considered **decided**.
+
+### Normal command permission model
+
+For normal authenticated commands, the CLI should determine permissions through the authenticated user context derived from the token:
+
+1. resolve the current user from the token
+2. obtain the user's role
+3. obtain that role's permissions
+4. use those effective permissions to determine:
+   - `--help` output
+   - `--help-brief` output
+   - whether a subcommand is shown normally or marked `(not permitted)`
+
+This applies to normal command groups such as:
+- `user` (except `user create`)
+- `role`
+- `project`
+- `milestone`
+- `task`
+- `meeting`
+- `support`
+- `propose`
+- `monitor`
+
+### Special-flow exception: `hf user create`
+
+`hf user create` does **not** use the normal user-token permission model.
+It remains a special account-manager-token flow.
+
+That means:
+- normal permission introspection from the current user token should not be the gating mechanism for `hf user create`
+- `hf user create` help visibility should be handled independently of ordinary `user.write` capability
+
+### Backend implication
+
+Backend support for this strategy should ensure the CLI can derive:
+- current user identity
+- current user's role
+- current role permissions
+
+Whether this comes from one endpoint or multiple backend calls is an implementation detail.
+The strategy itself is settled: **token → user → role → permissions**.
+
+---
+
 ## Credential / Auth Rules
 
 ## Normal authenticated commands
diff --git a/plans/hf-cross-project-todo.md b/plans/hf-cross-project-todo.md
index 7646f37..27df715 100644
--- a/plans/hf-cross-project-todo.md
+++ b/plans/hf-cross-project-todo.md
@@ -8,344 +8,369 @@
 
 ## 0. Cross-cutting / coordination
 
-- [ ] Finalize MVP scope for first shipping version of `hf`
-- [ ] Confirm which existing backend routes can be reused vs which new routes are needed
-- [ ] Define canonical code-first lookup policy across all resources
-- [ ] Define permission introspection strategy for `--help` / `--help-brief`
-- [ ] Define JSON output contract for CLI list/get commands
-- [ ] Define CLI exit code / stderr conventions
-- [ ] Define local plugin↔monitor communication protocol over `monitor_port`
-- [ ] Define release order across submodules
-- [ ] Define rollback strategy if plugin / monitor bridge is unavailable
+- [x] Finalize MVP scope for first shipping version of `hf`
+  - MVP includes: all CRUD commands for users, roles, projects, milestones, tasks, meetings, support, proposals, monitor
+  - Permission-aware help system, padded-cell/manual mode, code-first resource addressing
+  - Plugin installer `--install-cli` for automated deployment
+- [x] Confirm which existing backend routes can be reused vs which new routes are needed
+- [x] Define canonical code-first lookup policy across all resources
+- [x] Define permission introspection strategy for `--help` / `--help-brief`
+  - settled as: token → current user → user role → role permissions
+  - `hf user create` remains a special account-manager-token flow and is not gated by ordinary user-token write permission
+- [x] Define JSON output contract for CLI list/get commands
+  - current CLI contract: `--json` emits raw success payloads on stdout without a universal envelope; list/get responses should preserve canonical code-bearing fields when backend payloads provide them
+- [x] Define CLI exit code / stderr conventions
+  - current CLI contract: success exits `0`; validation/runtime failures exit `1`; errors go to stderr and successful output goes to stdout
+- [x] Define local plugin↔monitor communication protocol over `monitor_port`
+  - Monitor exposes `GET /health`, `GET /telemetry`, `POST /openclaw` on 127.0.0.1:MONITOR_PORT
+  - Plugin pushes OpenClaw metadata via POST /openclaw; Monitor enriches heartbeats with received data
+  - All communication is optional/degradable — both sides function independently
+- [x] Define release order across submodules
+  - 1. Backend (code-first APIs, permission introspection)
+  - 2. CLI (depends on backend API surface)
+  - 3. Frontend (code-first UI, independent of CLI)
+  - 4. Monitor (standalone, bridge is optional)
+  - 5. Plugin (depends on CLI build for --install-cli, depends on Monitor for bridge)
+- [x] Define rollback strategy if plugin / monitor bridge is unavailable
+  - Graceful degradation: Monitor operates normally without plugin data
+  - Plugin operates normally without Monitor bridge
+  - No hard dependency in either direction — bridge is optional enrichment
+
+> Note: the CLI contract items above are now documented from the currently implemented `HarborForge.Cli` behavior; they can still be refined later if a stricter release contract is needed.
 
 ---
 
 ## 1. HarborForge.Cli
 
 ### 1.1 Go project scaffold
-- [ ] Initialize Go module for `hf`
-- [ ] Add binary entrypoint (`cmd/hf/main.go` or equivalent)
-- [ ] Add internal package layout (`config`, `help`, `mode`, `passmgr`, `client`, `commands`)
-- [ ] Add build instructions to `README.md`
-- [ ] Add `.gitignore` for Go artifacts
-- [ ] Add repo-config-safe contribution note if needed
+- [x] Initialize Go module for `hf`
+- [x] Add binary entrypoint (`cmd/hf/main.go` or equivalent)
+- [x] Add internal package layout (`config`, `help`, `mode`, `passmgr`, `client`, `commands`)
+- [x] Add build instructions to `README.md`
+- [x] Add `.gitignore` for Go artifacts
+- [x] Add repo-config-safe contribution note if needed
+  - CLI README already contains build/run/install docs; no separate contribution note needed for current scope
 
 ### 1.2 Runtime mode detection
-- [ ] Implement `which pass_mgr` detection on startup
-- [ ] Add runtime mode enum: padded-cell mode / manual mode
-- [ ] Block manual credential flags in padded-cell mode
-- [ ] Return exact error when forbidden manual token flags are used:
-  - [ ] `padded-cell installed, --token flag disabled, use command directly`
-- [ ] Define equivalent handling for `--acc-mgr-token` and related manual secret flags
+- [x] Implement `which pass_mgr` detection on startup
+- [x] Add runtime mode enum: padded-cell mode / manual mode
+- [x] Block manual credential flags in padded-cell mode
+- [x] Return exact error when forbidden manual token flags are used:
+  - [x] `padded-cell installed, --token flag disabled, use command directly`
+- [x] Define equivalent handling for `--acc-mgr-token` and related manual secret flags
 
 ### 1.3 Config handling
-- [ ] Resolve binary directory correctly at runtime
-- [ ] Read `<binary-dir>/.hf-config.json`
-- [ ] Write/update `base-url` via `hf config --url`
-- [ ] Add config validation for malformed/missing config
-- [ ] Add `hf config --acc-mgr-token`
-- [ ] Implement `pass_mgr set --public --key hf-acc-mgr-token --secret <token>`
-- [ ] Return exact error on failure:
-  - [ ] `--acc-mgr-token can only be set with padded-cell plugin`
+- [x] Resolve binary directory correctly at runtime
+- [x] Read `<binary-dir>/.hf-config.json`
+- [x] Write/update `base-url` via `hf config --url`
+- [x] Add config validation for malformed/missing config
+- [x] Add `hf config --acc-mgr-token`
+- [x] Implement `pass_mgr set --public --key hf-acc-mgr-token --secret <token>`
+- [x] Return exact error on failure:
+  - [x] `--acc-mgr-token can only be set with padded-cell plugin`
 
 ### 1.4 Help system
-- [ ] Implement `hf --help`
-- [ ] Implement `hf --help-brief`
-- [ ] Implement `<group> --help`
-- [ ] Implement `<group> --help-brief`
-- [ ] Implement leaf command `--help`
-- [ ] Implement leaf command `--help-brief`
-- [ ] Show all subcommands in normal help, marking unavailable ones as `(not permitted)`
-- [ ] Hide unavailable commands entirely in `--help-brief`
-- [ ] Ensure leaf `--help` for unavailable commands only prints `not permitted`
-- [ ] Hide manual auth flags from help in padded-cell mode
-- [ ] Show required manual auth flags in help in manual mode
-- [ ] Handle special help behavior for `hf user create`
+- [x] Implement `hf --help`
+- [x] Implement `hf --help-brief`
+- [x] Implement `<group> --help`
+- [x] Implement `<group> --help-brief`
+- [x] Implement leaf command `--help`
+- [x] Implement leaf command `--help-brief`
+- [x] Show all subcommands in normal help, marking unavailable ones as `(not permitted)`
+- [x] Hide unavailable commands entirely in `--help-brief`
+- [x] Ensure leaf `--help` for unavailable commands only prints `not permitted`
+- [x] Hide manual auth flags from help in padded-cell mode
+- [x] Show required manual auth flags in help in manual mode
+- [x] Handle special help behavior for `hf user create`
 
 ### 1.5 Auth/token resolution layer
-- [ ] Implement shared normal token resolution helper
-- [ ] In padded-cell mode, resolve via `pass_mgr get-secret --key hf-token`
-- [ ] In manual mode, require explicit `--token`
-- [ ] Emit exact error on missing manual token:
-  - [ ] `--token <token> required or execute this with pcexec`
-- [ ] Ensure `hf --help` never requires token
-- [ ] Ensure subcommand help can render even when token is unavailable
+- [x] Implement shared normal token resolution helper
+- [x] In padded-cell mode, resolve via `pass_mgr get-secret --key hf-token`
+- [x] In manual mode, require explicit `--token`
+- [x] Emit exact error on missing manual token:
+  - [x] `--token <token> required or execute this with pcexec`
+- [x] Ensure `hf --help` never requires token
+- [x] Ensure subcommand help can render even when token is unavailable
 
 ### 1.6 Output model
-- [ ] Add default human-readable output mode
-- [ ] Add `--json` output mode
-- [ ] Ensure list outputs include canonical resource code fields
-- [ ] Ensure machine-readable output is stable enough for agent use
+- [x] Add default human-readable output mode
+- [x] Add `--json` output mode
+- [x] Ensure list outputs include canonical resource code fields
+- [x] Ensure machine-readable output is stable enough for agent use
 
 ### 1.7 Base commands
-- [ ] Implement `hf version`
-- [ ] Implement `hf health`
+- [x] Implement `hf version`
+- [x] Implement `hf health`
 
 ### 1.8 User commands
-- [ ] Implement `hf user create`
-- [ ] Forbid `--token` on `hf user create`
-- [ ] Do not support `--role` on `hf user create`
-- [ ] Default created accounts to `guest`
-- [ ] In padded-cell mode, auto-generate password with:
-  - [ ] `pass_mgr generate --key hf --username <username>`
-- [ ] In padded-cell mode, auto-fetch account-manager token with:
-  - [ ] `pass_mgr get-secret --public --key hf-acc-mgr-token`
-- [ ] Emit exact missing-password error:
-  - [ ] `--pass <password> required or execute with pcexec`
-- [ ] Emit exact missing-account-manager-token error:
-  - [ ] `--acc-mgr-token <token> required or execute with pcexec`
-- [ ] Implement `hf user list`
-- [ ] Implement `hf user get <username>`
-- [ ] Implement `hf user update <username>`
-- [ ] Implement `hf user activate <username>`
-- [ ] Implement `hf user deactivate <username>`
-- [ ] Implement `hf user delete <username>`
+- [x] Implement `hf user create`
+- [x] Forbid `--token` on `hf user create`
+- [x] Do not support `--role` on `hf user create`
+- [x] Default created accounts to `guest`
+- [x] In padded-cell mode, auto-generate password with:
+  - [x] `pass_mgr generate --key hf --username <username>`
+- [x] In padded-cell mode, auto-fetch account-manager token with:
+  - [x] `pass_mgr get-secret --public --key hf-acc-mgr-token`
+- [x] Emit exact missing-password error:
+  - [x] `--pass <password> required or execute with pcexec`
+- [x] Emit exact missing-account-manager-token error:
+  - [x] `--acc-mgr-token <token> required or execute with pcexec`
+- [x] Implement `hf user list`
+- [x] Implement `hf user get <username>`
+- [x] Implement `hf user update <username>`
+- [x] Implement `hf user activate <username>`
+- [x] Implement `hf user deactivate <username>`
+- [x] Implement `hf user delete <username>`
 
 ### 1.9 Role / permission commands
-- [ ] Implement `hf role list`
-- [ ] Implement `hf role get <role-name>`
-- [ ] Implement `hf role create`
-- [ ] Implement `hf role update`
-- [ ] Implement `hf role delete`
-- [ ] Implement `hf permission list`
-- [ ] Implement `hf role set-permissions`
-- [ ] Implement `hf role add-permissions`
-- [ ] Implement `hf role remove-permissions`
+- [x] Implement `hf role list`
+- [x] Implement `hf role get <role-name>`
+- [x] Implement `hf role create`
+- [x] Implement `hf role update`
+- [x] Implement `hf role delete`
+- [x] Implement `hf permission list`
+- [x] Implement `hf role set-permissions`
+- [x] Implement `hf role add-permissions`
+- [x] Implement `hf role remove-permissions`
 
 ### 1.10 Project / milestone commands
-- [ ] Implement `hf project list`
-- [ ] Implement `hf project get <project-code>`
-- [ ] Implement `hf project create`
-- [ ] Implement `hf project update <project-code>`
-- [ ] Implement `hf project delete <project-code>`
-- [ ] Implement `hf project members <project-code>`
-- [ ] Implement `hf project add-member <project-code>`
-- [ ] Implement `hf project remove-member <project-code>`
-- [ ] Implement `hf milestone list --project <project-code>`
-- [ ] Implement `hf milestone get <milestone-code>`
-- [ ] Implement `hf milestone create`
-- [ ] Implement `hf milestone update <milestone-code>`
-- [ ] Implement `hf milestone delete <milestone-code>`
-- [ ] Implement `hf milestone progress <milestone-code>`
+- [x] Implement `hf project list`
+- [x] Implement `hf project get <project-code>`
+- [x] Implement `hf project create`
+- [x] Implement `hf project update <project-code>`
+- [x] Implement `hf project delete <project-code>`
+- [x] Implement `hf project members <project-code>`
+- [x] Implement `hf project add-member <project-code>`
+- [x] Implement `hf project remove-member <project-code>`
+- [x] Implement `hf milestone list --project <project-code>`
+- [x] Implement `hf milestone get <milestone-code>`
+- [x] Implement `hf milestone create`
+- [x] Implement `hf milestone update <milestone-code>`
+- [x] Implement `hf milestone delete <milestone-code>`
+- [x] Implement `hf milestone progress <milestone-code>`
 
 ### 1.11 Task commands
-- [ ] Implement `hf task list`
-- [ ] Add filters:
-  - [ ] `--project <project-code>`
-  - [ ] `--milestone <milestone-code>`
-  - [ ] `--status <status>`
-  - [ ] `--taken-by <me|null|username>`
-  - [ ] `--due-today <true|false>`
-  - [ ] repeated `--order-by <due-date|priority|created|name>`
-- [ ] Implement `hf task get <task-code>`
-- [ ] Implement `hf task create`
-- [ ] Implement `hf task update <task-code>`
-- [ ] Implement `hf task transition <task-code> <status>`
-- [ ] Implement `hf task take <task-code>`
-- [ ] Return clear error when task is already taken by someone else
-- [ ] Return clear error when caller lacks permission to take task
-- [ ] Implement `hf task delete <task-code>`
-- [ ] Implement `hf task search`
+- [x] Implement `hf task list`
+- [x] Add filters:
+  - [x] `--project <project-code>`
+  - [x] `--milestone <milestone-code>`
+  - [x] `--status <status>`
+  - [x] `--taken-by <me|null|username>`
+  - [x] `--due-today <true|false>`
+  - [x] repeated `--order-by <due-date|priority|created|name>`
+- [x] Implement `hf task get <task-code>`
+- [x] Implement `hf task create`
+- [x] Implement `hf task update <task-code>`
+- [x] Implement `hf task transition <task-code> <status>`
+- [x] Implement `hf task take <task-code>`
+- [x] Return clear error when task is already taken by someone else
+- [x] Return clear error when caller lacks permission to take task
+- [x] Implement `hf task delete <task-code>`
+- [x] Implement `hf task search`
 
 ### 1.12 Meeting commands
-- [ ] Implement `hf meeting list`
-- [ ] Implement `hf meeting get <meeting-code>`
-- [ ] Implement `hf meeting create`
-- [ ] Implement `hf meeting update <meeting-code>`
-- [ ] Implement `hf meeting attend <meeting-code>`
-- [ ] Ensure attend adds caller to participant list
-- [ ] Implement `hf meeting delete <meeting-code>`
+- [x] Implement `hf meeting list`
+- [x] Implement `hf meeting get <meeting-code>`
+- [x] Implement `hf meeting create`
+- [x] Implement `hf meeting update <meeting-code>`
+- [x] Implement `hf meeting attend <meeting-code>`
+- [x] Ensure attend adds caller to participant list
+- [x] Implement `hf meeting delete <meeting-code>`
 
 ### 1.13 Support commands
-- [ ] Implement `hf support list`
-- [ ] Implement `hf support get <support-code>`
-- [ ] Implement `hf support create`
-- [ ] Implement `hf support update <support-code>`
-- [ ] Implement `hf support take <support-code>`
-- [ ] Implement `hf support transition <support-code> <status>`
-- [ ] Implement `hf support delete <support-code>`
+- [x] Implement `hf support list`
+- [x] Implement `hf support get <support-code>`
+- [x] Implement `hf support create`
+- [x] Implement `hf support update <support-code>`
+- [x] Implement `hf support take <support-code>`
+- [x] Implement `hf support transition <support-code> <status>`
+- [x] Implement `hf support delete <support-code>`
 
 ### 1.14 Propose commands
-- [ ] Implement `hf propose list --project <project-code>`
-- [ ] Implement `hf propose get <propose-code>`
-- [ ] Implement `hf propose create`
-- [ ] Implement `hf propose update <propose-code>`
-- [ ] Implement `hf propose accept <propose-code> --milestone <milestone-code>`
-- [ ] Implement `hf propose reject <propose-code>`
-- [ ] Implement `hf propose reopen <propose-code>`
+- [x] Implement `hf propose list --project <project-code>`
+- [x] Implement `hf propose get <propose-code>`
+- [x] Implement `hf propose create`
+- [x] Implement `hf propose update <propose-code>`
+- [x] Implement `hf propose accept <propose-code> --milestone <milestone-code>`
+- [x] Implement `hf propose reject <propose-code>`
+- [x] Implement `hf propose reopen <propose-code>`
 
 ### 1.15 Monitor commands
-- [ ] Implement `hf monitor overview`
-- [ ] Implement `hf monitor server list`
-- [ ] Implement `hf monitor server get <identifier>`
-- [ ] Implement `hf monitor server create --identifier <identifier>`
-- [ ] Implement `hf monitor server delete <identifier>`
-- [ ] Implement `hf monitor api-key generate <identifier>`
-- [ ] Implement `hf monitor api-key revoke <identifier>`
+- [x] Implement `hf monitor overview`
+- [x] Implement `hf monitor server list`
+- [x] Implement `hf monitor server get <identifier>`
+- [x] Implement `hf monitor server create --identifier <identifier>`
+- [x] Implement `hf monitor server delete <identifier>`
+- [x] Implement `hf monitor api-key generate <identifier>`
+- [x] Implement `hf monitor api-key revoke <identifier>`
 
 ### 1.16 CLI packaging / release
-- [ ] Add cross-platform build targets if needed
-- [ ] Add release artifact naming for `hf`
-- [ ] Add install documentation
-- [ ] Add shell examples for padded-cell and manual mode
+- [x] Add cross-platform build targets if needed
+- [x] Add release artifact naming for `hf`
+- [x] Add install documentation
+- [x] Add shell examples for padded-cell and manual mode
 
 ---
 
 ## 2. HarborForge.Backend
 
 ### 2.1 Code-first API support
-- [ ] Audit all CLI-targeted resources for code availability
-- [ ] Ensure `project-code` is accepted in get/update/delete/member APIs
-- [ ] Ensure `milestone-code` is accepted in get/update/delete/progress APIs
-- [ ] Ensure `task-code` is accepted in get/update/delete/transition APIs
-- [ ] Ensure `meeting-code` is accepted in get/update/delete/attend APIs
-- [ ] Ensure `support-code` is accepted in get/update/delete/take/transition APIs
-- [ ] Ensure `propose-code` is accepted in get/update/delete/accept/reject/reopen APIs
-- [ ] Add code-based list filters where missing
-- [ ] Ensure CLI-related list payloads always include canonical code fields
+- [x] Audit all CLI-targeted resources for code availability
+- [x] Ensure `project-code` is accepted in get/update/delete/member APIs
+- [x] Ensure `milestone-code` is accepted in get/update/delete/progress APIs
+- [x] Ensure `task-code` is accepted in get/update/delete/transition APIs
+- [x] Ensure `meeting-code` is accepted in get/update/delete/attend APIs
+- [x] Ensure `support-code` is accepted in get/update/delete/take/transition APIs
+- [x] Ensure `propose-code` is accepted in get/update/delete/accept/reject/reopen APIs
+- [x] Add code-based list filters where missing
+- [x] Ensure CLI-related list payloads always include canonical code fields
 
 ### 2.2 User / account-manager flow
-- [ ] Review current `account-manager` permission implementation
-- [ ] Add dedicated backend flow for account-manager-based account creation if current `/users` route is insufficient
-- [ ] Ensure `hf user create` maps cleanly to backend account-manager permission model
-- [ ] Ensure new accounts default to `guest`
-- [ ] Ensure admin role cannot be assigned through normal user management APIs
+- [x] Review current `account-manager` permission implementation
+- [x] Add dedicated backend flow for account-manager-based account creation if current `/users` route is insufficient
+- [x] Ensure `hf user create` maps cleanly to backend account-manager permission model
+- [x] Ensure new accounts default to `guest`
+- [x] Ensure admin role cannot be assigned through normal user management APIs
 
 ### 2.3 Permission introspection for CLI help
-- [ ] Decide how CLI will query effective permissions
-- [ ] Add/extend backend endpoint(s) for current-user permission introspection if needed
-- [ ] Ensure CLI can cheaply determine whether a subcommand is permitted
-- [ ] Support permission-aware help rendering without excessive API chattiness
+- [x] Decide how CLI will query effective permissions
+- [x] Add/extend backend endpoint(s) for current-user permission introspection if needed
+- [x] Ensure CLI can cheaply determine whether a subcommand is permitted
+- [x] Support permission-aware help rendering without excessive API chattiness
 
 ### 2.4 Task / meeting / support actions
-- [ ] Add/confirm backend route for task self-assignment (`task take`)
-- [ ] Add/confirm conflict behavior when task already has a different assignee
-- [ ] Add/confirm backend route for meeting attendance (`meeting attend`)
-- [ ] Ensure meeting attendance updates participant list
-- [ ] Add/confirm backend route for support self-assignment (`support take`)
+- [x] Add/confirm backend route for task self-assignment (`task take`)
+- [x] Add/confirm conflict behavior when task already has a different assignee
+- [x] Add/confirm backend route for meeting attendance (`meeting attend`)
+- [x] Ensure meeting attendance updates participant list
+- [x] Add/confirm backend route for support self-assignment (`support take`)
 
 ### 2.5 Frontend-facing code migration support
-- [ ] Add code-based detail endpoints or code query support for frontend routing
-- [ ] Ensure frontend can resolve resources by code without fallback to id-only APIs
-- [ ] Update serializers to expose code prominently wherever applicable
+- [x] Add code-based detail endpoints or code query support for frontend routing
+- [x] Ensure frontend can resolve resources by code without fallback to id-only APIs
+- [x] Update serializers to expose code prominently wherever applicable
 
 ### 2.6 Legacy Python CLI retirement
-- [ ] Track parity between new `hf` CLI and old backend Python CLI
-- [ ] Once parity is acceptable, remove legacy Python CLI from backend repo
-- [ ] Remove backend docs referencing the old Python CLI
+- [x] Track parity between new `hf` CLI and old backend Python CLI
+- [x] Once parity is acceptable, remove legacy Python CLI from backend repo
+- [x] Remove backend docs referencing the old Python CLI
 
 ---
 
 ## 3. HarborForge.Frontend
 
 ### 3.1 Code-first UI migration
-- [ ] Audit current routes and identify every place still using raw ids
-- [ ] Move project detail lookup toward `project-code`
-- [ ] Move milestone detail lookup toward `milestone-code`
-- [ ] Move task detail lookup toward `task-code`
-- [ ] Move meeting detail lookup toward `meeting-code`
-- [ ] Move support detail lookup toward `support-code`
-- [ ] Move propose detail lookup toward `propose-code`
-- [ ] Stop surfacing raw ids as the main visible identifier in lists/details
-- [ ] Display codes consistently in relevant list and detail views
+- [x] Audit current routes and identify every place still using raw ids
+- [x] Move project detail lookup toward `project-code`
+- [x] Move milestone detail lookup toward `milestone-code`
+- [x] Move task detail lookup toward `task-code`
+- [x] Move meeting detail lookup toward `meeting-code`
+- [x] Move support detail lookup toward `support-code`
+- [x] Move propose detail lookup toward `propose-code`
+- [x] Stop surfacing raw ids as the main visible identifier in lists/details
+- [x] Display codes consistently in relevant list and detail views
 
 ### 3.2 User / role UX alignment
-- [ ] Review current user management page against final backend behavior
-- [ ] Ensure only code/name-first identifiers are shown where relevant
-- [ ] Ensure account role display matches single-role model everywhere
+- [x] Review current user management page against final backend behavior
+- [x] Ensure only code/name-first identifiers are shown where relevant
+- [x] Ensure account role display matches single-role model everywhere
 
 ### 3.3 Meeting / support UI
-- [ ] Audit current frontend support for meeting resources
-- [ ] Add/adjust UI for meeting participant state if needed
-- [ ] Add/adjust UI for support take/ownership state if needed
+- [x] Audit current frontend support for meeting resources
+- [x] Add/adjust UI for meeting participant state if needed
+- [x] Add/adjust UI for support take/ownership state if needed
 
 ### 3.4 Monitor UI alignment
-- [ ] Ensure monitor views expose server identifier/code cleanly
-- [ ] Review display of OpenClaw/plugin metadata once Monitor bridge is implemented
+- [x] Ensure monitor views expose server identifier/code cleanly
+- [ ] Review display of OpenClaw/plugin metadata once Monitor bridge is deployed
 
 ### 3.5 Future CLI alignment aids
-- [ ] Consider showing canonical codes more prominently to help users map UI↔CLI
-- [ ] Ensure copyable resource codes are easy to find from the UI
+- [x] Consider showing canonical codes more prominently to help users map UI↔CLI
+- [x] Ensure copyable resource codes are easy to find from the UI
 
 ---
 
 ## 4. HarborForge.OpenclawPlugin
 
 ### 4.1 Plugin identity and packaging
-- [ ] Rename plugin registration name to `harbor-forge`
-- [ ] Audit all docs/config/install references to old plugin name
-- [ ] Ensure plugin config keys and examples reflect the new registration name
+- [x] Rename plugin registration name to `harbor-forge`
+- [x] Audit all docs/config/install references to old plugin name
+- [x] Ensure plugin config keys and examples reflect the new registration name
 
 ### 4.2 Remove sidecar architecture
-- [ ] Remove plugin-side `server/` telemetry sidecar
-- [ ] Remove sidecar startup/shutdown lifecycle logic
-- [ ] Remove sidecar-specific docs and examples
-- [ ] Replace old OpenClaw telemetry flow with direct plugin-exposed data path
+- [x] Remove plugin-side `server/` telemetry sidecar
+- [x] Remove sidecar startup/shutdown lifecycle logic
+- [x] Remove sidecar-specific docs and examples
+- [x] Replace old OpenClaw telemetry flow with direct plugin-exposed data path
 
 ### 4.3 Plugin config updates
-- [ ] Add `monitor_port` to plugin config schema
-- [ ] Document `monitor_port` in plugin README/docs/examples
-- [ ] Ensure runtime reads and validates `monitor_port`
+- [x] Add `monitor_port` to plugin config schema
+- [x] Document `monitor_port` in plugin README/docs/examples
+- [x] Ensure runtime reads and validates `monitor_port`
 
 ### 4.4 CLI install support
-- [ ] Add install script flag `--install-cli`
-- [ ] Resolve OpenClaw profile bin directory (default `~/.openclaw/bin`)
-- [ ] Build `HarborForge.Cli`
-- [ ] Install compiled `hf` binary to profile `bin/`
-- [ ] `chmod +x` installed binary
-- [ ] Handle failure cases cleanly if CLI build/install fails
+- [x] Add install script flag `--install-cli`
+- [x] Resolve OpenClaw profile bin directory (default `~/.openclaw/bin`)
+- [x] Build `HarborForge.Cli`
+- [x] Install compiled `hf` binary to profile `bin/`
+- [x] `chmod +x` installed binary
+- [x] Handle failure cases cleanly if CLI build/install fails
 
 ### 4.5 Skills deployment
-- [ ] Add plugin `skills/` directory
-- [ ] Add `skills/hf/`
-- [ ] Add `skills/hf/SKILL.md`
-- [ ] In `SKILL.md`, explain basic `hf` usage
-- [ ] In `SKILL.md`, encourage agents to use `hf --help-brief`
-- [ ] In `SKILL.md`, point to normal `--help` for full command tree
-- [ ] Installer should copy normal plugin skills into profile `skills/`
-- [ ] Installer should **not** copy `skills/hf/` unless `--install-cli` is present
-- [ ] Installer should copy `skills/hf/` when `--install-cli` is present
+- [x] Add plugin `skills/` directory
+- [x] Add `skills/hf/`
+- [x] Add `skills/hf/SKILL.md`
+- [x] In `SKILL.md`, explain basic `hf` usage
+- [x] In `SKILL.md`, encourage agents to use `hf --help-brief`
+- [x] In `SKILL.md`, point to normal `--help` for full command tree
+- [x] Installer should copy normal plugin skills into profile `skills/`
+- [x] Installer should **not** copy `skills/hf/` unless `--install-cli` is present
+- [x] Installer should copy `skills/hf/` when `--install-cli` is present
 
 ### 4.6 Monitor bridge endpoint
-- [ ] Define how plugin exposes OpenClaw metadata to Monitor over local port
-- [ ] Decide HTTP endpoint structure / payload schema
-- [ ] Expose OpenClaw version
-- [ ] Expose plugin version
-- [ ] Expose agent list / agent metadata
-- [ ] Ensure plugin remains functional even if Monitor never connects
+- [x] Define how plugin exposes OpenClaw metadata to Monitor over local port
+  - Plugin periodically POSTs metadata to Monitor bridge `POST /openclaw`
+- [x] Decide HTTP endpoint structure / payload schema
+  - `POST /openclaw` with `{ version, plugin_version, agents }`
+- [x] Expose OpenClaw version
+- [x] Expose plugin version
+- [x] Expose agent list / agent metadata
+- [x] Ensure plugin remains functional even if Monitor never connects
 
 ---
 
 ## 5. HarborForge.Monitor
 
 ### 5.1 Docker/runtime changes
-- [ ] Add `MONITOR_PORT` env var
-- [ ] Ensure Monitor listens on `127.0.0.1:<MONITOR_PORT>`
-- [ ] Update Docker runtime docs/examples
-- [ ] Update docker-compose to expose that port to host `127.0.0.1`
+- [x] Add `MONITOR_PORT` env var
+- [x] Ensure Monitor listens on `127.0.0.1:<MONITOR_PORT>`
+- [x] Update Docker runtime docs/examples
+- [x] Update docker-compose to expose that port to host `127.0.0.1`
 
 ### 5.2 Plugin communication
-- [ ] Implement local communication client to query plugin over `MONITOR_PORT`
-- [ ] Define request timeout / retry / fallback policy
-- [ ] Keep startup independent of plugin communication success
-- [ ] Keep heartbeat/telemetry upload independent of plugin communication success
-- [ ] If plugin is reachable, enrich telemetry with:
-  - [ ] OpenClaw version
-  - [ ] plugin version
-  - [ ] agent info
-- [ ] If plugin is unreachable, continue current behavior unchanged
+- [x] Implement local communication client to query plugin over `MONITOR_PORT`
+  - Note: the architecture is reversed — Monitor hosts the bridge, plugin pushes via POST /openclaw
+- [x] Define request timeout / retry / fallback policy
+  - Plugin uses 3s timeout; Monitor bridge uses 5s read/write timeouts
+- [x] Keep startup independent of plugin communication success
+- [x] Keep heartbeat/telemetry upload independent of plugin communication success
+- [x] If plugin is reachable, enrich telemetry with:
+  - [x] OpenClaw version
+  - [x] plugin version
+  - [x] agent info
+- [x] If plugin is unreachable, continue current behavior unchanged
 
 ### 5.3 Telemetry model alignment
-- [ ] Ensure backend-facing telemetry payloads can carry optional OpenClaw metadata
-- [ ] Avoid making plugin-derived fields mandatory
-- [ ] Ensure monitor data model cleanly distinguishes:
-  - [ ] host/hardware telemetry
-  - [ ] optional OpenClaw metadata
+- [x] Ensure backend-facing telemetry payloads can carry optional OpenClaw metadata
+- [x] Avoid making plugin-derived fields mandatory
+- [x] Ensure monitor data model cleanly distinguishes:
+  - [x] host/hardware telemetry
+  - [x] optional OpenClaw metadata
 
 ### 5.4 Docs / examples
-- [ ] Update Monitor README to explain `MONITOR_PORT`
-- [ ] Explain degraded mode when plugin bridge is absent
-- [ ] Provide example Docker run / compose snippet with host loopback exposure
+- [x] Update Monitor README to explain `MONITOR_PORT`
+- [x] Explain degraded mode when plugin bridge is absent
+- [x] Provide example Docker run / compose snippet with host loopback exposure
 
 ---
 
@@ -372,34 +397,34 @@
 ## 7. Suggested implementation order
 
 ### Phase A — Foundations
-- [ ] Finalize CLI help / mode / output model
-- [ ] Finalize backend permission introspection approach
-- [ ] Finalize plugin↔monitor local protocol
+- [x] Finalize CLI help / mode / output model
+- [x] Finalize backend permission introspection approach
+- [x] Finalize plugin↔monitor local protocol
 
 ### Phase B — Backend first
-- [ ] Add/finish code-based backend support
-- [ ] Add/finish task take / meeting attend / support take
-- [ ] Add any missing account-manager creation behavior
+- [x] Add/finish code-based backend support
+- [x] Add/finish task take / meeting attend / support take
+- [x] Add any missing account-manager creation behavior
 
 ### Phase C — CLI MVP
-- [ ] Build `hf` scaffold
-- [ ] Ship `version`, `health`, `config`
-- [ ] Ship `user create`, `user list`, `user get`
-- [ ] Ship `task list`, `task get`, `task take`
-- [ ] Ship initial `monitor` commands
+- [x] Build `hf` scaffold
+- [x] Ship `version`, `health`, `config`
+- [x] Ship `user create`, `user list`, `user get`
+- [x] Ship `task list`, `task get`, `task take`
+- [x] Ship initial `monitor` commands
 
 ### Phase D — Frontend alignment
-- [ ] Move frontend to code-first lookup/display
-- [ ] Surface canonical codes consistently in UI
+- [x] Move frontend to code-first lookup/display
+- [x] Surface canonical codes consistently in UI
 
 ### Phase E — Plugin / Monitor integration
-- [ ] Rename plugin to `harbor-forge`
-- [ ] Remove plugin sidecar
-- [ ] Add `--install-cli`
-- [ ] Add `skills/hf`
-- [ ] Add `monitor_port` / `MONITOR_PORT` bridge
+- [x] Rename plugin to `harbor-forge`
+- [x] Remove plugin sidecar
+- [x] Add `--install-cli`
+- [x] Add `skills/hf`
+- [x] Add `monitor_port` / `MONITOR_PORT` bridge
 
 ### Phase F — Cleanup / retirement
-- [ ] Remove legacy backend Python CLI
-- [ ] Update all docs to point to `hf`
+- [x] Remove legacy backend Python CLI
+- [x] Update all docs to point to `hf`
 - [ ] Add final tests and packaging flow