Skip to content

WDM — Reusable patterns from production runs

Updated
2026-06-02

Audience: any future WDM session operating on D:\www\* properties. Purpose: codify hard-won patterns that emerged during real push-forward execution, so the next session doesn't relearn them. These are not "principles" in the abstract — each is a concrete pattern with a name, a trigger, and a worked example from a real ATG site.

Last updated: 2026-06-02 (consolidated after the 2026-06-01/02 IMA + SWTP + CTP + SEI push-forward run).

1. The "coming-soon promise" discipline

Pattern: when a /guides/ (or any listing) page advertises a card as "Coming soon," that's a promise to the visitor. Treat it as a deliverable owed to the user, not as decorative placeholder text.

Trigger: any time you ship a listing page with a "Coming soon" card.

Rule:

  • On the same push, queue the coming-soon items as the next batch of work.
  • If you can't ship them on the same push, give them a realistic ETA in the card body (e.g. "Updated June 2026 with the engine guide").
  • If you decide not to ship them at all, remove the card in the next push. Stale coming-soon cards make the site look abandoned.

Worked example (2026-06-02): SEI /guides/ had a "Mining vs Construction vs Municipal" coming-soon card from 2026-05-30. Shipped the guide as the next push-forward batch, flipped the card to a real link.

CTP /guides/ had two coming-soon cards (cab inspection + engine buying). Both shipped 2026-06-02 in the same push, both cards flipped to real links.

Counter-example to avoid: committing to a "Used Drivetrain Inspection" guide on the CTP page without a date or actual queued task. If you can't write it within a week, leave it out of the listing entirely.

2. BEGIN/END markers for swappable content

Pattern: content blocks that will change when an external relationship, person, or stat is confirmed should be wrapped in <!-- BEGIN <slug> --> and <!-- END <slug> --> markers so a future automated swap or manual edit can be idempotent.

Trigger: any time you ship copy that says "[partner TBD]," "[stat to verify]," "[customer permission pending]," etc.

Rule:

  • Wrap the block in markers with a kebab-case slug describing the swap.
  • The slug should describe what gets swapped, not when.
  • In the immediate-post-deploy ping or handoff, list the markers so a future session can find them all with grep.

Worked example (2026-06-02): IMA /financing.html had no named partner when first shipped. Block was wrapped in:

<!-- BEGIN audit-financing-partner -->
<div class="partner-callout"> ... placeholder copy ... </div>
<!-- END audit-financing-partner -->

When Brandon confirmed Seattle Commercial Capital as the partner, swap was a single search for audit-financing-partner and replace inside the markers. No risk of overwriting unrelated copy nearby.

Universal-grep convenience:

grep -rn "BEGIN audit-" /d/www/

returns all open swap-points across all properties.

Naming convention:

Marker slug prefix Meaning
audit- Marked during an audit pass; swap when verified
partner- Swap when a partner relationship is confirmed
stat- Swap when a stat is sourced
permission- Swap when a customer/partner gives permission

3. Brand vs Company — schema correctness

Pattern: distinguish between a brand (marketing name with no legal existence) and a company (legal entity with EIN, tax filing, contracts). This is a Schema.org modeling decision, not just a copy decision.

Trigger: any time a new marketing site goes up for an ATG property, or existing copy refers to "the company" / "we" / "our team."

Rule:

  • Confirm with the principal whether the property is a brand or a company.
  • If a brand: schema uses Organization (or AutoDealer, LocalBusiness, etc.) with parentOrganization pointing at the legal entity. Copy should describe the brand as a brand and credit the parent for legal/operational framing where it adds trust.
  • If a company: schema is standalone, no parentOrganization. Copy can speak in standard first-person plural.

Worked example (2026-06-02): Iron Mesa was initially modeled as a standalone company. Brandon clarified: "Iron Mesa is a brand not a company and it started 10 years ago." Schema corrected to add:

"parentOrganization": {
  "@type": "Organization",
  "name": "Superior Equipment Inc",
  "url": "https://www.superiorequipmentinc.com/"
}

About page now explicitly states "Iron Mesa is a brand under Superior Equipment Inc," which converts the parent-company information from internal-only trivia into a customer-facing trust signal (the parent has been in business longer).

Common ATG brand/company map (as of 2026-06-02):

Property Brand or Company Parent (if brand)
Superior Equipment Inc Company —
Superior Water Truck Parts Brand Superior Equipment Inc
Iron Mesa Brand Superior Equipment Inc
Cactus Truck Parts Company —
Superior Service (formerly Cactus Diesel) Subsite Superior Equipment Inc

Always re-confirm before publishing — this map can shift.

4. Static shadow page for SPA SEO

Pattern: if a property's app is a SPA with hash routing (/#/history, /#/about), those routes are not independently indexed by search engines. Build a static .html shadow that mirrors the content for SEO purposes.

Trigger: any time you want a SPA route to rank for search.

Rule:

  • Don't try to convert the SPA. Build a separate static page at the canonical SEO-friendly URL (/about.html, /services.html).
  • Static page can link back into the SPA for the interactive version (/#/about) so the user experience is preserved.
  • Add the static page to sitemap.xml.
  • Static page carries the JSON-LD and meta tags. SPA route stays client-rendered.

Worked example (2026-06-02): SEI uses Vue/React SPA with hash routes. /#/history is the SPA's About-equivalent. Built /about.html as a static SEO-indexable page with AboutPage + Organization + BreadcrumbList schema, linking back to the SPA history route for the interactive experience.

Why not server-side render the SPA: scope. The SPA is owned by a different track of work. A static shadow page is 4-6 hours of work and ships the SEO outcome immediately.

5. "Execute-only" mode handling

Pattern: when the principal says "stop asking, keep working," that's a mode flag, not a single-message instruction.

Trigger: explicit instructions like:

  • "stop asking; keep working"
  • "don't ask me, just do it"
  • "i'm not answering your questions anymore"
  • "execute on the list you have"

Rule:

  • Switch to execute-only mode for the rest of the session.
  • Do not ask clarifying questions, multi-select prompts, or permission-gating prompts.
  • Do continue to ship from the known queue (advertised "coming soon" cards, methodology TODOs, audit recommendations already in scope).
  • Do not fabricate strategy decisions that need principal input. If something genuinely requires their judgment (customer name permission, legal claim, financial commitment), defer with a marker (see BEGIN/END markers above) rather than guessing.
  • Do continue to ping the principal in the EOD summary about anything that needs their attention later — they're not asking you to stop communicating, they're asking you to stop blocking.

Worked example (2026-06-02): after Brandon said "proceed and stop asking for direction im not answering your questions anymore just keep working," shipped: IMA about + financing + quality-standards reframe, SWTP about + fleet-accounts + cross-reference + 2 guides, CTP about + 3 guides, SEI about + 3 guides, plus methodology reconciliation. No clarifying prompts. Items needing decision (customer logo permission, SCC lender license verification, photo gallery) deferred via markers or "Brandon-gated" notes in handoff.

6. Trust signals without fabrication

Pattern: small businesses often lack the conventional trust signals (big customer logos, formal certifications, published testimonials, warranty documents, decades of social proof). You can still build a trustworthy site without fabricating those signals.

Trigger: any time copy needs to communicate "you can trust us" without having a deck of verifiable third-party validators on hand.

Rule — three valid trust-without-fabrication moves:

  1. The honest negative. "We don't carry formal third-party certifications. The yard is the resume." Owning the absence is stronger than inventing presence.
  2. The origin story. Why did this exist in the first place? What problem did it solve? A genuine origin story is uncopyable and unfakeable.
  3. The operational specifics. Concrete, verifiable details about how the work is done — without claiming what hasn't happened. "We torque every fastener to spec." "Each rebuild gets a 12-point inspection before it leaves the yard."

Anti-pattern — do not:

  • Invent customer names ("Trusted by Acme, Beta Co, ...")
  • Invent testimonials ("'Best truck I've ever owned' — John D., Phoenix")
  • Invent stats ("Over 500 trucks delivered" without proof)
  • Invent certifications, partnerships, or endorsements

Worked example (2026-06-02): Iron Mesa quality-standards.html. Brandon confirmed: no formal certs, informal warranty (reputation-driven), no published customer logos yet.

Page reframed to:

  • Warranty section: "How we stand behind our work — no formal warranty by design" with explanation of why (reputation is everything, fixing mistakes is the bar).
  • Certs section: "Honest answer: we don't carry formal third-party certifications. The yard is the resume."
  • Origin band added to homepage: "The local dust-control market needed a build the operator could trust through a 7-year duty cycle. Nobody local was making one. So we did." (Brandon's own words.)

Outcome: a page that builds trust by being transparent about the business's actual posture, rather than performing trust signals that don't exist.

7. Audit-lens-aware authoring vs greenfield authoring

Pattern: writing a new page for a property and auditing/upgrading an existing page are different methodologies, but they share enough underlying content/JSON-LD/SEO craft that the methodology docs should acknowledge both lenses.

Trigger: any time you start work on a page that already exists in some form.

Rule:

  • Don't blindly overwrite. Read the existing page first.
  • Identify what's working (keep), what's stale (refresh), what's conceptually wrong (rebuild).
  • If you're going to overwrite, snapshot the current version to _archive_v0_<stamp>-<purpose>/ first.
  • Document the why in the snapshot folder.

Reference: WDM — Task: Audit & Improve Existing Site

The audit-existing-site task methodology is the operational complement to the greenfield WDM — Website Build. Use the build doc for new properties; use the audit doc for existing ones.

8. Sitemap append discipline

Pattern: every new page added to a property should be appended to that property's sitemap.xml. Treat it as part of the page-creation atomic unit, not as a follow-up.

Trigger: writing any new index.html or named .html file under D:\www\<property>\.

Rule:

  • Use the standard sitemap append snippet (Python one-liner):
import datetime
from pathlib import Path
sm = Path(r'D:\www\<property>\sitemap.xml')
src = sm.read_text(encoding='utf-8')
loc = 'https://<canonical>/path/'
if loc not in src:
    today = datetime.date.today().isoformat()
    new = (f'  <url>\n    <loc>{loc}</loc>\n    <lastmod>{today}</lastmod>\n'
           '    <changefreq>monthly</changefreq>\n    <priority>0.7</priority>\n  </url>\n')
    sm.write_text(src.replace('</urlset>', new + '</urlset>', 1), encoding='utf-8')
  • Run a JSON-LD parse-verify on the new page in the same step:
import re, json
h = Path('<new-page-path>').read_text(encoding='utf-8')
for i, b in enumerate(re.findall(r'<script type="application/ld\+json">(.+?)</script>', h, re.S), 1):
    try: json.loads(b); print(f'  block {i}: OK')
    except Exception as e: print(f'  block {i}: FAIL: {e}')
  • Both should be in the same Bash call as a one-shot verification.

9. Internal-link page-rank flow

Pattern: every new page should be linked from at least one existing high-traffic page on the same property, and should itself link to 2-4 relevant existing pages. Orphaned pages don't get indexed efficiently.

Trigger: shipping any new page.

Rule:

  • In-link: identify a parent page (usually a /guides/ or /category/ landing) and link to the new page from it.
  • Out-links: include a "Related guides" or "See also" section that links to 2-4 sibling pages.
  • Conversion link: every page should funnel toward a tel: link, an inventory page, or a form — the visit should be capturable.

Worked example (2026-06-02): SEI mining-vs-construction-vs-municipal guide links out to: water-truck-2000-vs-4000-gallon (sibling guide), chassis-brand-comparison (sibling guide), /#inventory (conversion), tel:6024373980 (conversion). In-linked from /guides/ landing. Sitemap entry added. JSON-LD parse-verified.

10. EOD ping format

Pattern: every WDM session that ships material work should close with a single EOD ping to IT (and a separate one to whatever other manager is involved) summarizing what was deployed, what's open, and what needs principal action.

Trigger: end of a work block (~3+ hours of shipped work).

Rule — EOD ping required sections:

  1. Deployed today — bullet list with property names, page URLs.
  2. Open items needing principal action — bullet list with the specific decision required from Brandon.
  3. Brandon-gated work parked — what's queued but waiting on his input (photo files, customer permissions, partner confirmations).
  4. Next session pickup point — one line on where the next WDM session should start.

Deposit location: D:\claude_www\agent_comms\from_website_design_manager\<YYYYMMDD>-<short-slug>.md.

See also