@co0ontty/wand 4.57.0 → 4.58.0

package/vendor/codex-taskboard/shared/taskboard-automation.mjs

@@ -1,277 +0,0 @@
-import path from "node:path";
-import { fileURLToPath } from "node:url";
-
-const taskctlCliPath = fileURLToPath(new URL("../cli/taskctl.mjs", import.meta.url));
-
-const AUTOMATION_OPERATIONS = new Set(["ensure-active", "pause", "list", "apply-policy"]);
-const INTERVAL_MINUTES = new Set([5, 10, 15, 30, 60]);
-const HOST_REQUEST_FIELDS = new Set([
-  "id",
-  "action",
-  "requestId",
-  "operation",
-  "taskboardProjectId",
-  "codexProjectId",
-  "codexProjectKind",
-  "codexHostId",
-  "projectName",
-  "workspacePath",
-  "remoteProjects",
-  "skillPath",
-  "automationId",
-  "enabledByUser",
-  "quotaAware",
-  "intervalMinutes",
-  "model",
-  "reasoningEffort",
-]);
-
-export function parseTaskboardAutomationHostRequest(value) {
-  if (!value || typeof value !== "object" || Array.isArray(value)) return null;
-  if (Object.keys(value).some((field) => !HOST_REQUEST_FIELDS.has(field))) return null;
-  if (value.action !== "automation") return null;
-  if (!validIdentifier(value.id, 80) || !validIdentifier(value.requestId, 100)) return null;
-  if (!AUTOMATION_OPERATIONS.has(value.operation)) return null;
-  if (!validProjectId(value.taskboardProjectId)) return null;
-  if (!validText(value.codexProjectId, 256) || !validText(value.projectName, 200)) return null;
-  const codexProjectKind = value.codexProjectKind ?? "local";
-  const codexHostId = value.codexHostId ?? "local";
-  if (codexProjectKind !== "local" && codexProjectKind !== "remote") return null;
-  if (!validText(codexHostId, 256)) return null;
-  if (codexProjectKind === "local" && codexHostId !== "local") return null;
-  if (codexProjectKind === "remote" && codexHostId === "local") return null;
-  if (!validAbsolutePath(value.workspacePath) || !validAbsolutePath(value.skillPath)) return null;
-  const remoteProjects = value.remoteProjects === undefined ? [] : value.remoteProjects;
-  if (
-    !Array.isArray(remoteProjects)
-    || remoteProjects.some((project) => (
-      !project
-      || typeof project !== "object"
-      || Array.isArray(project)
-      || Object.keys(project).some((field) => ![
-        "codexProjectId",
-        "codexProjectKind",
-        "codexHostId",
-        "workspacePath",
-      ].includes(field))
-      || !validText(project.codexProjectId, 256)
-      || project.codexProjectKind !== "remote"
-      || project.codexHostId !== codexHostId
-      || !validAbsolutePath(project.workspacePath)
-    ))
-    || (codexProjectKind === "local" && remoteProjects.length > 0)
-  ) return null;
-  if (!INTERVAL_MINUTES.has(value.intervalMinutes)) return null;
-  if (!validText(value.model, 256) || !validText(value.reasoningEffort, 100)) return null;
-  if (value.automationId !== undefined && !validText(value.automationId, 256)) return null;
-  if (typeof value.enabledByUser !== "boolean" || typeof value.quotaAware !== "boolean") return null;
-
-  return {
-    id: value.id,
-    action: "automation",
-    requestId: value.requestId,
-    operation: value.operation,
-    taskboardProjectId: value.taskboardProjectId,
-    codexProjectId: value.codexProjectId,
-    codexProjectKind,
-    codexHostId,
-    projectName: value.projectName,
-    workspacePath: value.workspacePath,
-    ...(value.remoteProjects === undefined ? {} : { remoteProjects }),
-    skillPath: value.skillPath,
-    ...(value.automationId === undefined ? {} : { automationId: value.automationId }),
-    enabledByUser: value.enabledByUser,
-    quotaAware: value.quotaAware,
-    intervalMinutes: value.intervalMinutes,
-    model: value.model,
-    reasoningEffort: value.reasoningEffort,
-  };
-}
-
-export function buildTaskboardAutomationName(request) {
-  return `Taskboard 自动认领 · ${request.taskboardProjectId}`;
-}
-
-export function buildTaskboardAutomationPrompt(request) {
-  const taskctlCommand = buildTaskctlCommand(request);
-  const remoteProject = request.codexProjectKind === "remote";
-  const remoteProjects = request.remoteProjects ?? [];
-  const candidateInstructions = [
-    "从返回的 todo 中只选择依赖已完成的议题：relations.blockedBy 为空，或其中每个依赖的 status 都严格等于 done。无依赖的 todo 仍可并行处理。若有 todo 但全部被未完成依赖阻塞，本轮直接结束，不暂停自动化，也不创建或打开新的任务会话。",
-    "每次仅处理一个符合依赖条件的 todo：选定后先用 issue get 读取最新议题内容，并用 comment list 读取全部评论。根据描述和最新评论判断是否允许开始；若其中写明等待、暂不执行或当前不应开始，立即跳过并报告，不改状态。评论也包含已完成后被打回的返工要求。",
-    "完成 issue get 和 comment list 后、移动状态前，必须再次运行 issue get，并复核 relations.blockedBy 仍为空或其中每个依赖的 status 都严格等于 done。若依赖条件不再满足，立即跳过并结束本轮，不改状态，也不暂停自动化。",
-  ];
-  const executionInstructions = remoteProject
-    ? [
-        `本自动化仅在本机作为任务面板控制器运行；实际开发必须派发到 Codex SSH 远程项目。导入项目的基础 identity 是 projectId=${JSON.stringify(request.codexProjectId)}、hostId=${JSON.stringify(request.codexHostId)}、workspacePath=${JSON.stringify(request.workspacePath)}；同一保存主机当前可用的精确远程项目映射是 ${JSON.stringify(remoteProjects)}。不要在当前本地自动化会话修改项目文件。`,
-        ...candidateInstructions,
-        "先检查 issue get 的 projectId、version、status、archivedAt、threadId 和 threadBinding。完整 threadBinding 包含 threadId、codexProjectId、codexProjectKind、codexHostId、workspacePath，且它是该议题后续 send、wait 和状态写回的唯一目标；当前自动化的项目和主机只能作为未绑定议题的首次目标，不能替换已有绑定。若存在 threadId 但没有完整 threadBinding，这是只能由 UI 打开的 legacy local 绑定：使用 comment add 说明自动化无法确认项目和主机，再使用首次读取的 version 作为 --if-version、用 --binding-thread-id 保留原 threadId 将议题移动到 blocked；若冲突立即停止。不得 send、create 或覆盖该绑定。",
-        `未绑定议题必须先从上述精确远程项目映射解析 actualTarget。若 developmentContext.type 是 worktree，只保留 codexProjectKind="remote"、codexHostId=${JSON.stringify(request.codexHostId)} 且 workspacePath 与 developmentContext.path 完全相同的项；必须恰好命中一项，并使用该项自己的 codexProjectId、codexHostId 和 workspacePath。零项或多项时使用 comment add 明确记录“目标 SSH worktree 未映射”，随后结束本轮，不认领、不 create、不写基础项目 binding。若没有 worktree，actualTarget 才是上述基础 identity，并且它必须存在于精确映射中。不得回退到基础 root、local、项目名、其他主机或同路径的其他主机。`,
-        "确认允许开始后，只有未绑定且仍为未归档 todo 的议题才可在读取代码、下载附件、分析或实施前，由当前本地控制器使用刚读取的 version 移到 in_progress。已有完整 threadBinding 时，issue move 必须同时传 --binding-thread-id、--binding-codex-project-id、--binding-codex-project-kind、--binding-codex-host-id、--binding-workspace-path 的保存值，但在旧会话 send/stale 判断完成前不得把这个 todo 移到 in_progress；stale 清除步骤按后文显式使用 --clear-binding-thread。未绑定时必须传 --clear-binding-thread，避免把本地控制器 CODEX_THREAD_ID 写成任务绑定。写入成功后记录响应 task 的 version 为 ownedVersion、projectId 为 ownedProjectId，并记录本轮 binding；以后本轮每次 issue move 都必须显式传 --if-version ownedVersion，成功后再用响应 version 更新 ownedVersion。不得省略 --if-version 后让 taskctl 自动读取最新 version。写入成功前不得继续。所有认领、评论和状态写入只由当前本地控制器完成，不得要求远程会话运行 taskctl。",
-        "若因 version 陈旧发生版本冲突，重新运行 issue get 和 comment list；仅当仍为可认领 todo、绑定身份未变化、未归档且描述和最新评论未变化时，用最新 version 重试一次。若已被认领、绑定、状态或要求已变、已归档、服务或永久 API 错误，或重试仍失败，立即跳过该议题、退出并报告；不得抢占或循环重试。",
-        "认领成功后，已有完整 threadBinding 时，只能使用其保存的 threadId 和 codexHostId 调用 Codex send_message_to_thread。send 成功后必须重新 issue get 一次，确认 projectId 未变、未归档、status 仍为 todo 且完整 threadBinding 与保存值完全相同；然后由当前本地控制器使用这次复核返回的最新 version、完整旧 binding 和 --if-version 执行 issue move --status in_progress，传入 --binding-thread-id、--binding-codex-project-id、--binding-codex-project-kind、--binding-codex-host-id、--binding-workspace-path，并记录响应 task.version 为 ownedVersion。认领成功后继续执行后文现有 Codex wait_threads、结果评论和 in_review 写回路径，不得结束本轮；若认领发生 409，立即停止，不得重读新 version 覆盖。只有旧会话工具明确返回终态 NOT_FOUND 或 CLOSED 等会话不存在或已关闭结果时，才确认 stale。timeout、network failure、Codex host 暂时不可达或 Taskboard service unavailable 都不是 stale：保留 binding 并结束本轮，不得猜测、clear、create 或抢占。若任务已是 in_progress、活跃、已归档、状态或 binding 已变化，立即停止，不得在当前自动化目标创建替代会话。只有未绑定议题才使用 Codex create_thread 创建远程任务，target 必须是 {type:\"project\",projectId:actualTarget.codexProjectId,environment:{type:\"local\"}}，首次 identity 必须使用 actualTarget 的 projectId、kind=\"remote\"、hostId 和 workspacePath。发送给远程会话的指令必须包含议题编号、标题、完整描述、全部评论和开发上下文，并说明远程会话不运行 taskctl，只需完成实现、验证并返回改动、结果和剩余风险。",
-        "确认旧会话 stale 后，必须先用 comment add 保存一条历史记录，并同时传 --thread-id、--binding-thread-id、--binding-codex-project-id、--binding-codex-project-kind、--binding-codex-host-id 和 --binding-workspace-path 的完整旧 binding；评论写入成功后，再使用同一次 issue get 的 version 执行 issue move --status todo --clear-binding-thread --if-version。评论或清除失败立即停止，不得认领。然后只重新 issue get 一次；仅当 projectId 未变、未归档、status 仍为 todo、threadId 为空且 threadBinding 为空时，才进入未绑定议题的现有认领和 create_thread 路径。",
-        "仅当 send_message_to_thread 成功，或 create_thread 成功返回远程 threadId，才视为远程 worker 已确认。未绑定议题在 create_thread 失败时，使用 comment add 记录失败工具和错误；随后用 ownedVersion、显式 --if-version 和 --clear-binding-thread 将当前议题移回 todo 并结束。若发生 409，说明其他控制端已修改任务，立即停止且不得重读最新 version 后覆盖。此补偿只处理本轮当前已认领议题；不得扫描或接管其他 in_progress。",
-        "新建远程任务成功后，使用 ownedVersion 和显式 --if-version 再次移动到 in_progress；必须用完整 binding 参数保存 create_thread 返回的 threadId，以及 actualTarget 的 projectId、kind=\"remote\"、hostId 和 workspacePath。成功后用响应 version 更新 ownedVersion 和本轮 binding。若请求响应丢失或结果不确定，只允许重新 issue get 一次；仅当 projectId 等于 ownedProjectId、未归档、状态仍为本轮 in_progress，且 threadBinding 为空或与本轮五字段 binding 完全相同时才可继续。读到相同 binding 视为前次保存成功；读到空 binding 时才可用本次核对后的 version 重试一次；读到不同 binding 或任一其他核对项变化时立即退出，不得写回。若确定绑定写入失败，使用 comment add 记录失败和远程 threadId，再用 ownedVersion、显式 --if-version 和同一完整 binding 将议题移动到 blocked；409 时停止且不得重复派发。",
-        "使用 Codex wait_threads 等待远程会话时，目标必须使用任务保存的 threadBinding.threadId 和 threadBinding.codexHostId。wait_threads 失败、远程会话明确需要用户输入或无法继续时，使用 comment add 记录原因，再用 ownedVersion、显式 --if-version 和完整保存 binding 将议题移动到 blocked；409 时立即停止。远程会话完成后，使用 comment add 写入改动、验证结果、执行结果和剩余风险，再用 ownedVersion、显式 --if-version 和完整保存 binding 将议题移动到 in_review。worker 确认后的每一次 issue move 都必须显式传完整远程 binding；不要把未完成工作标记为 in_review。",
-      ]
-    : [
-        ...candidateInstructions,
-        `确认允许开始后，只有 threadId 和 threadBinding 都为空且仍为未归档 todo 的议题才可在读取代码、下载附件、分析或实施前认领。认领必须使用刚读取的 version 移到 in_progress，并显式传 --binding-thread-id "$CODEX_THREAD_ID"、--binding-codex-project-id ${JSON.stringify(request.codexProjectId)}、--binding-codex-project-kind "local"、--binding-codex-host-id ${JSON.stringify(request.codexHostId)}、--binding-workspace-path ${JSON.stringify(request.workspacePath)}，把当前自动化会话一次写成完整 binding；记录响应 task.version 为 ownedVersion。写入成功前不得继续。已有完整 binding 或 legacy local binding 的议题必须先按旧会话规则处理，不得先认领；不得认领已被其他会话绑定或其他 Agent 领取的议题。认领后的每一次 issue move 都必须显式传 ownedVersion 和这五个完整 binding 字段，成功后更新 ownedVersion。`,
-        "若因 version 陈旧发生版本冲突，重新运行 issue get 和 comment list；仅当仍为可认领 todo、未绑定其他会话、未归档且描述和最新评论未变化时，用最新 version 重试一次。若已被认领、状态或要求已变、已归档、服务或永久 API 错误，或重试仍失败，立即跳过该议题、退出并报告；不得抢占或循环重试。",
-        `若首次 issue get 返回完整 threadBinding，议题已绑定原会话：不要在当前自动化会话认领；只能使用保存的 threadId 和 codexHostId 调用 Codex send_message_to_thread。send 成功时保留 binding 并结束本轮；只有工具明确返回终态 NOT_FOUND 或 CLOSED 等会话不存在或已关闭结果时才确认 stale。timeout、network failure、Codex host 暂时不可达或 Taskboard service unavailable 都保留 binding 并结束本轮，不得猜测 stale。确认 stale 后，先用 comment add 同时传 --thread-id 和完整旧 binding 保存历史，再用同一次 issue get 的 version 执行 issue move --status todo --clear-binding-thread --if-version；然后只重新 issue get 一次，仍为未归档 todo 且 threadId、threadBinding 都为空时，才在当前自动化会话处理。若任务已是 in_progress、活跃、已归档、状态或 binding 已变化，或发生 409，立即停止，不得抢占。若返回 threadId 但没有完整 threadBinding，这是 legacy local 绑定：先调用 Codex list_threads（limit=50），合并 pinnedThreads 与 threads，并按完整 threadId 精确查找。只有恰好一项 kind="codex"、projectId=${JSON.stringify(request.codexProjectId)}、hostId=${JSON.stringify(request.codexHostId)}、cwd=${JSON.stringify(request.workspacePath)} 全部一致时，才把该项视为可核验旧会话；使用最新 issue version 执行 issue move --status todo --if-version，并显式传旧 threadId 及上述 projectId、kind="local"、hostId、workspacePath 五字段，将 legacy local 原位升级为完整 binding。升级成功后只向该旧 threadId 和 hostId 调用 send_message_to_thread，随后结束本轮，由旧会话按议题最新要求继续。若 list_threads 未找到、出现多项或任一字段不一致，不得迁移或发送；使用 comment add 记录实际不一致项，再用首次读取的 version 和 --if-version、--binding-thread-id 保留原 threadId 将议题移到 blocked。若升级发生 409，立即停止，不得用新 version 覆盖。若没有 threadId，则按未绑定议题处理。`,
-        "若议题已绑定 branch 或 worktree，必须在该议题绑定的开发上下文执行，避免并行 Agent 修改同一工作目录。",
-        "执行完成并验证后，先用 comment add 记录关键改动、验证结果、执行结果和剩余风险，再使用 ownedVersion、显式 --if-version 和认领时保存的完整 binding 将议题移动到 in_review；成功后更新 ownedVersion。不要省略 binding，避免把完整绑定降级为 legacy local；不要直接标记为 done。",
-      ];
-  return [
-    `[$manage-taskboard](${request.skillPath}) e-taskboard 每 ${request.intervalMinutes} 分钟检查任务面板中的「${request.projectName}」项目（项目 ID：${request.taskboardProjectId}，项目目录：${request.workspacePath}）。`,
-    `本轮所有 taskctl 操作都使用完整命令前缀 ${taskctlCommand}，不要使用 PATH 中的 taskctl。`,
-    `开始时先运行 ${taskctlCommand} issue list --project ${request.taskboardProjectId} --status todo --json。若没有 todo，直接结束；Taskboard 主机侧会暂停当前自动化，不要创建或打开新的任务会话。`,
-    ...executionInstructions,
-    `本次处理或交接后，再次运行 ${taskctlCommand} issue list --project ${request.taskboardProjectId} --status todo --json。若没有 todo，直接结束；Taskboard 主机侧会暂停当前自动化，避免后续创建空会话。`,
-  ].join("\n");
-}
-
-function buildTaskctlCommand(request) {
-  const command = `${shellQuote(process.execPath)} ${shellQuote(taskctlCliPath)}`;
-  const runtimeFilePath = process.env.CODEX_TASKBOARD_RUNTIME_FILE;
-  return runtimeFilePath
-    ? `${command} --runtime-file ${shellQuote(runtimeFilePath)}`
-    : command;
-}
-
-function shellQuote(value) {
-  return `'${value.replaceAll("'", "'\\''")}'`;
-}
-
-export function buildTaskboardAutomationSpec(request) {
-  return {
-    kind: "cron",
-    name: buildTaskboardAutomationName(request),
-    prompt: buildTaskboardAutomationPrompt(request),
-    projectId: request.codexProjectKind === "remote" ? null : request.codexProjectId,
-    executionEnvironment: "local",
-    localEnvironmentConfigPath: null,
-    model: request.model,
-    reasoningEffort: request.reasoningEffort,
-    rrule: `RRULE:FREQ=MINUTELY;INTERVAL=${request.intervalMinutes}`,
-  };
-}
-
-export function taskboardAutomationPolicyOperation(request, {
-  explicit,
-  hasTodo,
-  previousQuotaState,
-  quotaState,
-  currentStatus,
-}) {
-  if (!request.enabledByUser) return "pause";
-  if (hasTodo === false) return "pause";
-  if (
-    !explicit
-    && currentStatus === "PAUSED"
-    && (!request.quotaAware || previousQuotaState === "available")
-  ) return "list";
-  if (request.quotaAware && quotaState !== "available") return "pause";
-  return "ensure-active";
-}
-
-export async function reconcileTaskboardAutomation(request, rpc) {
-  const listed = await rpc("list-automations", {});
-  const items = Array.isArray(listed?.items) ? listed.items : [];
-  const name = buildTaskboardAutomationName(request);
-  const matchingItems = items.filter((item) => item?.name === name);
-
-  if (request.operation === "list") {
-    return { items: matchingItems.map(sanitizeAutomation).filter(Boolean) };
-  }
-
-  const existing = (
-    request.automationId
-      ? matchingItems.find((item) => item?.id === request.automationId)
-      : null
-  ) ?? matchingItems[0];
-  const spec = buildTaskboardAutomationSpec(request);
-
-  if (request.operation === "pause") {
-    if (!existing) return { error: "not-found" };
-    if (automationMatchesSpec(existing, spec, "PAUSED")) return { item: existing };
-    return rpc("automation-update", { ...spec, id: existing.id, status: "PAUSED" });
-  }
-
-  if (request.operation !== "ensure-active") {
-    throw new Error(`Unsupported automation operation: ${request.operation}`);
-  }
-  if (existing) {
-    if (automationMatchesSpec(existing, spec, "ACTIVE")) return { item: existing };
-    return rpc("automation-update", {
-      ...spec,
-      id: existing.id,
-      status: "ACTIVE",
-    });
-  }
-  return rpc("automation-create", spec);
-}
-
-function sanitizeAutomation(item) {
-  if (
-    !validText(item?.id, 256)
-    || (item.status !== "ACTIVE" && item.status !== "PAUSED")
-    || !validText(item.model, 256)
-    || !validText(item.reasoningEffort, 100)
-    || !validRrule(item.rrule)
-  ) return null;
-  return {
-    id: item.id,
-    status: item.status,
-    model: item.model,
-    reasoningEffort: item.reasoningEffort,
-    rrule: item.rrule,
-    ...(
-      item.nextRunAt === null || Number.isFinite(item.nextRunAt)
-        ? { nextRunAt: item.nextRunAt }
-        : {}
-    ),
-  };
-}
-
-function validRrule(value) {
-  return typeof value === "string"
-    && /^RRULE:FREQ=MINUTELY;INTERVAL=(5|10|15|30|60)$/.test(value);
-}
-
-function automationMatchesSpec(item, spec, status) {
-  return item?.status === status
-    && Object.entries(spec).every(([field, value]) => (
-      field === "projectId"
-        ? (item.projectId ?? item.target?.projectId ?? null) === value
-        : item[field] === value
-    ));
-}
-
-function validIdentifier(value, maxLength) {
-  return typeof value === "string"
-    && value.length > 0
-    && value.length <= maxLength
-    && /^[a-z0-9-]+$/i.test(value);
-}
-
-function validProjectId(value) {
-  return typeof value === "string"
-    && value.length > 0
-    && value.length <= 128
-    && /^[a-z0-9._-]+$/i.test(value);
-}
-
-function validText(value, maxLength) {
-  return typeof value === "string"
-    && value.trim() === value
-    && value.length > 0
-    && value.length <= maxLength
-    && !/[\u0000-\u001f\u007f]/.test(value);
-}
-
-function validAbsolutePath(value) {
-  return validText(value, 2_048)
-    && (path.posix.isAbsolute(value) || path.win32.isAbsolute(value));
-}

