toilville.com: generated patterns are a content skeleton — fidelity gaps vs the design #102

New issue

Open

opened 2026-09-09 20:42:53 +00:00 by peterswimm · 10 comments

peterswimm commented 2026-09-09 20:42:53 +00:00

Owner

Copy link

The toilville.com design is now wired into the deck → ForgeBlock → WP FSE
pattern pipeline (#101, merged). Colour is fully tokenised — the export's 508
raw hex literals are gone and CTAs bind to real palette slugs.

But the generated patterns are a token-bound content skeleton, not a rendering
of the design. This issue is the visual evidence, so the call on how far to
take it is yours.

In every image below: left = the design source, right (terracotta border)
= what build_surfaces.py generates today.

---

1. Inline <em> is displaced to the end of the heading

The hero reads "Governance should be a , not a plugin. primitive".
_collect_text() concatenates the element's own text before recursing into
children, so emphasised runs inside a heading get moved to the end.

2. Feature bullets reduce to bare en-dashes, and card grids flatten

On Home: the Rituals/Spelwork feature lists become three empty – paragraphs,
and both the 2-up product cards and the 3-up belief cards collapse into one
linear column. No column_set or fact_set is detected anywhere.

Also visible: the RITUALS and SPELWORK logo marks are dropped (no media block).

3. Rituals — the Wish/Steward/Ritual triad and the ritual-in-progress demo

The three-column model and the stepped demo both flatten. CTAs survive.

4. Spelwork — terminal block and intent-registry console

The CLI quickstart loses its terminal framing; the console mockup's sidebar +
table become a paragraph run.

5. News — post list loses its structure

Date / title / category become three separate paragraphs per entry, with the
category rendering as an uppercase mono label. No post-list structure, no
actions detected.

6. Contact — the form doesn't survive at all

Name / Work email / Organization / "Interested in" / "What do you need to
prove?" and the Send button are all lost. The footer sitemap flattens.

---

What the fix looks like

All of these are fixable without changing the converter — it already has an
explicit grammar that beats its heuristics (_build_labeled). That's how the
CTAs were fixed in #101: annotating 16 <a> elements with
data-block="button" and their containers with data-block="actions" was
enough to produce real wp:buttons.

The same applies here:

Gap	Fix
card grids	data-block="column_set" on the grid containers
feature lists	data-block="fact_set" with data-label/data-value
logos	data-block="media" on the logo wrappers
News entries	data-block="fact_set" or a post-list mapping
Contact form	no ForgeBlock vocabulary for form fields — see below
heading <em>	this one is a converter bug in _collect_text()

Two things genuinely need a decision rather than annotation:

1. The Contact form. forgeblock.yml has input as an element, but the
   pattern renderer has no form mapping. And the submission handler belongs in
   the WordPress/plugin layer, not this repo (submodule rules). Options: hand-author
   the form as a theme pattern, or use a form plugin and keep only the markup here.
2. How faithful do these need to be? If the plan is to hand-build
   toilville-fse templates anyway, these patterns are fine as content
   scaffolding and the annotation pass isn't worth it. If they're meant to be the
   actual page output, the annotation pass is real but bounded work.

Also worth knowing

spelwork's wp-style.json resolves to an empty palette — its paths use
color.primary, which isn't a token key — so its generated patterns carry no
colour at all. tctd resolves 1 of its entries. Unrelated to this design, but
it's the same mechanism and probably wants its own fix.

---

Evidence + render harness: docs/reviews/toilville-site-fidelity-2026-09-09/
on branch docs/toilville-site-fidelity-evidence.

The toilville.com design is now wired into the deck → ForgeBlock → WP FSE pattern pipeline (#101, merged). Colour is fully tokenised — the export's 508 raw hex literals are gone and CTAs bind to real palette slugs. But the generated patterns are a **token-bound content skeleton, not a rendering of the design**. This issue is the visual evidence, so the call on how far to take it is yours. In every image below: **left = the design source**, **right (terracotta border) = what `build_surfaces.py` generates today**. --- ## 1. Inline `<em>` is displaced to the end of the heading The hero reads *"Governance should be a , not a plugin. primitive"*. `_collect_text()` concatenates the element's own text before recursing into children, so emphasised runs inside a heading get moved to the end.  ## 2. Feature bullets reduce to bare en-dashes, and card grids flatten On Home: the Rituals/Spelwork feature lists become three empty `–` paragraphs, and both the 2-up product cards and the 3-up belief cards collapse into one linear column. No `column_set` or `fact_set` is detected anywhere. Also visible: the RITUALS and SPELWORK logo marks are dropped (no `media` block).  ## 3. Rituals — the Wish/Steward/Ritual triad and the ritual-in-progress demo The three-column model and the stepped demo both flatten. CTAs survive.  ## 4. Spelwork — terminal block and intent-registry console The CLI quickstart loses its terminal framing; the console mockup's sidebar + table become a paragraph run.  ## 5. News — post list loses its structure Date / title / category become three separate paragraphs per entry, with the category rendering as an uppercase mono label. No post-list structure, no actions detected.  ## 6. Contact — the form doesn't survive at all Name / Work email / Organization / "Interested in" / "What do you need to prove?" and the Send button are all lost. The footer sitemap flattens.  --- ## What the fix looks like All of these are fixable **without changing the converter** — it already has an explicit grammar that beats its heuristics (`_build_labeled`). That's how the CTAs were fixed in #101: annotating 16 `<a>` elements with `data-block="button"` and their containers with `data-block="actions"` was enough to produce real `wp:buttons`. The same applies here: | Gap | Fix | |---|---| | card grids | `data-block="column_set"` on the grid containers | | feature lists | `data-block="fact_set"` with `data-label`/`data-value` | | logos | `data-block="media"` on the logo wrappers | | News entries | `data-block="fact_set"` or a post-list mapping | | Contact form | no ForgeBlock vocabulary for form fields — see below | | heading `<em>` | this one **is** a converter bug in `_collect_text()` | Two things genuinely need a decision rather than annotation: 1. **The Contact form.** `forgeblock.yml` has `input` as an element, but the pattern renderer has no form mapping. And the submission handler belongs in the WordPress/plugin layer, not this repo (submodule rules). Options: hand-author the form as a theme pattern, or use a form plugin and keep only the markup here. 2. **How faithful do these need to be?** If the plan is to hand-build `toilville-fse` templates anyway, these patterns are fine as content scaffolding and the annotation pass isn't worth it. If they're meant to be the actual page output, the annotation pass is real but bounded work. ## Also worth knowing `spelwork`'s `wp-style.json` resolves to an **empty palette** — its paths use `color.primary`, which isn't a token key — so its generated patterns carry no colour at all. `tctd` resolves 1 of its entries. Unrelated to this design, but it's the same mechanism and probably wants its own fix. --- Evidence + render harness: `docs/reviews/toilville-site-fidelity-2026-09-09/` on branch `docs/toilville-site-fidelity-evidence`.

ville was assigned by peterswimm 2026-09-09 20:42:57 +00:00

peterswimm referenced this issue 2026-09-09 20:43:11 +00:00

docs(review): side-by-side fidelity evidence for the toilville deck pipeline #103

peterswimm commented 2026-09-09 20:50:33 +00:00

Author

Owner

Copy link

Correction — I missed a layer, and it changes the fix

Peter pointed out that this is a three-layer transform, not two. I only
accounted for two:

Layer	What	Where	State
1. Design	.dc.html canvas	Media/Decks/templates/toilville/	✅ #101
2. ForgeBlock	semantic JSON	*.forgeblock.json	✅ #101
3. Gutenberg	toilville/* blocks	Toilville_Rituals/wordpress/rituals-wp/blocks/	✅ already exists

Layer 3 already exists — 12 blocks — and the theme already composes them.
toilville-fse/templates/front-page.html is currently:

wp:toilville/hero-home
wp:toilville/products-grid
wp:query           (Notes from the bench)
wp:toilville/testimonial
wp:toilville/joinband-cta

So the real defect is narrower and different from what I wrote above:
forgeblock_pattern.py maps layer 2 → core Gutenberg (wp:paragraph,
wp:heading, wp:group, wp:buttons). It has no knowledge of toilville/*.
That is why the right-hand column in every screenshot is flat — it isn't that
the design information was lost, it's that it was rendered through primitives
instead of through the blocks that carry the design.

It also means the landing.php #101 generates duplicates and degrades what
front-page.html already does correctly.

Most of the "gaps" above are the wrong diagnosis

data-block annotation is not the fix for most of them. The blocks already have
the right shape:

Design section	Block	Fit
Home hero	toilville/hero-home	exact — eyebrow, headline1, headline2, body, cta1*, cta2*, proof
"What we make"	toilville/products-grid + product-card	good
Home CTA	toilville/joinband-cta	good
Spelwork hero	toilville/spelwork-hero	exact
Spelwork pipeline	toilville/spelwork-pipeline + pipeline-stage	good
Spelwork CTA	toilville/spelwork-cta	good
"What we believe"	toilville/spelwork-governance-triad	plausible reuse
Contact form	toilville/wish-form	exact — spec="contact", formTitle, buttonText, successMessage, serviceOptions
News list	core wp:query	already works

Two specific retractions:

• Gap 1 (displaced <em>) is not a blocker. hero-home has headline1 /
  headline2 as separate attributes — the two-line split is structural in the
  block, so the emphasis problem doesn't arise on that path at all.
• Gap 6 (Contact form). I said there was no form mapping and the handler
  belonged elsewhere. Wrong — toilville/wish-form already exists with exactly
  the design's fields, including the "Interested in" options and the success
  message.

What is genuinely still missing

No block yet for: Rituals hero, the Wish/Steward/Ritual triad, the
ritual-in-progress stepped demo + history, the Spelwork CLI terminal, the
intent-registry console, and "Who we are". Roughly 8 of ~15 section types are
covered.

The blocks are built for the previous site. Their defaults are the old
positioning ("Made by hand, on purpose", "Four tools, one grammar."), not
"Governance should be a primitive, not a plugin."

The blocks carry their own off-token palette, including the terracotta that
#99 just corrected:

#cc5c37 (stale terracotta)  9 occurrences
#c05734 (canonical)         0 occurrences

plus #7394c8 ×21, #0e0e0e ×17, #471f12 ×16, #587c6d ×10, #c66c5a ×6.
They mix var(--wp--preset--color--*) with raw hex. So the same tokenisation
work this repo just did needs doing in rituals-wp.

Sorry for the misdirection — the screenshots are still accurate as evidence of
current output, just not as a diagnosis.

## Correction — I missed a layer, and it changes the fix Peter pointed out that this is a **three-layer** transform, not two. I only accounted for two: | Layer | What | Where | State | |---|---|---|---| | 1. Design | `.dc.html` canvas | `Media/Decks/templates/toilville/` | ✅ #101 | | 2. ForgeBlock | semantic JSON | `*.forgeblock.json` | ✅ #101 | | 3. **Gutenberg** | **`toilville/*` blocks** | **`Toilville_Rituals/wordpress/rituals-wp/blocks/`** | ✅ **already exists** | **Layer 3 already exists — 12 blocks — and the theme already composes them.** `toilville-fse/templates/front-page.html` is currently: ``` wp:toilville/hero-home wp:toilville/products-grid wp:query (Notes from the bench) wp:toilville/testimonial wp:toilville/joinband-cta ``` So the real defect is narrower and different from what I wrote above: **`forgeblock_pattern.py` maps layer 2 → *core* Gutenberg** (`wp:paragraph`, `wp:heading`, `wp:group`, `wp:buttons`). It has no knowledge of `toilville/*`. That is why the right-hand column in every screenshot is flat — it isn't that the design information was lost, it's that it was rendered through primitives instead of through the blocks that carry the design. It also means the `landing.php` #101 generates **duplicates and degrades** what `front-page.html` already does correctly. ### Most of the "gaps" above are the wrong diagnosis `data-block` annotation is not the fix for most of them. The blocks already have the right shape: | Design section | Block | Fit | |---|---|---| | Home hero | `toilville/hero-home` | **exact** — `eyebrow`, `headline1`, `headline2`, `body`, `cta1*`, `cta2*`, `proof` | | "What we make" | `toilville/products-grid` + `product-card` | good | | Home CTA | `toilville/joinband-cta` | good | | Spelwork hero | `toilville/spelwork-hero` | **exact** | | Spelwork pipeline | `toilville/spelwork-pipeline` + `pipeline-stage` | good | | Spelwork CTA | `toilville/spelwork-cta` | good | | "What we believe" | `toilville/spelwork-governance-triad` | plausible reuse | | **Contact form** | **`toilville/wish-form`** | **exact** — `spec="contact"`, `formTitle`, `buttonText`, `successMessage`, `serviceOptions` | | News list | core `wp:query` | already works | Two specific retractions: - **Gap 1 (displaced `<em>`) is not a blocker.** `hero-home` has `headline1` / `headline2` as separate attributes — the two-line split is *structural* in the block, so the emphasis problem doesn't arise on that path at all. - **Gap 6 (Contact form).** I said there was no form mapping and the handler belonged elsewhere. Wrong — `toilville/wish-form` already exists with exactly the design's fields, including the "Interested in" options and the success message. ### What is genuinely still missing **No block yet** for: Rituals hero, the Wish/Steward/Ritual triad, the ritual-in-progress stepped demo + history, the Spelwork CLI terminal, the intent-registry console, and "Who we are". Roughly 8 of ~15 section types are covered. **The blocks are built for the previous site.** Their defaults are the old positioning (`"Made by hand, on purpose"`, `"Four tools, one grammar."`), not `"Governance should be a primitive, not a plugin."` **The blocks carry their own off-token palette**, including the terracotta that #99 just corrected: ``` #cc5c37 (stale terracotta) 9 occurrences #c05734 (canonical) 0 occurrences ``` plus `#7394c8` ×21, `#0e0e0e` ×17, `#471f12` ×16, `#587c6d` ×10, `#c66c5a` ×6. They mix `var(--wp--preset--color--*)` with raw hex. So the same tokenisation work this repo just did needs doing in `rituals-wp`. Sorry for the misdirection — the screenshots are still accurate as *evidence of current output*, just not as a diagnosis.

peterswimm referenced this issue 2026-09-09 21:02:30 +00:00

feat(surfaces): emit toilville/* Gutenberg blocks from ForgeBlock (layer 2 to 3) #104

peterswimm commented 2026-09-09 21:14:10 +00:00

Author

Owner

Copy link

Updated screenshots — now rendered through the real toilville/* blocks

#104 (the layer-2→3 emitter) and toilville_rituals#366 (the hero emphasis
attribute) are both in. Here is the same five-page comparison again.

Left = design source. Right (green border) = the generated pattern run
through the blocks' own render.php.

These are much closer to real WordPress output

The earlier set styled the core-block markup with a hand-written stylesheet. This
set actually executes each block's blocks/<name>/render.php with the
attributes the pattern carries — only wp_kses_post, esc_*,
get_block_wrapper_attributes and rest_url are shimmed. It then wraps the
result in the CSS variables WordPress emits from toilville-fse/theme.json
presets, plus every blocks/*/style.css verbatim.

Not real: WordPress itself, the theme's header/footer template parts, and the
core-block stylesheet (a small stand-in). Faithful preview, not production.

---

The displaced <em> is fixed

Root cause was in the converter, not annotation: handle_data() concatenated
every text run of a node into .text regardless of position, so
<h1>a <span>b</span> c</h1> flattened to "a c b". Node now keeps an
ordered parts interleave, and the heading records which run carries the
accent.

Home

The hero is now a real toilville/hero-home: eyebrow, accented headline, body,
both CTAs, art panel. The closing CTA is a real toilville/joinband-cta. Also
recovered here: "Let's build it." — my #101 annotation had promoted the
enclosing <div> to data-block="actions", which silently swallowed the
heading and body copy. Landing went 47 → 49 blocks.

Everything between the hero and the CTA is still core-block flat.

Spelwork

toilville/spelwork-hero + toilville/spelwork-cta.

Rituals, News, Contact — unchanged, deliberately

No hero block exists for these surfaces, and the adapters fall through to core
blocks rather than borrowing another page's hero.

---

What the new shots make obvious

The blocks are styled for the previous site. Look at the Home hero: the
design is sentence-case and tight; hero-home renders it uppercase with a
different type ramp, and carries an art panel (hands.svg) and a star "proof"
line that the current design doesn't have. Retargeting the copy defaults
(#366) didn't touch the layout, and that's the next real decision — it's a
design call, not an engineering one.

Coverage is still 4 blocks of ~15 section types. Hero and closing CTA on two
surfaces. Still no block for: Rituals hero, the Wish/Steward/Ritual triad, the
ritual-in-progress demo, the CLI terminal, the intent-registry console, "Who we
are". products-grid/product-card/wish-form adapters need column_set
and form detection in the converter first.

toilville/wish-form still isn't wired up — it exists and fits the Contact
page exactly (spec="contact", formTitle, serviceOptions,
successMessage), but nothing emits it yet, so Contact is still flat.

Two corrections from earlier in this thread

1. The "9× stale #cc5c37, 0× canonical" count was a plain grep that didn't
   distinguish fallbacks. They are all
   var(--wp--preset--color--primary, #cc5c37), so the blocks do reference
   the preset and already rendered the corrected #c05734. Only the fallback
   literal was stale; #366 updates it.
2. PHP is installed locally now, so I was able to lint what I couldn't before:
   all render.php files pass php -l. That closes the caveat on #366.

Harness + images: docs/reviews/toilville-site-fidelity-2026-09-09/after/ on
docs/toilville-site-fidelity-evidence (#103).

## Updated screenshots — now rendered through the real `toilville/*` blocks #104 (the layer-2→3 emitter) and toilville_rituals#366 (the hero `emphasis` attribute) are both in. Here is the same five-page comparison again. **Left** = design source. **Right** (green border) = the generated pattern run through the blocks' own `render.php`. ### These are much closer to real WordPress output The earlier set styled the core-block markup with a hand-written stylesheet. This set actually **executes each block's `blocks/<name>/render.php`** with the attributes the pattern carries — only `wp_kses_post`, `esc_*`, `get_block_wrapper_attributes` and `rest_url` are shimmed. It then wraps the result in the CSS variables WordPress emits from `toilville-fse/theme.json` presets, plus **every** `blocks/*/style.css` verbatim. Not real: WordPress itself, the theme's header/footer template parts, and the core-block stylesheet (a small stand-in). Faithful preview, not production. --- ### The displaced `<em>` is fixed Root cause was in the converter, not annotation: `handle_data()` concatenated every text run of a node into `.text` regardless of position, so `<h1>a <span>b</span> c</h1>` flattened to `"a c b"`. `Node` now keeps an ordered `parts` interleave, and the heading records which run carries the accent.  ### Home The hero is now a real `toilville/hero-home`: eyebrow, accented headline, body, both CTAs, art panel. The closing CTA is a real `toilville/joinband-cta`. Also recovered here: **"Let's build it."** — my #101 annotation had promoted the enclosing `<div>` to `data-block="actions"`, which silently swallowed the heading and body copy. Landing went 47 → 49 blocks. Everything between the hero and the CTA is still core-block flat.  ### Spelwork `toilville/spelwork-hero` + `toilville/spelwork-cta`.  ### Rituals, News, Contact — unchanged, deliberately No hero block exists for these surfaces, and the adapters fall through to core blocks rather than borrowing another page's hero.    --- ## What the new shots make obvious **The blocks are styled for the previous site.** Look at the Home hero: the design is sentence-case and tight; `hero-home` renders it **uppercase** with a different type ramp, and carries an art panel (`hands.svg`) and a star "proof" line that the current design doesn't have. Retargeting the *copy* defaults (#366) didn't touch the *layout*, and that's the next real decision — it's a design call, not an engineering one. **Coverage is still 4 blocks of ~15 section types.** Hero and closing CTA on two surfaces. Still no block for: Rituals hero, the Wish/Steward/Ritual triad, the ritual-in-progress demo, the CLI terminal, the intent-registry console, "Who we are". `products-grid`/`product-card`/`wish-form` adapters need `column_set` and form detection in the converter first. **`toilville/wish-form` still isn't wired up** — it exists and fits the Contact page exactly (`spec="contact"`, `formTitle`, `serviceOptions`, `successMessage`), but nothing emits it yet, so Contact is still flat. ## Two corrections from earlier in this thread 1. The "9× stale `#cc5c37`, 0× canonical" count was a plain grep that didn't distinguish fallbacks. They are all `var(--wp--preset--color--primary, #cc5c37)`, so the blocks **do** reference the preset and already rendered the corrected `#c05734`. Only the fallback literal was stale; #366 updates it. 2. PHP is installed locally now, so I was able to lint what I couldn't before: **all `render.php` files pass `php -l`.** That closes the caveat on #366. Harness + images: `docs/reviews/toilville-site-fidelity-2026-09-09/after/` on `docs/toilville-site-fidelity-evidence` (#103).

peterswimm commented 2026-09-09 21:31:50 +00:00

Author

Owner

Copy link

Migrated to the current design

The last set showed the blocks rendering the previous site's layout —
uppercase headline, art panel, star proof. That's now fixed. Same comparison,
third pass.

Left = design. Right (green) = the generated pattern through the real
render.php + block CSS.

The Home band is close: hero with the accent run inline, the [ 01 ] index on
the heading's baseline, and both product cards tinted by product with their
feature lists intact.

What changed

toilville_rituals#366 — layout migration:

• hero-home is a single column on a warm-to-white wash with the sun mark
  top-right, sentence-case at clamp(44px, 6vw, 82px)/1.02/-0.03em. The
  two-column art layout and the stars are gone; proof still works but renders
  nothing when empty.
• products-grid is the "What we make" band — primary-container wash, mono
  index on the heading baseline, auto-fit grid.
• product-card gains features, linkLabel/linkUrl and
  rituals/spelwork modes. It is now dynamic (render.php, save
  returns null) — a static block whose markup changes trips WordPress's
  "unexpected or invalid content" check on saved posts; a dynamic one
  re-renders. class-site-blocks.php now decides render_callback by whether
  a block ships a render.php rather than assuming children are static.

toilville-design#105 — two converter fixes and an adapter:

• <ul>/<ol> → fact_set. Lists fell through to a recurse that walks
  children only, so an <li>'s own text was dropped and the decorative
  <span>—</span> was all that survived. That was the (--) bug.
• <img> → image block. It was being dropped, taking the product logos with
  it — and the logo URL is the only thing that says which card is Spelwork.
  Without it both cards came out terracotta.
• _products_grid adapter emits the band as products-grid + one
  product-card per card.

toilville-design#106 — primary-container/secondary-container WP preset
slugs, so the band tint is a token rather than a literal.

Also worth noting

The harness itself was under-reporting: it only matched self-closing block
comments, and products-grid wraps InnerBlocks. Its section chrome was
rendering fine and simply wasn't in my screenshots. Fixed.

Still open

• Per-card links ("See Rituals →"). The design writes them as plain anchors,
  so the converter doesn't treat them as actions and they don't reach the
  adapter. The block renders them when given linkLabel; nothing supplies it.
• Logos aren't rendered. The image block now survives and picks the tint,
  but product-card has no logo attribute and the SVGs aren't in the plugin.
• Rituals / News / Contact are still core-block flat — no hero block for
  those surfaces, and toilville/wish-form still isn't wired to Contact.
• "What we believe" and "Who we are" have no block.

Images: docs/reviews/toilville-site-fidelity-2026-09-09/migrated/ on #103.

## Migrated to the current design The last set showed the blocks rendering the **previous** site's layout — uppercase headline, art panel, star proof. That's now fixed. Same comparison, third pass. **Left** = design. **Right** (green) = the generated pattern through the real `render.php` + block CSS.  The Home band is close: hero with the accent run inline, the `[ 01 ]` index on the heading's baseline, and both product cards tinted by product with their feature lists intact. ### What changed **toilville_rituals#366** — layout migration: - `hero-home` is a single column on a warm-to-white wash with the sun mark top-right, sentence-case at `clamp(44px, 6vw, 82px)/1.02/-0.03em`. The two-column art layout and the stars are gone; `proof` still works but renders nothing when empty. - `products-grid` is the "What we make" band — primary-container wash, mono index on the heading baseline, auto-fit grid. - `product-card` gains `features`, `linkLabel`/`linkUrl` and `rituals`/`spelwork` modes. **It is now dynamic** (`render.php`, `save` returns null) — a static block whose markup changes trips WordPress's "unexpected or invalid content" check on saved posts; a dynamic one re-renders. `class-site-blocks.php` now decides `render_callback` by whether a block ships a `render.php` rather than assuming children are static. **toilville-design#105** — two converter fixes and an adapter: - `<ul>`/`<ol>` → `fact_set`. Lists fell through to a recurse that walks children only, so an `<li>`'s own text was dropped and the decorative `<span>—</span>` was all that survived. **That was the `(--)` bug.** - `<img>` → image block. It was being dropped, taking the product logos with it — and the logo URL is the only thing that says which card is Spelwork. Without it both cards came out terracotta. - `_products_grid` adapter emits the band as `products-grid` + one `product-card` per card. **toilville-design#106** — `primary-container`/`secondary-container` WP preset slugs, so the band tint is a token rather than a literal. ### Also worth noting The harness itself was under-reporting: it only matched **self-closing** block comments, and `products-grid` wraps InnerBlocks. Its section chrome was rendering fine and simply wasn't in my screenshots. Fixed. ### Still open - **Per-card links** ("See Rituals →"). The design writes them as plain anchors, so the converter doesn't treat them as actions and they don't reach the adapter. The block renders them when given `linkLabel`; nothing supplies it. - **Logos** aren't rendered. The image block now survives and picks the tint, but `product-card` has no `logo` attribute and the SVGs aren't in the plugin. - **Rituals / News / Contact** are still core-block flat — no hero block for those surfaces, and `toilville/wish-form` still isn't wired to Contact. - **"What we believe"** and **"Who we are"** have no block. Images: `docs/reviews/toilville-site-fidelity-2026-09-09/migrated/` on #103.

peterswimm commented 2026-09-09 21:42:29 +00:00

Author

Owner

Copy link

Ready for sign-off — rendered from main in both repos

Everything below comes from merged code, not branches:

• toilville-design @ main — the generated patterns
• Toilville_Rituals @ main — the toilville/* blocks and their CSS

Left is the approved design canvas. Right is what toilville-fse +
rituals-wp actually produce today.

Home

Hero and the "What we make" band both track the design: accent run inline, sun
mark, [ 01 ] index on the heading baseline, both cards tinted by product with
their feature lists.

Spelwork

spelwork-hero + spelwork-cta. The middle sections still fall back to core
blocks.

Rituals

News

Contact

---

What ville is signing off on

Ready: Home hero, the products band, the closing CTA, and the Spelwork hero
and CTA — all rendering through toilville/* blocks with token-bound colour.
Zero raw hex reaches the page; the palette comes from theme.json presets.

Not ready, and visible above: Rituals, News and Contact are still core-block
flat. There is no hero block for those surfaces, so the adapters deliberately
fall through rather than borrow another page's hero. Also missing: per-card
links, the product logos, and toilville/wish-form wired to Contact.

So this is a partial migration. Home and Spelwork are close to the design;
the other three pages are structured content, not the design.

Deploying

Two pieces, and they must go together — the theme's front-page.html composes
blocks that live in the plugin:

1. Theme — rsync per udg/products/wp-themes/README.md:

   rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/
   

   Bind-mounted, so it is live immediately with no container restart.

2. Plugin — the Deploy rituals-wp workflow (workflow_dispatch), target
   wordpress, activate true.

Order matters. Deploy the plugin first. The theme's front page references
toilville/hero-home, toilville/products-grid, toilville/testimonial and
toilville/joinband-cta; if the theme lands first those render as missing
blocks.

One thing to check on the live site after deploying: product-card changed
from a static-save block to a dynamic one. That is the safe direction — a
dynamic block re-renders instead of tripping "unexpected or invalid content" —
but any page that already embeds a product card should be opened once to
confirm.

Still open

#103 carries every image in this thread, including these. It is still
unmerged, so if that branch is deleted the screenshots in all four comments
break.

## Ready for sign-off — rendered from `main` in both repos Everything below comes from **merged code**, not branches: - `toilville-design` @ `main` — the generated patterns - `Toilville_Rituals` @ `main` — the `toilville/*` blocks and their CSS Left is the approved design canvas. Right is what `toilville-fse` + `rituals-wp` actually produce today. ### Home  Hero and the "What we make" band both track the design: accent run inline, sun mark, `[ 01 ]` index on the heading baseline, both cards tinted by product with their feature lists. ### Spelwork  `spelwork-hero` + `spelwork-cta`. The middle sections still fall back to core blocks. ### Rituals  ### News  ### Contact  --- ## What ville is signing off on **Ready:** Home hero, the products band, the closing CTA, and the Spelwork hero and CTA — all rendering through `toilville/*` blocks with token-bound colour. Zero raw hex reaches the page; the palette comes from `theme.json` presets. **Not ready, and visible above:** Rituals, News and Contact are still core-block flat. There is no hero block for those surfaces, so the adapters deliberately fall through rather than borrow another page's hero. Also missing: per-card links, the product logos, and `toilville/wish-form` wired to Contact. So this is a **partial** migration. Home and Spelwork are close to the design; the other three pages are structured content, not the design. ## Deploying Two pieces, and they must go together — the theme's `front-page.html` composes blocks that live in the plugin: 1. **Theme** — `rsync` per `udg/products/wp-themes/README.md`: ``` rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/ ``` Bind-mounted, so it is live immediately with no container restart. 2. **Plugin** — the `Deploy rituals-wp` workflow (`workflow_dispatch`), target `wordpress`, activate `true`. **Order matters.** Deploy the plugin first. The theme's front page references `toilville/hero-home`, `toilville/products-grid`, `toilville/testimonial` and `toilville/joinband-cta`; if the theme lands first those render as missing blocks. One thing to check on the live site after deploying: `product-card` changed from a static-save block to a **dynamic** one. That is the safe direction — a dynamic block re-renders instead of tripping "unexpected or invalid content" — but any page that already embeds a product card should be opened once to confirm. ## Still open **#103** carries every image in this thread, including these. It is still unmerged, so if that branch is deleted the screenshots in all four comments break.

peterswimm commented 2026-09-09 23:10:42 +00:00

Author

Owner

Copy link

⚠️ Images above are broken — working links here

#103 merged (as #107) and its branch was deleted, so every image in the four
comments above now 404s: they pointed at
raw/branch/docs/toilville-site-fidelity-evidence/….

The files are all on main now. Ville — read this comment, not the ones
above.

Sign-off set — main in both repos

Left is the approved design canvas. Right is what toilville-fse +
rituals-wp produce today.

Home

Spelwork

Rituals

News

Contact

---

What you're signing off on

Ready: the Home hero, the "What we make" band, the closing CTA, and the
Spelwork hero and CTA — all rendering through toilville/* blocks with
token-bound colour. No raw hex reaches the page.

Not ready, and visible above: Rituals, News and Contact are still
core-block flat. There is no hero block for those surfaces, so the adapters
deliberately fall through rather than borrow another page's hero. Also missing:
the per-card links, the product logos, and toilville/wish-form wired to
Contact.

So this is a partial migration — two of five pages match the design; the
other three are structured content.

Deploying

Two pieces, and the plugin must go first — the theme's front-page.html
composes blocks that live in the plugin, so if the theme lands first they render
as missing blocks:

1. Plugin — Deploy rituals-wp workflow (workflow_dispatch), target
   wordpress, activate true.
2. Theme — rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/
   (bind-mounted, live immediately, no restart).

After deploying: product-card moved from a static-save block to a dynamic
one. That is the safe direction — dynamic re-renders instead of tripping
"unexpected or invalid content" — but open any page that already embeds a
product card once, to confirm.

Earlier sets, for the record

• before the layer 2→3 emitter — ForgeBlock straight to core blocks
• emitter landed, blocks still on the old design
• blocks migrated, rendered from branches

## ⚠️ Images above are broken — working links here #103 merged (as #107) and its branch was deleted, so every image in the four comments above now 404s: they pointed at `raw/branch/docs/toilville-site-fidelity-evidence/…`. The files are all on `main` now. **Ville — read this comment, not the ones above.** ## Sign-off set — `main` in both repos Left is the approved design canvas. Right is what `toilville-fse` + `rituals-wp` produce today. ### Home  ### Spelwork  ### Rituals  ### News  ### Contact  --- ## What you're signing off on **Ready:** the Home hero, the "What we make" band, the closing CTA, and the Spelwork hero and CTA — all rendering through `toilville/*` blocks with token-bound colour. No raw hex reaches the page. **Not ready, and visible above:** Rituals, News and Contact are still core-block flat. There is no hero block for those surfaces, so the adapters deliberately fall through rather than borrow another page's hero. Also missing: the per-card links, the product logos, and `toilville/wish-form` wired to Contact. **So this is a partial migration** — two of five pages match the design; the other three are structured content. ## Deploying Two pieces, and **the plugin must go first** — the theme's `front-page.html` composes blocks that live in the plugin, so if the theme lands first they render as missing blocks: 1. **Plugin** — `Deploy rituals-wp` workflow (`workflow_dispatch`), target `wordpress`, activate `true`. 2. **Theme** — `rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/` (bind-mounted, live immediately, no restart). After deploying: `product-card` moved from a static-save block to a **dynamic** one. That is the safe direction — dynamic re-renders instead of tripping "unexpected or invalid content" — but open any page that already embeds a product card once, to confirm. ## Earlier sets, for the record - [before the layer 2→3 emitter](https://git.toilville.dev/Toilville/toilville-design/raw/branch/main/docs/reviews/toilville-site-fidelity-2026-09-09/landing.png) — ForgeBlock straight to core blocks - [emitter landed, blocks still on the old design](https://git.toilville.dev/Toilville/toilville-design/raw/branch/main/docs/reviews/toilville-site-fidelity-2026-09-09/after/landing.png) - [blocks migrated, rendered from branches](https://git.toilville.dev/Toilville/toilville-design/raw/branch/main/docs/reviews/toilville-site-fidelity-2026-09-09/migrated/landing.png)

peterswimm commented 2026-09-09 23:16:20 +00:00

Author

Owner

Copy link

Coverage, in numbers — this is NOT 1:1 with the design

To be unambiguous before sign-off. Counting Gutenberg blocks in the generated
patterns on main:

Page	toilville/* blocks	core fallback
Home	5	29
Spelwork	2	85
Rituals	0	69
News	0	19
Contact	0	16

By design section, 5 of ~20 are covered by a real block:

Page	Section	Block
Home	hero	✅ hero-home
Home	What we make	✅ products-grid + 2 × product-card
Home	What we believe	❌ core
Home	Who we are	❌ core
Home	Latest	❌ core (the theme's front-page.html uses wp:query here)
Home	Let's build it	✅ joinband-cta
Rituals	hero	❌ no block exists
Rituals	Wish / Steward / Ritual	❌
Rituals	ritual-in-progress demo	❌
Rituals	capability grid	❌
Rituals	CTA	❌
Spelwork	hero	✅ spelwork-hero
Spelwork	CLI quickstart	❌
Spelwork	intent-registry console	❌
Spelwork	docs index	❌
Spelwork	community	❌
Spelwork	CTA	✅ spelwork-cta
News	post list	❌ (core wp:query is arguably correct here)
Contact	form	❌ — toilville/wish-form exists and fits exactly, but nothing emits it

Why Home looks better than it is: the hero and products band dominate the
screenshot. Everything below them on that page is flat paragraphs.

What 1:1 would need

• Blocks that don't exist yet: Rituals hero, the Wish/Steward/Ritual triad, the
  ritual-in-progress demo, the CLI terminal, the intent-registry console, "Who
  we are", "What we believe".
• Adapters for blocks that do exist but aren't wired: wish-form → Contact,
  testimonial, verdict-card, pipeline-stage.
• Two smaller gaps on the covered sections: per-card links (the design writes
  them as plain anchors, so they never reach the adapter) and the product logos
  (the image block survives and picks the card tint now, but product-card has
  no logo attribute and the SVGs aren't in the plugin).

So what is deployable today

The Home hero and products band, the closing CTA, and the Spelwork hero and CTA
— those match the design and are token-bound. The rest is structured content
in the right order with the right copy, styled by the theme rather than by the
design.

That is a real improvement over what is live, and it is safe to deploy. It is
not the design. Worth deciding explicitly which of those two you are approving.

## Coverage, in numbers — this is NOT 1:1 with the design To be unambiguous before sign-off. Counting Gutenberg blocks in the generated patterns on `main`: | Page | `toilville/*` blocks | core fallback | |---|---|---| | Home | 5 | 29 | | Spelwork | 2 | 85 | | Rituals | **0** | 69 | | News | **0** | 19 | | Contact | **0** | 16 | By design section, **5 of ~20 are covered by a real block**: | Page | Section | Block | |---|---|---| | Home | hero | ✅ `hero-home` | | Home | What we make | ✅ `products-grid` + 2 × `product-card` | | Home | What we believe | ❌ core | | Home | Who we are | ❌ core | | Home | Latest | ❌ core (the theme's `front-page.html` uses `wp:query` here) | | Home | Let's build it | ✅ `joinband-cta` | | Rituals | hero | ❌ no block exists | | Rituals | Wish / Steward / Ritual | ❌ | | Rituals | ritual-in-progress demo | ❌ | | Rituals | capability grid | ❌ | | Rituals | CTA | ❌ | | Spelwork | hero | ✅ `spelwork-hero` | | Spelwork | CLI quickstart | ❌ | | Spelwork | intent-registry console | ❌ | | Spelwork | docs index | ❌ | | Spelwork | community | ❌ | | Spelwork | CTA | ✅ `spelwork-cta` | | News | post list | ❌ (core `wp:query` is arguably correct here) | | Contact | form | ❌ — `toilville/wish-form` exists and fits exactly, but nothing emits it | **Why Home looks better than it is:** the hero and products band dominate the screenshot. Everything below them on that page is flat paragraphs. ### What 1:1 would need - Blocks that don't exist yet: Rituals hero, the Wish/Steward/Ritual triad, the ritual-in-progress demo, the CLI terminal, the intent-registry console, "Who we are", "What we believe". - Adapters for blocks that *do* exist but aren't wired: `wish-form` → Contact, `testimonial`, `verdict-card`, `pipeline-stage`. - Two smaller gaps on the covered sections: per-card links (the design writes them as plain anchors, so they never reach the adapter) and the product logos (the image block survives and picks the card tint now, but `product-card` has no `logo` attribute and the SVGs aren't in the plugin). ### So what is deployable today The Home hero and products band, the closing CTA, and the Spelwork hero and CTA — those match the design and are token-bound. The rest is **structured content in the right order with the right copy**, styled by the theme rather than by the design. That is a real improvement over what is live, and it is safe to deploy. It is not the design. Worth deciding explicitly which of those two you are approving.

peterswimm referenced this issue 2026-09-09 23:33:05 +00:00

fix(converter): see grids, forms and link labels - 100% design copy captured #110

peterswimm referenced this issue 2026-09-10 17:04:11 +00:00

docs(review): final sign-off renders, every section from the vocabulary #115

peterswimm commented 2026-09-10 17:04:48 +00:00

Author

Owner

Copy link

Every design section now renders from the vocabulary

Images go live when #115 merges — they point at main deliberately, so
they never break the way the earlier sets did when their branch was deleted.

Rendered from main in both repos. Left is the approved canvas; right is what
toilville-fse + rituals-wp produce.

Home

Rituals

The full ritual demo now renders: window chrome, steward avatar, step 3 of 5
pill, five steps with correct markers and trailing meta, and the signed history
timeline.

Spelwork

Terminal with command/output tinting, and the console with its dark rail,
selected item, typed table columns and pulsing attestation dot.

News

Contact

---

What changed since the last set

Everything is now driven by the universal ForgeBlock vocabulary, with the
WordPress client deciding how each block looks. That was the correction Peter
called for: ritual blocks are universal, clients render them.

Copy reaching rendered HTML: 98% — Home and Rituals 100%, Spelwork 98%,
News 94%, Contact 92%. The remainder is contractions inside excerpts.

One thing I want on the record

The plan said to emit the demo's history as lineage_entry. I didn't, and
reverted that work. lineage_entry has a CI-enforced contract —
mode, consent_tier, hash, lineage_id, timestamp_ms all required. It
is a signed, tiered, identified provenance record. The design's history rows are
a depiction of provenance on a marketing page, carrying no lineage id and no
hash. Emitting them as lineage_entry would have meant inventing signing data
for a website, or relaxing a governance contract to fit a mockup.

It uses status for the steps (exactly the UDG enum, exactly the design's three
states) and fact_set for the history. No new vocabulary block was needed —
only status.meta, for the trailing detail, declared and type-checked.

Known gaps

• Product logos are dropped, deliberately. The design's lockups are
  ./rituals-logo.svg, relative to the deck template directory, which resolves
  to nothing once WordPress serves the pattern — and the files are not in the
  plugin's asset store. The client suppresses them with a comment rather than
  emitting a broken <img>. Closing it means shipping the five SVGs into
  blocks/_shared/assets/ and resolving them server-side.
• No nav or footer. They sat outside the five artboards in the canvas and
  were not split out. In WordPress they are parts/header.html and
  parts/footer.html in the theme.
• Rituals and News have no hero block, so those heroes render as core
  blocks. Visible above.

Deploying

Two pieces, plugin first — the theme's front-page.html composes blocks
that live in the plugin, so a theme-first deploy renders them as missing:

1. Deploy rituals-wp workflow (workflow_dispatch), target wordpress,
   activate true
2. rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/

Post-deploy: product-card, verdict-card and pipeline-stage all moved from
static-save to dynamic blocks. That is the safe direction — a dynamic block
re-renders instead of tripping "unexpected or invalid content" — but any page
already embedding one is worth opening once.

## Every design section now renders from the vocabulary > **Images go live when #115 merges** — they point at `main` deliberately, so > they never break the way the earlier sets did when their branch was deleted. Rendered from `main` in both repos. Left is the approved canvas; right is what `toilville-fse` + `rituals-wp` produce. ### Home  ### Rituals  The full ritual demo now renders: window chrome, steward avatar, `step 3 of 5` pill, five steps with correct markers and trailing meta, and the signed history timeline. ### Spelwork  Terminal with command/output tinting, and the console with its dark rail, selected item, typed table columns and pulsing attestation dot. ### News  ### Contact  --- ## What changed since the last set Everything is now driven by the **universal ForgeBlock vocabulary**, with the WordPress client deciding how each block looks. That was the correction Peter called for: ritual blocks are universal, clients render them. **Copy reaching rendered HTML: 98%** — Home and Rituals 100%, Spelwork 98%, News 94%, Contact 92%. The remainder is contractions inside excerpts. ### One thing I want on the record The plan said to emit the demo's history as `lineage_entry`. **I didn't, and reverted that work.** `lineage_entry` has a CI-enforced contract — `mode`, `consent_tier`, `hash`, `lineage_id`, `timestamp_ms` all required. It is a signed, tiered, identified provenance record. The design's history rows are a *depiction* of provenance on a marketing page, carrying no lineage id and no hash. Emitting them as `lineage_entry` would have meant inventing signing data for a website, or relaxing a governance contract to fit a mockup. It uses `status` for the steps (exactly the UDG enum, exactly the design's three states) and `fact_set` for the history. **No new vocabulary block was needed** — only `status.meta`, for the trailing detail, declared and type-checked. ### Known gaps - **Product logos are dropped, deliberately.** The design's lockups are `./rituals-logo.svg`, relative to the deck template directory, which resolves to nothing once WordPress serves the pattern — and the files are not in the plugin's asset store. The client suppresses them with a comment rather than emitting a broken `<img>`. Closing it means shipping the five SVGs into `blocks/_shared/assets/` and resolving them server-side. - **No nav or footer.** They sat outside the five artboards in the canvas and were not split out. In WordPress they are `parts/header.html` and `parts/footer.html` in the theme. - **Rituals and News have no hero block**, so those heroes render as core blocks. Visible above. ## Deploying Two pieces, **plugin first** — the theme's `front-page.html` composes blocks that live in the plugin, so a theme-first deploy renders them as missing: 1. `Deploy rituals-wp` workflow (`workflow_dispatch`), target `wordpress`, activate `true` 2. `rsync -av --exclude='.git' wp-themes/toilville-fse/ toilville-forge:/opt/spelwork/wordpress/themes/toilville-fse/` Post-deploy: `product-card`, `verdict-card` and `pipeline-stage` all moved from static-save to **dynamic** blocks. That is the safe direction — a dynamic block re-renders instead of tripping "unexpected or invalid content" — but any page already embedding one is worth opening once.

peterswimm commented 2026-09-11 19:36:37 +00:00

Author

Owner

Copy link

Sign-off renders — the fidelity round (full pages)

A correction first. The renders I posted earlier in this thread were cropped at 2600px and made with a preview that flattered production, so most of what was wrong below the fold never showed. They also still showed Home's product cards after a change of mine had broken them. This set is full-length, rendered the way WordPress will actually lay the pages out.

(Separately: every image earlier in this thread went 404 when its branch was deleted after merging. That's restored.)

Left is your canvas. Right is what ships, rendered from the open PRs.

Contact, after sending. The canvas shows both states at once. The site shows the form, then swaps in the confirmation:

What changed since the last set

• Home: the product cards are back. "Who we are" is one panel with the founder sidebar, and the Latest heading row sits inline. The closing band links to Contact; it had been an email signup form.
• Rituals: a product hero, and the closing band it didn't have.
• Spelwork: Spelwork blue throughout. The docs show small tags and sit four across, the figures are one dark panel, and the captions sit inside their bands.
• News: a hero, and single arrows (every link read "→ →").
• Contact: the band and card. "Message received." now appears only after sending; it had been showing to every visitor.
• Sitewide: every band is full width. The theme's 760px content column would have squeezed them all on the live site. DM Mono is self-hosted; the live site loaded it nowhere, so every mono label would have fallen back to Courier New.

Known differences — your call

• Spelwork: the terminal band is white where the canvas tints it blue, and the console band is warm where the canvas is white.
• Home "What we believe": white cards on the warm band, where the canvas has a darker mocha panel.
• News: the headline wraps onto two lines; the canvas has three.
• News and Home "Latest" show the canvas's sample posts as static content. Wiring them to real posts is a separate decision.
• Header and footer aren't in these renders, because the preview can't run WordPress's navigation and site-logo blocks. They're in the theme from #118.

To ship

Merge toilville_rituals #390, then the toilville-design branch feat/fidelity-round. The renders themselves are on docs/signoff-renders-2026-09-11. #123 and #379 are already in.

The two toilville-design PRs aren't open yet: Forgejo returns 500 Internal Server Error when creating a PR in this repo right now (three attempts each, including a docs-only one). Both branches are pushed and merge cleanly onto main; I'll open them once it recovers.

Deploy the rituals-wp plugin first (Deploy rituals-wp, target wordpress, activate), then the theme. Then create four pages with the slugs rituals, spelwork, news and contact. They can be empty; the theme's templates render them.

ville — does this read as your design?

## Sign-off renders — the fidelity round (full pages) **A correction first.** The renders I posted earlier in this thread were cropped at 2600px and made with a preview that flattered production, so most of what was wrong below the fold never showed. They also still showed Home's product cards after a change of mine had broken them. This set is full-length, rendered the way WordPress will actually lay the pages out. *(Separately: every image earlier in this thread went 404 when its branch was deleted after merging. That's restored.)* **Left is your canvas. Right is what ships**, rendered from the open PRs.      **Contact, after sending.** The canvas shows both states at once. The site shows the form, then swaps in the confirmation:  ### What changed since the last set - **Home:** the product cards are back. "Who we are" is one panel with the founder sidebar, and the Latest heading row sits inline. The closing band links to Contact; it had been an email signup form. - **Rituals:** a product hero, and the closing band it didn't have. - **Spelwork:** Spelwork blue throughout. The docs show small tags and sit four across, the figures are one dark panel, and the captions sit inside their bands. - **News:** a hero, and single arrows (every link read "→ →"). - **Contact:** the band and card. "Message received." now appears only after sending; it had been showing to every visitor. - **Sitewide:** every band is full width. The theme's 760px content column would have squeezed them all on the live site. DM Mono is self-hosted; the live site loaded it nowhere, so every mono label would have fallen back to Courier New. ### Known differences — your call - **Spelwork:** the terminal band is white where the canvas tints it blue, and the console band is warm where the canvas is white. - **Home "What we believe":** white cards on the warm band, where the canvas has a darker mocha panel. - **News:** the headline wraps onto two lines; the canvas has three. - **News and Home "Latest"** show the canvas's sample posts as static content. Wiring them to real posts is a separate decision. - **Header and footer** aren't in these renders, because the preview can't run WordPress's navigation and site-logo blocks. They're in the theme from #118. ### To ship Merge toilville_rituals #390, then the toilville-design branch `feat/fidelity-round`. The renders themselves are on `docs/signoff-renders-2026-09-11`. #123 and #379 are already in. *The two toilville-design PRs aren't open yet: Forgejo returns `500 Internal Server Error` when creating a PR in this repo right now (three attempts each, including a docs-only one). Both branches are pushed and merge cleanly onto `main`; I'll open them once it recovers.* Deploy the `rituals-wp` plugin first (`Deploy rituals-wp`, target `wordpress`, activate), then the theme. Then create four pages with the slugs `rituals`, `spelwork`, `news` and `contact`. They can be empty; the theme's templates render them. ville — does this read as your design?

peterswimm commented 2026-09-11 20:15:01 +00:00

Author

Owner

Copy link

Update — before/after, and one font decision

The mono face changed. DM Mono is gone. It was never a Toilville decision: it arrived in a bulk token expansion and spread from there. Peter chose the system monospace, which is SF Mono on Apple and Consolas on Windows. Every eyebrow, tag, breadcrumb and form label below uses it. The renders in my previous comment still show DM Mono; their layout is unchanged.

Before/after, three columns per page: your canvas, then what main ships today, then what the PR ships. The middle column is what deploying main as it stands would put on the site:

• every section squeezed into the theme's 760px column
• Home's product cards collapsed into a list
• an email field in Home's closing band
• Spelwork in terracotta

Where it stands

• Rituals side: toilville_rituals #391, the system mono in the blocks and the macOS app. The fidelity round, #390, is already merged.
• Design side: the toilville-design PR can't be opened yet. Forgejo returns 500 Internal Server Error for every PR creation in that repo, including a docs-only one. The branch is pushed and merges cleanly: feat/ship-the-pages. The renders are on docs/signoff-renders-2026-09-11.
• Merge order: #391, then feat/ship-the-pages.

The known differences listed in my previous comment still stand. They're yours to call.

## Update — before/after, and one font decision **The mono face changed.** DM Mono is gone. It was never a Toilville decision: it arrived in a bulk token expansion and spread from there. Peter chose the system monospace, which is SF Mono on Apple and Consolas on Windows. Every eyebrow, tag, breadcrumb and form label below uses it. The renders in my previous comment still show DM Mono; their layout is unchanged. **Before/after, three columns per page:** your canvas, then what `main` ships today, then what the PR ships. The middle column is what deploying `main` as it stands would put on the site: - every section squeezed into the theme's 760px column - Home's product cards collapsed into a list - an email field in Home's closing band - Spelwork in terracotta      ### Where it stands - **Rituals side:** toilville_rituals #391, the system mono in the blocks and the macOS app. The fidelity round, #390, is already merged. - **Design side:** the toilville-design PR **can't be opened yet**. Forgejo returns `500 Internal Server Error` for every PR creation in that repo, including a docs-only one. The branch is pushed and merges cleanly: [`feat/ship-the-pages`](https://git.toilville.dev/Toilville/toilville-design/compare/main...feat/ship-the-pages). The renders are on [`docs/signoff-renders-2026-09-11`](https://git.toilville.dev/Toilville/toilville-design/compare/main...docs/signoff-renders-2026-09-11). - **Merge order:** #391, then `feat/ship-the-pages`. The known differences listed in my previous comment still stand. They're yours to call.

peterswimm referenced this issue 2026-09-11 20:36:21 +00:00

docs(review): before/after and sign-off renders for the site PRs #127

peterswimm commented 2026-09-11 20:37:03 +00:00

Author

Owner

Copy link

The design PRs are open: toilville-design #126 (the pages, and the system mono) and #127 (these renders). toilville_rituals #391 is merged, so #126 is the last merge before deploy.

The 500 was a stale lock left on the server's copy of this repo by an interrupted git write. It's cleared; nothing else was affected.

**The design PRs are open:** toilville-design #126 (the pages, and the system mono) and #127 (these renders). toilville_rituals #391 is merged, so #126 is the last merge before deploy. The `500` was a stale lock left on the server's copy of this repo by an interrupted git write. It's cleared; nothing else was affected.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels   

priority

P1

Urgent — no working icon yet (custom art pending) or a shipping asset

  

priority

P2

High — has an accessible stand-in; bespoke art wanted

  

priority

P3

Medium — stage visual headers

  

priority

P4

Low — behavioral dimension family

  

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

help wanted

Need some help

  

invalid

Something is wrong

  

question

More information is needed

  

wontfix

This won't be fixed

No labels

priority

P1

priority

P2

priority

P3

priority

P4

bug

duplicate

enhancement

help wanted

invalid

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

ville

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Toilville/toilville-design#102

No description provided.