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

SG-001

embarrassing self-contradicting-facts 3/4 lenses

The checkability promise dead-ends because the only demo report targets a site that no longer exists.

The method page's core promise is that every finding traces to something the reader can verify, but the sole public run (001) reviewed the domain's previous incarnation, which the homepage says is retired. A stranger cannot check a single receipt against a live page.

claim — method/index.html:30

Every SlopGuard finding traces to something you can check yourself.

ships — index.html:46

The catalog is retired. The report is public, and it is the product demo.

The entire pitch is receipts-you-can-verify; when I click through to the flagship evidence and realize the target is gone, the product demo becomes take-my-word-for-it, which is exactly what the product claims to eliminate.

fix — Link an archived snapshot of run 001's retired target next to this promise (or on the report page), or qualify the sentence to say the demo target is retired and its receipts are preserved inside the report.

this line

SG-002

embarrassing unverifiable-accountability 2/4 lenses

No page anywhere says who runs this, yet the queue asks strangers to email in their unlaunched sites.

The only identity signal on the whole site is one footer sentence about "a studio"; there is no about page, no name, no company detail. The privacy page even refers to "the operator's other project" without naming the operator.

index.html:102

Hexento is a studio of tools for people who build with AI. SlopGuard is the first.

I am being asked to hand my URL and email to an anonymous entity that will crawl my site and publish a public critique of it. With zero visible humans behind it, submitting feels risky and I hesitate at the exact conversion moment.

fix — Add an accountable identity — an operator or company name with a linked /about page — to the colophon that currently only says 'Hexento is a studio of tools'.

restructure

SG-003

embarrassing self-contradicting-facts 2/4 lenses

It is unclear whether "you read it first" includes any right to stop a brutal report from publishing.

The homepage states publication as automatic, while the privacy page frames publication as something "you opted into when submitting." Neither says what happens if the owner reads the report and does not want it public.

claim — index.html:95

Submit yours; the report is free, you read it first, and it publishes to the queue.

ships — privacy/index.html:41

Reports belong to the site owner and publish only to the queue you opted into when submitting.

The report of my possibly embarrassing launch will be public; whether I get a veto is the single question I need answered before submitting, and the site answers it two slightly different ways in two places.

fix — State in the queue ground rules whether an owner can read the report and decline publication, then align the strings 'it publishes to the queue' (index.html:95), 'it publishes here' (queue/index.html:7,30) and 'opted into when submitting' (privacy/index.html:41) with that answer.

sweep all instances

SG-004

embarrassing self-contradicting-facts 2/4 lenses

The homepage instructs a rerun that no offering on the site actually provides.

Step 4 of "What a run does" tells the visitor to rerun after fixes, but the queue offers exactly one free report per site and reruns are explicitly part of "the watch", which the pricing section says is still in build with no price. There is no stated way to get that rerun today.

claim — index.html:82

Paste it into your coding agent, say "fix these", rerun when it's done.

ships — queue/index.html:30

One free public report per site, for people launching things built with AI.

A visitor who follows the pitch to its natural next step hits a dead end: the product's own workflow ends in an action they cannot buy or request, which makes the whole flow feel unfinished.

fix — Drop or qualify 'rerun when it's done' on index.html:82 (e.g. 'a rerun lands with the watch') so the described workflow matches the one-free-report offer.

this line

SG-005

embarrassing unverifiable-accountability 1/4 lenses

The site claims it was reviewed by its own tool before deploy but links no report for the current site.

Both the footer ("Reviewed by its own product before deploy") and this method section assert a self-run on the current deploy, yet the only report offered anywhere is Report 001 of the retired previous site. No artifact of the claimed pre-deploy run on this version is linked.

method/index.html:98

Every Hexento deploy gets a SlopGuard run before it ships, this site included. If we skip our own tool, the tool dies.

A product whose rule is "no receipt, no finding" makes its own flagship claim with no receipt. Once I notice that, I start discounting every other unlinked claim on the page.

fix — Publish the pre-deploy self-run report for this site and link it from both claims, or sweep and soften the strings 'this site included' (method/index.html:98) and 'Reviewed by its own product before deploy.' (index.html:103).

sweep all instances

SG-006

embarrassing other 1/4 lenses

The 204/204 receipt stat is guaranteed by construction, yet is sold as an audit result.

The same page says any finding whose receipt cannot be re-found is dropped before the report is written, so the published set will always score N/N. Presenting the inevitable perfect score as an audit outcome (and repeating "receipts verified 204/204" in the homepage masthead) is circular.

