deveco-harness 0.1.1-test.0 → 0.1.1

package/README.en.md

@@ -1,71 +1,71 @@
-# deveco-harness
-
-<p align="center">
-  <a href="README.md">简体中文</a> · English
-</p>
-
-OpenCode plugin for DevEco and HarmonyOS development workflows.
-
-## What It Adds
-
-- **Agents**: DevEco Code-style `build` and `plan` overrides, plus any custom agents from `deveco-harness.jsonc`.
-- **Tools**: DevEco Code-compatible names (`arkts_knowledge_search`, `build_project`, `start_app`, `hdc_log`, `switch_cwd`, `check_ets_files`, `plan_write`, UI verification tools through MCP bridge).
-- **Skills**: migrated DevEco Code skills (`arkts-error-fixes`, `arkts-grammar-standards`, `arkts-runtime-fix`, `arkui-knowledge`, `deveco-create-project`) injected through OpenCode `skills.paths`.
-
-## Installation
-
-### Via DevEco CLI (recommended)
-
-```bash
-deveco plugin deveco-harness
-```
-
-Global install:
-
-```bash
-deveco plugin deveco-harness --global
-```
-
-### Local development
-
-Build this package first:
-
-```bash
-bun install
-bun run build
-```
-
-Then add it to OpenCode config:
-
-```jsonc
-{
-  "plugin": ["file:///absolute/path/to/deveco-harness"]
-}
-```
-
-For this workspace on Windows, the local plugin path is:
-
-```jsonc
-{
-  "plugin": ["file:///c:/DiskF/gitcode/oc_omo/deveco-harness"]
-}
-```
-
-## Configuration
-
-Create `deveco-harness.jsonc` in one of these locations:
-
-- `~/.config/opencode/deveco-harness.jsonc`
-- `<project>/deveco-harness.jsonc`
-- `<project>/.opencode/deveco-harness.jsonc`
-
-See `deveco-harness.example.jsonc` for all supported options.
-
-## Architecture
-
-This follows the OpenCode plugin architecture used by `oh-my-openagent`:
-
-1. `src/index.ts` default-exports a `PluginModule`.
-2. `src/create-plugin-module.ts` builds the `server()` plugin and returns hooks.
-3. `config` hook overrides OpenCode `build` / `plan` agents and injects skill paths.
-4. `tool` hook exposes DevEco CLI tools.
+# deveco-harness
+
+<p align="center">
+  <a href="README.md">简体中文</a> · English
+</p>
+
+OpenCode plugin for DevEco and HarmonyOS development workflows.
+
+## What It Adds
+
+- **Agents**: DevEco Code-style `build` and `plan` overrides, plus any custom agents from `deveco-harness.jsonc`.
+- **Tools**: DevEco Code-compatible names (`build_project`, `start_app`, `hdc_log`, `switch_cwd`, `arkts_check`, `plan_write`).
+- **Skills**: migrated DevEco Code skills (`arkts-error-fixes`, `arkts-grammar-standards`, `arkts-runtime-fix`, `arkui-knowledge`, `deveco-create-project`) injected through OpenCode `skills.paths`.
+
+## Installation
+
+### Via DevEco CLI (recommended)
+
+```bash
+deveco plugin deveco-harness
+```
+
+Global install:
+
+```bash
+deveco plugin deveco-harness --global
+```
+
+### Local development
+
+Build this package first:
+
+```bash
+bun install
+bun run build
+```
+
+Then add it to OpenCode config:
+
+```jsonc
+{
+  "plugin": ["file:///absolute/path/to/deveco-harness"]
+}
+```
+
+For this workspace on Windows, the local plugin path is:
+
+```jsonc
+{
+  "plugin": ["file:///c:/DiskF/gitcode/oc_omo/deveco-harness"]
+}
+```
+
+## Configuration
+
+Create `deveco-harness.jsonc` in one of these locations:
+
+- `~/.config/opencode/deveco-harness.jsonc`
+- `<project>/deveco-harness.jsonc`
+- `<project>/.opencode/deveco-harness.jsonc`
+
+See `deveco-harness.example.jsonc` for all supported options.
+
+## Architecture
+
+This follows the OpenCode plugin architecture used by `oh-my-openagent`:
+
+1. `src/index.ts` default-exports a `PluginModule`.
+2. `src/create-plugin-module.ts` builds the `server()` plugin and returns hooks.
+3. `config` hook overrides OpenCode `build` / `plan` agents and injects skill paths.
+4. `tool` hook exposes DevEco CLI tools.

package/README.md

