Large share cards, article metadata and per-topic descriptions

Links shared from the journal used to unfurl as a small logo thumbnail with no article metadata, and every topic page repeated the same generic description. This change gives every page a brand raster card with large-card markup, gives journal posts timestamps and image metadata, and gives each topic page its own Editor-drafted description. This log entry ships in the same change per the standing rule.

Motivation

Every page advertised the same small vector logo as its share image with the small-summary card type, so shares on large-card timelines rendered weakly with no image dimensions and no article timestamps. The proposal record documents the weak unfurls with live markup evidence and points at the raster-image guidance from the platform publishers: large cards want a 1200 by 630 raster image with explicit dimensions. Topic pages compounded the problem by repeating one generic description across all four archives. One static brand card plus wiring-only markup closes the gap with zero content risk.

What changed

A new brand card file now ships in the asset pipeline with content hashing like every other asset: 1200 by 630 pixels, opaque, flat theme colors, the logo tile geometry beside the wordmark with the tagline and address lines, inside the specified safe margins. Every rendered page now carries an absolute card image address with width, height, type and alt plus the matching image tag, and the card type is the large-image variant. Journal post pages only add published time, modified time, section and author tags, and the structured data for posts gains the absolute card image. The four topic pages each render their own Editor-drafted description in the page meta and share tags, enforced unique and complete by the builder. The logo and favicon files, header, footer, feeds and sitemap are untouched.

How it was done

After the remote preflight and a fresh feature branch from the main line, development generated the card with a local deterministic recipe: the tile is drawn from the logo geometry at four-times supersample and downscaled, the wordmark uses the serif system face with the tagline and address in the sans and mono system faces, and the file is saved optimized with no metadata at well under the weight budget. The shared page renderer passes the card address and dimensions into the base template as parameters, the archive helper accepts a per-page description, and the site data file carries the four Editor descriptions. A new contract test pins the card asset, the per-page markup, the post-only article fields and the distinct topic descriptions, and the standing weight budget now scopes the scraper-only card outside the render-blocking total with its own size pin. This log entry ships in the same change per the standing rule.

Verification evidence

The site build exits success, the full suite of fifty-two tests is green, a second consecutive build is byte-identical, and the presence gate prints success with this entry covering the change. The built card decodes at exactly 1200 by 630 and weighs about thirty-five kilobytes against the three-hundred-kilobyte budget. Every built page was scanned for the absolute card address, the dimension tags and the large-image card type, and every post page for the four article fields plus the structured-data image. The feed parses with the journal count intact, the sitemap parses with all addresses absolute, and a scan of the diff finds no secrets. The interactive sharing debugger needs a logged-in platform session, which the unattended build environment has no credentialed access to, so a direct debugger run returned a session error; the markup instead matches the published platform requirements line for line, and the debugger check is left for a credentialed reviewer on one post address after deploy. Security and quality reviews attach to the exact pushed head after this pull request opens.