claim — method/index.html:72

Receipts are re-verified mechanically before publication; in run 001, 204 of 204 receipts passed that audit.

ships — method/index.html:56

a finding whose receipt cannot be re-found is dropped before the report is written

The exact kind of skeptical reader this site courts will notice the metric cannot fail, and will then discount every other number on the page.

fix — Sweep the string '204/204' (method/index.html:72, index.html:36) and reframe it as filter output — state how many candidate receipts entered the mechanical audit and how many findings were dropped — instead of presenting a by-construction perfect score as an audit result.

sweep all instances

SG-007

nit audience-jargon-mismatch 3/4 lenses

The first-screen stats show 158 findings but 204 receipts with no explanation of the mismatch or the term.

"Receipts" is product jargon that has not been defined yet at this point in the page, and the 158-vs-204 discrepancy (findings can carry multiple receipts) is never explained on the homepage.

claim — index.html:36

findings <b>158</b> · receipts verified <b>204/204</b>

ships — method/index.html:72

Every finding quotes your content verbatim.

My literal first parsed content is a self-graded 204/204 score in a unit I do not understand; it reads as dashboard theater before I even know what the product is.

fix — Reword the ticker or add adjacent copy explaining the ratio, e.g. '158 findings backed by 204 verbatim receipts, all re-verified', so 204 receipts for 158 findings does not read as a discrepancy.

this line

SG-008

nit internal-vocabulary-leak 3/4 lenses

"The watch" appears as an unintroduced lowercase product name and "in build" is nonstandard phrasing.

A future feature is referred to by an internal nickname with no introduction; on first read "the watch" briefly parses as a wristwatch before the parenthetical rescues it.

index.html:90

The watch (scheduled reruns, diffs between runs, a CI gate) is in build; it gets a price when it works.

A small double-take in the pricing section, the one place a wary visitor is reading most carefully for catches.

fix — Replace 'The watch' and 'is in build' with plain language, e.g. 'A monitoring tier — scheduled reruns, diffs between runs, a CI gate — is in development; it gets a price when it works.'

this line

SG-009

nit self-contradicting-facts 2/4 lenses

The homepage's categorical 'not inferred from source' is contradicted by the method page's source mode.

The homepage states behavior is never inferred from source, while the method page describes a mode that skips the crawl and reads the repo directly. The absolute phrasing oversells one mode as the whole product.

claim — index.html:64

Behavior is observed, not inferred from source.

ships — method/index.html:38

Source mode skips the crawl and reads your repo directly.

A careful reader who visits both pages catches the site doing the thing it audits for: an absolute marketing claim softened by fine print one click away.

fix — Scope the claim to crawl mode on index.html:64, e.g. 'In a crawl, behavior is observed, not inferred from source.'

this line

SG-010

nit other 1/4 lenses

I clicked hexento.com and the page shouts SLOPGUARD, with the connection unexplained until the footer.

The domain, the wordmark, and (on the privacy page) a third brand, Playkeg, are three names for one operator introduced within a single visit. The one-line Hexento/SlopGuard explanation lives only in the footer colophon.

index.html:21

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

In the first three seconds I wonder whether I mistyped the URL or landed on a redirect; brand sprawl this early reads as improvised and makes a first-time visitor re-check the address bar instead of reading the pitch.

fix — Add a visible 'by Hexento' attribution beside the header wordmark on every page — sweep the pattern 'SLOP<b>GUARD</b></a>'.

sweep all instances

SG-011

nit self-contradicting-facts 1/4 lenses

The heading says run 001 "was this site" while the body says it was a different, retired site.

"Run 001 was this site" followed by "previous incarnation" forces a re-read to work out which site was reviewed, and "security-affiliate catalog built at agent speed" is dense insider phrasing that also reveals the domain's affiliate-site past.

claim — index.html:45

The first target was this domain's previous incarnation, a security-affiliate catalog built at agent speed.

ships — index.html:44

Run 001 was this site

I spend part of my thirty seconds untangling whether the report criticizes the page I am currently reading, and learning the domain used to be an affiliate catalog is an odd trust note to lead with.

fix — Change the heading 'Run 001 was this site' (index.html:44) to name the real target, e.g. 'Run 001: this domain's previous site'.

this line

SG-012

nit audience-jargon-mismatch 1/4 lenses

"Register keeper" is opaque jargon on the homepage where the other three lens names explain themselves.

Three of the four lens names are self-describing; "register keeper" means nothing to a lay visitor and is only glossed on the method page.

