Design Standards and the Design Mirror

systems/design-standards.md · System · design, quality, self-diagnostic

unverified: no trust signals recorded yet

One shared rule-set the generator, renderer, and admin self-diagnostic all consult — plus the mirror that scans and heals the fleet.

Design Standards and the Design Mirror

The single source of truth for "what a tasteful Doozer site looks like" is includes/design-standards.php. It exists so the design layers stop patching the same flaw in isolation. Three layers consult it:

1. Generation — the AI content prompt (includes/ai-content.php) injects

designStandardsPromptRules() so new content is born compliant (never bold a whole paragraph; only short phrases; no em dashes; 2 to 3 paragraphs).

2. Render — includes/prose-render.php delegates to designStandardsTameInline()

and designStandardsStripEmDash() as a safety net for non-compliant model output.

3. Diagnose — the Design Mirror scans the fleet and heals it.

Rules

designStandardsRules() is an extensible registry. v1 rules: over_emphasis, em_dash, wall_of_text, empty_content. Adding a rule is one array entry.

The Mirror

includes/admin-design-mirror.php (Admin → Design Mirror) scans live sites against the registry, shows per-rule counts and percent-of-fleet with sample offenders, and offers one-click remediation: Heal (reheal rules: re-saves cleaned content in place, zero API cost) and Queue regeneration (regen rules: enqueues content jobs). It never auto-acts; the operator controls spend.

The rule

New design-shape problems get a registry rule, NOT a one-off override. That is the anti-bandaid principle that motivated this system. See the content generation and heal process and the no dark patterns ethos.

The regeneration readability gate

The unified regeneration engine (includes/regeneration.php) uses this registry as its safety net: after generating new content it scans, heals once, and rolls back to the prior content if the result is still broken, so a regeneration can never leave a live site worse. What counts as "broken" is derived from the registry, not hardcoded: designStandardsBlockingRuleIds() returns the rules a heal cannot fix (fixable = 'regen', currently empty_content and wall_of_text). Cosmetic rules (fixable = 'reheal', e.g. over-bold prose and em-dashes) are auto-healed and NEVER block. This encodes the operator principle: reject broken or unreadable output, never reject a site for being bold or expressive. Any future regen-fixable rule joins the gate automatically.

(History worth keeping: this gate shipped dead in v2.2.205 and was a silent no-op until v2.2.211 — it scanned for a severity vocabulary and scan shape the registry never produced. The lesson, again: verify the wiring actually fires, do not assume it does.)

Scope: content shape, not visual CSS

This system governs the SHAPE of generated CONTENT (prose emphasis, em dashes, wall of text, emptiness). Visual CSS safety, such as AA contrast and guaranteeing an outline button is actually visible, is a separate concern handled at render time by the Muse System's composition layers (muse-contrast.php plus the button-visibility safety in muse-apply.php). If a control is invisible or low-contrast on live sites, look there, not in this registry.