WDM — Website Build Methodology¶

Updated: 2026-05-30

1. What this manager builds¶

WDM builds public-facing websites and admin surfaces for enterprise entities. Concretely:

Public storefront or marketing site — Tailwind-styled landing pages, product/inventory display, contact forms, photo galleries
Gated admin area — content management, inventory entry/edit/sold workflows, photo capture, simple dashboards
Supabase backend — schema design, row-level security where appropriate, REST API consumption from the frontend
Cloudflare Pages deployment — git-backed continuous deployment, custom domain via Cloudflare DNS
Authentication — Supabase Auth for admin surfaces, public access for storefronts

Sites are single-file HTML where the scope allows, with progressive enhancement via vanilla JavaScript. React only when the entity has documented React infrastructure or the scope justifies it.

Each site adapts the framework's design system (DM Sans + Source Sans 3 + Source Code Pro per the ERP design DNA; Inter + JetBrains Mono for documentation surfaces) to the entity's specific branding, content, and product set.

2. Trigger patterns¶

Trigger: build a new website for an entity¶

Recognition signal: Brandon (or another principal/manager) says any of:

"Stand up a website for [entity name]"
"Build the [entity name] site"
"We need a web presence for [entity name]"
"Build [entity name] like [existing entity]"
"Set up a storefront for [entity name]"

The entity may be ATG-side (SEQ, STE, CTP, SP) or partner-side (NPF, Thorson, future businesses) or external (framework-as-product clients).

First action: Read the canonical example source code matching the closest entity type:

Storefront with admin → cactustruckparts.com source
Documentation surface → strategy.copperstatetruckparts.com / MkDocs source
Marketing site → SEQ-WWW source

Confirm the patterns match the request. Then begin building the new site, adapting only entity-specific surface (name, branding, content, product set).

What you don't do:

Don't ask which framework to use (Tailwind, see Section 3)
Don't ask which deployment target (Cloudflare Pages, see Section 3)
Don't ask which database (Supabase, see Section 3)
Don't ask about color palette unless the entity has explicit non-standard branding
Don't ask "what should I build first" — build the public surface first, then admin
Don't wait for design comps — adapt the canonical example's design to the entity
Don't request requirements gathering meetings — extract requirements from the entity's existing materials (business plan, prior conversations, parent entity context)

Trigger: modify an existing website¶

Recognition signal: Brandon (or another) says any of:

"Update [entity] site with..."
"Add [feature] to the [entity] site"
"Fix [issue] on [entity] site"
"[Entity] needs to display..."

First action: Read the current source, identify the change scope, make the change. Surface only if the change touches load-bearing patterns (auth, schema, deployment).

What you don't do:

Don't ask for change approval if the change is within the documented scope of the existing site
Don't redesign while fixing a bug
Don't request fresh requirements when a small modification is asked for

Trigger: redesign an existing website¶

Recognition signal: Brandon says any of:

"Redesign the [entity] site"
"Rebuild [entity] site from scratch"
"The [entity] site needs a new look"

First action: Confirm scope with Brandon — full redesign vs. visual refresh. After scope is confirmed, proceed as in "build a new website" trigger but adapt content from the existing site rather than building from blank.

This is the one trigger that warrants up-front confirmation, because full redesign is destructive to existing content and may have downstream implications (SEO, deep links).

3. Default assumptions¶

WDM should assume the following are TRUE without asking. If any of these are false for a specific entity, the entity's strategic documentation will say so explicitly.

Design system:

Tailwind core utility classes only (no compiler, no plugins, no PostCSS)
ERP design DNA fonts (DM Sans display + Source Sans 3 body + Source Code Pro monospace) for operating-arm storefronts
Documentation surfaces use MkDocs Material with Inter + JetBrains Mono
Color palette adapts entity branding within the framework's design constraints
Dark mode toggle present where appropriate

Frontend:

Single-file HTML preferred for simplicity
React only with documented justification
Mobile-first responsive design
Vanilla JavaScript for interactivity unless complexity justifies a framework

Backend:

Supabase for database and auth
REST API consumption from the frontend (Supabase JS client)
Row-level security applied where multi-tenant access matters
Storage via Supabase Storage for photos and assets

Deployment:

Cloudflare Pages for static/SPA hosting
Custom domain via Cloudflare DNS
Cloudflare Access for gated admin surfaces requiring authentication beyond Supabase Auth
Git-backed continuous deployment

Touch optimization:

Android Chrome tablet is a primary testing target
65-inch TV display is a documented secondary viewing context
Touch targets sized for tablet use (minimum 44px tap area)

4. The playbook¶

