website

Imported from LordGhostX/grantline (website/AGENTS.md). Install upstream with npx skills add LordGhostX/grantline --skill website. Copyright stays with the author.

Website Working Memory

Purpose and boundary

This directory owns Grantline's public website, landing page, documentation surface, and future browser-facing demo. It is a Next.js App Router application using Fumadocs MDX for documentation content. It does not own contract enforcement, backend orchestration, SDKs, canonical deployment manifests, or private operational records; its checked-in deployment copies exist only as self-contained docs build inputs.

The website explains the authority model and links to the canonical repository at https://github.com/LordGhostX/grantline. Public-facing product copy uses UK English, including authorisation, authorised, and tokenised.

Layout

website/
├── AGENTS.md                 # Website-local working memory
├── package.json              # Bun scripts and dependencies
├── bun.lock                  # Checked-in dependency lockfile
├── next.config.mjs           # Next.js and Fumadocs MDX integration
├── source.config.ts          # Fumadocs content collection configuration
├── eslint.config.mjs         # ESLint flat configuration
├── .env.example              # Safe public site URL configuration template
├── data/deployments/         # Website-local deployment manifest copies
├── content/docs/             # Markdown and MDX documentation source
└── src/
    ├── app/                  # App Router pages, layouts, routes, and metadata
    ├── components/           # Shared website and MDX components
    └── lib/                  # Content loaders, site configuration, public links, and helpers

.source/ is generated by fumadocs-mdx and remains ignored. .next/, node_modules/, and build output are also ignored and must not be added to the repository.

Environment

NEXT_PUBLIC_SITE_URL is the preferred canonical URL and drives metadata, robots.txt, sitemap.xml, and absolute LLM document URLs through src/lib/site.ts. If it is absent, the server-only config derives https://${VERCEL_URL} for Vercel deployments; local development still needs .env.local unless the process supplies one of those variables. Keep site.ts out of client components because VERCEL_URL is not exposed to the browser and importing it into the landing page can fail hydration. Browser-facing repository and X links belong in src/lib/site-links.ts. Copy .env.example to .env.local for a stable local origin, and configure NEXT_PUBLIC_SITE_URL in the hosting provider when a canonical production domain is available. Do not put credentials, private keys, API tokens, or other secrets in this directory or its working-memory files.

NEXT_PUBLIC_DEMO_AGENT_ADDRESS and NEXT_PUBLIC_XLAYER_TESTNET_EXPLORER_URL are intentionally public configuration; the former identifies the testnet demo wallet and the latter identifies the public transaction explorer. DEMO_AGENT_PRIVATE_KEY is server-only and must never be imported by client code or exposed through a NEXT_PUBLIC_ variable. The demo signing route is limited to the configured X Layer Testnet agent and is not a production signing service.

The layout intentionally uses next/font/google for Geist and Geist Mono, so builds need network access to fetch the fonts. Keep that behaviour unless the product explicitly chooses a self-hosted font strategy.

Commands

Run these commands from website/:

bun install
bun run dev
bun run lint
bun run typecheck
bun run build
bun run start
bun audit
bun run copy:deployments

bun install runs the postinstall script, which regenerates Fumadocs' .source files. Run bun run postinstall directly when content collection types or generated entries need to be refreshed. bun run copy:deployments is a manual local command that copies the contents of ../contracts/deployments/ into data/deployments/; it is not part of installation, development, or production builds. Next.js 16 no longer provides next lint; linting is owned by the ESLint CLI through bun run lint.

Application conventions

Fumadocs content is defined in source.config.ts, loaded through src/lib/source.ts, and rendered under /docs. The /docs/:path*.mdx rewrite exposes processed Markdown at the corresponding .mdx URL for copy and LLM workflows. Keep the search route, /llms.txt, /llms-full.txt, and /llms.mdx aligned with the Fumadocs source loader when the content model changes.

React components in MDX do not automatically become useful Markdown in copy or LLM outputs. When a component carries content that those outputs need, add a Markdown renderer to src/lib/get-llm-text.ts and keep it derived from the same source data as the visual component.

When the browser demo and single-entrypoint deployment flow are stable, add a Fumadocs guide with tabbed code examples for the complete user loop: creating and funding a Vault, creating a Mandate and assigning an agent, submitting a signed Action Plan, and inspecting the result. Keep the prose around the tabs visible, derive commands from the current implementation, and do not document the present multi-contract deployment shape as the future user workflow.

Use next/link for internal navigation such as /docs; use normal anchors for in-page hash links and external destinations. Keep the canonical landing page's authorisation examples clearly illustrative until they are connected to live records or contract evidence. The canonical landing page uses the category-first, enforcement-led story and must remain separate from live demo integrations until those flows are safe and real. Do not present placeholder href="#" actions as live product integrations when those CTAs are made functional. The landing page and docs shell include Vercel Web Analytics at the root layout; keep it independent of the server-only site URL configuration.

The website may describe the current contracts MVP, but it must not imply that deferred backend or product capabilities already exist. Concepts are public product explanations; the Security model, enforcement, and execution pages connect those explanations to the contracts; guides and reference pages retain exact integration detail. The planned Guardians concept is the only conceptual future exception outside the Roadmap. Use Fumadocs callouts only at meaningful current-versus-future boundaries. The current contract-backed evidence is documented in ../contracts/AGENTS.md; update public copy when that evidence or the product brief changes.

