Auditing a marketing site after two product releases shipped
I shipped two loader releases earlier in the day and then audited the marketing site against them. The site was last updated on 2026-07-31 and predated both releases. The audit found six outright false claims, several stale sections, and one gap that was actively costing installs.
The numbers were fine. Every skill count on the site derives from a single config module rather than being hardcoded, and the vendored skill catalog was byte-identical to the loader's current copy. The stated Python floor of 3.10 matched the loader's declared minimum exactly. What had rotted was the behavioral writing: what the software does at startup, where skills live, what leaves the machine.
Privacy policy
The privacy policy said license validation sent a key and a timestamp. It actually sends the key, a hashed machine identifier, an email if one was given at activation, and environment details. There is no timestamp in the payload at all. Validation was described as though it were the only call to our servers. Two others were undisclosed entirely, and both carry the license key: a Pro bundle version probe that fires unprompted at session start, and the referrals page.
The policy now lists every outbound call, split into the ones that happen without being asked and the ones the user triggers, naming destination and payload for each.
I made two precision changes that strengthen the policy rather than soften it. The machine identifier is a one way hash with hostname, username and platform as inputs, so the policy now says that plainly instead of leaving "machine ID" undefined. A blanket claim that no skill usage data is collected was replaced with the narrower true claim that usage is recorded to a file on the user's own disk and never transmitted.
FAQ
The FAQ claimed zero performance impact on startup and described skills loading from a small catalog file of a few kilobytes. Neither survived the index relocation. The first start after installing or upgrading builds the index before answering anything, and nearly all of that wait is a one time download of the embedding model, so it tracks network speed rather than how many skills you have. The catalog description was what made the performance claim sound plausible, so both were rewritten together, using the loader's own wording so the site and the package now say the same thing.
Those eight FAQ answers lived in two places with no import between them: one copy rendered to readers, one hand copied into structured data served to search engines. They were identical only by discipline. I extracted and compared all sixteen strings before touching anything. Both copies now read a shared module, so drift is structurally impossible rather than merely corrected this once.
I put the shared FAQ module in the data layer rather than exporting it from the display component. A server component can import a constant from a client component module, but it works by accident, and it would have put structured data downstream of a presentational component.
I verified the second fix against the built artifact rather than the source. I extracted the structured data from the production build output and asserted all eight questions and answers matched the shared module with interpolations resolved, that the retired phrases appeared nowhere, and that the replacement named the index build, the model download and the vector store.
Deploy verification
The first check of the live privacy page still served the old text, because the push had not finished building yet. Confirming a deploy needs polling with cache busting, not a single fetch.
The production build silently rewrote a generated data file as part of its prebuild step. It was never staged and the branch sync reverted it, but running a build dirties the working tree in this repo.