#67 .fleet-task* files must not be committed to member repos

[Anonymous]

Originally created by: kumaakh

Problem

.fleet-task* files (created by the fleet during long-running task execution) are being committed to member git repositories. This causes proliferation — every sprint leaves behind stale task files in the repo history.

Impact

• Repos accumulate .fleet-task* files quickly across multiple sprints
• Committed files leak internal fleet implementation details into project repos
• git log and diffs get polluted with irrelevant task file churn

Expected Behavior

1. .fleet-task* should be added to .gitignore on the member's working repo automatically (at sprint start or via task harness setup)
2. /pm cleanup must aggressively remove these files: run git rm --cached .fleet-task* 2>/dev/null; rm -f .fleet-task* on both doer and reviewer before merge, and commit the removal
3. If .gitignore already exists, append .fleet-task* — never overwrite

Suggested Fix

• In task harness setup (send_files): append .fleet-task* to .gitignore if not already present
• In pm cleanup template: add explicit step to untrack and delete .fleet-task* files before the cleanup commit
• Consider: fleet server should suppress staging of these files if it ever auto-commits

[Anonymous]

Originally posted by: kumaakh

Related: Pipe vs File for Prompt Delivery

This issue surfaces a deeper question worth brainstorming: should prompts be delivered via pipe/stdin rather than written to .fleet-task* files on disk?

Current approach (files)

• Prompt is written to a .fleet-task* file on the member machine, then passed to the CLI
• Pros: Survives session disconnect; CLI can re-read on retry; easy to inspect/debug
• Cons: Files accumulate in the repo; risk of accidental commit (this issue); requires cleanup discipline; leaks prompt content to disk

Alternative: pipe / stdin

• Prompt is piped directly to the CLI's stdin (e.g. echo "$PROMPT" | claude -p or claude -p - < <(echo "$PROMPT"))
• Pros: Nothing written to disk; no cleanup needed; no gitignore risk; cleaner member repos
• Cons: Prompt lost on disconnect — no retry without re-dispatch from PM; harder to debug (can't inspect what was sent); shell escaping of large prompts over SSH is tricky; some CLIs may not support stdin prompts reliably

Worth deciding

• Is crash-resume via task file worth the cleanup overhead?
• Could we use a tmpfile outside the work_folder (e.g. /tmp/) to get the best of both worlds — survives retry but never in the repo?

[Anonymous]

Ticket changed by: kumaakh

• status: open --> closed

[Anonymous]

Ticket changed by: kumaakh

• status: closed --> open

[Anonymous]

Originally posted by: kumaakh

this needs a reconsideration... I see all the prompts are being committed constantly.. if we use a single file name it will be better as they will not proleferate

[Anonymous]

Ticket changed by: joiskash

• status: open --> closed