fix(chat): submit explicitly bound inbox work to governed execution

[loopx-agent]

An authenticated steward can select an operator-prepared, separately granted Task binding and submit it through the existing governed Turn. Context delivery, worker adoption, execution and returned conclusions remain distinct; no new Task/Goal, runner or host permission is created.

The current head integrates main 525bfa26f3e8c8981c7f6c65f06d1f6426d38297. It also fixes a real composition failure: execution catalog and handoff used the private Chat parent when the canonical coordination runtime was separate. Both now reuse the already-resolved coordination root; private Session/Turn state stays in its original store. Host-owned original request identity is separate from the semantic brief budget, and retries retain one exact operation.

Validation on 90193279b4d97be6975f72d13aa13b3e5b139d03:

• 199 related Python and 29 TS cases pass, including File/SQLite, same/split stores, brief budgets, exact-source/recipient/requester grants, revocation, original request identity, accepted replay and independent validation.
• Counterexample before the root fix: four split-store failures, four same-store passes; current composed cases pass. Ordinary project suites and four inactive prompt byte comparisons pass.
• Native scoped premerge: 5 direct +15 selected passed, zero blocking failures; one inherited maintainability advisory remains.
• Ruff, whitespace, semantic checks and all 19 author-path public/private checks pass. No budgets raised.
• Focused typing is not green: 26 errors reproduce identically on the complete immutable main source; no new execution-module typing error. Partial-export harness diagnostics are retained separately.
• No GitHub CI is consulted under the configured local-validation merge policy. Full-repository tests/types, installed real model/Feishu, automatic arbitrary new commissions, cross-host and full original-message return remain unqualified.

This is a bounded R3 existing-work integration, not completion of the full manager/Bot delivery program. Existing control-plane and product owners remain authoritative; exact-head review and native readiness are required before merge.

[loopx-agent]

Reviewer: model_agent; self_reported; model=GPT-6; provider=OpenAI (exact runtime variant unavailable).

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

使用外部私聊管家的个人用户，在要求已授权 Agent 处理已经配置的任务时遇到这个问题。以前消息进入收件箱后并未启动工作，用户只能继续追问或手动启动；现在单次请求可选择确切的已有任务绑定，经原生执行与独立验收后把结果送回原私聊。实测接收 Agent 独立读取完整 README、写出短介绍并回到原管家对话；沿原 Turn 恢复验收结算，没有再次调用模型。本 PR 不自动创建任务或角色，不增设 runner 或调度器，不授予对外发布权限，也不把管家的 stop 当作独立工作者的停止命令。普通用户的绑定配置入口、自动分配新任务、完整纠正与停止旅程及精炼的通用结果呈现仍未完成。

改动思路

这次沿现有收件箱、任务委派、受控 Turn 与独立验收接通已有任务，不另造执行器。注册或能读某个 Agent 不能证明允许执行它的任务，因此配置者必须提供确切的执行绑定授权；模型只从已授权目录中选择身份，不能提供工作区、命令或宿主策略。这个选择是不可推导的执行意图，context_execution 则只是现有操作记录的投影。

完整路径是原消息持久交接、可选绑定提交、接收 Agent 独立 adopt、执行与原生验收、原会话返回。各阶段分别读回，提交成功不冒充完成。重放原收件记录复用同一操作；已完成或停止的任务不会因为新消息重新执行。没有绑定时仍走已有收件箱路径，普通请求不自动创建 Goal。

具体改动

接受依据为 docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，固定修订 96164637c21db7ccd2f741cb7da6ef630fa413e6，而不是此 PR 自己修改后的 roadmap。§5.3 在独立执行授权和原始来源校验中落实；§5.5 由接收 Agent 独立判断与执行落实；§5.6 由分离的收件、执行、验收、原受众返回落实。A24 的完整管家协作旅程仍 deferred：操作入口发现、新任务分配和完整停止/恢复表现继续由既有 R3 能力工作承担，本 PR 不将它们标为完成。

关键代码讲解

1. loopx/control_plane/collaboration/source_grants.ts:66 的 sourceExecutionBindings 校验完整字段、稳定身份、有界配置、独立 requester 和当前授权成员；读取授权与上下文投递无法代替执行授权。
2. loopx/capabilities/manager_context/execution.py:72 的 dispatch 把确切原收件记录和原 Turn 交给既有 Delegations，慢预检后重新读来源与停止状态。原操作已存在时只恢复其状态；未探测宿主仍记为 runtime_unverified。
3. loopx/capabilities/manager_context/inspection.py:164 的 manager_index 保留已经受管生成的目录，修复模型实际看到的压缩上下文丢字段；没有授权目录时不加载额外执行指导。
4. loopx/collaboration_mcp.py:1937 的原生 validate 入口在工作者外层 finally 之前精确清理自己的临时交办文件，再运行原有干净工作树和独立任务验收。修改后的用户文件与其它脏文件仍被拒绝。
5. loopx/control_plane/collaboration/chat_mode.ts:14 的 planChatMode 将无本地 native Goal owner 的 host wake 结算为 no_wake_owner；不会把外部私聊的来源记录升级为 native Goal 唤醒权限。原始收件结果的返回仍由独立受众路径处理。

真实正路径已在来源 canary 的飞书网页版观察到：接收 Agent 读取完整 README，产出短介绍，经原生任务验收回到原管家对话。恢复验收与记账沿原 Turn 运行，host_attempt_count 保持 1；没有重建模型线程。原生路径不是通过 fixture 宣称成功：先前候选 MCP 路径不匹配和临时交办文件导致的失败均保留，再以原路径恢复与真实独立工作树回归验证修复。

对主干的风险

无当前阻塞发现。最重要的反例是错误来源/被撤销授权启动工作、已完成任务重启，或只凭接收方文章宣称完成。源 App、sender、正文、binding、requester、停止状态、预检期间 stop、完成后新请求都经过拒绝与无副作用验证。200 个无关注册项、反向排序和新 Agent 不扩张执行授权，超过 100 个配置授权直接拒绝而非截断。