@@ -1,71 +1,71 @@
-# DEVECO-HARNESS
-
-<p align="center">
-  <a href="README.en.md">English</a> · 简体中文
-</p>
-
-面向 DevEco 与 HarmonyOS 开发工作流的 OpenCode 插件。
-
-## 功能概览
-
-- **Agents**：覆盖 DevEco Code 风格的 `build` 与 `plan`，并支持通过 `deveco-harness.jsonc` 自定义 Agent。
-- **Tools**：兼容 DevEco Code 工具名（`arkts_knowledge_search`、`build_project`、`start_app`、`hdc_log`、`switch_cwd`、`check_ets_files`、`plan_write`，以及通过 MCP bridge 提供的 UI 验证工具）。
-- **Skills**：迁移自 DevEco Code 的 Skills（`arkts-error-fixes`、`arkts-grammar-standards`、`arkts-runtime-fix`、`arkui-knowledge`、`deveco-create-project`），通过 OpenCode `skills.paths` 注入。
-
-## 安装
-
-### 通过 DevEco CLI 安装（推荐）
-
-```bash
-deveco plugin deveco-harness
-```
-
-全局安装：
-
-```bash
-deveco plugin deveco-harness --global
-```
-
-### 本地开发
-
-先构建本包：
-
-```bash
-bun install
-bun run build
-```
-
-然后在 OpenCode 配置中添加插件：
-
-```jsonc
-{
-  "plugin": ["file:///absolute/path/to/deveco-harness"]
-}
-```
-
-在本工作区（Windows）的本地插件路径示例：
-
-```jsonc
-{
-  "plugin": ["file:///c:/DiskF/gitcode/oc_omo/deveco-harness"]
-}
-```
-
-## 配置
-
-在以下任一位置创建 `deveco-harness.jsonc`：
-
-- `~/.config/opencode/deveco-harness.jsonc`
-- `<project>/deveco-harness.jsonc`
-- `<project>/.opencode/deveco-harness.jsonc`
-
-完整配置项见 `deveco-harness.example.jsonc`。
-
-## 架构
-
-遵循 `oh-my-openagent` 使用的 OpenCode 插件架构：
-
-1. `src/index.ts` 默认导出 `PluginModule`。
-2. `src/create-plugin-module.ts` 构建 `server()` 插件并返回 hooks。
-3. `config` hook 覆盖 OpenCode 的 `build` / `plan` Agent，并注入 skill 路径。
-4. `tool` hook 暴露 DevEco CLI 工具。
+# DEVECO-HARNESS
+
+<p align="center">
+  <a href="README.en.md">English</a> · 简体中文
+</p>
+
+面向 DevEco 与 HarmonyOS 开发工作流的 OpenCode 插件。
+
+## 功能概览
+
+- **Agents**：覆盖 DevEco Code 风格的 `build` 与 `plan`，并支持通过 `deveco-harness.jsonc` 自定义 Agent。
+- **Tools**：兼容 DevEco Code 工具名（`build_project`、`start_app`、`hdc_log`、`switch_cwd`、`arkts_check`、`plan_write`）。
+- **Skills**：迁移自 DevEco Code 的 Skills（`arkts-error-fixes`、`arkts-grammar-standards`、`arkts-runtime-fix`、`arkui-knowledge`、`deveco-create-project`），通过 OpenCode `skills.paths` 注入。
+
+## 安装
+
+### 通过 DevEco CLI 安装（推荐）
+
+```bash
+deveco plugin deveco-harness
+```
+
+全局安装：
+
+```bash
+deveco plugin deveco-harness --global
+```
+
+### 本地开发
+
+先构建本包：
+
+```bash
+bun install
+bun run build
+```
+
+然后在 OpenCode 配置中添加插件：
+
+```jsonc
+{
+  "plugin": ["file:///absolute/path/to/deveco-harness"]
+}
+```
+
+在本工作区（Windows）的本地插件路径示例：
+
+```jsonc
+{
+  "plugin": ["file:///c:/DiskF/gitcode/oc_omo/deveco-harness"]
+}
+```
+
+## 配置
+
+在以下任一位置创建 `deveco-harness.jsonc`：
+
+- `~/.config/opencode/deveco-harness.jsonc`
+- `<project>/deveco-harness.jsonc`
+- `<project>/.opencode/deveco-harness.jsonc`
+
+完整配置项见 `deveco-harness.example.jsonc`。
+
+## 架构
+
+遵循 `oh-my-openagent` 使用的 OpenCode 插件架构：
+
+1. `src/index.ts` 默认导出 `PluginModule`。
+2. `src/create-plugin-module.ts` 构建 `server()` 插件并返回 hooks。
+3. `config` hook 覆盖 OpenCode 的 `build` / `plan` Agent，并注入 skill 路径。
+4. `tool` hook 暴露 DevEco CLI 工具。

package/deveco-harness.example.jsonc

