Phase 1a.4: what execution found — plan corrected, buttons investigated - #529
Merged
Merged
Conversation
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Investigated the last untouched 1a.4 item. `components/c-button.css` already defines exactly three roles - --primary (ruby/white), --secondary (white/dark), --tertiary (transparent/ruby) - and is already tokenised apart from four `#ffffff` literals. I tokenised those literals, then checked whether it mattered and reverted: **`c-button--*` appears ZERO times in any template or content file**, and PurgeCSS strips it from every shipped bundle - `grep -rc 'c-button--primary' _dest/public-dev/css/*.css` returns nothing. The component was built and never adopted; the live buttons are FL Builder's `.fl-button`. Reverting rather than shipping was the point. A tidy diff against dead code reads as "button roles: done" to the next person and changes nothing a visitor sees - the third instance of that failure on this phase, after the careers eyebrow (overridden by a later file) and the friday screenshot assertion (excluded from CRITICAL_TESTS). The real item is either adopting c-button in templates (a markup migration) or bringing `.fl-button` onto the three roles (another sweep through the per-page FL export CSS). Both are larger than the plan line implies, and the second is the same legacy-export problem as the footer and eyebrow items. The tertiary role also sits on the on-dark AA blocker wherever it lands on a dark band. Recorded in Outstanding. Docs only; bin/hugo-build clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recording measured reality in the plan itself, because the next session reads the plan and would otherwise re-estimate the same four items the same way. One of four items was what the line said. The alias deletion shipped first try with zero visual delta. The other three are materially different work: * Footer onto surface-ink is not a footer change - it is one edge of a dark region built from a CSS background, an SVG fill on a pointer-events:none shape layer, and a painter still unidentified. 7+ bundles, 1b in size. * One eyebrow style cannot be one style - the canonical form was designed against LIGHT surfaces and drops two homepage eyebrows to 4.10:1 when applied site-wide. Swept, measured, reverted. * Three button roles is already built and never adopted - c-button--* appears zero times in markup and PurgeCSS strips it from every bundle. And the connection nothing in the plan made: **two of them are gated by the same missing token.** --color-ruby is 4.10:1 on #000 and 3.67:1 on --surface-ink, so the dark-surface migration makes contrast WORSE. Eyebrows and the tertiary button role both sit on it. Also recorded, because it is the transferable part: the estimates were written against the TOKEN layer while the work is against the FL-Builder export CSS that redeclares everything per page. Three changes this phase looked complete, passed every gate, and did nothing at runtime - an eyebrow rule overridden by a later file, a screenshot assertion excluded from CRITICAL_TESTS, and a tokenisation of purged dead code. The plan now tells the next session to verify a change reaches the rendered page before counting it done. Docs only; bin/hugo-build clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
**My PurgeCSS check was a false green.** I cited `grep -rc 'c-button--primary' _dest/public-dev/css/*.css` returning nothing. That command returns nothing whether or not the component is adopted: public-dev is built in DEV mode where PurgeCSS is disabled, and this CSS is emitted INLINE in the HTML rather than under css/*.css. Re-verified against the production tree - `grep -rl 'c-button' _dest/public-test/` returns nothing and components.css is not referenced from index.html - so the conclusion survives, but the evidence I published for it did not. Both are now recorded, because "right answer, wrong proof" is the failure that makes the NEXT claim untrustworthy. **The live buttons are five families, not one.** `.fl-button`, `.btn`/ `.btn-primary` (navigation), `.btn--primary` (shortcodes/cta), `.action-button` (use-cases) and `.pp-button` (services). My "sweep `.fl-button`" framing would have left four families outside the roles. **The tags deliverable had vanished from the matrix.** My four-row table silently replaced "tags to ink site-wide" - an actual scope item - with the `--rr-*` alias deletion, which the brief lists separately. An executor reading it would skip the 17-bundle tag work entirely. Tags restored as an OPEN row, honestly marked NOT investigated, and the alias row relabelled as the separate deletion item. **The plan linked to a blocker absent from this branch.** It was cut from a stale origin/master predating #528. Rebased onto current master; the ruby-on-dark Outstanding entry the note points at now exists here. Docs only; bin/hugo-build clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pftg
force-pushed
the
phase-1a4-buttons-finding
branch
from
August 21, 2026 03:05
8578b34 to
01ea8cc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs only. Closes out the 1a.4 investigation by recording what each item
actually requires, so the next session doesn't re-estimate them the same way.
The last item: "three button roles" is already built and never adopted
components/c-button.cssdefines all three roles, already tokenised apart fromfour
#ffffffliterals. I fixed those, then checked whether it mattered:c-button--*appears zero times in any template or content filegrep -rc 'c-button--primary' _dest/public-dev/css/*.cssreturns nothing.fl-buttonI reverted the change. A tidy diff against dead code reads as "button roles:
done" and changes nothing a visitor sees.
One of four items was what the plan said
--rr-*alias deletionsurface-inkThe connection the plan never made
Two items are gated by the same missing token.
--color-rubyis 4.10:1 on#000and 3.67:1 on--surface-ink— so the dark-surface migration makescontrast worse, not better. Eyebrows and the tertiary button role both sit
on it.
Why the estimates were wrong — the transferable part
They were written against the token layer; the work is against the
FL-Builder export CSS that redeclares everything per page.
Three changes this phase looked complete, passed every gate, and did nothing at
runtime:
CRITICAL_TESTSThe plan now tells the next session to verify a change reaches the rendered page
before counting it done.
Gates
bin/hugo-buildclean. Docs only — no CSS, templates, or baselines touched.🤖 Generated with Claude Code