From bb83701344e4dcf2e840acb6f31386b79befd329 Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Thu, 9 Jul 2026 08:44:44 -0600 Subject: [PATCH] feat: rebuild footer to match Lovable.dev's dense multi-column structure Restructures the footer from 4 columns (brand + 3) to 5 (brand + 4: Product, Resources, Support, Company), matching the dense multi-column pattern used at lovable.dev/home -- uppercase section labels, a muted link list per column, a social icon row under the brand block, and a two-part bottom bar (copyright + license link). Note: the Chrome extension used for live browser inspection wasn't reachable while building this, so column/link organization is matched structurally (verified via a content fetch of the live page) rather than pixel-verified against Lovable's exact computed styles. Colors, type, and spacing use Traverse's own existing design tokens rather than copying Lovable's palette. Content is 100% real Traverse pages -- no fabricated links. This surfaced two previously orphaned pages with zero incoming nav/footer links (/compare.html was fixed earlier this session; /faq.html is fixed here) and both are now linked. faq.astro also had the same placement-model inaccuracy corrected earlier this session ("run it anywhere... same binary... without rewrite") -- fixed to the device-independent, client-decides framing. Co-Authored-By: Claude Sonnet 5 --- public/assets/css/components.css | 18 +++++++++++------- src/components/Footer.astro | 21 ++++++++++++++++++--- src/pages/faq.astro | 2 +- 3 files changed, 30 insertions(+), 11 deletions(-) diff --git a/public/assets/css/components.css b/public/assets/css/components.css index 846ca78..4219de3 100644 --- a/public/assets/css/components.css +++ b/public/assets/css/components.css @@ -368,14 +368,15 @@ } .footer-grid { display: grid; - grid-template-columns: 2fr repeat(3, 1fr); - gap: 3rem; + grid-template-columns: 1.6fr repeat(4, 1fr); + gap: 2.5rem; padding-bottom: 2.5rem; margin-bottom: 2rem; border-bottom: 1px solid var(--border); } -@media (max-width: 900px) { .footer-grid { grid-template-columns: 1fr 1fr; } } -@media (max-width: 540px) { .footer-grid { grid-template-columns: 1fr; gap: 2rem; } } +@media (max-width: 1024px) { .footer-grid { grid-template-columns: 1.6fr repeat(2, 1fr); row-gap: 2.5rem; } } +@media (max-width: 640px) { .footer-grid { grid-template-columns: 1fr 1fr; gap: 2rem; } } +@media (max-width: 420px) { .footer-grid { grid-template-columns: 1fr; } } .footer-brand p { font-size: 0.8125rem; color: var(--fg-muted); margin-top: 0.75rem; max-width: 24ch; line-height: 1.6; @@ -396,10 +397,13 @@ .footer-bottom { display: flex; align-items: center; justify-content: space-between; font-size: 0.8rem; color: var(--fg-subtle); + flex-wrap: wrap; gap: 0.75rem; } -.footer-social { display: flex; gap: 1rem; } -.footer-social a { color: var(--fg-subtle); transition: color 0.15s; } -.footer-social a:hover { color: var(--fg-muted); } +.footer-bottom a { color: var(--fg-subtle); transition: color 0.15s; } +.footer-bottom a:hover { color: var(--fg-muted); } +.footer-social { display: flex; gap: 1rem; margin-top: 1.25rem; } +.footer-social a { color: var(--fg-subtle); transition: color 0.15s; display: flex; } +.footer-social a:hover { color: var(--fg); } /* ─── CTA band ───────────────────────────────────────────────────────────── */ .cta-band { diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 9e2ac38..cad3989 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -8,11 +8,16 @@ Traverse. -

Contract-driven WASM runtime for portable business capabilities.

+

Contract-driven WASM runtime for device-independent business capabilities.

