TeaParty Provider-Neutral Protocol

一张图

Protocol owns meaning, adapter owns mechanics. 语义归 TeaParty，工具细节归 provider。

                    ┌──────────────────────────────────────┐
                    │          TeaParty Protocol            │
                    │ .teaparty/protocol/{core,memory,...} │
                    └──────────────────┬───────────────────┘
                                       │
          ┌────────────────────────────┼────────────────────────────┐
          │                            │                            │
┌─────────▼─────────┐        ┌─────────▼─────────┐        ┌─────────▼─────────┐
│ Claude Code        │        │ Codex             │        │ Future Provider    │
│ .claude adapter    │        │ .agents adapter   │        │ adapter TBD        │
│ hooks/skills/agent │        │ repo/test/review  │        │                    │
└─────────┬─────────┘        └─────────┬─────────┘        └─────────┬─────────┘
          │                            │                            │
          └────────────────────────────┼────────────────────────────┘
                                       │
                    ┌──────────────────▼───────────────────┐
                    │         TeaParty File System          │
                    │ seats / parties / projects / bazaar   │
                    │ vault/facts.jsonl + vault/links.jsonl │
                    └──────────────────────────────────────┘

Claude 特有文件如何剥离

多数内容不是 Claude 专属，而是茶会领域规则。真正专属的是 hook、工具声明、agent 调用和 Claude CLI 运行方式。

当前文件	现在定义了什么	剥离策略
`CLAUDE.md`	古镇结构、面团身份、记忆分层、对话模式、触发器、硬规则、Claude 入口说明。	领域协议迁到 `.teaparty/protocol/`；Claude 入口保留薄 adapter。
`.claude/settings.json`	SessionStart / Stop / PostToolUse hooks。	抽象为 session_start、session_stop、file_written 事件。
`.claude/rules/*.md`	idea 生命周期、分类、圆桌、记忆更新、原子事实、项目推进、经验提炼。	基本可整体迁到 `.teaparty/protocol/rules/`。
`.claude/skills/*`	recall、reindex、review、roundtable、new-idea、update-memory、sprint、new-party。	技能语义迁到中立层；allowed-tools、Claude CLI、tmux runner 留在 adapter。
`.claude/agents/*.md`	architect、pm、futurist、pragmatist、researcher 的 Claude agent wrapper。	角色定义中立化；Claude/Codex 各自映射为 sub-agent 或本地角色提示。
`.claude/agent-memory/`	历史 agent 研究、项目判断、临时记忆混合区。	做归位审计，不能继续作为第三套事实源。

目标结构

把 TeaParty 规则从 provider 文件中抽出，形成一套可被任何 AI coding agent 读取的协议包。

Protocol

中立协议源

.teaparty/protocol/ 存放 core、memory、project、lifecycle、routing、rules、skills、roles、events。它解释 TeaParty 是什么。

Adapters

执行器适配

CLAUDE.md 和 AGENTS.md 不再是完整协议，而是读取中立协议并说明各自工具能力的入口。

Memory

同一记忆源

Claude Code 和 Codex 都写入同一套 seats、parties、projects、bazaar、vault，避免两套面团各自生活。

.teaparty/
├── protocol/
│   ├── core.md
│   ├── identity.md
│   ├── access.md
│   ├── memory.md
│   ├── project.md
│   ├── context-loading.md
│   ├── lifecycle.md
│   ├── routing.md
│   ├── events/
│   ├── rules/
│   ├── skills/
│   ├── roles/
│   └── adapters/
│       ├── claude-code.md
│       └── codex.md
├── memory/
└── inbox/

身份与权限进入协议核心

多人不是只多一个入口。必须先回答：这次是谁、以哪个 seat 进入、能读什么、能写什么。

Identity

seat 是身份场域

同一个账号可以绑定多个 seat。设备和上下文决定默认 seat，例如个人手机进入 k，工作电脑进入 work_k，家庭 iPad 进入 home_shared。

Access

检索前过滤

私有内容不能靠 LLM 自觉保密。recall、grep、图谱、dashboard、publish 都必须先按当前 seat 的 read 权限过滤。

Context

项目加载可声明

用户说“继续 Amber”时，项目协议应声明 canonical context，adapter 按权限加载 progress、decisions、debugging、deployment、map 和相关圆桌。

Binding

账号授权，设备定场域

bindings:
  - principal: openai:k_account
    device: iphone_personal
    seat: k
  - principal: openai:k_account
    device: macbook_work
    seat: work_k

ACL

frontmatter 覆盖默认权限

visibility: restricted
owner: work_k
access:
  read: [k, work_k]
  write: [work_k]
  share: [k]

已验证的 Provider 派发

这不是纯设计推演。2026-05-18 已实际测试 Codex 调度 Claude Code，在项目目录内完成读、写、Cloudflare 查询和部署。

