One Web#

The Rust one::web::server facade serves the bounded Order Review application as ordinary HTML and CSS. That product declares its contracts and root in .one and implements its behavior in Rust. The .one envelope keeps semantic declarations separate from implementation items whose using profile selects their language; Order Review selects Rust. Its server-document profile sends no JavaScript or browser runtime.

The Experience owner defines the bounded Rust and TypeScript bindings and their named consumers. Use application-selected frameworks for ordinary web, mobile, and desktop applications.

The following illustrative presentation sketch uses the public Rust facade. Its submission handler only changes the displayed state; the complete product owns intent validation, draft checking, and the resulting success or rejection.

use one::experience::{CommandStateKind, IntentId, Page, PlaceId};
use one::web::server::{Application, Document, Form, view};

struct Orders;

impl Application for Orders {
    fn present(&self) -> Document {
        order_page("7", "42", CommandStateKind::Idle)
    }

    fn submit(&self, form: &Form) -> Document {
        let customer = form.get("customer_id").unwrap_or_default();
        let order = form.get("order_id").unwrap_or_default();
        order_page(customer, order, CommandStateKind::Succeeded)
    }

    fn stylesheet(&self) -> &'static str {
        include_str!("style.css")
    }
}

fn order_page(customer: &str, order: &str, state: CommandStateKind) -> Document {
    let page = Page::new(PlaceId::new(1).unwrap(), state);
    view! {
        page: &page,
        title: "Order Review";
        <h1>{"Order Review"}</h1>
        <p>{"Check one customer order draft before submission."}</p>
        <label>
            {"Customer ID"}
            <input name={"customer_id"} value={customer} />
        </label>
        <label>
            {"Order ID"}
            <input name={"order_id"} value={order} />
        </label>
        <button intent={IntentId::new(1).unwrap()}>{"Review order"}</button>
    }
}

view! makes the bounded document composition visible with familiar elements, but remains a thin syntax layer over the public Document builder. The finite accepted grammar maps headings, paragraphs, labeled inputs, typed intent buttons, and status regions to the same named builder methods. Applications can use the builder directly when ordinary Rust control flow is clearer. The macro does not accept arbitrary HTML or select a renderer.

The product code does not implement an HTTP parser, route switch, response headers, percent decoding, HTML escaping, output limits, or socket loop. The opt-in server-html facade owns one fixed route set:

• GET / presents the page;
• POST /submit supplies a bounded, duplicate-free Form;
• GET /style.css serves the application stylesheet; and
• GET /health reports readiness.

The host emits a restrictive content-security policy and rejects malformed, ambiguous, oversized, or incomplete requests. The HTML adapter contextually escapes text and attributes and enforces a finite document budget. A submitted intent remains an inert exact identity: application and service code must still validate input and hold the authority for any real effect.

Start the server#

The native entry point is intentionally small:

use one::web::server::serve;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    serve(Orders, "127.0.0.1:3201")?;
    Ok(())
}

The executable Order Review Web product uses this surface from its own one.one, exact one.lock, and order_review_web root. Its selected product closure has Rust, .one, and CSS only—no authored Cargo.toml, Cargo.lock, package.json, TypeScript, JavaScript, Node, npm package, or client hydration runtime. Build derives a disposable exact Cargo package and lock beneath .one/build/work.

Pure contract operations stay small as well. one::service::pure adapts the application rule to the canonical cancellation-aware local-service contract:

pub fn review_service<Open, Store>(
    _open: Open,
) -> Result<
    impl one::service::LocalService<
        ReviewDraft,
        Response = ReviewResult,
        Error = ReviewFault,
    >,
    String,
>
where
    Open: FnOnce(one::state::KeyValueLimits) -> Result<Store, String>,
{
    Ok(one::service::pure(|draft: ReviewDraft| {
        (draft.customer_id != 0 && draft.order_id != 0)
            .then_some(ReviewResult { order_id: draft.order_id, ready: true })
            .ok_or(ReviewFault::InvalidDraft)
    }))
}

Lifecycle#

The canonical commands below require an installed distribution containing the root's exact semantic packages, tools, and providers, plus the applicable local bindings and Build authority. They describe the acceptance path; the facade and renderer tests alone do not prove that an installed release completes it. The owning lifecycle acceptance exercises this root against an explicitly supplied final immutable distribution.

From the repository root, with those inputs available:

one check --workspace systems/system/idl/examples/order/review/web --offline
one test --workspace systems/system/idl/examples/order/review/web \
  --root order_review_web --offline
one invoke order.review#Review.Check@1 request.json \
  --workspace systems/system/idl/examples/order/review/web \
  --root order_review_web --offline
one plan --workspace systems/system/idl/examples/order/review/web \
  --root order_review_web --offline
one build --workspace systems/system/idl/examples/order/review/web \
  --root order_review_web --offline
one observe <subject-ref> --workspace systems/system/idl/examples/order/review/web
one release local build:sha256:<build-digest> \
  --workspace systems/system/idl/examples/order/review/web
one approve plan:sha256:<plan-digest> \
  --workspace systems/system/idl/examples/order/review/web
one apply plan:sha256:<plan-digest> \
  --workspace systems/system/idl/examples/order/review/web
one reconcile operation:sha256:<operation-digest> \
  --workspace systems/system/idl/examples/order/review/web
one inspect operation:sha256:<operation-digest> \
  --workspace systems/system/idl/examples/order/review/web

Use {"customer_id":"7","order_id":"42"} for request.json; canonical OCS integers are represented as JSON strings at this boundary. Substitute the exact Build, plan, and operation references printed by the preceding commands. reconcile resumes the same operation without redispatching it. There is no Cargo or web manifest, npm setup, framework CLI, or product-specific One command.