v0.7.0 Apache 2.0
+
+ + + +
Product
@@ -25,12 +30,21 @@
-
Developers
+
Resources
+
+
+
Support
+
@@ -46,6 +60,7 @@
© 2026 Enrico Piovesan · Traverse Framework + Apache 2.0 · License
diff --git a/src/pages/faq.astro b/src/pages/faq.astro index 3642b55..88223cd 100644 --- a/src/pages/faq.astro +++ b/src/pages/faq.astro @@ -1,7 +1,7 @@ --- import SubpageLayout from '@layouts/SubpageLayout.astro'; -const _body = "
\n
\n FAQ\n

Your questions, answered.

\n

Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.

\n
\n
\n\n
\n
\n\n \n\n
\n\n \n
\n
Getting Started
\n
\n\n
\n \n
\n

Traverse is a runtime that lets you write business logic once in Rust, compile it to WASM, and run it anywhere. Browser, edge, cloud, AI pipeline. Same binary, same behavior, no rewrite.

\n

Each capability is wrapped in a machine-readable contract. The runtime checks inputs and outputs against that contract before anything runs. You get a trace artifact showing exactly what happened and why.

\n
\n
\n\n
\n \n
\n

To write new capabilities from scratch, yes. Rust compiles to WASM and gives you the control and safety the runtime expects.

\n

But you can call Traverse from JavaScript, Python, or any language with a WASM host. If someone else compiled the capability, you consume it through the SDK without touching Rust at all. The Python SDK is on the roadmap for v0.8.x.

\n
\n
\n\n
\n \n
\n

v0.7.0 ships with 100% test coverage and 9 governing specs. The core runtime, CLI, browser adapter, and MCP server are all working and testable today.

\n

Some advanced executor targets are still planned. If your use case maps to what is shipping now, you can build on it. Check the roadmap to see what lands when.

\n
\n
\n\n
\n \n
\n

Right now: browser via the browser adapter, server-side via the Rust runtime, and AI pipelines via the MCP server. The React demo and Expedition example both run in browser.

\n

Edge and cloud executor adapters are next on the roadmap. Device is further out. All of them run the same WASM binary when they ship.

\n
\n
\n\n
\n
\n\n \n
\n
Technical
\n
\n\n
\n \n
\n

Microservices separate deployment. Traverse separates the capability from the runtime entirely. Your pricing logic does not care whether it runs in a browser or on a server. A microservice always runs where you deployed it.

\n

There is also no network call when a capability runs close to the user. The WASM binary runs in-process. That changes the latency profile completely.

\n
\n
\n\n
\n \n
\n

Serverless functions are tied to a cloud provider and a specific execution model. You write a function for AWS Lambda or Cloudflare Workers and it runs there. Traverse capabilities are not tied to any provider or platform.

\n

The contract system is also different. Serverless functions have no formal contract. Traverse validates inputs and outputs every time, which means it can catch integration errors before they reach production.

\n
\n
\n\n
\n \n
\n

WASM runs near-native. The contract validation adds a fixed overhead per call, not per computation unit. For most business logic workloads this is noise. A formal benchmarks page is planned for v0.8.x.

\n

The bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.

\n
\n
\n\n
\n \n
\n

Every capability has a contract file that declares what inputs it accepts, what outputs it produces, which placement targets it supports, and what constraints apply. The runtime reads this file before execution.

\n

If you try to call a capability with the wrong inputs, the runtime rejects it before the WASM even runs. The trace artifact records the full decision. Nothing executes without a passing contract check.

\n
\n
\n\n
\n \n
\n

WASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.

\n

If you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.

\n
\n
\n\n
\n \n
\n

The runtime catches the failure, records it in the trace artifact with a timestamp and the failing contract clause, and returns a structured error. Nothing silent or ambiguous.

\n

Contract violations fail before execution. Runtime errors fail during execution. Both produce a trace. You always know exactly where the failure happened and what the runtime saw at that point.

\n
\n
\n\n
\n \n
\n

Start with the trace artifact from the failed call. It records input values, contract checks, execution steps, and output values. Most problems are visible there without any additional tooling.