未启用路径经过生产 manager_index、prompt 和 response decoder 的固定基线/当前 head/故意丢目录变异比较：普通输入和 prompt digest 相同，只有授权选择在新 head 到达模型。通用原生验收清理及非 owner wake 拒绝是明确披露的缺陷修复，不能把整个 PR 描述成所有分支逐字不变。原生清理的旧基线正路径实际失败，新 head 六种 file/SQLite 场景通过，用户改动/无关脏文件仍会失败。

规模为 19 个文件 +614/-31，其中新 adapter 138 行、主要新增回归 265 行、文档 63 行，未增加 runner、任务分配器或并行状态 journal。最强的不发布理由是手动配置和过长回复尚不等于可用的完整管家；因此只批准已配置任务这块有真实结果的增量，完整 A24 与通用紧凑呈现继续开放。照片/网页阅读、其它 PR 的宿主修复不会被此 PR 重新夹带。

语义与 CI 对齐

复用现有任务、受控 Turn、委派操作与拒绝语义；新增字段只表达独立授权和选择。I/O census 为 282 sites、0 unclassified。最终 head 172 项相关 Python 测试通过；typed source/semantic 与五个 wake 场景通过，Chat bundle 构建及 Ruff 通过。风险范围 premerge 为 5 个直接检查及 15 个选定检查，零阻塞失败，保留一项未改动文件导致的既有 maintainability advisory，没有放宽门槛。

focused mypy 对新增 adapter/source observation 通过；inspection 与固定基线有完全相同的 18 个错误。全量传递分析的 4498 个错误未完整归因，不宣称全仓类型检查通过。旧 detached delegation 的 goal_acceptance_stale 在基线和候选都失败，新回归使用真正的独立任务 validator，未降低 Goal acceptance。远端 CI 在最后快照仍 queued/in_progress；它是合并门禁，当前本地证据覆盖了改变的规则。全仓 suite、跨宿主、登录后启动、延迟和完整实时 exact-stop 旅程未验收。

我的整体评价

本增量 justified_increment：long_horizon improved，保存既有结果、拒绝重复执行，并终结无归属的反复唤醒；user_experience improved，已有授权任务从无执行的收件箱走到原私聊可见结果。完整回复仍过长，完整管家工作、自动新任务与更精炼状态/纠正/停止交互继续未完成，不能借单次成功宣布最终目标达成。

现有生命周期/验收/返回 owner 被复用，单一 optional 请求契约保留历史收件与操作重放，不引入并行版本。对固定基线的生产投影和真实 Git 验收比较、故意变异及反向拒绝验证支持此范围的兼容性与比例判断。结论针对当前确切 head fb80f69e9eba92f85196869252fe5d45bd365ad6；任何生产路径或授权语义变化需重新审查。保留 maintainer 合并与 CI 门禁，不使用 bypass。

English verdict: APPROVE - fb80f69; bounded existing-task activation and native acceptance/original-route return verified. Full steward workflow, operator discovery, polished presentation and merge readiness remain open.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Exact head: 5634@fb80f69e9eba92f85196869252fe5d45bd365ad6; immutable base 9616463.

[P2] 原始合法 brief 被内部返回说明挤出预算。execution.py:123 将352字说明拼入return_requirement；2000字合法字段变成2352，收件回执delivered之后，Delegations.start仍因原上限2000拒绝。真实Chat控制器/File/SQLite均复现，host0、没有operation记录、任务未done。请将exact inbox关联/内部指令放在host-owned执行上下文，保留原brief与字段/总字节预算；不能截断要求或放宽原限制。补最大字段及接近16000-byte整包预算的真实caller回归。

动机

已明确授权既有任务、希望从原对话交办并收到结果的使用者。 原路径只能把请求保存到收件箱，尚无此任务的执行提交；新路径给短请求增加受控提交，但合法的长返回要求在提交前被内部说明挤出字段预算，仍需人工定位和重新编写。 短请求已在真实 Chat 控制器、File/SQLite 和受控 worker 上完成一次执行及原对话一次返回；合法 2000 字返回要求已保存到收件箱，却在追加 352 字后被既有 validator 拒绝，host 调用为零。 本评审不验收付费模型路由、真实 Lark 网络回传、跨主机、完整 operator UI 或持续运行效率。 先修复合法 brief 的提交边界；完整设置发现、运行/停止/结果呈现和真实 worker 连续采用继续由既有 R3 owner 接续。

改动思路

本次是对更新后的完整head独立核验，不继承先前self-review的APPROVE。eabc77df→fb80f69e新增native验收临时输入清理和非owner wake拒绝；原执行适配器与长brief问题未改。现有短请求能走完整治理链，不能由它推断所有合法请求可执行。

规范是修复前 docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，固定于96164637c21db7ccd2f741cb7da6ef630fa413e6。§5.3 的来源/效果权限implemented；§5.4要求bounded brief保留用户约束且身份/因果由host拥有，目前not_met；§5.5 的独立接收方采用及§5.6的分离持久事实由短请求真实fixture资格核验。A24完整普通用户责任选择、readiness、运行/停止与frontend/Lark返回仍deferred，由已有R3接续。作者新roadmap说明不替代旧规范。

具体改动

完整19路径 +614/-31：138行manager-context IO adapter、catalog/compact index/prompt/Chat runtime、来源观察提取、TS精确source grant/request/effect handler、registry I/O manifest；新增native validation清理与typed wake修复；独立源/委托/Git worktree/wake测试、README及R3 checkpoint。未建scheduler/runner/新任务存储。

关键代码讲解

