Enforce UI Visual Restraint

Treat every gap, line, box, panel, and dark surface as a design decision that needs evidence. Prefer clear hierarchy and compact rhythm over decorative structure.

Load dependencies

1. Use context-first-design-execution when continuing an existing task or interpreting referential feedback.
2. Load the relevant surface Skill before editing, such as the installed Figma or frontend implementation Skill.
3. Use sync-responsive-figma-from-web only when Web-to-Pad/Mobile parity is also in scope. Report synchronization and visual restraint as separate checks.

Read visual-structure-ledger.md when several sections share the same spacing, divider, container, or dark-surface problem. Use it to trace each visible structure to a source or semantic purpose before batching a correction.

Lock the visual contract

Record:

• the authorized files, pages, frames, or components;
• the latest approved screenshot, design, implementation, or design-system source;
• the content and interactions that must remain unchanged;
• the specific symptoms named by the user;
• the visual evidence required for acceptance.

Inspect the complete root frame or rendered page before judging local colors or spacing. Transparent nodes, inherited fills, hidden constraints, and clipped parents can make an isolated layer misleading.

Require evidence for visible structure

Allow a divider, border, card outline, background panel, or dark region only when at least one condition holds:

• it exists in the approved visual source;
• it is an approved component state or design-system rule;
• it communicates a real semantic boundary, interaction state, selection, warning, or contrast requirement;
• the user explicitly requests it.

Remove or avoid:

• gray horizontal rules added to fill blank space;
• borders around content already grouped by alignment and spacing;
• repeated card shells that reduce information density;
• full-width lines carried over from an unrelated template;
• muted gray panels with no hierarchy or state role;
• black or inverse regions inferred from an isolated transparent layer;
• dark bands added for visual drama without source evidence.

Use alignment, typography, proximity, and whitespace before adding a visible separator. If a visible structure remains, record its source or semantic purpose.

Control spacing at three levels

Review spacing separately:

1. Inside an item — icon-to-label, heading-to-body, label-to-value, control padding.
2. Inside a module — row gap, card gap, column gap, text-to-media distance.
3. Between modules — section padding, transition gap, long-page rhythm, footer offset.

Apply these rules:

• Derive values from the approved source, local design tokens, or repeated neighboring patterns. Do not insert generic large gaps without evidence.
• Preserve a readable hierarchy of gaps: item gaps < module gaps < major section transitions.
• Widen text containers before accepting excessive wrapping, tall rows, or false empty space.
• Prefer content-driven height and Auto Layout over large fixed heights.
• Remove obsolete min-height, spacer layers, invisible placeholders, and nested fixed heights when they create inactive blank zones.
• Recalculate child, parent, root, and following-section positions after vertical edits.
• Keep density appropriate to the product. Compact does not mean cramped; every reduction must preserve readability, target size, and semantic grouping.

When a layout engine resists height reduction, inspect min/max constraints, fixed sizing, Auto Layout behavior, clipping, overflow, and ancestor height before changing visible styles.

Edit in a stable order

For each scoped module, modify in this order:

1. container width, columns, and outer padding;
2. text width, wrapping, and content-driven height;
3. internal gaps and row heights;
4. unjustified dividers, borders, cards, and background panels;
5. unjustified black or inverse surfaces after checking ancestor fills and themes;
6. typography, semantic colors, radii, icons, and media treatment;
7. module height, page height, overflow, and downstream positions.

Reuse approved components, variables, and styles. Preserve component linkage. Do not detach instances or change shared main components unless explicitly authorized.

Validate a specimen before batching

Choose one difficult representative module before applying a rule broadly. Prefer long text, metric lists, dense indexes, forms, or a section the user called out.

For the specimen:

1. capture the complete before state and its surrounding context;
2. inventory visible gaps, dividers, boxes, panels, and dark surfaces;
3. trace each retained structural element to a source or semantic reason;
4. apply the smallest rule set that resolves the stated problem;
5. capture the after state at the same viewport or frame scale;
6. check readability, information density, clipping, overflow, and overall rhythm;
7. correct the rule before batching it to sibling screens.

Do not batch from token inspection alone when the complaint concerns geometry, spacing, or invented decoration.

Run final QA

Check every scoped screen for:

• compact, consistent, content-driven vertical rhythm;
• text widths and wrapping appropriate to the viewport;
• no unexplained gray line, border, card shell, background panel, or dark region;
• every retained visible boundary tied to a source or semantic role;
• no clipping, overlap, unintended overflow, or large tail gap;
• readability, interaction target size, state clarity, and accessibility preserved;
• content, routes, media, and out-of-scope shared components unchanged.

Return Pass, Open, or Blocked for spacing, visible boundaries, surface colors, and full-screen rhythm. Do not merge these results into cross-device parity status.

Handoff

Return:

1. scope and approved visual source;
2. content and interactions kept unchanged;
3. rules applied for spacing, boundaries, containers, and surface colors;
4. before/after proof from the same context and scale;
5. full-screen QA status;
6. retained exceptions and their evidence;
7. explicit remaining issues.