desirecore/market
2
0
Fork 0
mirror of https://git.openapi.site/https://github.com/desirecore/market.git synced 2026-09-05 20:03:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
167 Commits 7 Branches 0 Tags
607045e44e5fe9f038a22c2b71d30e8b5d1d41f6
Commit Graph

22 Commits

Author SHA1 Message Date
Yige
6963018829 feat(feishu-orchestrator): 改为 pointer 形态并声明可安装 / switch to pointer form and make it installable (#119) 
## 为什么 / Why

条目此前是 inline + `listing-only`，详情页显示「仅收录，当前不能由 DesireCore 一键获取」。同期
#115（企微）与 #118（发票助手）都已 `installable`，**飞书是唯一装不了的第三方 Agent**。

inline 形态在这条路上无解：`installable` 要求内容有独立的不可变 ref，而 inline 内容随本仓库走，没有自己的制品
ref。

The listing was inline + `listing-only`, so the client showed it as
discovery-only. With WeCom (#115) and Invoice Organizer (#118) already
installable, this was the only third-party Agent users could not
acquire. Inline form cannot satisfy the installable evidence gate, which
requires content pinned to its own immutable ref.

## 顺带修掉一个错误的承诺 / An incorrect claim, fixed along the way

原 `agent.json` 用 `default_enabled.skills` 声明那 23 个 `lark-*`
技能。但该字段的语义是**「本地已有的技能默认启用」**，schema 明确限定 ID 需存在于 Agent 自带 `skills/` 或市场
`builtin-skills` 清单中 —— `lark-*` 两者都不在，**声明落空**。

真正负责「把技能取过来」的是 `required_skills`（desirecore/desirecore#2587）。也就是说，条目
`fullDesc` 里「随 Agent 一并安装 23 个技能，安装后即可使用」在原实现下**做不到**。

上游 `agent.json` 已改用 `required_skills.collections`，两个字段按 schema
的分工同时保留。逐项核对过：

| 检查项 | 结果 |
|---|---|
| 合集 `larksuite-cli` entry 与 children | 存在，28 个 |
| 声明的 23 个 ID 是否都在其中 | **全部命中，无缺失** |
| source | 公开 git + 固定 ref，可取 |
| 合集自身版本门槛 | 无 |
| `redistribution` | `allowed` |
| 合集是 `listing-only` 是否影响预置 | 否 —— 预置路径不检查 `availability` |

## 形态 / Form

内容移至
[desirecore-agent/feishu-orchestrator](https://github.com/desirecore-agent/feishu-orchestrator)，pin
到 `d5b0a78`。market 侧只留 `entry.json` + sidecar + `assets/`。

上游 `agent.json` 已剥净市场卡片字段，并**单独跑过 `agentConfigSchema`** —— pointer 没有
`projectMarketAgentConfigToAgentFs` 那层投影兜底，`persona`
这类卡片字段留着就会让落盘配置非法（本次正是由该校验捕获并修掉的）。

**图片头像保留**：`assets/avatar.webp` 连同 `entry.avatar.image` 一起留在 market
侧，validator 接受 —— pointer 形态不必退回纯文字头像。

## 证据六项 / Acquisition evidence

- `provenance.content`：https + 40 位 SHA
- `license`：`known` + `MIT` + `evidencePath: LICENSE`
- `compliance`：六字段齐全（含 `noticePath: NOTICE`）
- `compliance.reviewedRef === provenance.content.ref`
- `timestamps.reviewedAt.value === compliance.reviewedAt`
- `availability: installable`

一致性：`entry.maintainer` → sidecar `upstreamMaintainer`；`tags` 用英文 slug 与
`presentation.tags` 逐字一致；`redistribution` 为
`source-pointer-only`；`entry.requiredClientVersion` 与
`compatibility.requiredClientVersion` 一致（`10.0.144`，即包含 #2587 的首个发布版本）。

## 校验 / Verification

| 命令 | 结果 |
|---|---|
| `validate_catalog_metadata.py --require-complete` | **0 error**，75
sidecars |
| `validate-i18n.py` | 0 error |
| `test_validate_catalog_metadata.py` | 47/47 |
| 上游 `agent.json` 过 `agentConfigSchema` | 通过（捕获并修掉了 `persona` 字段） |

Co-authored-by: yi-ge <jackyoncode@gmail.com>
 2026-09-05 14:30:35 +08:00
Yige
1f9e0b0a03 chore(invoice-organizer): 1.0.1 —— 重新 pin 到已合并 commit / repin to merged commit (#121) 
## 背景 / Background

接 [#120](https://github.com/desirecore/market/pull/120)。那个 PR
只改了技能内容，**刻意没动版本号与 pin**——`contentSource.ref` 必须指向**已合并的 commit**，而那个
SHA 在合并前并不存在。先 bump 版本会让目录声称 1.0.1、却仍按指向 1.0.0 内容的 pin 去取文件，比不 bump
更糟。这是 #117/#118 那次两步发布的同一条约束。

Follow-up to #120, which deliberately left the version and pin
untouched: `contentSource.ref` must point at an already-merged commit,
which did not exist until #120 landed.

## 改动 / Changes

- `agent.json#contentSource.ref`、sidecar 的 `provenance.content.ref` 与
`governance.compliance.reviewedRef` **三处同步** pin 到 `7560a58`
- 版本 `1.0.0` → `1.0.1`（`agent.json` 与 sidecar `release.version` 两处一致）
- 补 1.0.1 changelog（中英双语）

## 1.0.1 修了什么 / What 1.0.1 fixes

三条都是真机整理实测撞出来的 Agent 侧规格洞，不是模型不听话：

| 缺陷 | 实测现象 | 根因 |
| --- | --- | --- |
| 归档路径 | 五轮里有两轮归成 `<工作目录>/2022/11/增值税电子普通发票/2022-11-18_….pdf`——同时违反「缺
`归档/` 首层」「多插一层 `<发票类型>/`」「日期用 `YYYY-MM-DD` 而非八位连写」三条 |
原文只用一句散文说了路径，上下文压缩后凭印象重建就会漂 |
| 报告文件名 | 三轮全部写出 `报告/整理报告-<运行日期>.md` | 技能只定义了 `报告/<YYYY-MM>.md`，多月场景无从填写
|
| 台账表数量 | 只有 1 张发票时产出三张表（省了「按销售方汇总」） | 技能写了「四张表，顺序固定」但没说「即使为空也必须存在」 |

前两条的共同点：**只跑一遍、或只跑成功的那遍，都看不见**。归档路径在早期几轮全对，是在同一会话被压缩之后才走样的。

All three are spec gaps found by repeated real-machine runs, not model
disobedience — and the first two are only visible across multiple runs
in the same (compacted) conversation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-09-04 12:22:39 -04:00
Yige
7560a58642 fix(invoice-organizer): 统一报告文件名约定 / unify report file naming (#120) 
## 问题 / Problem

真机三轮整理实测：Agent 全部写出 `报告/整理报告-<运行日期>.md`，而技能里只定义了 `报告/<YYYY-MM>.md`。

**原因不是模型不听话。** 测试范围跨了 2020-08 到 2024-09 共十几个月，`<YYYY-MM>`
在多月场景下无从填写——技能没给出这种情况的文件名，Agent 只能自己发明一个。

**后果不是难看，而是会攒垃圾。** `invoice-automation` 的定时任务每月重建的是 `报告/<上月
YYYY-MM>.md`；与按运行日期命名的手工报告永远不会互相覆盖，用户目录里会留下一堆内容重叠、无从分辨新旧的报告。

Three real-machine runs all produced `报告/整理报告-<run date>.md`, while the
skills only define `报告/<YYYY-MM>.md`. The runs spanned 2020-08 through
2024-09, so `<YYYY-MM>` was unfillable and the agent improvised. Because
the scheduled monthly job rebuilds `报告/<last month YYYY-MM>.md`, the two
naming schemes never overwrite each other and the user's directory
accumulates overlapping reports with no way to tell which is current.

## 改动 / Changes

- `invoice-workflow` 第 7 步补一张表，把两种文件名钉死：

  | 本次覆盖 | 文件名 | 例 |
  | --- | --- | --- |
  | 恰好一个自然月 | `报告/<YYYY-MM>.md` | `报告/2024-08.md` |
  | 跨多个月 | `报告/<起始 YYYY-MM>_<结束 YYYY-MM>.md` | `报告/2020-08_2024-09.md` |

并写明月份按**开票日期**归属（与台账同口径）、同名直接覆盖（报告是从 `.index/ledger.json`
全量重建的派生产物，不像台账需要先备份）、以及**为什么不许用运行日期命名**
- `invoice-ledger` 与 `references/月度报告模板.md` 同步该约定
- 目录布局示例与中英 USAGE 一并标注跨月形态

## 为什么不在本 PR 里 bump 版本 / Why no version bump here

`contentSource` 的 `ref` 必须 pin 到**已合并的 commit**，本 PR 合并前拿不到那个 SHA。先 bump
版本会让目录声称 1.0.1、却仍按指向 1.0.0 内容的 pin 去取文件——比不 bump 更糟。版本号、pin 与 changelog
留到后续 PR 一起改。

The `contentSource` ref must pin to an already-merged commit, which does
not exist until this PR lands. Bumping the version now would advertise
1.0.1 while still serving 1.0.0 content. Version, pin and changelog
follow in a second PR.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---

## 追加：台账四张表必须全建 / Also: all four ledger sheets must always exist

真机压测（只有 1 张发票）产出的 `台账.xlsx` **只有三张表**——Agent 判定「按销售方汇总」在单一销售方下冗余而略过：

```
发票测试（23 张） → ['明细', '月度汇总', '按销售方汇总', '异常']
发票压测（1 张）  → ['明细', '月度汇总', '异常']          ← 少一张
```


技能写的是「四张表，顺序固定」，但没说「即使为空也必须存在」。台账是要被重复重建、被用户自己写公式引用、被下一次整理覆盖的产物；表的位置一旦随数据量浮动，「第
3 张是按销售方汇总」这类引用就会在下个月悄悄指错。已在 `invoice-ledger` 里把这条钉死。

A stress run with a single invoice produced only three sheets — the
agent judged the per-seller summary redundant. The skill said "four
sheets, fixed order" but never said "even when empty". Sheet positions
that float with row count silently break user formulas and rebuilds; now
pinned.
 2026-09-04 11:56:48 -04:00
Yige
98251c9a1d feat: 新增飞书编排助手 Agent 市场条目 / add Feishu Orchestrator agent listing (#114) 
## 这是什么 / What

把自然语言意图翻译成第三方飞书 CLI（`lark-cli`）的正确调用，覆盖云文档、Markdown
文件、电子表格、多维表格、云空间、知识库、幻灯片、画板、即时消息、邮箱、日历、视频会议与妙记、任务、审批、OKR、考勤、应用搭建与实时事件等业务域。

声明 23 个业务域技能依赖，安装后即可使用，无需手工拷贝技能目录。

An agent that turns natural-language intent into correct calls to the
third-party Feishu CLI, covering documents, sheets, Base tables, drive,
wiki, messaging, mail, calendar, meetings, tasks, approvals, OKR and
attendance. It declares 23 domain skill dependencies that install
together with the agent.

## 结构 / Layout

与仓库既有的 `dingtalk-workspace` / `wecom-assistant` 条目保持一致：

```
agents/feishu-orchestrator/
├── agent.json                 # 内联元数据（AgentFS 配置 ∪ 市场卡片，含 i18n 双语 + changelog）
├── catalog-metadata.v1.json   # sidecar，字段全部从 agent.json 派生
├── assets/avatar.webp         # 512×512 图片头像
├── persona.md / principles.md # L0/L1/L2 分层人格与硬规则
├── README.md                  # 条目总览 + 文档索引
└── docs/01..13-*.md           # 按业务域拆分的 13 篇功能文档
```

## 文档 / Docs

命令、参数约定与坑位**均来自真机验证**（2026-09-01，220 个已授权 scope）。未跑通的能力在
[`docs/13-能力边界.md`](agents/feishu-orchestrator/docs/13-能力边界.md)
中如实标注，不含任何租户、组织或个人标识。

其中固化了三处容易踩错的 CLI 契约：

| 契约 | 踩错的后果 |
|---|---|
| `auth status` 成功时**没有**顶层 `ok` 字段 | 按通用 `ok === true`
判据会把「已授权」误判成「未授权」，反复推用户重新扫码 |
| 身份不显式指定会落到 `bot` | bot 看不见用户的个人日历、云盘、邮箱，且返回**空成功**而非报错 |
| `--ranges`（复数）的 sheet 前缀要用 `sheet_name` | 用 `sheet_id` 会通过确认门禁、但在 API
层报 `Sheet not found`；而单数 `--range` 的约定**正好相反** |

## 治理 / Governance

- `governance.availability: listing-only` —— 与核心
Agent、钉钉、企微三个既有条目一致。inline agent 的内容随仓库走，没有独立制品 ref，无法满足 `installable`
分支「必须有不可变 ref 或 SHA-256 摘要」的门禁
- `governance.branding`：`independent-listing` / `nominative` / `logo
not-used` —— 飞书、Lark 为第三方商标，头像为抽象编排拓扑图，不使用任何第三方 logo
- `compatibility.requirements`：按仓库「外部依赖披露」规范声明运行时、权限、连接三类前置。DesireCore
不打包、不分发、不授权、不安装、不代付 `lark-cli` 及其背后的飞书产品

## 顺带修正 / Incidental

根 `README.md` 的 Agent 清单停留在 `2` 个（遗漏 `wecom-assistant`），一并补齐为准确的 4
个；`manifest.json#stats.totalAgents` 3 → 4。

## 校验 / Verification

| 校验 | 结果 |
|---|---|
| `validate_catalog_metadata.py --require-complete` | **0
error**，sidecars 74，本条目零 warning |
| `validate-i18n.py` | 0 error |
| `test_validate_catalog_metadata.py` | 47/47 |
| 发布前敏感信息扫描（邮箱 / 飞书真实 ID / 租户组织标识 / 带 ID 链接 / 密钥形态 / 隐藏文件，全工作树） |
**零命中** |
| 文档内部链接 | 13 个链接全部命中真实文件，无断链 |

## 依赖 / Dependency

`requiredClientVersion: 10.0.143` —— 自动装齐依赖技能的能力来自主仓库
desirecore/desirecore#2587，该值按其合入后的首个发布版本填写。**若 #2587 未能进入
10.0.143，此值需回填修正**，否则用户在缺少该能力的版本上装完 Agent 会没有技能。

---------

Co-authored-by: yi-ge <jackyoncode@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
 2026-09-04 10:38:37 -04:00
Yige
6c303ef21f feat(invoice-organizer): 声明为可安装并 pin 到已合并 commit / make Invoice Organizer installable (#118) 
接 #117。那个 PR 只登记了条目本身（`availability: listing-only`），用户在市场里**看得到、装不了**。
本 PR 补齐可安装所需的证据链。

Follow-up to #117, which only listed the entry (`listing-only`) —
visible in the marketplace but
not installable. This PR supplies the evidence chain required for
installation.

## 改动 / Changes

- `agent.json` 新增 `contentSource`，pin 到 #117 的合并 commit `42a29e9`
- sidecar 的 `provenance.content` 与之**归一化后逐字一致**
（两侧字段名按各自 schema 写：agent.json 侧是 `repoUrl`（`marketPointerSchema`
的必填字段名），
sidecar 侧是 `url`；`normalizeContentSource` 里 `input.url ?? input.repoUrl`
把两者统一成 `url`，
  比对发生在归一化之后，取的是 `{kind, url, path, ref, sha256}` 五元组）
- `governance.compliance.reviewedRef` 绑定同一 commit；`reviewedAt` 与
  `timestamps.reviewedAt` 取同一天
- `governance.availability` 翻成 `installable`
- **移除** sidecar 的 `stewardship: "official"` 与 `branding.relationship:
"official"`

## 为什么移除 `stewardship: official`（这一条值得单独看）

`normalize/sidecar.ts` 只允许 `bundled-builtin` / `system-agent` /
`official-pointer`
三种受信来源自称 official。**inline agent 不在其中**，命中即
`catalog.sidecar-forbidden-provider-claim` —— **整份 sidecar 被丢弃**，
静默回落到 `agent.json` 派生的 legacy 默认值。

在 dev 实例上实测确认（同步到 `42a29e9` 之后）：

```
客户端拿到的 governance:
  {"availability":"listing-only","license":{"state":"unknown"},
   "redistribution":"verify-package-terms","listingMaintainer":{...}}
sidecar 里写的却是:
  license: {state:"known", value:"MIT", evidencePath:"LICENSE"},  redistribution: "allowed"
catalogDiagnostics: null
```

也就是说：sidecar 被整份丢弃，而**维护者没有任何反馈**。

`dingtalk-workspace` 也有同样的 `stewardship: "official"`，它的 sidecar
**同样一直在被静默丢弃**
（实测它的客户端 governance 与本条目改之前完全一样）。这条不在本 PR 范围内，
建议单独处理；DesireCore 主仓库那边我另外记了一条「sidecar 被拒的诊断没有透出到任何 API」的缺口。

## 验证 / Verification

直接调用客户端的真实代码路径（不是照着文档推断）：

```
hydrateCatalogSidecar                  success=true   diagnostics=[]
compareMarketCatalogConsistency        consistent=true  mismatches=[]
evaluateCatalogAcquisitionEligibility  allowed=true   reasons=[]

legacy  provenance.content: {"kind":"git","url":"https://github.com/desirecore/market.git",
                             "path":"agents/invoice-organizer","ref":"42a29e99a0…"}
sidecar provenance.content: {同上，逐字一致}
```

`compareMarketCatalogConsistency` 对 inline agent 会**逐字比对**
`provenance.content`；
不一致会让整份 sidecar 静默降级回 listing-only，而 Python 校验器对 inline 条目
直接跳过这项比对（`_validate_content_consistency` 对 inline 早退），抓不到。
所以这一项只能靠上面这条客户端侧的验证兜住。

## 校验 / Validation

```
validate_catalog_metadata.py --require-complete   0 error, 129 warning, agents=4, sidecars=74
validate-i18n.py                                  0 error, 129 warning
translate.py --check                              ok
gen-collection-children.py --check                ok
```
129 条 warning 全部来自 `skills/*` 的存量条目，`invoice-organizer` **零命中**。
 2026-09-04 09:03:21 -04:00
Yige
42a29e99a0 feat(invoice-organizer): 新增发票整理助手 Agent / add Invoice Organizer agent (#117) 
新增官方 inline Agent「发票整理助手」（`invoice-organizer`）。

Adds an official inline Agent, **Invoice Organizer**, that turns
invoices scattered across
mailboxes and local folders into a reconcilable, reusable ledger.

## 它做什么 / What it does

七步固定流程，每一步幂等：**接入检查 → 收集 → 解析 → 去重 → 归档 → 台账 → 报告**。

- **收集**：从已接入的邮箱（Gmail / Outlook / IMAP）找出候选发票邮件，附件用 `MailOperations` 的
  `save_to` 直接落盘，base64 不进模型上下文
- **解析**：OFD（三个结构化来源分别处理）、PDF 文字层、扫描件走视觉；每个字段带 `extractedBy` 与置信度
- **去重**：发票号码为主键，跨格式识别同一张票（PDF 与照片、重复下载）；近重复不自动合并
- **归档**：`归档/年/月/YYYYMMDD_销售方_金额_发票号码.ext`，原件一个不动
- **台账**：xlsx 四张表（明细 / 月度汇总 / 按销售方汇总 / 异常），发票号码强制文本格式；
  装不上 openpyxl 时降级为 UTF-8 BOM CSV
- **报告**：Markdown 月度报告，收尾固定报五个计数（范围 / 候选 / 成功 / 待复核 / 失败）
- **自动化**：邮件规则 `agent_handle` + `ManageSchedule` 定时出账

## 明确的能力边界 / Explicit boundaries

- **不做发票真伪查验**，也不暗示做过——只做形式校验与勾稽校验，给出官方查验平台入口让用户自己核验
- **不删除、不移动、不转发用户的邮件**
- **票面内容不外流**：不外发、不代发、不上传第三方接口或在线查验站点
- **不做汇率换算**；不承诺「已找全」，只报「在给定范围内找到 N 封候选、成功解析 M 张」

## 结构 / Structure

```
agents/invoice-organizer/
├── agent.json  persona.md  principles.md  LICENSE
├── USAGE.zh-CN.md  USAGE.en-US.md
├── catalog-metadata.v1.json      # availability: listing-only（可安装化见下）
├── assets/avatar.webp
└── skills/
    ├── invoice-workflow/         # 七步总纲、目录布局、落盘顺序、去重主键、幂等
    ├── invoice-extract/          # 三种载体的解析细则、置信度分档、特殊票据
    │   └── references/票面文本形态.md
    ├── invoice-ledger/           # 台账结构、人民币约定（覆盖 xlsx 技能的默认口径）
    │   └── references/月度报告模板.md
    └── invoice-automation/       # 邮件规则与定时调度的参数模板与排查
```

`manifest.json` 的 `stats.totalAgents` 3 → 4。

## 事实性核对 / Fact-checking

技能里引用的**每一个**端点 / 工具名 / 参数名 / 返回字段都对着 DesireCore 主仓库实现逐条核对过，
并经过一轮对抗式 review。review 抓到的、已修正的主要事实错误：

- OFD 一节原本只覆盖 2020 年式样；已改为按**三个来源**分述
  （内嵌附件 / 2024 数电票的 `Tags/CustomTag.xml` 标引 / `DocInfo/CustomDatas`），
  键名从 `Buyer/BuyerName` 改为真实的点号路径 `Buyer.BuyerName`，置信度按来源分档
- **`DocInfo/CustomDatas` 的「合计金额」是不含税金额**，误当 `totalAmount` 会让每张 2024
数电票少记税额
  ——已写成硬规则
- Gmail 本地缓存搜索的 `q` **实际只按主题过滤**（正文过滤在主题收窄之后才跑），
  原文写成「搜主题与正文」会导致静默漏邮件
- 「轮询只覆盖收件箱」只对 IMAP 成立，Gmail / Outlook 是整个邮箱
- `POST /rules/{id}/test` 走另一份内联实现、**没有 `matches_regex` 分支**，
  不能用它验证正则规则
- 邮件列表项里 Gmail / IMAP **是带** `attachments[]` 的，只有 Outlook 不带；
  `labelIds` 是 Gmail 专有

## 真机验证 / Verified on a live instance

在 dev 实例上以一句话指令处理 31 个混合文件（数电票 / 旧版票 / OFD / 扫描件 / 行程单，
外加重复、近重复、作废、零额与 4 个非发票负样本）：

- 23 张归档，字段与夹具 ground truth **逐条吻合**
- 4 个非发票**全部正确拒绝**并写明理由（施工许可证 / 对账单 / 技术服务合同 / 邮件通知）
- 4 个跨格式重复（3 张扫描件 + 1 次重复下载）**全部靠发票号码主键识破**，隔离而非删除
- 近重复正确未合并；作废票归档但不计入合计；低置信度定额发票标为待复核
- 台账 xlsx 四张表、报告含五个计数、`SendUserMessage` 带附件交付
- `待整理/` 31 个原件一个未动

## 校验 / Validation

```
validate_catalog_metadata.py --require-complete   0 error, agents=4, sidecars=74   exit=0
validate-i18n.py                                  0 error                          exit=0
translate.py --check                                                               exit=0
gen-collection-children.py --check                                                 exit=0
```
129 条 warning 全部来自 `skills/*` 的存量条目，改前改后一字不差，`invoice-organizer` 零命中。
另核实：`agent.json` 过 `marketAgentSchema`（详情页）与收窄后过
`agentConfigSchema`（安装），
persona / principles 的 6 个 canonical key 用平台真实解析器全部解得出，全树敏感信息扫描通过
（所有公司名 / 税号 / 银行账号均为 `示例`/`示范`/`虚构`/`样例` 前缀的合成值）。

## 后续 / Follow-up

本 PR 为 `availability: listing-only`。可安装化需要把 `agent.json#contentSource` 与
sidecar 的 `provenance.content` **逐字一致地** pin 到本 PR 的合并 commit，
并补 `governance.compliance` 与 `timestamps.reviewedAt`——那是紧接着的第二个 PR。
 2026-09-04 07:28:03 -04:00
Yige
61c82782c4 fix(wecom-assistant): sidecar 显式声明 installPolicy/updatePolicy / declare install & update policy in sidecar (#116) 
## 中文

sidecar 的 `spec` 未声明 `installPolicy` / `updatePolicy`，而 legacy 侧对双缺省派生为
`market` / `market`，导致 `compareMarketCatalogWithLegacy` 判定
`spec.agent.policy` 不一致，**整个 sidecar 被拒**（`sidecarRejected`）并回退
listing-only。

真机取证——客户端市场索引 `cache/market/index.json` 中该条目：

```json
"sidecarRejected": true,
"catalogDiagnostics": [
  {"code": "market.catalog-legacy-mismatch", "field": "governance.availability"},
  {"code": "market.catalog-legacy-mismatch", "field": "spec.agent.policy"}
]
```

本 PR 修掉其中的 `spec.agent.policy`。另一条 `governance.availability`
是**客户端侧的结构性缺陷**，不在本仓库范围：`market-agent-entry.client.schema.json` 等 5 个
market schema 均无 `availability` 字段且 `additionalProperties: false`，因此
pointer 条目的 legacy availability 恒为 `listing-only`，sidecar 声明
`installable` 必然 mismatch。主仓库已另开 PR 修复，客户端发版后本条目即可生效；在此之前旧客户端会降级为
listing-only 展示，不影响可用性。

校验：`validate_catalog_metadata.py` 0 error。

---

## English

The sidecar's `spec` omitted `installPolicy` / `updatePolicy`, while the
legacy side derives `market` / `market` from the double default.
`compareMarketCatalogWithLegacy` therefore flagged `spec.agent.policy`
as inconsistent and **rejected the whole sidecar**, falling back to
listing-only.

Verified against a live client's market index, which showed
`sidecarRejected: true` with diagnostics for both `spec.agent.policy`
and `governance.availability`.

This PR fixes the former. The latter is a **structural gap on the client
side**, outside this repository: none of the five market schemas carry
an `availability` field and all set `additionalProperties: false`, so a
pointer entry's legacy availability is always `listing-only` and any
sidecar declaring `installable` must mismatch. A separate PR in the main
repository addresses that; this entry becomes effective once the client
ships it. Older clients degrade to listing-only, which does not affect
usability.

Validation: 0 errors from `validate_catalog_metadata.py`.
 2026-09-04 01:18:03 -04:00
Yige
2eebcd3d8c feat(wecom-assistant): 改为 pointer 形态并补齐获取证据 / switch to pointer form with full acquisition evidence (#115) 
## 中文

把「企业微信助手」从 inline 形态改为 pointer 形态，并补齐严格证据门槛，使其成为**首个可一键安装的 Market
Agent**。

### 为什么改

此前该条目在市场详情页显示「仅收录 / 当前不能由 DesireCore 一键获取」。判定源是
`evaluateCatalogAcquisitionEligibility`：Agent 类条目**不享受** builtin Skill 的
`isTrustedBundledBuiltin` 快捷通道（该函数硬编码 `kind === 'skill'`），必须走 content
不可变 + license known + compliance 三重匹配的严格门槛。这与本仓库 README 的「Agent pointers
do not receive the built-in Skill exceptions」及 ADR-137 一致，是有意的设计而非缺陷。

inline 形态还存在自指问题：证据要求 `content` 指向不可变 commit，而 inline
内容就在本仓库里，条目无法预知自己将被合并进哪个 commit。现网 41 个 inline 条目全部没有 `content`，30 个
pointer 条目全部有——数据印证了这一点。

### 改了什么

**形态**：内容迁至 `desirecore-agent/wecom-assistant`，本仓库只保留 `entry.json` 与
sidecar。删除 53 个文件 / 16494 行，条目从 1.0M（全仓最大的 Agent 条目）降到数 KB。符合
ADR-038「market 仓库只放元数据、不放具体内容」。

**证据六项**：
| 项 | 值 |
|---|---|
| `provenance.content` | git + `665ab1d2…`（https + 40 位 SHA） |
| `governance.license` | `unknown` → `known` / MIT，`evidencePath:
LICENSE` |
| `governance.compliance` | 五项齐备，`reviewedRef` 等于 `content.ref` |
| `timestamps.reviewedAt` | 与 `compliance.reviewedAt` 逐字一致 |
| `availability` | `listing-only` → `installable` |
| `redistribution` | 与 `entry.json` 同为 `source-pointer-only` |

**内容侧**（在内容仓库中完成）：13 个业务技能改为 vendor 企业微信官方
`WecomTeam/wecom-cli`（MIT，pinned `78c514b2`），自维护 `wecom-shared` /
`wecom-chat` / `wecom-workflows` 三个治理与增量技能。官方内容量为原自研版的 1.6 倍（21.6k vs
13.7k 行），并已修正官方 `meeting rooms search` 的 3
个失效参数名——`room_keyword`/`min_capacity`/`building_city` 在 CLI 1.2.0 已改名，而
CLI 对未知字段不校验、原样透传，会导致静默订错会议室。MIT 署名义务由内容仓库的 `NOTICE` 与
`third_party/wecom-cli/LICENSE` 履行。

### 校验

`validate_catalog_metadata.py` 0 error、`validate-i18n.py` 0
error、`gen-collection-children.py --check` 通过（wecom-cli 14 children）。129
个 warning 均为其他既有条目所有，本次未新增。

### 已知风险

市场 Agent 的安装链路此前**从未被真实用户走过**（现网 0 个 installable
agent，仅有单测覆盖）。合并后需真机验证安装、并重启客户端后再验一次卸载。

---

## English

Switches the WeCom Assistant entry from inline to pointer form and
supplies the full acquisition evidence, making it the **first
installable Market Agent**.

### Why

The entry previously rendered as listing-only. Agent items do **not**
receive the builtin-Skill fast path in
`evaluateCatalogAcquisitionEligibility` (`isTrustedBundledBuiltin`
hardcodes `kind === 'skill'`), so they must satisfy the strict gate:
immutable content, known license, and ref-bound compliance. That matches
this repo's README ("Agent pointers do not receive the built-in Skill
exceptions") and ADR-137 — it is deliberate, not a defect.

Inline form also has a self-reference problem: the gate requires
`content` to pin an immutable commit, but inline content lives in this
repository and cannot know which commit will carry it. All 41 inline
entries currently lack `content`; all 30 pointer entries have it.

### What changed

**Form**: content moved to `desirecore-agent/wecom-assistant`; only
`entry.json` and the sidecar remain here. 53 files / 16494 lines
removed, shrinking the entry from 1.0M (the largest Agent entry in the
repo) to a few KB, per ADR-038.

**Evidence**: `provenance.content` pins `665ab1d2…`; license becomes
known/MIT with `evidencePath`; compliance carries all five required
fields with `reviewedRef` equal to `content.ref`;
`timestamps.reviewedAt` matches `compliance.reviewedAt`; availability
becomes `installable`; redistribution aligns with `entry.json`.

**Content side**: 13 business skills are now vendored from the official
`WecomTeam/wecom-cli` (MIT, pinned `78c514b2`) — 1.6× the volume of the
previous in-house set — with three self-maintained skills for governance
and coverage gaps. Three stale meeting-room parameter names were
corrected; the CLI passes unknown fields through without validation, so
the stale names would silently book the wrong room. MIT attribution is
carried by `NOTICE` and `third_party/wecom-cli/LICENSE` in the content
repository.

### Validation

0 errors from the catalog and i18n validators; collection children check
passes. The 129 warnings all belong to pre-existing entries.

### Known risk

The Market Agent install path has never been exercised by a real user (0
installable agents in production; unit tests only). Post-merge, install
should be verified on a real client, and uninstall re-verified after a
restart.
 2026-09-04 00:46:33 -04:00
Yige
a8361009b9 feat(dingtalk-workspace): add USAGE.md and wire feature docs into skill references (#113) 
## 背景 / Background

`agents/dingtalk-workspace` 条目把 13 篇使用文档放在 `docs/` 目录，但**两侧都读不到**：

- 市场详情页只渲染 `agent.json` 的元数据字段，不扫描条目目录下的 `docs/`
- Agent 自身的上下文只挂载 `persona.md` / `principles.md` / `memory/` /
`skills/`，`docs/` 不在其中

The listing kept 13 usage documents under `docs/`, but nothing consumed
them: the
market detail page only projects `agent.json` metadata, and the agent's
own context
mounts `persona.md` / `principles.md` / `memory/` / `skills/` only.

## 变更 / Changes

配合 DesireCore 主仓库的 `USAGE.md` 平台约定（ADR-143）与既有技能 `references` 机制，分别解决两侧。
Pairs with the new `USAGE.md` platform convention (ADR-143) in the
DesireCore repo.

| 变更 / Change | 说明 / Detail |
| --- | --- |
| 新增 `USAGE.md` | 安装前该知道的内容：第三方 CLI 依赖声明、5
步快速开始、六种审批模式取舍、安全与已知边界。**刻意不含图片**——详情页的 markdown 渲染器会移除普通 `img src` |
| 新增私有技能 `dingtalk-guide` | 只做索引，正文用 `${SKILL_DIR}/references/` 绝对路径指向
13 篇文档，Agent 按需 `Read`。单产品问题（如「钉盘同步怎么用」）可触发查文档再作答，不占每轮上下文 |
| `docs/` → `dingtalk-guide/references/` | 整体移入并拍平。原 12
篇无交叉链接、无图片，移动无需改写正文 |
| `docs/README.md` 拆分 | 安装部分 → `USAGE.md`；界面与审批部分连同两张截图 →
`references/界面与审批.md` |
| `README.md` | 补 `USAGE.md` 约定说明与目录树条目 |
| `manifest.json` | 1.5.0 → 1.5.1（条目内容新增；计数不变，经校验器实跑确认） |

**单一真相源 / Single source of truth**：每篇文档只有一份，归 `dingtalk-guide` 技能所有；
不存在 `docs/` 与 `references/` 两份副本。`dingtalk-onboarding` 与
`dingtalk-workflows`
两个既有技能不变。

## 校验 / Validation

README 记录的 7 条 CI 校验命令全部实跑通过（改动前后各一轮）：

```
scripts/i18n/test_validate_i18n.py                              exit=0
scripts/catalog/test_validate_catalog_metadata.py               exit=0
scripts/catalog/test_collection_generator.py                    exit=0
scripts/catalog/validate_catalog_metadata.py --require-complete  exit=0
scripts/i18n/validate-i18n.py                                   exit=0
scripts/i18n/translate.py --check                               exit=0
scripts/gen-collection-children.py --check                      exit=0
```

`manifest.json#stats` 由 `validate_catalog_metadata` 输出实跑确认（agents=3,
teams=1,
publishableSkills=69），非算术推导，故不变。

## 公开信息边界 / Public information boundary

全树扫描零命中：改动文件、新增路径名、分支名、commit 主题与正文、本 PR 文本均不含
租户/客户/伙伴/个人身份。两张截图已逐张目视复核——仅含 DesireCore 自身界面、Agent 名称与
通用 `dws` 命令，返回结果为空列表，不含组织名或任何组织形态。

Full-tree scan returned zero results. Both screenshots were reviewed
individually:
they show only DesireCore's own UI, the agent name, and generic `dws`
commands.

## 依赖 / Dependency

`USAGE.md` 的详情页渲染依赖 DesireCore 主仓库的配套 PR。在其发布前，本条目的
`USAGE.md` 仍是仓库内可读的普通文件，不影响现有行为。

Detail-page rendering depends on the companion PR in the DesireCore
repository.
Until it ships, `USAGE.md` is simply a readable file in the listing and
changes nothing.
 2026-09-04 00:08:53 -04:00
Yige
aec2e7c28b feat: 新增企业微信助手 Agent，并修正 wecom-cli 条目 ref 漂移 (#112) 
## 概述 / Overview

两件事：新增「企业微信助手」Agent（自带 15 个技能），并修正 `wecom-cli` 条目钉在 6 月快照的 ref 漂移。

Two changes: adds the **WeCom Assistant** agent (bundling 15 skills),
and fixes the `wecom-cli` entry whose pinned ref was stuck on a June
snapshot.

## 1. 新增企业微信助手 Agent

覆盖企业微信 **14 类服务、95
个方法**：消息、群聊历史、通讯录、日程、会议、待办、邮件、在线文档、在线表格、智能表格、智能文档、文档管理、微盘、媒体文件。

**采用内联形态 + 自带私有技能**：Agent 安装对 `agents/<id>/` 整目录递归复制且 `skills/`
不在排除集合里，因此装 Agent 即带全部技能，用户无需再单独获取技能合集。

### 技能集（15 个，约 5000 行）

- 基于上游 [wecom-cli](https://github.com/WecomTeam/wecom-cli) 官方
Skill（MIT，© WecomTeam）改写，每个技能末尾保留归属声明
- **新增 `wecom-chat`**：补齐上游零覆盖的群聊历史读取
- 补齐上游未覆盖的 `message.send`、`doc.create`，方法覆盖达 **95/95**
- 修正上游三处文档漂移：邮件能力描述与实际相反、会议室参数名已过时、`title_highlight` 字段不存在

### 相对上游的核心增量：风险治理

- 26 个对外可见或不可逆的方法逐个写明**执行前确认要求**
- 4 个条件升级方法给出**参数级判据**，而非按方法名一刀切
- 文档权限扩散两项加重处理，涉及**企业外可见**时单独再确认一次
- 内部标识禁止外露，不因用户索要而放宽
- 拒绝导出可识别到具体自然人的隐私字段

### 三条真机实测得出、上游未覆盖的硬约束

1. 机器人**只能写入/修改自己创建的数据**，真人创建的只能读
2. 每次响应携带的 `extra_identity_context` **禁止透露给用户**
3. 权限错误（`850002`/`851008`/`853006`）**不得重试**，须将 `help_message`
**逐字原样**转给用户

## 2. 修正 wecom-cli 条目 ref 漂移

`source.ref` 原钉在 2026-06-28 的 `72e14f7`，该快照只有 7
个子技能且用已废弃的旧命名（`msg`/`schedule`）。上游 v1.2.0 已扩展到 **14 个**技能。按旧 ref
安装的用户拿到的是三个月前的快照。

- `source.ref` → `78c514b2afee7c0d3d7be715628478421f37ee63`
- `children` 由 `scripts/gen-collection-children.py` 重新生成，**7 → 14**
- sidecar 同步 `provenance.content.ref`、`childCount` 与 `children`

## 验证 / Verification

**静态**
- 215 条示例命令追加 `--dry-run` 实跑，**215/215 退出码 0**
- 未知方法 0、未知参数 0、`--json` 未知字段 0、枚举违规 0
- 15 个 `SKILL.md` 的 frontmatter 经客户端 `skillFrontmatterSchema` 校验全部通过
- `validate_catalog_metadata.py --require-complete` 与
`gen-collection-children.py`：**0 error**

**真机（在真实企业微信账号上端到端）**
- **待办域 6/6 方法全通**（含 2 个 write-high），`items` 必填的隐蔽坑实测证实
- **日程域 5 个方法全通**（含 3 个 write-high）
- 消息发送、通讯录解析、微盘列表、邮件搜索、文档搜索、会议列表、智能表格创建均已实测通过
- 测试数据已全部清理，未污染真实账号

**尚未实测**：群聊历史（机器人未开通该品类）。相关文档已明确标注验证状态，未实测的能力不写「实际效果」段落。
 2026-09-03 03:50:00 -04:00
Yige
43a8cbd549 feat: 新增钉钉工作台助手 Agent 市场登记条目 (#107) 
## 摘要 / Summary

**中文**：新增市场第 2 个 Agent 条目
`dingtalk-workspace`（钉钉工作台助手），作为钉钉全产品能力的**发现入口**。条目只提供发现元数据与治理事实，Agent
正文不在本仓库分发。

**English**: Adds the marketplace's second Agent listing,
`dingtalk-workspace` (DingTalk Workspace Assistant), as a **discovery
entry** for DingTalk's product surface. The listing carries discovery
metadata and governance facts only; the Agent's own content is not
distributed from this repository.

## 变更 / Changes

| 文件 / File | 说明 / Note |
| --- | --- |
| `agents/dingtalk-workspace/agent.json` | 市场展示元数据，zh-CN + en-US 双语 /
Market display metadata, zh-CN + en-US |
| `agents/dingtalk-workspace/catalog-metadata.v1.json` | 治理 sidecar /
Governance sidecar |
| `agents/dingtalk-workspace/assets/avatar.webp` | 512×512 中性图形头像 /
Neutral 512×512 avatar |
| `manifest.json` | `totalAgents` 1 → 2；version 1.2.30 →
1.3.0；lastUpdated |
| `README.md` | Agent 计数与目录示意 / Agent count and repository shape |

## 条目形态：可安装 / Shape: installable

**中文**：条目随附完整 Agent 正文（`persona.md`、`principles.md`、2 个 Skill、13
篇文档），安装后即得到完整可用的 Agent。

治理字段取值与理由：

| 字段 | 取值 | 理由 |
| --- | --- | --- |
| `installPolicy` / `updatePolicy` | `market` / `market` |
正文已在条目内，Market 负责安装与更新。这也避开了
`isMarketAgentMetadataOnly()`（`sync/market.ts:113-128`）——它只在
`system`+`repository` 时返回 true，另一条分支是对 `desirecore` 的 id 硬编码特判，本条目不适用 |
| `release` | `known` `1.0.0` `semver` | 非 system Agent 时
`validate_catalog_metadata.py:625-630` 要求 `release` 保留 legacy `version`
|
| `timestamps.releasePublishedAt` | `2026-09-01` | 本次发布日 |
| `governance.availability` | `listing-only` | 见下 |

**为什么 `availability` 不是
`installable`**：`validate_catalog_metadata.py:650-712` 的强证据门禁要求不可变
`provenance.content`（git 40 位 SHA 或 sha256）+ 已知 license + 已知
`reviewedAt` + `compliance`。本条目正文就在本仓库这次提交里，无法自指一个尚不存在的固定
ref；未做治理审查，也不会编造 `reviewedAt` 与许可证据。`listing-only`
在本仓库既有先例（`wecom-cli`、`larksuite-cli` 都是 `listing-only`
且实际可安装），且客户端不读该字段——真正决定可安装性的是 `installPolicy`。

**English**: The listing ships the complete Agent content (`persona.md`,
`principles.md`, 2 Skills, 13 documents), so installing yields a fully
working Agent.

| Field | Value | Rationale |
| --- | --- | --- |
| `installPolicy` / `updatePolicy` | `market` / `market` | Content lives
in the listing, so Market owns install and update. This also avoids
`isMarketAgentMetadataOnly()` (`sync/market.ts:113-128`), which returns
true only for `system`+`repository`; its other branch is an id-hardcoded
special case for `desirecore` that does not apply here |
| `release` | `known` `1.0.0` `semver` | For a non-system Agent,
`validate_catalog_metadata.py:625-630` requires `release` to preserve
the legacy `version` |
| `timestamps.releasePublishedAt` | `2026-09-01` | Publication date |
| `governance.availability` | `listing-only` | See below |

**Why `availability` is not `installable`**: the strict evidence gate at
`validate_catalog_metadata.py:650-712` requires an immutable
`provenance.content` (40-hex Git SHA or sha256) plus a known license, a
known `reviewedAt`, and `compliance`. This listing's content lives in
this very commit, so it cannot pin a ref that does not yet exist; no
governance review was performed, and no `reviewedAt` or license evidence
will be invented. `listing-only` has precedent here (`wecom-cli` and
`larksuite-cli` are both `listing-only` yet installable in practice),
and the client does not read the field — installability is actually
decided by `installPolicy`.

### agent.json 的双重身份 / agent.json serves two contracts

**中文**：安装时整个 `agents/<id>/` 目录被 `cpSync` 到
`~/.desirecore/agents/<id>/`（`market-routes.ts:1228-1252`），因此这个
`agent.json` **同时**是市场展示元数据和 AgentFS 运行时配置。已把源 Agent 的运行时配置并入（`llm` 智能路由
flagship、`heartbeat`、`session_mode`、`env`、`mcp_servers`、并发上限等）。

已知副作用：两套 Schema 在 10 个字段上不相交（市场侧的 `category` / `updatedAt` /
`maintainer` / `i18n` / `persona` / `changelog` / `installPolicy` /
`updatePolicy`，以及 `avatar.t` / `avatar.bg`），AgentFS 侧
`agentConfigSchema` 是 `additionalProperties: false`，`id` 还要求 UUID
形态。因此安装后
`parseAgentJsonText`（`agent/reader.ts:375-397`）会走宽松解析分支，每个进程打印一条
warning。宽松分支原样返回解析结果，配置全部生效——已实测确认（见下）。这是「内联可安装 Market
Agent」这一形态固有的，本仓库此前没有先例。

**English**: On install the whole `agents/<id>/` directory is
`cpSync`-ed into `~/.desirecore/agents/<id>/`
(`market-routes.ts:1228-1252`), so this `agent.json` is
**simultaneously** the marketplace display metadata and the AgentFS
runtime config. The source Agent's runtime configuration has been merged
in (`llm` smart routing at flagship tier, `heartbeat`, `session_mode`,
`env`, `mcp_servers`, concurrency cap).

Known side effect: the two schemas are disjoint on 10 fields
(market-side `category`, `updatedAt`, `maintainer`, `i18n`, `persona`,
`changelog`, `installPolicy`, `updatePolicy`, plus `avatar.t` /
`avatar.bg`), AgentFS's `agentConfigSchema` is `additionalProperties:
false`, and its `id` expects a UUID shape. So after install,
`parseAgentJsonText` (`agent/reader.ts:375-397`) takes the lenient
branch and prints one warning per process. That branch returns the
parsed object as-is, so every setting still applies — verified below.
This is inherent to the "inline installable Market Agent" shape, which
has no prior precedent in this repository.

## 外部依赖披露 / External dependency disclosure

**中文**：本 Agent 依赖一个由第三方独立分发的命令行程序，并需要用户自行完成钉钉账号 OAuth 授权。按仓库
`CLAUDE.md`「External dependency disclosure」要求，已在四处披露：

1. **发现描述** — `agent.json#i18n.<locale>.shortDesc`（zh-CN 与 en-US 各一份）
2. **`compatibility` 字段** — sidecar `compatibility.requirements[]`，4
条：runtime（用户自行安装第三方 CLI）、runtime（官方产品技能需手工拷贝且每次升级重做）、permission（钉钉账号
OAuth，能力范围取决于授权范围）、connection（网络与所在组织已开通的产品/权益）
3. **本地化市场文案** — `agent.json#i18n.<locale>.fullDesc` 与 sidecar
`presentation.i18n.<locale>.description` 中的「外部依赖声明」整节
4. **执行约定** — 同一节明确：依赖不可用（未安装 / 未授权 / 无权限 /
组织未开通）时，在发起外部调用**之前**停止并如实说明，**不编造成功结果**

明确声明 DesireCore
**不打包、不分发、不授权、不安装、不代付、不运营**该程序及其背后的产品；凭据与费用由用户与服务方之间的条款约束。

**English**: This Agent depends on an independently distributed
third-party CLI and requires the user's own account OAuth. Per
`CLAUDE.md` "External dependency disclosure", it is disclosed in all
four required places:

1. **Discovery description** — `agent.json#i18n.<locale>.shortDesc`, in
both zh-CN and en-US
2. **`compatibility` field** — sidecar `compatibility.requirements[]`,
four entries: runtime (user installs the third-party CLI), runtime
(official product skills must be copied manually and re-copied after
each upgrade), permission (account OAuth; coverage depends on granted
scopes), connection (network plus the products and entitlements enabled
for the user's own organization)
3. **Localized marketplace text** — the "External dependency disclosure"
section inside `agent.json#i18n.<locale>.fullDesc` and sidecar
`presentation.i18n.<locale>.description`
4. **Execution instructions** — the same section states that when the
dependency is unavailable (not installed, not authorized, not permitted,
or not enabled), the Agent stops **before** the external call and never
fabricates a successful result

It states explicitly that DesireCore does **not bundle, distribute,
license, install, pay for, or operate** that program or the products
behind it; credentials and fees are governed by terms between the user
and the service provider.

## 品牌与商标 / Branding

**中文**：`branding.relationship: independent-listing` / `nameUsage:
nominative` / `logoStatus: not-used`。头像是自制的中性图形（对话气泡 + 终端提示符
`>_`，表达「自然语言意图 → 命令调用」），**未使用任何第三方 logo 或商标图形**。

**English**: `branding.relationship: independent-listing` / `nameUsage:
nominative` / `logoStatus: not-used`. The avatar is an original neutral
mark (a speech bubble containing a `>_` terminal prompt, expressing
"natural-language intent becomes a command call"). **No third-party logo
or trademark artwork is used.**

## 未审查的事实保持 unknown / Unverified facts left unknown

**中文**：未做治理审查，因此
`governance.license`、`timestamps.reviewedAt`、`timestamps.releasePublishedAt`、`timestamps.upstreamObservedAt`、`release`
一律如实为 `unknown`，不编造许可证据或审查时间。`compatibility.platforms` 同样为
`unknown`——实际只在 macOS 上验证过，不宣称未验证的平台。

**English**: No governance review was performed, so
`governance.license`, `timestamps.reviewedAt`,
`timestamps.releasePublishedAt`, `timestamps.upstreamObservedAt`, and
`release` are all honestly `unknown`; no license evidence or review date
is invented. `compatibility.platforms` is likewise `unknown` — only
macOS was actually exercised, and untested platforms are not claimed.

## 校验 / Validation

**中文**：按 `.github/workflows/i18n-validate.yml` 的顺序在本地跑完 7 步，全部 `exit
0`；`0 error(s)`，116 warning 全部是主干既有条目的历史告警，**新条目零告警**。

**English**: All seven steps from `.github/workflows/i18n-validate.yml`
were run locally in order; every step exited `0`. `0 error(s)`; all 116
warnings are pre-existing on `main` for other listings — **the new
listing produces none**.

```
exit=0  errors=0   新条目命中=0    <-- scripts/i18n/test_validate_i18n.py
exit=0  errors=0   新条目命中=0    <-- scripts/catalog/test_validate_catalog_metadata.py
exit=0  errors=0   新条目命中=0    <-- scripts/catalog/test_collection_generator.py
exit=0  errors=0   新条目命中=0    <-- scripts/catalog/validate_catalog_metadata.py --require-complete
exit=0  errors=0   新条目命中=0    <-- scripts/i18n/validate-i18n.py
exit=0  errors=0   新条目命中=0    <-- scripts/i18n/translate.py --check
exit=0  errors=0   新条目命中=0    <-- scripts/gen-collection-children.py --check

0 error(s), 116 warning(s). agents=2, builtinSkills=34, pointerSkills=28,
publishableSkills=62, collections=7, collectionChildren=147, sidecars=64
```

另外用客户端契约做了运行时验证：按 `readAgentDetail` 的归一化逻辑（i18n 拍平 + changelog 按 locale
解析 + system 策略下 `version` → `metadataRevision`）还原 detail
对象后，`validateMarketAgent` 在 zh-CN 与 en-US 下均 PASS。

Additionally verified against the client contract: after reproducing
`readAgentDetail`'s normalization (i18n flattening, per-locale changelog
resolution, and `version` → `metadataRevision` under the system policy),
`validateMarketAgent` PASSes for both zh-CN and en-US.

### 安装验证 / Install verification

**中文**：用 agent-service 的**真实导出函数**复刻 `market-routes.ts:1185-1260`
的安装流水线（`skillCopyFilter`、`computeCapabilityContentDigest`、`isMarketAgentMetadataOnly`、`extractAgentVersion`、`parseAgentJsonText`），在
vitest unit project 中执行。

**English**: The install pipeline from `market-routes.ts:1185-1260` was
reproduced using agent-service's **real exported functions**
(`skillCopyFilter`, `computeCapabilityContentDigest`,
`isMarketAgentMetadataOnly`, `extractAgentVersion`,
`parseAgentJsonText`) and executed inside the vitest unit project.

```
[1] isMarketAgentMetadataOnly = false => 放行可装
[2] cpSync ok; source=cb8c961bb55b9abe… staged=cb8c961bb55b9abe…
[3] installedVersion = 1.0.0
[5] 应存在 19 项，缺失 0 项
[6] parseAgentJsonText => 可用配置
    name=钉钉工作台助手 llm.routingMode=smart tier=flagship
    max_concurrent_sessions=3 accepts_messages=true
    avatar.image.path=assets/avatar.webp

 ✓ packages/agent-service/src/__tests__/…  (1 test) 75ms
 Test Files  1 passed (1)
```

19 项断言覆盖 `agent.json` / `persona.md` / `principles.md` / 2 个 `SKILL.md`
/ `assets/avatar.webp` / 13 篇文档，全部存在；staged 摘要与源摘要一致（内容无漂移）。

All 19 assertions — `agent.json`, `persona.md`, `principles.md`, both
`SKILL.md` files, `assets/avatar.webp`, and all 13 documents — are
present, and the staged digest matches the source digest (no content
drift).

## 公开信息边界 / Public information boundary

**中文**：按 `CLAUDE.md`「Required pre-publication
check」执行完毕。敏感令牌清单通过私有渠道获取并保存在仓库之外，未落盘、未写入否定名单。全工作树扫描（含隐藏文件、排除 `.git`）后，本
PR 新增与修改的文件（含本次新增的 17
个正文文件）**零命中**；已对示例做语义复核，正文示例统一使用「某某」「张三」这类中文通用占位人名，正文只描述公开的软件包名、公开命令与中立能力域，不含任何租户、客户、伙伴或个人身份，也无截图。分支名、commit
标题与正文、以及本 PR 文本同样零命中。检查通过。

**English**: The `CLAUDE.md` "Required pre-publication check" was
completed. The sensitive token list was obtained through a private
channel and kept outside the repository; it was not persisted and not
added to any denylist. After scanning the complete working tree
(including hidden files, excluding `.git`), the files added or modified
by this PR — including the 17 content files added in this round —
produce **zero hits**. Examples were reviewed semantically: the text
describes only public package names, public commands, and neutral
capability domains, with no tenant, customer, partner, or individual
identity, and no screenshots. The branch name, commit subject and body,
and this PR text are likewise clean. Check passed.

## 备注 / Notes

**中文**：与 #104（`skills/dingtalk-cli` 技能条目）互补——那个 PR 登记工具层，本 PR 登记 Agent
层。两者都改了 `manifest.json` 与 `README.md` 的统计行，后合并的一方需要重算计数。本分支基于 `main`，不依赖
#104。

目录 slug 选用 `dingtalk-workspace` 而非本机 AgentFS 实例目录名：AgentFS
实例目录是创建时按中文名自动生成的拼音串，不满足市场 slug 的语义可读性要求；`dingtalk-workspace`
与它所面向的产品域（钉钉工作台）及上游 CLI 包名一一对应，对应关系明确可查。

**English**: Complementary to #104 (the `skills/dingtalk-cli` listing) —
that PR registers the tool layer, this one the Agent layer. Both touch
the stats lines in `manifest.json` and `README.md`, so whichever merges
second must recount. This branch is based on `main` and does not depend
on #104.

The directory slug is `dingtalk-workspace` rather than the local AgentFS
instance directory name: that instance directory is an auto-generated
pinyin transliteration of the Chinese display name and is not
meaningfully readable as a marketplace slug. `dingtalk-workspace` maps
one-to-one onto the product surface it fronts and onto the upstream CLI
package name, so the correspondence stays explicit.

---------

Co-authored-by: yi-ge <jackyoncode@gmail.com>
 2026-09-02 06:36:14 -04:00
Yige
df5959eebf 移除官网展示用 Agent 目录 (#109) 
## 变更

- 移除此前为官网展示加入的 7 个 Agent 条目
- 恢复 Market 为真实可复用目录，不再承载官网宣传样例
- 恢复 README 与 manifest 中的 Agent 计数

## 验证

- `scripts/i18n/test_validate_i18n.py`
- `scripts/catalog/test_validate_catalog_metadata.py`
- `scripts/catalog/test_collection_generator.py`
- `scripts/catalog/validate_catalog_metadata.py --require-complete`
- `scripts/i18n/validate-i18n.py`
- 敏感信息与发布边界检查通过
 2026-08-31 23:39:53 -04:00
Yige
9eb6181e55 feat: 增加公开业务 Agent 目录 (#108) 
## 摘要

新增 7 个公开、可复用的 listing-only Agent 条目：

- 内容营销 Agent
- 标书协作 Agent
- 合同审查 Agent
- 工程图校核 Agent
- 检验报告 Agent
- 研究证据 Agent
- 流程运营 Agent

这些条目用于发现和展示能力蓝图，不声明已安装、已连接外部系统或可替代专业人员签发。工程、检验、法律和研究类条目均保留人工复核边界。

## Summary

Add seven public, reusable, listing-only Agent entries for content
marketing, tender collaboration, contract review, engineering drawing
review, inspection reports, research evidence, and workflow operations.

The entries are discovery blueprints only. They do not claim installed
tools, connected systems, or authority to replace qualified professional
review and sign-off.

## 数据变更 / Data changes

- Market version: `1.3.0`
- Agent count: `1 → 8`
- Every Agent includes bilingual legacy metadata and `CatalogItemV1`
sidecar data
- All new entries remain `listing-only` with unknown license/platform
facts where evidence is absent

## 验证 / Validation

- i18n unit tests: 9/9
- catalog validator tests: 29/29
- collection generator tests: 4/4
- catalog validation: 0 errors
- i18n validation: 0 errors
- secret/private-key scan: 0 findings
 2026-08-31 22:43:30 -04:00
Yige
a205ef20f0 feat: 迁移统一目录元数据契约 (#102) 
## 中文

- 为 System Agent、34 个 Builtin Skill、28 个 Pointer/Collection 条目增加 catalog
sidecar
- 覆盖 147 个 collection child，并固定可证明的来源；无法证明的内容保持 listing-only/unknown
- 增加 strict Schema、validator、collection check 与 CI 完整性门禁

## English

- Add catalog metadata sidecars for the System Agent, 34 built-in
Skills, and 28 pointer/collection entries
- Cover 147 collection children while keeping unverifiable facts
listing-only or unknown
- Add strict schemas, validators, deterministic collection checks, and
CI completeness gates

## 验证 / Verification

- Catalog validator 17/17
- Collection generator 4/4
- 63 sidecars, 147 children, zero errors
 2026-08-31 04:10:49 -04:00
Yige
5a0a80d31c test(market): delist temporary QA agent (#89) 
Removes the temporary QA-only Agent listing after successful real Market
installation verification. The installed local copy is intentionally
verified separately to ensure delisting does not delete user-owned
installations.
 2026-08-23 19:07:09 +08:00
Yige
4bc2d41b12 test(market): publish temporary QA agent (#88) 
Temporary QA-only Agent pointer for validating the real publish,
install, and delist lifecycle.\n\n- Source repo is public and MIT
licensed\n- Pointer is pinned to immutable commit
dd4abbe342f25d0569dba152ce1be3fb867c3474\n- No user data, credentials,
or third-party content\n- A follow-up PR will remove this entry after
installation verification
 2026-08-23 18:51:06 +08:00
Yige
43239669e5 feat: DesireCore 条目添加图片头像 (#84) 
## 变更 / Changes

新增 `agents/desirecore/assets/avatar.webp`（512×512，32KB），并在 `agent.json`
的 `avatar` 加 `image` 字段。条目版本 1.1.0 → 1.2.0。

## ⚠️ 这是市场仓库的新约定

市场包此前**从不携带 Agent 图片资源** —— 整个 zip 里唯一的图标是技能用的 SVG。本次起，Agent 条目可在自己的目录下放
`assets/` 图片，由客户端的 `GET /api/market/agents/:id/avatar-image` 读取（上限
2MB，magic bytes 校验，仅 PNG/JPEG/WebP）。

This is a **new convention** for the market repo: entries may now ship
an `assets/` image alongside their config.

## `t` 与 `bg` 保留

不是冗余：客户端取不到图时回落到 `t + bg` 渲染；旧客户端不认识 `avatar.image`，也走这两个字段。所以它们仍是必填。

## 与安装后的头像是两套

市场 avatar（`{t, bg, image}`）是**展示元数据**，与安装后 `agent.json` 的 avatar（`{char,
color, image}`）互不迁移 —— 这是既有语义（配色本来就不迁移），本次不改变它。

## 配套 / Companion

- 客户端市场侧支持：desirecore#1951
- 核心智能体自身的头像：agent-desirecore#6（已合并）

Co-authored-by: yi-ge <jackyoncode@gmail.com>
 2026-08-15 01:10:12 +08:00
Yige
8bdda4afb1 feat: skills i18n 改造（schemaVersion 1.1，零向后兼容） (#1) 
* feat: skills i18n 改造 — schemaVersion 1.1，零向后兼容

把 21 个 skills + 1 个 agent + manifest/categories 全量迁移到 schemaVersion 1.1
的 i18n 结构，配套 CI AI 翻译流水线（GitHub Models）与本地工具链。

## 关键变更

### 数据结构（破坏性，schemaVersion 1.0 → 1.1）
- SKILL.md: 顶层 name 改为 ASCII slug（== 目录名，符合 agentskills.io 规范）；
  中文显示名/short_desc/description 全部迁入 metadata.i18n.<locale>
- agents/<id>/agent.json: shortDesc/fullDesc/tags/persona.{role,traits} 迁入
  i18n.<locale>；changelog[].changes 改为 { <locale>: string[] } 对象
- categories.json: 每个分类的 label/description 迁入 i18n.<locale>，顶层只剩
  color/icon
- manifest.json: 加 supportedLocales / defaultLocale；顶层 description 迁入
  i18n.<locale>

### Body 文件结构
- 根 SKILL.md = frontmatter + default_locale (en-US) body
- SKILL.<locale>.md = 各 locale 的 markdown body（首行 <!-- locale: xx --> 自校验）

### 工具链（scripts/i18n/）
- glossary.json: zh→en 术语表 + do_not_translate 白名单
- schema/skill-frontmatter.schema.json: i18n frontmatter JSON Schema
- validate-i18n.py: 8 条校验规则（name 合规 / locale 完整性 / hash 一致性等）
- translate.py: GitHub Models / Anthropic 双 backend，sha256 增量翻译
- migrate.py: 一次性迁移脚本（旧格式 → i18n 结构）

### CI（.github/workflows/）
- i18n-validate.yml: PR 触发跑 validate + translate --check
- i18n-translate.yml: PR 触发用 GitHub Models（默认 openai/gpt-5-mini）翻译缺失
  locale，自动追加 commit；可切到 ANTHROPIC_API_KEY 走 Claude

### 文档
- docs/I18N.md: 作者贡献指南（schema 说明 / 提交流程 / 常见问题）
- README.md: 加多语言段落

## 验证

- uv run scripts/i18n/validate-i18n.py: OK，49 文件 0 错误
- uv run scripts/i18n/translate.py --check: 0 stale locale
- 21 skills 标题数 zh-CN == en-US 严格对齐（最大 66=66）
- skills-ref 规范校验：全部通过（顶层 name ASCII slug + description 单字段）

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(i18n): 修复 PR #1 review 反馈的 6 项问题

- schema: translated_by 正则放宽为 ^(human|ai:[A-Za-z0-9._:/-]+)$，接受
  'ai:github:openai/gpt-5-mini' 这类 backend:model 形式（CI 翻译输出格式）
- README + docs/I18N.md: 修正"CI 用 Claude API"误导描述，正确说明默认是
  GitHub Models（openai/gpt-5-mini）+ GITHUB_TOKEN，可选切到 Anthropic
- skills/minimax-tts/SKILL.md & SKILL.zh-CN.md: 删除多余的 ``` 闭合，避免
  Markdown 后续渲染错乱
- skills/docx/SKILL.md: 翻译时丢失的 • Unicode escape 示例已恢复，
  与 zh-CN 版本对齐

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-05 00:26:33 +08:00
yi-ge
6ea6ddcec6 fix: 统一 DesireCore 智能体头像字符为 "D" 
市场中 desirecore 的 avatar.t 为"核"，与本地预设的 "D" 不一致，
统一为 "D" 以保持一致性。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-03-22 17:05:40 +08:00
yi-ge
89e68de812 feat: 上架 DesireCore 核心智能体，新增管理分类，精简 latestVersion 
- 新增 management 分类（系统管理与编排工具）
- 创建 DesireCore Agent 市场条目（id: desirecore, verified）
- 更新 manifest 统计（totalAgents: 1, lastUpdated: 2026-02-27）
- 移除 4 个 skill.json 中冗余的 latestVersion 字段（version 已够用）

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-27 20:28:51 +08:00
yi-ge
404af550da refactor: 移除旧版 agent.json 和 skill.json 文件 
移除已废弃的市场元数据文件：
- 6 个 agent.json（business-analyst, code-reviewer, data-analyst, task-master, translator, writing-coach）
- 5 个 skill.json（calendar-sync, doc-parser, email-client, file-manager, web-search）

版本信息已统一由 SKILL.md frontmatter 管理，skill.json 不再需要。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-02-27 19:43:19 +08:00
DesireCore
b09592338c Initial market data: 6 agents, 5 skills 2026-02-16 21:48:24 +08:00