SlopGuard · Run 001 — hexento.com (productization, pre-deploy)

SG-001

trust-killer claim-code-contradiction 1/4 lenses

The report link is sold as private and unguessable, but anyone rescanning the same domain is handed it.

The homepage's own terms say a second scan of the same domain inside the 24-hour window returns the existing report instead of a new run, and scan.js redirects any such requester straight to reportPath on the domain_rate_reuse code. So the 'private to you' link is actually handed to any visitor — colleague, competitor, or stranger who ticks the ownership checkbox — who types the same domain within 24 hours.

claim — apex/privacy/index.html:63

The report lives at a private, unguessable link and is <strong>kept for about 24 hours, then deleted</strong>.

ships — apex/index.html:129

If a complete report for that domain is still in the 24-hour window, you get that report back rather than a new run.

A buyer weighing whether to point this tool at their unlaunched site reads 'private, unguessable' and then, two sections later, learns privacy depends on nobody else scanning their domain that day. That is exactly the claim-vs-shipped-behavior gap this product claims to catch.

fix — Reconcile the reuse path with the privacy promise: either gate the domain_rate_reuse redirect so only the original requester (e.g. matched against the browser's slopguard:lastScan record) receives the existing report, or rewrite privacy/index.html:63 and the status page's 'private to you' copy to state that a same-domain rescan within 24 hours receives the same report.

restructure

SG-002

embarrassing claim-code-contradiction 3/4 lenses

Privacy page says analytics send event names and page URLs only, but events ship extra properties.

scan.js attaches a source property ('home_form'/'scan_form') and the queue page attaches a method property ('mailto'/'copy') to tool_start events. The data is benign, but the privacy page's literal 'names and page URLs only' claim is false as written.

claim — apex/privacy/index.html:58

Event names and page URLs only. Never email addresses or anything from a scanned site.

ships — apex/scan.js:75

track('tool_start', { source: form.getAttribute('data-source') || 'scan_form' });

A skeptical buyer who opens devtools — the exact reader this site courts — sees event payloads the privacy page says don't exist. For a company selling claim-vs-behavior audits, being caught understating its own telemetry on the privacy page is disqualifying-adjacent.

fix — Rewrite privacy/index.html:58 to disclose the event properties — e.g. 'Event names, page URLs, and a coarse interaction label (which form or button) only.' — or strip the source/method props from the tool_start track calls in scan.js and the queue page.

this line

SG-003

embarrassing other 2/4 lenses

The site never says whether the "four reviewers" are humans or AI

The homepage lede, the method page ("Four lenses"), and the status page ("Four reviewers are reading your site cold", status-page.js line 122) all personify the reviewers, but no page plainly states this is an automated AI pipeline. A scan that finishes in "a few minutes" clearly isn't four humans, so the copy reads as coy.

claim — apex/index.html:57

Four reviewers read your live pages. A fifth pass tries to kill every finding against the quoted text.

ships — apex/method/index.html:67

Exact-match passes run first: crawl errors, placeholder hrefs, draft remnants, head-metadata gaps, duplicate titles. No model involved.

A skeptical buyer deciding whether to trust a scan tool notices the evasion immediately: if you won't say what's doing the reviewing, what else are you fuzzing? One plain sentence ("four AI review passes") would remove the doubt.

fix — Search for the personifications 'Four reviewers' (apex/index.html:57, status-page.js HEAD.analyzing) and 'Four lenses' (method) and state plainly once per page that the reviewers are AI passes, e.g. 'Four AI reviewers read your live pages.'

sweep all instances

SG-004

embarrassing unverifiable-accountability 1/4 lenses

The benchmark section makes precise claims with zero receipts, violating the site's own core rule

The "Standing benchmark" gives exact numbers (21 of 21, 0 of 5) and colorful details about a ChatGPT session, with no link to the session transcript, the compared reports, or any evidence. Two sections earlier the same page declares "No receipt, no finding" as the evidence rule.

claim — apex/method/index.html:118

A real ChatGPT session with browsing quoted the site accurately (21 of 21 checkable claims verified against source) and caught the copy’s repetitive cadence. It surfaced 0 of the 5 verified trust-killers

ships — apex/method/index.html:94

<dt>No receipt, no finding</dt>

The one section that argues the product beats a free alternative is the one section a skeptic cannot check. On a page built around receipt discipline, an unreceipted self-serving benchmark reads as marketing wearing a lab coat.

fix — Publish and link the Round 1 evidence (the ChatGPT session transcript and both reports) from the benchmark paragraph at method/index.html:118, or remove the exact 21/21 and 0/5 figures.

this line

SG-005

embarrassing internal-vocabulary-leak 1/4 lenses

"Retired security catalog freeze" is opaque insider jargon that appears on two pages unexplained

This phrase (also on the homepage, line 124: "A freeze of the previous site’s retired security catalog is archived") is never defined. "Security" arrives from nowhere — everything else describes a stranger-test/copy-review tool — and "catalog freeze" and "retired" are internal history a first-time visitor has no way to parse.

apex/queue/index.html:72

Retired security catalog freeze; 158 verified findings stand as the archive.

A visitor scanning the queue table or homepage hits a sentence they cannot decode about the product's only prior work, and either wonders if they misunderstood what the tool does (is it a security scanner?) or skips the archive link entirely.

fix — Search all pages for 'security catalog' and 'freeze' (apex/queue/index.html:72, apex/index.html:124, apex/method/index.html:53) and rewrite in plain visitor language, e.g. 'an archived report of the previous version of this site (158 verified findings)'.

sweep all instances

SG-006

nit generated-copy-defects 3/4 lenses

The sample-report meta strip says "rebuild, pre-deploy" twice in adjacent items

Two consecutive meta items carry the same "rebuild · pre-deploy" information, so the exhibit header reads like a template that was filled twice with the same value.

claim — apex/index.html:91

<span>sample <b>rebuild · pre-deploy</b></span>

ships — apex/index.html:92

<span>target <b>hexento.com (rebuild, pre-deploy)</b></span>

Tiny, but the exhibit is presented as a specimen of the product's precision; visible duplication in its header slightly undercuts that.

fix — Delete or relabel line 91's 'sample rebuild · pre-deploy' (e.g. 'sample run 001') since line 92's target item already says '(rebuild, pre-deploy)'.

this line

SG-007

nit stale-claim 2/4 lenses

The homepage's only displayed receipt cites a method-page line that no longer contains that text

The flagship sample finding SG-006 quotes "204 of 204 receipts passed that audit" and cites method/index.html:72, but the live method page contains no such sentence anywhere — line 72 is a heading. The disclaimer "The receipts document the pages as they stood then" (line 78) exists but is one easily-skimmed sentence.

claim — apex/index.html:117

<span class="lab src">claim — method/index.html:72</span>

ships — apex/method/index.html:72

<h3>Four lenses</h3>

The entire pitch is verifiable verbatim receipts. The first skeptical visitor who tries to verify the one receipt shown on the homepage finds nothing at the cited location and concludes the receipts don't check out — the exact failure the product claims to prevent.

fix — Date-stamp the exhibit source label at apex/index.html:117, e.g. 'claim — method/index.html:72 (pre-deploy, 2026-08-09)', so the citation reads as historical rather than a live pointer to the current method page.

this line

SG-008

nit disclosure-inventory-drift 2/4 lenses

The privacy page never mentions the browser-side localStorage scan record

scan.js and the status page persist the last scan's id, URL, and report link in localStorage for 24 hours ("this browser also remembers the last one", scan page line 69). It's benign and local-only, but the privacy page enumerates analytics, scans, and queue submissions and then says "Nothing else" without mentioning it.

claim — apex/privacy/index.html:53

Short, because little happens here.

ships — apex/scan.js:29

localStorage.setItem(STORE_KEY, JSON.stringify({

A privacy-minded visitor who inspects storage finds a record the privacy page said nothing about. Trivial to disclose in one sentence; slightly corrosive when discovered instead.

fix — Add a sentence to the privacy page's Self-serve scans section disclosing the browser-only localStorage record (scan id, URL, report link under 'slopguard:lastScan', kept about 24 hours in the visitor's browser, never sent to the server).

this line

SG-009

nit other 1/4 lenses

"First scan free" implies a paid second scan, but nothing is for sale and repeat scans are unexplained

"First scan free" is stamped on the header, meta description, and og tags, which universally signals "later scans cost money." The pricing section then says nothing can be bought. A visitor cannot tell whether a second scan of their site next week is possible, forbidden, or priced.

claim — apex/index.html:51

<span>first scan <b>free</b></span>

ships — apex/index.html:129

Paid features (scheduled reruns, diffs, a CI gate) are not for sale yet. No price to quote until they work.

A visitor evaluating whether to invest in the tool hits a dead end on the most basic question — can I use this again? — and either emails or leaves. The honesty about unfinished paid features is good; the "first ... free" framing contradicts it.

fix — Add one sentence to the 'What it costs' paragraph at apex/index.html:129 stating what a second scan (same site after 24 hours, or a different site) is today — e.g. that self-serve scans are currently free while paid features are built.

this line

SG-010

nit unverifiable-accountability 1/4 lenses

Every piece of evidence on the site is SlopGuard scanning hexento.com itself

The sample report, the archived report, the rerun, the benchmark round 1, and queue slot 001 are all the operator's own domain. The queue's only completed entry is the operator's site, and the method page concedes "Round 2 runs on the queue’s first external site" — i.e., no external site has been scanned yet.

apex/index.html:78

We ran SlopGuard on this site before it shipped.

A skeptical potential payer asks "has anyone else actually used this?" and the honest answer visible on the page is no. It's disclosed rather than hidden, which helps, but it is a real hesitation the copy never addresses head-on.

fix — Add one plain sentence near the sample-report intro at apex/index.html:78 acknowledging that all published runs so far are of Hexento's own sites and that queue slot 002 will be the first external one.

this line

SG-011

nit operator-pipeline-narration 1/4 lenses

The lede describes pipeline internals before ever saying what problem the tool solves

The first on-page sentence a visitor reads is about reviewers, passes, and "killing findings against the quoted text" — terms that only make sense after reading the method page. The plain-language version ("quotes what a first visitor would trip on") lives only in the meta description, invisible on the page.

apex/index.html:57

A fifth pass tries to kill every finding against the quoted text. What survives is a markdown report with paths, line numbers, and a fix scope

In the 30-second window, a visitor has to reverse-engineer what a "finding" is and why it needs killing before understanding they're being offered a site review. The target audience will mostly get there, but it costs several of the 30 seconds.

fix — Rewrite the lede at apex/index.html:57 to open with the visitor-facing benefit — surface the meta description's 'quotes what a first visitor would trip on' as the first on-page sentence, then the mechanism.

this line

SG-012

nit other 1/4 lenses

Decorative header SVGs declare role="img" and aria-hidden="true" simultaneously, on every page

role="img" asserts the element is meaningful image content (and requires an accessible name); aria-hidden="true" removes it from the accessibility tree. The two contradict each other. The same pattern repeats in the headers of index, method, privacy, queue, scan, the exhibit block, and the status page template — while the scan page's mock correctly pairs role="img" with an aria-label.

apex/index.html:42

<svg viewBox="0 0 640 44" preserveAspectRatio="none" role="img" aria-hidden="true">

Harmless to sighted users, but an accessibility-literate reviewer auditing a site that sells automated nitpicking will spot self-contradictory ARIA repeated eight times; dropping role="img" (or the aria-hidden) is a one-token sweep.

fix — Search all HTML and the status-page template for 'role="img" aria-hidden="true"' and delete role="img" from those decorative SVGs, keeping aria-hidden="true".

sweep all instances

SG-013

nit internal-vocabulary-leak 1/4 lenses

The showcase finding renders the raw fallback category 'other' as a visitor-facing label.

In the sample exhibit's head row, between "embarrassing" and "1/4 lenses", the finding's failure-class slot displays the machine bucket "other" — an internal classification default, not a label written for a reader.

apex/index.html:111

<span class="lab">other</span>

The one finding chosen to sell the product's polish shows an unpolished internal enum value, which the detail-oriented buyers this page targets will notice.

fix — Replace the raw category label 'other' at apex/index.html:111 with a human-readable failure-class name for SG-006 (e.g. 'self-scored metric') or remove the span.

this line

SG-014

nit operator-pipeline-narration 1/4 lenses

Homepage pipeline summary is a string of verb-less internal stage names, including 'Adversarial verify' as a noun.

Five fragments in a row read like the operator's checklist of pipeline stages rather than sentences for a first visitor; "Adversarial verify" in particular is the internal stage label used as a noun phrase. The builder audience can decode it, but it is telegraphed at them, not written for them.

apex/index.html:134

Crawl and render in a real browser. Deterministic checks. Four independent lenses. Adversarial verify against the quoted page. Markdown out.

A first visitor skimming "How a finding is made" gets the config-file version of the pipeline; it works for insiders but reads as notes the builder forgot to expand.

fix — Rewrite the stage fragments at apex/index.html:134 as visitor-facing clauses, e.g. replace 'Adversarial verify against the quoted page.' with 'An adversarial pass re-checks every finding against the quoted page.'

this line

SG-015

nit structural-inconsistency 1/4 lenses

On subpages the logo links to /scan/, not home — clicking the wordmark lands on the scan form

On method, scan, queue, and privacy pages the SLOPGUARD wordmark links to /scan/ while the small "a Hexento tool ›" byline is the actual home link. The universal convention is logo → home; a visitor trying to get back to the homepage lands on the intake form instead.

apex/method/index.html:32

<a class="wordmark mono" href="/scan/">SLOP<b>GUARD</b></a>

Momentary "where am I?" disorientation and an extra hunt for the real home link — small, but it happens on every subpage.

fix — Search for '<a class="wordmark mono" href="/scan/">' across method, queue, privacy, scan pages and status-page.js and change the href to '/' so the wordmark goes home; keep the nav's Scan link as the /scan/ entry point.

sweep all instances

SG-016

nit internal-vocabulary-leak 1/4 lenses

'Operator run' is an internal run category never defined anywhere on the site.

Visitors know about self-serve scans and the roast queue; "operator run" is the builder's own vocabulary for runs they perform themselves, and it appears exactly once, undefined, in a sentence about data retention.

apex/method/index.html:111

A queue or operator run is kept as history so runs can be compared

A reader working out which retention policy applies to their data meets a category they cannot map to anything they were offered, which muddies an otherwise crisp retention story.

fix — Replace 'A queue or operator run' at method/index.html:111 with plain language, e.g. 'A queue run, or a run we perform ourselves,'.

this line

SG-017

nit other 1/4 lenses

When copy fails, the Copy button permanently becomes the email address with no reset

The success path restores "Copy address" after 1.6 s, but the failure path replaces the button label with "hello@hexento.com" and never restores it. The control then reads as a second address chip while still behaving as a copy button on click.

apex/queue/index.html:127

else btn.textContent = addr;

A visitor on a browser where execCommand fails ends up with two elements showing the same email and no visible copy control — a small but permanent broken-looking state on the page asking them to submit.

fix — In the queue page copy fallback, replace 'else btn.textContent = addr;' with a branch that shows the address and setTimeout-restores 'Copy address' after ~2 seconds.

this line

SG-018

nit claim-code-contradiction 1/4 lenses

Submit message promises "the live progress page" but the reuse path opens the report instead

On the 24-hour same-domain reuse path the code deliberately navigates straight to the report, yet the status message shown just before navigation always says the live progress page is opening. A reuse-path user is told one destination and lands on another.

claim — apex/scan.js:77

msg.className = ''; msg.textContent = 'Starting the scan. Opening the live progress page.';

ships — apex/scan.js:100

location.href = (reuse && reportPath) ? reportPath : (statusPath || reportPath);

A returning visitor who re-submits their URL reads "Opening the live progress page" and abruptly lands on a finished report — a small disorientation on a product that sells attention to exactly this kind of copy/behavior mismatch.

fix — In scan.js, set the destination-specific message after the /api/scan response: on the reuse path (reused/domain_rate_reuse/complete) show e.g. 'A report for this domain from the last 24 hours exists. Opening it.' instead of 'Opening the live progress page.'

this line

SG-019

nit other 1/4 lenses

Queue message renders the raw queuePosition as the count of scans ahead of you

If queuePosition is a 1-based position (as the name suggests), a user at position 2 has one scan ahead but is told "2 ahead of you." If instead it is already a count-ahead value, the `> 1` guard hides the "1 ahead of you" case and shows the generic "Starting shortly" message while someone is still ahead. Either reading leaves one visible state wrong.

tools/slopguard/src/server/status-page.js:210

elHead.textContent = 'Queued. ' + s.queuePosition + ' ahead of you.';

A waiting user staring at this page has exactly one number to trust, and it is likely off by one — the kind of sloppy computed string SlopGuard itself claims to catch on other people's sites.

fix — Align the queue copy with the API semantics at status-page.js:209-210: if queuePosition is a 1-based position, render (s.queuePosition - 1) + ' ahead of you.'; if it is already a count of scans ahead, change the guard to s.queuePosition >= 1.

this line

SG-020

nit other 1/4 lenses

Browser tab title stays "scanning…" forever, even after the report is ready or the scan fails

The script updates the on-page h1 to "Report ready" or "Scan didn't finish" but never touches document.title, so a backgrounded tab — the most likely state during a multi-minute scan the copy tells you to keep open — permanently reads "scanning…".

claim — tools/slopguard/src/server/status-page.js:16

<title>SlopGuard · scanning…</title>

ships — tools/slopguard/src/server/status-page.js:176

elTitle.textContent = 'Report ready';

Users are explicitly told to keep the page open and wait; the one signal visible from another tab (the title) never announces completion, so they either poll manually or miss the finish.

fix — In status-page.js, set document.title alongside the h1 updates: 'SlopGuard · report ready' in the complete branch and 'SlopGuard · scan didn’t finish' in the error branch.

this line

SG-021

nit other 1/4 lenses

Status page with JavaScript blocked shows "Starting the scan." forever with no noscript notice

All polling, progress, and the report link are injected by script. The marketing pages each carry a noscript fallback ("This form needs JavaScript to reach the scanner."), but this template — the one page users are told to keep open for minutes — has none, so a no-JS visitor sees a permanently frozen "Starting the scan."

tools/slopguard/src/server/status-page.js:100

<p class="headline" id="headline">Starting the scan.</p>

A user with a strict blocker sits on a page that claims work is starting and never moves, with no hint that JavaScript is the reason — indistinguishable from a hung scan.

fix — Add a noscript fallback to the status-page.js template body, e.g. '<noscript>This page needs JavaScript to show live scan progress and your report link.</noscript>'.

this line

Editor's note

The report link is sold as private and unguessable, but anyone rescanning the same domain is handed it.

Privacy page says analytics send event names and page URLs only, but events ship extra properties.

The site never says whether the "four reviewers" are humans or AI

The benchmark section makes precise claims with zero receipts, violating the site's own core rule

"Retired security catalog freeze" is opaque insider jargon that appears on two pages unexplained

The sample-report meta strip says "rebuild, pre-deploy" twice in adjacent items

The homepage's only displayed receipt cites a method-page line that no longer contains that text

The privacy page never mentions the browser-side localStorage scan record

"First scan free" implies a paid second scan, but nothing is for sale and repeat scans are unexplained

Every piece of evidence on the site is SlopGuard scanning hexento.com itself

The lede describes pipeline internals before ever saying what problem the tool solves

Decorative header SVGs declare role="img" and aria-hidden="true" simultaneously, on every page

The showcase finding renders the raw fallback category 'other' as a visitor-facing label.

Homepage pipeline summary is a string of verb-less internal stage names, including 'Adversarial verify' as a noun.

On subpages the logo links to /scan/, not home — clicking the wordmark lands on the scan form

'Operator run' is an internal run category never defined anywhere on the site.

When copy fails, the Copy button permanently becomes the email address with no reset

Submit message promises "the live progress page" but the reuse path opens the report instead

Queue message renders the raw queuePosition as the count of scans ahead of you

Browser tab title stays "scanning…" forever, even after the report is ready or the scan fails

Status page with JavaScript blocked shows "Starting the scan." forever with no noscript notice

Rollup — 9 failure classes

other	7
claim-code-contradiction	3
internal-vocabulary-leak	3
operator-pipeline-narration	2
unverifiable-accountability	2
disclosure-inventory-drift	1
generated-copy-defects	1
stale-claim	1
structural-inconsistency	1