Skip to content

Help wanted: capable manager & semantic handoff / 强能力管家与语义交接（RFC #4330） #4339

Open
Open
Help wanted: capable manager & semantic handoff / 强能力管家与语义交接（RFC #4330）#4339
Labels
direction/architecture-evolutionArchitecture evolution and research-incubator work.direction/operator-surface-imOperator surfaces, frontend control plane, and bounded IM integration.enhancementNew feature or requesthelp wantedExtra attention is needed

Description

@huangruiteng
huangruiteng
opened on Sep 13, 2026

Summary / 目标

Help build a capable LoopX manager that can investigate with ordinary host tools, hand work to another agent without losing its meaning, and return the result automatically.

The bilingual RFC landed in #4330. This is an implementation invitation, not a feature-release announcement: the document records proposed behavior and acceptance requirements, not completed M1–M4 qualification.

  • RFC: English · 中文
  • Scenarios and design feedback: Discussion #4340 / 场景与方案讨论.
  • Direction: Operator Surface / IM Integration, with a shared TypeScript collaboration boundary.
  • Intended base: current main; check existing work before choosing a slice.
  • This issue is a public coordination entry point. Link existing engineering Todos, issues and PRs; do not create a parallel authoritative task ledger.

Inherited acceptance: PR investigation and responsible routing (#4305)

Product triage on 2026-09-24 consolidates #4305 here; this is not a claim that its original Lark journey is fixed. The superseded dedicated-provider/automatic-evidence-handoff proposal is retired. Keep the user outcome under existing M1/M2/M3 owners:

  • M1: answer a concrete PR question using ordinary tools within the effective host/provider/audience grants; retain the actual revision, coverage and read failure. Missing local evidence alone must not create delegated work or trigger repeated unrelated pagination.
  • M2: when authorized specialist or sustained work needs delegation, inspect current registered responsibilities/work and choose a suitable receiver. Exercise two different-role receivers, a sole incompatible receiver, missing/ambiguous responsibility information and stale discovery. Registration or list position does not prove suitability; absence of a convenience profile alone does not disqualify an otherwise evidenced receiver. Preserve a visible unresolved route when no suitable authorized receiver can be established.
  • M3: return the sourced conclusion to the original audience, preserving correction context, restart recovery, revocation and duplicate-effect protection. Qualify the restricted external/Lark route separately from private-owner host tools.

Existing foundations: #4303 (configuration source), #4337 (private-owner host profile), #4675 (semantic collaboration), #4372 (uncertain-return verification). These do not prove the exact missing-PR/two-role/Lark scenario. Reuse that scenario in a bounded existing collaboration slice; no separate PR-only capability, scheduler, mandatory profile allowlist or new task ledger is requested. RFC §6's live investigation/routing obligation is retained here, not waived by closing #4305.

中文：#4305 的独立旧方案停止推进，真实价值保留为本 issue 的验收场景：授权内直接查证、必要时按实际职责交接、结果回原会话。双角色/唯一不适任接收方和飞书真实旅程尚未验收，不能标为已修复。

Contribution areas

Area Useful contribution Acceptance anchors / dependencies
M1 — capable host manager Ordinary file/Git/tool investigation within existing authorization; accurate effective profile/session readback; actionable failures. A1–A3, A12. Can proceed without the general handoff refactor or storage-provider promotion.
M2 — semantic work continuation Replace one complete request transaction in the typed collaboration boundary; preserve intent, corrections, evidence and pending obligations across manager→worker and worker→worker. A4–A7, A11, A13–A16 on supported paths. Start with caller/record characterization, migration mapping and one writer; reuse existing Goal/Todo/Vision/lease authority and the #4094 continuation adapter.
M3 — automatic return and visible state Recover saved replies, reconcile uncertain delivery, and show request/assessment/result/delivery accurately in packaged frontend, Lark and CLI. A8–A10 and relevant A13–A14 return paths. Independent reply-recovery fixes can use existing inbox/outbox now; general producer integration follows M2's receipt contract.
M4 — qualification and retirement End-to-end journeys across three heterogeneous active Goals, private/shared audiences and configured SSH; failure injection, measured latency/cost and removal of superseded paths. Follows verified M1–M3. Promote only the named, tested scope; storage promotion and shared-goal amendment commits retain their own gates.

Best starting points: one real M1 investigation journey, an independent M3 reply-recovery bug, or a reproducible acceptance fixture. M2 is a cohesive transaction replacement, not a collection of disconnected new fields or an unused framework.

How to participate

Comment with:

Area / milestone:
User problem and smallest useful slice:
Existing issue / Todo / PR, if any:
Runtime and affected entry points:
RFC acceptance IDs and validation plan:
Dependencies / non-goals:

Use the thread to coordinate overlap before starting a large refactor. Contributions can be implementation, design review, real-runtime validation or public/synthetic reproductions. A whole milestone is not a prerequisite for participation.

Completion and boundaries

  • Bind evidence to the actual source/runtime revision. Test failure, restart and compatibility paths, not only the happy path; UI/IM changes require real entry-point readback.
  • Preserve pending requests, historical decisions and result receipts during migration. Delivery, receiver assessment, accepted work and completed work are different facts.
  • Preserve existing authorization and audience isolation. A message, capability switch or handoff cannot grant new host permissions or broaden disclosure.
  • No new runtime, second scheduler/task database, implicit provider promotion or unqualified shared-goal amendment effect is in scope.
  • Use public or synthetic examples. Do not post credentials, private transcripts, internal links or local active-state files.

中文：一起把这条协作链做完整

我希望管家能在现有授权内充分调查，合适的短工作自己完成，持续或专业的工作交给对应 Agent；交出去的不只是一句话，还包括背景、纠正、已排除方案、证据和期望回报。接收方判断如何接续自己的计划，做完后，用户不用再追问“结果呢”。

欢迎参与四个方向：M1 本机调查能力、M2 通用语义交接、M3 自动回传与前端/飞书可见性、M4 真实旅程验收与旧路径退役。 M1 和独立的正文恢复可以先做，不必等完整 handoff 重构；M2 需要围绕一个完整事务交付，保留已有工作状态权威。

不必一次认领整份 RFC。可以选一个具体问题，贴出拟做范围、关联的已有任务/PR、运行时、验收 ID 和验证方法，再协调实现。真实失败案例、反例和设计审阅，同样是有价值的贡献。

本 Issue 只汇总参与入口和公开结果，不复制另一份工程任务权威；RFC 已合入，不等于其中能力已上线。

Activity

  1. huangruiteng
    added
    enhancementNew feature or request
    help wantedExtra attention is needed
    direction/operator-surface-imOperator surfaces, frontend control plane, and bounded IM integration.
    direction/architecture-evolutionArchitecture evolution and research-incubator work.
    on Sep 13, 2026

  2. LIHUA919 commented on Sep 14, 2026

    @LIHUA919
    LIHUA919
    on Sep 14, 2026
    Contributor

    @huangruiteng 想确认一个可独立交付的 M3 切片是否已有负责人，避免与现有工程 Todo 重叠。

    • Area / milestone: M3，异步 worker 结论的送达核验恢复；对应 A8/A10 的有界子场景。
    • 问题与证据： 最新 main 201da973c603de7eb4d84b167bd5706819827fdf 的 manager_context/roundtrip.py::drain 在 external_write_performed=true、reply_verified=false 后写入 verification_required，之后的 pump 跳过该状态。已有 test_ambiguous_provider_write_is_not_blindly_resent 正确保护“不盲目重发”；希望在这个保证之上补只读核验原发送的路径。
    • 最小范围： 先限定 provider 已返回消息定位、随后读回暂时失败的情况。由既有 Lark adapter 私有保存最小发送事实，复用 return pump 只读核验原消息，成功后关联原结果的送达回执。无法定位或证据不充分时继续明确未验证，不自动重发、不重跑 worker/model。
    • 复用与入口： 复用 fix(manager): recover saved Lark replies after format failures #4314、现有 manager-context roundtrip、Lark manager_returns/inbox_reply；覆盖 Chat return service、manager-inbox 状态及现有前端/Lark 反馈。fix(chat): scope attached completion messages to turns #4353 的 attached completion transcript 修复与此范围不同。
    • 验证计划： 发送成功但读回失败、重启、重复 pump、正文/受众冲突、权限撤销、旧记录缺定位与 provider 离线；保持重复外部效果为零，并补授权测试入口的真实读回。此前固定基线 5ce8e9fcf 上相关 22 项测试通过；这不是当前 head 的完整验收或真实 Lark 验收声明。
    • 不包含： M2 通用请求/session 接管、Todo/lease authority、provider 晋级，以及无法定位发送结果的通用自动恢复。

    这个窄范围能由我承接吗？如果已有 M3 Todo 或正在实施的重叠工作，请指向其公开关联项或建议边界；我会复用已有任务，不另建平行账本。此留言先确认分工，尚未开始实现。

    English: Could I take this bounded M3 slice: read-only reconciliation of an asynchronous worker reply whose provider message locator is known but delivery readback failed? It preserves the existing no-blind-resend guarantee and reuses the current result/return owners. Please point me to the existing M3 work item or any overlapping implementation before I start.

  3. huangruiteng commented on Sep 14, 2026

    @huangruiteng
    huangruiteng
    on Sep 14, 2026
    CollaboratorAuthor

    @LIHUA919 可以承接，而且建议把它扩成一个仍可独立合并的 M3 delivery verification vertical slice，不只停在 pump 的一个分支。

    建议你负责的范围

    1. Provider-neutral 送达核验事实

      • 在现有 result/return owner 中定义最小、可持久化的消息定位与只读核验证据；不要新建第二套 outbox 或任务状态。
      • Lark adapter 负责保存 provider 返回的最小 locator，并把读回结果关联到原 result/delivery identity。
      • 兼容旧记录：有可靠 locator 的可以恢复；无 locator、locator 冲突或证据不足时保持 explicit unverified，不猜测、不重发。

    2. 幂等恢复状态机

      • 覆盖 external_write_performed=true && reply_verified=false 后的后续 pump、进程重启和重复 pump。
      • 核验成功后只补 verified delivery receipt；权限撤销、provider offline、正文/受众不一致、消息不存在等情况保留可行动且真实的失败状态。
      • 外部重复效果必须为 0；不得重跑 worker/model，也不得用“再发一次”代替 reconciliation。

    3. 同源用户可见状态

      • 让 Chat return service、manager-inbox CLI/readback、现有 frontend 和 Lark 投影读取同一组 queued / verification_required / delivered / explicit-unverified 事实。
      • 覆盖 RFC A8–A10，包含 A9 的长正文/截断 trailer 恢复；A17 只做“已发生外部发送后的 return-pump/进程重启”这一半，不承担 session takeover。
      • 提供 deterministic fixtures、重启/重复投递/权限/冲突测试和 packaged frontend 状态证据。真实私有 Lark canary 可由我在你的精确 PR head 上补做，不要求你接触私人群或凭证。

    仍由我负责 / 非目标

    请基于当前 main，先贴一个简短 ownership map（现有 writer/reader、拟改文件、兼容边界）再开实现 PR；PR 描述绑定 A8/A9/A10 的具体测试。你的切片可以与 M1/M2 并行，不需要等待 #4337，但不要宣称通用 handoff schema 已交付。开 PR 后在这里贴链接，我会避开同一代码面并做 exact-head review/集成。

    English: Please take an expanded but still independently mergeable M3 delivery-verification vertical slice: provider-neutral persisted locator/verification facts, Lark read-only reconciliation, idempotent restart recovery, and truthful shared CLI/frontend/Lark delivery states. Preserve zero duplicate external effects and explicit unknowns. Generic M2 transaction/authority, unknown-locator recovery, producer integration, private canary, and full M3/M4 qualification remain with me.

  4. LIHUA919 commented on Sep 14, 2026

    @LIHUA919
    LIHUA919
    on Sep 14, 2026
    Contributor

    @huangruiteng Ownership map for the approved M3 delivery-verification slice, based on origin/main@ced85a63b2e390fbbe75c5e8da6b707307b01546.

    Existing owners and readers

    • Result / return writer: loopx/capabilities/manager_context/roundtrip.py. report() owns the immutable audience-ready result; drain() is the sole writer of its delivery state; reply_status() is the provider-neutral read model.
    • Lark provider adapter: loopx/extensions/lark/manager_returns.py revalidates live route and audience authority; loopx/extensions/lark/inbox_reply.py owns the external send and provider readback. It currently has the provider message id during the failed verification attempt, but does not return a durable locator.
    • Readers: manager_context/tracking.py::query() and manager-inbox status consume reply_status(); the Chat transcript consumes the stable manager_followup id; Lark consumes the adapter result. The existing frontend reads the same persisted Chat/manager projections and should receive only public-safe status/error fields.

    Proposed change and placement

    • Capability id: keep manager-context; no new built-in capability. Provider: existing Lark extension. This is the nearest existing owner because the shipped caller outcome is “return the delegated result to its original audience,” while Lark-specific locators and readback commands remain adapter-private.
    • Add a small provider-neutral persisted attempt/verification contract beside the existing reply delivery state in roundtrip.py; keep one delivery writer in drain(). Private locator payloads are accepted only from the provider adapter, validated/bounded, and never projected by reply_status().
    • Extend inbox_reply.py to return the minimum Lark locator when a send occurred and readback was inconclusive, plus a read-only “verify this exact prior reply” path that performs no send. Compose that verifier in manager_returns.py after the same live route/authority checks.
    • State transitions remain queued/retry_pending -> verification_required -> delivered | explicit_unverified. A recoverable known locator is rechecked after restart; missing legacy locator, conflict, revocation, missing message, content/audience mismatch, or insufficient evidence stays explicit and never resends.

    Expected changed files

    • Runtime: loopx/capabilities/manager_context/roundtrip.py, loopx/extensions/lark/manager_returns.py, loopx/extensions/lark/inbox_reply.py.
    • Shared readback/docs: loopx/capabilities/manager_context/README.md; tracking.py/CLI only if the current projection cannot carry the truthful public-safe state without change.
    • Frontend: existing personal-workspace Chat/readback components and i18n only if the live schema needs a new display mapping; reuse existing primitives and packaged assets.
    • Validation: tests/test_manager_context_roundtrip.py, tests/extensions/test_lark_manager_returns.py, focused Lark reply tests, manager-inbox projection tests, and packaged frontend contract/browser smoke.

    Compatibility and non-goals

    • Existing delivered, retry_pending, superseded, and legacy verification_required records remain readable. Legacy records without a trustworthy locator become explicit unverified and are not rewritten into guessed proof.
    • Preserve zero duplicate external effects, the immutable result identity, current return route/audience checks, and independent transcript idempotency. No model/worker rerun.
    • No M2 WorkRequest/Assessment transaction, Todo/lease/Goal authority, session takeover, unknown-locator recovery, new outbox/task database, provider promotion, or private canary in this PR.

    I will implement this on codex/m3-delivery-verification, bind the PR to A8/A9/A10 tests, and post the exact head here for review.

  5. huangruiteng commented on Sep 14, 2026

    @huangruiteng
    huangruiteng
    on Sep 14, 2026 via email
    CollaboratorAuthor

  6. LIHUA919 commented on Sep 14, 2026

    @LIHUA919
    LIHUA919
    on Sep 14, 2026
    Contributor

    Implemented the approved M3 delivery-verification slice in #4372: #4372

    • Base: 6c1a4d2cc37280a1d652b4bf67afd9c7d69ce19e
    • Exact head: a883609c13826143e1d159c5a11f810171f14c49
    • Runtime: provider-neutral persisted attempt facts, Lark locator capture before readback, read-only reconciliation after restart, fail-closed legacy/conflict/revocation/missing-message handling, and zero resend/model rerun.
    • Shared state: Manager CLI/readback and Chat expose the same public-safe delivery statuses; provider locator remains private.
    • UI: packaged Personal Workspace updates one returned message from “verification required” to “verified after recovery” on desktop/mobile.
    • Validation: 326 relevant Python tests; Dashboard build; packaged navigation-sorting, chat-recovery, typed-actions; Ruff/diff; maintainability ratchet; premerge canary 18/18, no manual holds.

    The PR records the two unchanged base failures separately and leaves the private Lark canary with you as agreed. M2/session takeover/provider promotion remain out of scope. Requesting exact-head review and the owner-side private canary when ready; I will address actionable findings on the same branch.

  7. LIHUA919 commented on Sep 14, 2026

    @LIHUA919
    LIHUA919
    on Sep 14, 2026
    Contributor

    Follow-up to the TS-refactor suggestion: #4372 now includes a bounded typed collaboration contract with a real Python caller.

    • New exact head: 544915263e43d248ca50db9a77b1067b838ec68f
    • control_plane/collaboration/return_delivery.ts now owns exact provider-neutral attempt validation and verification classification.
    • Python retains result/delivery persistence, locking and retry orchestration; Lark retains provider locator interpretation/readback. No second writer or M2 framework was introduced.
    • The PR body now includes TS migration economics and removal gates.
    • New TS contract + runtime handler tests: 12/12; typecheck passed; final premerge canary 18/18; 326 Chat/manager/Lark tests passed.

    The owner-side private Lark canary and exact-head review remain the next acceptance steps.

  8. LIHUA919 commented on Sep 14, 2026

    @LIHUA919
    LIHUA919
    on Sep 14, 2026
    Contributor

    Latest exact head after CI installation repair: f15b6eb4b77da7ee287839a115c0e5313e5e00fe.

    The first head exposed a real wheel packaging gap for the new TS collaboration subpackage. The fix adds the package-data boundary; an isolated wheel build/install successfully invoked both new runtime methods. On the new CI run, Release Artifacts and stage2c (installed 0) now pass. Remaining jobs are still running; the LoopX github-pr-4372 monitor will handle CI/review/private-canary changes and repair actionable findings on the same branch.

    Repair receipt: #4372 (comment)

  9. LIHUA919 commented on Sep 15, 2026

    @LIHUA919
    LIHUA919
    on Sep 15, 2026
    Contributor

    M3 delivery-verification slice update: #4372 now merges current main and rebuilds the packaged chat assets on the merged sources.

    • New exact head: be8c25a6f58048fdabb837d6dcaef689d231357c
    • Root cause of the red frontstage-pages build was the stale PR base (main refreshed dashboard sources and packaged assets after 6c1a4d2c); CI's pull_request build compiles the merge, so neither side's committed assets matched. Merging main and rebuilding resolves it; the new generation reproduces the exact CI clean-build bytes.
    • Repair receipt with full validation: feat(manager): reconcile uncertain delegated result delivery #4372 (comment)
    • Note: test-shard (3) red is a date-parameterized test_delivery_response case that reproduces identically on exact origin/main@a1c2516f4; it predates this slice.

    The reviewed projection-completeness fix is unchanged. Re-review and the owner-side private Lark canary remain the next acceptance steps.

  10. LIHUA919 commented on Sep 16, 2026

    @LIHUA919
    LIHUA919
    on Sep 16, 2026
    Contributor

    @huangruiteng 想申请承接 #4311 在 #4330 下的一个 bounded M2 vertical slice。先贴 ownership / compatibility / acceptance map，确认没有和现有工程 Todo 重叠后再开实现 PR。

    当前证据

    建议负责的范围

    1. 一个真实的 M2 request transaction

      • 在 TypeScript Core collaboration boundary 定义并执行一个版本化 request/context/dispatch/assessment/observation transaction；同一 event replay 返回原 receipt，identity 相同而 payload 不同则 conflict。
      • Python manager_context 只保留现有 runtime/channel I/O 与兼容读取，不再拥有新的通用状态转换；不新建 task database、daemon 或 provider。

    2. fix(scheduler): dispatch executor-excluded handoffs instead of repolling origin monitor #4311 作为第一个真实 adapter/caller

      • material monitor 产生 executor-excluded independent_handoff successor 时，创建一个 delegated_work request/dispatch obligation。
      • 通过现有 peer directory 选择一个不同的已注册 eligible peer；无 eligible peer 时投影 typed blocker，不创建 user gate。
      • receiver assessment 与 Todo claim/adopt 分开；真正 ownership 变化仍调用现有 claim/continuation owner并回读 canonical Todo。

    3. 兼容与第二消费者边界

    验收与验证

    • 绑定 RFC A4–A7 中与本 slice 相关的子集：缺 convenience profile 仍能发现正确 receiver；correction/rejected approach 不丢；manager→worker 与 worker→worker 使用同一 contract；duplicate ingress、late receipt、concurrent claim、crash-after-effect 不产生重复 effect。
    • 保留 fix(scheduler): dispatch executor-excluded handoffs instead of repolling origin monitor #4311 的 focused cases：dispatchable_by_peer / executor-excluded visibility、typed no_eligible_peer、restart、stale claim、canonical claim readback、duplicate dispatch/read/claim、effect-after-crash reconciliation。
    • 先做 base/head differential characterization，再跑 TypeScript contract/effect-runtime tests、Python adapter/CLI quota and Turn tests、process-restart fixture、git diff --check、public-boundary scan 与 risk-based premerge canary。

    非目标

    请确认这个 first M2 transaction + #4311 adapter slice 是否可以由我负责；若已有 canonical Todo、正在实施的 owner，或希望先进一步缩小 transaction boundary，请指向对应公开项。我会在确认后从最新 origin/main 建独立 codex/ worktree，并在实现前贴最终 file/owner map。

    English summary: Requesting ownership of a bounded first M2 transaction with #4311 as the first real adapter. The slice moves new generic request/assessment transitions into the typed Core collaboration boundary, keeps Python as runtime/channel compatibility I/O, preserves existing Todo/lease/Goal authority, migrates #4312 semantics only as legacy compatibility, and qualifies manager-to-worker plus the #4094 worker-to-worker adapter without claiming full cross-Goal or effectful takeover support. No open PR currently overlaps the actual owner files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    direction/architecture-evolutionArchitecture evolution and research-incubator work.direction/operator-surface-imOperator surfaces, frontend control plane, and bounded IM integration.enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions