simon-web-blueprint-guard

name: simon-web-blueprint-guard description: Preserve the dark technical blueprint/editorial visual identity of the simon-web React/Vite portfolio. Use only in /Users/coffeedev/Projects/simon-web when a task changes visible frontend design, layout, routes, CSS, animation, typography, navigation, hero, publication cards, article/register pages, responsive behavior, or UI copy tone. Do not use for data-only edits, source-register cleanup, build config, dependency work, or non-visual content analysis.

Simon Web Blueprint Guard

Overview

Protect the existing Gemini-made blueprint design while allowing narrow frontend changes. Treat this skill as a design-preservation guard, not a redesign engine.

This app's target is a dark technical/editorial blueprint portfolio: not SaaS, not startup, not a generic personal site. When uncertain, preserve the current visual system and ask before changing the design direction.

Required Context

Before editing visible UI, inspect the current implementation:

• src/index.css
• src/App.tsx
• src/components/BlueprintBackground.tsx
• src/components/BlueprintBackground.css
• The route component being changed: src/pages/Home.tsx, src/pages/Publications.tsx, src/pages/Article.tsx, or src/pages/Register.tsx

Then load the references needed for the task:

• Read references/design-dna.md for any new UI, layout, visual polish, route, or section.
• Read references/no-go-and-acceptance.md before any implementation that could alter the visual feel.

Workflow

1. Classify the task as preserve, extend, repair, or redesign-risk.
   • preserve: copy/content/layout adjustments that should keep the design essentially unchanged.
   • extend: adding a section, route, state, component, or content block inside the existing visual system.
   • repair: fixing responsive, accessibility, spacing, overlap, animation, or rendering defects.
   • redesign-risk: changing hero, palette, background, navigation, type scale, layout model, motion language, or visual assets.
2. Name the design invariants that must survive before making edits. Keep this concise in commentary.
3. Prefer the smallest local change that solves the request. Extend existing CSS variables, classes, layout patterns, and blueprint motifs before introducing a new visual language.
4. Keep visual source of truth in the repo. Do not import broad UI kits, icon packs, fonts, or animation libraries unless the user explicitly asks and approves dependency changes.
5. Verify after meaningful UI changes with the local dev server and browser screenshots or DOM checks. Test the changed route at desktop width and at least one mobile/narrow width.
6. In the final answer, state what changed, what visual invariants were preserved, and what verification ran.

Design Rules

• Preserve the blueprint background as a first-class identity element. It is not a generic SVG hero decoration.
• Preserve the palette: near-black base, cool light text, copper accent. Add new colors only when required and keep them subordinate.
• Preserve editorial scale: large serious hero typography, uppercase navigation, mono metadata/proof details.
• Preserve the evidence tone: field notes, original sources, publication register, concrete proof metrics.
• Prefer sharp technical edges, thin borders, grids, corner marks, measure lines, subdued motion, and asymmetry.
• Keep cards restrained and technical. Avoid soft rounded marketing cards as the dominant structure.
• Use Swedish UI/copy unless the existing surface is intentionally English.

No-Go Summary

Never introduce these without explicit user approval:

• Gradient orbs, bokeh blobs, decorative glows, glassmorphism, neon cyberpunk, or purple-blue AI-dashboard styling.
• Stock-image hero, split hero card, centered generic landing page, or hero text inside a card.
• A broad design-system rewrite, shadcn-style UI conversion, or component-library reskin.
• Replacing BlueprintBackground with a generic background.
• Renaming the information architecture into generic portfolio labels such as "Projects", "Case Studies", or "Insights" unless requested.
• Hiding mobile problems instead of solving layout, overlap, and readability.

Acceptance Checks

For visual edits, check:

• The first viewport still reads as dark blueprint/editorial, not generic portfolio or SaaS.
• Navigation, hero, copper accent, and proof/field-note framing remain recognizable.
• Text fits and does not overlap at desktop and mobile widths.
• Motion remains subtle and technical; it does not distract from reading.
• Build or lint passes when the edit touches TypeScript/CSS behavior.
• Browser verification covers the route that changed.

Example Use

User asks: "Add a LIA section to the start page."

Use this skill, classify as extend, read Home.tsx, index.css, BlueprintBackground.*, and references/design-dna.md, then add a section that uses the existing dark editorial blueprint language. Do not add a colorful card grid or generic landing-page block.

OpenAI Frontend Guidance

Use OpenAI's frontend guidance as an anti-generic filter, not as a replacement design direction. If general frontend guidance conflicts with this repo's explicit blueprint identity, preserve the repo identity and explain the tradeoff.