方法版本：v0.2
周期：每周日 20:00（Asia/Shanghai）
入口：https://wehub.us/team-dashboard/system-reflection/
Discord feedback grow place：https://discord.com/channels/1467236722524950630/1526521491154407474
Source owner：WeHub Team OS + WeHub Agent Mind
当前执行器：Codex app automation WeHub 每周系统自省

1. 这个过程解决什么问题

WeHub 已经有很多项目、Agent、runtime、Discord thread、状态文件、技能和公开 surface。系统自省不是再制造一份项目周报，而是周期性回答：

这一周 WeHub 是否真的变强了；如果变强，哪条可验证因果链支持这个判断？

它服务三个目的：

  1. 帮助 Gong 用较少注意力把控整个系统，而不是逐项巡视；
  2. 帮助 wehub-agent-mind 形成有证据、可纠偏的系统自我认知；
  3. 让反思方法本身可见、可评测、可迭代，而不是藏在一次性的 prompt 里。

2. 它不是什么

  • 不是项目数量、网页数量、消息数量或 token 数的周度汇总；
  • 不是自动优先级系统；
  • 不是自动改写 Founder Seed、project seed 或 campaign commitment 的控制器；
  • 不是新的 metabolism platform、中央数据库、dashboard schema 或通用 eval 平台；
  • 不是以“每周必须有变化”为前提的内容生产任务。

如果本周没有 material delta，正确输出就是：无重大系统变化。

3. Authority chain

每次运行先从 source 与 live state 读取，不从上周文字直接续写本周结论：

  1. /Users/cms/wehub-system-msp/FOUNDER_SEED.md：系统方向、北极星与反漂移；
  2. /Users/cms/wehub-system-msp/README.md、hello_agent.md：系统 root、source / grow place / projection 边界；
  3. 各项目自己的 seed、state、output 与 verified runtime source；
  4. Team OS / host / runtime / provider 的最新状态；
  5. Discord/AID、nano-work 与真实协作 evidence；
  6. 网站、dashboard、历史周报：只用于路由、对比与检查 projection drift，不单独创造事实。

Discord #wehub-系统自省 是长期 feedback / evaluation grow place，不是 canonical source。它承接每周摘要、Gong 订正、多智能体讨论与方法纠偏；稳定理解必须回填到本方法文件或 Agent Mind feedback observation。

每个状态判断必须查看更新时间。不同 state clocks 可以同时局部真实，但不能无说明地拼成同一个“现在”。

4. 每周观察范围

默认覆盖以下系统面，但不要求平均用力：

  • system root / project family / Seed Registry；
  • Team OS、hosts、runtimes、providers 与 access surfaces；
  • Discord 人机协作现场与 AID organization facts；
  • nano-work 的事项记忆、commitment 与 WIP 信号；
  • WeHub Agent Mind 的认知投影与真实行为证据；
  • Skills API Flywheel 的 capability / second-use / case evidence；
  • Causal Superintelligence、Causality Primer 与 Causal Intelligence；
  • 10 Paper Portfolio 当前 WIP、next gates 与外部压力；
  • 必要时检查其他本周产生 material delta 的系统线。

覆盖范围不是 checklist 完成率。没有变化的系统面可以一句话说明；有因果意义的变化应深入核查 source。

5. 生成过程

Step A · 回到基线

读取最新系统自省报告和方法版本，只用于建立待检验的旧判断：上周认为什么是主线、瓶颈、风险和认知候选。

Step B · 收集本周 live delta

从 canonical source、最新 state、runtime evidence 与真实交付中寻找过去七天的变化。优先寻找状态跃迁，不把活动量当进展。

Step C · 给证据分类

每条重要内容标明：

  • current fact：当前 source/runtime 直接支持；
  • inference：由多条事实推导，必须说明推导；
  • risk：尚未发生但值得防守的路径；
  • proposal：建议或 mind delta 候选，不自动生效。

Step D · 做五个系统检验

  1. Mainline test：当前 campaign 是否产生 gate exit，WIP 是否被支线侵蚀？
  2. Evolution test：是否出现 selection → inheritance → second use → better outcome？
  3. Human-attention test：Gong 的注意力是否更多进入不可替代判断，而非系统维护？
  4. Complexity test：新增复杂度是否解除真实瓶颈，还是来自架构完整感？
  5. Representative-work test：原创命题、真实 Agent Society、旗舰结果、外部迁移四项是否获得新证据？

Step E · 形成一句 verdict

