`limit: n` on a resource spec, applied after `jq`. The releases card is what asked for it: a page that grows by one card per release gets longer forever, and the cut a visitor should run is the newest one — the rest are history, not an invitation. redoal's card had every release on it. After `jq` rather than before, for two reasons: it caps what the page will actually render whatever the filter did, and content that reorders with the filter can then take the top of its own ordering rather than the top of the source's. A source yielding a single record has no length and passes through untouched — turning one record into an empty list would be worse than ignoring a limit that cannot apply. `limit: 0` on a list does mean nothing, and the `empty` line speaks instead, which is a coherent thing for content to ask for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ByshXuDEzH8hXh5qp4VgGk
portal
A content-driven question engine: one Rust binary that turns a Git repo of YAML into a live site — pages, forms, review desks and state machines, with a durable event-sourced record of every answer underneath.
The engine special-cases nothing. Everything a site serves is declared in its content repo, content pushes hot-reload every running instance, and the same build serves any number of sites: instances differ only by environment variables. uhhm.no and redoal.com are two faces of the same binary from the same release artifact.
It composes with the surrounding stack rather than bundling it. Gitea hosts the content, NATS JetStream stores the events and projections, Kanidm provides identity, and anything downstream — automations, newsletters, onboarding — subscribes to the answer stream.
Documentation
Everything is under docs/:
- Architecture — what the engine is made of.
- Content reference — every key a content repo may write.
- State machines —
aggregates.yaml. - Access — the policy compiled from content.
- Operations — releasing, deploying, adding a site.
Development
cargo leptos build # server + wasm
cargo test --features ssr # tests/jetstream.rs needs PORTAL_TEST_NATS_URL
Content is linted by iris, which depends on this crate and carries the same version, so a content repo can check itself against the exact portal its instance runs:
iris check --path questions
Releasing
cargo release patch tags and pushes; CI builds the tarball and
attaches it to the Gitea release. A site takes it by bumping
PORTAL_RELEASE in its own content repo. See
operations.