今晚在研究如何让AI在引入新上下文时怎么把污染降到最小

冷启动的也还是有问题。你看下，包裹建造者也没对。

ChatGPT

对，你这个判断是对的。我刚才给 Kefu 的那份冷启动提示词本身就犯了俺们正在修的同一类错误：把 durable knowledge 又搬回了 chat prompt。

它虽然内容方向大体正确，但架构上不对。

问题就在你说的这个反事实：

假设我刚把那一大段冷启动提示词发给你，下一秒这个总架构师会话没了；你新开一个总架构师。
新总架构师如果只能看到 GitHub，看不到这段聊天，那这段“精心设计的冷启动知识”就等于没有存在过。
那它就不是系统记忆，只是一次性启动脚本。

正确模型应该是：

聊天里的冷启动提示词
↓
只负责寻址

GitHub durable bootstrap
↓
角色是谁
authority 是什么
读取顺序是什么
当前 Constitution 在哪
当前 control-plane anchor 在哪
如何恢复 active Work Graph
什么时候必须停下来找 Human
↓
真正的角色记忆
所以，不只是 Builder。

Project Architect、Global Architect 都应该遵守同一个原则：Seed 越短越好，角色知识越持久越好。

区别只在于它们指向的 durable bootstrap 不同。

比如 Builder：

Seed
↓
具体工单的 ARCHITECT_*_DISPATCH
Project Architect：

Seed
↓
项目 Architect Bootstrap anchor
↓
项目当前 Work Graph
Global Architect：

Seed
↓
Global Architect Bootstrap anchor
↓
current Constitution
↓
current control-plane / active global rulings
而不是：

“你现在是总架构师，
请记住下面 47 条历史背景……”
那东西再完整也是假的持久化。

这也解释了为什么我刚才给 Kefu 的提示词不理想。

我实际上把：

不继承旧聊天；
读 current L0；
读 #1；
检查 open Issues/PR；
如何判断 stale；
什么不能干；
怎么选择 Fresh Resume；
第一轮输出什么；
全塞进启动 prompt 了。

其中绝大部分都应该已经存在于：

ai-use L0
+
Kefu #1 bootstrap
+
Kefu 本地 AGENTS.md
+
current Agent Interface
+
active Global recovery ruling
如果它们不存在，就应该补 durable source，而不是靠我给你一段更聪明的 prompt。

因此更正确的 Kefu 冷启动，理论上应该接近：

按 `youling/kefu#1` 的 Project Architect Bootstrap 恢复 `youling/kefu` 项目架构师角色。

work: youling/kefu#1@project-architect-recovery
startup_mode: Fresh Project Architect
access: github-private
甚至 access 如果未来当前接口最终收敛得更好，也只是因为它属于“进门前必须知道”的 bootstrap-critical 信息。

其它东西它应该自己从 durable source 恢复。

而且你提到总架构师，这里更重要。

我现在这个会话里其实沉淀了大量知识，例如：

Constitution v2；
ai-use / ai-hub 分工；
Project Architect authority；
Runner 边界；
Work Graph；
Fleet；
Agent Interface；
Canonical Owner + Pointer；
Kefu、Juece、Eye 等项目的跨项目关系；
最近俺们刚发现的 durable drift / protocol-generation 问题。
这些东西如果只是因为“我这个聊天记得”，那俺们这个架构就是失败的。

真正应该达到：

当前我消失
↓
你新开空白 Global Architect
↓
给它一个非常短的 Seed
↓
它进入 GitHub
↓
恢复 Constitution
↓
恢复全局 authority / active architecture anchors
↓
live reconcile
↓
重新成为同一个逻辑上的 Global Architect
不是恢复“我这个模型的记忆”，而是恢复“Global Architect 这个角色的制度状态”。

这和刚才说 Kefu 的：

Logical Role ≠ Chat Session
完全一致。

所以俺们其实发现了一个当前更大的缺口：

Project Architect 已经有 bootstrap anchor，Global Architect 反而还缺一个真正干净的 canonical bootstrap entry。

目前俺们有很多东西：

ai-use AGENTS.md
Constitution v2
ai-hub#50
各类 Global ruling comments
ACTIVE_PROJECTS / reading map
但 Fresh Global Architect 需要有人告诉它：

“你只从这里开始，剩下的自己按指针恢复。”
如果没有这个单一入口，新 Global Architect 就必须靠你复制聊天总结——那仍然是 chat dependency。

