Files
portal/docs
Bendik Aagaard LynghaugandClaude Opus 5 214d4eb85c
Test / test (push) Successful in 58s
Sessions outlive the deploy that interrupted them
A MemoryStore meant every restart signed out every desk on the site
being deployed. Bearable while a desk is three people, and not the
kind of thing that gets better on its own.

They live in NATS KV now: the JetStream already under the events, the
projections, the content reload and the access questions. No new
service, no new store, and the same bucket a second instance of a site
would read if there ever is one. `create` draws a fresh id rather than
writing over a session already at that key, the bucket's `max_age`
collects what nobody comes back for, and a record's own expiry is what
answers a load, whatever the bucket still holds.

Proved the only way it can be: a store opened twice against one
JetStream, which is what two runs of the binary are.

Also fixed, while there: the integration test asserted a record's
projected state was one that `aggregates::transition` never writes -
it appends events, the desk handler updates the projection - so it
failed whenever it was actually run. It now asserts what it says it
does, that a mailed reply leaves the state alone. test.yml has been
red since 0.3.47 while publish.yml stayed green, which is how v0.4.0
went out over it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-28 16:38:05 +02:00
..

portal documentation

Portal turns a Git repo of YAML into a running site. Almost everything here is about that YAML: what a content repo may say, and what the engine does with it.

Architecture What the engine is made of and where each piece lives in the source.
Content reference Every key a content repo may write, and what it does.
State machines aggregates.yaml: stages, who moves a case, mail, deadlines, memberships.
Access How the Cedar policy is compiled from content, and who may ask it what.
Operations Releasing, deploying, adding a site, environment variables.
Filesystem routes Why the questions/ tree is the router.

Two repos in the same family carry their own docs:

  • uhhm/iris — the lint. Versioned as portal and released by portal's publish job; it is the thing a content repo's CI runs before anything reaches a site.
  • uhhm/gdo — the mailer. Delivers what content asked to be sent, and carries replies back.