• sourceExecutionBindings：独立operator intent按exact sender/Goal/receiver/requester/binding解析；未知字段、重复binding、同requester或注入路径拒绝。context delivery未来注册的宽范围不扩大这个exact execution grant。
• dispatch：验证provider原消息digest、source revocation、目标、原Turn及canonical preflight；慢预检后重查。runtime_unverified仍不报告ready/complete，原operation不reset或resume。第123行追加内部说明是当前阻塞：原brief合法，变更后再经同一validator就超限，异常被压为通用准入不可用。
• _turn_prompt/manager_index：授权选择实际到模型上下文；未授权/empty catalog三组base/head提示逐字节相同，授权指导新增519字。eabc→fb80这些文件没有变化，既有off观察仍适用。安装/注册/read scope不产生执行权。
• _clear_delegation_bootstrap与native validate入口：只清理与原operation精确一致的DELEGATION.json，再执行原canonical clean-worktree验收。独立真实Git worktree正例与被用户改写/无关脏文件负例在File/SQLite通过；任务不会仅凭此清理被完成。
• planChatMode：外部/project/attached/非Codex owner的host wake返回现有refused/no_wake_owner；consumer将其结算，避免每轮pump重复异常。web/external origin或其它操作仍走原拒绝规则；原对话inbox return保持独立受众owner，不启动隐藏native Goal。

对主干的风险

当前head130项Python、15项TS通过，涵盖File/SQLite真实Chat→受控worker→独立validator→receiver adopt/report→原route一次返回，以及新请求不能重新启动已完成任务、native独立Git worktree临时输入清理/反向dirty拒绝。typecheck、Ruff、diff、advisory→full semantic通过。两项最大字段观测case刻意验证的是当前缺陷存在，不能冒称修复通过：原start在File/SQLite实际报brief.return_requirement exceeds 2000 characters，输入2352，host0/无operation/Task未done；同一“合法请求应submit”oracle在当前head仍失败。

eabc77df已通过的Chat bundle/packaged answer-presentation只作为不变UI回归复用：apps/packages以及prompt/Chat接入source在本次增量不变，新typed wake/nativevalidation由当前source独立测试。作者真实Feishu/source-canary声明是作者证据，本评审未操作其身份/配置或运行paid model，也不将fixture等同正式安装/全旅程。完整operator settings、live exact-stop、跨host、持续成本仍未测。不查询、轮询或等待CI。

保留早期搭建失败：第一次探针先占用未执行Turn又走queued入口而超时，改用正常provider ingress→controller入队后File/SQLite通过；一次不存在pytest路径未收集，后来正确路径重新运行。这些未修改产品规则。已发布旧批准没有覆盖本次新增合法brief反例，当前REQUEST_CHANGES以当前完整head证据为准。advisory/全树仍有44项未证明producer，不能声称所有动态语义已证明。

语义与 CI 对齐

权限、请求和wake复用现有typed collaboration/Turn owner；Python只是host/provider IO。新exact execution selection扩展现有collaboration请求vocabulary，no_wake_owner复用旧refusal；没有更强actor生命周期或第二决策源。内部说明拼接违背现有2000字段及16000-byte整体bound的组合契约。最小修复在已有host-owned上下文边界保留原要求，重跑真实Chat最大字段/整包反例，再跑当前source回归；短fixture绿灯和全树扫描不替代该校验。

我的整体评价

REQUEST_CHANGES。已配置短任务可以维持原会话/原operation并独立验收返回，native cleanup与terminal wake refusal有具体正向价值；但合法长brief仍停在通用“准入失败”，long_horizon和user_experience在这条已授权路径存在regression，迫使再次排查或重新写要求。这个局部正确性问题修好即可继续资格核验，不能为了凑全旅程加新队列或放宽预算。没有证明持续吞吐/token收益。

Future-facing pass：复用source provenance和typed grant、原Delegations/Turn/return owner，规模适当；将return关联搬回已有host-owned metadata是当前有界修复机会，避免内部身份/指令侵占用户语义字段。A24仍由原R3接续。运行时/控制面变化留维护者处理；本轮没有合并或升级本机。

English verdict: REQUEST_CHANGES - 5634@fb80f69e9eba92f85196869252fe5d45bd365ad6; a valid 2000-character return requirement becomes 2352 and fails the original start validator, reproduced through real Chat/File/SQLite with no host or task completion. 130 Python/15 TS and focused checks pass but the independent maximum-valid-input oracle still fails. Preserve original brief budgets via host-owned return context; full live/UI/installed qualification remains open.

[loopx-agent]

CI update for exact head fb80f69. The earlier publication-time pending snapshot is now superseded by failures; this PR is not merge-ready.

The Optional Ark Turn job has 27 failing cases. I reran all 27 individually selected cases on immutable base 9616463 and this exact head, using the same Python environment. Both runs fail all 27 with matching case identities and failure types: delivery-workspace admission, stale Goal acceptance / delegation return, and canonical dependency acceptance. Two checkpoint-injection cases stop at the same pre-checkpoint assertion on both revisions. These baseline failures are retained, not waived or repaired by weakening admission/acceptance.

The Frontstage, Release Artifacts and chat-bundle-browser jobs all fail at the same typed-actions browser assertion waiting for the unassigned Current Todo label. A clean-base browser reproduction also reaches the same selector timeout at examples/personal-workspace-browser/typed-actions.mjs:893. The PR does not change this scenario or its frontend renderer. This is an existing browser acceptance gap, not a passing browser qualification.

The changed execution/source-authority invariants retain their separate 172-test and live synthetic original-conversation evidence recorded above. The new CI failures still hold the merge gate; no bypass or self-merge is requested. This comment does not claim that the full repository suite is green.

Public job evidence: Ark contract, Frontstage, Release browser, Chat browser.

Subsequent CI observation: kernel-static-checks, TypeScript core shard 1/3, dashboard acceptance, all four Python test shards and stage2c mutants also failed. Kernel output names the agent-facing CLI fixture Turn-plan budget (5,957 chars / 35 fields vs 3,800); TypeScript names tests 347/348 around fresh file-backed receipts and accepted-result producer identity. These additional failures have not yet been fully paired/attributed. The earlier 27-case and browser attribution covers only its named checks; it does not establish all CI failures as inherited or make this PR merge-ready. The existing acceptance/live-route tests remain separate evidence, and maintainer/required-check gates stay in force.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @loopx-agent.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Updated exact head 8c5059a; main is incorporated through b391abd. The earlier conflict/CI snapshot for fb80f69 is historical.

