Requested outcome

Expand the public Tripwire site in the private Boring-Software-Inc/tripwire-landing repo with:

1. A public /oss page that shows Tripwire working on real open source repositories.
2. A public /pricing page based on Tripwire's approved commercial model.
3. A useful site-wide navigation with real destinations.

This issue lives in v2 for product tracking. The implementation belongs in tripwire-landing, not in apps/web.

What the references establish

• Detail OSS makes real repository outcomes browseable, then gives visitors one relevant next action.
• Detail pricing states the billing basis, plan fit, included capabilities, and real product-specific questions.
• Context.dev uses its navigation to expose product areas, use cases, pricing, and docs instead of limiting the header to account actions.
• Context.dev pricing explains who each plan is for and makes the usage model understandable before signup.

Use these as information architecture references. Do not copy their visual identity, card treatments, copy, plan count, or page structure. The result must continue the existing Tripwire landing site's grid, typography, fire motif, spacing, and interaction language.

Information architecture

Recommended first cut:

• Product links to a real section on /.
• OSS links to /oss.
• Pricing links to /pricing.
• Preserve Sign in and Join the beta as the account actions.

Add Docs, About, or other links only when those destinations exist. No dead links, placeholder dropdowns, or navigation labels that point into the signed-in app.

The same destinations should be available in the footer. On small screens, use an accessible compact menu or another deliberate mobile layout. Do not squeeze the desktop row onto a phone.

/oss

Build a Tripwire-specific public proof page, not a generic customer grid.

Each published repository entry must use verified data and include enough provenance to audit it:

• forge and repository name
• repository URL
• a short explanation of what Tripwire protected or evaluated
• only real, sourced outcomes, such as runs evaluated, rules triggered, maintainer reviews, or forge actions
• a source URL or public case-study URL
• a verification date

Start with a curated static content source in tripwire-landing. Do not add a public v2 API for this page unless a separate decision approves one.

The page should:

• lead with a plain explanation of what the examples prove
• support a readable repository list or grid on desktop and a deliberate single-column mobile layout
• link each example to inspectable evidence when that evidence can be public
• end with one real action, currently Join the beta unless a more specific OSS onboarding flow exists
• omit the page from navigation until at least one verified repository can ship

Do not invent repositories, star counts, languages, rule matches, actions, customer quotes, or aggregate claims. If private customer data cannot be published, leave it out.

/pricing

Create the route and page shell only around founder-approved pricing. Before publishing, record the approved:

• plan names and count
• price and billing unit
• included limits or capabilities
• overage behavior, if any
• beta or free-plan policy
• CTA destination for each plan
• enterprise or contact path, if any
• cancellation, trial, and billing answers that are safe to state publicly

Keep these values in one typed content source so the cards, comparison content, metadata, and FAQ cannot drift.

The page should explain who each plan is for, what the customer pays for, the meaningful differences between plans, and what happens after the CTA.

Use the number of plans Tripwire actually has. Do not default to three equal cards or mark a middle plan as popular without a product reason. Include only questions that Tripwire can answer today. This issue does not authorize Stripe, billing, entitlements, checkout, or changes to the closed-beta access gate.

If pricing is not approved when implementation starts, stop at the content decision. Do not publish plausible placeholder prices.

Shared navigation and page behavior

• Extract or extend the shared public Nav and Footer rather than duplicating markup per route.
• Show the current page with aria-current="page".
• Keep every destination usable by keyboard with a visible focus state.
• Keep touch targets at least 44 by 44 pixels and prevent horizontal overflow.
• Preserve reduced-motion behavior.
• Add page-specific metadata and include /oss and /pricing in app/sitemap.ts.
• Keep existing tracking parameters and analytics behavior on app-domain CTAs.

Likely implementation surfaces in tripwire-landing:

• app/oss/page.tsx
• app/pricing/page.tsx
• app/sitemap.ts
• components/landing/sections.tsx or a smaller shared navigation module
• lib/content.ts or focused typed content modules
• app/landing.css

Follow that repo's Next.js version instructions before editing.

Out of scope

• billing, checkout, subscriptions, or entitlement enforcement
• new v2 API endpoints
• public customer data without approval
• fabricated product claims or placeholder metrics presented as real
• a visual clone of Context.dev or Detail
• unrelated changes to the signed-in product

Done when

• /, /oss, and /pricing share a coherent desktop and mobile navigation.
• Every navigation and footer link resolves to a real destination.
• /oss contains only approved, source-backed repository examples with verification dates.
• /pricing contains only founder-approved prices, limits, billing language, and CTA destinations.
• Both routes have unique title, description, canonical metadata, and sitemap entries.
• Keyboard navigation, visible focus, 200% text zoom, reduced motion, and 360px through desktop layouts have been checked.
• The site build and lint pass with no console errors.
• A reviewer clicks every link and CTA on all three public routes and records the destination.
• The PR includes desktop and mobile screenshots for /, /oss, and /pricing.