index.html:70

Cold stranger, skeptical buyer, detail nitpicker, register keeper.

One unexplained term in a four-item list makes me wonder if I am missing context, a small stumble in an otherwise clear pitch.

fix — Append a brief gloss to 'register keeper' on index.html:70, e.g. 'register keeper (is every sentence written for the visitor?)'.

this line

SG-013

nit other 1/4 lenses

The header chart is labeled as run data but is an unlabeled decorative squiggle with no axes or key.

Three curves announced as "Run 001 severity traces" carry no axes, units, or legend, so they communicate nothing checkable — on a site whose brand is verifiable evidence.

index.html:28

aria-label="Run 001 severity traces"

It looks like the fake dashboard art on a thousand AI-generated landing pages, which is a risky first visual for a product that polices exactly that genre.

fix — Either add axes and a legend that make the three curves readable as run-001 severity data, or mark the SVG decorative with aria-hidden="true" and delete the 'Run 001 severity traces' label.

this line

SG-014

nit missing-meta 1/4 lenses

No page carries a single date, so nothing distinguishes a live project from an abandoned one.

Run 001 is undated, the queue slots are undated, 'the watch... is in build' has no timeline, and the benchmark's 'results publish here as they land' has no timestamps. There is no last-updated marker anywhere across five files.

index.html:35

run <b>001</b> · target <b>hexento.com</b>

A skeptical buyer cannot tell whether this launched last week or has been a dormant shell for two years. 'Open' queue slots and 'in build' features with no dates read as claims that may be long stale, and staleness hygiene is one of the very things this product audits.

fix — Add a run date wherever the string 'run <b>001</b>' or slot 001 appears (index.html:35, queue/index.html:46-48) and a last-updated stamp in each page's colophon block.

sweep all instances

SG-015

nit stale-claim 1/4 lenses

The benchmark section stakes the product's existence on results that are not shown anywhere.

The section says SlopGuard "has no reason to exist" unless it beats a plain chat prompt, then presents zero results — only a promise that they will appear.

method/index.html:93

SlopGuard runs against a plain "review my site" chat prompt on identical targets, scored on confirmed-finding precision and trust-killer recall. Results publish here as they land.

A bold falsifiability claim with an empty results slot reads as aspiration dressed as evidence; I note that the one benchmark that matters has not been run or has not been shared.

fix — Rewrite the benchmark section in future tense with a date for the first result, or remove the section until at least one result exists.

this line

SG-016

nit generated-copy-defects 1/4 lenses

"Copy buttons sized for a coding agent's terminal" does not parse on first read.

Buttons are not sized for terminals; the intended meaning (copy blocks formatted for pasting into an agent session) has to be reconstructed by the reader.

method/index.html:62

copy buttons sized for a coding agent's terminal

A stumble in the one paragraph describing the deliverable makes the reader reread, and rereading is where trust in the writing starts to leak.

fix — Rewrite the phrase as e.g. 'with one-click copy blocks formatted for pasting into a coding agent' so the description attaches to the copy blocks, not the terminal.

this line

SG-017

nit disclosure-inventory-drift 1/4 lenses

Retention is scoped to 'a run,' leaving the fate of your submission email unstated.

The privacy page says what a run keeps but never says how long the operator retains your email address and correspondence, which live outside any run. For the one interaction that collects personal data, retention is the one thing left unsaid.

privacy/index.html:40

The report is the only artifact a run keeps: crawl snapshots and network logs are discarded once it is written.

A privacy-conscious submitter notices the careful scoping and reads it as lawyerly: the deleted-data promise covers the machine's artifacts, not the human's inbox.

fix — Add a sentence to the Queue submissions section stating how long submission emails and correspondence are retained and when they are deleted.

this line

SG-018

nit disclosure-inventory-drift 1/4 lenses

The privacy page discloses named interaction events that no shipped code ever sends.

analytics.js exports HexentoAnalytics.track for interaction events, but no page in the site attaches a single handler or calls it, so the only events that can exist are Umami's automatic pageviews. The disclosure describes behavior that does not occur.

privacy/index.html:35

Events record page URLs and named interactions.

Benign direction, but on a site whose founding trust-killer was a privacy page mismatching analytics behavior, any privacy-vs-code drift, even over-disclosure, reads as sloppy.

fix — Change privacy/index.html:35 to describe only what ships ('Events record page URLs.') or add real HexentoAnalytics.track calls for the named interactions.

this line

SG-019

