docs(catalog): add IP-031 manager context is not turn authority

[BigDataDZ]

Summary

• Add IP-031 Manager Context Is Not Turn Authority to docs/concepts/interaction-pattern-catalog.md under the State And Boundary family, with its catalog row and pattern-to-canary matrix registration.
• Describe a shipped boundary that was not yet catalogued: a Lark Manager connection separates message visibility from Turn authority. Retaining compact non-self group messages as local-private context starts no model call, sends no reply or reaction, acknowledges no provider event, and authorizes no Goal or Todo mutation.
• Record the three authorized Turn sources (provider-native mention of the bound Bot, provider-verified reply to that Bot, another existing typed authority record), the eight-item / 4,000-character projection budget where every item is labeled context-only, and the rule that history catch-up stays context-only even for messages that originally mentioned the Bot, so it never replays a missed Turn.
• Link docs/reference/protocols/lark-manager-context-authority-v0.md plus the turn-start-sync and goal-topic-runtime tests as the validation path.
• Documentation only. No behavior, CLI contract, protocol, or existing IP entry is changed.

Issue Or Task

• Closes [Task]: Add IP-031 for the manager-context versus Turn-authority boundary #4373
• Contributor task ID: GH-C37

Numbering note

This entry is IP-031 because IP-030 is taken by #4321, an earlier open PR on this same file. This branch is based on main at 6c1a4d2cc, which does not yet contain #4321, so the catalog here ends at IP-029 and this PR introduces IP-031 directly. If #4321 merges first the numbering is contiguous; if this PR merges first, IP-030 is briefly absent until #4321 lands. Merging #4321 first keeps the sequence clean, but either order applies without conflict — the two changes touch different families.

Merge-order note

This PR and #4321 both register a row in the pattern-to-canary matrix, and those two rows are adjacent (Human Decision and State And Boundary). Applying both produces exactly one trivially resolvable conflict in docs/concepts/interaction-pattern-catalog.md — the fix is to keep both edited rows, since each PR changes a different family.

Either PR merges cleanly on its own (both report MERGEABLE). If #4321 lands first I will rebase this branch immediately; the resolution is to keep IP-030 in the Human Decision row and IP-031 in the State And Boundary row.

Validation

• Tested revision: 23f9c6358fc111e6d4a55842453c69fbe181542a
• Run state: finished
• Input classes: synthetic

Check kind	Result	Public-safe evidence / limitation
static	passed	loopx check --scan-path docs/concepts/interaction-pattern-catalog.md → ok: True, errors=0, public boundary scan clean: 1 files.
smoke	passed	python3 examples/interaction-pattern-catalog-smoke.py → interaction-pattern-catalog-smoke: ok.
unit	not_run	Docs-only change; no runtime module is touched, so no unit suite applies. The linked test modules are cited as the behavior evidence for the interaction IP-031 describes, not as checks this PR modifies.

• Coverage and gaps: Structural checks confirm the entry is complete and consistent rather than partially applied — IP-031 carries all five template sections, the catalog table order and the Pattern Details order agree for all five families, and the pattern-to-canary matrix coverage matches the P0/P1 table rows for all five families including IP-031. Mermaid fences stay balanced (100, even). Every claim is taken from lark-manager-context-authority-v0.md and the shipped constants (context_only_captured, replied_and_acknowledged in loopx/extensions/lark/goal_topic_runtime.py); no new behavior is asserted.

Frontend / Visual Evidence

• UI impact: none
• Before:
• After:
• States and viewports shown:
• Source data: none

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring (no functional changes)
• Documentation update
• Test update

LoopX Area

• Control plane (goals, todos, quota, scheduler, registry, runtime)
• Benchmark boundary (adapters, runners, verifiers, scoring, evidence)
• Capability or extension (providers, adapters, skills)
• Public docs or presentation surface (README, protocols, dashboard)
• Build, packaging, installer, or CI
• Host or runtime integration

Technical Direction

• Core control-plane hardening

• Long-horizon benchmark evidence

• Operator surface and IM integration

• Shared Goal Authority and cross-host coordination

• Architecture and research incubator

• Target base branch: main

[steven-kid]

详细中文评审

结论：APPROVE。未发现阻断性的内容问题。评审 head：23f9c6358fc111e6d4a55842453c69fbe181542a；对照 base：6c1a4d2cc37280a1d652b4bf67afd9c7d69ce19e。当前 GitHub 显示合并冲突；这是分支集成事项，合并前应更新分支并保留已合并的 IP-030，不能把本次内容批准视为冲突已解决。

动机

