`formFactor: 'desktop'` changes which thresholds a metric is scored against and
NOTHING else. Throttling and the user agent keep their defaults, which are mobile
— so every desktop run was a desktop-sized window on a 4x-slowed CPU over slow 4G,
announced as a moto-g.
It read 86 where the same page reads 100. That gap was reported repeatedly as
network latency to the host. It was not latency; it was this. Measured after the
fix: desktop 100, LCP 0.4s against 2.2s.
Nine more from the same review:
runtimeError was never checked, so a page that failed to load reported
"nothing failing" — the most reassuring possible output for a site that is down
--json exited 0 before the gate, so the documented non-zero exit was true for a
person reading the table and false for the only caller that could act on it
scoreDisplayMode 'error' was filtered out while still nulling its category, so
a category could read 0 with an empty findings list
a missing metric serialised as 0, which a script reads as a perfect measurement
`source` is a string on some audits and an object on others; String() on the
object printed [object Object]
the watchdog's surrender was permanent — the health branch sat below the check,
so once it stopped trying it also stopped noticing, and a server fixed by hand
left it asleep until the platform restarted
a failed restart leaves no process at all, because startServer deletes before
it starts. status null then reads as "somebody stopped it", which the watchdog
leaves alone — one bad restart would have turned it off and taken the server
with it, silently
the skill claimed the panel uses this engine. Nothing but the CLI does
and gave `bun run build:site` with no cwd, which only works from the website
checkout — api/static-site.ts documents that and the skill did not
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fofos-dev sat for eighteen hours reporting `online`, holding its port open and
answering nothing. pm2 was not wrong — the process was alive and the socket was
bound. It was `bun --hot` wedged after a day of edits, sitting in ep_poll and
never completing a request. dev.fofosfluffybastards.com was down the whole time
and nothing said so.
servers.ts already knows those two answers disagree; that is why `reachable` is
asked separately from pm2's status, and its own comment says so. This asks the
same question on a timer.
Not an hourly restart. That bounces a healthy server fifty times to catch one
wedge, drops whatever anybody was doing each time, and still leaves the site
broken for up to an hour where a probe catches it in two minutes.
It acts only when pm2 says online AND the port does not answer, which is a lie
worth correcting. A server somebody STOPPED is a decision and is left alone.
Two strikes a minute apart, because --hot legitimately goes quiet while it
rebuilds. Five minutes of cooldown after acting. Three failed restarts and it
gives up and says to go read the logs, because a watchdog that restarts forever
is a crash loop with a nicer name.
State is on its own route rather than folded into /_config/servers, which answers
with a bare array that two screens read positionally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5