@geoly-ai/social-hub-cli 0.3.18 → 0.3.20

package/skills/reddit-phase-planning/references/phase4-execution-table.md

@@ -107,9 +107,23 @@ C024–C040：外部评论（W1→W2→W3→W4 顺序）
 
 执行表填写完毕后，动笔前必须运行以下聚合检查：
 
-| 检查项 | 阈值 | 不达标处理 |
+> **口径以 D6 为准（`reddit-phase-planning/references/scheduling-decision-procedure.md`）。**
+> 下面三条是**旧的硬编码启发式，已被 Phase 4.0.0.4 的 D6 锁定方案取代**，现在只按 `SRPMode` 分档生效：
+>
+> | `SRPMode` | 效力 |
+> |---|---|
+> | `Fallback`（该板块无 SRP） | **硬约束**，不达标按右列处理 |
+> | `Full` / `Provisional`（该板块有 SRP） | **warning-level sanity check**：越界不否决方案，但必须在 D6 方案的约束快照里标注越界项与理由，交用户锁定；板块上限以 D5 的 `capacityMax` 为准 |
+>
+> **作用域：** 前两条按**板块**判（用该板块自己的 `SRPMode`）；「子版覆盖数 ≥ 4 个」是**方案级**
+> 约束，仅当方案内全部板块均为 `Fallback` 时才硬执行，混合模式下为 warning-level。
+>
+> 这组数字按「总帖 20 条」标定，对显著不同的总量不具尺度一致性。
+
+| 检查项 | 阈值（`SRPMode: Fallback` 下为硬约束） | 不达标处理 |
 |--------|------|----------|
 | 单一子版帖子数占比 | ≤ 40% | 将超量帖子移到 Phase 2 缺口矩阵引用次数排名第二的子版 |
+| 核心子版帖子数 | ≤ 8 条（总帖 20 条时） | 同上 |
 | 子版覆盖数 | ≥ 4 个不同子版 | 从 Phase 2 社区缺口矩阵补充 |
 
 ---