Verdict 必须能够被下一周证伪或修正。避免“稳步推进”“持续完善”等无法检验的套话。

Step F · 产出报告

报告最少包含：

  1. 一句诚实 verdict；
  2. 本周 verified deltas；
  3. 主战役与 WIP 判断；
  4. 能力继承 / second-use 证据；
  5. Discord/AID 与 human attention 判断；
  6. 复杂度与战略性推迟；
  7. 代表作四项证明的变化；
  8. 最多 1–3 条方向建议；
  9. 一个最值得 Gong 思考的问题；
  10. 最多 3 个 stable mind delta 候选，全部标记为 proposal。

Step G · 发布与验证

每期 Markdown source 进入：

/Users/cms/wehub-agent-mind/feedback-observations/
  YYYY-MM-DD-wehub-weekly-system-reflection.md

然后由 Team OS renderer 生成专题首页与当期详情页，部署到双 origin，并验证：

  • Team Dashboard 首页有最新 verdict 与专题入口；
  • 专题首页能看到最新报告、历史报告和本方法；
  • 当期详情页标题、日期、verdict、证据边界与返回入口正确；
  • 桌面与手机宽度可读；
  • 公网 route 返回成功且包含代表性 marker。

网页部署和公网验证成功后，向固定频道 #wehub-系统自省 发送一条低噪音摘要：一句 verdict、当期详情链接、验证状态、最多一个需要 Gong 判断的问题。发送后必须 read-back；没有 material delta 也发送，但明确写“无重大系统变化”。默认不按周新建频道或 thread，只有需要多轮判断的重要误判、方法升级或系统决策才从当期消息开 thread。

本地最小 gate：python3 scripts/verify_system_reflection.py。它检查 source header、latest metadata、专题/详情/Team Dashboard 三层投影和关键边界文案；公网 verifier 另行检查 live route。

6. Source header contract

每期报告开头保留以下最小字段，供人和 renderer 共同读取：

# Feedback observation · WeHub 每周系统自省 · YYYY-MM-DD

> 日期：YYYY-MM-DD
> 周期角色：weekly
> 方法版本：<当前方法版本>
> Verdict：**一句可检验判断。**
> 状态：feedback observation / proposal only

报告 source 是反馈观察，不是稳定宪法。专题页是 projection，不反向覆盖 source。

7. Promotion boundary

系统自省可以提出 stable mind delta，但不能自动升格。只有同时满足以下条件，才建议 owner 审核：

  1. 它改变了真实任务中的识别、路由、沉默、升级、验收或回写行为；
  2. 改变有 source pointer 与前后 decision delta；
  3. 至少出现一次 second use，或重复失败证明它是稳定模式；
  4. 与 Founder Seed 和项目 owner 边界不冲突。

8. 如何优化这个反思过程

每四周或出现明显误判时，回看以下过程指标：

  • Freshness coverage：关键结论是否读取了最新 source/state，是否误用陈旧 projection？
  • False promotion：是否把消息热度、页面更新或单次调用误判为 commitment / capability？
  • Missed delta：是否漏掉后来证明重要的 gate exit、失败或 owner correction？
  • Action value：方向建议是否改变了下一周的行动、WIP 或战略性推迟？
  • Correction latency：错误判断多久被真实反馈纠正？
  • Attention cost：Gong 读完并完成必要判断需要多少注意力？
  • Compression quality：首页一句 verdict 是否准确代表完整报告，而不是制造误导？

优化顺序：先修 source coverage 与分类错误，再调整问题、输出结构或 cadence。不要因为一次报告不理想就建设新平台。

9. 方法版本记录

v0.2 · 2026-07-14

  • 建立唯一长期 Discord grow place #wehub-系统自省，承接每周反馈、owner 订正与方法纠偏；
  • 网页部署和公网验证成功后才发送 Discord 摘要，且必须 read-back；
  • 稳定理解回填 Agent Mind feedback observation 或本方法文件，Discord 不成为 canonical source；
  • 默认保持一个连续频道，不按周增殖频道或 thread。

v0.1 · 2026-07-14

  • 建立每周系统级自省，而不是一次性总体分析；
  • 以 Intent → Agent Society → Verified Outcome → Inherited Capability → Stronger ME 为主循环；
  • 固定检查 mainline、inheritance、human attention、complexity 与 representative-work proof；
  • Discord/AID 坚持 high recall, low authority；
  • 报告进入 Agent Mind feedback observation，专题页负责连续呈现；
  • stable mind delta 只作为 proposal，不自动升格。