package/vendor/codex-taskboard/skills/manage-taskboard/SKILL.md

@@ -1,45 +0,0 @@
----
-name: manage-taskboard
-description: Manage Codex Taskboard / e-taskboard work with taskctl. Use for taskboard issue IDs, status sync, comments, or taskctl cloud setup—not for unrelated product docs.
----
-
-# Manage Taskboard
-
-Use `taskctl` for every project, issue, relation, and comment operation. Consume its JSON output. Use the exact issue identifier returned by the taskboard or supplied in the prompt. Never assume, derive, or rewrite an identifier prefix.
-
-Open only the relevant section of [references/cli.md](references/cli.md) when command syntax is needed.
-
-## Select the CLI and active service
-
-- Use the exact `taskctl` binary and Taskboard URL supplied by the task or injected runtime. Do not replace them with a global CLI, the default port, or another board.
-- On macOS, when no binary is injected and the desktop app is installed, use `'/Applications/Codex Taskboard.app/Contents/Resources/bin/taskctl' issue get ID --json`. Keep the single quotes because the path contains a space. The packaged wrapper reads the active launcher runtime; do not search the filesystem for another CLI or reconstruct the tokenized URL.
-- On Linux, when no binary is injected and Codex was started by the desktop app, use `taskctl issue get ID --json`. The desktop app adds its packaged wrapper to the managed Codex `PATH`; do not search the filesystem for another CLI or reconstruct the tokenized URL.
-- If that exact command reaches a sandbox restriction on the loopback service, retry the same command with the required permission. Do not switch binaries or endpoints.
-
-## Terminology: local companion
-
-In this product, **companion** means the **device-local loopback service** used for cloud mode (Codex/Git/Skill/MCP, path mapping, Basic Auth proxy). Related names: `local companion`, `loopback companion`, `CODEX_TASKBOARD_COMPANION_URL`, `cloud-companion.json`, `LOCAL_COMPANION_REQUIRED`.
-
-When writing Chinese, keep the English word or use **本地 companion** / **本地配套服务** / **环回代理**. Never translate as **伴侣** or invent **伴侣 API**. Ordinary task/comment/attachment HTTP routes (`/api/tasks`, `/api/comments`, `/api/attachments`, …) are the **Taskboard HTTP API** (or local server API)—not “companion API”.
-
-## Core workflow
-
-1. For an existing issue, first run `issue get` and `comment list`. Also run `attachment list --task`. On the first handoff, omit `--after` and read the full results. Keep the separate `nextCursor` from each list. When the same task resumes, run `issue get` again, then pass each saved cursor to its matching list with `--after` so only new or modified entries are returned. Comment lists include the attachments on returned comments; use `attachment list --comment` with its own cursor when a known comment attachment list can grow. Read the description and latest comments before deciding whether to start. Treat comments as current requirements, including returned work. If they say to wait, not execute, or not start now, stop and report without changing the status.
-2. Treat `backlog` as not approved for execution. Unless the user explicitly authorizes that issue, do not claim it, move it to another status, or perform task work; its assignee alone is not authorization. If work may start, claim it before reading code, downloading attachments, analyzing the implementation, or doing any other task work. Move a claimable `todo` to `in_progress` with its current `version`; do not continue until the move succeeds. If it is already `in_progress`, continue only when it is bound to the current conversation. Never move an issue claimed by another conversation.
-3. If the move conflicts because the `version` is stale, run `issue get` and `comment list` again. Retry once with the latest `version` only when the issue is still a claimable `todo`, is not bound to another conversation, is not archived, and its description and latest comments are unchanged. If it was claimed, its status or requirements changed, it is archived, the service is unavailable, a permanent API error occurs, or the retry fails, stop and report. Never loop or take over another agent's claim.
-4. For a new durable requirement, run `context current`. Treat its project as a workspace match only when `project.workspacePath` is the current directory or one of its ancestors. An unmatched `local` project is the documented fallback, not proof that the requirement belongs in the global project. If the user named a target project or the working directory identifies one, run `project list`, select that exact project by id or name, and stop to ask if the result is ambiguous. Search existing project issues before creating one in that confirmed project, then pass its explicit id to `issue create`. Update a matching issue instead of creating a duplicate. Use the fallback only when the user explicitly wants the global project. Do not track trivial requests.
-5. Execute only the requested work in the issue's branch or worktree when one is bound.
-6. Verify the requested operation path. Add a comment with the changes, verification result, outcome, and remaining risks. Read the issue again, then move it to `in_review` with its current `version`.
-7. Move an issue to `done` only after the user explicitly accepts it or asks to complete it. Use `blocked` when work cannot continue and `canceled` when it will not continue.
-
-## Other operations
-
-- Run `taskctl project readme get [PROJECT_ID]` to inspect project architecture, constraints, and conventions before planning or executing complex tasks.
-- Keep the project README focused on root overview and conventions; store detailed multi-page documentation in the local repository's `docs/` folder.
-- Preserve existing issue scope when adding requirements or acceptance details.
-- Add only relations that the work requires. Use parent for contained work, blocks or blocked_by for dependencies, and related for close association.
-- Let `taskctl` read `CODEX_THREAD_ID` for controller attribution. Outside Codex, pass the exact conversation ID with `--thread-id`. This value alone is not a complete task binding.
-- Any issue that the current conversation claims or continues must store a complete `threadBinding`: `threadId`, `codexProjectId`, `codexProjectKind`, `codexHostId`, and `workspacePath`. For an unbound local issue launched with injected Taskboard context, use the current `CODEX_THREAD_ID`, the injected project id and workspace path, `local` project kind, and `local` host id. Pass all five explicit `--binding-*` options on the claim and every later `issue move` that retains ownership. If any identity field is unavailable, stop before moving the issue to `in_progress`; never create a legacy binding containing only `threadId`.
-- When an issue already has a complete `threadBinding`, preserve its exact five saved values on every status write. Do not rebuild or replace it from the current context, and never take over a binding owned by another conversation.
-- Use the latest returned `version` with `--if-version` for concurrent updates. On conflict, read the issue again and reconcile before retrying.
-- Download and inspect an inline `![alt](api/attachments/<id>/content)` image only when it is needed to understand the requirement.

