harness-gateway 0.7.0__tar.gz

harness_gateway-0.7.0/.codebuddy/commands/ship.md

@@ -0,0 +1,47 @@
+Analyze the current git changes, run code quality checks, create a well-structured commit, and push to the remote. Follow these steps precisely:
+
+## Step 1: Analyze Changes
+
+Run `git status` and `git diff --stat` to understand the scope of changes. If there are unstaged changes, stage them with `git add -A`.
+
+If there are no changes to commit, inform me and stop.
+
+## Step 2: Code Quality Checks (Python only)
+
+If any staged changes include `.py` files, run the following checks **before committing**:
+
+```bash
+ruff check . --fix
+ruff format .
+```
+
+- If `ruff check --fix` auto-fixes issues, re-stage the affected files with `git add -A`.
+- If `ruff check` still reports errors after `--fix` (i.e., errors that require manual intervention), **stop and report the errors**. Do not proceed with the commit until all errors are resolved.
+- If there are no `.py` files in the staged changes, skip this step.
+
+## Step 3: Generate Commit Message
+
+Run `git diff --cached` to inspect the staged changes in detail.
+
+Write a **Conventional Commits** message following this format:
+
+```
+<type>(<scope>): <concise summary>
+
+<optional body — bullet points explaining key changes>
+```
+
+Rules for the commit message:
+- **type**: one of `feat`, `fix`, `refactor`, `chore`, `docs`, `style`, `perf`, `test`, `build`, `ci`
+- **scope**: the primary module or area affected (e.g., `agent`, `dashboard`, `memory`, `config`)
+- **summary**: imperative mood, lowercase, no period, ≤ 72 characters
+- **body**: include only when there are multiple logical changes; use bullet points
+- The commit message (including body) must be in **English**
+
+## Step 4: Commit and Push
+
+1. Create the commit with the generated message.
+2. Push to the remote tracking branch (usually `origin/<current-branch>`).
+3. Show me the final `git log --oneline -1` and confirm success.
+
+$ARGUMENTS

harness_gateway-0.7.0/.codebuddy/rules/python-code-quality.mdc

@@ -0,0 +1,113 @@
+---
+description: 
+alwaysApply: true
+enabled: true
+updatedAt: 2026-03-17T06:54:46.604Z
+provider: 
+---
+
+# Python Code Quality Standards — LightClaw
+
+## 1. Pre-commit: ruff check & ruff format
+
+Every Python change **must** pass the following before commit:
+
+```bash
+ruff check . --fix   # lint + auto-fix
+ruff format .        # deterministic formatting
+```
+
+- If `ruff check` reports errors that `--fix` cannot resolve, fix them **manually** before proceeding.
+- Never suppress a warning with `# noqa` unless there is a clear, documented reason (e.g., an import purely for availability detection).
+- When generating or editing Python code, ensure the result is **ruff-clean** — run `ruff check` mentally against your output.
+
+## 2. Modern Type Annotations (PEP 585 / PEP 604)
+
+### Banned legacy aliases
+
+| ❌ Legacy (do NOT use) | ✅ Modern replacement |
+|------------------------|----------------------|
+| `Optional[X]` | `X \| None` |
+| `Union[X, Y]` | `X \| Y` |
+| `Dict[K, V]` | `dict[K, V]` |
+| `List[T]` | `list[T]` |
+| `Tuple[T, ...]` | `tuple[T, ...]` |
+| `Set[T]` | `set[T]` |
+| `FrozenSet[T]` | `frozenset[T]` |
+| `Type[T]` | `type[T]` |
+| `Any` | Avoid — prefer `object`, `Protocol`, `TypedDict`, or a concrete union |
+
+### Rules
+
+- **Always** use lowercase built-in generics: `list[str]`, `dict[str, int]`, `tuple[int, ...]`.
+- **Always** use `X | None` instead of `Optional[X]`.
+- Add `from __future__ import annotations` when forward references are needed, but prefer it in all new files for consistency.
+- `typing.TYPE_CHECKING` is fine for import-cycle breaking; keep runtime imports lean.
+- If `Any` is truly unavoidable, add a brief comment explaining why.
+
+## 3. Comments & Docstrings — English Only
+
+### Comments
+
+- **All comments must be in English.** No Chinese in `#` comments or inline remarks.
+- Keep comments concise: explain *why*, not *what* (the code shows *what*).
+- Use `# TODO(author): description` / `# FIXME(author): description` for action items.
+- Avoid redundant comments that merely restate the code:
+  ```python
+  # Bad — restates the code
+  # Increment counter by one
+  counter += 1
+
+  # Good — explains intent
+  # Retry once more before giving up
+  counter += 1
+  ```
+
+### Docstrings
+
+- Use triple double-quotes `"""` exclusively.
+- First line: short imperative summary (≤ 79 chars), ending with a period.
+- Blank line, then detailed description if needed.
+- Document parameters, return values, and raised exceptions for public APIs.
+- Prefer reStructuredText or Google-style format — be consistent within a module.
+- Docstrings must also be in **English**.
+
+## 4. Import Hygiene
+
+- One import per line; no `import os, sys`.
+- Order: stdlib → third-party → local, separated by blank lines, sorted alphabetically within each group.
+- Never use `from module import *`.
+- Remove unused imports immediately — ruff rule `F401` will catch these.
+- Place `from __future__ import annotations` before all other imports.
+
+## 5. PEP 8 Essentials (enforced by ruff)
+
+- **Indentation**: 4 spaces, no tabs.
+- **Line length**: 120 characters max (matches project `.editorconfig`).
+- **Trailing whitespace**: forbidden.
+- **Blank lines**: 2 between top-level definitions, 1 between methods.
+- **File endings**: exactly one trailing newline, LF only.
+- **Variable naming**: `snake_case` for functions/variables, `PascalCase` for classes, `UPPER_SNAKE` for constants.
+- **Avoid ambiguous names**: no single-char `l`, `O`, `I` (ruff `E741`).
+
+## 6. Common Pitfalls to Avoid
+
+| Rule | Example |
+|------|---------|
+| No mutable default args | `def f(items=None):` not `def f(items=[]):` |
+| No bare `except:` | Always catch a specific exception |
+| Use `is not` instead of `not ... is` | `if x is not None:` |
+| Sequence truthiness | `if seq:` not `if len(seq):` |
+| Use `with` for resources | Files, sockets, locks |
+| No `lambda` assignment | Use `def` instead of `fn = lambda x: ...` |
+| No string concat in loops | Use `"".join(parts)` |
+
+## 7. Quick Checklist Before Commit
+
+- [ ] `ruff check . --fix` — zero errors
+- [ ] `ruff format .` — no diff
+- [ ] No `Optional`, `Dict`, `List`, `Any` in new/modified code
+- [ ] All comments and docstrings are in English
+- [ ] No unused imports or variables
+- [ ] Type hints on all new public functions
+- [ ] `from __future__ import annotations` in new files

