work-checklistlisted

# Work / 6. Checklist Convert concerns into accountable robustness work. Read [../QUALITY.md](../QUALITY.md) first and preserve its reliability, meaningful testing, simplicity, and clean-break rules. Use concerns already visible in the conversation, especially the latest `$work-concern` or `$work-audit` result. If none exist, inspect the smallest relevant implementation using the `$work-concern` standard before creating the checklist. Never invent concerns to make the list look complete. Do not spawn agents. The parent owns verification, edits, integration, and proof. If the scope genuinely requires orchestration, preserve the checklist and hand it unchanged to `$work` rather than silently changing workflows. ## 1. Build the checklist Recheck each concern against the current implementation and actual user flow. Merge duplicates, discard unsupported concerns with evidence, and order the survivors by likely user impact, data or security risk, and dependency order. For every item, define: ```markdown - [ ] C<number> — <concise concern> - Evidence: <exact path, symbol, behavior, test, or observation> - Why it matters: <realistic consequence> - Verify: <smallest decisive reproduction or check> - Done when: <observable robust behavior and validation evidence> ``` Allowed states are `pending`, `verified`, `resolving`, `resolved`, `disproved`, `blocked`, and `accepted risk`. `Accepted risk` requires explicit user approval and must remain visible in the final robustnes