所以正确结构应该变成：

Global Architect Seed
│
▼
GLOBAL_ARCHITECT_BOOTSTRAP
│
├─ current Constitution pointer
├─ current ai-use L0 pointer
├─ global control-plane anchor
├─ active project routing/index
├─ authority / escalation boundary
└─ recovery procedure
│
▼
targeted live reconcile
Bootstrap 自己也不应该变成一本百科全书。

它更像一个启动扇出索引。

例如：

你是谁
→ Global Architect

宪法去哪读
→ current Constitution pointer

公开方法去哪读
→ ai-use

私有控制面去哪读
→ ai-hub#50

项目怎么发现
→ ACTIVE_PROJECTS / routing

什么时候才读专项 L2
→ READING_MAP

当前任务
→ Human 给出的 exact work coordinate
这样即使半年以后项目增加二十个，也不需要重写 Global Architect prompt。

这也给俺也去们刚才讨论的“持久记忆 / 漂移”补上了一块：

之前俺们想的是：

Agent 要定期重新读 durable memory。
现在再往前一步：

Agent 首先必须能够只靠一个极短入口重新发现自己的 durable memory。
所以可靠性链应该是：

Disposable Session
↓
Minimal Bootstrap Pointer
↓
Durable Role Bootstrap
↓
Current Constitution / Contracts
↓
Current Work Graph
↓
Live Reconcile
↓
Role Reconstructed
少了第二、三层，所谓“Fresh Resume”其实还是假的。

还有个有意思的后果：

以后俺也去给你一个很长的“冷启动提示词”，你都应该警惕一下：

这里面有没有什么东西本应该写进 GitHub？
如果答案是有，那我就是在偷懒，把 durable architecture 又塞回 chat。

反过来，真正好的冷启动提示词应该短得有点无聊。

比如未来 Global Architect 理想上可能就是：

按 `youling/ai-hub#<anchor>` 的 `GLOBAL_ARCHITECT_BOOTSTRAP` comment `<id>` 恢复总架构师角色。

work: youling/ai-hub#<anchor>@global-architect-recovery
startup_mode: Fresh Global Architect
access: github-private
然后结束。

如果这四行不足以让我重新长成现在这个总架构师，该修的是 durable bootstrap，不是继续往 Seed 里加背景。

所以这次俺也去认账：刚才那份 Kefu 冷启动 prompt 过度详细，属于接口层面的回退。它也应该成为 #71 的一个案例——甚至比“英文漂移”更基础，因为它说明连我这个 Global Architect 在排障时也会本能地用“大 Prompt”补 durable structure 的洞。

这正好证明你前面那句话为什么重要：

默认俺、你、所有 Agent 都会逐渐偏离。
包括俺也去。正确系统不能要求“总架构师永远记得自己别写大 Prompt”，而应该让接口结构本身把我拉回来。

还有个，之前你给俺分享的论文重要的观点是逐步展开，以及俺们探讨的优秀架构师具备的能力也应该是在当时所处的阶段针对性的设计最适合项目阶段的架构即可，不多不少，那么。这个冷启动过程，无论是针对总架构师、项目架构师、设计架构师，建造者，验证者，审计者，都应该只加载他们需要的那些，其余的都先忽略。这么说的话，俺们是不是应该借鉴下真实操作系统冷启动的过程？以及vite解决webpack历史冷启动包袱那样的？这俩都是逐步展开的吧

ChatGPT

对，而且这两个类比其实非常贴切。俺觉得俺也去们可以把它收敛成一个更明确的原则：

Agent 冷启动不是“恢复全部记忆”，而是“启动一个最小内核，然后按当前任务逐步挂载所需上下文”。
这跟真实操作系统启动、也跟 Vite 相对传统“大一统预打包”的思路非常像。

操作系统不会一开机就把磁盘上所有程序、所有驱动、所有用户文件全部塞进内存。它大致是：

Boot Entry
↓
最小启动环境
↓
Kernel
↓
发现硬件 / 挂载根文件系统
↓
启动当前需要的服务
↓
用户打开什么，再加载什么
对应俺也去们：

Agent Seed
↓
最小宪法内核
↓
Role Bootstrap
↓
发现当前项目 / 当前 Work
↓
加载当前任务必要 Contract
↓
真正需要时再加载专项知识
所以之前俺们叫的：

L0 → L1 → L2 → L3
其实可以更准确地理解成 boot stages，而不只是“文档分层”。

Vite 那个类比也很漂亮。