harness_gateway-0.7.0/.codebuddy/skills/pypi-publish/SKILL.md

@@ -0,0 +1,307 @@
+---
+name: publish
+description: 当需要发布 Python 包到 PyPI 时使用 — 创建 release 分支、升版本号、更新 CHANGELOG、发布到 PyPI、打 tag、并创建合并请求到 main
+---
+
+# Publish
+
+自动化 Python 包的完整发布流程。
+
+**开始时宣告：** "正在使用 publish 技能发布版本 {VERSION}。"
+
+## 配置项
+
+以下配置有默认值，可在项目的 `.codebuddy/skills/publish/SKILL.md` 中覆盖。
+
+| 配置项 | 默认值 | 说明 |
+|--------|--------|------|
+| `PUBLISH_CMD` | 自动检测（见步骤 5） | 发布到 PyPI 的命令 |
+| `CHANGELOG_FILE` | `CHANGELOG.md` | 相对于仓库根目录的路径，文件不存在则跳过 |
+| `VERSION_FILE` | `pyproject.toml` | 包含版本号的文件 |
+| `VERSION_PATTERN` | `^\s*version\s*=\s*"[^"]+"` | 匹配版本行的正则表达式 |
+| `TAG_PREFIX` | ``（空） | Git tag 前缀，设为 `v` 则生成 `v0.1.14` 风格标签 |
+| `REMOTE` | `origin` | Git 远程仓库名 |
+| `TARGET_BRANCH` | `main` | 合并请求的目标分支 |
+| `RELEASE_BRANCH_PREFIX` | `release/` | release 分支名前缀 |
+
+## 调用方式
+
+```
+/publish 0.1.14
+```
+
+目标版本号是唯一必填参数，其余均从配置或自动检测获取。
+
+## 发布流程
+
+### 步骤 1 — 读取配置并确认版本
+
+1. 获取仓库根目录：`git rev-parse --show-toplevel`
+2. 从 `VERSION_FILE` 读取当前版本：
+   ```bash
+   grep -E '^\s*version\s*=\s*"[^"]+"' pyproject.toml
+   ```
+3. 检查未提交的更改：
+   ```bash
+   git status --short
+   ```
+   如果存在未提交的更改，它们将被包含在步骤 4 的发布提交中。这是有意为之 — 所有待处理的工作随版本一起发布。
+4. 查找最近的 git tag：
+   ```bash
+   git tag --sort=-creatordate | head -1
+   ```
+   如果没有 tag，视为首次发布（在步骤 3 中使用从仓库初始到 HEAD 的所有提交）。
+5. 展示确认信息：
+
+```
+当前版本 (pyproject.toml): X.Y.Z
+目标版本:                   A.B.C
+上次发布 tag:               X.Y.Z (YYYY-MM-DD)
+Release 分支:               release/A.B.C
+目标分支 (MR):              main
+
+确认发布 X.Y.Z → A.B.C？[y/N]
+```
+
+如果用户未输入 `y` 确认，立即中止。
+
+### 步骤 2 — 创建 release 分支
+
+从当前 HEAD 创建并切换到新的 release 分支：
+
+```bash
+git checkout -b {RELEASE_BRANCH_PREFIX}{version}
+```
+
+如果分支已存在，中止：
+```
+✗ 分支 {RELEASE_BRANCH_PREFIX}{version} 已存在。
+请手动删除：git branch -D {RELEASE_BRANCH_PREFIX}{version}
+然后重新运行 /publish。
+```
+
+### 步骤 3 — 分析变更并生成 CHANGELOG 草稿
+
+1. 获取上次 tag 以来的提交：
+   ```bash
+   git log {last_tag}..HEAD --oneline
+   # 首次发布时：
+   git log --oneline
+   ```
+
+2. 如果没有找到提交：
+   ```
+   ⚠ 自上次发布 tag ({last_tag}) 以来没有新提交。
+   是否继续？[y/N]
+   ```
+   用户未确认则中止。
+
+3. 按提交前缀分类，生成 Keep a Changelog 格式的条目。
+
+   **CHANGELOG 内容必须用中文书写。** 将每个提交总结为简洁的中文要点 — 不要逐字翻译提交信息。适当合并相关提交。
+
+   分类规则：
+   - 以 `feat:` 或 `feat(` 开头 → **新增**
+   - 以 `fix:` 或 `fix(` 开头 → **修复**
+   - 以 `refactor:` 或 `perf:` 开头 → **变更**
+   - 包含 `!:` 或提交正文含 `BREAKING CHANGE:` → **变更**，加 `**Breaking:**` 前缀
+   - 以 `docs:` 开头 → **变更**
+   - 以 `chore:`、`test:`、`ci:` 开头 → 忽略（基础设施噪音）
+   - 其他所有提交 → **变更**
+   - 移除的功能 → **移除**
+   - 安全修复 → **安全**
+
+   输出格式：
+   ```markdown
+   ## [A.B.C] - YYYY-MM-DD
+
+   ### 新增
+   - 中文描述新增功能
+
+   ### 修复
+   - 中文描述修复内容
+
+   ### 变更
+   - 中文描述行为变更
+
+   ### 移除
+   - 中文描述移除内容
+
+   ### 安全
+   - 中文描述安全修复
+   ```
+   省略空的分类。日期使用 ISO 8601 格式（当天日期）。日期行与第一个分类之间、各分类之间保留空行。
+
+4. 向用户展示草稿并请求确认：
+   ```
+   CHANGELOG 草稿：
+
+   {draft}
+
+   添加到 CHANGELOG.md？[y/N/edit]
+   ```
+   - `y` → 继续
+   - `n` → 中止
+   - `edit` 或其他反馈 → 询问用户："需要什么修改？" — 等待回复后重新生成，再次展示确认。循环直到 `y` 或 `n`。
+
+5. 如果 `CHANGELOG_FILE` 不存在，跳过此步骤（无需警告）。
+
+### 步骤 4 — 更新文件、提交并推送 release 分支
+
+按顺序执行：
+
+**4a. 更新 CHANGELOG：**
+
+在 `CHANGELOG_FILE` 中找到 `## [Unreleased]` 标题，在其后插入新版本条目（保持 `[Unreleased]` 为空）：
+
+```markdown
+## [Unreleased]
+
+## [A.B.C] - YYYY-MM-DD
+### 新增
+- ...
+```
+
+如果 `## [Unreleased]` 标题不存在，在 `# Changelog` 标题行之后插入新条目（若无标题则插入到文件顶部）。
+
+**4b. 升级 VERSION_FILE 中的版本号：**
+
+替换 `VERSION_PATTERN` 匹配到的版本行。对于 `pyproject.toml`：
+```bash
+# 查找当前行：
+grep -n '^\s*version\s*=\s*"[^"]+"' pyproject.toml
+# 用 Edit 工具将该行的 "X.Y.Z" 替换为 "A.B.C"
+```
+
+**4c. 提交：**
+
+检查工作树状态：
+```bash
+git status --short
+```
+
+- 如果有更改（已暂存或未暂存）：暂存所有文件并提交：
+  ```bash
+  git add -A
+  git commit -m "chore: release {version}"
+  ```
+- 如果工作树已干净：无需提交，跳过。
+
+**4d. 推送 release 分支：**
+```bash
+git push -u {REMOTE} {RELEASE_BRANCH_PREFIX}{version}
+```
+
+推送失败则中止。
+
+### 步骤 5 — 发布到 PyPI
+
+**自动检测 PUBLISH_CMD**（仅在配置未覆盖时）：
+
+```bash
+# 检查 Makefile 是否有 publish 目标
+grep -q '^\s*publish\s*:' Makefile 2>/dev/null && echo "make publish" || echo "python -m build && python -m twine upload dist/*"
+```
+
+- 如果 `make publish` 目标存在 → `PUBLISH_CMD=make publish`
+- 否则 → `PUBLISH_CMD=python -m build && python -m twine upload dist/*`
+- 如果 `python -m build` 或 `python -m twine` 未安装，中止："缺少构建工具。请安装：`pip install build twine`"
+
+执行：
+```bash
+{PUBLISH_CMD}
+```
+
+实时输出。如果退出码非零：
+
+```
+✗ 发布失败（退出码 N）。已停止 — 不会创建 tag。
+请检查上方输出，解决问题后重新运行 /publish。
+```
+
+**不继续执行步骤 6。**
+
+### 步骤 6 — 打 tag 并推送
+
+```bash
+git tag {TAG_PREFIX}{version}
+git push {REMOTE} {TAG_PREFIX}{version}
+```
+
+如果 `git tag` 因 tag 已存在而失败：
+```
+✗ Tag {TAG_PREFIX}{version} 已存在。
+请手动删除：git tag -d {TAG_PREFIX}{version}
+然后重新运行 /publish 从此步骤重试。
+```
+中止。
+
+### 步骤 7 — 创建合并请求
+
+使用工丰 MCP 工具从 release 分支创建到 `TARGET_BRANCH` 的合并请求：
+
+1. 从 git remote 检测项目路径：
+   ```bash
+   git remote get-url {REMOTE} | sed -E 's|.*[:/](.+/.+)\.git$|\1|'
+   ```
+
+2. 使用 `mcp__gongfeng__create_merge_request` 创建 MR：
+   - `project_id`：项目完整路径（如 `orcakit/finnie`）
+   - `title`：`chore: release {version}`
+   - `source_branch`：`{RELEASE_BRANCH_PREFIX}{version}`
+   - `target_branch`：`{TARGET_BRANCH}`
+   - `description`：步骤 3 生成的 CHANGELOG 条目
+
+3. 成功时展示：
+   ```
+   ✓ 已发布 {package_name} {version} 到 PyPI
+   ✓ 已创建并推送 tag {TAG_PREFIX}{version} 到 {REMOTE}
+   ✓ 已创建合并请求：{RELEASE_BRANCH_PREFIX}{version} → {TARGET_BRANCH}
+     链接：{mr_url}
+   ```
+
+4. MR 创建失败时展示警告（非致命 — 发布已成功）：
+   ```
+   ⚠ 发布成功，但合并请求创建失败。
+   请手动创建：{RELEASE_BRANCH_PREFIX}{version} → {TARGET_BRANCH}
+   ```
+
+### 步骤 8 — 切回原分支
+
+返回创建 release 分支之前所在的分支：
+
+```bash
+git checkout {original_branch}
+```
+
+确保流程结束后用户不会停留在 release 分支上。
+
+## 错误处理参考
+
+| 场景 | 行为 |
+|------|------|
+| `VERSION_FILE` 未找到 | 中止："找不到 VERSION_FILE：{path}" |
+| 文件中未匹配到版本号 | 中止："在 {VERSION_FILE} 中找不到匹配 {VERSION_PATTERN} 的版本行" |
+| 没有 git tag（首次发布） | 使用从仓库初始到 HEAD 的所有提交；提示"首次发布 — 使用完整 git 历史" |
+| 上次 tag 以来无提交 | 警告并询问是否继续 |
+| Release 分支已存在 | 中止并给出删除指令 |
+| 步骤 4 推送失败 | 中止：文件已在本地更新但未推送 |
+| 步骤 5 发布失败 | 中止：不创建 tag、不创建 MR |
+| 步骤 6 tag 已存在 | 中止并给出删除指令 |
+| 步骤 7 MR 创建失败 | 仅警告（发布已成功） |
+
+## 红线规则
+
+**绝不：**
+- 在发布成功前创建 tag
+- 在发布成功前创建合并请求
+- 跳过步骤 1 的用户确认
+- 跳过步骤 3 的 CHANGELOG 确认
+- 在任何步骤失败后继续执行（步骤 7 MR 失败除外）
+- 流程结束后让用户留在 release 分支
+
+**始终：**
+- 任何失败立即中止（步骤 7 除外）
+- 中止前展示完整错误输出
+- 插入新版本条目后保持 `[Unreleased]` 为空
+- 流程结束时切回原分支

