Bendik Aagaard LynghaugandClaude Fable 5.1
ef4789f9b2
Five things the first cut of accounts-from-content left open. The first person and the responsible people are set up side by side, and both try again a minute apart: a seed that waited twenty minutes on Kanidm used to hold everyone else up, and a responsible person who failed waited for the next restart. The responsible are gone over again whenever the content changes. watch_for_reload publishes portal.content.reloaded once new content is in place, and seed.rs listens. Being responsible ends when the content stops saying so: someone no page names any more leaves RESPONSIBLE_GROUP in the same pass, if portal is who put them there (Invited.already_member). The account stays. An invite keeps itself current. portal_invites has an expired state; signing in closes a person's invites, a sweep moves the ones whose link ran out, and a desk's move from expired back to open makes a fresh link and mails it. Invites made at start are on file with the desks'. A suggested edit is a case in the built-in portal_edit_suggestions bucket, the person who made it is mailed at each move, and the card lists what they sent and where it stands. Found on the way, against Kanidm 1.11.2: a link's end comes as seconds since the epoch, which portal did not read, so invite mails said "until" and nothing; and a mail search answered with a 5xx was taken for a refusal. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt
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.