\n

The CLI includes a trace subcommand for inspecting trace files. The MCP server exposes trace querying to AI agents. Expanded trace querying is planned for v0.8.x.

\n
\n
\n\n
\n \n
\n

JavaScript works today via the browser adapter. You load the WASM module and call capabilities through the JS bindings. The React demo shows exactly how this looks.

\n

Python SDK is experimental and on the roadmap for v0.8.x. Other language bindings depend on community interest and WASM host availability in that ecosystem.

\n
\n
\n\n
\n \n
\n

A trace is a structured record produced after every capability execution. It captures the inputs the runtime received, which contract clauses were checked, the execution path taken, and the outputs produced.

\n

This matters for two reasons. First, it makes debugging fast. Second, it makes auditing possible. If a pricing rule applied a discount you did not expect, the trace shows you exactly why. That kind of explainability is hard to add after the fact.

\n
\n
\n\n
\n
\n\n \n
\n
Licensing & Maintenance
\n
\n\n
\n \n
\n

Apache 2.0 is a permissive open source license. You can use Traverse commercially, modify it, distribute it, and build closed-source products on top of it. You need to include the original license notice.

\n

There are no royalties and no restrictions on commercial use. If you are evaluating this for a company, legal counsel can confirm, but Apache 2.0 is one of the most business-friendly open source licenses available.

\n
\n
\n\n
\n \n
\n

Enrico Piovesan. One person. This is not a VC-funded team with a support contract. It is research engineering built over years of real product work, published as open source.

\n

The upside is that the design is intentional and consistent. The tradeoff is that response times on issues depend on one person's capacity. Community contributions are welcome and encouraged.

\n
\n
\n\n
\n
\n\n \n
\n
AI and MCP
\n
\n\n
\n \n
\n

The MCP server exposes Traverse capabilities as tools that AI agents can call. The agent reads the capability contract to understand what the tool does, what inputs it takes, and what it returns. No custom glue code needed.

\n

Because every call produces a trace, the agent can inspect what actually happened and reason about it. This turns capabilities into auditable building blocks for AI workflows, not just function calls that return an opaque result.

\n
\n
\n\n
\n \n
\n

Function calling gives an agent a schema and an endpoint. The agent calls the function and gets a response. There is no contract enforcement, no placement logic, and no trace.

\n

With Traverse, the agent is working with governed capabilities. Inputs are validated before execution. The result includes a trace. The contract tells the agent exactly what the capability is allowed to do. That is a different level of trust and observability.

\n
\n
\n\n
\n \n
\n

Contract-Driven AI Development, or C-DAD, is a methodology that asks AI agents to navigate systems that have machine-readable contracts rather than undocumented code. If your capabilities have contracts, an AI agent can read them and reason about the system correctly.

\n

Without contracts, AI agents are guessing based on naming conventions and comments. With contracts, they have a precise definition of what each capability does, what it accepts, and what constraints apply. Enrico published the C-DAD whitepaper as the theoretical foundation for this approach.

\n
\n
\n\n
\n \n
\n

Universal Microservices Architecture, or UMA, is the architectural pattern Traverse implements. The core idea is that business capabilities should be portable across every runtime, not tied to the environment they were first deployed in.

\n

The UMA book on Amazon covers the theory in 13 chapters with runnable Rust and WASM examples. Traverse is the production runtime that makes those ideas executable. More at universalmicroservices.com.

\n
\n
\n\n
\n
\n\n \n
\n
Community
\n
\n\n
\n \n
\n

Open an issue or a pull request on GitHub. Issues are the best place to start for new capability ideas, bug reports, or questions that are not answered here.

\n

One rule: nothing ships without a governing spec. If you want to add a feature, the spec comes first. This keeps the codebase navigable and the intent documented regardless of who makes a change.

\n
\n
\n\n
\n
\n\n
\n
\n
\n\n
\n
\n
\n
Ready to build?
\n

