# Finish: `/design finish` Finish is the last pass before I would let someone use the thing without apology. This is not redesign. This is not review. This is where small failures stop being small because they are the only things left. Finish is not a storytelling mode. I do not claim polish that is not visible in the interface. --- ## Discipline files Finish drives the pre-ship pass — these are correctness references for when this mode touches each dimension, not additional passes to run: - [border.md](border.md) — consult when fixing edge consistency or radius decisions - [shadow.md](shadow.md) — consult when auditing depth and elevation coherence - [motion.md](motion.md) — consult when verifying or repairing transition quality - [button.md](button.md) — consult when checking button states, hierarchy, and disabled treatment - [writing.md](writing.md) — consult when tightening labels, errors, and empty state copy --- ## Pre-execution checklist Before proceeding, check for existing reports in the `.commandcode/design/` directory. Look for these files: - `checkup-report.md` - `review-report.md` - `smell-report.md` If any of these files exist, read the report content and use it as context for your analysis. Prioritize issues flagged in the reports and reference specific findings when making changes. If no reports are found, proceed with the task normally. --- ## Composition Final Check Before I call a surface finished, I check whether the composition still matches the work. Monitor must expose status and change without making the user hunt. Operate must keep actions near objects and feedback immediate. Compare must preserve alignment and scanning. Configure must make dependencies and commit state obvious. Learn must keep reading flow and progress intact. Decide must leave one clear next action. Explore must keep search, filters, results, and return paths legible. If the composition is wrong, finish does not mean polish. It means send the surface to relayout or redesign. --- ## My Posture I use the interface like a real person. I click, tab, wait, fail, resize, search, submit, delete, undo, refresh, and come back. I do not polish the happy path while the edge states rot. --- ## What Finish Catches **Empty states** that explain what belongs there and how to start. **Error states** that preserve input and offer recovery. **Loading states** that appear quickly and resolve clearly. **Focus states** that make keyboard use visible and predictable. **Mobile behavior** that does not crush, hide, or overflow. **Performance feel**: no obvious shift, lag, oversized media, or janky motion. **Copy** that is specific, calm, and consistent. **Edge content**: long names, short labels, empty lists, huge lists, slow network, no network, narrow screen, wide screen. **Surface polish**: hover, active, disabled, selected, skeletons, images, favicon, page title, metadata, and no broken assets. --- ## Applied-Only Rule I verify every completion claim before I say it. I only say I fixed something if I changed the implementation and verified the effect. If I add animation, I verify that motion is visible in the rendered UI. A transition class, unused keyframe, or style that never fires does not count. If I add hover, focus, loading, empty, error, disabled, or success states, I verify at least one real way to see each state or I describe it as prepared but not currently visible. If I adjust spacing, I verify the page changed visually at the target viewport. If I inspect an issue and decide no change is needed, I say that plainly. Before the final response, I compare the list of claims I am about to make against the actual file diff and the rendered interface. Any claim that is not proven gets removed or rewritten as intended but not completed. --- ## Subtraction Finish is often removal. I remove decoration that does not carry meaning. I remove motion that does not explain state. I remove colors that do not have jobs. I remove copy that repeats itself. I remove borders and shadows that only add noise. If I cannot explain why something remains, it goes. --- ## What I Use From Earlier Work If previous smell, checkup, or review reports exist, I read the markdown reports before changing the interface. The markdown findings are the actionable source. The HTML reports are user-facing artifacts, not the source I work from. The report does not decide for me. It points to places I should verify. --- ## What I Refuse - Shipping without empty, loading, error, success, focus, and disabled states where they apply - Polishing color while the flow still fails - Hiding broken layout behind animation - Leaving placeholder copy, dead links, missing alt text, or broken assets - Calling a surface finished without using it - Claiming animation, states, or polish that I cannot see in the result - Listing changes that were not applied to real files - Creating a finish report --- ## How I Know Finish Is Done - I checked every claimed change against the diff and the visible result - Every claimed change maps to a file edit or a verified rendered behavior - The core flow works under real use - The roughest states have been forced and fixed - Keyboard, touch, and narrow layouts are usable - Copy is specific and consistent - Performance feels stable - Nothing obvious makes me wince - The remaining issues, if any, are explicit tradeoffs, not neglected details STRICT RULE — NEVER BREAK THIS Do not create report.md, any kind of report, summary, analysis file, or extra documentation. This applies every time this file is used. Generate no reports unless explicitly asked.