这次 PR 把已经实现、但尚未收录进交互目录的 Manager 边界命名为 IP-031：看得到群聊消息，不等于有权把它当作一次 Turn。此前 canonical protocol 和运行时已经描述/实现这条规则，但按目录选择边界 canary 的维护者仍需自行找到相应协议与测试。

只在既有 IP-005 State Projection Gap 或 IP-006 Checkpointed Scope Mismatch 下增加一个链接，是可考虑的更小方案；不过它们分别关注投影缺口与写入范围，而这里有独立的“静默保留 → 后续授权消费 → 历史补采不重放”交互链。因此增加一个有明确 trigger、owner、bad smell 和已有测试入口的条目合理。它没有为了文档再新增运行时机制或一次性 smoke。

改动思路

权威仍来自 lark-manager-context-authority-v0 协议、既有 Manager binding/routing 和 typed authority；目录只负责解释和导航，不生成新授权。State And Boundary 表、pattern-to-canary matrix 和详细条目共同注册 IP-031，使读者能从分类定位到实际行为和验证入口。

正向链条是：一个未直接寻址 Bot 的非自身群消息被保留为 context-only，不调用 answer、不发送回复；后来 provider-native mention 触发已授权 Turn，manager_context_materials 按最近八条和总计 4,000 字符截取材料，回复验证后由已有 material-review ledger 结算。对应运行时测试明确检查第一次 capture 的 answer 调用数为零，后续授权请求只调用一次并结算材料。

负向链条是：历史补采中的旧 mention 仍然是 context-only，保留 provenance 而清除 live attention/reply 标志；歧义绑定、自身消息或其他 chat 不应通过入口。失败由既有 Lark routing/sync 边界处理，不由目录或另一个 inbox 权限库接管。这与新增正文和 Mermaid 的意图一致。

具体改动

关键内容讲解

唯一修改文件是 docs/concepts/interaction-pattern-catalog.md，整体为 +67/-1，没有 production、测试、安装或生成产物变更。

第一处在 Pattern-To-Canary Design Matrix 的 State And Boundary 行追加 IP-031，继续复用 Projection and boundary canary 分类，没有新建验证体系。第二处在 State And Boundary 目录表添加 P1 行，owner 是 Manager connection owner，用户通道是静默保留，行为摘要明确把 context 与 provider-native mention/verified reply/typed authority 分开。

第三处新增完整详细条目：Trigger 覆盖唯一启用绑定、授权 Turn 的上下文读取/同步和历史 mention；Expected behavior 说明保留本身不触发模型、reply/reaction、provider ack 或 Goal/Todo mutation，给出每 Turn 的数量/字符预算以及成功回复后的结算条件。Visual Model 把唯一绑定、上下文保留、授权判断和补采画成流程；Bad smell 点出把可见消息误当权限、历史 mention 重放、adapter 另建请求数据库三类错误。Validation 链接现有协议和三个测试模块，而不是新增只检查本段文字的测试。

我另外核对了未修改的 manager_context.py 常量和材料选择逻辑、goal_topic_runtime.py 的 CONTEXT_ONLY 提前返回与授权消费路径，以及历史同步相关测试。正文中的八条/4,000 字符是单 Turn 投影预算，不能据此推断持久化存储也只有这个大小；本 PR 没有声称新增持久化 retention 政策。

对主干的风险

主要风险是解释性文档夸大权限或把 context 当作待办。此次正文反复明确 context-only 不是 command、authorization 或独立 Todo；历史补采也不会重放 Turn。实际 runtime 的提前返回分支和测试断言与这些内容相符，所以没有发现新增权限或静默运行时变化。

独立执行：python3 examples/interaction-pattern-catalog-smoke.py 通过；引用的 test_lark_turn_start_sync.py、test_lark_goal_topic_runtime.py、test_lark_goal_topic_connections.py 共 156 passed；对 exact base/head 的 git diff --check 通过。测试使用合成 provider 输入，足以检查本次文档引用的本地路由/材料边界，但不代表真实 Lark 网络环境已验证。未执行渲染后的 Mermaid 视觉检查；文本和 fenced diagram 已阅读。

另已检查 #4321：它为 machine configuration 注册 IP-030，目前已合并。当前 PR 的 merge state 为 DIRTY，更新分支时应保留两个相邻 canary 行的内容及各自条目，之后重跑目录 smoke；不要用任一侧覆盖另一侧。此项不构成当前文档语义缺陷。

我的整体评价

这一改动给既有行为增加了可检索的交互名称和验证导航，范围小、owner 清楚，没有创建第二个 authority 或为了目录引入额外运行时代码。全文件差异、链接所指协议、关键实现及正负向测试之间没有发现阻断性矛盾，因此对这个 exact head 给出 APPROVE。

