「最小 ipedia-meta」长什么样？——匿名示例、键对照与用途边界
HDGP protocols：匿名形状示例 + 键对照 + 机检/摘要/验稿边界；与字段导读、tag/发布面两篇互补，不把双轨当主轴。
摘要（结论先行）
7 条要点；与下方 ipedia-meta 中 summary 数组逐字一致。
- 仅有「一份合法 JSON」并不代表读者或 CI 已理解其约束；`ipedia-meta` 的价值在于键语义稳定、可与正文与编辑政策交叉核对，而不仅是语法可通过校验。
- 文内匿名示例采用与 IPedia 模板一致的 `ipedia-meta` 内联 JSON 形态，示例内 `summary` 为 5 条；正式稿件通常 `summary` 为 7 条并与文首列表逐字一致。
- 键对照表逐项说明各键的人类可读含义，并标出与 §2–§4 的对应关系，便于把「字段责任」从「段落修辞」里拆出来。
- 在用途边界上：机检侧重可解析与必填字段齐全及轨道单选；对外搜索摘要可安全复用 `title` 与 `summary`；主系统验稿仍以正文与站内政策为准，Meta 不能替代法务或监管结论。
- 反模式包括：嵌入示例与正文事实冲突、`summary` 条数与文首列表不一致、在 Meta 中暗示已具备 Judge、Engine、认证或监管背书。
- 与 HDGP-Core 的关系限于 Meta-only 字段语义对齐；本示例使用虚构项目与虚构链接，不暗示已绑定某 tag、某发布面或任何生产部署。
- 延伸阅读以中性锚文本链向两篇 protocols 与 governance 三文，避免本篇重复展开双轨叙事或合规导流细则。
正文
读者任务 → 匿名示例块 → 键对照表 → 用途边界与反模式 → HDGP-Core 一句 → 延伸阅读。
1. 读者任务：为什么「有一份 JSON」还不够
语法上合法的 JSON 只保证能被解析；ipedia-meta 在 IPedia 流程里承担的是契约头：同一页面上，机器、搜索摘要生成器、编辑与（若接入的）主系统验稿脚本，都应能读到同一套键并得到不与正文打架的结论。若键齐全但语义与正文矛盾，或
summary 与文首列表字数不同，则「有 JSON」反而放大误读——读者会以为机检已通过即代表内容已获背书。
关于 Meta-only 与运行时、双轨、承诺过度的完整讨论，请参阅 governance 轨三篇及前两篇 protocols（见下文「延伸阅读」）；本篇只保留上段定位，不展开成长论述。
2. 匿名示例：最小内联块（summary 示例 5 条；正式稿常扩至 7 条）
下面示例使用虚构项目名 Riverbend Meta Lab 与 example.org 下虚构路径（RFC 保留用途域名，非真实产品主页）。字符串内不使用裸 ASCII 双引号 U+0022，统一用中文直角引号「」包裹需强调的短语，避免嵌套引号截断内联 JSON。
说明：页面顶部 id="ipedia-meta" 为本篇真实稿件元数据；下列 id="riverbend-meta-shape-demo" 仅为形状演示，避免与机检用的唯一 ipedia-meta 冲突。
正式稿件仍须满足仓库内公开文档《IPedia 文章验收工作流》（docs/IPEDIA_ARTICLE_AUDIT_WORKFLOW_v1.md）与随稿校验脚本所约定的最小字段集；summary
条数允许 3–7，IPedia 当前惯例为 7 条并与文首 <li> 逐字一致——精神同「先写可机读摘要、再写人读正文」，不必抄具体校验脚本。文章 HTML 骨架见
IPedia 仓库中的 article-template.v1.html（GitHub）。
3. 键对照表（键名 → 含义 → 正文位置）
| 键名 | 人类可读含义（一句话） | 与正文关系 |
|---|---|---|
title |
页面主标题；宜与 <h1> 一致或显式声明差异规则 |
§2 示例 title；§4 勿与正文标题语义冲突 |
summary |
3–7 条短句；正式稿须与文首摘要列表逐字一致（本篇顶部 ipedia-meta 为 7 条）。§2 Riverbend 块仅 5 条，属刻意缩略的演示形态，不是生产稿形态。
|
§2 演示 5 条 vs 本篇正式 7 条的对照见上；§4 禁止正式稿在条数或措辞上与文首列表不一致。 |
track |
三选一：hdgp / xyrang / intdone；本篇固定 hdgp | §4 禁止跨轨串题 |
category |
栏目 slug；本篇为 protocols | 与 governance 栏目区分 |
intent |
explain / compare / migrate / compliance / index 等 | 影响检索归类；勿与正文体裁矛盾 |
audience |
读者画像；含 G=Government 时与全站 HDGP 文一致 | §2 示例已对齐全站口径 |
risk_tags |
风险域标签；仅用站内已稳定枚举（如 misinfo、security、abuse） | 勿引入未定论枚举名 |
scope_boundary |
「不做什么、不承诺什么」的可解析陈述 | §4 禁止写进运行时能力暗示 |
sources |
≥2 条 {title,url}；须 HTTPS、无追踪参数 | 示例用虚构 URL；真稿须可验证权威链 |
updated_at |
ISO 日期或 YYYY-MM-DD | 可与 doc-release-tag-and-published-surface 一文对照发布面 |
relationship_disclosure |
利益关系与维护方披露 | 与编辑规范关联方口径一致 |
4. 用途边界与反模式（短）
机检：解析成功、必填键存在、track 单选、sources 数量与 URL 形态合法。
搜索摘要：可复用 title + summary 作 snippet，前提是 summary 已与正文对齐，否则会「摘要卖一件、正文讲另一件」。
主系统验稿：Meta 是输入线索，不是判决书；法务、监管与采购结论仍在正文与政策文档链中完成。
反模式：① 示例 JSON 写「不提供法律意见」而正文仍做合规结论式表述；② 文首 7 条与 summary 数组长度或文字不一致；③ 在 scope_boundary 或 summary 里写「已通过某认证」「默认开启 Judge」等——均与 Meta-only 及 IPedia 禁区精神冲突。
5. 与 HDGP-Core 的一句关系
HDGP-Core 提供 Meta-only 字段语义参考；本篇示例体现键名与边界语言可对齐，不暗示 Riverbend 或任何真实部署已绑定某 Git tag、某静态发布面或 Judge/Engine；与第二篇 protocols 的「发布面与 tag」主题仅作呼应，不重复论证。
6. 延伸阅读（中性锚文本）
protocols
governance
来源与引用
2 个可验证入口；与 ipedia-meta.sources 一致。
- HDGP-Core（Meta-only baseline）· core.hdgp-protocol.com （镜像 GitHub Pages； 仓库 GitHub） —— Meta-only 字段语义与声明层对齐的事实锚点。
- Introducing JSON —— 合法 JSON 与内联解析的公开说明；与 §2 引用点一致。
边界声明
置于来源之后；与 ipedia-meta.scope_boundary 一致。
- 本文不提供法律意见或监管背书；不承诺文末 JSON 草稿或文内匿名示例可不经人工终审直接用于生产。
- 不评价具体产品或部署是否满足某法规；不暗示对齐 HDGP-Core 字段语义即等同于已部署 Judge、Engine 或已获得任何认证。
- 不代表主系统、PFaaS 或商业交付方立场。
更新记录
首发与主系统验稿后修订的对外记录。
-
2026-05-15：外部通读与读者体验 — protocols 三篇统一移除正文「关于 slug」内部说明；本篇键对照表显式区分 §2 Riverbend 演示（5 条）与页顶正式
ipedia-meta（7 条）；§2 文章 HTML 骨架改指 GitHub 公开链。 -
2026-05-15：主系统侧验稿 Accept；§2「最小字段集」改指仓库内工作流文档路径；
ipedia-meta.updated_at与页眉标签同步为 2026-05-15。 -
2026-05-14：首发定稿 — JSON（
ipedia-meta）、摘要 7 条、正文六节、Riverbend 演示块（独立 id）、键对照表、来源 2 条（GitHub + json.org）及后置边界声明；栏目protocols。