Bottega Website — the marketing site for Bottega

Next.js 16 App Router + React 19 + TypeScript + plain CSS + static export

Architecture

The website is a static marketing surface, not a second product implementation. Interactive demonstrations reproduce the shipped product's visible contracts, while product behavior remains owned by the Bottega desktop repository.

Each concept has one source of truth:

• lib/release.ts exposes the public repository and URLs from the verified lib/release.json snapshot.
• lib/seo/site.ts owns the production origin and default social image dimensions for metadata, crawler routes, and audits.
• lib/i18n/catalogs/en.ts defines the complete content shape; four translated catalogs must match it.
• lib/agents.ts combines stable Agent/App facts with the current locale's demonstration copy.
• components/features/catalog.ts combines stable feature identity with the current locale's content.
• --bleed and --edge own horizontal alignment across the shrinking hero, shared header, and page content.
• SiteHeader and SiteFooter are the only site chrome implementations.
• DownloadButton is the only download control; every other surface links to the release archive instead.

The App Router serves six canonical English pages without a prefix and the same six logical pages under /zh-CN, /ja, /fr, and /es. English and x-default share the unprefixed URLs; every other language has a self-canonical URL. No route infers language from the browser, redirects by language, or requires server data or client-side content fetching.

Search and sharing

The production origin is https://www.getbottega.app, matching the destination of the apex domain's redirect. Canonical URLs, hreflang, Open Graph, JSON-LD, and the sitemap all use that origin and retain the existing trailing-slash route policy. The previous bottega.app origin is not the product website.

All thirty pages have localized search titles and descriptions. Feature metadata has its own catalog fields, so descriptive search snippets do not change the visible headlines or short navigation labels. Each page includes a large Open Graph/Twitter preview: existing feature screenshots where available, otherwise a 1200 x 630 branded PNG generated locally at /og.png during the build.

/robots.txt permits crawling and points to /sitemap.xml. Normal pages permit indexing and large image previews; the generated 404 remains noindex. Static JSON-LD describes the website and each localized page, the downloadable application on home pages, and breadcrumbs on feature and Changelog pages. Application facts reuse the release snapshot and the MIT source repository; no ratings are invented.

pnpm build runs catalog tests, Next.js compilation/typechecking, and audits against the fresh export. The audits verify all thirty URLs, reciprocal HTML/XML alternates, unique metadata per locale, social image files and dimensions, JSON-LD parity, internal link targets, and the 404 policy. To inspect an existing export, run pnpm audit:i18n and pnpm audit:seo.

After deploying, submit https://www.getbottega.app/sitemap.xml in the site's Google Search Console property and inspect representative English and translated URLs. Local export checks do not measure index coverage; field Core Web Vitals come from Vercel Speed Insights, which SiteDocument mounts once for every page and which reports dynamic segments as [locale] and [slug] routes. Traffic analytics come from Google Analytics 4 (G-D852HRD2JY), which SiteDocument also mounts once after hydration. SoftwareApplication markup describes the product; eligibility for app rich results also requires a genuine published rating or review under Google's software app guidelines.

Styling

The site uses plain CSS because its visual system is already expressed as custom properties. Styles are imported in a deliberate cascade from app/globals.css; module ownership is documented in app/styles/README.md.

One neutral ramp serves both the page and the product demonstrations, copied by value from the product's packages/ui/src/styles/globals.css:

• --ground, --card, --ink, and --line describe the page: it sits one step below the cards (--secondary under --background), exactly as the product's sidebar sits beside its main column, and lines are 10% ink so a white card's border is the product's --border.
• --app-* describes the product UI inside demonstrations with the same values, so a product window on the page is the same material as the page.
• --accent is the amber story accent; it numbers the stories and nothing else. Colour otherwise enters through content: Agent marks, chart palettes, the Ready badge, and the hero wallpaper (--wall), which every home figure reuses as its backdrop.

Motion uses transform or opacity, starts only when its argument enters the viewport, and has a complete prefers-reduced-motion fallback.

Shared chrome

SiteHeader renders the same DOM in three presentations: the home hero reveals the stage variant as the desktop shrinks; once that band scrolls off the top, FloatingHeader slides the fixed floating variant in (and back out when the band returns); content pages use the framed variant, which is sticky at the top. Both persistent skins share one glass — the page colour at 84% over a blur with a hairline below — so scrolled content stays faintly visible behind the navigation. The controls use a shared 32px height and preserve brand, Features, and Download on narrow screens.

The Features, download, and language controls use native details/summary. Their entries remain in the initial DOM, so the menu works with pointer, keyboard, and assistive technology without a client state machine. open is the single switch: the download menu's hover opening writes it rather than running beside it, because a parallel :hover opener makes clicking the trigger closed impossible while the pointer is still on it. Hover is claimed only where a real pointer exists. Both language selectors use explicit alternate links, preserve the current logical page, query, and hash, and derive their selected state only from the current route.

