rseng-project-trackinglisted

# Task management and project records Research software projects fail operationally more often than technically: work lives in heads, decisions evaporate, and the grant's last month arrives with nobody able to say what remains. The remedy is cheap and boring - tracked tasks, a planning cadence tied to real deadlines, and records written where the code lives. rseng-management-planning owns the strategic layer (SMPs, technology choice); this skill owns the week-to-week operation, sized to the tier: a solo analysis repo needs a TODO issue and a decision log; an infrastructure project needs the full apparatus. ## Tasks: one tracked unit of work - Everything in the tracker, however small: the forge's issues are the natural home (docs and templates live with the code; rseng-community-governance's issue templates apply). An untracked task is a task that will be forgotten or duplicated. - Write tasks as outcomes with acceptance criteria ("CLI reads gzipped input; test added") rather than activities ("look into compression") - an outcome can be closed, an activity cannot. - Small enough to finish: split anything beyond a few days' work into steps; long-lived umbrella issues track the epic, linked to its pieces. - Link everything both ways: commits and PRs reference their issue (fixes #42), so the tracker and the history explain each other (rseng-version-control-review) - this linking IS the bookkeeping most projects miss. - Triage on a cadence, not on interrupt: