Package
@flashyos/page
One page, one card, one claim: per-page social images, canonical metadata and structured data for a property that expects to be cited by search engines and answered from by generative ones.
version 0.1.1 · audit of 2026-10-04 · source: flashyos/packages/page
npm i @flashyos/pageMeasured on 2026-08-31 across thirteen properties and 733 pages: 11% had an image of their own, 29% a canonical URL, 20% structured data. The estate was good at metadata and bad at identity. This kit composes all of it from the page’s own facts in the same call that sets its title, so a title and its card cannot disagree. SEO and GEO are the same fields read twice; there is one function, not two.
This property’s own cards are rendered by this kit, vendored byte-identical (`src/lib/page/`), and a drift test compares the copy to canon or reports unknown.
Edge cases — each one paid for once
A property that forgets its accent should fail to compile, not render in somebody else’s colour
The accent is a table keyed by property, not a parameter with a default. Thirteen hand-rolled card routes would have been the same four files written thirteen times, which is how the estate once ended up with eleven identical charter checkers that all disagreed with the spec in the same four places.
Each property renders its own cards
Not flashyos.com’s /og with a query parameter: that would make every property’s social links depend on another domain being up, so one deploy could turn thirteen properties’ shared links into grey rectangles at once. A card is part of what a property serves.
It never writes a description
A card and a canonical are derivable from the page; a description somebody has not written is a description somebody has not written. 539 pages in the estate carried a card that repeated the homepage, and that was the defect being fixed, not a template to generate more of.