Hero and home narrative

The first screen shows a working product demonstration rather than a poster. During scroll, the desktop moves from full-bleed to an inset card; padding and border radius change instead of scaling the whole UI, keeping text sharp.

The light and dark wallpapers follow the active theme. Auto mode resolves system preference before first paint and continues to follow operating-system changes. Manual choices remain local to the browser.

On the Chat surface a phone stacks over the window's bottom-right corner, running the Web shell of the same open Chat — the window hands it the Chat it shows, so the two screens never disagree — with the executing computer's chip in its composer. The chip bar is pinned to the stage's bottom centre. Narrow screens hide the phone and return the chips to the flow under the window.

The desktop shows one of two surfaces. Chat is the default. The Apps surface opens on the product's own Apps page — one card per first-party App — and then plays a single beat: the leading card takes a press, and that App opens in its own window stacked over the desktop, crossing the first window's right edge because a second window must read as a second window. The window runs the same surface the Apps home section uses, drawn at its natural width and scaled as one block. Any card opens its own App, the red traffic light closes it, and the Apps chip replays the sequence. Reduced motion skips the beat and the movement, never the result.

The home narrative contains four sections immediately after the hero, each opened by a full-width hairline, an eyebrow and a title:

1. Agents: the CLI roster (one row, one sign-in command each), then two numbered stories — Handoff (three Chat windows stacked in time order, Plan → Codex builds → the result back for review, joined by two handwritten flow arrows and printed with the Agents feature page's own product strings) and Data space (the Base reel with its four-view case list).
2. Local first · Encrypted sync: four claims in one row, then Open source (the fork/install/build terminal beside Fork on GitHub and Browse source) and Sync & remote control (the phone beside the desktop panel of the same Chat).
3. Apps: the App stage rotating through the four first-party surfaces, then Dock (the same Expense Tracker surface open above Bottega Dock drawn to the product's metrics, Apps and widgets on one bar) and Widgets (a four-case list driving a centred widget card and its open slot on the Dock).
4. FAQ: a heading column beside seven native disclosures, the first one open.

Every story figure sits in the same figure card, backed by the hero wallpaper. Each story ends with the same FeatureLink action and maps to one feature documentation route. Decorative demonstrations are hidden from the accessibility tree; the surrounding copy carries the argument in reading order.

Feature documentation

app/(english)/features/[slug]/page.tsx and app/[locale]/features/[slug]/page.tsx generate Agents, Apps, Customizable, and Base from one localized catalog and one wiki-style shell with a current-page-aware icon sidebar. Agents has a dedicated article: three static, code-built visuals explain official CLI support, capability-aware conversation adaptation, and persistent cross-Agent Chat handoffs. The Agent picker embeds the canonical Home Hero ProductWindow itself with its menu pinned open; the illustration is inert, outside clicks cannot dismiss its evidence, and the interactive Home Hero keeps its normal dismissal behavior. The capability matrix stands alone without product-window chrome. No real user data is exposed. The cross-Agent handoff flow uses the same unframed treatment.

Apps, Customizable, and Base share one prose article whose opening screenshot and per-section figures are both optional. Apps and Customizable open on a screenshot; Base opens on its first section and carries three figures instead. The first draws a receipt sent into a Chat and the row Base records from it in the column beside the conversation. The second is the only animated surface outside the home narrative: one Base panel whose six view tabs cycle on their own and stop when clicked, each tab drawing the same eighteen rows as a table, list, Kanban board, a map of central Washington, a three-card chart dashboard, and a gallery. The third borrows the Agents cross-Agent sketch — three staggered frames, elbow ink, handwritten notes — to show one Chat filing that receipt, the Project Base the row lands in, and a second Chat reading the month's total back out of it; like the Agents sketch it stays unframed on the page's own paper, so the white cards are the anchors. Every column type, view type, tool name, and owner-key prefix in them is copied from the desktop repository rather than approximated, down to the list and Kanban row titles, which come from the ledger's first column because that is what the product's own projections do. The Apps and Customizable screenshots under public/features/ were captured from the local Bottega development build with private sidebar content collapsed. All claims were cross-checked against current GTM notes, public feature documentation, production source contracts, and the corresponding running product surface. Copy must describe shipped behavior; roadmap language does not belong on these pages.

Product fidelity

The hero and feature reels use the same dimensions, typography hierarchy, logos, and interaction states as their desktop counterparts where those details carry meaning. Intentional deviations must remain visible in code comments and serve framing or legibility, never invent capability.

Interactive controls only receive hover or pressed states when they perform the advertised action. Screenshot dimensions are declared to prevent layout shift. The two runtime dependencies are [email protected], shared with the product's streaming status treatment, and @vercel/speed-insights, which adds one deferred script after hydration; icons and model marks otherwise come from local primitives.

Downloads

The download button uses the verified lib/release.json snapshot. Its macOS action points directly to the installer; a visitor whose platform has no published installer sees View release instead. The menu lists only available installers, the version and prerelease status, and installation notes. macOS downloads are for Apple silicon. All three platform actions remain in the initial DOM so the prepaint platform selection and the native disclosure still work without a client-side data request.

scripts/sync-release.mjs is the snapshot's only writer. It reads the public release list, ignores drafts, and selects the greatest published vX.Y.Z version, including prereleases. It does not use GitHub Latest, which intentionally excludes the personal prereleases. It claims at most one installer per platform by extension; unpublished platforms are explicitly null. No installers, duplicate claims, unfinished uploads, unexpected URLs, or failed HEAD/size checks leave the previous snapshot untouched and fail the run. Only a fully verified snapshot is written, with an atomic rename.

pnpm sync:release

.github/workflows/sync-release.yml runs the same script daily and on demand, authenticates the metadata request with its own GITHUB_TOKEN, and commits the JSON snapshot. Installer probes remain anonymous. The website follows new releases within a day, or immediately from the workflow's manual trigger. Builds stay offline and validate release, platform, version, and installer-link parity in the static export.

Version 0.2.10 is the official stable release for macOS on Apple silicon (ARM64). Windows and Linux installers are not distributed in this release. The macOS installer uses Developer ID signing and Apple notarization, and 0.2.10 uses the official stable automatic-update channel. Versions 0.2.6, 0.2.7, 0.2.8 and 0.2.9 use that stable channel. The shipped 0.2.5 personal build cannot update automatically: quit Bottega and install 0.2.10 manually. This release uses protocol 21: update the computers that run Agents and reload Bottega Web; desktop, Web and Cloud must use the matching protocol. Existing content, sync passwords and account keys stay in place; no data reset is needed. This describes the supported upgrade path, not a completed automatic-upgrade test. The sidebar and Settings show download progress and require an explicit Restart and update action.

The menu links to the current release's installation instructions, and the footer continues to link to the full release archive. Changelog dates identify development milestones; the GitHub Release is the source for the actual publication timestamp.

Codex uses its native App Server with CLI 0.163.0-alpha.10.2 exactly. All five Agents pages explain native approval, network and temporary-directory access, ordinary reads outside the workspace, the removal of Bottega's previous credential-path denials and internal read-only fences, and the limits of Plan and strict roles. The shared conversation presentation is retained. Bottega Dock remains Alpha and requires macOS 27.x and Apple silicon for the entire plugin. Replacement, recovery across logout or restart, and display/fullscreen combinations remain under validation. These plugin requirements do not change the main application's requirements.

Changelog

English and Simplified Chinese are synchronized from Bottega's public Changelog documentation. Japanese, French, and Spanish are maintained by this repository. Five snapshots under content/ let the site clone and build independently; tests enforce matching dates, order, and item counts.

When developing as the Bottega-Dev submodule, run pnpm sync:changelog to refresh the English and Chinese snapshots, then update the three maintained translations before building. Builds always read the committed snapshots without modifying them, so nested and independent checkouts publish the same content. Catalog parity is a mandatory build gate.

Development

pnpm install --ignore-workspace
pnpm dev
pnpm check   # catalog tests + fresh build/typecheck + i18n and SEO audits
pnpm build

pnpm sync:release is a release-time step rather than a build step: it needs the network, and pnpm build must stay offline.

pnpm check runs the complete production validation pipeline through pnpm build, so it cannot pass against stale or missing exported HTML. pnpm typecheck remains available for a quick source check. There is no lint script: Next.js 16 removed next lint, and this repository never carried an ESLint configuration of its own — a script that cannot run is worse than no script, because it reads like a gate that is holding.

The site is an independent Git repository nested inside Bottega-Dev. The --ignore-workspace flag keeps a direct install from binding its dependencies to the parent workspace. The development server runs at http://localhost:3000; the static production output is written to out/.

The production command deliberately uses Webpack. Next.js 16's default Turbopack trace can stall when this independent repository is checked out inside Bottega-Dev; selecting the stable builder keeps the documented gate deterministic:

pnpm build

Deployment

Vercel can build this repository directly with automatic Next.js framework detection. No Bottega desktop runtime, local account, or sibling checkout is required.

Speed Insights must be enabled once in the Vercel project; the client script is then served from the deployment's own /_vercel/speed-insights/ path, so no domain is added to the page's request set. On any other static host the script request fails and the component only logs a console note.

License

MIT