surface-completeness

Surface completeness

Use this workflow during user-facing implementation, after each cosmetic change, and before declaring the affected work complete. An explicit session closeout can also cover new services and their user documentation without a UI change. Scope follows the requested change. It does not authorize unrelated redesign, releases, provider changes, or new external communication.

Preserve the accepted result

Record the accepted baseline, intended improvement, affected surfaces, and recent work that must survive in your task list or plan tool. Distinguish current source, open pull requests, approved references, and deployed screens. For overlapping pull requests, compare their incremental intent and shared history before reconciling files. Do not replace a whole file from one branch when that discards unrelated work.

A direction such as "use bolder colors" changes presentation within the established action hierarchy. It does not promote Cancel, make a safe secondary action look like success, or erase the distinction between ordinary and destructive actions. Preserve the project's accepted palette and interaction model. Use authoritative standards guidance when deciding hierarchy, action emphasis, color meaning, contrast, focus, motion, or target behavior. Separate normative accessibility requirements from design-system recommendations.

Change the shared owner

Find the existing semantic token, shared component, or style rule that owns the element. Change its parameters once and inspect all affected consumers. Avoid repeating a common style in individual components or adding a parallel system. Trace aliases, variants, generated outputs, and local overrides. A local exception needs a concrete behavior or context difference and documented scope.

When the new design changes the accepted rule, update its owning contract, tokens, and existing enforcement in the same work. Otherwise, cite the existing rule that already covers it. Do not update screenshots only to make a failure disappear. Use checks proportional to the change. Do not create persistent exact-text or CSS assertions that only mirror the implementation.