The browser demo's Escalations page now reads historical records through the scoped EscalationManager indexes, shows submittedBy, sorts active records before finalized records, and uses the existing controller approval, denial, and approved-execution entrypoints. Its ABI and deployment manifest must be refreshed together after a fresh contract deployment.

The deployment tables in the contracts documentation use the ordered registry at the top of src/components/docs/deployment-manifest-table.tsx to map display labels to files under data/deployments/. Run bun run copy:deployments manually after a contracts deployment change, then add or adjust the registry entry when the deployment should be included or reordered. The copy command does not delete files or update the registry. These copies stay inside the website so Vercel and Docker builds that use website/ as their context do not depend on files outside the package.

Documentation update workflow

When a product or contract feature changes, use the following order:

1. Confirm the behaviour against the contracts, tests, deployment manifest, and ../contracts/AGENTS.md. Treat the implementation as current only when the evidence supports it; otherwise label the feature as planned or deferred.
2. Update the durable concept only when the product model changes. Keep concepts focused on stable ideas such as authority, custody, delegation, conditions, decisions, and traceability, so adding an action type or changing a field does not require rewriting several pages.
3. Put exact fields, units, action types, versions, thresholds, event names, contract roles, and transaction mechanics in the relevant enforcement, execution, guide, or reference page. Add a roadmap page when the feature is direction rather than shipped behaviour.
4. Update the docs landing page when the current MVP or deferred feature summary changes, and update navigation metadata when adding, moving, or removing pages. Keep links, /llms.txt, /llms-full.txt, /llms.mdx, sitemap entries, and page metadata aligned with the content tree.
5. Update this file's current status and deferred-work notes when the website surface, documentation coverage, or public integration assumptions change. Record broader architecture or product decisions in the root AGENTS.md as well.
6. Run bun run postinstall, bun run lint, bun run typecheck, bun run build, and bun audit from this directory. Check generated routes and links when pages or navigation change, and run git diff --check before handoff.

Current status and handoff

The Next.js and Fumadocs foundation is working. The canonical category-first landing page is implemented in src/app/page.tsx with its landing stylesheet in src/app/landing.css; the docs shell, MDX source loader, search, LLM routes, favicon, robots route, sitemap, and Vercel Web Analytics are implemented. The /app demo now has a receipt-driven X Layer Testnet control surface for connecting a wallet, creating/funding/withdrawing from Vaults, pausing Vaults, creating Mandates, pausing or revoking Mandates, and signing and executing native transfer Action Plans through Grantline. Action Plans for the configured demo agent use the server-side testnet signing route, while other Mandates continue using the connected agent wallet; the connected wallet still submits the execution transaction. It remains a native-asset-only testnet flow and does not imply production execution. The docs now use a layered public-to-technical progression: Concepts explain the product model and planned Guardian direction, the Security model plus Enforcement and Execution explain the contract-backed path, Guides show read-only and integration workflows, Reference records exact fields and events, and one Roadmap page covers future mandate policy, destination and capability policies, SDK/API integration, Guardians, and indexing with Decision Receipts.

The package currently uses Next.js 16.3.0, React 19.2.8, Fumadocs Core/UI 16.14.3, Fumadocs MDX 15.2.3, @vercel/analytics 2.0.1, Tailwind CSS 4.3.3, and Bun-managed dependencies. ESLint 9.39.5 with eslint-config-next@16.3.0 is the compatible linting setup; ESLint 10 currently fails inside the installed React plugin stack even though the Next config's peer range permits it. TypeScript remains on the declared ^5 line.

The production build and route smoke tests pass with network access. The site URL override has been verified with a preview build, and the generated robots.txt, sitemap.xml, and LLM document URLs use the configured origin; Vercel deployments can use VERCEL_URL when the explicit variable is absent. Sitemap entries intentionally use the current generation date for lastModified because the current landing page and concept docs do not provide reliable source modification dates.

The placeholder Activity surface has been removed; indexed Activity records remain deferred until the API and indexer exist. Deferred website work also includes a tabbed Fumadocs guide for the complete Vault-to-signed-Action-Plan loop, social preview assets, and connecting richer records or receipt views. The Authority page now provides read-only indexed Mandate, effective-rule, Preflight, and delegation-lineage inspection. The roadmap describes future capabilities at product level because destination and capability policies, shared cumulative budgets, Guardians, a Grantline SDK, a public API, an indexer, and assembled Decision Receipts do not exist yet. The current integrator guides use raw contract calls and external wallet tooling for the same reason. The current Security model documents the owner-controlled Vault boundary and must be revised when the planned Vault creation and ownership architecture changes. Do not add wallet signing, capital movement, or production transaction submission to the landing page without an explicit product and security review.

Working-memory rules

Update this file when the website boundary, framework/content architecture, deployment configuration, public terminology, or user-facing integration assumptions change. Keep implementation details here only when they affect future website work; put deeper component or content-authoring guidance in a nearer package or content-local file if one is introduced.

Never record secrets or transient command output here. When a deployment or public URL changes, update the environment guidance and the relevant site configuration together.

This is NOT the Next.js you know

This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in node_modules/next/dist/docs/ (resolved from this file's directory; in monorepos the next package may not be visible from the repo root) before writing any code. Heed deprecation notices.

This block is written and re-added by next dev — verify at node_modules/next/dist/server/lib/generate-agent-files.js. Removing it from a diff only re-creates the uncommitted change; committing it with your work keeps the tree clean.