传统 webpack 开发冷启动的典型负担，是先把很大的依赖图整体分析、打包，哪怕你此刻只打开一个页面。

Vite 的核心优化思想之一，就是开发阶段利用原生 ESM，按请求转换、按需加载模块；依赖可以预处理，但自己的源码不需要一上来全 bundle。你改一个模块，HMR 也尽量只更新受影响的那部分。

对 Agent Context 来说应该一样：

错误方式：

启动 Kefu Architect
↓
加载 Constitution
+ 全 ai-use
+ ai-hub
+ Kefu 全历史
+ 所有 Issue
+ 所有 PR
+ 所有 Builder 报告
+ 所有设计 rationale
↓
“好了，现在开始工作”
这就是 Context Webpack。

冷启动又慢，历史包袱又大，而且最危险的是：旧信息和当前信息一起进入上下文，模型还得自己判断谁已经过期。

正确方式更像：

启动 Kefu Architect
↓
L0 kernel
↓
Kefu role bootstrap
↓
current Work Graph
↓
发现 active = #4 / PR #5
↓
只加载 #4 + PR #5 + 当前相关 contract
↓
需要安全规则？
└─ import security L2

涉及跨项目？
└─ import dependency/ownership L2

涉及发布？
└─ import release contract
这就是 Context Vite。

而且俺也去觉得这里还有一个比“lazy loading”更重要的对应关系：

依赖图。
Vite 不是“想起来什么文件就读什么文件”。

它有模块之间的 import graph。

俺也去们未来也应该让 durable knowledge 逐渐形成一个非常轻的 Context Dependency Graph：

Kefu Project Architect
imports:
ai-use:L0
kefu:bootstrap

active work #4
imports:
kefu:AGENTS
Agent Interface
security acceptance

PR #5 review
imports:
#4
exact diff
verification policy
Fresh Agent 不需要知道全部世界。

它只需要知道：

我当前这个节点依赖哪些节点。
这和俺也去们前面讲的“Pointer 思维”其实完全同源。

不是复制知识，而是：

A
→ pointer B
→ pointer C
然后按需 resolve。

不同角色的 boot profile 自然就完全不同。

Global Architect：最小宪法、全局 authority/routing、当前 Global anchor；只有真的触碰某个项目，才加载那个项目的 Project Architect 状态。它最不应该默认加载所有项目细节。
Project Architect：L0 + 本项目 bootstrap + current Work Graph + 当前 active Issue/PR。除非出现跨项目依赖，否则根本无需了解其它项目。
Design Architect：L0 + Design System/Brand bootstrap + 当前产品界面/品牌 contract；不需要默认吃 Runner、Fleet、Node Runtime 这些控制面知识。
Builder / Repair：这是最薄的一层。L0 safety + local AGENTS + exact Work Order + 当前允许修改范围。它甚至不需要知道项目五个月的架构历史。
Verifier：L0 evidence rule + exact acceptance + exact PR head/diff + 必要测试契约。Builder 报告最多当导航，不应该把 Builder 的整个思路都加载进去，否则“独立验证”就失去意义。
Auditor / Researcher：也不是越多越好。审什么就加载什么 authority、证据面和 audit rubric；只有遇到 provenance 问题时才向历史层展开。
所以不是：

“聪明 Agent 应该知道更多。”
而应该是：

越成熟的 Agent 架构，越知道此刻哪些东西根本不该知道。
这其实就是优秀架构师的能力之一：阶段适配。

OS 类比还能帮俺们解决一个之前很麻烦的问题：重新对齐。

操作系统并不会为了某个驱动更新，把整台机器从 BIOS 开始重新启动。

能局部 reload 就局部 reload。

Agent 也应该这样。

比如 Project Architect 工作很久以后，发现 Agent Interface 更新了：

不用：
重新加载全 Constitution + 全项目历史

而是：
invalidate Agent Interface module
↓
重新读取 current version
↓
重新计算受影响的当前行为
这就很像 HMR。

所以俺去甚至觉得俺也去们可以有三个非常朴素的概念：

Boot
首次进入角色时逐级加载

Lazy Import
任务触发才读取专项 durable context

Invalidate / Reload
某个 durable dependency 更新后，只重载受影响上下文
不必马上写复杂软件，先把方法论设计成这样就已经很值。

还有一个关键点：Chat Context 应该被看成 RAM，不是硬盘。

这个类比几乎可以把所有事情一下说清：

