Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Task][RFC]: Complete Goal lifetime fencing and governed orphan recovery

Ouverte
  • Quelque chose ne va pas ?
#5,206 6 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python, typescript
Domaine
backend, distributed-systems

Piste de recherche

Read the linked RFC and current owners/PRs first; implementation and integration overlap active work, so identify an unowned acceptance gap in a claim comment before starting. The listed entry points are loopx/control_plane/goals/goal_instance_identity.ts, source_session_lifetime.ts, and loopx/control_plane/projects/registry_codec.py. Done means reconciling the accepted scope with the integrated revision and recording commands, passed/failed/untested evidence, and remaining gates; a merged PR alone is not completion.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

direction/architecture-evolution

Outcome / 目标

完成 Goal 生命周期隔离与孤儿状态恢复。One task tracks this RFC's delivery; keep implementation PRs and milestone evidence here instead of creating a parallel task tree.

Canonical design: RFC. Roadmap: S2/S3/S9 · R5, under #4574. Design acceptance is distinct from implementation, live qualification and promotion.

Current boundary

Integrated checkpoint: #5389, merge 3cecb0d7cbf3d247cfd996267d7fc64627bd6e49 (2026-10-02). The source-session lifetime transaction and individually qualified attached Chat, handoff and Turn-journal owners are already implemented; first-party host enforcement remains partial. Do not restart from the old codec-only checkpoint.

#5389 qualifies quota_settlement: exact GoalRef admission and ownership across spend/replay/receipt repair/void/readback, with legacy parity. Exact-head review: 231 Python and 279 TypeScript tests passed; 37 final-main integration tests passed; identical base/head public CLI and native artifact comparisons passed; risk-based premerge passed with 19 checks and no failures. These are isolated component/runtime results, not live product qualification.

execution_authority: false and the overall activation hold remain. Remaining inventory owners, old/warm-writer compatibility, external-effect drain, M4 recovery and packaged M5 acceptance are still open.

Product integration path / 产品联动路径

Canonical plan: RFC integration matrix · roadmap integration · golden-query lifecycle scenario.

  1. P0 / R1–R3 / G1: Goal 创建、Agent 创建或复用、2–3 worker 两轮依赖产物与 peer handoff、独立验收和同生命周期纠偏恢复。先在已支持 profile 验证；重连、换模型和新 Turn 不创建新的 Goal lifetime。
  2. P1 / S7 / R5: 实例归属接共享团队预算与 M4 孤儿恢复。共享额度分配仍由 quota/scheduler 验收，不能从实例隔离直接推导完成；恢复复用 preview/backup/apply/resume/readback。
  3. P2 / R6 / G3: 在真实跨主机认证、撤销与 lease 条件下验证迟到 worker，不把本地文件证据算作远端资格。

M5 的隔离重建场景必须等选定 profile 的 M2/M3 owner、旧 writer 与 drain 门槛满足后运行；涉及孤儿处置时包含 M4。检查 A 退役、B 同名重建、迟到 A 与重复回调不会污染 B，B 和无关 Goal 继续推进，结果回到原入口。App + 独立 CLI/source 回读先验，Lark 单独资格化。Component fixtures can precede activation but cannot certify the live journey. Use existing R1–R3/G1 owners under #4574; this issue owns the lifetime/recovery dependency, not a parallel team-orchestration ledger.

Work remaining

  • Finish the current binding-owner inventory and remaining admission/commit fences using the source registry’s exact GoalRef.
  • Complete preview/backup/journal/apply/resume/readback for supported orphan dispositions with explicit activation and compatibility boundaries.

Ownership and ongoing work

Reuse #4800/#4915 for paths and #3245 for authority promotion. Do not reimplement delivered source-session transactions or take over the active migration writers. Record remaining binding families, not an obsolete codec-only status.

Contribution route: implementation/integration overlaps active work. Start from the linked current owners/PRs and identify an unowned acceptance gap in a claim comment; do not begin a competing rewrite.

Acceptance

  • Delete/recreate of one alias cannot accept old session, inbox, host or execution authority; late A results cannot settle B.
  • Concurrent retirement, stale global projections, crash recovery and ambiguous commit preserve exact original identity and receipts.
  • Recovery never guesses a candidate or mutates active state as a test; isolated real-provider evidence and CLI/product readback cover the advertised path.
  • Reconcile the RFC's current delivery checkpoint and this issue with the integrated revision, commands, passed/failed/untested evidence and remaining gates. Close the accepted scope only; no claim that a merged PR alone completes the RFC.

Starting points and delivery boundary

Base: latest main. Reuse the existing typed owner and provider boundaries. Include affected CLI/frontend/Lark companions; verify real entrypoints and backend where changed. Preserve existing first-screen review and maintainer merge gates. Public artifacts contain only synthetic/public-safe evidence, no private operational state. This task does not authorize provider promotion, benchmark launches, release/deployment or unrelated protected effects.

Langage dominant
Python
Étoiles
6.2k
Forks
596
Merge moyen
7 h 35 min
PR mergées (30 j)
928

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de loopx-project/loopx

Toutes les issues de loopx-project/loopx

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.