package/vendor/codex-taskboard/skills/manage-taskboard/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Manage Taskboard"
-  short_description: "Manage projects and issues with taskctl CLI"
-  default_prompt: "Manage the referenced taskboard issue with taskctl and keep its status synchronized."

package/vendor/codex-taskboard/skills/manage-taskboard/references/cli.md

@@ -1,211 +0,0 @@
-# taskctl CLI
-
-`taskctl` emits JSON for normal commands. Add `--json` when making the output contract explicit. Built-in help is the only successful stdout exception: it writes plain text, exits with code `0`, and does not request the Taskboard service.
-
-Use built-in help for the current command tree or a specific supported level:
-
-```bash
-taskctl --help
-taskctl issue --help
-taskctl comment list --help
-```
-
-## Terminology: local companion
-
-**Companion** here is a product term for the **device-local loopback HTTP service** that `taskctl` talks to in cloud mode. It applies Basic Authentication, stores device-only project path mappings, and keeps Codex/Git/Skill/MCP capabilities on the machine. It is not a chat persona and not a separate public “companion product API”.
-
-| English | Prefer in Chinese | Do not use |
-| --- | --- | --- |
-| local companion / loopback companion | 本地 companion、本地配套服务、环回代理 | 伴侣、伴侣 API |
-| Taskboard HTTP API (`/api/tasks`, `/api/comments`, `/api/attachments`, …) | Taskboard HTTP API、本地服务 API、附件上传接口 | companion API、伴侣 API |
-
-Env and files that refer to this service: `CODEX_TASKBOARD_COMPANION_URL`, `CODEX_TASKBOARD_URL` (loopback origin), `.data/cloud-companion.json`. Error code `LOCAL_COMPANION_REQUIRED` means a capability needs that **local loopback service**, not a different API surface.
-
-## Context and projects
-
-```bash
-taskctl context current [--cwd PATH] [--json]
-taskctl project list [--json]
-taskctl project create --name NAME [--id ID] [--workspace-path PATH] [--json]
-taskctl project map PROJECT_ID --workspace-path PATH [--json]
-taskctl project readme get [PROJECT_ID] [--json]
-taskctl project readme set [PROJECT_ID] (--content TEXT | --file PATH) [--if-version N] [--json]
-```
-
-Use `--workspace-path` to associate a project with a local repository. `context current` chooses the most specific project whose workspace contains the current directory, then falls back to the `local` project.
-
-Use `project readme get` and `project readme set` to read and update the project's single root README document. Detailed multi-page documentation belongs in the project's local `docs/` folder.
-
-Set `CODEX_TASKBOARD_URL` to override the default local API origin, `http://127.0.0.1:47823`.
-
-For a shared cloud board, keep `taskctl` pointed at the **loopback companion** (local loopback service; see Terminology above) and configure the upstream HTTPS origin through it:
-
-```bash
-taskctl cloud login --url HTTPS_ORIGIN --actor-name NAME [--json]
-taskctl cloud status [--json]
-taskctl project list [--json]
-taskctl project map PROJECT_ID --workspace-path /absolute/local/path [--json]
-taskctl cloud logout [--json]
-```
-
-`cloud login` reads the shared password from a private `Shared key:` prompt. The actor name is the display attribution sent through Basic Authentication. The local companion stores its configuration with mode `0600`; project mappings stay on the current device and can differ between collaborators. In cloud mode, failed upstream writes fail rather than falling back to or double-writing the local SQLite database.
-
-Every issue or comment write must be attributed to a Codex conversation. In Codex, `taskctl` reads the current conversation from `CODEX_THREAD_ID`. Outside Codex, pass `--thread-id ID` explicitly. An explicit option takes precedence over the environment. Read commands do not require a conversation id.
-
-Except for built-in help, every successful command writes one JSON object with `schemaVersion` to stdout. The current schema version is `2`. Errors write one JSON object to stderr. Exit codes are `0` for success, `2` for invalid input, `3` when the service is unavailable, `4` for API or response errors, and `5` for conflicts.
-
-## Read issues
-
-```bash
-taskctl issue list [--project PROJECT_ID] [--status STATUS] [--archived true|false|all] [--json]
-taskctl issue get ID [--json]
-taskctl issue tree ID --direction descendants|ancestors --depth N [--json]
-```
-
-`issue tree` is a bounded structural read. `--depth 1` returns only direct children or the direct parent; larger values include that many levels, up to 25. The response is flat and deterministic: every node carries `id`, traversal `parentId`, `depth`, and `path` (usable as a breadcrumb), plus a small task summary. It never calculates status rollups or changes issues.
-
-## Create issues
-
-```bash
-taskctl issue create \
-  --project PROJECT_ID \
-  --title TITLE \
-  [--description TEXT | --description-file FILE] \
-  [--status STATUS] \
-  [--priority PRIORITY] \
-  [--labels a,b] \
-  [--thread-id ID] \
-  [--git-branch BRANCH] \
-  [--worktree-path PATH] \
-  [--worktree-branch BRANCH] \
-  [--start-date YYYY-MM-DD] \
-  [--due-date YYYY-MM-DD] \
-  [--recurrence-interval N --recurrence-unit day|week|month|year] \
-  [--json]
-```
-
-Statuses are `backlog`, `todo`, `in_progress`, `in_review`, `blocked`, `done`, and `canceled`. Priorities are `none`, `urgent`, `high`, `medium`, and `low`.
-
-Issues created through `taskctl` are assigned to Codex Agent by default. Other CLI writes preserve the existing assignee.
-
-## Update issues
-
-Read the issue immediately before a write and pass its `version` with `--if-version`.
-
-```bash
-taskctl issue update ID \
-  [--project PROJECT_ID] \
-  [--title TITLE] \
-  [--description TEXT | --description-file FILE] \
-  [--status STATUS] \
-  [--priority PRIORITY] \
-  [--labels a,b] \
-  [--thread-id ID] \
-  [--git-branch BRANCH] \
-  [--worktree-path PATH] \
-  [--worktree-branch BRANCH] \
-  [--start-date YYYY-MM-DD] \
-  [--due-date YYYY-MM-DD] \
-  [--recurrence-interval N --recurrence-unit day|week|month|year] \
-  [--if-version N] \
-  [--json]
-
-taskctl issue move ID --status STATUS \
-  [--thread-id ID] \
-  [--binding-thread-id ID \
-    [--binding-codex-project-id PROJECT_ID \
-     --binding-codex-project-kind local|remote \
-     --binding-codex-host-id HOST_ID \
-     --binding-workspace-path PATH] \
-   | --clear-binding-thread] \
-  [--if-version N] [--json]
-taskctl issue archive ID [--thread-id ID] [--if-version N] [--json]
-taskctl issue restore ID [--thread-id ID] [--if-version N] [--json]
-```
-
-Use `issue move` to set `in_progress` before implementation and `in_review` after implementation and self-verification. Codex must not move work directly from `in_progress` to `done`; use `done` only after the user explicitly confirms acceptance or explicitly asks to mark the issue complete. Use `blocked` when work cannot continue and `canceled` when it will not continue. On a version conflict, fetch the issue again and reconcile before retrying.
-
-`--thread-id` records the conversation performing the mutation; it does not create a complete task binding. `--binding-thread-id` can stand alone to preserve a legacy local binding. If any binding identity option is present, all four identity options are required. `--clear-binding-thread` conflicts with every `--binding-*` option. A conversation that claims or continues an issue must pass all five `--binding-*` options together. Reuse an existing complete binding exactly. For an unbound local issue launched with injected Taskboard context, use the current conversation id, injected project id and workspace path, `local` project kind, and `local` host id. Never leave an active issue with only a legacy local `threadId`. Use `--clear-binding-thread` only when the workflow explicitly requires an unbound issue.
-
-Use either `--git-branch` or `--worktree-path`/`--worktree-branch`; an issue has only one development context. Issue JSON stores it as `developmentContext`, either `{ "type": "branch", "branch": "..." }` or `{ "type": "worktree", "path": "...", "branch": "..." }`. Its singular `threadId` is the Codex conversation that most recently created or changed the issue itself. Recurrence requires a due date.
-
-Changing only `--project` preserves the issue's existing linked conversation.
-
-## Issue relations
-
-Read the anchor issue immediately before adding or removing a relation and use its current version. Relation writes require Codex conversation attribution like every other issue write.
-
-```bash
-taskctl issue relation add ISSUE_ID \
-  --type parent \
-  --issue PARENT_ISSUE_ID \
-  [--thread-id ID] \
-  [--if-version N] \
-  [--json]
-
-taskctl issue relation add ISSUE_ID \
-  --type blocks|blocked_by|related \
-  --issue RELATED_ISSUE_ID \
-  [--thread-id ID] \
-  [--if-version N] \
-  [--json]
-
-taskctl issue relation remove ISSUE_ID \
-  --type parent|blocks|blocked_by|related \
-  --issue RELATED_ISSUE_ID \
-  [--thread-id ID] \
-  [--if-version N] \
-  [--json]
-```
-
-For `--type parent`, `ISSUE_ID` is the child and `PARENT_ISSUE_ID` is its parent. Adding another parent replaces the child's current parent atomically. To add an existing issue as a sub-issue, anchor the command on the child and pass the exact parent identifier with `--issue PARENT_ISSUE_ID`.
-
-For `blocks`, the anchor issue blocks the related issue. For `blocked_by`, the related issue blocks the anchor. `related` is symmetric. Self-relations, duplicates, and parent cycles are rejected. For compatibility, relation writes between different projects remain rejected for now; this is a temporary boundary, not the final hierarchy contract.
-
-## Issue comments
-
-Use the issue id to read or append comments. Comment updates and deletes require the latest comment `version` returned by `comment list`.
-
-```bash
-taskctl comment list ISSUE_ID [--after CURSOR] [--json]
-taskctl comment add ISSUE_ID (--body TEXT | --body-file FILE) [--thread-id ID] [--json]
-taskctl comment update COMMENT_ID --body TEXT --if-version N [--thread-id ID] [--json]
-taskctl comment delete COMMENT_ID --if-version N [--thread-id ID] [--json]
-```
-
-Without `--after`, `comment list` returns the full list. Its response includes `nextCursor`; keep that value and pass it to the next read of the same issue to return only comments created or modified after that cursor. `--body-file` reads the UTF-8 file and passes its contents directly to the existing comment write path.
-
-Each comment JSON object independently records the most recent conversation that created or changed that comment as `threadId`. Comment operations never change the parent issue's `threadId`.
-
-## Attachments
-
-Issue descriptions and comments may contain inline images at exact positions in their Markdown:
-
-```markdown
-![alt text](api/attachments/ATTACHMENT_ID/content)
-```
-
-Upload a local file to a task or a comment. Provide exactly one of `--task` or `--comment`:
-
-```bash
-taskctl attachment list (--task TASK_ID | --comment COMMENT_ID) [--after CURSOR] [--json]
-taskctl attachment upload --task TASK_ID --file PATH [--content-type TYPE] [--kind inline|attachment] [--json]
-taskctl attachment upload --comment COMMENT_ID --file PATH [--content-type TYPE] [--kind inline|attachment] [--json]
-```
-
-Without `--after`, `attachment list` returns the full list for that task or comment. Its response includes `nextCursor`; keep a separate cursor for every attachment list target and pass it to the next read to return only later attachments.
-
-The command sends the file bytes to:
-
-- `POST /api/tasks/:id/attachments`, or
-- `POST /api/comments/:id/attachments`
-
-with the same headers as the web UI (`Content-Type`, `X-Taskboard-Filename`, `X-Taskboard-Attachment-Kind`). If `--content-type` is omitted, the CLI guesses from the file extension and falls back to `application/octet-stream`. If `--kind` is omitted, images use `inline` and other files use `attachment`. Use `--kind attachment` for an image that must appear in the attachment list. An inline upload returns the attachment id; use that id in the task description or comment Markdown at the required position.
-
-Download an attachment to an explicit local path:
-
-```bash
-taskctl attachment download ATTACHMENT_ID --output PATH [--json]
-```
-
-The command writes the response body as binary data and returns the absolute output path, content type, and size in its JSON result. Choose the output filename yourself; `taskctl` does not infer or append an extension.