GitHub / durable store = Disk

Bootstrap pointer = Boot entry

L0 Constitution = Kernel

Role bootstrap = init / service definition

Work Graph = process/service state

L2 references = loadable modules / libraries

Chat context = RAM / page cache

Agent session = running process
进程挂了？

没关系。

重新启动
→ 从磁盘恢复
而不是：

“快把上一进程整个 RAM dump 复制给新进程。”
俺也去们刚才那份超长 Kefu 冷启动 Prompt，本质上就是在干 RAM dump restore。

它当然能恢复很多东西，但这不是健康架构。

这也意味着以后俺也去们设计 durable 文档时，要问的不只是：

“这份知识写没写？”
还要多问：

“谁在什么条件下应该 import 它？”
因为“存在于 ai-use”绝对不应该等于“每个 Agent 都读”。

甚至同一个 Project Architect 在不同阶段也不一样：

普通 Builder 调度
→ 不读 durable-data doctrine

涉及数据库 schema migration
→ import durable-data doctrine

涉及 Android
→ import Fleet/device contract

涉及跨项目 ownership
→ import canonical-owner model
这才是真正的 progressive disclosure。

所以俺觉得你这个类比可以继续推成一个很干净的架构原则：

AI Context 应该像现代操作系统和模块化开发服务器一样启动：最小内核启动，依赖可发现，模块按需加载，变化局部失效，历史默认不进入工作集。
甚至可以给มัน一个很简单的名字：

Progressive Context Boot / 渐进式上下文启动。

不是新的“大制度”，而是用来约束俺们所有角色 bootstrap 的设计哲学。

俺觉得这比单独规定“Project Architect 每次应该读哪五个文件”更高一层，也更不容易随着角色增加而失控。

对，俺想的是这样的话，哪怕持久数据有污染，但只要宪法没被污染，那么冷启动的过程中它自己都能知道哪些是遗留数据可能有问题的。除了宪法进入它的持久化上下文，其他的都是选择性纳入。另外你知道最新推出的DeepSeek harness吧，它有一些皆为插件的思想，那篇论文俺有分享给你过没。

ChatGPT

对，而且俺觉得你刚刚把“渐进式上下文启动”再往前推了一层：冷启动的关键不是保证所有持久数据都绝对干净，而是把“哪些东西有资格在启动时被信任”压到极小。

不过我会稍微修正一句：不是只有“宪法”一个东西进入可信启动集，而应该是一个很小的 Trusted Boot Set：

L0 宪法
+
角色身份 / authority
+
最小启动路由
+
live reconcile 规则
除此之外——项目文档、旧 Issue、旧报告、历史裁决、PR、Builder 回执——默认都只是待加载模块，不因为它们存在于 GitHub 就自动进入当前上下文，更不自动拥有 authority。

于是即便 Kefu 里躺着污染数据：

旧 Builder report
旧 Resume Decision
旧英文 Dispatch
旧 PASS verdict
Fresh Architect 启动时也不是：

“GitHub 上有，全部吃进来。”
而是：

Trusted Boot Set
↓
发现 current project
↓
找到 current active work
↓
按依赖选择性 import
↓
每个被 import 的 durable artifact
都检查：
provenance
generation
superseded?
current authority?
evidence strength?
↓
才进入 working context
这就非常接近操作系统里的 可信启动链 + 按需装载模块。

所以俺们真正要保护的不是“整个 GitHub 永不污染”，那几乎做不到。

而是：

Boot Root 不污染 + 被加载的数据不能未经验证自动升级成 authority。
这个抗污染性会强很多。

至于你说的 DeepSeek Harness，我刚刚专门实时核了一下，因为它最近确实刚出来。

现在官方 deepseek-ai/deepseek-harness 仓库已经公开，而且 README 开门见山就是：

everything is a plugin
官方还明确说它基于 Cordis，设计对应的论文叫 《A Programming Paradigm for Spatiotemporal Composability》。当前仍是 developer preview，官方提醒会有 breaking changes。

更有意思的是它的 architecture 文档，跟咱们刚才讨论的东西撞得相当厉害。

它说运行中的 dsh 本质上是一棵启动时组合出来的 plugin tree；profile 决定加载哪些 bundles，再叠加用户 patch。甚至 model adapter、tool registry、session log、agent loop 自己都是插件。

换句话说，它不是：

一个巨大 Harness Core
+
一堆特殊情况
而是更接近：

