Null's instruction, 2026-09-10. The number itself is confirmed and stays
everywhere it appears. What comes off is the claim wrapped around it in three
places, each of which asserted an outcome over that time rather than experience:
index.html:12 meta description "25+ years of proven reliability."
index.html:15 og:description "25+ years of proven reliability."
Home.jsx:97 the home description "...and networking. 25+ years."
All three now read "25+ years of industry experience", which is what the rest of
the site already said: the home trust chip ("25+ Years Experience"), the About
stat ("Communications and infrastructure experience"), the contact page ("25+
years of experience") and the footer.
Two nearby claims were left alone as different in kind, and are worth a second
look if the intent was broader: Contact.jsx:179 "8x8 Certified Partner with
proven expertise", which is about a partnership rather than a track record, and
About.jsx:83 "technology that works - proven, stable, and repeatable", which is
about the technology rather than the customers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The work this batch exists for. Levi Halford approved two copy sheets on
2026-08-28 and sent them the same day; they were never deployed. Closes#220,
#219 and #218.
What ships, verbatim from the sheets:
/services/unified-communications 1,125 words, 10 sections, 7 FAQs
/services/contact-center 2,499 words, 12 sections, 10 FAQs
Titles, H1s, hero subheadings and descriptions are the approved strings exactly,
including descriptions at 164 and 191 characters, which are emitted whole rather
than clamped. Each section opens with its direct answer, because that passage is
what a search result or an AI answer quotes. Every section carries a stable,
letter-first anchor, so an answer can deep-link to it. The FAQ is visible h3 and
p, with no FAQPage markup, as the sheets require.
The old copy goes: the unattributed "99.999% uptime reliability" the sheet named,
and both pages' short blurbs, which the approved sections now say at length.
idealFor stays, because the services index prints it as "Best fit".
Levi's two constraints are held and proven, not assumed. The footer is byte for
byte identical to the pre-batch build on all 19 pages. The Quick Info box is on
both pages, unchanged.
Verified against the built HTML, not the source: title, description and H1 match
the sheets exactly; all 22 approved H2s and all 17 FAQ questions are present; no
website-manager direction survived (checked against 20 phrases); no 99.999, no em
dash, no U+FFFD, no markdown. In a browser: no horizontal scroll, no broken
image, no console error at 320, 390, 768 and 1024; hydration clean on all 18
pages; all 24 section anchors deep-link correctly.
Docs corrected in the same commit, because each would have sent the next writer
the wrong way: REDESIGN_REVIEW's metrics lists now carry the owner's 2026-09-10
direction that a figure must be current, vendor-attributed and verified;
OVERHAUL_PLAN gains the long-form blueprint and stops recommending an accordion
for an FAQ; README stops claiming a server-rendered privacy fallback that never
existed, and says what hydration actually does now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both approved sheets ask for it: Unified Communications section 15 and Contact
Center section 18 each list the pages that should link back to them. Home, the
services index, the header and the footer already did. Managed Support and the
four industry pages did not, and the industry pages linked to no service at all.
Each industry page's own description already tells the reader Queue North
"delivers phone, contact center, network, and IT support" for that industry, so
all four qualify. The anchors are descriptive rather than the page names:
"Business phone and UCaaS solutions" and "Contact center and CCaaS solutions".
Rendered through the shared RelatedLinks component, in the industry sidebar card
and after "Ideal For" on a service page. It renders nothing without links, so
the five service pages that have none are untouched: only 5 of the 18 pages gain
a Related services block, and they are exactly the five the sheets name.
Verified against the build: both hrefs are present on managed-support and on all
four industry pages, the built-HTML audit passes with every link and fragment
resolving, and no other page gained the block.
Closes#221.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The privacy policy held the site's only block renderer, and the two approved
service pages need the same vocabulary plus ordered steps, a figure and a link
list. Two renderers would have drifted, so there is one:
src/components/content/ContentBlocks.jsx, with p (including inline links), h3,
ul, ol (a step, optionally with its explanation), callout, image and links.
The old renderer sent an unknown block type to its paragraph case, which
rendered an empty <p>. A misspelt type silently dropped a paragraph of copy and
nothing said a word. The shared one throws, and the prerender turns that into a
build failure naming the route, the section and the block index.
PrivacyPolicy passes in the two block types only a policy has, email and
contactBlock, rather than forking the renderer. That page is the one an ad
platform must be able to read, so its markup had to be untouched: the renderer
was written to emit exactly what the page emitted before, prop order included.
Proven: dist/privacy-policy/index.html is byte for byte identical before and
after, 82,392 bytes either way, with asset hashes normalised. And a block type
misspelt as 'emial' fails the build with "prerender: /privacy-policy could not
be rendered: content: section "marketing", block 3: unknown block type".
RelatedLinks is the second shared piece, for the links the sheets ask each page
to carry. It renders nothing when a page has no links, so the pages that have
none are unchanged.
Closes#229.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Live until now, on every service and industry page:
"...seamless integration Delivered by Queue North, a veteran-owned..."
"...for medical providers Queue North delivers phone, contact center..."
clampDescription joined its fragments with a space, and no shortDesc in
services.js or industries.js ends in a full stop. Nothing added one. The
description is the first thing a searcher reads, and it read as a run-on on
eleven of the eighteen pages.
buildDescription replaces it and joins fragments AS SENTENCES. It also takes an
`approved` description, which it emits verbatim: never joined, never clamped.
Levi's approved copy for the two long-form pages is 164 and 191 characters, and
the old 158-character clamp would have cut his sentences off with an ellipsis.
ServiceDetail reads it from `page.seo`, which the content commit fills in.
ServiceDetail and IndustryDetail now build their canonical from SITE_URL rather
than repeating the origin. The three files release.sh greps for that literal are
untouched, so the origin guard still has three copies to compare.
Verified against a build, page by page: all 11 detail descriptions gained
exactly a full stop and changed in no other way, and no other page's description
moved.
Closes#234.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Null's direction of 2026-09-10. Punctuation only: not one word changed.
Nine of them, and the share-image alt text was on every page twice:
src/components/SEO.jsx:4 the default og:image and twitter:image alt
index.html:25,:31 the same string, as template fallbacks
src/pages/Home.jsx:257,:290
src/pages/Services.jsx:99
src/pages/Contact.jsx:183
src/data/services.js:120 the wireless card on Home and the index
public/site.webmanifest:4 linked from every page
Thirteen more sit in code comments and reach no page, so they stay. The hours
range on /contact uses en dashes, which are a different character and are not
what was asked about.
This lands before the guards that reject an em dash in content or in built
HTML, because until now every built page carried one and those guards would
have gone red on arrival.
Verified against the build, not the source: no U+2014 in any file under dist/,
including the HTML, the webmanifest, the sitemap and the JS bundle.
Closes#222.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Batch 10, and only three of its six issues were real. The other three are
answered on the tracker with the arithmetic.
#189 — focus indicator. Footer and Home carried zero focus styling across 17
links. Added one global :focus-visible rule rather than sprinkling classes,
because the issue's own scope was "all interactive <a> and <Link> elements".
Not the ring the issue asked for. It suggested ring-primary-cyan; #22D3EE is
6.26:1 on navy and 2.38:1 on white, so on this light-first design that ring
would have failed WCAG 1.4.11 across most of the site. Two rings instead — white
inside, navy outside — so the white carries the dark bands and the navy carries
the light sections. Worst case across every background in the palette is
13.62:1. box-shadow so both rings follow each element's own border-radius, plus
a transparent outline for forced-colors mode.
#192 — aria-expanded={isOpen} and aria-controls on the mobile nav trigger, and
the id on SheetContent it now points at. Confirmed as "false" in the
prerendered HTML.
#193 — INVERTED. The issue asked for aria-labels to be added consistently to
hero CTAs. The aria-labels already there were WCAG 2.5.3 Label in Name failures,
Level A: "Schedule a consultation" is not a superset of the visible "Schedule
Consultation", so a voice-control user saying what they see cannot activate the
link. Doing what the issue asked would have spread a Level A failure. Removed
the six that broke it; kept the eight that genuinely add context and do contain
their visible text, including the icon-only header logo link that needs one.
Audit now reports 0 failures across Home, Services, Footer and Header.
Verified: npm run build; the ring is in the built CSS, aria-expanded="false" and
id="mobile-nav-content" are in the prerendered HTML, all six removed labels are
absent from it, and the visible CTA text still renders.
NOT verified: nothing has been walked keyboard-only in a browser, and no screen
reader has been used. That gap is recorded in docs/qa/ClaudeQACoverage.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Client directive (Levi Halford, 2026-08-01) ahead of Google/Meta lead forms.
Privacy policy:
- Publish approved policy verbatim at /privacy-policy (src/data/privacyPolicy.js
is the single source of truth; 292/292 source lines verified present)
- Privacy Policy link in the footer of every page
- Effective/Last Updated 2026-07-31, privacy@queuenorth.com as mailto
Remove St. Petersburg street address from every surface named in the brief:
footer, contact page, schema markup, SEO metadata, Google Maps links. Collapse
ProfessionalService + Organization schema into a single Organization with
areaServed: United States; drop geo coordinates, priceRange, openingHours.
Add the approved US-coverage sentence to About. No replacement address.
Crawler visibility (the site previously served 0 bytes of body HTML without JS):
- Prerender all 19 routes at build time via src/entry-server.jsx + scripts/prerender.js
- Hoist title/meta/canonical/JSON-LD into <head>; renderToString does not do this
and react-helmet-async's context is empty under React 19
- Serve prerendered HTML; return a real 404 for unknown paths instead of 200
- Hydrate instead of discarding the prerendered markup
SEO/perf:
- Titles <=60 and descriptions <=160 chars across all pages
- Add BreadcrumbList to interior pages, WebSite to home
- Generate sitemap.xml from the route list with git-derived lastmod
- 301 duplicate URL forms (trailing slash, //, /index.html), preserving query
- Immutable caching for content-hashed assets; no-cache for HTML
- Split the 522 KB bundle into app/react-vendor/router/icons
- loading/decoding/fetchpriority + per-route hero preload; drop unused asset
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
null