/* ══════════════════════════════════════════════════════════════════════════════════════════════
CandySweeps — theme.css CSTHEME_REV 2026.10.07-4
⚠ BUMP CSTHEME_REV ON EVERY EDIT, and BUMP THE ?v= ON EVERY PAGE THAT LINKS IT.
★★ THE ?v= IS NOT OPTIONAL AND IS NOT A TIDINESS THING. (7 Oct 2026)
The five pages that load this file ask for /assets/theme.css?v=N. Editing this file WITHOUT
moving N means the browser and the CDN keep serving the copy they already have, so a correct
upload produces no visible change — which then gets diagnosed for twenty minutes as a failed
upload, a broken selector, or a cache that "should" have cleared.
That is on record on WildSweeps: a replaced logo at an unchanged URL survived FOUR purges, all of
which reported success, because the layer holding it had a ten-year TTL. No purge fixes an asset
replaced in place. Only a new URL does.
→ Edited this file? Then ad-disclosure.php, contact-us.php, privacy-policy.php,
terms-conditions.php and thank-you.php ALL need the new ?v= in the same upload.
Currently: ?v=6
⚠ ?v=5 WAS SHIPPED WITHOUT MOVING THE NUMBER AND NOTHING CHANGED ON SCREEN. (7 Oct 2026)
I edited this file, had it uploaded, and told Chris the six linking pages "don't need
re-uploading" because ?v=5 was unchanged. That is the precise failure described six lines above,
committed by the person who wrote the warning, about three hours later. The upload was fine; the
browser and the CDN simply never asked for the new copy. Chris: "uploaded, not seeing any
difference" — exactly the twenty-minute false diagnosis this note exists to prevent.
★ THE RULE IS NOT "BUMP IT WHEN THE CHANGE IS BIG". It is bump it EVERY time this file changes,
including when the edit feels too small to matter — small edits are the ones you skip it on.
⚠ HEADER SAID "HoneySweeps — theme.css / HSTHEME_REV" until 7 Oct. This is CandySweeps' own copy
and has been since the site was built; the name was carried over with the file. Harmless until
somebody greps for HSTHEME_REV to find out which site a stylesheet belongs to and gets the wrong
answer with total confidence.
REPLACES the old dark stylesheet. Goes to /assets/theme.css.
── WHY ONE FILE FIXES ALL OF THEM ────────────────────────────────────────────────────────────
The new homepage carries its own inline CSS, but privacy-policy.php, ad-disclosure.php,
contact-us.php and thank-you.php all still this file and were rendering on a near-black
rgb(18,13,6) background. Homepage light and new, every other page dark and old.
Rewritten rather than patched: every class below was read off those four files, not guessed —
page-flex · site-head · site-logo · page · back-link · content-card · page-title · page-subtitle
contact-detail · detail-label · detail-content · center-wrap · form-shell · ty-card · check-icon
ty-heading · ty-message · btn-home · deco-icons · site-footer · wrap · flinks · age · disc · copy
⚠ ANY CLASS NOT IN THAT LIST IS NOT STYLED HERE. If a page appears unstyled after this goes up,
it uses markup none of those four files do — send it to me rather than assuming the file is bad.
── ★★ THE PALETTE WAS HONEYSWEEPS', NOT CANDYSWEEPS'. (7 Oct 2026, #468) ─────────────────────
The comment here read "THE PALETTE IS THE HOMEPAGE'S — kept as :root custom properties so the two
cannot drift: if the homepage palette changes, these names change with it."
⚠ THAT IS THE EXACT OPPOSITE OF WHAT CUSTOM PROPERTIES DO ACROSS TWO FILES. Sharing a VARIABLE
NAME is not sharing a VALUE. index.php declares its own :root and this file declares its own; the
names matched and the numbers were free to diverge — which is precisely what happened the moment
CandySweeps repainted the homepage pink and nobody opened a legal page. The comment promised a
coupling that does not exist in CSS, and then stood there asserting it for weeks. A mechanism that
is described as preventing drift, and does not, is worse than no mechanism: it stops people
checking.
Found only because Chris screenshotted the new cookie policy and the page was CREAM. Every legal
page and the thank-you page were rendering in honey gold (#F2A20C), honey cream (#FFFBF0) and
honey brown (#1B1205) — HoneySweeps' colours, on CandySweeps, since the site was built. The candy
dots added minutes earlier were sitting on a honey-coloured page.
Values below are now index.php's :root verbatim. The --gold-* and --cyan-* ramps have no homepage
equivalent (the homepage only declares a flat --gold and --cyan) so they are rebuilt around the
CandySweeps gold #FFC01E and cyan #29ABE2 rather than left on the honey ones.
★ THEY STILL CANNOT ENFORCE EACH OTHER. Two files, two declarations, no link. The only real
protection is to CHANGE BOTH TOGETHER and to LOOK AT A LEGAL PAGE after any homepage theme change
— the thing neither of us did. Said plainly here instead of the comforting version.
══════════════════════════════════════════════════════════════════════════════════════════════ */
:root{
/* ⚠ MIRRORS index.php's :root. Change one, change the other, then open a legal page. */
--gold:#FFC01E; --gold-lt:#FFD95E; --gold-hi:#FFF0B8; --gold-dk:#C9941A;
--cyan:#29ABE2; --cyan-lt:#7FD3F2; --cyan-dk:#1B7FA8;
--pink:#EE3A7D; --lime:#7DC832;
--ink:#3A1B12; --ink-2:#7A5548; --line:#F6D9E4; --paper:#FFF8FB;
--font:'Inter',-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Arial,sans-serif;
--display:'Poppins','Inter',-apple-system,'Segoe UI',Roboto,Arial,sans-serif;
}
*{box-sizing:border-box}
/* ★★ CANDY DOTS, NOT THE HONEYCOMB LATTICE. (7 Oct 2026, #468)
The comment here read "The honeycomb, identical to the homepage" — and it was HONEST when it was
written, because the homepage DID carry the comb then. The homepage moved to candy dots during the
CandySweeps build; this file did not, and the comment went on asserting a match that had stopped
being true. Result: a honeycomb lattice behind every legal page and the thank-you page, in
HoneySweeps' gold, on a pink candy site. Chris spotted it in a screenshot of the new cookie policy.
⚠ THIS IS THE THIRD PLACE THE COMB HAD TO BE REMOVED, AND THE LAST ONE FOUND.
1. the homepage SVG pattern — done when the site was built
2. six clip-path shapes — done earlier today
3. this background — missed by both passes
The first two were found by searching for a SHAPE (the polygon). This one is a lattice made of
three crossed repeating-linear-gradients, with no polygon, no hexagon, and no word "comb" in the
CSS itself. A grep for the motif could never have found it; only looking at the page could.
★ A VISUAL MOTIF CANNOT BE FULLY REMOVED BY GREP. Look at every page type after a theme change —
the legal pages load a different stylesheet from the homepage and nobody had opened one since.
⚠ A COMMENT THAT DESCRIBES ANOTHER FILE GOES STALE SILENTLY. "identical to the homepage" was a
claim about a file this one cannot see. Said once, true once, then quietly wrong for weeks.
Same technique as before — gradients, so there is still no image request — and the same four
palette colours as the homepage's #dotbg, on the same 84px grid at four offsets so the dots
scatter rather than forming visible rows. Fixed, so it covers the whole document however long. */
body{
margin:0;
color:var(--ink);
font-family:var(--font);
font-size:16px;
line-height:1.65;
background-color:var(--paper);
/* ⚠ SECOND ATTEMPT. The first one was candy dots I INVENTED — an 84px grid of uniform 2.2px dots
with a #FFE9F2 wash — rather than the homepage's. Chris put the two pages side by side and they
were obviously different: his were bigger, denser, more saturated. I had replaced "looks like
HoneySweeps" with "looks like neither", which is not an improvement, and I would not have caught
it because I never compared the two pages myself.
★ MATCHING A DESIGN MEANS READING ITS NUMBERS, NOT REMEMBERING ITS IDEA. "Candy dots" is the
idea; 60×60, r=5/3.5/4/3, those four positions and those four opacities are the design.
Values below are index.php's #dotbg pattern and its body wash, copied exactly:
60×60 tile · (12,12) r5 pink .13 · (42,24) r3.5 gold .22
· (24,44) r4 cyan .14 · (52,54) r3 lime .16
wash: radial-gradient(900px 420px at 50% 0%, #FFE3EF → transparent 70%)
Done as CSS gradients rather than the homepage's inline