残余风险主要是分支集成，以及合成测试无法替代真实 provider 的环境验证。此次为纯文档改动，无需把这些未运行的外部检查包装成 runtime 新能力的保证。批准仅覆盖此 head 的内容；解决冲突后需核对新的 diff 与目录结构，不包含自动合并授权。

English verdict: APPROVE at exact head 23f9c63. No blocking content finding: IP-031 accurately catalogs the existing separation between retained Manager context and Turn authority, including bounded consumption and non-replayed historical mentions. Independently checked the full docs-only diff, canonical protocol, relevant runtime branches, catalog smoke, diff check, and 156 linked tests. Live Lark and rendered Mermaid were not exercised. The branch currently has a merge conflict; preserve already-merged IP-030 when updating it and recheck the resulting diff. Approval is not merge authorization.

[steven-kid]

English verdict: APPROVE at exact head 23f9c63. No blocking content finding: IP-031 accurately catalogs the existing separation between retained Manager context and Turn authority, including bounded consumption and non-replayed historical mentions. Independently checked the full docs-only diff, canonical protocol, relevant runtime branches, catalog smoke, diff check, and 156 linked tests. Live Lark and rendered Mermaid were not exercised. The branch currently has a merge conflict; preserve already-merged IP-030 when updating it and recheck the resulting diff. Approval is not merge authorization.

[huangruiteng]

Merge readiness conclusion (content approved upstream; merge blocked by branch conflict)

队列前言（loopx pr-review --state open --limit 200，complete=true，policy_revision=3，other-developers-first）：49 个 open PR 中 28 个需要处理。本卡覆盖 rank 2 的 #4374——作者 @BigDataDZ，动作类型 qualify_pull_request_merge_readiness（该 head 已存在 @steven-kid 的有效 APPROVE 结论，所以本卡交付的是合并就绪资格判定，不是又一轮内容评审）。下一张待办是 rank 3 的 #4376。

结论先行：内容侧没有发现阻塞项，但这个 head 现在不能合并。 --check-merge-readiness 4374@23f9c6358 返回 ready=false，两个原因都很具体：merge_state_requires_update（分支与 main 冲突）和 github_review_decision_not_approved（GitHub 的 review decision 仍是 REVIEW_REQUIRED，尽管该 head 上有一条有效 APPROVE）。

动机

Lark Manager 连接已经上线了一条边界，但 interaction pattern catalog 里没有它的条目：把群消息作为 local-private context 保留下来，与「授权一次 Turn」是两件事。未登记的边界拿不到 canary archetype，后续任何针对上下文保留或 Manager 授权的改动都没有可继承的检查模板，所以补录是维护成本最低的收口方式。

改动思路

入口是 docs/concepts/interaction-pattern-catalog.md，它同时维护三处登记：State And Boundary 家族行、P1 目录表、以及 pattern-to-canary 映射与正文小节。PR 在三处都补了 IP-031，正文按既有模板写 trigger / expected behavior / 验证路径，并链接 manager-context 协议与 turn-start-sync、goal-topic-runtime 测试。我确认 main 上最高编号是 IP-030、IP-031 尚不存在，因此这不是重复登记，也不会与既有编号冲突。

具体改动

1 个文件 +67/−1：家族行加入 IP-031，P1 表新增一行（Owner 为 Manager connection owner，无中断、保留静默），正文新增 IP-031 小节，说明「可见性≠授权」、授权只来自 provider 原生 mention、经验证的 reply 或既有 typed authority，并给出最多 8 条 / 4000 字符的 context-only 预算与「历史回补不重放 Turn」的约束。目录自带的 examples/interaction-pattern-catalog-smoke.py 在该 head 上输出 ok。

对主干的风险

文档型改动，风险限于「描述与实现不一致」：如果正文写的边界与已上线的 Manager 行为不符，agent 会继承一个并不真正覆盖该边界的 canary 原型。现有 smoke 只校验目录结构接线，不校验行为描述是否与运行时一致；我核对的是编号与重复登记这两件 smoke 覆盖不到、且最容易出错的事。另外这个 head 目前 mergeStateStatus=DIRTY：git merge-tree 显示冲突就在同一个文件里，来自 main 之后落地的 IP-030。

我的整体评价