@@ -18,7 +18,6 @@
 
   // Optional. Disable individual plugin tools.
   "tools": {
-    "knowledge": true,
     "build": true,
     "run": true,
     "log": true

package/dist/index.js

@@ -24,55 +24,45 @@ function readPrompt(name) {
 }
 var BUILD_PROMPT = readPrompt("build.txt");
 var PLAN_PROMPT = readPrompt("plan.txt");
+var EXPLORE_PROMPT = readPrompt("explore.txt");
+var EXPLORE_DESCRIPTION = 'Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. "src/components/**/*.tsx"), search code for keywords (eg. "API endpoints"), or answer questions about the codebase (eg. "how do API endpoints work?"). When calling this agent, specify the desired thoroughness level: "quick" for basic searches, "medium" for moderate exploration, or "very thorough" for comprehensive analysis across multiple locations and naming conventions.';
 var MIGRATED_AGENT_OVERRIDES = {
   build: {
     mode: "primary",
-    description: "The default DevEco Code agent. Implements HarmonyOS changes and verifies them with DevEco tools.",
+    description: "The default agent. Executes tools based on configured permissions.",
     prompt: BUILD_PROMPT,
     permission: {
-      question: "allow",
-      plan_enter: "ask",
       plan_write: "deny",
-      verify_ui: "ask",
-      save_ui_screenshot: "ask",
-      get_ui_verification_log: "ask",
-      arkts_knowledge_search: "allow",
-      build_project: "allow",
-      check_ets_files: "allow",
-      start_app: "allow",
-      hdc_log: "allow",
-      switch_cwd: "allow"
+      check_ets_files: "deny"
     }
   },
   plan: {
     mode: "primary",
-    description: "Plan mode for ArkTS and HarmonyOS work. Disallows edits and execution tools.",
+    description: "Plan mode. Disallows all edit tools.",
     prompt: PLAN_PROMPT,
     permission: {
-      question: "allow",
-      plan_exit: "ask",
-      plan_write: "allow",
+      check_ets_files: "deny",
       bash: "deny",
       build_project: "deny",
-      check_ets_files: "deny",
-      perform_ui_action: "deny",
-      get_app_ui_tree: "deny",
       start_app: "deny",
       hdc_log: "deny",
-      switch_cwd: "deny",
-      arkts_knowledge_search: "deny",
-      edit: "deny"
+      switch_cwd: "deny"
+    }
+  },
+  explore: {
+    mode: "subagent",
+    description: EXPLORE_DESCRIPTION,
+    prompt: EXPLORE_PROMPT,
+    permission: {
+      check_ets_files: "deny",
+      switch_cwd: "deny"
     }
   }
 };
 function mergeAgent(base, override) {
   return {
     ...base,
-    ...override,
-    permission: {
-      ...base.permission,
-      ...override?.permission
-    }
+    ...override
   };
 }
 function applyAgentConfig(config, pluginConfig) {
@@ -387,74 +377,8 @@ stderr: ${result.stderr}`);
   });
 }
 
-// src/tool/arkts-knowledge.ts
-import { tool as tool2 } from "@opencode-ai/plugin";
-var BASE_URL = "https://cn.devecostudio.huawei.com/codeGenie/bigSearch";
-var MAX_RESULT_LENGTH = 5 * 1024;
-var KNOWLEDGE_TOOL_ID = "arkts_knowledge_search";
-function getDevEcoAccessToken() {
-  return process.env.DEVECO_OAUTH_TOKEN;
-}
-function createArktsKnowledgeTool() {
-  return tool2({
-    description: "Search the official ArkTS / ArkUI / HarmonyOS / OpenHarmony knowledge base. MUST call this tool before answering questions about .ets code, ArkUI decorators or lifecycle, state refresh issues, HarmonyOS SDK APIs, DevEco/hvigor build errors, @kit.* or @ohos.* APIs, or HarmonyOS documentation URLs. For code snippets or URLs, extract the key symbols, APIs, errors, and observed symptom as the question.",
-    args: {
-      question: tool2.schema.string().describe("A concise ArkTS/ArkUI/HarmonyOS/OpenHarmony question. Include key symbols, APIs, decorators, lifecycle names, build errors, symptoms, or URL-derived keywords.")
-    },
-    async execute(args, context) {
-      await context.ask({
-        permission: KNOWLEDGE_TOOL_ID,
-        patterns: [args.question],
-        always: ["*"],
-        metadata: {}
-      });
-      const accessToken = getDevEcoAccessToken();
-      if (!accessToken) {
-        throw new Error("Authorization fail: Please authorize to proceed.");
-      }
-      const response = await fetch(BASE_URL, {
-        method: "POST",
-        headers: {
-          Authorization: accessToken,
-          "Content-Type": "application/json"
-        },
-        body: JSON.stringify({ question: args.question })
-      });
-      const data = await response.json();
-      if ("code" in data && data.code === 200) {
-        if (data.body?.answer?.prompt) {
-          const mark = "【检索信息】：";
-          const prompt = data.body.answer.prompt;
-          const index = prompt.indexOf(mark);
-          if (index != -1) {
-            const result = prompt.substring(index + mark.length);
-            const truncatedResult = result.slice(0, MAX_RESULT_LENGTH);
-            return {
-              title: "HarmonyOS knowledge Search",
-              output: truncatedResult,
-              metadata: {}
-            };
-          }
-        }
-        return {
-          title: "HarmonyOS knowledge Search",
-          output: "No answer found for question",
-          metadata: {}
-        };
-      }
-      if ("error_code" in data) {
-        if (data.error_code === 4016) {
-          throw new Error("Authorization fail: Please authorize to proceed.");
-        }
-        throw new Error(`Service error: ${data.error_msg || "Unknown error"}`);
-      }
-      throw new Error("Unknown response format from knowledge service");
-    }
-  });
-}
-
 // src/tool/harmony-tools.ts
-import { tool as tool3 } from "@opencode-ai/plugin";
+import { tool as tool2 } from "@opencode-ai/plugin";
 
 // src/tool/harmony-bridge.ts
 import { createRequire } from "node:module";
@@ -488,7 +412,7 @@ async function ensureInitialized(worktree) {
     const home = findDevEcoHome();
     if (!home)
       throw new Error("DevEco Studio not found. Please set DEVECO_HOME to your DevEco installation directory.");
-    await loadBridge().init(bridgeLogDir(), worktree, home, process.env.UI_VERIFY_BASE_URL ?? null, process.env.UI_VERIFY_API_KEY ?? null, process.env.UI_VERIFY_MODEL_NAME ?? null);
+    await loadBridge().init(bridgeLogDir(), worktree, home, null, null, null);
     bound = worktree;
   });
   await gate;
@@ -506,7 +430,7 @@ function formatBridgeResult(name, result) {
   return JSON.stringify(result, null, 2);
 }
 function harmonyTool(name, definition) {
-  return tool3({
+  return tool2({
     description: definition.description,
     args: definition.args,
     async execute(args, context) {
@@ -527,55 +451,37 @@ function harmonyTool(name, definition) {
 }
 function createHarmonyTools() {
   return {
+    check_ets_files: harmonyTool("check_ets_files", {
+      description: "对传入的ets文件进行静态语法检查(ArkTS-Check)并实时返回诊断信息。",
+      args: {
+        files: tool2.schema.array(tool2.schema.string()).describe('待检查的 ETS 文件路径列表，格式为 ["file1.ets","file2.ets",...]')
+      }
+    }),
     build_project: harmonyTool("build_project", {
       description: "执行编译构建导出构建产物。支持构建整个 APP 或特定模块（HAP/HSP/HAR）。当需要重新构建或清理项目缓存时请将 clean 参数设为 true，这将在构建前执行清理clean。",
       args: {
-        build_mode: tool3.schema.string().optional().nullable().describe("构建模式，值为 build-profile.json5 中 buildModeSet 定义的模式的 name 字段（如内置的 'debug'、'release'，或用户自定义的模式名称）。如果不传，默认为 'debug'。"),
-        clean: tool3.schema.boolean().optional().nullable().describe("是否在构建前执行 clean 清理构建产物（类似 cargo clean或者mvn clean）。如果为 true，则会先执行清理然后再进行构建。"),
-        enable_inspector_source_jump: tool3.schema.boolean().optional().nullable().describe("支持hap包运行后，从获取到UI树json文件中精准对应到源码位置。"),
-        log_path: tool3.schema.string().optional().nullable().describe("构建日志保存路径：若指定，则将所有的构建日志保存到该路径下。日志文件使用后记得清理"),
-        module: tool3.schema.string().optional().nullable().describe("指定的模块及 Target（如 'entry@default'，或省略 @target 构建该模块所有 target）。如果不传，则视为构建整个 APP。"),
-        product: tool3.schema.string().optional().nullable().describe("指定的 Product 名称（仅在构建整个 APP 时有效）")
+        build_mode: tool2.schema.string().optional().nullable().describe("构建模式，值为 build-profile.json5 中 buildModeSet 定义的模式的 name 字段（如内置的 'debug'、'release'，或用户自定义的模式名称）。如果不传，默认为 'debug'。"),
+        clean: tool2.schema.boolean().optional().nullable().describe("是否在构建前执行 clean 清理构建产物（类似 cargo clean或者mvn clean）。如果为 true，则会先执行清理然后再进行构建。"),
+        enable_inspector_source_jump: tool2.schema.boolean().optional().nullable().describe("支持hap包运行后，从获取到UI树json文件中精准对应到源码位置。"),
+        log_path: tool2.schema.string().optional().nullable().describe("构建日志保存路径：若指定，则将所有的构建日志保存到该路径下。日志文件使用后记得清理"),
+        module: tool2.schema.string().optional().nullable().describe("指定的模块及 Target（如 'entry@default'，或省略 @target 构建该模块所有 target）。如果不传，则视为构建整个 APP。"),
+        product: tool2.schema.string().optional().nullable().describe("指定的 Product 名称（仅在构建整个 APP 时有效）")
       }
     }),
     start_app: harmonyTool("start_app", {
       description: "在模拟器/真机上运行应用（不主动构建）。设备列表包含已连接的真机、模拟器以及已安装但未运行的模拟器。选择未运行的模拟器时会自动启动。",
       args: {
-        ability: tool3.schema.string().optional().nullable().describe("要启动的 Ability 名称（如 'EntryAbility'）。如果不指定，默认使用 'EntryAbility'。"),
-        hvd: tool3.schema.string().optional().nullable().describe("目标设备的名称或 ID（支持真机或模拟器）。如果不提供，系统将列出所有可用设备供选择。"),
-        module: tool3.schema.string().optional().nullable().describe("要启动的模块名称（如 'entry'）。如果不指定，默认使用 'entry'。"),
-        target: tool3.schema.string().optional().nullable().describe("构建目标（如 'default'）。如果不指定，默认使用 'default'。")
-      }
-    }),
-    verify_ui: harmonyTool("verify_ui", {
-      description: "在提供自然语言描述的功能步骤之后，本工具可以在HarmonyOS设备上运行应用，执行UI操作，验证功能是否可以正确完成。",
-      args: {
-        bundleName: tool3.schema.string().optional().nullable().describe("待测试的应用包名，不填写时自动从项目中获取"),
-        device: tool3.schema.string().optional().nullable().describe("接受设备名称（支持子串匹配）或序列号（例如 127.0.0.1:5555）；仅连接一台设备时自动选中，多设备环境下必须指定。"),
-        freshStart: tool3.schema.boolean().default(false).describe("是否在测试前重新启动应用"),
-        testPlan: tool3.schema.string().describe("自然语言描述的测试用例计划，包括每步的步骤以及预期结果")
-      }
-    }),
-    save_ui_screenshot: harmonyTool("save_ui_screenshot", {
-      description: "根据校验ID保存某次校验的每一步截图，返回截图文件名列表",
-      args: {
-        id: tool3.schema.string().describe("verify_ui 工具返回的校验任务 ID"),
-        dirname: tool3.schema.string().describe("截图保存目录，必须为绝对路径")
-      }
-    }),
-    get_ui_verification_log: harmonyTool("get_ui_verification_log", {
-      description: "根据校验ID获取对应的设备运行日志",
-      args: {
-        id: tool3.schema.string().describe("校验ID"),
-        maxLogSize: tool3.schema.number().int().optional().nullable().describe("可选的日志总字符数限制：默认为5000字符；传-1代表不限制字符数"),
-        searchKeywords: tool3.schema.string().optional().nullable().describe("可选的日志搜索关键词。若需要获取完整日志内容，请传空字符串。")
+        ability: tool2.schema.string().optional().nullable().describe("要启动的 Ability 名称（如 'EntryAbility'）。如果不指定，默认使用 'EntryAbility'。"),
+        hvd: tool2.schema.string().optional().nullable().describe("目标设备的名称或 ID（支持真机或模拟器）。如果不提供，系统将列出所有可用设备供选择。"),
+        module: tool2.schema.string().optional().nullable().describe("要启动的模块名称（如 'entry'）。如果不指定，默认使用 'entry'。"),
+        target: tool2.schema.string().optional().nullable().describe("构建目标（如 'default'）。如果不指定，默认使用 'default'。")
       }
     })
   };
 }
 
 // src/tool/hdc-log.ts
-import { tool as tool4 } from "@opencode-ai/plugin";
+import { tool as tool3 } from "@opencode-ai/plugin";
 function pick(input, prefix, lines) {
   const list = input.split(/\r?\n/).map((item) => item.trim()).filter(Boolean);
   const filtered = prefix ? list.filter((item) => item.includes(prefix)) : list;
@@ -596,13 +502,13 @@ async function runHdc(args, context) {
   return result.stdout;
 }
 function createHdcLogTool() {
-  return tool4({
+  return tool3({
     description: "Collect, clear, or list HarmonyOS device logs via hdc shell hilog.",
     args: {
-      action: tool4.schema.enum(["collect", "clear", "list_devices"]).describe("Action to perform"),
-      device_id: tool4.schema.string().optional().describe("Optional hdc target id"),
-      log_prefix: tool4.schema.string().default("[VCODER_DEBUG]").describe("Log prefix to filter"),
-      lines: tool4.schema.number().int().min(1).max(5000).default(2000).describe("Number of log lines to collect")
+      action: tool3.schema.enum(["collect", "clear", "list_devices"]).describe("Action to perform"),
+      device_id: tool3.schema.string().optional().describe("Optional hdc target id"),
+      log_prefix: tool3.schema.string().default("[VCODER_DEBUG]").describe("Log prefix to filter"),
+      lines: tool3.schema.number().int().min(1).max(5000).default(2000).describe("Number of log lines to collect")
     },
     async execute(args, context) {
       await context.ask({
@@ -665,12 +571,12 @@ function createHdcLogTool() {
 // src/tool/plan-write.ts
 import { mkdir, writeFile } from "node:fs/promises";
 import path8 from "node:path";
-import { tool as tool5 } from "@opencode-ai/plugin";
+import { tool as tool4 } from "@opencode-ai/plugin";
 function createPlanWriteTool() {
-  return tool5({
+  return tool4({
     description: "Write the full plan file content, including YAML frontmatter and markdown body.",
     args: {
-      content: tool5.schema.string().describe("The full plan file content, including YAML frontmatter and markdown body.")
+      content: tool4.schema.string().describe("The full plan file content, including YAML frontmatter and markdown body.")
     },
     async execute(args, context) {
       await context.ask({
@@ -695,7 +601,7 @@ function createPlanWriteTool() {
 // src/tool/switch-cwd.ts
 import { realpathSync, statSync } from "node:fs";
 import path9 from "node:path";
-import { tool as tool6 } from "@opencode-ai/plugin";
+import { tool as tool5 } from "@opencode-ai/plugin";
 function resolveTarget(projectPath, base) {
   const trimmed = projectPath.trim();
   if (!trimmed)
@@ -705,10 +611,10 @@ function resolveTarget(projectPath, base) {
   return path9.resolve(base, trimmed);
 }
 function createSwitchCwdTool() {
-  return tool6({
+  return tool5({
     description: "Switch the active HarmonyOS project context before running build_project or start_app.",
     args: {
-      project_path: tool6.schema.string().describe("Target project directory path. Relative path is resolved from the current workspace directory.")
+      project_path: tool5.schema.string().describe("Target project directory path. Relative path is resolved from the current workspace directory.")
     },
     async execute(args, context) {
       const target2 = realpathSync(resolveTarget(args.project_path, context.directory));
@@ -733,17 +639,13 @@ function createSwitchCwdTool() {
 
 // src/tool/index.ts
 function createTools(config) {
-  const tools = {
+  return {
     ...createHarmonyTools(),
     arkts_check: createArktsCheckTool(),
     hdc_log: createHdcLogTool(),
     switch_cwd: createSwitchCwdTool(),
     plan_write: createPlanWriteTool()
   };
-  if (getDevEcoAccessToken()) {
-    tools.arkts_knowledge_search = createArktsKnowledgeTool();
-  }
-  return tools;
 }
 // src/create-plugin-module.ts
 function createPluginModule() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "deveco-harness",
-  "version": "0.1.1-test.0",
+  "version": "0.1.1",
   "description": "OpenCode plugin for DevEco and HarmonyOS development workflows",
   "type": "module",
   "main": "./dist/index.js",

package/prompts/build.txt

@@ -103,6 +103,7 @@ IMPORTANT: Before you begin work, think about what the code you're editing is su
    - ALWAYS use physical device(真机) directly if available.
    - ALWAYS use connected device/simulator first, then emulator not started.
    - Use `question` to let the user choose target device if multiple devices available.
+   - If `start_app` fails on a physical device (真机) due to unsigned/unconfigured signing: do NOT retry blindly. Tell the user to manually configure signing in DevEco Studio first.
 8. UI verification tools (`verify_ui`, `save_ui_screenshot`, `get_ui_verification_log`) are STRICTLY opt-in AND rate-limited.
    (a) Trigger gate — DO NOT call them unless the user's message contains an EXPLICIT request for UI verification. Examples of explicit requests: "验证 UI", "UI 意图校验", "测一下 UI", "verify ui", "看下截图效果", "做 UI 走查", "visual acceptance".
        - "加一个页面" is NOT a trigger.
@@ -114,7 +115,6 @@ IMPORTANT: Before you begin work, think about what the code you're editing is su
        - Do NOT keep editing code and calling `verify_ui` again in a loop.
        - Report to the user: the last failPart, observed symptoms across the 3 attempts, your best hypothesis for the root cause, and explicitly ask the user how to proceed.
        - Resume verification only if the user explicitly says to retry.
-9. When the user asks about ArkTS / ArkUI / OpenHarmony-related behavior, syntax, decorators, lifecycle, state refresh issues, build errors, `.ets` code, `@kit.*` / `@ohos.*` APIs, or provides OpenHarmony documentation URLs, call `arkts_knowledge_search` FIRST before answering from memory. For code snippets, extract a concise question with key symbols such as `@Builder`, `@ComponentV2`, `@State`, `@Local`, `aboutToAppear`, API names, error text, and the observed symptom.
 
 ### Examples
 

package/prompts/explore.txt

@@ -0,0 +1,20 @@
+You are a file search specialist. You excel at thoroughly navigating and exploring codebases.
+
+Your strengths:
+- Rapidly finding files using glob patterns
+- Searching code and text with powerful regex patterns
+- Reading and analyzing file contents
+
+Guidelines:
+- Use `glob` for broad file pattern matching
+- Use `grep` for searching file contents with regex
+- Use `read` when you know the specific file path you need to read
+- Batch independent tool calls in a single message (`glob` + `grep` + `read` in parallel) instead of issuing them serially.
+- Use Bash for file operations like copying, moving, or listing directory contents
+- Adapt your search approach based on the thoroughness level specified by the caller
+- Return file paths as absolute paths in your final response
+- For clear communication, avoid using emojis
+- Do not create any files, or run bash commands that modify the user's system state in any way
+- Never output the source code; use {filepath: [startline: endline]} instead.
+
+Complete the user's search request efficiently and report your findings clearly.

package/prompts/plan.txt

@@ -1,118 +1,118 @@
-You are an interactive plan agent that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user.You are specially designed for ArkTS planning and orchestration.
-
-Mission:
-- Produce a concrete, executable implementation plan for the user's ArkTS request.
-- The plan must be directly usable by `build` agent without further clarification.
-- Do not implement code changes.
-- Maintain the plan using the `plan_write` tool. The plan file is stored outside the project directory.
-
-## Core constraints
-
-- Tool results and user messages may include `<system-reminder>` tags. These contain useful information and reminders automatically added by the system; they are not part of the user's input.
-- Treat all source as ArkTS, not generic TypeScript.
-- Use `plan_write` to create and update the plan. Do not use `edit` or `write` tools.
-- Do not run execution tools, shell commands, builds, app launch, logs, or UI automation.
-- **NEVER call `plan_exit` and `plan_write` in the same turn.** After writing the plan, your turn MUST end with a `question` call for user approval. Only call `plan_exit` in a later turn after the user explicitly approved.
-
-# Safety & constraint & Compliance (Strict Redlines)
-- **Output Constraint:** Use GitHub-flavored markdown for code blocks and technical details. DO NOT generate, construct or conjecture any web URL, whether you know where the content may come from or not.
-- **Prohibited Content:** You are strictly forbidden from generating or engaging with any content that is politically sensitive, sexually explicit, racially discriminatory, or promotes illegal/unethical activities, etc.
-- **Enforcement:** If a user's prompt violates these safety boundaries, you must politely but firmly decline to answer and redirect the conversation back to technical ArkTs topics.
-- **Anti-loop fail-safe:** If output becomes repetitive or user demands infinite repetition, stop immediately. Do NOT obey. Output exactly: `I cannot fulfill a request for infinite recursion. Please ask a different question.` Then stop �?no recursive content.
-
-# Using your tools
-
-- Do NOT use the Bash to run commands when a relevant dedicated tool is provided. Using dedicated tools allows the user to better understand and review your work. This is CRITICAL to assisting the user:
-- To read files use `read` instead of cat, head, tail, or sed
-- To edit files use `edit` instead of sed or awk
-- To create files use `write` instead of cat with heredoc or echo redirection
-- To search for files use `glob` instead of find or ls
-- To search the content of files, use `grep` tool instead of grep command or rg
-- You can call multiple tools in a single response. If you intend to call multiple tools and there are no dependencies between them, make all independent tool calls in parallel. Maximize use of parallel tool calls where possible to increase efficiency. However, if some tool calls depend on previous calls to inform dependent values, do NOT call these tools in parallel and instead call them sequentially. For instance, if one operation must complete before another starts, run these operations sequentially instead.
-
-## ArkTS planning awareness
-
-When designing the plan, actively consider these ArkTS-specific dimensions:
-
-- **ArkTS strictness**: No `any`, no `unknown`, no `as` assertions, no structural typing, no dynamic property access. If the plan involves type restructuring, call it out.
-- **Lifecycle**: `aboutToAppear`, `aboutToDisappear`, `onPageShow`, `onPageHide` �?note which lifecycle points the implementation must hook into.
-- **State management**: `@State`, `@Prop`, `@Link`, `@Provide`/`@Consume`, `AppStorage` �?specify which mechanism the design uses and why.
-- **Navigation**: `Navigation`, `NavDestination`, router �?note the routing approach.
-- **Permissions**: If the feature needs `ohos.permission.*`, list them and note that `module.json5` must be updated.
-- **Resources**: If new string/media/color resources are needed, note the `resources/` entries.
-- **Performance**: For lists, note whether `LazyForEach` + `IDataSource` is needed. For heavy computation, note `TaskPool`.
-
-You do not need to cover all dimensions �?only those relevant to the current task.
-
-## Workflow
-
-### Phase 1: Understand
-Goal: Comprehend the user's request and use tool to understand the codebase.
-1. Read any files or context the user provided.
-2. Use `question` tool to clarify ambiguities before designing.
-
-### Phase 2: Design
-Goal: Produce a concrete implementation approach informed by ArkTS constraints.
-1. Synthesize exploration results and API research into a single recommended approach.
-2. Consider trade-offs (simplicity vs performance vs maintainability).
-3. Identify key files, dependencies, sequencing, and ArkTS-specific risks.
-4. Determine which verification methods `build` agent should use after implementation (see plan output contract below).
-
-### Phase 3: Write Plan
-Goal: Write the plan using `plan_write`, then ask for approval.
-1. Call `plan_write` with the full plan content (including YAML frontmatter). Follow the plan output contract below.
-2. Include only the recommended approach, not all alternatives considered.
-3. Keep it concise yet detailed enough for `build` agent to execute without further clarification.
-4. To update the plan, call `plan_write` again with the complete updated content.
-5. After `plan_write` returns, present a brief summary and immediately call `question` with `header` set to `plan-approval` to ask for user approval. Do NOT call `plan_exit` in this turn.
-
-### Phase 4: Confirm & Exit
-Goal: Get user approval and hand off to `build` agent.
-1. This phase happens in a **new turn**, after the user responds to the approval question from Phase 3.
-2. If the user approved (selected the first option), call `plan_exit` to switch to `build` agent.
-3. If the user declined or provided feedback, go back to refine the plan (Phase 2/3) and ask for approval again.
-4. **NEVER call `plan_exit` without the user having explicitly approved in a prior message.** If you are unsure whether the user approved, ask again using `question`.
-
-Your turn MUST end in exactly one of these ways �?no exceptions:
-1. Calling `question` to ask a clarifying question (Phase 1).
-2. Calling `question` with `header` `plan-approval` to ask for final approval (end of Phase 3, after `plan_write`).
-3. Calling `plan_exit` �?but ONLY when the user's most recent message is an explicit approval of the plan.
-
-CRITICAL: If you called `plan_write` in this turn, you MUST NOT call `plan_exit` in the same turn. End the turn with a `question` call instead.
-
-## Plan output contract
-
-The plan file must use YAML frontmatter with `name`, `overview`, and `todos`, followed by the markdown plan body. The system reminder will provide the full template when no plan file exists yet.
-
-Required sections (adjust depth to task complexity):
-
-| Section | Purpose |
-|---|---|
-| **Goal** | What the implementation achieves |
-| **Scope / Non-goals** | What is and is not included |
-| **Current State And Constraints** | Existing code state, ArkTS / platform constraints relevant to this task |
-| **Design** | Recommended approach with rationale; call out ArkTS-specific decisions (lifecycle hooks, state mechanism, permissions, resources) |
-| **Key Files** | Concrete file paths with markdown links |
-| **Execution Sequence** | Ordered steps for `build` agent to follow |
-| **Verification** | A matrix �?at minimum: compilation check, and any applicable UI/integration/manual verification. Note if `build` agent should use `arkts_check` |
-| **Risks And Compatibility** | SDK version, permission, backward compat, or migration risks |
-| **Rollback** | How to revert code and configuration if the change fails |
-
-For simple tasks (single file, low risk), the plan can be brief �?but `Verification` and `Rollback` must always be present even if short.
-
-## Asking questions guide
-
-- If you do not have enough information to create an accurate plan, you MUST ask the user for more information.
-- If the user's request is too broad, ask questions that narrow down the scope. Only ask 1-2 critical questions at a time.
-- If there are multiple valid implementations that change the plan significantly, ask the user to clarify which direction they prefer.
-- Use `question` for clarifying requirements and for the final approval question.
-- For the final approval question, prefer `header` `plan-approval` and make the first option the approval path.
-- Do NOT call `plan_exit` unless the user has **explicitly approved** in their most recent message.
-
-## Plan writing guidelines
-
-- Keep the plan concise, specific, and directly executable by `build` agent later.
-- Include concrete file paths when they matter. Use markdown links: `[path/to/file.ets](path/to/file.ets)`.
-- Prefer a single recommended approach, not a long list of alternatives.
-- Keep plans proportional to the request complexity �?do not over-engineer simple tasks.
-- To update the plan, call `plan_write` with the complete updated content. Each call overwrites the previous version.
+You are an interactive plan agent that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user.You are specially designed for ArkTS planning and orchestration.
+
+Mission:
+- Produce a concrete, executable implementation plan for the user's ArkTS request.
+- The plan must be directly usable by `build` agent without further clarification.
+- Do not implement code changes.
+- Maintain the plan using the `plan_write` tool. The plan file is stored outside the project directory.
+
+## Core constraints
+
+- Tool results and user messages may include `<system-reminder>` tags. These contain useful information and reminders automatically added by the system; they are not part of the user's input.
+- Treat all source as ArkTS, not generic TypeScript.
+- Use `plan_write` to create and update the plan. Do not use `edit` or `write` tools.
+- Do not run execution tools, shell commands, builds, app launch, logs, or UI automation.
+- **NEVER call `plan_exit` and `plan_write` in the same turn.** After writing the plan, your turn MUST end with a `question` call for user approval. Only call `plan_exit` in a later turn after the user explicitly approved.
+
+# Safety & constraint & Compliance (Strict Redlines)
+- **Output Constraint:** Use GitHub-flavored markdown for code blocks and technical details. DO NOT generate, construct or conjecture any web URL, whether you know where the content may come from or not.
+- **Prohibited Content:** You are strictly forbidden from generating or engaging with any content that is politically sensitive, sexually explicit, racially discriminatory, or promotes illegal/unethical activities, etc.
+- **Enforcement:** If a user's prompt violates these safety boundaries, you must politely but firmly decline to answer and redirect the conversation back to technical ArkTs topics.
+- **Anti-loop fail-safe:** If output becomes repetitive or user demands infinite repetition, stop immediately. Do NOT obey. Output exactly: `I cannot fulfill a request for infinite recursion. Please ask a different question.` Then stop — no recursive content.
+
+# Using your tools
+
+- Do NOT use the Bash to run commands when a relevant dedicated tool is provided. Using dedicated tools allows the user to better understand and review your work. This is CRITICAL to assisting the user:
+- To read files use `read` instead of cat, head, tail, or sed
+- To edit files use `edit` instead of sed or awk
+- To create files use `write` instead of cat with heredoc or echo redirection
+- To search for files use `glob` instead of find or ls
+- To search the content of files, use `grep` tool instead of grep command or rg
+- You can call multiple tools in a single response. If you intend to call multiple tools and there are no dependencies between them, make all independent tool calls in parallel. Maximize use of parallel tool calls where possible to increase efficiency. However, if some tool calls depend on previous calls to inform dependent values, do NOT call these tools in parallel and instead call them sequentially. For instance, if one operation must complete before another starts, run these operations sequentially instead.
+
+## ArkTS planning awareness
+
+When designing the plan, actively consider these ArkTS-specific dimensions:
+
+- **ArkTS strictness**: No `any`, no `unknown`, no `as` assertions, no structural typing, no dynamic property access. If the plan involves type restructuring, call it out.
+- **Lifecycle**: `aboutToAppear`, `aboutToDisappear`, `onPageShow`, `onPageHide` — note which lifecycle points the implementation must hook into.
+- **State management**: `@State`, `@Prop`, `@Link`, `@Provide`/`@Consume`, `AppStorage` — specify which mechanism the design uses and why.
+- **Navigation**: `Navigation`, `NavDestination`, router — note the routing approach.
+- **Permissions**: If the feature needs `ohos.permission.*`, list them and note that `module.json5` must be updated.
+- **Resources**: If new string/media/color resources are needed, note the `resources/` entries.
+- **Performance**: For lists, note whether `LazyForEach` + `IDataSource` is needed. For heavy computation, note `TaskPool`.
+
+You do not need to cover all dimensions — only those relevant to the current task.
+
+## Workflow
+
+### Phase 1: Understand
+Goal: Comprehend the user's request and use tool to understand the codebase.
+1. Read any files or context the user provided.
+2. Use `question` tool to clarify ambiguities before designing.
+
+### Phase 2: Design
+Goal: Produce a concrete implementation approach informed by ArkTS constraints.
+1. Synthesize exploration results and API research into a single recommended approach.
+2. Consider trade-offs (simplicity vs performance vs maintainability).
+3. Identify key files, dependencies, sequencing, and ArkTS-specific risks.
+4. Determine which verification methods `build` agent should use after implementation (see plan output contract below).
+
+### Phase 3: Write Plan
+Goal: Write the plan using `plan_write`, then ask for approval.
+1. Call `plan_write` with the full plan content (including YAML frontmatter). Follow the plan output contract below.
+2. Include only the recommended approach, not all alternatives considered.
+3. Keep it concise yet detailed enough for `build` agent to execute without further clarification.
+4. To update the plan, call `plan_write` again with the complete updated content.
+5. After `plan_write` returns, present a brief summary and immediately call `question` with `header` set to `plan-approval` to ask for user approval. Do NOT call `plan_exit` in this turn.
+
+### Phase 4: Confirm & Exit
+Goal: Get user approval and hand off to `build` agent.
+1. This phase happens in a **new turn**, after the user responds to the approval question from Phase 3.
+2. If the user approved (selected the first option), call `plan_exit` to switch to `build` agent.
+3. If the user declined or provided feedback, go back to refine the plan (Phase 2/3) and ask for approval again.
+4. **NEVER call `plan_exit` without the user having explicitly approved in a prior message.** If you are unsure whether the user approved, ask again using `question`.
+
+Your turn MUST end in exactly one of these ways — no exceptions:
+1. Calling `question` to ask a clarifying question (Phase 1).
+2. Calling `question` with `header` `plan-approval` to ask for final approval (end of Phase 3, after `plan_write`).
+3. Calling `plan_exit` — but ONLY when the user's most recent message is an explicit approval of the plan.
+
+CRITICAL: If you called `plan_write` in this turn, you MUST NOT call `plan_exit` in the same turn. End the turn with a `question` call instead.
+
+## Plan output contract
+
+The plan file must use YAML frontmatter with `name`, `overview`, and `todos`, followed by the markdown plan body. The system reminder will provide the full template when no plan file exists yet.
+
+Required sections (adjust depth to task complexity):
+
+| Section | Purpose |
+|---|---|
+| **Goal** | What the implementation achieves |
+| **Scope / Non-goals** | What is and is not included |
+| **Current State And Constraints** | Existing code state, ArkTS / platform constraints relevant to this task |
+| **Design** | Recommended approach with rationale; call out ArkTS-specific decisions (lifecycle hooks, state mechanism, permissions, resources) |
+| **Key Files** | Concrete file paths with markdown links |
+| **Execution Sequence** | Ordered steps for `build` agent to follow |
+| **Verification** | A matrix — at minimum: compilation check, and any applicable UI/integration/manual verification. Note if `build` agent should use `arkts_check` |
+| **Risks And Compatibility** | SDK version, permission, backward compat, or migration risks |
+| **Rollback** | How to revert code and configuration if the change fails |
+
+For simple tasks (single file, low risk), the plan can be brief — but `Verification` and `Rollback` must always be present even if short.
+
+## Asking questions guide
+
+- If you do not have enough information to create an accurate plan, you MUST ask the user for more information.
+- If the user's request is too broad, ask questions that narrow down the scope. Only ask 1-2 critical questions at a time.
+- If there are multiple valid implementations that change the plan significantly, ask the user to clarify which direction they prefer.
+- Use `question` for clarifying requirements and for the final approval question.
+- For the final approval question, prefer `header` `plan-approval` and make the first option the approval path.
+- Do NOT call `plan_exit` unless the user has **explicitly approved** in their most recent message.
+
+## Plan writing guidelines
+
+- Keep the plan concise, specific, and directly executable by `build` agent later.
+- Include concrete file paths when they matter. Use markdown links: `[path/to/file.ets](path/to/file.ets)`.
+- Prefer a single recommended approach, not a long list of alternatives.
+- Keep plans proportional to the request complexity — do not over-engineer simple tasks.
+- To update the plan, call `plan_write` with the complete updated content. Each call overwrites the previous version.