Update the published team pointer to the reviewed team revision that
locks Lead and Evidence 0.1.1. Preview wording remains until
clean-install end-to-end acceptance is complete.
Co-authored-by: yige <yige@yigedeMacBook-Neo.local>
## What this changes
Adds the tender-review team and its onboarding entry to the official
Market catalog as an immutable source pointer, plus bilingual catalog
sidecars.
- `teams/biao-shu-lian-he-shen-cha/entry.json` points to the published
team commit `7ee5650b066cdee385288a722b8cbd8e1947d0fe`.
- `agents/tender-review-assistant/entry.json` points to assistant commit
`4b6855d2edb535f81c29847e06145c0da87942d0`.
- Both entries include bilingual descriptions, privacy boundaries and
`requiredClientVersion: 10.0.155`.
- The listing is deliberately `pointer` / preview. It does not claim the
v10.0.155 release is fully green or production-certified; newcomer
qualification remains pending.
## Validation
- `python3 scripts/catalog/validate_catalog_metadata.py --json` — 0
errors (existing catalog warnings unchanged).
- Market entry and both `catalog-metadata.v1.json` sidecars validate
against the current client/catalog schemas.
- Published source repositories and full commit pins were checked before
creating this branch.
---------
Co-authored-by: yige <yige@yigedeMacBook-Neo.local>
## Why
The C02 newcomer test exposed a missing-material preflight defect in the
contract-review lead. The corrected team release is already merged as
0.1.24; this PR publishes the exact team ref to the market.
## What changed
- Update the market pointer and catalog sidecar to contract-review-team
0.1.24.
- Pin both metadata surfaces to
`e096a74a482b55266753b3b93e179f9cac2f0ecd`.
- Publish contract-review-lead 1.0.12 in the team roster.
## Validation
- Parsed both market JSON files.
- Verified pointer, provenance, and reviewed refs are identical.
- Verified the remote team `main` ref matches the published pointer.
- Ran the catalog and i18n validators successfully; they reported only
pre-existing catalog warnings outside this team.
- Ran `git diff --check`.
## 中文说明
将市场中的合同审查团队发布指针升级到 0.1.24，并锁定已合并的团队提交。该版本包含统筹官 1.0.12
的无材料零工具咨询修复；entry、sidecar 的来源与审阅提交已一致，市场校验通过。
## Why
Publish the reviewed contract review team fix that was validated by a
fresh final18 real run. The prior run correctly fail-closed when
reporter artifacts escaped the lead case root and clauses.yaml was not
parseable.
## Changes
- bump marketplace entry/catalog to team 0.1.18
- point source/provenance/governance refs to merged team commit
6aa93bf11a6e37cc9d0444e3335ba953bee0a61f
- expose lead 1.0.10, clause 1.0.5, reporter 1.0.4 member versions
- retain legal disclaimer and source-pointer-only distribution
## Validation
- catalog validator exit 0
- i18n validator exit 0
- targeted JSON/ref assertions
- git diff --check
Publish Contract Review Team 0.1.12. Update entry/catalog to the merged
team ref d85b9244244c3b69718b2525b8ef4b8b7296f144, lead 1.0.8, and
current timestamps. Focused validators: metadata 47 passed, i18n 19
passed, collection 4 passed, JSON parse and diff-check pass; existing
catalog warnings unchanged.
## 中文
上一个 PR（#136）把两条能力边界写进了 `USAGE.md`。但 `USAGE.md` **刻意不进模型上下文**（ADR-143，与
`fullDesc` 分开正是为了不占每轮 token）——也就是说运行时模型并不知道这些边界，遇到 `851003` 仍会当故障重试。本 PR
把它们落到技能侧。
重新 pin 到内容仓库
[`ebb1903`](ebb19035bb)。
### 三条改动
**1. `wecom-shared` 新增「零之四：企业人数改变机器人的身份」**
| 企业规模 | 模式 | 以谁的身份调用 | 能否读到真人的东西 |
| --- | --- | --- | --- |
| ≤ 10 人 | 小团队模式 | 授权真人 | 能，继承其文档权限 |
| > 10 人 | 企业模式 | 机器人独立身份 | **不能** |
写明了它与既有「零之一」的分工——零之一管**写**（任何规模下只能写机器人自己建的），本条管**读**（>10
人连读都不继承）。给出正确动作：说明边界 + 建议把文档显式分享给机器人，而不是重试。并标注**这条不可自查**：CLI
没有查企业人数的接口，`identity whoami` 也不返回规模，只能从实际返回反推。来源为上游 issue #64 维护者确认。
此前这个概念只藏在 `wecomcli-smartsheet/references/smart-sheet-webhook.md`
里，是局部知识，而且表述成「写入接口被限制」——真实机制是身份不继承，本 PR 一并修正。
**2. `wecom-shared` 易错点补「方法描述里也有不存在的参数」**
比既有的「服务描述里有不存在的能力」更隐蔽：方法真的存在，只是做不到描述承诺的事。实测三处，`--schema` 请求体里根本没有对应字段：
| 方法 | 描述承诺 | 请求体实际只有 |
| --- | --- | --- |
| `calendar schedules cancel` | 周期日程需指定编辑规则 | `schedule_id` |
| `calendar schedules update` | 同上 | 11 个字段，无一是周期规则 |
| `meeting cancel` | 周期会议取消单次需指定子会议 ID | `meeting_id` |
这解释了 `wecomcli-calendar` / `wecomcli-meeting` 为何禁止操作周期日程——**不是技能保守，是 CLI
没暴露参数**。顺带把 `calendar` 的「日历本列表查询」补进既有的服务描述清单。
**3. `smartsheet get` 是 `sheets list` 的别名**
两者官方描述逐字相同、返回同一份子表列表。此前 `smartsheet get` 在整个仓库零字面出现，模型只能靠 `--help`
自己摸到，然后在两者之间犹豫。
### vendor 纪律
第 3 条与 webhook 归因修正都落在 **vendor 自上游的 `wecomcli-smartsheet`**
上。脚本头注释明确「不要手工编辑 `skills/wecomcli-*`，改动会在下次重跑时被无声抹掉」，所以走
`patches/snippets/` + `injections.tsv` 注入，不手工改文件。
`bash scripts/vendor-official-skills.sh` **连跑两次 diff 不变**，幂等成立；注入计数 6 →
8，脚本摘要与 tsv 注释同步更新。
### 条目改动
三处 ref 一起改（这次用全文扫 40 位 hex 复核，只剩一个值），`releasePublishedAt` 不动——版本仍 1.0.0：
- `entry.source.ref`
- `provenance.content.ref`
- `governance.compliance.reviewedRef`
推之前本地跑过 `uv run scripts/catalog/validate_catalog_metadata.py
--require-complete`：**0 error**（129 warning 为全仓存量）。
---
## English
#136 put two capability limits into `USAGE.md`, which is **deliberately
kept out of model context** (ADR-143). At runtime the model therefore
still doesn't know them and retries `851003` as a failure. This PR lands
them in the skills.
1. **`wecom-shared` gains "rule zero-four": corporation size changes the
bot's identity.** ≤10 people — the bot calls *as the authorizing user*
and inherits their document permissions; >10 — it calls under its own
identity and inherits nothing. Spelled out against the existing "rule
zero-one" (that one governs *writes*; this one governs *reads*). Marked
as non-self-checkable: no API returns the corporation size, so it can
only be inferred from responses. Source: upstream issue #64.
2. **A new pitfall: method descriptions also promise parameters that
don't exist** — subtler than the existing service-level note, since the
method does exist. Three verified cases where `--schema` has no such
field, which is precisely why the calendar/meeting skills forbid
recurring-event operations.
3. **`smartsheet get` is an alias of `sheets list`** — identical
official descriptions, same payload.
Items 2–3 touch vendored upstream skills, so they go through
`patches/snippets/` + `injections.tsv` rather than hand edits; the
vendor script is idempotent across two consecutive runs. Catalog
validator reports 0 errors locally before pushing.
## 中文
企业微信助手的市场详情页「使用说明」区此前为空。内容仓库
[`desirecore-agent/wecom-assistant@047928a`](047928afe1)
新增 `USAGE.md`，本 PR 把条目重新 pin 过去。
### 为什么要写这两条
它们都是**装之前**该知道、且**装完也改不了**的边界，正是 `USAGE.md` 的定位（ADR-143：与 `fullDesc`
分开，不进模型上下文）。
**1. 群聊历史目前仅对 ≤10 人企业开放。** 官方错误码 `853001` 的释义原文如此。实际触发返回相邻的 `853006`：
```
errcode: 853006
errmsg: this tool is not available for your corporation
```
措辞是 **for your
corporation**，不是「机器人未开通某品类」——所以让用户去找管理员开通品类是无效动作。本机实测复现，同一凭证下其余 12
个服务域全部正常，`chat` 是唯一被拒的域。上游 `WecomTeam/wecom-cli` #106 / #107 / #132 三个
issue 都在追这件事，截至提交时全部 OPEN、官方未回复。
**2. 同一条命令在不同规模的企业行为不同，而且不报错。** 上游维护者在 issue #64 确认：≤10
人「小团队模式」机器人以**授权用户身份**调用、继承其文档权限；>10
人「企业模式」机器人以**独立身份**调用、不继承。后果是同事分享给你的文档，小公司读得到、大公司读同一份返回
`851003`。这不是故障，但不写出来必然被当成故障反复重试。
顺带记入第三条与规模无关的边界：`wecom-cli identity whoami`
返回原文「只能写入或修改机器人创建或拥有的数据」——这是邮件署名固定为「XXX的机器人」、用户对助手所建文档反而没有管理权的根因。
### 条目改动
pointer 条目的 `USAGE.md` 由客户端从内容仓库**按 pinned ref** 抓取（`sync/market.ts` 的
`pointerUsage` ← `code-repo/file-fetcher.ts`），所以只推内容仓库不改 ref
的话客户端看不到。四处一起改，保持 ADR-137 证据链自洽：
| 字段 | 旧 | 新 |
| --- | --- | --- |
| `entry.source.ref` | `665ab1d2` | `047928a` |
| `compliance.reviewedRef` | `665ab1d2` | `047928a` |
| `compliance.reviewedAt` | 2026-09-04 | 2026-09-06 |
| `timestamps.reviewedAt.value` | 2026-09-04 | 2026-09-06 |
| `timestamps.catalogUpdatedAt.value` | 2026-09-04 | 2026-09-06 |
`releasePublishedAt` **不动**——版本仍是 1.0.0，本次只增文档。
已核对：`reviewedRef === source.ref`、`timestamps.reviewedAt ===
compliance.reviewedAt`、`availability: installable`、`license.state:
known`、compliance 五项必填齐全、ref 为 40 位 SHA、`repoUrl` 在官方前缀内。
### 证据等级
| 结论 | 来源 |
| --- | --- |
| `853006` 错误原文与触发条件 | 本机实测复现 |
| 「仅对 ≤10 人企业开放」 | 官方错误码 `853001` 释义 |
| 小团队 / 企业模式身份差异 | 上游 issue #64 维护者确认 |
| 「只能写入机器人拥有的数据」 | `identity whoami` 返回原文 |
| 群聊 7 天限制 | `chat messages list` 的 `begin_time` 字段 schema |
**未核实**：`853006` 的具体判定标准（是否严格按人数、有无灰度名单）与开通路径，官方未公开、上游 issue
未获回复。`USAGE.md` 里已如实标注。
### 追加：一并修正 docs 的 853006 归因
同一 ref 里还带了内容仓库
[`047928a`](047928afe1)
的一处事实修正。原 docs 把 `853006` 写成「机器人未开通『群聊会话』品类」，并给出
「要让它可用：为机器人开通群聊会话品类」——**这是让用户去做一件做不成的事**。
改了 6 处（`04-群聊历史` 四处、`README` / `01-快速开始` / `99-风险与确认` 各处），
只纠正群聊这一处的归因，**不动「能力按品类逐项开通」这条通则**——那条对 `850002`
依然成立。技能侧（`wecom-shared` / `wecom-workflows` / `wecomcli-message`）本就写的是
「企业级不可用」，本次是让 docs 与技能口径一致。
---
## English
The agent detail page's "Usage" section was empty for the WeCom
assistant. The content repo now carries a `USAGE.md`; this PR repins the
listing to it.
It documents two limits that a reader needs **before** installing and
cannot change afterwards:
1. **Chat history is currently limited to corporations of 10 people or
fewer.** Official error `853001` states this; the actual response is
`853006 this tool is not available for your corporation` — the wording
is *corporation*, not *bot*, so asking an admin to enable a bot
capability is a dead end. Reproduced locally; all 12 other service
domains work under the same credential. Upstream issues #106 / #107 /
#132 all remain OPEN with no official response.
2. **The same command behaves differently by corporation size, without
erroring.** Per the upstream maintainer in issue #64, bots in ≤10-person
"small team mode" call **as the authorizing user** and inherit their
document permissions; in ">10 person" enterprise mode they call **under
their own identity** and do not. A doc shared with you is readable in a
small company and returns `851003` in a large one.
A pointer listing's `USAGE.md` is fetched from the content repo **at the
pinned ref**, so `source.ref` and the ref-bound compliance evidence are
updated together to keep the ADR-137 chain self-consistent.
`releasePublishedAt` is unchanged — still 1.0.0, docs only.
## Why / 背景
The market entry still pointed at team v0.1.5. Its pinned member lock
used stale agent manifests whose `command_authority.allowed_targets` did
not match the installed runtime IDs, so a fresh newcomer install could
pass catalog discovery but block the first delegation. The upstream team
main is now v0.1.6 with the corrected lock and member versions.
市场条目仍指向 v0.1.5。其成员锁引用了旧 Agent
manifest，`command_authority.allowed_targets` 与安装后的 runtime ID
不一致，导致新人实例虽然能发现团队，却会在首次委派时被阻断。上游团队 main 已更新到 v0.1.6，成员锁和版本已修正。
## What changed / 变更
- bump `latestVersion` and `release.version` to `0.1.6`;
- point entry source, catalog provenance, and compliance `reviewedRef`
to upstream team commit `3a4736e31ff5bf4299fde17fdde682a179d898b2`;
- align all six listed member versions with the upstream
`members.lock.json` (lead 1.0.4, intake 1.0.1, clause 1.0.2, risk 1.0.2,
jurisdiction 1.2.1, reporter 1.0.1);
- update release and upstream observation timestamps.
- 将 `latestVersion` 与 `release.version` 更新为 `0.1.6`；
- 将 entry source、catalog provenance 和 compliance `reviewedRef` 对齐上游团队
commit `3a4736e31ff5bf4299fde17fdde682a179d898b2`；
- 六名成员版本与上游 `members.lock.json` 对齐（统筹 1.0.4、输入 1.0.1、条款 1.0.2、风险
1.0.2、法域 1.2.1、报告 1.0.1）；
- 更新发布时间与上游观察时间。
## Validation / 验证
- `uv run scripts/catalog/validate_catalog_metadata.py --json` — exit 0,
0 errors, 129 existing warnings;
- `uv run scripts/i18n/validate-i18n.py` — exit 0;
- `uv run scripts/catalog/test_validate_catalog_metadata.py` — 47
passed;
- `uv run scripts/i18n/test_validate_i18n.py` — 19 passed;
- `uv run scripts/catalog/test_collection_generator.py` — 4 passed;
- independent GPT-Reserve reviews — PASS, P0/P1/P2/P3=0;
- `git diff --check` — passed.
- `uv run scripts/catalog/validate_catalog_metadata.py --json`：exit 0，0
errors，129 个既有 warnings；
- `uv run scripts/i18n/validate-i18n.py`：exit 0；
- `uv run scripts/catalog/test_validate_catalog_metadata.py`：47 passed；
- `uv run scripts/i18n/test_validate_i18n.py`：19 passed；
- `uv run scripts/catalog/test_collection_generator.py`：4 passed；
- 两次独立 GPT-Reserve 复审：PASS，P0/P1/P2/P3=0；
- `git diff --check`：通过。
## Changes\n- publish contract-review-team v0.1.5\n- point entry and
catalog metadata at merged team main commit
2a45d9fc031ba7d63d3ec15552ef0bc4c3a2b46e\n- align clause-extractor
roster version to 1.0.2\n- advance release timestamps to
2026-09-06T10:02:16Z, after team lock resolvedAt
2026-09-06T09:56:11.162Z\n- preserve Work Context description and all
unrelated metadata\n\n## Validation\n- team entry schema: PASS\n-
catalog metadata validator: PASS (existing repository warnings only)\n-
i18n validator: PASS (0 errors, 129 existing warnings)\n- collection
generator tests: 4 passed\n- git diff --check: PASS\n\nPlease review
independently; do not merge automatically.
Publish team 0.1.4 with the merged lead manifest version/hash lock. Independent GPT-Reserve review PASS; Copilot approval recommended; market validators/tests PASS.
Publish contract review team 0.1.3 with Work Context orchestration compatibility and aligned publication provenance timestamps. Independent GPT-Reserve review PASS; market validators and tests PASS; Copilot concern resolved with timestamp fix.
Align the market roster jurisdiction-auditor version with the published
team lock. Independent GPT-Reserve review passed; canonical market
validators and tests pass.
Publish contract review team 0.1.2 with runtime Agent IDs in command
authority and update the catalog metadata to the merged team lock
commit. Independent GPT-Reserve review passed; canonical market
validators report 0 errors.
## Why / 背景
The pinned team release `73cd87a9901cc548871927e9d5dbec8e4cc6c2b1`
contains `jurisdiction-auditor` version `1.0.0`, but the merged market
entry advertised `1.2.0`. That metadata mismatch makes a valid pinned
release fail exact roster validation during newcomer installation.
团队发布锁 `73cd87a9901cc548871927e9d5dbec8e4cc6c2b1` 中的
`jurisdiction-auditor` 实际版本为 `1.0.0`，已合并的市场条目却写成
`1.2.0`。该元数据不一致会让新人安装时的精确 roster 校验拒绝有效的 pinned release。
## What changed / 变更
- Set only the market roster version for `jurisdiction-auditor` back to
`1.0.0`.
- Keep the pinned source ref, member commits, content hashes, governance
sidecar, and all other members unchanged.
- 仅将市场 roster 中 `jurisdiction-auditor` 的版本恢复为 `1.0.0`。
- pinned source ref、成员 commit、content hash、治理 sidecar 与其他成员均保持不变。
## Validation / 验证
- `uv run scripts/catalog/validate_catalog_metadata.py --json` — 0
errors, 129 existing warnings
- `uv run scripts/catalog/test_validate_catalog_metadata.py` — 47 passed
- `uv run scripts/catalog/test_collection_generator.py` — 4 passed
- `uv run scripts/i18n/validate-i18n.py` — 0 errors, existing warnings
only
- public-tree sensitive-pattern scan — zero matches
## Why
The team source lock declares `jurisdiction-auditor` at version `1.2.0`,
while the market roster still said `1.0.0`. DesireCore correctly
rejected the install because market member versions must match the
pinned team release.
## What changed
- update the market roster entry for `jurisdiction-auditor` to `1.2.0`;
- leave the pinned team source, commit, governance evidence, and all
other members unchanged.
## Validation
- `uv run scripts/catalog/validate_catalog_metadata.py --json` — 0
errors, 129 existing warnings
- public-tree sensitive-pattern scan — zero matches
## Why
The published pointer advertises client version `10.0.137`, while the
current DesireCore release is `10.0.136`. The newcomer instance
therefore correctly blocks installation even though the team source is
compatible with the current client.
## What changed
- align the team pointer's `requiredClientVersion` with the current
client version;
- align the catalog sidecar's compatibility declaration with the same
version.
No source pointer, team member, capability, privacy, or governance claim
changed.
## Validation
- `uv run scripts/catalog/validate_catalog_metadata.py --json` — 0
errors, 129 existing warnings
- `uv run scripts/catalog/test_validate_catalog_metadata.py` — 47 passed
- `uv run scripts/catalog/test_collection_generator.py` — 4 passed
- public-tree sensitive-pattern scan — zero matches
## Why
The contract review team already has a reproducible public Git source,
but its market pointer is still listing-only and uses the legacy
display-only shape. The current DesireCore client contract requires
explicit members, capabilities, privacy, an immutable source ref, and
installability evidence.
## What changed
- publish the contract review team as an installable,
source-pointer-only team entry;
- add the six-member roster, capability boundaries, privacy notice, and
update date;
- record review and license evidence in the catalog sidecar;
- keep the legacy team-entry schema branch while adding the current
client contract, so existing public pointers remain valid during
migration.
The source remains a public HTTPS Git pointer locked to commit
`73cd87a9901cc548871927e9d5dbec8e4cc6c2b1`. The team output is
supporting review material, not legal advice, and still requires
qualified human review.
## Validation
- `uv run scripts/catalog/validate_catalog_metadata.py --json` — 0
errors, 129 existing warnings
- `uv run scripts/catalog/test_validate_catalog_metadata.py` — 47 passed
- `uv run scripts/catalog/test_collection_generator.py` — 4 passed
- `uv run scripts/i18n/validate-i18n.py` — no errors; existing catalog
freshness warnings remain
- public-tree sensitive-pattern scan — zero matches
## 问题 / Problem
`scripts/catalog/__pycache__/validate_catalog_metadata.cpython-314.pyc`（60KB）在
#118 被误提交进仓库。
它是跑仓库校验脚本时的就地产物，**会随 `defaults/market.zip` 分发给每一个客户端**，而且只对生成它的那个 Python
版本（3.14）有效——换个版本就是纯粹的死重量。
本仓库此前**没有 `.gitignore`**，所以这类产物每次都得靠人眼发现。
A Python bytecode artifact was accidentally committed in #118. It ships
to every client inside `defaults/market.zip` and is only valid for the
exact Python version that produced it. The repository had no
`.gitignore` at all, so nothing prevented it.
## 改动 / Changes
- 删除该 `.pyc`
- 新增 `.gitignore`：`__pycache__/`、`*.py[cod]`、`.DS_Store`
## 与主仓库那道闸门的关系 / Relation to the upstream guard
desirecore/desirecore#2602 已让 `sync-market`
在同步目录不干净时拒绝打包——今天正是它拦下了我本机跑校验产生的 `cpython-310.pyc`：
```
Error: [sync-market] 同步目录存在未提交内容，拒绝打包：
?? scripts/catalog/__pycache__/validate_catalog_metadata.cpython-310.pyc
```
但那道断言只看**未提交内容**，拦不住已经进了仓库的 `cpython-314.pyc`。两处配合才完整：`.gitignore`
防止它被提交，洁净断言防止未提交残留被打包。
## 验证 / Verification
- `validate_catalog_metadata.py --require-complete`：0 error，75 sidecars
- `validate-i18n.py`：0 error
- 新增 `.gitignore` 后重跑校验，新产生的字节码不再出现在 `git status` 中
Co-authored-by: yi-ge <jackyoncode@gmail.com>
## 问题 / 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.
## 中文
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`.
## 中文
把「企业微信助手」从 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.