内容可以过，但合并路径目前是堵住的，两步缺一不可：先在当前 main 上 rebase 并解决 docs/concepts/interaction-pattern-catalog.md 的机械冲突（IP-030 之后插入 IP-031），然后重新取得一条会被 GitHub 计入的 approval——由于 rebase 会改变 head，现有那条 APPROVE 与本次资格判定都会失效并需要重跑。之所以没有直接在这里给出正式 APPROVE，是因为对即将被 rebase 重写的 head 追加同类结论没有意义，也会掩盖 REVIEW_REQUIRED 这个真实状态。

English verdict: APPROVE on content at exact head 23f9c63 — IP-031 is the correct next identifier (main stops at IP-030), it is registered in the family row, the P1 table, and its own section, and examples/interaction-pattern-catalog-smoke.py passes at this head. Merge readiness is nevertheless FALSE: loopx pr-review --check-merge-readiness 4374@23f9c6358 reports merge_state_requires_update (a real content conflict in docs/concepts/interaction-pattern-catalog.md caused by the later IP-030 landing) and github_review_decision_not_approved (GitHub still requires an approval that counts despite the valid APPROVE conclusion from another reviewer). Required next steps: rebase onto current main, resolve that conflict, push, and re-run the review and merge gates on the new head.

[huangruiteng]

队列前言（loopx pr-review --state open --limit 200，complete=true，policy_revision=3，other-developers-first）：本卡是 #4374 在 head 7b833560a 上的复审。原 head 23f9c6358 因与 main 冲突不可合并，本 head 是维护者在当前 main 上重排后的版本。

结论先行：通过。 内容与上一轮一致（IP-031 是 main 之后的下一个编号，三处登记齐全，目录 smoke 通过），本轮新增的是冲突解决后的复核，以及两条需要与并发 PR 协调的事项。

动机

Lark Manager 连接已经上线一条边界，但 interaction pattern catalog 里没有它的条目：把群消息作为 local-private context 保留下来，与「授权一次 Turn」是两件事。未登记的边界拿不到 canary archetype，后续任何针对上下文保留或 Manager 授权的改动都没有可继承的检查模板。补录是维护成本最低的收口方式，而不是新增机制。

改动思路

入口是 docs/concepts/interaction-pattern-catalog.md，它同时维护三处登记：State And Boundary 家族行、P1 目录表、以及 pattern-to-canary 映射与正文小节。PR 在三处都补了 IP-031，正文按既有模板写 trigger / expected behavior / visual model / bad smell / validation，并链接 manager-context 协议与 turn-start-sync、goal-topic-runtime、goal-topic-connections 测试。

我核对了 main 现状：目录最高编号是 IP-030（Human Decision 家族），IP-031 尚未占用，因此这是下一个可用编号，不存在重编号或重复登记。四个被引用的验证路径在当前树上全部存在。

具体改动

1 个文件 +67/−1：家族行由 …IP-026, IP-028 变为 …IP-026, IP-028, IP-031；P1 表新增一行（Owner 为 Manager connection owner，无中断、保留静默）；正文新增 IP-031 小节，说明「可见性≠授权」、授权只来自 provider 原生 mention、经验证的 reply 或既有 typed authority，并给出最多八条 / 4,000 字符的 context-only 预算与「历史回补不重放 Turn」的约束。

本 head 的差异只在冲突解决：原分支基线早于 main 的 IP-030 落地，两者改的是同一段家族行区块。我按「保留 main 的 IP-030 Human Decision 行 + 在 State And Boundary 行追加 IP-031」重排，作者提交内容不变，rebase 后 git diff --check 干净，examples/interaction-pattern-catalog-smoke.py 输出 ok。

补充一条与内容无关的排查记录：head 13cc490a9 上 Sign-off 曾失败，原因是该 PR 的 base.sha 仍停在开 PR 时的提交，DCO 的检查范围 base.sha..head 因此把 main 自己的合并提交（44a10c95c、e743f2404 等，本身没有 trailer）也算了进去；刷新 base 指针并 rebase 后范围只剩本 PR 的提交，检查自然转绿，没有任何提交被改动签署。

对主干的风险

文档型改动，风险限于「描述与实现不一致」：若正文写的边界与已上线的 Manager 行为不符，agent 会继承一个并不真正覆盖该边界的 canary 原型。我把正文的关键数字与规则逐条对到 docs/reference/protocols/lark-manager-context-authority-v0.md 与 loopx/extensions/lark/manager_context.py（MANAGER_CONTEXT_ITEM_LIMIT = 8、MANAGER_CONTEXT_CHARACTER_LIMIT = 4000、historical_context_only）以及 goal_topic_runtime.py 的 context_only_captured / replied_and_acknowledged，描述与实现一致。需要指出的是，目录 smoke 只校验接线结构，不校验正文与运行时是否漂移，这条已作为 P3 记录。