The quickstart gets you to a running capability in under 10 minutes. No account required.

\n
\n Read the quickstart\n View on GitHub →\n
\n
\n
"; +const _body = "
\n
\n FAQ\n

Your questions, answered.

\n

Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.

\n
\n
\n\n
\n
\n\n \n\n
\n\n \n
\n
Getting Started
\n
\n\n
\n \n
\n

Traverse is a runtime that lets you write a business capability once in Rust and compile it to WASM. The binary is device-independent and runs on any client without modification, executing locally by default. If the client decides to, based on its own heuristics, it can delegate a subset of the capability to the server. Same binary, same behavior, no rewrite.

\n

Each capability is wrapped in a machine-readable contract. The runtime checks inputs and outputs against that contract before anything runs. You get a trace artifact showing exactly what happened and why.

\n
\n
\n\n
\n \n
\n

To write new capabilities from scratch, yes. Rust compiles to WASM and gives you the control and safety the runtime expects.

\n

But you can call Traverse from JavaScript, Python, or any language with a WASM host. If someone else compiled the capability, you consume it through the SDK without touching Rust at all. The Python SDK is on the roadmap for v0.8.x.

\n
\n
\n\n
\n \n
\n

v0.7.0 ships with 100% test coverage and 9 governing specs. The core runtime, CLI, browser adapter, and MCP server are all working and testable today.

\n

Some advanced executor targets are still planned. If your use case maps to what is shipping now, you can build on it. Check the roadmap to see what lands when.

\n
\n
\n\n
\n \n
\n

Right now: browser via the browser adapter, server-side via the Rust runtime, and AI pipelines via the MCP server. The React demo and Expedition example both run in browser.

\n

Edge and cloud executor adapters are next on the roadmap. Device is further out. All of them run the same WASM binary when they ship.

\n
\n
\n\n
\n
\n\n \n
\n
Technical
\n
\n\n
\n \n
\n

Microservices separate deployment. Traverse separates the capability from the runtime entirely. Your pricing logic does not care whether it runs in a browser or on a server. A microservice always runs where you deployed it.

\n

There is also no network call when a capability runs close to the user. The WASM binary runs in-process. That changes the latency profile completely.

\n
\n
\n\n
\n \n
\n

Serverless functions are tied to a cloud provider and a specific execution model. You write a function for AWS Lambda or Cloudflare Workers and it runs there. Traverse capabilities are not tied to any provider or platform.

\n

The contract system is also different. Serverless functions have no formal contract. Traverse validates inputs and outputs every time, which means it can catch integration errors before they reach production.

\n
\n
\n\n
\n \n
\n

WASM runs near-native. The contract validation adds a fixed overhead per call, not per computation unit. For most business logic workloads this is noise. A formal benchmarks page is planned for v0.8.x.

\n

The bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.

\n
\n
\n\n
\n \n
\n

Every capability has a contract file that declares what inputs it accepts, what outputs it produces, which placement targets it supports, and what constraints apply. The runtime reads this file before execution.

\n

If you try to call a capability with the wrong inputs, the runtime rejects it before the WASM even runs. The trace artifact records the full decision. Nothing executes without a passing contract check.

\n
\n
\n\n
\n \n
\n

WASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.

\n

If you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.

\n
\n
\n\n
\n \n
\n

The runtime catches the failure, records it in the trace artifact with a timestamp and the failing contract clause, and returns a structured error. Nothing silent or ambiguous.

\n

Contract violations fail before execution. Runtime errors fail during execution. Both produce a trace. You always know exactly where the failure happened and what the runtime saw at that point.

\n
\n
\n\n
\n \n
\n

Start with the trace artifact from the failed call. It records input values, contract checks, execution steps, and output values. Most problems are visible there without any additional tooling.

\n

The CLI includes a trace subcommand for inspecting trace files. The MCP server exposes trace querying to AI agents. Expanded trace querying is planned for v0.8.x.

