app.web-landing

@lssm-tech/app.web-landing

Next.js delivery shell for the public ContractSpec website: technical substrate marketing, docs, registry pages, /llms*, and selected operate/sandbox surfaces.

What It Does

• Owns the app shell, metadata, OG generation, route wrappers, and public site delivery.
• Publishes the marketing experience while delegating most page-body composition to @lssm-tech/bundle.marketing.
• Serves docs, registry, sandbox, and operate surfaces while keeping their shared shell consistent with the public brand system.
• Shares example preview rendering across docs, /templates, and /sandbox, with rich UI for UI-backed examples and fallback cards for the rest of the discoverable catalog.
• Hosts the CompanyOS adaptive Request-to-Verified-Proof journey through an app-owned preview override, allowlisted same-origin no-store operation route, and browser-safe fetch client while keeping runtime composition server-only and Playwright outside the client graph.
• Publishes /llms, /llms.txt, /llms-full, /llms-full.txt, and package-specific /llms/[slug] endpoints for agent-friendly repo guidance.
• Keeps Managed CompanyOS agent guidance aligned with the real-organization rollout runbook: Better Auth membership and active organization are authoritative, NDconsulting history is preserved, and rollout/canary/rollback remain operator-gated.
• Documents design-system adoption guidance for shared interaction patterns such as ObjectReferenceHandler and AdaptivePanel, including human-readable docs and agent-facing /llms* prompts.
• Documents ContractSpec translation runtime guidance, including the optional i18next adapter, SSR/hydration rules, production checks, and an agent implementation prompt.
• Documents data-exchange flexible import-template guidance at /docs/guides/data-exchange-import-templates, including developer templates, user remapping flows, server dry-runs, format profiles, verification commands, and copy-ready prompts.

Template preview and LLMS sync workflow

Public example preview changes must keep human and agent-facing surfaces aligned:

• /templates, /docs/examples/<key>, and /sandbox?template=<key> consume the same module examples preview surface so inline UI and fallback behavior stay consistent.
• /llms, /llms.txt, /llms-full, /llms-full.txt, and /llms/[slug] must be regenerated or verified after README changes that document example exports, preview support, route inventory, or release workflow expectations.
• Rich previews are deterministic local fixtures by default. The CompanyOS proof demo is the explicit governed exception: the host override injects the same-origin runtime client into the generic preview. Live mode starts an ephemeral loopback fixture and never targets production. The reliable public path is the committed validated recording; live Chromium is opt-in and must pass a real preflight.
• Public key or alias changes are compatibility-sensitive. Preserve existing examples.* and normalized lookup behavior unless a release capsule explicitly documents and tests the migration.

Architecture

• src/app/ contains route groups for marketing, docs, sandbox, operate, registry, and API endpoints.
• src/components/ contains app-local shell concerns such as header, footer, SEO helpers, and local route UI.
• public/llms*.txt contains machine-readable monorepo guidance exposed directly from the site.
• scripts/generate-llms-full.mjs regenerates the public aggregated README corpus used by /llms-full.txt.

This package should stay thin:

• marketing page narratives belong in @lssm-tech/bundle.marketing
• docs and library composition belong in @lssm-tech/bundle.library
• shared reusable UI primitives belong in lower layers

Public Entry Points and Topics

Static and generated public surfaces currently delivered by this app:

• Marketing and conversion: /, /product, /pricing, /templates, /contact, /cofounder, /contribute, /design-partner, plus legal pages at /legal/privacy and /legal/terms.
• Release and registry: /changelog, /changelog/[version], /registry/featured, /registry/packs, /registry/packs/[name], /registry/packs/[name]/versions/[version], and /registry/publish.
• Feature catalog: /features, /features/[key], and feature detail routes for operations, events, forms, presentations, and DataViews.
• Docs shell: /docs and topic groups for getting started, specs, guides, libraries, the first-class Agent Ecosystem at /docs/agents, domains, safety, knowledge, integrations, architecture, advanced operation, comparisons, ecosystem, examples, Studio, intent pages, generated reference, manifesto, and ops.
• Agent Ecosystem docs: /docs/agents plus focused guides for getting started, two all-in-one examples, multi-agent operation, governed self-improvement, durable runtime, self-maintaining APIs, replaceable deployment topologies, and production readiness. The Release Steward guide covers verified, human-approved migration pull requests. The Company Intelligence Scout guide covers bounded public-web research, source citations, 30-day person/contact retention, and policy-controlled recruiting or sales drafts and sends.
• Docs guide topics: installation, private registry access, Hello World, compatibility, developer tools, DataViews, troubleshooting, Next.js endpoint adoption, imported codebases, contract intelligence, codebase graphs, validation/typing, ContractSpec theme, contract-driven forms, i18n, Drizzle database setup, data-exchange import templates, docs/client/schema generation, docs pipeline, module bundles, mobile navigation, Builder workbench/spec packs/intelligence, Connect, provider-backed knowledge, release capsules, and CI diff gating.
• Docs library topics: contracts, schema, runtime, translation runtime, UI kit, UI kit web, design system, application shell, cross-platform UI, data views, personalization, observability, resilience, multi-tenancy, workflow composer, workflows, AI agent, analytics, content generation, cost tracking, data backend, evolution, GraphQL, growth, overlay engine, SLO, support bot, and testing.
• Docs integration topics: setup/model docs plus OpenAI, Mistral, Qdrant, Gmail, Google Drive, Google Calendar, Stripe, Twilio, GitHub, Slack, Postmark, Powens, Resend, S3, ElevenLabs, WhatsApp Meta, WhatsApp Twilio, circuit breakers, and health routing.
• Examples and sandbox: /docs/examples, /docs/examples/[exampleKey], /docs/examples/data-grid-showcase, /templates, /sandbox, and /graph-showcase.
• Operate surfaces: /operate/builder/workspaces/[workspaceId], /operate/builder/workspaces/[workspaceId]/mobile-review/[cardId], /operate/pm/issues/[issueId], and API proxy routes under /api/operate/builder/*.
• Agent-facing discovery: /llms, /llms.txt, /llms-full, /llms-full.txt, /llms/[slug], and /docs/llms.txt via static files and rewrites.
• Public APIs: /api/changelog, /api/chat, /api/graphql/*, /api/mcp, /api/og, /api/examples/companyos-ai-solutions-engineer-poc/[operation], and operate builder API routes.

Route changes here affect SEO, external links, sitemap output, and agent-discovery flows. Keep src/app/sitemap.ts, next.config.mjs rewrites, public/llms*.txt, this README, and route wrappers aligned.

Marketing contract boundary

The (landing-marketing) route group is wrapped with the shared marketing contract boundary and backed by the ContractSpec route contract registry from @lssm-tech/bundle.marketing/content. Static routes, deterministic feature/changelog routes, and runtime-only registry pack families must stay covered by src/marketing-contract-system.test.ts when route files move or change.

Local Commands

• bun run dev — bun --bun next dev
• bun run start — bun --bun next start
• bun run build — bun --bun next build
• bun run lint — bun run lint:fix
• bun run lint:check — biome check .
• bun run lint:fix — biome check --write --unsafe --only=nursery/useSortedClasses . && biome check --write .
• bun run clean — rimraf .next dist .turbo
• bun run llms:generate — bun scripts/generate-llms-full.mjs
• bun run build:types — tsgo --noEmit
• bun run test:unit — invoke Bun’s test runner directly from the repository root, scoped to this app. The command must begin with bun test; placing --cwd before test invokes the root package script and unrelated suites.
• bun run test — run the root-safe unit suite, then the package-context CompanyOS route proof.
• bun run test:companyos-route — verify the CompanyOS browser client and server-only live route proof with the package-local Bun test configuration.

For a customer-call rehearsal, run:

bun run --cwd examples/companyos-ai-solutions-engineer-poc precall

This validates the example/profile, committed recording and hashes, Chromium plus fixture behavior, and the same-origin host route. Optional request analysis is host-only, disabled by default, and requires CONTRACTSPEC_COMPANYOS_LIVE_ANALYSIS=1 plus approved provider configuration. It has no tools and returns analysis-only authority. Live proof is separately disabled unless CONTRACTSPEC_COMPANYOS_LIVE_BROWSER=1; even then, the route requires a successful ready-live probe and an exact prepared-generation session binding before it creates the loopback fixture.

The live CompanyOS route proof is opt-in during generic bun test discovery. Run it through test:companyos-route: Bun's repository-root project configuration can corrupt the loopback Playwright proof state before mutation, while the package-local server test configuration observes and resets the exact expected state. The scoped command remains part of bun run test, so CI keeps the live-browser source, status, observed-state, and reset assertions.

Notes

• Branding changes in this package must stay aligned with root docs, generated root AGENTS content, and public/llms.txt.
• When updating the public shell, verify that docs and /llms* remain readable; this package serves more than the marketing homepage.
• Keep /docs/libraries/design-system and /llms/lib.design-system aligned when documenting object references, adaptive panels, or other interaction primitives that downstream apps should adopt consistently.
• Keep /docs/libraries/translation-runtime, /llms/[lib.translation-runtime], and @lssm-tech/lib.translation-runtime README guidance aligned when documenting i18n runtime or adapter behavior.
• Keep /docs/guides/data-exchange-import-templates, /llms/lib.data-exchange-core, /llms/lib.data-exchange-client, and /llms/lib.data-exchange-server aligned when documenting import templates, flexible column mapping, dry-runs, or mapping-review prompts.

Static-generation resource budget

bun run build retains the required TypeScript prebuild and generates every configured route. CONTRACTSPEC_BUILD_CPU_BUDGET accepts a positive integer allocation; page-data/static generation use at most four workers and two page renders per worker. Without an allocation, the worker count follows local availableParallelism() up to the same four-worker cap. Invalid overrides fail configuration instead of starting an oversized pool. Turbo hashes both the allocation and the budget helper.

The failed Railway build had compiled successfully before launching 47 workers against a 4-CPU/16-GB allocation. A local full build with budget four completed all 1,644 static tasks in 58.41 seconds overall, including the TypeScript gate. The route count reflects that release snapshot; live runner memory/cgroup qualification remains required and should use the current route inventory.