harness_gateway-0.7.0/.env.example

@@ -0,0 +1,55 @@
+# OpenAI API Configuration
+# Copy this file to .env and fill in your credentials
+
+OPENAI_API_KEY=your_api_key_here
+OPENAI_BASE_URL=https://api.openai.com/v1
+OPENAI_MODEL_NAME=gpt-4o-mini
+
+# ---------------------------------------------------------------------------
+# XiaoYi (小艺 / Huawei OpenClaw)
+# ---------------------------------------------------------------------------
+XIAOYI_AK=
+XIAOYI_SK=
+XIAOYI_AGENT_ID=
+# Show thinking / tool messages (true/false)
+XIAOYI_SHOW_THINKING=false
+XIAOYI_SHOW_TOOL_HINTS=true
+
+# ---------------------------------------------------------------------------
+# MQTT (EMQX Cloud example)
+# ---------------------------------------------------------------------------
+MQTT_HOST=c14633a9.ala.cn-shenzhen.emqxsl.cn
+MQTT_PORT=8883
+MQTT_USERNAME=
+MQTT_PASSWORD=
+MQTT_SUBSCRIBE_TOPIC=devices/+/in
+MQTT_PUBLISH_TOPIC=devices/{client_id}/out
+MQTT_TLS_ENABLED=true
+# Path to CA PEM file, or set tls_ca_pem inline in code
+MQTT_TLS_CA_FILE=
+MQTT_SHOW_THINKING=false
+MQTT_SHOW_TOOL_HINTS=true
+
+# ---------------------------------------------------------------------------
+# Telegram
+# ---------------------------------------------------------------------------
+TELEGRAM_BOT_TOKEN=
+TELEGRAM_HTTP_PROXY=
+TELEGRAM_SHOW_TYPING=true
+TELEGRAM_SHOW_THINKING=false
+TELEGRAM_SHOW_TOOL_HINTS=true
+
+# ---------------------------------------------------------------------------
+# Other IM platforms (examples)
+# ---------------------------------------------------------------------------
+FEISHU_APP_ID=
+FEISHU_APP_SECRET=
+QQ_APP_ID=
+QQ_TOKEN=
+QQ_SECRET=
+DINGTALK_APP_KEY=
+DINGTALK_APP_SECRET=
+WECOM_BOT_ID=
+WECOM_SECRET=
+WEIXIN_ACCOUNT_ID=
+WEIXIN_TOKEN=

