From 0691eafef22aaecedd6f0f727410b780b7cf5863 Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Wed, 8 Jul 2026 08:20:53 -0600 Subject: [PATCH] fix: resolve all broken internal links and nav contrast bug in light mode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes two confirmed bugs from a manual site audit: 1. 12 broken links (404s), traced to two root causes: - 7 nav/footer links pointed to trailing-slash directory URLs (/blog/, /solutions/, /docs/, /questions/, /compare/, /examples/, /use-cases/) but the site's build.format:'file' + trailingSlash: 'never' config emits flat *.html files, not dir/index.html. Every such link across the whole site (crumbs, sidebar, cards) has been corrected to the *.html form the build actually produces, and new landing pages were added for each of these sections (blog, compare, docs, questions, solutions, docs/guides) built from the real existing content in each folder, not fabricated pages. - 2 dead links to /docs/guides/capability-authoring.html and /docs/guides/workflow-authoring.html, referenced from the docs sidebar and several content pages, pointing to guides that were never built. Redirected to real existing content that already covers the same material (quickstart.html, concepts.html#workflows) rather than inventing new guide pages. - /examples/ and /use-cases/ had no page at all. Built both from content that already exists elsewhere on the site (the capability contract example used on the homepage/docs, and the use-case descriptions already on solutions pages) rather than fabricating new claims. 2. The docs sidebar was hardcoded HTML duplicated across all 5 docs pages, and had drifted into three different structures (quickstart and concepts each had a unique variant; architecture, cli-reference, and troubleshooting shared a third, the one with the dead guide links). Extracted to a single DocsSidebar.astro component with an `active` prop, used consistently by all 5 pages plus the two new docs index pages. 3. Nav contrast bug in light mode: the homepage hero has a hardcoded- dark background regardless of theme (brand art), but the nav's transparent (unscrolled) state used theme-aware --fg/--fg-muted, which flips to near-black in light mode — rendering the wordmark, nav links, and GitHub button nearly invisible against the dark hero. Scoped a fix to body.home only (verified no other page has a hardcoded-dark hero) forcing light nav text while transparent, falling back to normal theme-aware color once scrolled/solid. Verified: 0 broken internal links across all 88 built pages (up from 80 — 8 new landing/index pages), 0 canonical URLs with a trailing slash, docs sidebar renders identically (same links, correct active state) across all 5 docs pages plus computed styles confirming legible nav text in light mode on the homepage. Co-Authored-By: Claude Sonnet 5 --- src/components/DocsSidebar.astro | 49 +++++++ src/components/Footer.astro | 10 +- src/components/Nav.astro | 30 +++- src/layouts/BaseLayout.astro | 3 +- src/layouts/QuestionLayout.astro | 2 +- src/pages/about.astro | 2 +- src/pages/blog/ai-agents-need-contracts.astro | 4 +- src/pages/blog/index.astro | 42 ++++++ src/pages/blog/logic-duplication.astro | 4 +- src/pages/blog/runtime-assumptions.astro | 4 +- src/pages/blog/uma-explained.astro | 4 +- src/pages/blog/wasm-business-logic.astro | 4 +- src/pages/compare/index.astro | 40 ++++++ src/pages/compare/vs-function-calling.astro | 4 +- src/pages/compare/vs-microservices.astro | 4 +- src/pages/compare/vs-serverless.astro | 4 +- src/pages/docs/architecture.astro | 10 +- src/pages/docs/cli-reference.astro | 10 +- src/pages/docs/concepts.astro | 10 +- src/pages/docs/guides/index.astro | 37 +++++ src/pages/docs/guides/mcp-setup.astro | 4 +- src/pages/docs/guides/react-integration.astro | 4 +- src/pages/docs/index.astro | 41 ++++++ src/pages/docs/quickstart.astro | 10 +- src/pages/docs/troubleshooting.astro | 10 +- src/pages/examples/index.astro | 77 +++++++++++ src/pages/index.astro | 3 +- src/pages/questions/index.astro | 130 ++++++++++++++++++ .../what-is-a-contract-in-traverse.astro | 2 +- src/pages/roadmap.astro | 2 +- src/pages/solutions/ai-companies.astro | 2 +- src/pages/solutions/ecommerce.astro | 4 +- src/pages/solutions/enterprise.astro | 4 +- src/pages/solutions/fintech.astro | 4 +- src/pages/solutions/index.astro | 42 ++++++ src/pages/solutions/saas.astro | 4 +- src/pages/use-cases/index.astro | 62 +++++++++ 37 files changed, 621 insertions(+), 61 deletions(-) create mode 100644 src/components/DocsSidebar.astro create mode 100644 src/pages/blog/index.astro create mode 100644 src/pages/compare/index.astro create mode 100644 src/pages/docs/guides/index.astro create mode 100644 src/pages/docs/index.astro create mode 100644 src/pages/examples/index.astro create mode 100644 src/pages/questions/index.astro create mode 100644 src/pages/solutions/index.astro create mode 100644 src/pages/use-cases/index.astro diff --git a/src/components/DocsSidebar.astro b/src/components/DocsSidebar.astro new file mode 100644 index 0000000..0f02608 --- /dev/null +++ b/src/components/DocsSidebar.astro @@ -0,0 +1,49 @@ +--- +export interface Props { + active: string; +} +const { active } = Astro.props; + +const sections = [ + { + title: 'Getting Started', + links: [{ href: '/docs/quickstart.html', label: 'Quickstart' }], + }, + { + title: 'Core Concepts', + links: [ + { href: '/docs/concepts.html', label: 'Contracts' }, + { href: '/docs/architecture.html', label: 'Architecture' }, + ], + }, + { + title: 'Guides', + links: [ + { href: '/docs/guides.html', label: 'All Guides' }, + { href: '/docs/guides/mcp-setup.html', label: 'MCP Setup' }, + { href: '/docs/guides/react-integration.html', label: 'React Integration' }, + ], + }, + { + title: 'Reference', + links: [ + { href: '/docs/cli-reference.html', label: 'CLI Reference' }, + { href: '/docs/troubleshooting.html', label: 'Troubleshooting' }, + { href: '/examples.html', label: 'Examples' }, + { href: '/changelog.html', label: 'Changelog' }, + ], + }, +]; +--- + diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 738771d..4aa2536 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -17,8 +17,8 @@
Product
@@ -26,17 +26,17 @@
Developers
Company
diff --git a/src/components/Nav.astro b/src/components/Nav.astro index c96ba77..022a878 100644 --- a/src/components/Nav.astro +++ b/src/components/Nav.astro @@ -144,14 +144,14 @@ const { currentPath = '' } = Astro.props;
Resources
- + ◎ All Questions 55 answered questions - + ◷ Examples @@ -162,7 +162,7 @@ const { currentPath = '' } = Astro.props;
-
  • Blog
    • +
  • Blog
    • @@ -184,9 +184,9 @@ const { currentPath = '' } = Astro.props; \n\n
    \n
    \n
    \n
    Have a feature request?
    \n

    Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.

    \n \n
    \n
    "; +const _body = "
    \n\n
    \n Roadmap\n

    Where Traverse is going.

    \n

    This is the public roadmap. It is honest about what ships now, what is next, and what is further out. Nothing moves to planned without an approved governing spec. Nothing ships without test coverage.

    \n
    \n\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.7.0\n
    \n\n
    \n
    \n
    \n \n
    \n
    \n
    Core runtime
    \n
    Contract validation, WASM execution, trace production. The engine everything else runs on.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    CLI
    \n
    Build, run, validate, and inspect capabilities from the command line.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    MCP server
    \n
    Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Browser adapter
    \n
    Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    React demo
    \n
    Working example of browser-side capabilities in a React app.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    Expedition example
    \n
    End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    9 governing specs
    \n
    Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
    \n
    \n
    \n
    \n
    \n \n
    \n
    \n
    100% test coverage
    \n
    All shipped code is tested. No exceptions. Every future PR must maintain this.
    \n
    \n
    \n
    \n
    \n\n \n
    \n
    \n →\n

    Next

    \n v0.8.x\n
    \n\n
    \n\n
    \n
    \n
    Edge executor adapter
    \n planned\n
    \n

    Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.

    \n executor / edge\n
    \n\n
    \n
    \n
    Python SDK (experimental)
    \n planned\n
    \n

    Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

    \n sdk / python\n
    \n\n
    \n
    \n
    Expanded trace querying
    \n planned\n
    \n

    More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.

    \n tracing / cli\n
    \n\n
    \n
    \n
    Performance benchmarks page
    \n planned\n
    \n

    Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.

    \n docs / perf\n
    \n\n
    \n
    \n
    Additional example domains
    \n planned\n
    \n

    More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.

    \n examples\n
    \n\n
    \n
    \n\n \n
    \n
    \n ⋯\n

    Later

    \n exploring\n
    \n\n
    \n\n
    \n
    \n
    Cloud executor adapter
    \n exploring\n
    \n

    Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.

    \n executor / cloud\n
    \n\n
    \n
    \n
    AI-pipeline placement target
    \n exploring\n
    \n

    First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.

    \n ai / placement\n
    \n\n
    \n
    \n
    Multi-agent orchestration
    \n exploring\n
    \n

    Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.

    \n ai / orchestration\n
    \n\n
    \n
    \n
    Governance dashboard
    \n exploring\n
    \n

    Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.

    \n observability\n
    \n\n
    \n
    \n
    Extended SBOM tooling
    \n exploring\n
    \n

    Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.

    \n security / sbom\n
    \n\n
    \n
    \n
    Device executor
    \n exploring\n
    \n

    Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.

    \n executor / device\n
    \n\n
    \n
    \n\n
    \n\n \n
    \n
    Principles that govern this roadmap
    \n
    \n
    \n
    01
    \n
    Spec before code. Every item on this roadmap requires an approved governing spec before any implementation starts. The spec defines what the feature does, what inputs it takes, what constraints apply, and how it integrates with the rest of the system.
    \n
    \n
    \n
    02
    \n
    No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
    \n
    \n
    \n
    03
    \n
    Community input is welcome. Have a use case that is not covered? Open an issue on GitHub. Feature requests that come with a clear problem statement and a proposed spec have the best chance of moving forward.
    \n
    \n
    \n
    04
    \n
    Honest sequencing. Items in \"exploring\" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
    \n
    \n
    \n
    \n\n
    \n\n
    \n
    \n
    \n
    Have a feature request?
    \n

    Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.

    \n \n
    \n
    "; --- \n