Merge pull request 'Merge dev-2026-03-22 into main' (#5) from dev-2026-03-22 into main
Reviewed-on: #5
This commit was merged in pull request #5.
This commit is contained in:
@@ -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": {
|
||||
"entries": {
|
||||
"harbor-forge": {
|
||||
"enabled": true,
|
||||
"challengeUuid": "YOUR_CHALLENGE_UUID"
|
||||
"config": {
|
||||
"enabled": true,
|
||||
"apiKey": "YOUR_API_KEY",
|
||||
"monitor_port": 9100
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Submodule HarborForge.Backend updated: 271d5140e6...88931d822d
Submodule HarborForge.Cli updated: ddaea1c15b...b3063733a9
Submodule HarborForge.Frontend updated: fd28bb6b6f...ce07ee9021
Submodule HarborForge.Monitor updated: 739b8fcd74...dc05fa01d1
Submodule HarborForge.OpenclawPlugin updated: afdbc469ad...e7ba982128
5
plans/automation/cron/hf-bootstrap-2026-03-21-state.json
Normal file
5
plans/automation/cron/hf-bootstrap-2026-03-21-state.json
Normal file
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"wakeCount": 4,
|
||||
"createdAt": "2026-03-21T12:25:00Z",
|
||||
"updatedAt": "2026-03-21T13:29:00Z"
|
||||
}
|
||||
54
plans/automation/cron/hf-bootstrap-2026-03-21.prompt.md
Normal file
54
plans/automation/cron/hf-bootstrap-2026-03-21.prompt.md
Normal file
@@ -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 对应动作执行
|
||||
25
plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md
Normal file
25
plans/automation/cron/hf-dev-kimi-2026-03-21.prompt.md
Normal file
@@ -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 了哪些分支/提交
|
||||
- 是否发现阻塞
|
||||
25
plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md
Normal file
25
plans/automation/cron/hf-dev-opus-2026-03-21.prompt.md
Normal file
@@ -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 了哪些分支/提交
|
||||
- 是否发现阻塞
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user