harness_gateway-0.7.0/.github/pull_request_template.md

@@ -0,0 +1,23 @@
+## Summary
+
+<!-- What does this PR change and why? -->
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Breaking change
+- [ ] Documentation
+- [ ] Refactor / chore
+
+## Test plan
+
+<!-- How did you verify this? Include commands run (e.g. `make all`). -->
+
+- [ ] `make all` passes locally
+- [ ] Added/updated tests
+
+## Checklist
+
+- [ ] Updated `CHANGELOG.md` (if user-facing)
+- [ ] README / docs updated (if needed)

harness_gateway-0.7.0/.github/workflows/ci.yml

@@ -0,0 +1,38 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+concurrency:
+  group: ci-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  quality:
+    name: "Python ${{ matrix.python-version }}"
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.11", "3.12"]
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: astral-sh/setup-uv@v4
+        with:
+          enable-cache: true
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install dependencies
+        run: make install
+
+      - name: Lint
+        run: make lint
+
+      - name: Type check
+        run: make typecheck
+
+      - name: Test
+        run: make test

harness_gateway-0.7.0/.github/workflows/codeql.yml

@@ -0,0 +1,30 @@
+name: CodeQL
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+  schedule:
+    - cron: "0 3 * * 1"
+
+permissions:
+  security-events: write
+
+jobs:
+  analyze:
+    name: Analyze
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v3
+        with:
+          languages: python
+
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v3
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v3