实验	执行目录	工具	结果
Smoke test	`/private/tmp`	none	返回 `SMOKE_OK`
只读理解 TeaPartyDocs	`~/Create/TeaPartyDocs`	Read / Grep / Glob	正确识别页面定位，并指出外部观众背景解释不足
沙盒写入与读回	`/private/tmp`	Read / Write	写入并读回 `PROVIDER_WRITE_OK`
Cloudflare Pages 查询	`~/Create/TeaPartyDocs`	Bash / Wrangler	查询部署状态成功，未泄露 token
Cloudflare Pages 部署	`~/Create/TeaPartyDocs`	Bash / Wrangler	部署成功，返回 `STATUS=success`

What Works

Claude Code 适合做项目内 provider

在具体项目目录中，Claude Code 可以执行项目理解、局部写入、Cloudflare Pages/Workers 部署，以及它自身的 skill/MCP 任务。

Constraint

不要从 TeaParty 根目录裸派发

TeaParty 根目录协议和渠道插件链路太重，非交互长任务容易无 stdout 卡住。派发任务必须指定具体项目 cwd 和允许工具。

跨入口连续

TeaParty 必须在中立文件中保持连续，而不是依赖某个 provider 的私有记忆。下一个执行体应从协议层恢复状态。

Canonical Shared State
├── seats/{seat}/profile.md
├── seats/{seat}/.teaparty/sessions/YYYY-MM-DD.md
├── seats/{seat}/.teaparty/memory/
├── .teaparty/protocol/
├── .teaparty/memory/
├── {project}/.teaparty/protocol.md
├── {project}/.teaparty/memory/
├── .teaparty/dispatch/requests/
└── .teaparty/dispatch/results/      ← 派发交接账本

Start

入口握手

解析 seat → 运行连续性检查 → 加载最新 session 与 progress → 读取项目协议 → 检查 dispatch ledger 中是否有未消化的跨 provider 结果。

Work

工作过程中

所有 durable 变更写入中立路径。Claude Code 可以维护 .claude/ 机制文件，但仅靠它们不足以让 Codex 或其他 provider 继续。

End

退出握手

追加当日 session（Done / Decided / Next）→ 更新 progress 顶部焦点 → 更新项目记忆 → 如有派发则记录 result → 更新索引与图谱。

冲突规则：provider 私有记忆与中立记忆冲突时，中立记忆优先，除非用户明确说私有记忆更新。此时应将更新事实迁移到正确的中立层。

.teaparty/dispatch/
├── requests/
│   └── YYYYMMDD-HHMMSS-claude-code-project.md
└── results/
    └── YYYYMMDD-HHMMSS-dispatch-project-status.md

派发模式

plan / think / implement / deploy 构成权限递增的闸门管道。mode 是持久派发契约的一部分，未经批准不能跨模式执行。

模式	读	编辑	运行命令	部署	用途
plan	是	否	否	否	安全评估范围与工作量
think	是	否	否	否	架构推理、风险分析、决策备忘
implement	是	是	本地验证	否	编码、测试、验证
deploy	是	否	已批准命令	是	生产部署与发布

1. Create

创建请求

默认 mode: plan。声明 provider、acting_seat、cwd、goal、scope 和 forbidden 清单。

2. Approve

审批模式

K 明确授权特定请求和特定 mode（plan / think / implement / deploy），记录 approved_by、approved_at、approved_mode。

3. Execute

模式匹配执行

执行前检查 approved_mode 与执行 mode 是否一致。不一致则拒绝。dry-run 也是 mode-aware。

4. Record

记录结果

结果写入 .teaparty/dispatch/results/。plan 要求 summary / changed_files / implementation_plan / risks；think 要求 assumptions / analysis / alternatives；implement / deploy 要求 verification / deploy_url。

5. Review

审查与接受

协调方检查 result 结构、git diff、验证输出，再决定提交、部署或推进记忆。provider 进程成功 ≠ 工作可用。

立项项目必须纳入设计

这是这次设计里最容易漏掉的一层。项目不是 TeaParty 的附件，而是 TeaParty 记忆体系的正式一环。

当前 `~/Create/` 下 Amber、Yumuoo、BIOS、Chaki、InsightForge、Portfolio、Void 等项目基本都有项目级 `CLAUDE.md`，但几乎没有项目级 `AGENTS.md`。如果不迁移项目协议，Codex 进入项目目录时就会失去产品灵魂、硬规则和项目记忆归属。

Project Protocol

每个项目的中立协议

产品灵魂和定位
技术栈和运行方式
目录职责和边界
项目记忆：progress / decisions / debugging
map.md 生成和验证规则
项目硬规则和部署规则

Migration Order

项目迁移顺序

先迁 Chaki：公共基建，最简单。
再迁 BIOS / Portfolio：结构稳定。
最后迁 Amber / Yumuoo：活跃主线，避免扰动。

{Project}/
├── .teaparty/
│   ├── protocol.md
│   └── memory/
│       ├── progress.md
│       ├── decisions.md
│       └── debugging.md
├── CLAUDE.md     # generated or thin Claude adapter
├── AGENTS.md     # generated or thin Codex adapter
└── map.md

