Hard Rules & Reusable Patterns
The standing rules every session inherits, pulled from the memory system so they survive past any one conversation.
Every Claude session for Design Hacker reads from a persistent memory system before it starts working. Most of those ~200 files are session-by-session project pings (superseded the moment the next session ships something newer) and stay out of this hub on purpose, same reasoning as the handoffs/ archive. This page pulls out the part that doesn’t expire: the hard rules and reusable patterns that apply to every future session, regardless of which project it’s touching.
Naming — non-negotiable
Kelli Connor
bex+Co.
Brand Builder Bot
BBE language
Infrastructure — standing defaults
Cloudflare only, never Netlify
Read CURRENT.md before citing a BBB version
CURRENT.md is the one source of truth for what’s actually live.Populate the exact page Andrew gives you
Archive, never delete
Voice & copy
- Brain Candy Voice is the default teaching voice for workshops, videos, and educational content — the fallback whenever a piece doesn’t specify a different register.
- Luxury voice never attacks — competitive or comparison copy stays confident, never disparaging.
- No timing claims — never promise how fast a result will show up; DH’s copy discipline bans specific-timeframe promises.
- Honest vs. hype framing — claims get the honest register even when the hype register would convert better short-term.
- Bio writing, ad-copy-bank formatting, and Bridge Page copy each have their own documented micro-rules — check the specific SOP before freehanding those formats.
Working with Andrew
- Plain English, collapsed/skim layouts. Andrew’s internal tools should read like a briefing, not a spec doc — same posture as the operating manual on the Start Here page.
- Cascade over spot-fixes. When a bug or inconsistency shows up in one place, check whether it’s systemic before patching the one instance.
- Auto-log always. Work that changes something durable gets logged as it happens, not reconstructed afterward from memory.
- Reference projects first. Before assuming a fact about DH’s systems, check the project’s own docs — don’t reason from general knowledge about how a similar system “usually” works.
- Supersede old entries explicitly. When a new ruling replaces an old one, say so in the new doc rather than leaving two contradictory answers findable.
Technical scars worth knowing by name
Brand pack round trip + slot invariant
Brand packs must survive a full export/import round trip without drift, and every pack slot is a hard invariant — dropping or renaming a slot breaks every brand already loaded against it.
Notion views: no wrapped text, rich detail in the page body
Notion database views should never carry long wrapped text in a property column. Anything detailed belongs in the page body, not the view.
Chrome / CSS rendering quirks
A cluster of narrow, hard-won fixes: OKLCH computed-style quirks in Chrome, surface-alignment issues, chroma-floor clamping killing neutral tones, and a file-protocol issue where a second script tag silently drops in local HTML previews. Each has its own detailed memory file if a rendering bug looks familiar.
Client-prep pages need a self-updating date label
Any client-facing prep page with a “last updated” style label should compute it relative to today, not hardcode a date that goes stale the moment the page ships.
Where the rest of this lives
The full memory system is the working log this page was distilled from — every shipped feature, every version bump, every project ruling, timestamped. It’s deliberately NOT mirrored into the hub wholesale, for the same reason handoffs/ stays out of the front-line reference on the Decisions & History page: session-by-session detail is valuable as an archive, but it drowns the current truth if it sits next to it. Rulings that graduate to genuinely standing doctrine (like the ones above, or like the BBE deal structure) get pulled forward into the hub by hand.