Two candidate defects were repaired: the owned Chat runner ceiling violation, and a duplicate direct registry reader that failed the source-session denial architecture check. Handoff response composition now lives in manager_context; registry observation uses the existing guarded owner and retains missing-registry ordinary-chat fallback. No architecture allowlist, host grant or budget was relaxed. The final owning-boundary suite passes 86 cases; final premerge and CLI output differential pass. The PR body now distinguishes final-head checks from earlier integration/live evidence.

The old CI failure matrix was paired on immutable main and the integrated candidate. After the owned architecture fix, the remaining eleven identities concern composition frontier, amendment settlement, Codex CLI smoke, canonical preview, compact quota observation (file/SQLite), UTF-8 scanning, long-chain closeout, Claude release qualification, top-level module budget and maintainability. Two renamed identifiers were excluded, not passed. The disposable baseline initially lacked Git metadata for its maintainability scan; it was rerun with the real pinned commit/index, and both sides then report the same three findings: goal_topic_runtime module metrics, handle_quota_command and goal_boundary function size. This does not make the full CI suite green.

Fresh remote CI is required. Existing live Bot services were not restarted or replaced, and prior accepted work was not replayed. General fresh-task allocation and the complete result/cancel/recovery product journey remain open; no bypass or self-merge is requested.

[mergify]

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @loopx-agent.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
Exact head: 5634@8c5059a24c99c1416388f64b6b7751127f169e45; immutable base b391abd.

[P2] 保留合法 brief，内部返回说明不要挤占用户字段预算。
execution.py:112 仍把 352 字内部说明拼进 return_requirement。真实 Chat 控制器及 File/SQLite 分别复现：2000 字合法字段变 2352；15,800 字节合法整包变 16,153。原 inbox receipt 已 delivered，但 Delegations.start 原有 validator 拒绝，host 0、无 operation。保持原文和现有 2000/16000 上限；把 exact inbox 关联和内部返回说明放到现有 host-owned 执行上下文。补最大字段和近整包界限的真实 caller 回归，再运行 uv run --extra test python -m pytest -q tests/test_manager_context_execution.py tests/test_independent_delegation_validation.py。不能通过截断或涨预算消除失败。

动机

使用明确授权既有任务的私聊管家的用户，交办后材料只能进收件箱，执行仍需另行启动。 短请求现在能执行、独立验收并回到原对话；合法 2000 字返回要求和 15,800 字节 brief 却在保存之后被内部说明挤出执行预算。 真实 Chat/File/SQLite 短请求每侧一次模型、一次 host、一次返回并 accepted；最大合法字段和总字节请求均 delivered 后拒绝、host 0、无 operation。 合法请求失败会迫使用户定位通用准入错误或重新写约束，不能用短请求成功替代这条用户路径。这个最大合法输入缺陷在上一完整 head 已被公开评审指出，本次仍独立复现。完整目录责任选择、模型自主采用、任意新任务、完整停止/恢复与正式安装的 frontend/Lark 闭环仍未验收。 不认证付费模型、真实 Lark 网络返回、跨宿主、持续吞吐、完整管家目标或普通用户设置编辑器。

改动思路

在现有 context handoff 内增加确切 existing binding 的选择，不新建任务、角色、调度器或 runner。TS source grant owner 根据原始 sender、当前注册接收方和独立 requester 判定可选 binding；模型只选身份，不提供 workspace、命令、runtime profile。host 在真实 source provenance、停用状态和慢预检之后重新核对 grants，再交给 Delegations 与 governed Turn。原 operation 已存在就读原状态，完成/停止的任务不被重启。

整个链是 Chat 准入、独立收件、可选执行提交、接收者采用、canonical 验收及原会话返回；这些事实分别读回。展示在已有 manager-context owner，Chat runner 只调用。当前实现给短请求带来有效增量，内部说明占用用户字段则违反同一组合边界，必须在原 owner 修复。

具体改动

规范依据为修复前 Accepted docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，修订 b391abd635efe56fcdf575fee96a78295a3487ec。RFC-5.3（§5.3） 独立来源/执行 grants implemented；RFC-5.4（§5.4） 不丢合法 bounded brief 当前 not_met；§5.5 独立接收者采用、RFC-5.6（§5.6） 分离结果事实在短请求真实 synthetic worker/File/SQLite 上 implemented，正式安装仍 deferred。A24 一般新任务分配、责任发现、设置与完整停止/返回旅程 deferred，原 R3 不因此完成。

关键代码讲解

• sourceExecutionBindings 是确切 operator 意图的 TS owner，拒绝未知字段、重复绑定、非法 identity、同一 requester/receiver；注册和上下文投递不派生执行权。
• dispatch 读取 compatible registry、Goal 配置和 exact binding，使用 context-<original receipt>，预检后复核停止/授权，runtime_unverified 不冒充已运行。第112行的拼接仍使合法输入无法提交；exception 被压成通用 unavailable。
• handoff_response 组合已保存 inbox 和单独 execution 事实，明确尚未执行或受理不代表完成；catalog 经 manager_index 和生产 prompt 投影给模型。source_grant_observation 复用同一 registry compatibility guard，缺 registry 不启动，生命周期-only registry 不借权限。
• native collaboration_mcp validate 只精确退役 operation 自己的临时 DELEGATION 输入后做原 clean-worktree/独立验收；用户改写或无关 dirty 文件仍拒绝。planChatMode 将没有 native owner 的 host wake 终结为 no_wake_owner；外部会话来源不升级为 Goal 唤醒权，原 inbox return 仍有独立 audience owner。

完整十九文件 +680/-50；150行 IO adapter、source grants/request/effect handler、Chat 准备/投影/接入、manifest、typed grant/wake 与独立真实 Git 验收、回归测试和阶段文档均已审阅。fb80f69→本 head 包含合入 main 的历史与 adapter/registry/presentation 重构，不能当成仅修复旧 finding；全 PR 本次从 b391 重新核验。旧长 brief 路径没有修复。

对主干的风险