另一条需要协调的事项（P2）：另有一个并发 PR 以同一个编号 IP-031 登记同一模式（标题为 Manager Context Versus Turn Authority，P0 行，并带一段 state contract）。两者若原样落地，目录里会出现两个不同的 IP-031，且同一模式有两个优先级分类。合并计划是只保留一个 IP-031 条目，把并发方案的 state contract 细节与补充分验证链接并入该条目，这是维护者侧的集成决定，不是本 PR 自身的缺陷。

我的整体评价

这是一次最小形状的目录补录：无代码、无 schema、无默认行为变化，登记的边界已经上线，编号取用正确，三处登记与两个 smoke 的消费路径都验证过。冲突已解决且校验通过，两条观察（正文无法被 smoke 校验、并发同号登记）都已记录并给出处理方式，因此在本 head 上给出通过结论。

English verdict: APPROVE at exact head 7b83356 — IP-031 is the next free identifier (main stops at IP-030), it is registered in the family row, the P1 catalog table, and its own section, and examples/interaction-pattern-catalog-smoke.py passes at this head. The head is a rebase of the author's commit onto current main, resolving a pure stale-base conflict in the family row while keeping main's IP-030 registration; the rebased commit is signed off by both author and maintainer, git diff --check is clean, and all linked validation paths exist. Two non-blocking observations: the catalog smoke validates wiring rather than prose-versus-runtime agreement, and a concurrent pull request registers the same IP-031 with a P0 row plus a state contract, so the two must be unified into a single entry rather than landed as duplicates.

[huangruiteng]

合并决策记录（exact head 7b833560a）

决策：合并。 合并提交 f72fea4e0（Merge pull request #4374 from BigDataDZ/docs/catalog-manager-context-authority），第二父提交即本次评审并验证的 head 7b833560ac6dd4e55794c1819c9d96fb35fc83b。

变更面：docs/concepts/interaction-pattern-catalog.md，+67/−1。新增 IP-031 Manager Context Is Not Turn Authority：State And Boundary 家族行、P1 目录表行、以及带 trigger / expected behavior / visual model / bad smell / validation 的正文小节。

已跑检查

• python examples/interaction-pattern-catalog-smoke.py 在 exact head 输出 ok。
• PR 上 Sign-off、merge-gate、build、changes、dependency-review 与 docs 路径矩阵全部通过；其余 13 项（pytest、stage2c、windows-powershell、node 兼容、dashboard acceptance、sonar、deploy 等）按路径条件 skip。
• git diff --check <base>...HEAD 干净；IP-031 在目录中恰好三处登记；四个被引用的验证路径（manager-context 协议与三个扩展测试）都存在。
• 编号核验：main 当时最高编号为 IP-030，IP-031 未占用，故取下一个可用编号且未触发重编号。

失败、跳过与人工保留

• head 13cc490a9 上 Sign-off 曾失败，是检查范围问题而非提交问题：DCO 用 pull_request.base.sha..head.sha 取范围，而该 PR 的 base 指针仍停在开 PR 时的提交，于是范围把已合入 main、本身没有 trailer 的提交（如 44a10c95c、e743f2404）也算了进去。刷新 base 指针并在当前 main 上重排后，范围只剩本 PR 的提交，检查转绿，没有任何提交被改动签署。
• 未本地验证：无（纯文档改动，无运行时或后端路径可执行）。
• 非阻塞观察：目录 smoke 只校验接线结构，不校验正文与运行时是否漂移（P3）；另有一个并发 PR 登记同一编号 IP-031（P2），已按「只保留一条条目」的原则处理。

跨 PR 协调：并发 PR 以同一编号 IP-031 登记同一边界，并带 P0 行与 state contract。本次合并先落地本条目，并发 PR 随后以增补形式并入同一条目，不产生第二个 IP-031。

门禁说明：GitHub 规则要求 require_last_push_approval，而分支最后一次推送者与审批者是同一账号，reviewDecision 无法进入 APPROVED。合并前已取得该 exact head 的有效 APPROVE 结论，并按仓库所有者的显式授权使用规则集的 owner bypass 完成合并；bypass 只用于这一条推送审批要求，没有替代评审与验证证据。

English summary: merged at exact head 7b833560a (merge commit f72fea4e0) after an exact-head APPROVE and green required checks. Validation: catalog smoke ok, clean diff check, IP-031 registered exactly three times against a base whose highest identifier was IP-030, and all four referenced validation paths present. The earlier Sign-off failure was a stale-base range artifact, not an unsigned commit, and was fixed by refreshing the base pointer and rebasing. The owner ruleset bypass was used only for require_last_push_approval.