standing: a firing's tasks board is always empty — wrong task index path + armed-firing scoping hide project tasks
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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分
- マージ済み PR（30日）
- 775
環境構築
このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Agent-Field/CodeAF のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
Agent-Field/CodeAF#1679 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
Agent-Field/CodeAF#1678 ·
メンテナーはふだん 1 日以内に返信
-
area:chat bug sev:papercut
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
Agent-Field/CodeAF#1592 ·
メンテナーはふだん 1 日以内に返信
-
codeaf do "" runs a paid job with an empty brief対応中かも @santoshkumarradha が 2 日前に担当しました。 オープン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 日以内に返信
Agent-Field/CodeAF の issue をすべて見る
似ている issue
-
area: global bug dx priority: low
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
grafana/mcp-grafana#1267 ·
メンテナーはふだん 1 日以内に返信
-
automation models
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
coverage-gap good-first-pattern help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
GoogleCloudPlatform/k8s-aibom#114 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
txn2/mcp-data-platform#1984 ·
メンテナーはふだん 1 日以内に返信