nit other 1/4 lenses

The only submission path is a mailto button, which silently does nothing for many webmail users.

The primary CTA on the conversion page opens the OS mail client; on machines with no configured client (most webmail users) the click produces nothing. The plain-text address in the paragraph above is the only fallback.

queue/index.html:63

<a class="btn big" href="mailto:hello@hexento.com?subject=Roast%20my%20site">Submit your site</a>

I click the big button, nothing happens, and with thirty seconds of patience I am more likely to close the tab than to hunt for the email address one paragraph up.

fix — Show the plain address inside or beside the mailto button and add a copy-to-clipboard affordance so visitors without a configured mail client can still submit.

this line

SG-020

nit missing-meta 1/4 lenses

The slots table has no header row or caption for its three columns.

The table ships tbody-only with no th cells, so the slot number, description, and status columns are unlabeled; screen readers announce an anonymous grid of cells.

queue/index.html:43

<table class="slots">

Sighted visitors infer the columns, but assistive-tech users get context-free fragments — a small structural miss on a site that flags exactly this kind of thing in others.

fix — Add a caption and a thead with th cells ('Slot', 'Site', 'Status') to the slots table in queue/index.html.

this line

SG-021

nit generated-copy-defects 1/4 lenses

The queue page calls the team "the maker" while the same page's lede says "we".

Self-reference drifts across the site between "we", "the maker", "the operator", and "Hexento"; on this page the third-person "the maker" sits seventeen lines below first-person "we run".

claim — queue/index.html:47

the maker's own site

ships — queue/index.html:30

You submit, we run, you read it first, it publishes here.

Shifting self-reference reads as multiple uncoordinated drafting passes, which is exactly the tell this product claims to catch in other people's sites.

fix — Pick one self-reference voice ('we') and sweep the strings 'the maker' (queue/index.html:47) and 'the operator' (privacy/index.html:34) to match it.

sweep all instances

SG-022

nit phantom-reference 1/4 lenses

robots.txt advertises a sitemap.xml that is not present in the reviewed file set.

robots.txt points crawlers at /sitemap.xml, but no sitemap file appears among the shipped files under review. If it is genuinely absent at deploy, every crawler that honors the directive fetches a 404.

robots.txt:4

Sitemap: https://hexento.com/sitemap.xml

Invisible to humans but not to search engines; for a site marketing meticulousness, a dead sitemap pointer is an easy credibility ding for anyone who checks.

fix — Ship a sitemap.xml at the site root listing the site's pages, or delete the Sitemap line from robots.txt.

this line

Editor's note

The checkability promise dead-ends because the only demo report targets a site that no longer exists.

No page anywhere says who runs this, yet the queue asks strangers to email in their unlaunched sites.

It is unclear whether "you read it first" includes any right to stop a brutal report from publishing.

The homepage instructs a rerun that no offering on the site actually provides.

The site claims it was reviewed by its own tool before deploy but links no report for the current site.

The 204/204 receipt stat is guaranteed by construction, yet is sold as an audit result.

The first-screen stats show 158 findings but 204 receipts with no explanation of the mismatch or the term.

"The watch" appears as an unintroduced lowercase product name and "in build" is nonstandard phrasing.

The homepage's categorical 'not inferred from source' is contradicted by the method page's source mode.

I clicked hexento.com and the page shouts SLOPGUARD, with the connection unexplained until the footer.

The heading says run 001 "was this site" while the body says it was a different, retired site.

"Register keeper" is opaque jargon on the homepage where the other three lens names explain themselves.

The header chart is labeled as run data but is an unlabeled decorative squiggle with no axes or key.

No page carries a single date, so nothing distinguishes a live project from an abandoned one.

The benchmark section stakes the product's existence on results that are not shown anywhere.

"Copy buttons sized for a coding agent's terminal" does not parse on first read.

Retention is scoped to 'a run,' leaving the fate of your submission email unstated.

The privacy page discloses named interaction events that no shipped code ever sends.

The only submission path is a mailto button, which silently does nothing for many webmail users.

The slots table has no header row or caption for its three columns.

The queue page calls the team "the maker" while the same page's lede says "we".

robots.txt advertises a sitemap.xml that is not present in the reviewed file set.

Rollup — 10 failure classes

self-contradicting-facts	5
other	4
audience-jargon-mismatch	2
disclosure-inventory-drift	2
generated-copy-defects	2
missing-meta	2
unverifiable-accountability	2
internal-vocabulary-leak	1
phantom-reference	1
stale-claim	1