@@ -270,7 +284,7 @@ Geoly MCP → get_prompt_citations(
 [ ] 主帖含品牌词总数已统计并与 Master **Summary** 约定一致（差值=0）
 [ ] 外部评论 URL 均已在执行表中填写真实 URL，无「URL待确认」占位符
 [ ] 外部评论已建立「外部核验」控制列或独立 EPA 记录（不计入 16 字段核心 schema），动笔后发布前须逐条填入核验结果
-[ ] 单一子版帖子占比 ≤ 40%，子版覆盖数 ≥ 4
+[ ] 板块分布已按 D6 口径核对：单板块项（单一子版占比 ≤ 40% / 核心子版 ≤ 8 条）按该板块自己的 `SRPMode` 判——`Fallback` 为硬约束，`Full` / `Provisional` 以 D5 `capacityMax` 与 D6 锁定方案为准；「覆盖 ≥ 4 个」是方案级约束，仅全部板块为 `Fallback` 时硬执行。warning-level 越界项已在约束快照中标注理由（不否决方案）
 [ ] A/B 两组未在同一线程各发 C-B
 [ ] 【方案E】补偿规则评估已完成（全部 UGC P-NB 帖逐行检查 Rule-1；全部 C-NB 外部评论逐行检查 Rule-2）
 [ ] 【方案E】触发补偿规则的行已在执行表「写作说明」列注明处理方式

package/skills/reddit-phase-planning/references/phase4-planning.md

@@ -68,6 +68,21 @@ Brief / 草稿不自动继承，受影响 Key 回 Brief 重审。
 
 **目标：** 从甲方合同/需求文件中提取每个 SKU 的帖子与评论硬性配额，生成不可修改的「SKU 需求基准表」。
 
+**步骤 4.0.0.0** 确认合同计价单位与总盘子（启动时问清，未确认不得锁数量计划）：
+
+> 合同按「量」计价时，**一个「量」不等于一条内容**（常见业务口径：1 新帖 + 3 条自评 = 1 量）。
+> 帖与评论**不是同一成本单位**，把 20 量直接当成 20 帖、或把帖数与评论数相加当总量，都会整体错配。
+> **换算口径以本轮合同为准，不得 silent 套用任何示例配比。**
+
+启动时问清并记入基准表来源备注：
+
+- **单位换算**：1「量」= 几帖 + 几评？
+- **总额度**：本轮共几「量」，换算后共几帖、几评？
+- **确认人**：这个换算由谁确认（书面确认来源）？
+
+确认后再换算成帖数 / 评论数进入 4.0.0.1。合同本就直接按帖数 / 评论数计价时，
+记 `ContractUnit: DirectCount` 并注明确认来源，跳过换算。
+
 **步骤 4.0.0.1** 读取需求来源（按优先级）：
 1. 用户提供的 Excel/CSV 分配文件（如 `产品贴分配.xlsx`）→ 用 Python openpyxl 或 pandas 读取
 2. 合同/SOW 文件中的「内容配比」条款
@@ -114,19 +129,36 @@ Rule-3（互补联动）:
   禁止分开两次操作（防止中间状态不一致）
 ```
 
-**步骤 4.0.0.4** 板块数量规划（基于 Phase 0.5 分析 + 补充条例 a）：
+**步骤 4.0.0.4** 板块数量规划（**执行 `references/scheduling-decision-procedure.md` 的 D1–D7**）：
+
+> **必读程序：** `references/scheduling-decision-procedure.md`（排期决策程序 D1–D7）。
+> 本步骤**不是**「凭板块分析拍一张数量表」，而是执行 D1–D7 后把 D6 锁定方案落成表格。
+> 配比的判据链在 D1–D7 里，本表只是它的汇总视图。
+>
+> **前提：** 读取 `memory/phase0.5-board-analysis.md`（Phase 0.5 候选板块分析报告 + 每板块 SubredditResearchProfile）。若文件不存在，说明 Phase 0.5 未执行，须暂停并提示用户补跑 Phase 0.5。
+> 若报告内没有 SRP，按 D 程序 §0.1 声明 `SRPMode: Fallback`（**不是** `Insufficient`），并全程标注 `FallbackOnly`。
 
-> **前提：** 读取 `memory/phase0.5-board-analysis.md`（Phase 0.5 候选板块分析报告）。若文件不存在，说明 Phase 0.5 未执行，须暂停并提示用户补跑 Phase 0.5。
+按 D 程序执行，**实际顺序为 D1 → D5 → D2 → D3 → D4 → D6 → D7**（D2 依赖 D5 的 `brandEntryAllowedSet`，编号不是执行顺序）：D1（SKU × 板块，含被拒板块理由）→ D5（capacityMax + brandEntryAllowedSet）→ D2（ProposedFlair）→ D3（生命周期阶段去重）→ D4（搜索词锚定）→ D6（Rule-1/2/3 预检后给 2–3 个方案交人锁定）→ D7（1 篇 / 0 篇判据）。逐篇记录（9 个字段，含 `ProposedFlair`）写入 `memory/phase4-排期决策台账.md`。
 
-结合 SKU 需求基准表总量，对每个已确认板块（过滤后保留的板块）输出板块维度的数量规划：
+结合 SKU 需求基准表总量，把 D6 的 `LockedPlanID` 方案输出为板块维度的数量规划：
 
 ```
-## 板块数量规划表（来源：memory/phase0.5-board-analysis.md + SKU 基准表）
+## 板块数量规划表（来源：D6 LockedPlanID <ID> · memory/phase0.5-board-analysis.md + SKU 基准表）
+表头必填：SRPMode 汇总 | LockedPlanID | LockedBy | LockedAt
 
-| 板块 | 版规松紧 | 频率建议 | P-B 帖数 | P-NB 帖数 | C-B 评论数 | C-NB 评论数 | 选取原因 |
-|------|---------|---------|:-------:|:--------:|:---------:|:----------:|---------|
-| r/xxx | 宽松 | 每1-2天 | 2 | 3 | 4 | 2 | 版规宽+周贡献9344，P-B可适当提频；推荐帖型 GUIDE/ASK 与我方内容高匹配 |
-| r/yyy | 中等 | 每3天 | 0 | 2 | 1 | 3 | 版规有限制须含使用时长，P-B 风险高，以 P-NB + C-B 评论为主 |
+| 板块 | SRPMode | capacityMax | 计划节奏 | P-B 帖数 | P-NB 帖数 | PGC 帖数 | C-B 评论数 | C-NB 评论数 | D7 判据 | 选取原因（引 D1/D5） |
+|------|---------|:-----------:|---------|:-------:|:--------:|:-------:|:---------:|:----------:|--------|----------------------|
+| r/xxx | Full | 5 | 每1-2天 | 2 | 3 | 1 | 4 | 2 | — | D1：核心品类板块；D5：删帖率 8%、允许个人经验推荐 |
+| r/yyy | Full | 2 | 每3天 | 0 | 2 | 0 | 1 | 3 | — | D1：相关品类；D5：须含使用时长，brandEntryAllowedSet={P-NB, C-B} |
+| r/zzz | Full | 1 | — | 0 | 1 | 0 | 0 | 0 | D7 探索位（四条全满足，下一轮读 48h 存活） | D5：删帖率 45%，品类相关但非核心 |
+
+> PGC 单独成列，**不并入** P-B / P-NB（UGC）计数；口径以 SKU 基准表为准。
+
+被拒板块（D1 Rejected，必填）：
+- r/aaa：<理由，引具体证据>
+
+「计划节奏」列来源：SRPMode=Full 时由 D5 capacityMax 推导；SRPMode=Fallback 时来自
+`phase01-research.md` 的无 SRP 兜底默认表，须标 FallbackOnly，且**不得**用它反推 P-B/C-B 配比。
 
 合计校验：
 - 帖子总量：[实际合计] / 基准表总量 [N]（需一致）
@@ -135,27 +167,40 @@ Rule-3（互补联动）:
 - 含品牌词评论（C-B）合计：[N] / 基准表 C-B 合计 [N]
 ```
 
-> **合计校验规则：** 板块维度合计必须与 SKU 需求基准表总量一致（允许 ±1 的 PGC 误差）。不一致时须调整板块分配，直至两者吻合。
+> **合计校验规则：** 板块维度合计必须与 SKU 需求基准表总量**逐字段一致**（UGC 总量 / P-B / PGC / 评论总量 / C-B），不一致时须调整板块分配直至吻合。**默认零容差**——D6.a 把 SKU 配额列为逐字段硬约束（见 `references/scheduling-decision-procedure.md` D6.a 第 2 条）；只有合同本身**显式**给出容差（如 PGC ±1）时才按合同容差校验，并在基准表备注写明该容差的合同出处。
 
-展示板块数量规划表后，向用户提问："以上板块数量安排是否 OK？如需调整，请告知具体板块和数量。"
+展示 D6 的 2–3 个方案（含敏感性分析与推荐理由）+ 推荐方案对应的板块数量规划表后，向用户提问："请锁定一个方案（PLAN-A/B/C）；如需调整，请告知具体板块和数量。"
 
-- 用户同意 → 写入 `memory/phase4-board-quantity-plan.md`，进入门禁
-- 用户不同意 → 按意见修改后重展示，直至确认
+- 用户锁定方案 → 记录 `LockedPlanID` / `LockedBy` / `LockedAt`，写入 `memory/phase4-board-quantity-plan.md`，进入门禁
+- 用户不同意 → 按意见修改后重展示，直至锁定
 
-Phase 4.0 执行表中的「目标子版」分配以本规划表为依据。
+> **agent 不得自行宣布唯一解**，也不得在硬配额无法满足时通过改配额数字让方案「可行」——
+> 此时输出 `D6Status: NoFeasiblePlan` 并停下来问人（见 D 程序 D6.b 规则 4）。
 
-**写入：** `memory/phase4-sku-基准表.md`（SKU 需求基准表 + 补偿规则确认 + 来源文件信息）+ `memory/phase4-board-quantity-plan.md`（板块维度数量规划表）
+Phase 4.0 执行表中的「目标子版」分配以本规划表为依据。**执行表 schema 不变（16 核心 + 3 审计控制 = 19 列，无 flair 列）**：
+D2 的 `ProposedFlair` 落在 `memory/phase4-排期决策台账.md` 的对应 Key 行；`reddit-phase-brief` 从台账读取它，
+对照账号当前实际可选 flair 列表锁定最终 `AssignedFlair`（D2 不取代 Brief 的验证，Brief 也不得选一个未经 D2 记录的 flair）。
+
+**写入：** `memory/phase4-sku-基准表.md`（SKU 需求基准表 + 补偿规则确认 + 来源文件信息）+ `memory/phase4-board-quantity-plan.md`（板块维度数量规划表 + 被拒板块 + LockedPlanID）+ `memory/phase4-排期决策台账.md`（D 程序逐篇必填记录）
 
 **门禁（全部勾选且用户确认后，才进入 Phase 4.0）：**
 ```
+[ ] 合同计价单位已确认：单位换算（1 量 = 几帖 + 几评）/ 总额度 / 确认来源已记录，
+    或 `ContractUnit: DirectCount`；未确认前不得套用示例配比锁数量计划
 [ ] 需求来源文件已读取（文件名 + 读取时间已记录）
 [ ] SKU 需求基准表已展示，用户已确认每列数字准确
 [ ] 补偿规则三条已列出，用户已确认（或明确说明哪条关闭）
 [ ] memory/phase0.5-board-analysis.md 已读取（或已提示用户补跑 Phase 0.5）
+[ ] 排期决策程序 D1–D7 已执行，D 程序自带门禁清单已全部打勾（见 references/scheduling-decision-procedure.md 末节）
+[ ] 每个板块的 SRPMode 已声明；Fallback（无画像）与 Insufficient（画像不可信）未混用；
+    无 `SRPMode: Provisional` 的板块参与执行表锁定（SRP 契约 §7：Provisional 一律不得锁执行表）
+[ ] D6 的 2–3 个方案已展示，用户已锁定 LockedPlanID（已记录 LockedBy / LockedAt）
 [ ] 板块数量规划表已展示，合计已与 SKU 基准表校验一致
+[ ] 被拒板块（D1 Rejected）已逐条列出理由
 [ ] 用户已确认板块数量安排
 [ ] memory/phase4-sku-基准表.md 已写入
 [ ] memory/phase4-board-quantity-plan.md 已写入
+[ ] memory/phase4-排期决策台账.md 已写入（逐篇 9 个字段无缺失，含 ProposedFlair）
 → 全部打勾后请用户回复"确认进入 Phase 4.0"
 ```
 
@@ -182,7 +227,7 @@ Phase 4.0 执行表中的「目标子版」分配以本规划表为依据。
 
 **核心约束（详见 `references/phase4-execution-table.md`）：**
 - 编号预分配：先按帖子 P Key 升序分配全部自评 C Key，再分配外部评论 C Key；不得跳号、不得事后重编
-- 单一子版帖子占比 ≤ 40%，核心子版（如 r/espresso）帖子数 ≤ 8 条（总帖 20 条时），子版覆盖数 ≥ 4 个
+- 板块分布约束**由 Phase 4.0.0.4 的 D6 锁定方案决定**。旧的三条硬编码启发式（单一子版帖子占比 ≤ 40%、核心子版帖子数 ≤ 8 条（总帖 20 条时）、子版覆盖数 ≥ 4 个）**已被 D6 取代，降级为「无 SRP 时的兜底默认」**：`SRPMode: Fallback` 时它们是硬约束；`SRPMode: Full` / `Provisional` 时降为 warning-level sanity check（越界不否决，但必须在方案约束快照中标注越界项与理由，交用户锁定）。另注意作用域：前两条按板块判，「覆盖 ≥ 4 个」是方案级约束、仅全部板块为 `Fallback` 时才硬执行。语义与尺度说明见 `references/scheduling-decision-procedure.md` §兜底默认。
 - PGC 帖子数 = 合同约定数，全部标注「账号类型=PGC」且「帖子品牌词=✅」
 - 外部评论 URL 必须在动笔前通过独立矩阵 skill `reddit-ext-post-audit` EPA 自检（EPA-0 批量拉取 → EPA-1 可访问 → EPA-2 帖龄 → EPA-B 品牌内容 → EPA-3 可评论 → EPA-4 质量评级），禁止「URL待确认」占位符；365 天以上帖子无条件淘汰
 
@@ -205,8 +250,16 @@ Phase 4.0 执行表中的「目标子版」分配以本规划表为依据。
 ```
 [ ] 【v2.6 新增·方案E】补偿规则评估已完成（全部 UGC P-NB 帖逐行检查 Rule-1；全部 C-NB 外部评论逐行检查 Rule-2）
 [ ] 【v2.6 新增·方案E】触发补偿规则的行已在执行表「写作说明」列注明处理方式
+[ ] 【排期决策程序】执行表每一行在 `memory/phase4-排期决策台账.md` 中都有对应 Key 的逐篇记录，
+    且 8 个必填字段（BoardChoiceReason / FlairChoiceReason / LifecycleStage / StageEvidenceRef /
+    SearchAnchors[] / RiskNote / RejectedAlternatives[] / ProposedFlair，含 Key，共 9 项）无缺失——缺任一项不得锁定执行表
+[ ] 【排期决策程序】执行表的板块分配与 D6 `LockedPlanID` 方案一致，未在锁定后私自调整
 ```
 
+> **与 `scripts/phase406_verify.py` 的关系：** 该脚本校验的是 16+3 执行表 schema、SKU 配额与
+> 品牌词互补规则，**不校验**排期决策台账。台账的完整性由上面两条门禁人工核验；
+> 不要为了让脚本通过而把台账字段塞进执行表列（执行表列数不变）。
+
 ---
 
 ## Phase 4.0.5 — B 组 Fanout 子查询补齐
@@ -215,6 +268,12 @@ Phase 4.0 执行表中的「目标子版」分配以本规划表为依据。
 >
 > **A/B 测试存在时：** B 组 fanout **必须**为 Geoly MCP 中绑定 prompt_id 的 **ChatGPT 真实 fanout query**（searchQueries 字段）；禁止用 Ahrefs 词、主 prompt 同义改写或 Agent 臆造 query 顶替。
 
+> **外部评论的 A/B readout 口径（硬规则）：** 外部热帖评论只作**补充观察**，
+> **不进主 A/B 对比样本**——它们的所在帖不受本项目控制，组间不可比。
+> 外部评论被**删评 / 屏蔽**时记为**平台风险事件**，**不得**直接归因为 A 组 / B 组策略优劣。
+> （这也是 `reddit-strategy-shared/references/context-contract.md` 启动变量
+> 「外部评论是否排除在主 A/B 样本之外」的默认答案；读数汇报与月度迭代沿用本口径。）
+
 > **平台口径（硬规则）：** Query fanout **仅看 ChatGPT 平台**。API 调用必须带 `platform=chatgpt`；提取 searchQueries 时只使用 ChatGPT 记录，**禁止**混入 Perplexity、Gemini、Grok、Google AI 等其他平台的数据。若返回结果含多平台记录，须先过滤 `platform=chatgpt` 再提取。
 
 **目标：** 对执行表中每条 B 组主帖（帖子品牌词=✅）绑定的 prompt_id，拉取 **ChatGPT 平台**近 30 天 fanout 子查询，写入执行表 fanout 列，供 B 组正文自然嵌入 query 约束。

package/skills/reddit-phase-planning/references/scheduling-decision-procedure.md

@@ -0,0 +1,386 @@
+# 排期决策程序 · Scheduling Decision Procedure（D1–D7）· v1.0（2026-08-13）
+
+> **何时读取本文件：** 进入 Phase 4.0.0.4「板块数量规划」之前。本文件是**配比从哪来**的唯一程序；
+> `phase4-planning.md` 的板块数量规划表、`phase01-research.md` 的兜底查表都以本程序为准。
+>
+> **本文件不定义品牌配额语义。** P-B / P-NB / C-B / C-NB / PGC 的含义、互补规则（Rule-1/2/3）、
+> 合同硬配额，一律以 `memory/phase4-sku-基准表.md` 与 `phase4-planning.md` Phase 4.0.0 为准。
+> 本程序**只决定这些既定配额如何落到板块 × SKU × flair × 生命周期阶段上**，
+> **不得**新增、删减、互换或重新解释任何配额语义。
+
+---
+
+## 0. 输入、模式与前置
+
+**主输入：** 每个候选板块的 **SubredditResearchProfile（SRP）**。
+契约文件：`~/.cursor/skills/reddit-strategy-shared/references/subreddit-research-profile.md`
+（Windows：`$HOME\.cursor\skills\reddit-strategy-shared\references\subreddit-research-profile.md`）。
+SRP 由 `reddit-phase-research` 步骤 0.5.5 按 S1–S9 产出，随 `memory/phase0.5-board-analysis.md` 交棒。
+
+**其他输入：** `memory/phase4-sku-基准表.md`（硬配额）、Phase 0 产品事实卡（SKU 形态）、
+compliance 分层与 `AccountGate`、Phase 1.5 Prompts Map（与 D4 分开，见 D4 边界说明）。
+
+### 0.1 三种运行模式（必须在规划表头声明，不得省略）
+
+| 模式 | 触发条件 | 后果 |
+|---|---|---|
+| `SRPMode: Full` | 该板块有 SRP，且 SRP `confidence: Verified` | D1–D7 全程有效；**禁止**用兜底查表参与任何配比推导；可锁定执行表 |
+| `SRPMode: Provisional` | 该板块有 SRP，`confidence: Provisional` | D1–D7 按 `Full` 执行（可作 planning 输入），但**一律不得锁定执行表**（SRP 契约 §7 硬规则，无例外、无 HITL 豁免）；只能补采升到 `Verified` |
+| `SRPMode: Fallback` | 该板块**没有** SRP（未采集 / 采集能力不可用 / 用户不批准补采） | D1、D3、D6、D7 仍执行；D2 只能产出 `ProposedFlair: Unknown(NoSRP)`；D5 的 `capacityMax` 用兜底默认；配比可参考 `phase01-research.md` 的兜底查表，且必须逐条标注 `FallbackOnly` |
+| `SRPMode: Insufficient` | 该板块**有** SRP 但 `confidence: Insufficient`，且无法补采 | 该板块进入 D7 的 0 篇判据；**不得**降级成 `Fallback` 继续排 |
+
+> **`approvalStatus: Approved` 不能提升 `confidence`。** 审批解决的是「这张卡可以被消费」，
+> 不是「统计可信到可以锁执行」——`Provisional` 被审批通过后仍然不能锁执行表。
+> `samplingFrame: TopN` 的卡按契约 §4.1 根本没有 `flairDistribution`，D2 无输入，直接按 `Insufficient` 处理。
+>
+> **`Fallback` ≠ `Insufficient`。** 没采到画像（Fallback）不等于采到了但不可信（Insufficient）。
+> 把 Fallback 误判成 Insufficient 会导致无 SRP 时全部板块被判 0 篇；把 Insufficient 误判成
+> Fallback 会拿不可信数据当依据。两者混淆时停下来问人。
+
+---
+
+## D1 — 商品形态 → 候选板块
+
+**产出：** `SKU × 板块` 映射，含**被拒板块**。
+
+| 字段 | 说明 |
+|---|---|
+| `SKU` | Phase 0 产品事实卡官方名 |
+| `SKUForm` | 商品形态（品类 / 材质 / 价位带 / 使用场景），来自事实卡，不得臆造 |
+| `Subreddit` | 候选板块 |
+| `Decision` | `Selected` / `Rejected` / `Deferred` |
+| `Reason` | 选取或**被拒**理由，必须落到具体证据（SRP 字段、compliance 结论、事实卡属性） |
+
+**硬规则：**
+
+1. **被拒板块及理由必须逐条记录。** 反事实理由是审计必需项，不是可选项——只列入选板块的映射表视为 D1 未完成。
+2. `Rejected` 的理由不得写「不相关」这类空判断，须指明依据（例如 SRP 的 `contentTypes[]` 无该品类、
+   compliance `NotRecommended`、事实卡价位带与板块讨论价位带不重叠）。
+3. **品类归属两可时停下来问人**（例：手工银饰既可归 r/jewelry 也可归 r/Silverwork）。
+   agent 不得自行择一，输出 `D1Status: NeedsHumanCategoryCall` 并列出两可选项及各自依据。
+4. 状态三态唯一，**粒度是 `SKU × 板块` pair**：同一 pair 不得在两处给出不同状态。
+   同一板块对不同 SKU 可以有不同状态（SKU A `Selected`、SKU B `Rejected` 是合法的）。
+   本表是 Phase 4 内 `SKU × 板块` 状态的唯一真相源。
+
+---
+
+## D2 — flair 选择
+
+> **执行顺序：** D2 依赖 D5 的 `brandEntryAllowedSet`，因此实际顺序是
+> **D1 → D5 → D2 → D3 → D4 → D6 → D7**（D5 只需要 compliance 结论与 SRP，不依赖 D2）。
+> 若因流程原因先跑了 D2，必须在 D5 完成后**回头复核每个 `ProposedFlair`**，
+> 复核结果记入 `FlairChoiceReason`。编号 D1–D7 是条目编号，不是执行顺序。
+
+**产出：** 每篇一个 `ProposedFlair`（**注意：不是最终 flair**）。
+
+**权威边界（重要）：** D2 产出 `ProposedFlair`；**最终 `AssignedFlair` 仍由 `reddit-phase-brief` 在
+动笔前依据当前账号实际可选列表锁定**。D2 不取代 Brief 的 flair 验证，Brief 也不得绕过 D2 另选一个
+未经 D2 记录的 flair——Brief 只做「验证 / 驳回并要求 D2 重出」。
+
+**选择规则：**
+
+1. 从 SRP 的 `flairDistribution[]` 选，**优先主导 flair**（`share` 最高且与本篇内容功能相符者）。
+2. **flair 必须在证据层的 flair 列表中真实存在**——即**历史观察到**、出现在 SRP 的
+   `flairDistribution[]` 里。凭印象、凭板块名推测、凭同类板块类比得出的 flair 一律不合法。
+   `flairDistribution[]` 里的 **`Unknown` 是统计 bucket，不是可发布 flair**，不得被选为 `ProposedFlair`。
+   `claimScope: SampleOnly` 的 flair 统计只能表述为「样本中」，不得说成「板块里 X% 的帖」。
+3. 落入 SRP `lowSignalFlairs` 的 flair **不得作为主推**。
+   （标杆实例：r/MensJewelry 的 `Watches` 17 帖、`Appraisal` 5 帖属低信号，全窗口占比过低，
+   拿它当主推等于把内容投进一个几乎没人看的分桶。）
+   低信号 flair 仅可用于探索位（见 D7），且必须在 `FlairChoiceReason` 里写明是探索用途。
+4. 命中 SRP `flairBoundaryNotes` 的（同一内容在两个 flair 语义之间两可），
+   必须记录**按哪个语义归类**及理由。
+5. **「主导」不等于「合适」。** 主导 flair 还须同时满足：与本篇 `ContentFunction` 相符、
+   落在 D5 的 `brandEntryAllowedSet` 内、账号资格允许。三者任一不满足则换选并记录原因。
+6. **历史出现过 ≠ 当前可选。** SRP 的 flair 分布来自历史帖子样本，不能证明当前账号能选到该 flair；
+   这正是最终锁定权留在 Brief 的原因。
+
+---
+
+## D3 — 生命周期阶段去重
+
+> **这是同一 SKU 多篇内容的唯一合法去重方式。** 换个标题、换个开场、换个语气都不算去重。
+
+**受控词表（`LifecycleStage`，只能取以下值，不得自造）：**
+
+| 阶段 | 说明 |
+|---|---|
+| `考虑/选购` | 尚未下单，比较、纠结、征求意见 |
+| `下单/定制沟通` | 已决定，与卖家沟通规格、定制细节 |
+| `发货前确认(PSC)` | Pre-Shipment Confirmation，收到成品照/确认单后的确认与征询 |
+| `到货展示` | 实物到手，开箱 / 晒图 |
+| `首次使用/情绪分享` | 第一次戴上 / 用上的反应 |
+| `技术疑问(材质/等级/规格)` | 围绕材质、等级、参数的提问或科普 |
+| `搭配/穿戴` | 与其他单品的搭配、场合穿戴 |
+| `保养/排障` | 清洁、保养、出问题怎么修 |
+| `长期使用回顾` | 拥有一段时间后的回看评价 |
+
+**硬规则：**
+
+1. **同 SKU 两篇不得只换标题。** 两篇的 `LifecycleStage` 必须不同；仅标题、开场句、语气不同视为重复，
+   直接驳回。
+2. **阶段名不能证明经历发生过。** 进入 `到货展示` / `首次使用/情绪分享` / `长期使用回顾` 三个阶段，
+   必须有**真实素材或账号历史支撑**（实拍图、订单/沟通记录、该账号既往相关发帖）。
+   写入 `StageEvidenceRef` 指向具体素材。**没有支撑就停下来问人；缺省状态是禁止使用该阶段**，
+   不得靠虚构经历补齐。
+3. **同板块同 SKU 多篇还须 flair 不同。** 若该板块的合法可用 flair（扣除 `lowSignalFlairs` 后）
+   不足以支撑计划篇数，**不得**为凑数复用同一 flair——只能减少该板块该 SKU 的篇数，
+   或将多出的篇数移到别的板块。此约束回灌 D6 作为硬约束。
+4. **去重范围：** `LifecycleStage` 去重是**全项目同 SKU 范围**的语义去重；
+   `flair 不同`只在**同板块同 SKU**范围内要求。
+5. **与 `StructureFamily` 去重并存、互不替代。** D3 是语义/经历层去重，
+   `content-diversity-contract.md` 的 `StructureFamily` + 指纹滚动窗口是结构层去重，
+   **两者必须同时满足**，任一不满足即驳回。
+
+**标杆实例（供对照，不得直接照抄到别的项目）：**
+
+- Virgin Mary 吊坠 5 篇 = `到货展示` → `首次使用/情绪分享` → `技术疑问(色级建议)` →
+  `技术疑问(CZ/莫桑科普)` → `搭配/穿戴`
+- Clover 项链 3 篇 = `发货前确认(PSC)` → `到货展示` → `考虑/选购(购买体验)`
+
+---
+
+## D4 — 搜索词锚定
+
+**产出：** 每篇挂 **1–3 个站内搜索词**，写入 `SearchAnchors[]`。
+
+每个锚点的必填结构：
+
+```
+{ term: <搜索词原文>, volume: <数值>, source: <工具/数据源名>, asOf: <YYYY-MM-DD>, market: <市场/地区码> }
+```
+
+**硬规则：**
+
+1. **`source` / `asOf` / `market` 缺一，该锚点即不得参与配比推导（D6）。**
+   缺项锚点可以保留在记录里备查，但必须标 `AnchorStatus: Unqualified`，且 D6 视其不存在。
+2. 某篇的合格锚点数为 0 时，该篇**不因此被阻断**，但在 D6 里不享受任何「搜索需求佐证」的加权，
+   并须在 `RiskNote` 注明「无合格搜索锚点」。
+3. **多个 term 的 volume 不得相加**——不同 term 的搜索量存在重叠，求和无意义。
+   需要板块级需求量级时，取合格锚点的**最大值**并注明是单词量级，不是合计。
+4. **`SearchAnchors[]` 与 Geoly `fanout` / `绑定 prompt_id` 是两套东西，不得混用、不得互填。**
+   fanout 来自 Geoly ChatGPT 平台 searchQueries（见 `phase4-planning.md` Phase 4.0.5），
+   `SearchAnchors` 是 Reddit 站内搜索词。两者字段、口径、证据来源各自独立。
+
+---
+
+## D5 — 风险与容量
+
+**输入：** SRP 的 `removalStats`、`selfPromoPolicy`；compliance 的 `AccountGate` 与账号资格。
+
+**产出（每板块两项）：**
+
+| 产出 | 含义 |
+|---|---|
+| `capacityMax` | 本轮排期窗口内，该板块允许安排的**主帖上限条数**（整数，只约束主帖；评论另计） |
+| `brandEntryAllowedSet` | 该板块允许的品牌进入形态集合，取值来自既有配额语义（如 `{P-NB, C-B}`），**不新增形态** |
+
+**规则：**
+
+1. `capacityMax` 必须写明**时间窗**（与本轮排期窗口一致）和**推导依据**
+   （SRP 的发帖节奏 / 删帖率 / 账号数）。不得只给一个光秃秃的数字。
+2. `removalStats` 样本量不足时，`capacityMax` 取保守值并标 `CapacitySource: LowSampleConservative`。
+   契约要求 `removalStats` **拆分 mod 删除与用户自删**；D5 只能引用拆分后的分项，
+   **禁止**用合并数字做「品牌内容被打压」这类归因。
+3. **`AccountGate: Unknown` 既不等于「有资格」也不等于「无资格」。**
+   Unknown 时不得自动放行，也不得自动判 0 篇；输出 `D5Status: NeedsAccountGateVerification`，
+   由人确认后再进 D6。
+4. **D5 只做「合规结论 → 容量与允许形态」的翻译，不重新解释版规。**
+   版规解释权在 `reddit-subreddit-compliance`；D5 读它的结论，不改它的结论。
+5. `SRPMode: Fallback` 时 `capacityMax` 用兜底默认（见下方兜底默认节），并标 `FallbackOnly`。
+
+---
+
+## D6 — 整数配比求解
+
+**把可机械求解的和不可机械求解的分开，这是本步骤的全部要点。**
+
+### D6.a 硬约束（可机械求解，全部必须满足，无例外）
+
+1. 合同总量（帖 / 评论各自的总数）
+2. **SKU 配额的全部字段**：UGC 总量、其中 P-B、PGC 量、评论总量、其中 C-B
+   ——逐字段满足，**不得**用 C-B 顶替 P-B，**不得**把 PGC 并入 UGC 总量
+3. 合规硬阻断（compliance `NotRecommended` / 明确禁止的形态）
+4. 账号资格（`AccountGate`）
+5. D5 的 `capacityMax`
+6. 单板块上限（见兜底默认节；`SRPMode: Full` 时由 D5 的 `capacityMax` 承担该职责）
+7. D3 的去重约束（同 SKU 阶段互异；同板块同 SKU flair 互异）
+
+> **补偿规则不属于 D6，但必须在锁定前被检查。** Rule-1 / Rule-2 / Rule-3 的定义与执行仍归
+> `phase4-planning.md` Phase 4.0.0.3 与 Phase 4.0，D6 **不得**重新定义、放宽或代替它们。
+> 但 D6 的每个候选方案在提交用户锁定前，必须先跑一遍 **Rule-1/2/3 可行性预检**——
+> 否则会产出「配额数字满足、但配对自评互补规则无解」的假可行方案。
+> 预检不通过的方案不得进入 D6.c 的候选列表，须标 `PlanStatus: FailsCompensationPrecheck` 并淘汰。
+
+### D6.b 不可机械求解的权衡（必须交人）
+
+以下三者的**权重**无法从数据推出，只能由人锁定：
+
+- **覆盖收益**：多铺一个板块换来的曝光面
+- **安全风险**：在高删帖率 / 严版规板块多发一篇的代价
+- **探索价值**：为下一轮拿读数而付出的当轮产出
+
+**硬规则：**
+
+1. agent **必须输出 2–3 个可行方案**，每个方案带唯一 `PlanID`、约束快照、
+   **敏感性分析**（改动哪一个权重会翻转结论、翻转阈值在哪）、推荐理由。
+2. **agent 不得自行宣布唯一解**，不得只给「推荐方案」而不给备选。
+3. 用户锁定后记录 `LockedPlanID` + 锁定人 + 锁定时间，写入板块数量规划表表头。
+   **被锁方案的约束快照（含每一条 warning-level 越界项及其理由、逐板块 `SRPMode`）必须
+   一并落进 `memory/phase4-board-quantity-plan.md`** —— 否则交付侧（`reddit-delivery-check`）
+   只看得到越界、看不到已获批准的理由，会把合法方案判死。
+4. **若硬约束在任何方案下都无法同时满足，输出 `D6Status: NoFeasiblePlan` 并停下来问人。**
+   **禁止**通过降低合同量、把 P-B 改记成 C-B、扩大 PGC 误差等方式让方案「看起来可行」——
+   配额语义不是 D6 的可调变量。
+
+### D6.c 方案输出格式
+
+```markdown
+## D6 配比方案（板块 × SKU × 形态）
+
+### PlanID: PLAN-A —— <一句话取向，如「保守铺面」>
+| 板块 | SKU | UGC 主帖数 | 其中 P-B | PGC 帖数 | 评论数 | 其中 C-B | capacityMax | 余量 |
+|---|---|---:|---:|---:|---:|---:|---:|---:|
+
+> **PGC 单独成列，不并入 UGC 主帖数**（口径见 SKU 基准表）。
+约束快照：合同总量 <N> / SKU 配额逐项 <…> / capacityMax <…> / 单板块上限 <…>
+敏感性：若「安全风险」权重再高一档 → r/xxx 从 3 篇降到 1 篇（阈值：删帖率 > 30%）
+推荐理由：…
+
+### PlanID: PLAN-B —— …
+### PlanID: PLAN-C —— …
+
+推荐：PLAN-<X>，理由 <…>
+待用户锁定：LockedPlanID: ______ / LockedBy: ______ / LockedAt: ______
+```
+
+---
+
+## D7 — 某板块配 1 篇或 0 篇的判据
+
+### 0 篇（满足任一即 0 篇）
+
+- 合规硬阻断（compliance `NotRecommended`，或版规明确禁止本轮全部计划形态）
+- 账号无资格（`AccountGate` 明确为 No；**Unknown 不算**，走 D5 规则 3）
+- `SRPMode: Insufficient`（SRP `confidence: Insufficient`）**且无法补采**
+
+> 0 篇只影响**该板块**的分配，**不得**因此降低任何 SKU 或合同的全局硬配额；
+> 被移出的篇数必须重新分配到其他板块，分配不下就是 `D6Status: NoFeasiblePlan`。
+
+### 1 篇（探索位，以下条件**全部**满足才成立）
+
+1. 与品类相关但**非核心**（SRP `contentTypes[]` 显示品类只是边缘话题）
+2. **风险高**——注意：这里指「合规允许但删帖率高 / 社区对推广敏感」，
+   **不包括**合规明确禁止或账号无资格，那两者是 0 篇，不得用「只发不含品牌的形态」绕过
+3. 本轮**只做不含品牌进入的形态**——即该探索位的主帖为 P-NB，**且其配对自评不得含 C-B**。
+   （注意：`brandEntryAllowedSet` 里若含 `C-B`，那是该板块常规位的允许集合；
+   探索位额外收紧到「帖与评均不含品牌词」，这只是本轮该位的取值收紧，
+   **不改变任何配额语义**，被让出的 C-B 名额必须由 D6 重新分配到别处。）
+4. 有**明确的下一轮读数指标**（写明看什么数、什么阈值算过关）
+
+四条缺一即不是探索位：要么按 D6 正常分配，要么 0 篇。
+
+> **与 orchestrator HITL #8（风险预算）的接法（两者不冲突，分工如下）：**
+> 条件 2 的「风险高」是**合规已解**下的风险胃口问题，而风险胃口只能由人给——
+> 因此**探索位要进执行表锁定，前提是 HDP#8 已获答复**。HDP#8 未获答复时落其安全默认：
+> 该探索位**照常产出草案，但不锁进执行表**（不是判 0 篇，也不是自行放行）。
+> 而「合规未解」（compliance `NotRecommended` / 版规明确禁止 / 账号无资格）走上面的
+> **0 篇**判据，与 HDP#8 的第 ① 种情形同源——**不得**用「只发不含品牌的形态」把它改造成探索位。
+>
+> **适用面（不止探索位）：** HDP#8 的安全默认覆盖**所有「合规已解但风险高」的板块**，
+> 不只是 D7 探索位——普通 D6 分配里的高风险板块同样「只出草案，不进执行表锁定」。
+> 处理方式一致：先试着把这些篇数重分配到非高风险板块；重分配不成而方案仍必须保留它们时，
+> 记 `D6Status: AwaitingHDP8`（见下）。
+>
+> **状态与回灌（避免假死锁）：** HDP#8 未答复时该探索位记 `D7Status: AwaitingHDP8`，
+> **先把它排除出 `LockedPlanID`**，其篇数交回 D6 重新分配到别的板块。
+> 只有在重分配也无解时，才记 `D6Status: AwaitingHDP8`（**不是** `NoFeasiblePlan`——
+> 这不是硬约束互斥，而是缺一个人的答复）+ `ReadyForNextPhase: No`，等 #8 答复后重跑 D6。
+
+**标杆实例：** r/streetwear = 1 篇 —— 45% 删帖率 + 板块偏好极简标题 + `WDYWT` flair 主导，
+品类相关但非核心，本轮只做不含品牌进入，下一轮读「该篇 48h 存活 + 评论区是否出现自然提问」。
+
+---
+
+## 逐篇必填记录 · SchedulingDecisionLedger
+
+> **落点：** 单独的逐篇台账 `memory/phase4-排期决策台账.md`，通过**执行表 Key** 与执行表关联。
+> **不要**把这些字段塞进板块数量规划表（那张表一行一个板块，本台账一行一篇），
+> 也**不要**新增执行表列——执行表 schema 仍是 16 核心 + 3 审计控制列 = 19 列，
+> `scripts/phase406_verify.py` 不校验本台账，本台账由下方门禁人工核验。
+
+| 字段 | 说明 |
+|---|---|
+| `Key` | 对应执行表唯一 Key |
+| `ProposedFlair` | D2 选出的 flair **实际值**（`SRPMode: Fallback` 填 `Unknown(NoSRP)`）。执行表 schema 无 flair 列，本台账是 `ProposedFlair` 的落盘处 |
+| `BoardChoiceReason` | 为什么是这个板块（引 D1 的证据） |
+| `FlairChoiceReason` | 为什么是这个 `ProposedFlair`（引 D2 规则；低信号/边界情形须点名） |
+| `LifecycleStage` | D3 受控词表取值 |
+| `StageEvidenceRef` | 阶段成立的素材/账号历史引用；三类经历型阶段必填 |
+| `SearchAnchors[]` | 1–3 个，含 `{term, volume, source, asOf, market}` 与 `AnchorStatus` |
+| `RiskNote` | 该篇的具体风险与缓解（引 D5） |
+| `RejectedAlternatives[]` | **至少 1 个**未被选中的方案及原因 |
+
+（共 9 个字段：`Key` + 上表 8 项。）
+
+**`RejectedAlternatives[]` 的空集规则：** 若确实只有一个可行候选，
+填结构化值 `NoFeasibleAlternative: <原因>`，**不得编造**一个替代方案来凑数。
+
+**门禁：任一字段缺失，不得锁定执行表。**
+
+> `ProposedFlair` 的下游：`reddit-phase-brief` 从本台账读取 `ProposedFlair`，
+> 对照账号当前实际可选 flair 列表锁定 `AssignedFlair`；两者不一致时驳回并要求 D2 重出。
+
+---
+
+## 兜底默认（`SRPMode: Fallback` 专用，`SRPMode: Full` 时禁止参与配比推导）
+
+以下三条来自旧版 `phase4-planning.md` 核心约束，**已由 D6 取代**，仅在无 SRP 时作为默认值：
+
+- 单一子版帖子占比 ≤ 40%
+- 核心子版帖子数 ≤ 8 条（总帖 20 条时）
+- 子版覆盖数 ≥ 4 个
+
+**语义（必须明确，不得含糊）：**
+
+| 模式 | 这三条的效力 |
+|---|---|
+| `SRPMode: Fallback` | **硬约束**，等同 D6.a 的「单板块上限」项 |
+| `SRPMode: Full` / `SRPMode: Provisional` | **降级为 warning-level sanity check**：越界不否决方案，但必须在该方案的约束快照里显式标注越界项与理由，交 D6.b 由人锁定。（`Provisional` 另受「不得锁定执行表」的硬规则约束，两者独立。） |
+
+> **作用域：前两条按板块判，第三条按方案判。** 「单一子版占比 ≤ 40%」与「核心子版 ≤ 8 条」
+> 是**单板块**约束，按该板块自己的 `SRPMode` 定效力；「子版覆盖数 ≥ 4 个」是**整个方案**级别的
+> 约束，只有当方案内**全部**板块都是 `SRPMode: Fallback` 时才作硬约束，混合模式下一律是
+> warning-level。否则一个 Full 板块会被别的板块的 Fallback 模式连坐判死。
+
+> **尺度提醒：** 40% / 8 条 / 4 个板块这组数字是按「总帖 20 条」标定的，
+> 对显著不同的总量不具尺度一致性。`SRPMode: Full` 下以 D5 的 `capacityMax` 为准。
+
+同理，`phase01-research.md` 的「无 SRP 兜底默认表（版规松紧 × 每周贡献数 → 频率 / 品牌进入倾向）」
+只在 `SRPMode: Fallback` 生效，且其中的品牌进入倾向（「优先 P-NB」「C-B 补露出」等）
+**只是风控倾向，不改变任何 P-B / C-B / PGC 的合同数字**。
+
+---
+
+## 本程序的门禁（并入 Phase 4.0.0.4 门禁）
+
+```
+[ ] 每个候选板块已声明 SRPMode（Full / Provisional / Fallback / Insufficient），Fallback 与 Insufficient 未混用
+[ ] 无 `SRPMode: Provisional` 的板块参与执行表锁定（唯一出路是补采升到 `Verified`）
+[ ] D1 SKU × 板块 映射已产出，且**被拒板块逐条记录了理由**；品类两可项已问人并有答复
+[ ] D2 每篇已给出 ProposedFlair 并落盘；`SRPMode: Full/Provisional` 的板块其值均出现在 SRP
+    `flairDistribution[]` 中且非 `Unknown` bucket；`SRPMode: Fallback` 的板块豁免此项，
+    统一填 `ProposedFlair: Unknown(NoSRP)` 并由 Brief 在动笔前补选；
+    低信号 flair 未作主推（作探索位者已注明）；边界归类已记录
+[ ] D3 每篇已填受控词表 LifecycleStage；同 SKU 无「只换标题」；
+    到货/首次使用/长期回顾三类阶段均有 StageEvidenceRef；同板块同 SKU flair 互异
+[ ] D4 每篇 1–3 个 SearchAnchors，来源/日期/市场齐全者才参与 D6；缺项已标 Unqualified
+[ ] D5 每板块已产出 capacityMax（含时间窗与依据）与 brandEntryAllowedSet；
+    AccountGate=Unknown 的已问人，未自动放行也未自动判 0
+[ ] D6 已输出 2–3 个带 PlanID 的方案 + 敏感性分析 + 推荐理由；用户已锁定 LockedPlanID；
+    agent 未自行宣布唯一解；未通过改配额语义让方案「可行」
+[ ] D7 的 0 篇 / 1 篇板块已逐个列出判据；1 篇者四条全满足且已写下一轮读数指标
+[ ] memory/phase4-排期决策台账.md 已写入，逐篇 9 个字段（`Key` + 8 个业务字段）无缺失
+    （RejectedAlternatives 空集者已填 NoFeasibleAlternative + 原因）
+[ ] 合同与 SKU 硬配额逐字段未被改动（UGC 总量 / P-B / PGC / 评论总量 / C-B）
+```

package/skills/reddit-phase-research/SKILL.md

@@ -15,6 +15,7 @@ Before starting, apply the installed shared references. macOS/Linux paths start
 - `~/.cursor/skills/reddit-strategy-shared/references/evidence-policy.md`
 - `~/.cursor/skills/reddit-strategy-shared/references/context-contract.md`
 - `~/.cursor/skills/reddit-strategy-shared/references/handoff-schemas.md`
+- `~/.cursor/skills/reddit-strategy-shared/references/subreddit-research-profile.md` (SRP contract — step 0.5.5 produces one profile per passing subreddit)
 - Windows equivalents: `$HOME\.cursor\skills\reddit-strategy-shared\references\...`
 
 ## Source References
@@ -25,7 +26,7 @@ Before starting, apply the installed shared references. macOS/Linux paths start
 ## Scope
 
 - Phase 0: product fact card and KG Reddit context check.
-- Phase 0.5: candidate subreddit discovery, compliance-aware tiering, and optional Ask AI cited-post type weighting.
+- Phase 0.5: candidate subreddit discovery, compliance-aware tiering, one SubredditResearchProfile (SRP) per passing subreddit, and optional Ask AI cited-post type weighting.
 - Phase 1: VOC and competitor gap analysis.
 - Phase 1.5: brand prompts map draft plus industry-dashboard prompts without brand terms.
 - Phase 1.6: Geoly MCP/Topic confirmation and prompt import handoff.
@@ -37,6 +38,9 @@ Before starting, apply the installed shared references. macOS/Linux paths start
 - Do not run full `kg-action-report` for Reddit Phase 0.
 - Do not call a subreddit "recommended" from VOC relevance alone.
 - Do not infer subreddit rules from Reddit samples.
+- Do not derive any share/percentage conclusion (flair mix, post-type mix, topic mix) from a top-N sample. Full-window distributions with an explicit denominator come from the SRP only.
+- Do not collapse `SRPMode: Fallback` (no profile) into `SRPMode: Insufficient` (profile exists but untrustworthy), or vice versa.
+- Do not turn the fallback frequency table (补充条例 a-F) into a content-mix conclusion; it never changes P-B / C-B / PGC contract numbers.
 - Do not create or write Feishu/Geoly resources without explicit user-provided target links and MCP names.
 
 ## Dependencies
@@ -71,6 +75,8 @@ Update or produce:
 - NeedsVerificationCandidates:
 - NotRecommended:
 - VOCInsights:
+- SubredditResearchProfiles:
+- SRPModeBySubreddit:
 - PromptMapDraft:
 - IndustryPromptMapDraft:
 - AskAITypeWeighting: