mirror of
https://git.openapi.site/https://github.com/desirecore/market.git
synced 2026-09-05 15:33:52 +08:00
Yige
e77c658958
## 变更 / What
市场此前只有 `agents` 与 `skills` 两类条目。本 PR 加入**团队（teams）**条目类型，并上架第一条真实团队
listing。
The market supported only `agents` and `skills`. This PR adds a
**teams** entry type and lists the first real team.
## 一、支持团队条目类型
「支持一种新条目类型」实际涉及 4 组共 11 个文件，比表面看到的多：
**客户端契约快照**
- 新增 `schemas/market-team-entry.client.schema.json`，用 esbuild 打包客户端
`packages/schemas/src/market.ts` 后导出生成。用同样方法重新生成
`market-agent-entry.client.schema.json` 验证过管线——字节完全一致（含属性顺序），确认不是手工誊抄。
**Sidecar schema**
- `identity.kind` 枚举加 `team`；新增 `$defs.teamSpec`；接入 `spec.oneOf` 与
kind→spec 派发
**校验器（工作量主要在这里）**
- `scripts/catalog/validate_catalog_metadata.py`：`load_legacy`
原先硬编码只认两个根目录。抽出 `CATALOG_ROOTS` 常量同时驱动允许的父目录集合与错误文案；按 kind 分派客户端 schema
校验；`teams` 进 stats 与 `--require-complete` 覆盖统计；把**严格 provenance
比对**与「可安装 pointer 必须自带不可变 ref」两道门禁扩展到团队
- `scripts/i18n/validate-i18n.py`：**它独立重算计数并逐个校验 `entry.json`**，不接团队会漏校
- `.github/workflows/i18n-validate.yml`：变更检测的 grep 不含 `teams/`——**一个只改
teams 的 PR 会报「无 i18n 相关变更，跳过校验」然后零校验通过**
- 测试：`test_validate_catalog_metadata.py` 29→47，`test_validate_i18n.py`
9→17
**顺带修正一条本就不对的规则**：`icon` 此前被要求「每个 entry.json 都必须有非空内联 SVG」，但运行时 schema 里
`marketAgentSchema` 与 `marketTeamSchema` **都没有 `icon` 字段**（只有 skill
有）。也就是说这条规则对 Agent pointer 同样在强加死重量，只因本仓库暂无 agent pointer 条目而未暴露。改为
`ICON_RENDERED_KINDS = {"skill"}`，agent/team 声明 icon
时给**警告**而非错误，文案说明「下一个维护者会以为改它能改变卡片」。
## 二、上架合同审查团队
`teams/contract-review-team/`（`entry.json` + sidecar）。
**团队条目是 fork 指针卡，不分发正文**：市场只存展示元数据 + git-only `source`，真实定义（`team.json`
/ `members.json` / `shared/`）在 `source.repoUrl` 指向的仓库里。安装即
`forkTeam`，更新即 `git pull`——组合固定，因此**没有** `installPolicy` /
`updatePolicy`。
| 字段 | 值 | 依据 |
|---|---|---|
| `source.ref` | `73cd87a9901cc548871927e9d5dbec8e4cc6c2b1` | v0.1.1
的**完整 SHA**。tag 不是可复现 pin，validator 有测试专门拒绝 |
| `latestVersion` | `0.1.1` | 上游真实 tag，与 `release.version` 交叉校验 |
| `license` | `MIT` | 上游仓库真有 LICENSE，已在 pinned ref 的快照中复验 |
| `redistribution` | `source-pointer-only` |
市场从不打包团队正文，只给指针——这是交付形态，与许可证宽松与否无关 |
| `requiredClientVersion` | `10.0.137` | 六个成员都声明了 `FileDigest`
内置工具，它随该版本发布 |
| `memberCount` / `memberNames` | 6 / 5 名 | schema 规定前者**含**组长、后者**不含**
|
| `availability` | `listing-only` | 见下 |
**`availability` 为什么不是 `installable`**：四项证据满足两项（不可变 pin ✓、已知 license
✓），缺的 `reviewedAt` 与 `governance.compliance`
本质是**一次尚未发生的治理审查**——需要具名方在具体日期针对这个确切 ref 审过许可合规、第三方内容与商标使用。没发生的事不能写进目录。
补充一个事实：本仓库**零个 sidecar 有 `compliance` 块，29 个 pointer 条目全是
listing-only**，`installable` 路径从未在任何真实条目上走过。这不阻止安装——fork 由 `source` 驱动。
**`license.evidencePath` 的基准此前是未定义的**：schema 只说
`safeRelativePath`，没规定相对谁。仓库里仅有的两个先例（`guizang-ppt`、`presentation-forge`）都是
vendored 技能，LICENSE 物理上在条目目录里。按那个读法，pointer 条目写 `evidencePath`
断言的是市场目录下有该文件——对 pointer 永远不成立。新增 `license-evidence` 规则按条目形态分派：vendored
要求文件存在（error），pointer 要求条目已 pin（warning），两种读法写进 README。
## 校验 / Validation
```
test_validate_catalog_metadata.py 47 tests OK
test_validate_i18n.py 17 tests OK
test_collection_generator.py exit 0
validate_catalog_metadata.py --require-complete
0 error, 116 warning (agents=1, teams=1, publishableSkills=62, sidecars=64)
validate-i18n.py / --online 0 error, 116 warning
translate.py --check exit 0
gen-collection-children.py --check exit 0
```
116 warnings 即加入团队之前的基线——**本条 listing 贡献 0 个警告**。
真实条目上的反向控制（跑在 rsync 副本上，仓库保持干净）：
```
source.kind=zip → team-entry-schema (error)
install/updatePolicy 出现 → team-entry-schema (error)
requiredClientVersion 漂移 → legacy-consistency (error)
memberCount 漂移 → legacy-consistency (error)
provenance ref 漂移 → legacy-consistency (error)
可安装但无不可变 ref → installable-evidence (error)
evidencePath 在未 pin 的 pointer → license-evidence (warning)
```
另用**客户端真实校验器**（`parseMarketTeamEntry`，不是快照）验证条目通过，且多写一个字段会被拒。
## 公开信息边界 / Public information boundary
全树扫描无新增命中。团队内容使用「某某科技（北京）有限公司」这类标准中文占位。
---------
Co-authored-by: yi-ge <mizan57533@gmail.com>
70 lines
3.4 KiB
Markdown
70 lines
3.4 KiB
Markdown
# AGENTS.md
|
|
|
|
This repository is a public marketplace. Every contribution must be reusable,
|
|
customer-neutral, and safe to index publicly.
|
|
|
|
## Public information boundary
|
|
|
|
- Never put a tenant, customer, prospect, partner, or other confidential identity
|
|
in tracked files, paths, filenames, Agent, Team or Skill IDs, frontmatter, descriptions,
|
|
examples, fixtures, memories, generated artifacts, or screenshots.
|
|
- Apply the same rule to Git metadata and collaboration text: branch names, commit
|
|
subjects and bodies, PR or issue titles and bodies, comments, and review replies.
|
|
- Describe reusable capabilities with domain-neutral roles and entities. Put
|
|
customer-specific prompts, facts, mappings, examples, data, and deployment
|
|
settings only in private AgentFS homes, private repositories, or private runtime
|
|
configuration.
|
|
- Do not add a real confidential token to a denylist, test fixture, documentation,
|
|
or example. A literal denylist in a public repository creates a second leak.
|
|
|
|
## External dependency disclosure
|
|
|
|
- A Skill, Agent or Team that relies on separately licensed, purchased, hosted, or
|
|
deployed third-party software must disclose that dependency in its discovery
|
|
description, `compatibility` field, localized marketplace text, and execution
|
|
instructions.
|
|
- Distinguish an included connector or adapter Tool from the external product it
|
|
accesses. Never imply that registering a Tool bundles, licenses, installs, pays
|
|
for, or operates the third-party product.
|
|
- State the operator prerequisites, applicable licensing or usage terms, separate
|
|
costs when relevant, connection readiness checks, and safe degraded behavior.
|
|
If the dependency is unavailable, stop before the external call and never
|
|
fabricate a successful result.
|
|
|
|
## Required pre-publication check
|
|
|
|
Before committing or opening/updating a PR:
|
|
|
|
1. Obtain the sensitive tokens through a private channel and keep them outside the
|
|
repository.
|
|
2. Scan the complete working tree, including hidden files while excluding `.git`.
|
|
3. Scan new path names, branch names, commit subjects and bodies, and the proposed
|
|
PR/issue/review text.
|
|
4. Review examples semantically: changing a proper noun is insufficient when an
|
|
example still exposes a customer-specific organization shape or private fact.
|
|
5. Run the repository validation and translation-freshness checks documented in
|
|
`README.md`.
|
|
|
|
A zero-result scan is a release requirement. Record only that the check passed;
|
|
never persist the confidential search tokens or command history in the repository.
|
|
|
|
## Incident response
|
|
|
|
If confidential identity or data reaches the public repository:
|
|
|
|
1. Stop the merge or release and neutralize all editable GitHub metadata.
|
|
2. Replace the public content with a genuinely reusable abstraction; do not merely
|
|
rename the customer.
|
|
3. If reachable Git history is affected, make a mirror backup, rewrite only the
|
|
affected history, verify expected tree objects, push with an exact lease, and
|
|
restore branch protections immediately.
|
|
4. Treat pull-request refs, cached views, reviews, notifications, and search-engine
|
|
caches as separate surfaces. Follow the hosting provider's sensitive-data
|
|
removal process instead of claiming that a force-push removed them.
|
|
5. Re-run all publication checks before reopening or merging work.
|
|
|
|
## Instruction synchronization
|
|
|
|
`AGENTS.md` and `CLAUDE.md` are equivalent repository policy entrypoints. Any
|
|
substantive change to one must be made to the other in the same commit.
|