project:
  id: amber
  owner_seats: [k, work_k]
  source_idea: parties/career/ideas/vibe-interviewing.md

context:
  required:
    - .teaparty/memory/progress.md
    - .teaparty/memory/decisions.md
    - .teaparty/memory/debugging.md
    - .teaparty/memory/deployment.md
    - .teaparty/memory/map.md
  related:
    - parties/product/roundtables/amber-review-2026-05-08.md

access:
  read: [k, work_k]
  write: [k]
  deploy: [k]

协调模型：Coordinator / Worker

TeaParty 使用 coordinator/worker 模型，而不是 provider 阵营化。Codex 协调，Claude Code 执行；单方有能力时直接完成，不必为仪式而拆分。

User asks → Codex resolves context → Can Codex do it end-to-end?
                                    │
                                    ├─ Yes → Complete
                                    │
                                    └─ No  → Dispatch to Claude Code
                                              ↓
                                       Claude Code executes
                                              ↓
                                       Codex reviews result
                                              ↓
                                       Commit / Deploy / Advance memory

Codex

Coordinator — 协议 steward

解析上下文与项目协议
决定自完或派发
大范围修改、多文件审查、迁移
测试、浏览器验证、部署检查
审查 Claude Code result 后再提交
最终记忆与 commit owner

Claude Code

Worker — 执行与深度思考

具体项目目录内的编码实现
高 token 深度架构/产品推理
Cloudflare MCP / skill / Wrangler 部署
长驻 session、warmed context
Telegram / 微信通道链路
被 Codex 派发时按 mode 限制执行

Shared

共享同一套事实

Truth = File
Single Owner
wikilink + facts + links
项目 debugging 是项目教训 canonical source
bazaar 承担跨项目模式回流

Default Path

单方直接完成

当当前 provider 已持有足够上下文和工具时，直接完成有界任务，不必派发。不要为避免读上下文而派发。

Dispatch Trigger

何时派发

仅当另一 provider 有具体能力优势：Cloudflare MCP/skills、warmed context、通道访问、高 token 深度思考、安全并行、或配额优势。

实施路线

先不要大拆。最稳的打法是 inventory → skeleton → adapter → project migration → sync tooling。

Phase 0

Protocol Inventory

列出 Claude-specific、Codex-specific、provider-neutral、project-specific 文件，标注 move / keep / generate / deprecate / audit。

Phase 1

Neutral Skeleton

创建 `.teaparty/protocol/`，先放 core、memory、project、rules、skills、adapters，不删除旧文件。

Phase 2

Thin Adapters

把 `CLAUDE.md` 和 `AGENTS.md` 改为薄入口。`.claude/rules` 与 `.agents/skills` 标记为 synced/generated。

Phase 2.5

Identity / Access / Provider Contract / Continuity / Dispatch Modes

固化设备/账号/上下文到 seat 的绑定、内容 ACL 和 Codex → Claude Code 派发协议：project cwd、allowedTools、env 注入、禁止事项、输出格式和 timeout。落地 continuity.md、provider-dispatch.md 及 public 可视化文档。

Phase 3

Project Protocol Migration

升级 seed 模板，先试点 Chaki，再迁稳定项目，最后迁活跃项目 Amber/Yumuoo。

Phase 4

Audit and Sync Tooling

新增 `protocol-audit` 和 `protocol-sync`，检查 adapter 漂移、项目缺协议、agent-memory 未归位。

建议下一步

这件事值得做，但要像协议工程一样推进，不要一口气把 Claude 运行时打散。

下一步先做 `provider-neutral-protocol-inventory.md`，同时落地 `.teaparty/protocol/identity.md`、`access.md`、`context-loading.md` 和 `adapters/claude-code.md`。Inventory 完成后，再创建完整骨架。这样既能保留 Claude Code 当前可用性，也能让 Codex 正式成为调度入口。

让 TeaParty 成为协议，而不是某个工具的配置

一张图

Claude 特有文件如何剥离

目标结构

中立协议源

执行器适配

同一记忆源

身份与权限进入协议核心

seat 是身份场域

检索前过滤

项目加载可声明

账号授权，设备定场域

frontmatter 覆盖默认权限

已验证的 Provider 派发

Claude Code 适合做项目内 provider

不要从 TeaParty 根目录裸派发

跨入口连续

入口握手

工作过程中

退出握手

派发模式

创建请求

审批模式

模式匹配执行

记录结果

审查与接受

立项项目必须纳入设计

每个项目的中立协议

项目迁移顺序

协调模型：Coordinator / Worker

Coordinator — 协议 steward

Worker — 执行与深度思考

共享同一套事实

单方直接完成

何时派发

实施路线

Protocol Inventory

Neutral Skeleton

Thin Adapters

Identity / Access / Provider Contract / Continuity / Dispatch Modes

Project Protocol Migration

Audit and Sync Tooling

建议下一步