chore: remove progress.txt session log, rely on git history

progress.txt was a hand-maintained narrative log appended on every
run_once.sh invocation, which also injected the entire file (9,148
lines, ~175K tokens) into every autonomous agent's prompt context and
instructed it to append more. That's an unbounded, ever-growing
context tax on every run, and an append-anywhere shared text file is
inherently conflict-prone across the tool's parallel per-issue
worktrees.

Commit messages and PR descriptions already carry the durable record
of what changed and why; the git log for this repo is the history.
Strips the file itself along with every reference: the run_once.sh
prompt injection/update instruction, the CLAUDE.md convention section,
ci.yaml's paths-ignore entries, REUSE.toml's license exemption, and
stale in-code pointers to specific progress.txt entries in
dc_bringup, dc_demos, dc_simulation, and tools/e2e.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y6cGXmDzcNi3P79JA3S7pM
Signed-off-by: David Bensoussan <d.bensoussan@proton.me>

Author: Minipada

.github/workflows/ci.yaml

@@ -49,15 +49,13 @@ on:
     paths-ignore:
       - doc/**
       - docs/**
-      - progress.txt
       - "**.md"
   push:
     branches:
       - jazzy
     paths-ignore:
       - doc/**
       - docs/**
-      - progress.txt
       - "**.md"
 
 concurrency:

CLAUDE.md

@@ -130,7 +130,7 @@ those are dropped):
 
 Keep them short. A file header is one to three lines; a block comment is one or two.
 Say *why*, and only when the code can't. No history lessons, no restating the diff, no
-paragraphs of rationale — that belongs in `progress.txt`, an ADR, or the PR description.
+paragraphs of rationale — that belongs in an ADR or the PR description.
 Some older files (`ci.yaml`, `doc.yaml`, `tools/e2e/Containerfile`) have long headers
 from before this rule; don't copy them, and trim them when you touch them.
 
@@ -139,10 +139,8 @@ from before this rule; don't copy them, and trim them when you touch them.
 - Issues ready for autonomous agent work carry the `ready-for-agent` label.
 - An issue can declare dependencies with a `## Blocked by` section listing `#N` issue numbers;
   agents must not start an issue while any listed blocker is still open.
-- `progress.txt` at repo root is the running log of completed work — read it and the target
-  GitHub issue before implementing, update it with what you did, and commit it alongside the
-  code change (it's tracked in git, not gitignored — the log is part of the durable state a
-  fresh agent session reconstructs context from).
+- Read the target GitHub issue before implementing; git log/PR history is the record of
+  completed work — there is no separate progress log to maintain.
 - One task per run/session. Commit, push the branch, and open a PR whose description includes
   `Closes #N`.
 - `run_once.sh` automates all of the above: it picks the oldest eligible issue, does the work in

REUSE.toml

@@ -24,7 +24,6 @@ path = [
   "dc_simulation/maps/**",
   "dc_simulation/models/**",
   "dc_simulation/env-hooks/dc_simulation.dsv.in",
-  "progress.txt",
   ".codespell.txt",
   ".python-version",
 ]

dc_bringup/launch/dc_bringup.launch.py

@@ -86,8 +86,8 @@ def build_bridge_and_mcap_actions(configured_params):
        run` spawns its target as a child of its own process and does not forward
        signals to it, so a `respawn`/shutdown-triggering `kill` on what `ros2 run`
        returns never reaches the actual writer (see `tools/e2e/scripts/entrypoint.sh`
-       and progress.txt's #210 follow-up entry for how this was found). `ExecuteProcess`
-       runs `python3 -m dc_mcap_writer.cli` directly instead.
+       for the same pattern). `ExecuteProcess` runs `python3 -m dc_mcap_writer.cli`
+       directly instead.
 
     When the block is absent or `enabled` is false or missing (every existing params
     file, unchanged), this returns exactly what the static `Node(...)` it replaces used

dc_demos/params/qrcodes_nav.yaml

@@ -115,8 +115,8 @@ controller_server:
     #
     # Hence 0.1 rad, not the 0.2 this carried. Yaw is the expensive term because
     # it scales with the standoff, and a diff-drive robot turning on the spot
-    # settles well inside 0.1 rad -- measured at no cost in navigation time (see
-    # progress.txt); xy stays at 0.1 m, which costs nothing.
+    # settles well inside 0.1 rad -- measured at no cost in navigation time;
+    # xy stays at 0.1 m, which costs nothing.
     #
     # Worth knowing that this budget is not the whole error: the goal checker
     # compares AMCL's *estimate* of the pose against the goal, so localization

dc_simulation/README.md

@@ -151,8 +151,8 @@ world-file cleanup.
 **That gain does not show up once Nav2 and DC are both running.** With the full demo
 pipeline up and the robot merely parked at its spawn pose — no navigation, camera
 measurements still polling once a second — RTF sits at ~0.11 whether or not the props
-are merged: the same figure progress.txt records for "the pass with DC running" against
-#279's DC-off 0.198. Nav2's planners/costmaps and DC's per-frame ZXing decode (two
+are merged: the same figure recorded for "the pass with DC running" against #279's
+DC-off 0.198. Nav2's planners/costmaps and DC's per-frame ZXing decode (two
 1280x720 streams, every poll) are together the larger cost once they're both in the
 loop, and they swamp what the world-entity count buys on this box. See
 [#52](https://github.com/Minipada/ros2_data_collection/issues/52) for the full

progress.txt

@@ -86,7 +86,6 @@ fi
 
 REPO_ROOT="$(git -C "$(dirname "$(realpath "$0")")" rev-parse --show-toplevel)"
 BASE_REF="origin/jazzy"
-PROGRESS_FILE="progress.txt"
 
 AGENT_COLORS=(blue cyan fuchsia green indigo lime magenta orange pink purple rose teal violet yellow)
 
@@ -384,13 +383,11 @@ else
 	fi
 fi
 
-PROMPT="@${PROGRESS_FILE}
-1. Read GitHub issue #${ISSUE_NUMBER} and the progress file.
+PROMPT="1. Read GitHub issue #${ISSUE_NUMBER}.
 2. Implement issue #${ISSUE_NUMBER}.
 3. Commit your changes.
-4. Update ${PROGRESS_FILE} with what you did.
-5. Push the branch and open a PR.
-6. The PR description must include 'Closes #${ISSUE_NUMBER}'.
+4. Push the branch and open a PR.
+5. The PR description must include 'Closes #${ISSUE_NUMBER}'.
 ONLY DO ONE TASK AT A TIME."
 
 COLOR_INDEX=$(printf '%s' "$ISSUE_NUMBER" | cksum | awk '{print $1}')

run_once.sh

@@ -53,8 +53,8 @@
 unfinished* file that `mcap_summary.py` cannot parse at all yet. A live snapshot taken
 mid-rotation therefore reports those Records as "never reached dc_mcap_writer" even
 though they are sitting safely on disk, about to become readable a few seconds later.
-Verified empirically against a real run (see #382's progress.txt entry): a level's check
-failed with a clean, well-formed "ZERO-LOSS VERIFICATION FAILED" (not a parse crash) that
+Verified empirically against a real run: a level's check failed with a clean,
+well-formed "ZERO-LOSS VERIFICATION FAILED" (not a parse crash) that
 the exact same check, re-run against the same still-live containers a bit later, no
 longer reproduced. So `verify_zero_loss_at_level()` retries *any* failure shape once,
 after a pause comfortably longer than that 15s rotation window