Unattended Works · How it works
How it works
One purchase, five stages, no conversation. This page describes the run as it is implemented today, including where checkout is still test-mode only and live charging remains human-gated.
The run, in order
Five stages, no conversation
Purchase test mode
You supply one public https URL, prove control of the exact host (DNS TXT or a well-known HTTPS file), and authorize a one-time Stripe payment. No account is created and no questionnaire is served. Order + package code exists on this stack in Stripe test mode with manual capture after package proof. Live checkout and live keys are human-gated and not open; the catalog stays unavailable and unpriced until those gates close.
Scope resolution built
The runner resolves the entry URL, reads robots.txt, and expands the route list up to the published crawl budget (sold path: 25 routes, 2000 requests, 0.5 s interval, 900 s wall-clock — see the table on this page). The resolved list — including what was excluded and why — is written into the report before any evidence is collected, so scope is a recorded fact rather than an afterthought.
Evidence collection built
Each route is loaded in a real browser engine at a desktop viewport and a mobile viewport. Screenshots, request ledgers, storage ledgers, console transcripts, computed styles, and DOM assertions are recorded as they happen. Interaction probes are not run in v1; the interactions domain is published as not_covered so an empty result is never read as a pass.
Verification built
Findings are derived from the recorded artifacts, not from the live site. Any candidate finding without a referenced artifact is dropped rather than described. Severity is applied from the published rubric, and findings sharing a cause are grouped before ranking.
Delivery test mode
The HTML report and the JSON document are packaged with a content hash per artifact and made available as a time-limited download (7-day signed link; packages purged after 30 days). There is no email step and no dashboard login. The delivery path is implemented for the demo and test-mode order flow; commercial live delivery opens only with checkout.
Failure handling
What happens when a run cannot finish
The site cannot be reached
If the entry URL does not resolve or the origin refuses the runner, the run stops and reports that it stopped. No partial report is delivered as though it were complete.
Some routes cannot be reached
Routes that time out, rate-limit, or require authentication are recorded with status not_reached and appear in the report's not_covered list. They are never silently omitted and never counted as passing.
The site is larger than the crawl budget
The budget numbers are stated in the report along with the exact routes visited. A truncated crawl is reported as truncated. On the sold path the route ceiling is 25 and wall-clock is 900 s; the operator CLI default of 50 routes / 300 s is not the commercial product.
The runner itself fails
A run that cannot produce a verifiable report is a failed run. In the payment path that means no capture when Stripe cancellation is confirmed, not a delivered report with caveats.
Why the whole run is written down
An unattended product is only trustworthy if you can describe what it does without being in the room. That is why every stage above is published, in the order it happens, with test-mode stages labelled as test-mode rather than as fully open commerce or as if they did not exist.
Why evidence first, findings second
Most automated site tooling inverts this: it runs a rule engine against a live page and reports the rule output. That is fast and it is unreproducible — rerun it an hour later against a changed page and the finding cannot be defended.
Here the artifacts are captured first and the findings are derived from the artifacts afterwards. That ordering has two consequences worth stating. A finding can always be traced to the exact recorded observation behind it, and a report can be re-derived from its own artifacts without touching your site again.
What you do afterwards
Nothing, unless you want to. The ledger is ordered so that reading it top-down is a reasonable plan, and every entry is written as an outcome to reach rather than as a patch to apply. Whoever maintains the site does the fixing. This product does not write code, open merge requests, or deploy anything.
Crawl budget · wea-v1-crawl-budget · definition v1
Published crawl budget
These are the numeric limits the runner enforces. The sold product uses the API path numbers. The operator CLI ships different defaults for local runs; that difference is intentional and stated here so it is not a surprise.
| Limit | Sold product (API) | Operator CLI default |
|---|---|---|
| Maximum in-scope routes | 25 | 50 |
| Maximum total HTTP requests | 2000 | 2000 |
| Maximum redirect hops | 5 | 5 |
| Minimum request interval (cooldown) | 0.5 seconds | 0.5 seconds |
| Wall-clock timeout | 900 seconds (API job / crawl ceiling) | 300 seconds |
| Crawl transfer-byte cap | 67108864 bytes (64 MiB aggregate declared responses) | 67108864 bytes |
| Persisted artifact-byte cap | 134217728 bytes (128 MiB) | 134217728 bytes |
| Per-request timeout | 45 seconds | 45 seconds |
| API job queue depth | 4 | n/a (CLI is single-run) |
| Ownership challenge rate limits | 5 per host / 20 global per 3600s window | n/a |
Viewports: desktop 1440×900 and mobile 390×844. robots.txt is respected by default. Buyers cannot raise these limits at purchase. Truncation and not-reached routes are recorded in the report.