standing: a firing's tasks board is always empty — wrong task index path + armed-firing scoping hide project tasks
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with internal/session/task_index.go:404, internal/session/standing_run.go:940-941, internal/session/tools_tasks.go:935, and internal/session/taskdelta.go:721. Reproduce a standing item that calls tasks, checking unarmed and armed firings plus id and scope=everywhere queries. Done means standing firings can see project tasks and eligible tasks in other windows through the promised task-tool paths.
由索引模型根据 Issue 内容生成。
描述
A standing-run firing that calls the tasks tool always sees an empty board, regardless of whether project tasks exist. Two independent root causes, both in internal/session, produce this: the task index file resolves to a wrong path for standing runs (cause A, bites unarmed firings), and an armed firing's task scoping hides project tasks behind graph-child-only lookups (cause B, bites the observed firing).
Reproduction
Create a standing item whose body calls tasks (with or without an id or scope argument) every 20 minutes. For example, a kind=task item monitoring three delegated tasks (ids 4, 5, 6) in the conversation that created the item. When the firing runs, every variant returns empty:
- No-query listing: "No tasks have run in this project yet."
scope=everywhere: equally empty.- Id lookups: No task "4" among the pieces you handed out.
...while those tasks are live and visible in the conversation that created the standing item.
Root causes
A -- Wrong task index path (task_index.go:404)
taskIndexFile() at internal/session/task_index.go:404 (filepath.Dir at :406) derives the index bucket as filepath.Dir(Place.Dir). For a normal conversation, Place.Dir is a session folder under ~/.codeaf/v3/projects/<workspace-hash>/, so one Dir() hop resolves to the correct project bucket. For a standing firing, Place.Dir is ~/.codeaf/v3/standing/<item-id>/runs/0001 (set at standing_run.go:773,778), so one hop lands in runs/ and ReadTaskIndex opens a tasks.jsonl that never exists there.
Cause A bites any standing firing whose taskRows() reaches TaskIndex() -- that is, when taskID == 0. For the observed armed firing (taskID != 0), cause B below was the active mechanism.
B -- Armed-firing scoping hides project tasks (standing_run.go:941, tools_tasks.go:935, taskdelta.go:721)
standingWideWork at internal/session/standing_run.go:940-941 arms the firing by setting cfg.taskID (and cfg.tasker) when the item divides (swarm on, brief passes the width gate at :884). With taskID != 0, taskRows() at internal/session/tools_tasks.go:935 returns only the root node's graph children -- which for a standing firing that has not divided is an empty slice -- and never calls TaskIndex() at all. Separately, tellsElsewhere() at internal/session/taskdelta.go:721 returns false when InTask || taskID != 0 (:722), preventing the scope=everywhere path from reaching taskElsewhereText (tools_tasks.go:256, gated at :260/268). Together these mean an armed firing cannot see conversation tasks by id, by query, or by any scope.
Why this is a bug, not intentional scoping
task_index.go:40-56 header comment states the scope is the project, not the conversation. The tasks tool contract (tasksDescription at internal/session/tools_tasks.go:72) promises that other windows' live work appears as anonymous "another window" rows. Both promises are broken for standing firings: project tasks are invisible, and live tasks in other windows never appear.
Suggested fix directions
Three changes needed:
-
Fix the index path (cause A). Derive the project bucket for standing runs directly instead of
filepath.Dir(Place.Dir)-- for example, walkPlace.Dirupward until thetasks.jsonlor the project bucket marker is found. -
Do not arm with an unmatchable taskID (cause B). Leave
cfg.taskIDat 0 for standing firings sotaskRows()falls through toTaskIndex(). This alone does not work without fix 1. -
Let
tellsElsewhere()return true for standing runs (or add a standing-specific path) so thatscope=everywhereworks.
Fix 1 alone does not cure cause B (an armed firing never reaches the index). Fix 2 alone (using fix 1's corrected index) is the full cure for both unarmed and armed firings but depends on fix 1. Fix 3 is independent of 1 and 2 and covers the elsewhere gate.
Workaround
Replace the kind=task standing item with a kind=probe item whose shell command greps the project's real tasks.jsonl directly at ~/.codeaf/v3/projects/<workspace-hash>/tasks.jsonl.
—
Drafted with CodeAF · reviewed and owned by the author
- 主要语言
- Go
- 星标
- 115
- 派生
- 14
- 平均合并
- 9 小时 44 分钟
- 30 天内合并 PR
- 766
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Agent-Field/CodeAF 的其他 Issue
-
area:chat bug sev:papercut
难度 2/5 1-3 小时 新手友好度 86/100
Agent-Field/CodeAF#1592 ·
维护者通常 1 天内回复
-
area:headless bug sev:critical
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1566 · 已指派 1 人 ·
维护者通常 1 天内回复
-
area:chat feature
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1510 ·
维护者通常 1 天内回复
-
area:tests bug
难度 2/5 1-3 小时 新手友好度 82/100
Agent-Field/CodeAF#1489 ·
维护者通常 1 天内回复
-
area:chat bug good first issue sev:papercut
难度 2/5 1-3 小时 新手友好度 78/100
Agent-Field/CodeAF#1470 ·
维护者通常 1 天内回复
查看 Agent-Field/CodeAF 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
gruntwork-io/boilerplate#329 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
prime-radiant-inc/evener#3291 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
Netcracker/qubership-apihub-backend#582 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复