Summary
A plan task with an empty files_touched list (a pure verification/read-only task that writes no files) can never be marked completed. update_task_status requires a pre_check gate, but pre_check_batch only writes that gate when it has files to scan — and with files_touched: [] there are no files, so the gate is never recorded. The task is stuck in in_progress forever.
Reproduction
- Create a plan with a task whose
files_touched is [] (e.g., a verification-only task).
- Run
pre_check_batch (with or without an explicit file list).
- Attempt
update_task_status(task_id, "completed").
Result:
Task 1.1 generation 0 has not passed exact-task QA. State: idle. Missing gates: [pre_check].
Root cause
update_task_status requires a pre_check gate in the per-task evidence file (.swarm/evidence/<taskId>.json).pre_check_batch scans files and writes its verdict to shared gate-level evidence directories (build/, quality_budget/, sast_scan/, secretscan/) — it never writes a pre_check entry into the per-task evidence file.- With
files_touched: [], there is nothing to scan, so no gate evidence is produced at all.
- Additionally,
check_gate_status reports a different required-gate set (e.g., only critic_sounding_board) than update_task_status enforces (pre_check), so the two tools disagree about what the task actually needs.
Why files_touched can legitimately be empty
A task may be a pure verification task: it exists to confirm that the existing toolchain (install, typecheck, lint, test baseline) runs cleanly against human-authored configuration files. Those config files are explicitly outside the coder's write authority (config-zone), and the task itself makes no code changes — so there are no files the coder is permitted to write. files_touched: [] is the correct, honest declaration for such a task, and it should not deadlock the completion gate.
Expected behavior
One of:
- A task with
files_touched: [] should be able to pass the pre_check gate without file scanning (e.g., pre_check_batch with no files still records a gate verdict), or
update_task_status should not require pre_check for tasks that declare no file scope, orcheck_gate_status and update_task_status should derive required gates from the same source so they never disagree.
Workaround (current)
Give the task a non-empty files_touched containing a real file (e.g., a minimal smoke test) so pre_check_batch has something to scan. This works but forces artificial file writes onto verification-only tasks.
Summary
A plan task with an empty
files_touchedlist (a pure verification/read-only task that writes no files) can never be markedcompleted.update_task_statusrequires apre_checkgate, butpre_check_batchonly writes that gate when it has files to scan — and withfiles_touched: []there are no files, so the gate is never recorded. The task is stuck inin_progressforever.Reproduction
files_touchedis[](e.g., a verification-only task).pre_check_batch(with or without an explicit file list).update_task_status(task_id, "completed").Result:
Root cause
update_task_statusrequires apre_checkgate in the per-task evidence file (.swarm/evidence/<taskId>.json).pre_check_batchscans files and writes its verdict to shared gate-level evidence directories (build/,quality_budget/,sast_scan/,secretscan/) — it never writes apre_checkentry into the per-task evidence file.files_touched: [], there is nothing to scan, so no gate evidence is produced at all.check_gate_statusreports a different required-gate set (e.g., onlycritic_sounding_board) thanupdate_task_statusenforces (pre_check), so the two tools disagree about what the task actually needs.Why
files_touchedcan legitimately be emptyA task may be a pure verification task: it exists to confirm that the existing toolchain (install, typecheck, lint, test baseline) runs cleanly against human-authored configuration files. Those config files are explicitly outside the coder's write authority (config-zone), and the task itself makes no code changes — so there are no files the coder is permitted to write.
files_touched: []is the correct, honest declaration for such a task, and it should not deadlock the completion gate.Expected behavior
One of:
files_touched: []should be able to pass thepre_checkgate without file scanning (e.g.,pre_check_batchwith no files still records a gate verdict), orupdate_task_statusshould not requirepre_checkfor tasks that declare no file scope, orcheck_gate_statusandupdate_task_statusshould derive required gates from the same source so they never disagree.Workaround (current)
Give the task a non-empty
files_touchedcontaining a real file (e.g., a minimal smoke test) sopre_check_batchhas something to scan. This works but forces artificial file writes onto verification-only tasks.