name: checkpoint-system description: Standing checkpoint/QA discipline agreed with Andrew — three-part report format (Problem & Resolution, Risk Analysis, Code Change) per bug/change, tracked via SimpleDesk helpdesk mod already installed on his forum, with a "Claude" forum account Andrew will operate as proxy sources: [chat] aliases: [checkpoint discipline, SimpleDesk tracking, Problem Resolution Risk Code Change reports]
- [stated] Andrew has SimpleDesk (SMF helpdesk/ticket mod) already installed and in active use tracking bugs, with real tickets and attachments
- [stated] Decided to use SimpleDesk as the formal tracking system for checkpoints going forward, rather than building a new JSON store or a second SMF install; supports BBCode and attachments
- [stated] Standing checkpoint format per bug/change, agreed this session: 1. Problem & Resolution report, 2. Risk Analysis report, 3. Code Change report (with diff) — first full example built for the PDFsearch.py phrase-mode bug
- [stated] Andrew is creating a "Claude" member account on the forum so tickets can be assigned to it; he will act as proxy, logging in as that account himself and pasting in whatever a given session produces, since Claude has no persistent login/memory across sessions on its own
- [stated] Plan: future tickets assigned to the Claude account will be resolved by pasting the relevant checkpoint plus full session transcript into a fresh session, so it can rebuild context without relying on cross-session memory
- [stated] Underlying premise agreed: any code change carries a chance of causing an unforeseen issue; the goal of this discipline is not preventing that but making problems detectable and recoverable, distinguishing portability/environment bugs (caught by his existing Dev/Live 6-environment topology) from logic/contract bugs (identical across environments, needing standing regression tests instead)