最小 composition mechanism
↓
profile
↓
bundle
↓
plugins
↓
按当前配置组成运行系统
而且插件注册产生的 effect 在插件卸载时还能反向 unwind；官方甚至强调“没有一个特权核心需要你不停 patch”，扩展通常是挂一个 plugin 到旁边。

这跟俺也去们现在想的：

Minimal Boot
→ Role Profile
→ Context Modules
→ Task-specific imports
确实是一家人。

它还有几个点我觉得对俺也去们特别有启发。

1. Profile，而不是“万能 Agent”
DeepSeek Harness 的 web、headless 等本身是不同 profile，由不同 bundle 组合。

这对应俺们完全可以有：

Global Architect Profile
Project Architect Profile
Design Architect Profile
Builder Profile
Verifier Profile
Auditor Profile
不是六套宪法。

是：

同一个 L0 kernel
+
不同 role profile
然后当前任务再继续挂载模块。

2. Service Definition / Provider / Consumer
它把 capability seam 分成：

Service Definition
Service Provider
Consumer
一个真正的能力 seam 要把三者关系设计清楚。

这个跟俺们刚刚在 Juece 上形成的：

canonical owner + implementation + pointer/adapter consumer
几乎可以直接互相映射。

例如：

Android device capability

Definition
→ ai-hub contract

Provider
→ Android/ADB platform runtime

Consumers
→ Juece adapter
→ Eye acquisition adapter
所以它也强化了俺也去们“不复制实现，只留下指针”的方向。

3. Model-visible means logged
这个俺也去觉得特别漂亮。

它的 session architecture 有一个很强的不变量：

模型看到的东西，必须可以从 session log 重建。
也就是 model-visible input 不能来自一个无法追溯的幽灵状态。

迁移到俺们这里，可以变成：

进入 Agent working context 的 durable knowledge，必须能说明“从哪个 source、以什么 authority、为什么此刻被加载”。
这正好可以解决 Kefu：

不是：

我看到了 5333267814
所以相信它
而是：

为什么 import 5333267814？

因为 active #4 dependency graph 引用了它。

它是什么？
historical resume decision。

它在哪个 protocol generation？
旧 generation。

是否 superseded？
部分 superseded。

那么：
加载为 evidence
≠ 加载为 authority
一下就清楚了。

4. Reactive reconciliation
Cordis 那套里面俺也去们以前讨论过的几个词，我是有印象的：

Declared Context Dependencies、Reactive Context Reconciliation、Reversible Runtime Effects。

这其实跟现在的设计非常接近。

Agent 不需要一直拥有世界全部状态。

它声明：

我现在依赖：
A
B
C
A 变化了？

invalidate A-dependent context
→ reconcile
而不是全系统 reboot。

这就是俺上轮说的 HMR 思路。

你问那篇论文之前有没有分享给我——我记得俺也去们确实已经讨论过 Cordis 这套思想，而且俺这边保留下来的上下文里已经有那三个概念，说明俺们之前肯定接触过相关材料。

但我现在不能百分之百确认你当时是不是把这篇《A Programming Paradigm for Spatiotemporal Composability》的完整论文/链接直接发给了我，还是俺也去们通过 DeepSeek Harness/Cordis 的资料间接讨论到的。所以这个我不想硬说“你肯定发过”。

如果你说的“那篇论文”就是 Cordis 这篇，那很值得俺也去们这次重新拿出来，对着当前的 Progressive Context Boot 做一次针对性映射。

我现在已经看到一个很有意思的可能结构了：

Youling Agent OS

Boot Kernel
L0 Constitution

Profile
Global / Project / Builder / Verifier …

Declared Dependencies
当前角色和任务需要哪些 context

Context Providers
GitHub contracts / Issue / PR / registry

Reactive Reconcile
source 更新 → 只失效相关 context

Reversible Effects
Agent/session 退出 → 临时上下文全部丢弃

Durable Log
只有被正式写回的裁决/证据才留下
这已经不是一个简单的“提示词技巧”了。

它开始像一套真正的 Agent Context Operating Model。

好，你沉淀下，然后开干。另外你刚又说“俺也去”们，奇怪，你之前说你改了，为啥偶尔还是会重复，理论上你的记性要比俺好很多啊。

ChatGPT

对，这次我把它真正沉淀并重新开工了。