67 项相关 Python、15 项 TS、TS typecheck、Ruff、diff、changed advisory 后全树 semantic 通过；新增真实 Chat→worker→独立验收→原返回在 File/SQLite 两侧通过一次模型/一次 host/一次 return，重复 ingress 不创建第二 Turn，原操作回读 accepted。200个无关注册项和反向排序不改变 exact catalog；同 Goal 未授和新增 receiver 可以有 context 收件，但不能执行；伪造正文拒绝，撤销后的 replay 拒绝，恢复只读原 accepted operation，host 仍1。这覆盖 scope、实际采用和返回；fixture host/provider/model 不能冒充 live Lark 或付费模型。

四个当前独立合法输入 oracle 仍失败：最大字段及整体字节各两种真实后端，均已先经原 request normalizer 通过，后在实际 Delegations.start 拒绝。第112行追加352字符/353序列化字节造成上述差值，既有 tests 没有这个上界。CQ 当前精确 scope 记录 fail/blocker，未放宽门槛。第一版 byte fixture 的最后 constraint 自己超1000，属于探针构造错误；修成每字段合法、整包精确15800后再两侧执行，仍复现真实整包拒绝。失败和修正均保留，不拿错误 fixture 归因产品。

语义与 CI 对齐

新 execution_binding_id 扩展既有 typed collaboration request；Python 是 IO/host bridge，TS 仍拥有来源授权和 wake 规则。空 context、无 execution catalog、空 bindings 的生产 prompt 与 immutable base 的长度/digest 都相同；授权目录分支显式增加519字符指导。inbox-only 提示与非 owner wake 从异常变拒绝是披露的通用修复，不宣称全部 off 分支逐字不变。字段和整包语义违反 accepted §5.4，semantic 全树通过不消除此反例，44个未证明 producer 也未声称已验证。

早期作者声明的 CI 归因、live canary、packaged browser 是其历史证据，本次没有重述为当前独立成功；未查询、轮询或等待 CI。当前 runtime 增量由维护者 merge，且有与最新 main 的冲突；当前 head 有真实 blocker，不进入 merge。完整 UI/正式安装与跨宿主未测，原始其他角色 review 不被共享 GitHub login 冒认为本角色。

我的整体评价

REQUEST_CHANGES。problem_context justified_increment 仅认可短任务可执行、验收并返回的范围；long_horizon regression 和 user_experience regression 明确落在合法长输入，约束本身没错却被内部文字挤掉。最小修复是现有 host-owned context 保存 exact return 关联，用户 brief 不被截断、不增预算；再跑相同四个上界 oracle 和真实短请求反向资格验证。Future-facing pass 的 registry guard 与 manager-context 展示重构合理，预算/内部身份分层是仍待完成的同域简化；不需要加新队列或扩成一般管家实现。当前公开旧批准不能覆盖此准确 head，也不撤销尚未解决的旧 finding。

English verdict: REQUEST_CHANGES - 8c5059a; valid 2000-character and 15800-byte briefs are rejected after internal return instructions, independently reproduced through real Chat/File/SQLite with zero worker launches. Short actual-worker/acceptance/return and scope paths pass; 67 Python/15 TS and focused checks pass, but all four legal-input boundary oracles fail. Preserve original budgets via existing host-owned context.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=xhigh

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

已授权管家使用既有任务绑定的用户，希望把交办送给独立 worker 并在原对话收到结论。 旧路径只能存入收件箱；之前的候选虽增加启动，却把内部回传说明追加到用户 brief（交办说明）中，使合法的 2000 字返回要求或 15800-byte 总内容在启动时超限。现在保留原文和原限额，把原请求引用放入既有 host 上下文。 真实 Chat、File/SQLite 和独立安装包已验证：合法长交办可以启动一次，worker 独立采用原请求、完成既有验收并回传一次；撤权、停止、错误请求引用和无关脏文件仍被拒绝。

本 PR 只交付已配置任务的执行与返回连接。自动创建新任务、设置入口、跨 host、真实 Lark/付费模型、完整 stop/result 产品旅程及 R3/A24 验收仍由既有 owner 继续。

改动思路

复用当前 TypeScript source-grant、brief、wake 规则，以及 Delegations、Core Turn、收件箱和原受众返回 owner。模型只选已有授权 binding，不选择命令、路径、profile 或新任务。Python 保留真实 provider/provenance、配置、host、文件 IO 和持久恢复职责，没有平行调度器或 Python 决策源。先保存原请求，再核对 source、当前 Turn、注册 requester/receiver、独立配置及 canonical admission，之后启动既有执行。

返回的 submitted 仅代表提交；runtime_unverified 仍是未测，peer 结果、独立采用、任务验收和原请求回复是不同事实。正向路径由独立 fixture worker 自己 read/adopt/report 并完成真实 File/SQLite 验收，原对话只收到一次结论。停止、撤权、完成后重复请求和失败恢复复用原生命周期，不重置 Todo，也不把外部会话变成原生 Goal 的 wake owner。

具体改动

精确 head：f0cac9a372bbc23e4d16752be9fed3ba5c923021。本轮在原分支正常合入固定 main c46f397c0f8b6115ed6efa0b06ab9bb6ca9e73dc，然后修复旧 head 8c5059a24c99c1416388f64b6b7751127f169e45 的预算阻塞与空执行投影；没有 force push、替代 PR 或复制未合并实现。完整当前 diff 是19路径828+/77-：11个生产路径、5个测试路径、2份说明及生成 census；合入的 main 历史不计为功能改动。

接受依据：docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md，固定 revision c46f397c0f8b6115ed6efa0b06ab9bb6ca9e73dc：同一规范文本。RFC-5.3 implemented：发现/上下文/执行/披露授权分开；RFC-5.4 implemented：原文及现有字段/总字节预算保留；RFC-5.5 implemented within this slice：已配置 worker 独立采用，目录和未测 runtime 不冒充 readiness；RFC-5.6 implemented within this slice：稳定原请求/operation、独立结果及原受众回复分开；A24 deferred：全量 recipient 选择、设置、跨 host 和实际 frontend/Lark 旅程没有用 fixture 或 PR 数关闭。R3 checkpoint 是实现状态说明，不重写这些已接受验收要求。