\n
\n
\n\n
\n \n
\n

JavaScript works today via the browser adapter. You load the WASM module and call capabilities through the JS bindings. The React demo shows exactly how this looks.

\n

Python SDK is experimental and on the roadmap for v0.8.x. Other language bindings depend on community interest and WASM host availability in that ecosystem.

\n
\n
\n\n
\n \n
\n

A trace is a structured record produced after every capability execution. It captures the inputs the runtime received, which contract clauses were checked, the execution path taken, and the outputs produced.

\n

This matters for two reasons. First, it makes debugging fast. Second, it makes auditing possible. If a pricing rule applied a discount you did not expect, the trace shows you exactly why. That kind of explainability is hard to add after the fact.

\n
\n
\n\n
\n
\n\n \n
\n
Licensing & Maintenance
\n
\n\n
\n \n
\n

Apache 2.0 is a permissive open source license. You can use Traverse commercially, modify it, distribute it, and build closed-source products on top of it. You need to include the original license notice.

\n

There are no royalties and no restrictions on commercial use. If you are evaluating this for a company, legal counsel can confirm, but Apache 2.0 is one of the most business-friendly open source licenses available.

\n
\n
\n\n
\n \n
\n

Enrico Piovesan. One person. This is not a VC-funded team with a support contract. It is research engineering built over years of real product work, published as open source.

\n

The upside is that the design is intentional and consistent. The tradeoff is that response times on issues depend on one person's capacity. Community contributions are welcome and encouraged.

\n
\n
\n\n
\n
\n\n \n
\n
AI and MCP
\n
\n\n
\n \n
\n

The MCP server exposes Traverse capabilities as tools that AI agents can call. The agent reads the capability contract to understand what the tool does, what inputs it takes, and what it returns. No custom glue code needed.

\n

Because every call produces a trace, the agent can inspect what actually happened and reason about it. This turns capabilities into auditable building blocks for AI workflows, not just function calls that return an opaque result.

\n
\n
\n\n
\n \n
\n

Function calling gives an agent a schema and an endpoint. The agent calls the function and gets a response. There is no contract enforcement, no placement logic, and no trace.

\n

With Traverse, the agent is working with governed capabilities. Inputs are validated before execution. The result includes a trace. The contract tells the agent exactly what the capability is allowed to do. That is a different level of trust and observability.

\n
\n
\n\n
\n \n
\n

Contract-Driven AI Development, or C-DAD, is a methodology that asks AI agents to navigate systems that have machine-readable contracts rather than undocumented code. If your capabilities have contracts, an AI agent can read them and reason about the system correctly.

\n

Without contracts, AI agents are guessing based on naming conventions and comments. With contracts, they have a precise definition of what each capability does, what it accepts, and what constraints apply. Enrico published the C-DAD whitepaper as the theoretical foundation for this approach.

\n
\n
\n\n
\n \n
\n

Universal Microservices Architecture, or UMA, is the architectural pattern Traverse implements. The core idea is that business capabilities should be portable across every runtime, not tied to the environment they were first deployed in.

\n

The UMA book on Amazon covers the theory in 13 chapters with runnable Rust and WASM examples. Traverse is the production runtime that makes those ideas executable. More at universalmicroservices.com.

\n
\n
\n\n
\n
\n\n \n
\n
Community
\n
\n\n
\n \n
\n

Open an issue or a pull request on GitHub. Issues are the best place to start for new capability ideas, bug reports, or questions that are not answered here.

\n

One rule: nothing ships without a governing spec. If you want to add a feature, the spec comes first. This keeps the codebase navigable and the intent documented regardless of who makes a change.

\n
\n
\n\n
\n
\n\n
\n
\n
\n\n
\n
\n
\n
Ready to build?
\n

The quickstart gets you to a running capability in under 10 minutes. No account required.

\n
\n Read the quickstart\n View on GitHub →\n
\n
\n
"; ---