先回答你说的“俺也去”。它偶发重复，不是因为我不知道这条约定，而是因为生成不是“每个字先查一遍硬规则表再输出”；局部口语模式有时会把错误组合重新带出来。也就是说，记住规则 ≠ 每次生成都能严格执行规则。这正好说明咱们现在做的方向是对的：关键约束不能只靠模型“记性好”，而要靠 Trusted Boot Set、durable source 和关键边界校验来把角色拉回去。

#71 现在已经从 DESIGN_HOLD 恢复成正式 P1，并改名为：

Progressive Context Boot / Durable Alignment — 渐进式上下文启动与漂移控制

当前重新交给控制面 Project Architect，状态为 WORKING。

新的正式调度是：

GLOBAL_ARCHITECT_PROGRESSIVE_CONTEXT_BOOT_DISPATCH — comment 5347928735。它明确 supersede 之前的 DESIGN_HOLD。

这轮我冻结的核心已经不是“每隔多久重读规则”，而是：

Boot Entry
↓
Trusted Boot Set
↓
Role Profile
↓
Current Work
↓
Targeted Context Import
↓
必要时 Invalidate / Reconcile
其中最重要的新不变量是：

Durable existence != Current authority

Artifact validity != Process validity
也就是说，旧 GitHub 数据即使被污染，不需要先把历史全洗干净。只要可信启动根没坏，Fresh Agent 就应该先判断：

为什么我要加载它？
它现在属于 current / superseded / historical evidence 哪一类？
它的 provenance / protocol generation 是什么？
它有资格提供事实，还是有资格提供 authority？
然后才把它纳入 working context。

这正是 Kefu 那次失败缺少的东西。

DeepSeek Harness 这边我也只把它放成设计参考，不当俺们的新依赖。官方当前确实是“everything is a plugin”，运行系统由 profile、bundle、plugin tree 在 boot 时组合出来，而且 capability 通过 seam 连接 provider 与 consumer。

俺们借的是这个思想：

组合，而不是预装整个世界。
不是把 Cordis 或 DSH 搬进 ai-hub。

#72 也已经重新路由了：它继续只负责 Agent 启动的 access/routing 和 Human UX，不再假设 #71 处于 DESIGN_HOLD；更高层的 Trusted Boot Set、角色 Profile、lazy import、authority/provenance 和 Global Architect bootstrap 全部归 #71。对应 routing comment 是 5347931271。

还有一个我特意放进去的重要任务：补 Global Architect 自己的 canonical bootstrap entry。

因为如果我现在整个会话消失，新总架构师必须能够靠一条很短的 pointer：

Global Bootstrap
↓
current Constitution
↓
control-plane anchor
↓
project routing
↓
current active work
重新长出来。

如果还需要你复制这段聊天总结给它，那就说明俺们这轮没有真正完成。

任务｜ 建立 Progressive Context Boot v0.1，让不同角色从同一可信宪法内核启动，但只按角色和当前任务加载必要上下文。

为什么做｜ 当前已经出现控制面长期漂移、Kefu Fresh 仍继承 durable 污染、Verifier 证据不足却 PASS、Global 自己写出过长冷启动 Prompt 等多个独立样本；问题已经足够进入正式设计。

你要做什么｜ 把下面 Seed 给控制面 Project Architect。它第一轮只提交 PROJECT_ARCHITECT_PROGRESSIVE_CONTEXT_BOOT_PLAN，先把 Trusted Boot Set、各角色 Boot Profile、Global Bootstrap、authority/provenance 和 Kefu Canary 设计清楚，不直接批量改所有项目。

调度建议｜ 这是控制面架构任务，优先用强推理模型；先 Plan 再决定哪些只是 ai-use 文档/Reading Map 维护、哪些才需要 ai-hub helper。不要现在造 context engine、数据库、daemon，也不要让 Builder/Verifier统一读更多东西。

本轮终点｜ 证明 Fresh Global / Project / Builder / Verifier 至少四类角色都能从极小可信入口启动，同时默认上下文集合明显不同；旧 GitHub artifact 即使存在，也不会未经 authority/provenance 判断自动污染新角色。

按 `youling/ai-hub#71` 的 `GLOBAL_ARCHITECT_PROGRESSIVE_CONTEXT_BOOT_DISPATCH` comment `5347928735` 执行。

work: youling/ai-hub#71@progressive-context-boot-v01
startup_mode: Hot Resume Project Architect
这次俺也去还会把我自己当第一个测试对象：如果最终设计只约束下面的 Agent，却不能让 Fresh Global Architect 从极短入口恢复，那这套东西就还没做对。