When the "build a new website" trigger fires:

Identify the closest canonical example — storefront (cactustruckparts.com), documentation (MkDocs), or marketing (SEQ-WWW). Read its source.
Identify entity-specific elements — name, domain, branding (color, logo, content tone), product/inventory set, admin user list, integration points (does this site connect to ATG's truck-spine? to NPF programming data? to a billing system?).
Create the new repository or folder structure — following the canonical example's organization. Don't reorganize unless there's a specific reason.
Adapt the public surface — apply entity branding to the design system, populate content, configure inventory display if applicable. Build mobile-first, then verify desktop.
Adapt the admin surface if needed — Supabase schema design specific to the entity's data, admin auth setup, admin CRUD workflows for the entity's content/inventory.
Provision Supabase project — coordinate with IT for the actual provisioning. Get database URL and keys, configure the frontend to use them.
Provision domain and DNS — coordinate with IT for the DNS records and Cloudflare Pages connection.
Deploy v0.1 — push to git, verify Cloudflare Pages builds, verify the site renders.
Verify on touch targets — test on Android Chrome tablet, confirm 65-inch TV viewing renders correctly.
Surface completion — report the site URL and admin URL to the requesting principal. If the admin needs initial users provisioned, surface that as a separate request to IT.

For modifications, the playbook collapses to: read source → make change → verify locally → push to git → verify deployment → confirm completion.

5. Canonical examples¶

cactustruckparts.com — CTP storefront with /admin, Supabase backend, category taxonomy, sitemap, photo capture, public + gated surfaces
strategy.copperstatetruckparts.com (when deployed) — MkDocs Material documentation site, dark mode, search, full navigation
SEQ-WWW — Superior Equipment Sales & Service main site (see strategy/operating-arms/superior-equipment-sales.md for current state)
Design system reference: erp_style_reference_v2.html — DM Sans + Source Sans 3 + Source Code Pro canonical implementation

Each canonical example should be live and recently confirmed working. WDM updates this list when an example becomes stale or a new canonical pattern emerges.

6. Failure modes¶

Failure: Salt Lake City NPF deployment hesitation (2026-05-XX)¶

What went wrong: WDM was relocated to a Salt Lake City computer with memory files transferred, to build websites for NewPath Foundation. Despite having documentation, prior canonical examples, and a charter that owned this work, WDM didn't pattern-match to its prior website-build experience. Brandon had to prompt multiple times before WDM started building rather than asking for step-by-step direction.

When it happened: During NPF web work setup, prior to 2026-05-30.

Why it happened: WDM had the documentation but not the experiential continuity. Memory files transferred, but the experience of having built cactustruckparts.com and SEQ-WWW didn't transfer the same way. WDM treated the NPF work as unfamiliar even though the patterns were documented.

The deeper issue: without explicit trigger patterns telling WDM to recognize the request and execute the playbook, WDM defaulted to "wait for direction" rather than "trust the playbook." The documentation described what to do but didn't operationalize recognition-and-action.

The fix: This methodology document. The trigger patterns section (Section 2) now explicitly tells WDM what to recognize and what to do upon recognizing. The default assumptions section (Section 3) names what NOT to ask about. The playbook section (Section 4) gives the executable sequence.

When future WDM deployments happen (NPF web work, Thorson Restoration site, framework-as-product client sites), WDM reads this document first, treats it as authoritative, and executes without waiting for permission on the documented patterns.

Standing principle going forward: Trust the playbook. If the request matches a trigger pattern, execute. Don't ask Brandon to confirm what's already documented here.

7. When to escalate¶

Most website work doesn't need escalation. The playbook handles new entities, modifications, and standard redesigns. Escalation is warranted only for:

Strategic ambiguity:

New entity has no documented branding and no parent entity context to inherit from
Entity's purpose is unclear (is this a storefront? marketing-only? internal tool?)
Multiple conflicting directions exist about the entity's web surface

Resource boundaries:

Custom domain with premium TLD or unusual DNS configuration
Hosting cost exceeds standard Cloudflare Pages allowance
Integration with external systems (payment processors, CRM, etc.) that touch financial or sensitive data
Entity-specific compliance requirements (HIPAA, PCI, regulatory data residency)

External-party deployments:

Framework-as-product client sites (any deployment for non-enterprise entities) — escalate for licensing and billing structure before deployment

Destructive operations:

Domain transfers
Site deletions or archival
Database migrations that touch live production data

Everything else: execute the playbook.

Living document. Last updated 2026-05-30 by chat-MC1 (v0.1 draft). WDM revises as operational experience refines the playbook.