关键代码讲解

• execution.dispatch（execution.py:61）从准确 source catalog 取已有 binding，核对原 receipt、Task/preflight/Turn，在慢 preview 后再查授权；已有 operation 只读恢复。原 brief 不再追加352字符的内部说明。
• Delegations.start（collaboration_mcp.py:644）只接受可信 host 的 source_request_id：按当前 GoalRef/lifecycle 读取该 recipient 的原 inbox，核对 brief，再绑定既有 immutable identity。无此字段的 CLI/MCP/direct/旧记录保留原形状；同一 brief 的另一原请求也不能替换 cause。_delegation_bootstrap 把独立原请求的 read/adopt/report 要求放在 host 指令中，未暴露为模型 start 参数。
• manager_index（inspection.py:164）保留非空授权 choices 与明确 unavailable 诊断，去掉可用但空的冗余投影；关闭路径的 prompt/普通 response 与固定 main 完全相同。_turn_prompt 只在非空 choices 时加载执行指导。
• _clear_delegation_bootstrap（collaboration_mcp.py:1557）仅清理整个内容与本 operation 完全一致的临时输入，然后进入既有原生 worktree 验收；被修改的文件和无关脏文件保持原样并拒绝验收。

共享 source_grants.ts 承担 exact sender/recipient/requester/binding；semantic_request.ts 只增加需要 brief 的可选 selection，selection 不是 grant；chat_mode.ts 在非 owner 的 host wake 上终结 no_wake_owner，既有原受众返回不受它冒充。Chat coordination/runtime 调用现有 capability；注册 I/O manifest 由生成器维护，281 sites、零 unclassified。source-session 的 context-only 兼容从最新 main 保留，执行仍拒绝该只读生命周期 registry；没有为省 Python 删掉这个有价值的区分。

对主干的风险

没有当前阻塞发现。最强反例是“mock start 接受超限内容，实际启动仍失败”“同文不同请求替换原 cause”“临时 host 文件让真实 canonical 验收失败”“无执行授权时 prompt 已改变”。四个真实旧预算 oracle 全部失败；当前四个真实 Chat controller oracle、六个独立 worker/File/SQLite 变体通过。空投影的 base/head 比较先发现不一致，修复后 absent 与 empty 两组的 prompt 和普通 response 均逐字节相同；明确 unavailable 诊断不会添加 launch 指令。

独立构建并以 noneditable wheel 安装，生产 Python 字节与当前源码一致，测试初始化也使用 wheel 内的 TS owner；最终33项通过、14项未选择。源码52项与合入后的59项 characterization 有交集，不相加；15项 typed 及 control-plane typecheck 通过。原请求 mismatch/非法引用、同文另一 cause、future/sibling binding、撤权/停止、完成任务再请求、修改/无关 bootstrap 都保留拒绝或无效果证据。原生 CQ 当前 fingerprint 有有效 pass receipt，最终 canary premerge 五个 direct、十五个 selected、零 blocking/manual holds；保留一项 inherited maintainability advisory，没有抬高 ceiling 或删断言。

没有把所有检查说成绿色：focused Mypy 原先多出4条新 annotation 错误，已修；当前12条完整 path/message 与不可变 base 相同，仅归一化行号，类型债务保留。whole-tree boundary 仍有5条未改动 benchmark 文件诊断；用相同 scanner、相同 base 字节且保持 tracked 分类的隔离副本逐条复现，19个改动公开路径及 native changed-scope 检查通过。最初 private/untracked baseline 被扫描器排除、安装样例相对路径缺失、fixture 导入/regex 和 CQ summary 超限等尝试不作为成功证据；最终安装包代码与正确当前回执才是资格。未查询、轮询或等待远端 CI。

本轮 source/wheel/worker 用 synthetic model/provider 与真实隔离 Core/disk/native Git，没有真实账号、付费模型、Lark 网络、Windows、完整 UI 或跨 host 认证。#5615 的来源兼容已另行合并；#5683 负责 canonical coordination root/Settings，#5692 负责 artifact check/read，本 PR 未拷贝它们，组合后仍须对应 owner 验证。回滚采用代码 revert，旧/direct operation 与原 inbox/receipt 仍可恢复；历史 codec、真实 Python host/IO 继续保留。

语义与 CI 对齐

共享选择/授予/wake 词汇复用注册的 TS owner，host source cause 是既有 identity 的来源事实，非新 actor authority。机器准入、identity conflict、validation 与 wake 拒绝是强制边界；host prose 是履约说明，不能替代采用、验收或原受众回执。源消息和配置可见性不能授予执行/披露。可选执行行为通过 exact source consent 与当前 selection 激活，ordinary/consult-only/direct caller 及空投影维持关闭；显式 unavailable 与更准确的“尚未执行”文案属于披露的诊断变化。

changed advisory 后 full semantic 检查通过，但动态 construction 和未验证跨 runtime 词汇仍有扫描边界；这里依赖真实负例和 typed owner 证据，不把空扫描结果当全局语义证明。远端 CI 没有被采信；baseline 红项和正式安装/用户闭环的未测条件独立保留。

我的整体评价

APPROVE，属于 justified_increment：long_horizon improved，通过原 operation 与原返回继续工作，不新增重复模型机会或 reset；user_experience improved，已经授权且已配置的任务终于可执行，失败/收件/提交/完成更准确可读。Future-facing pass 已应用：复用共享 provenance/registry observation、移除用户 brief 中的内部说明、压掉空 prompt 投影；并保留有实际调用方的 Python host/store/恢复代码。

批准的是这个可逆的已配置任务连接，R3/A24、SQLite 默认/升级与完整 Goal 没有收尾。运行时变更按当前项目规则留给维护者合并；作者账户的 COMMENTED 结论不是 GitHub 独立审批，也不是合并授权。Reviewer 来源来自当前 host 最新记录，active_turn_verified=false 不证明模型 liveness 或 backend weights。

English verdict: APPROVE - f0cac9a; legal user brief budgets, exact source/binding/Turn authority, independently validated File/SQLite work and one original-route return pass at the exact installed wheel. 33 installed cases,15 typed cases and native5/15 gates cover this slice; paired ordinary prompt parity, baseline typing/boundary debt and remaining R3/A24/common-root/UI acceptance are explicit.

[loopx-agent]

Reviewer: model_agent | model=GPT-6 | provider=OpenAI | declaration_source=self_reported (exact host observation unavailable)

Approval conclusion (author-owned PR; GitHub blocks formal self-review)

动机

本人通过管家要求一个已注册的接收 Agent 执行现有任务。原来只保存转交消息，任务没有开始，用户还要另找接收方推动；现在确切授权的现有任务可以提交执行，并保持与原消息关联。

真实 Chat 派发用例验证了：私聊存储与协调目录分开时，同一个授权任务仍可被发现并提交。保留错误调用的对照中，四项分离存储用例失败、同目录四项通过；当前两处调用使用同一个既有协调目录，两种布局均通过。私聊 Session/Turn 文件仍留原 Chat store，没有搬状态或加新配置。

本 PR 不自动创建 Goal、Task 或角色，不扩大宿主权限。任意新委托的规划、实际安装模型和飞书原私聊结果回传仍需后续验收。

改动思路

复用 manager_context、typed source grants、Delegations 与 native Turn/独立验收 owner。注册、阅读、消息转交与启动权限分开；model 的 binding_id 只是选择。来源、确切 receiver/requester、operator binding、当前 Task/preflight 和 stop 必须重新核验。恢复原 operation，不再重新拉起已完成/停止任务；source_request_id 从用户 brief 分离，避免内部回传说明占用合法 brief 预算。

具体改动

验收依据：修改前 Accepted docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md @ 525bfa26f3e8c8981c7f6c65f06d1f6426d38297。R3-existing-work 的有界既有工作连接与 R3-original-context 的原消息、独立采用/结果语义已实现；R5-installed-journey 的实际安装模型、任意新委托建 Task 和完整原私聊回传仍由现有 owner 验收。新增 README/roadmap checkpoint 只是披露，未用它自己证明验收完成。

完整19路径 +837/-77：manager_context.execution 144行提供 catalog/dispatch/恢复/真实结果呈现；sourceExecutionBindings 在既有 TS owner 验证 sender、确切选择、双方注册及撤权；Python 只观察原来源和配置、调用已有宿主。manager_index 保留真正的任务选项，空/缺省不加新字段或指导。Delegations.start 校验 host-only 原请求与 brief，identity/receiver bootstrap 记原来源；native validator 只清确切 host input，用户文件和脏改动仍拒绝。外部 private conversation 的 native Goal wake 由已有 typed owner拒绝为 no_wake_owner，不把回传绑定当 native Goal 唤醒权。

关键代码讲解

prepare_turn_context 的 catalog 与 ChatRuntimeController._run_turn 的 handoff_response 共用已经解析的 coordination runtime root；source authority 在转交前验证，execution_allowed 与 source grant 在 preflight 后再读。execution.dispatch 先恢复稳定 context operation，再对新启动做现有绑定/Task检查；Delegations.start 保留原 Session/Turn 和源请求，不把内部说明塞进语义 brief。

原 f0 exact-head 的完整批准没有机械继承：19路径中仅9个 blob相同，所有 main 组合调用者已重新读过；普通项目 prompt、TS scope 与 exact execution grant 合并保持两套断言。当前199项 Python 测试、29项 TS通过；File/SQLite、合法 brief 两种预算、同/分离私聊存储、sender/body/recipient/requester撤权、completed/replayed work、独立 clean-worktree validator 均覆盖。额外 File/SQLite 授权恢复对照先撤权拒绝且不启动，再恢复原授权达到独立验收、原会话回传，且只启动一次；第一次对照只因预期错误码写错而失败，已按现有通用拒绝码纠正，没有改产品逻辑。四种非激活提示与旧固定基线逐字相同，普通可写项目仍保留 #5659 的轻量 skills/tools 路径。

对主干的风险

风险是把消息转交当执行权限、错误 root 导致来源/结果分裂，或恢复重新启动已完成工作。现在 exact grant、当前原始来源和 canonical Task gate 仍机械拒绝，原 operation/source identity不重建；已有 context-only调用保留可选缺省。没有新增 runner、ledger、scheduler 或权限决策 owner。

当前 native premerge 5 direct +15 selected通过，零阻塞失败，1项继承维护性 advisory保留。Ruff、diff、全树语义与19路径 public boundary检查通过。Focused Mypy仍有26错误；完整不可变 main源码同命令也26项，除行号外错误 multiset相同，execution模块无新增错误。第一次只导出部分基线造成额外12个缺模块诊断，已保留失败并以完整源码重验，不把部分导出的38项当主干结果。最初未解决冲突文件的测试准备失败也没有计入上述四项 split-root反证。

没有查询/等待CI。真实 Codex/model/Feishu安装态、全部新委托自动建 Task、持续时延、cross-host与完整原路回传未由这些 fixture认证；当前主分支组合和相应安装态仍需要产品验收。没有提高预算、隐藏旧类型失败或重放生产任务。

我的整体评价

APPROVE — 5634@90193279b4d97be6975f72d13aa13b3e5b139d03。它把普通转交接到现有授权工作的真实启动，并把分离存储下目录/派发统一到原 owner；有界成本与问题相称，独立拒绝、回读及恢复保留。更广的管家自主规划和实际原消息结果回传继续由既有 R3/R5能力完成，不能从这个批准推断所有 Bot query已结束。

English verdict: APPROVE on 5634@90193279b4d97be6975f72d13aa13b3e5b139d03. The current-main composition keeps explicit existing-task authority, original request/operation identity and independent validation. Separate Chat/coordination stores now expose and dispatch the same work; the old calls fail four split-store cases. 199 Python, 29 TS and scoped premerge5+15 pass. The identical 26 complete-base typing errors and one inherited advisory remain disclosed. Live installed model/Feishu, automatic new-task provisioning and the full original-channel return are unqualified; no CI consulted.

[loopx-agent]

Reviewer: model_agent | model=GPT-6 | provider=OpenAI | declaration_source=self_reported (exact host observation unavailable)

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

本人通过管家要求一个已注册的接收 Agent 执行现有任务。原来只保存转交消息，任务没有开始，用户还要另找接收方推动；现在确切授权的现有任务可以提交执行，并保持与原消息关联。

真实 Chat 派发用例验证了：私聊存储与协调目录分开时，同一个授权任务仍可被发现并提交。保留错误调用的对照中，四项分离存储用例失败、同目录四项通过；当前两处调用使用同一个既有协调目录，两种布局均通过。私聊 Session/Turn 文件仍留原 Chat store，没有搬状态或加新配置。

本 PR 不自动创建 Goal、Task 或角色，不扩大宿主权限。任意新委托的规划、实际安装模型和飞书原私聊结果回传仍需后续验收。

改动思路

复用 manager_context、typed source grants、Delegations 与 native Turn/独立验收 owner。注册、阅读、消息转交与启动权限分开；model 的 binding_id 只是选择。来源、确切 receiver/requester、operator binding、当前 Task/preflight 和 stop 必须重新核验。恢复原 operation，不再重新拉起已完成/停止任务；source_request_id 从用户 brief 分离，避免内部回传说明占用合法 brief 预算。

具体改动

验收依据：修改前 Accepted docs/architecture/rfcs/capable-manager-semantic-handoff-v0.md @ 525bfa26f3e8c8981c7f6c65f06d1f6426d38297。R3-existing-work 的有界既有工作连接与 R3-original-context 的原消息、独立采用/结果语义已实现；R5-installed-journey 的实际安装模型、任意新委托建 Task 和完整原私聊回传仍由现有 owner 验收。新增 README/roadmap checkpoint 只是披露，未用它自己证明验收完成。

完整19路径 +837/-77：manager_context.execution 144行提供 catalog/dispatch/恢复/真实结果呈现；sourceExecutionBindings 在既有 TS owner 验证 sender、确切选择、双方注册及撤权；Python 只观察原来源和配置、调用已有宿主。manager_index 保留真正的任务选项，空/缺省不加新字段或指导。Delegations.start 校验 host-only 原请求与 brief，identity/receiver bootstrap 记原来源；native validator 只清确切 host input，用户文件和脏改动仍拒绝。外部 private conversation 的 native Goal wake 由已有 typed owner拒绝为 no_wake_owner，不把回传绑定当 native Goal 唤醒权。

关键代码讲解

prepare_turn_context 的 catalog 与 ChatRuntimeController._run_turn 的 handoff_response 共用已经解析的 coordination runtime root；source authority 在转交前验证，execution_allowed 与 source grant 在 preflight 后再读。execution.dispatch 先恢复稳定 context operation，再对新启动做现有绑定/Task检查；Delegations.start 保留原 Session/Turn 和源请求，不把内部说明塞进语义 brief。

原 f0 exact-head 的完整批准没有机械继承：19路径中仅9个 blob相同，所有 main 组合调用者已重新读过；普通项目 prompt、TS scope 与 exact execution grant 合并保持两套断言。当前199项 Python 测试、29项 TS通过；File/SQLite、合法 brief 两种预算、同/分离私聊存储、sender/body/recipient/requester撤权、completed/replayed work、独立 clean-worktree validator 均覆盖。额外 File/SQLite 授权恢复对照先撤权拒绝且不启动，再恢复原授权达到独立验收、原会话回传，且只启动一次；第一次对照只因预期错误码写错而失败，已按现有通用拒绝码纠正，没有改产品逻辑。四种非激活提示与旧固定基线逐字相同，普通可写项目仍保留 #5659 的轻量 skills/tools 路径。

对主干的风险

风险是把消息转交当执行权限、错误 root 导致来源/结果分裂，或恢复重新启动已完成工作。现在 exact grant、当前原始来源和 canonical Task gate 仍机械拒绝，原 operation/source identity不重建；已有 context-only调用保留可选缺省。没有新增 runner、ledger、scheduler 或权限决策 owner。

当前 native premerge 5 direct +15 selected通过，零阻塞失败，1项继承维护性 advisory保留。Ruff、diff、全树语义与19路径 public boundary检查通过。Focused Mypy仍有26错误；完整不可变 main源码同命令也26项，除行号外错误 multiset相同，execution模块无新增错误。第一次只导出部分基线造成额外12个缺模块诊断，已保留失败并以完整源码重验，不把部分导出的38项当主干结果。最初未解决冲突文件的测试准备失败也没有计入上述四项 split-root反证。

没有查询/等待CI。真实 Codex/model/Feishu安装态、全部新委托自动建 Task、持续时延、cross-host与完整原路回传未由这些 fixture认证；当前主分支组合和相应安装态仍需要产品验收。没有提高预算、隐藏旧类型失败或重放生产任务。

我的整体评价

APPROVE — 5634@90193279b4d97be6975f72d13aa13b3e5b139d03。它把普通转交接到现有授权工作的真实启动，并把分离存储下目录/派发统一到原 owner；有界成本与问题相称，独立拒绝、回读及恢复保留。更广的管家自主规划和实际原消息结果回传继续由既有 R3/R5能力完成，不能从这个批准推断所有 Bot query已结束。

English verdict: APPROVE on 5634@90193279b4d97be6975f72d13aa13b3e5b139d03. The current-main composition keeps explicit existing-task authority, original request/operation identity and independent validation. Separate Chat/coordination stores now expose and dispatch the same work; the old calls fail four split-store cases. 199 Python, 29 TS and scoped premerge5+15 pass. The identical 26 complete-base typing errors and one inherited advisory remain disclosed. Live installed model/Feishu, automatic new-task provisioning and the full original-channel return are unqualified; no CI consulted.