Bendik Aagaard LynghaugandClaude Opus 5
f18d1a5181
Five things a building authority needed and portal could not say,
found by building one and replaying its cases through the engine.
The one that mattered: a submitter could only ever act on a record
nobody had touched. `access.rs` pinned a self_transition's from-state
to `open`, though the runtime had always passed the real state and
asked. So the applicant written to for a missing drawing could not
send it, and nobody could withdraw once anything had happened.
`self_transition` now takes `from: [state, ...]` and compiles one rule
per state; omitted it still means the initial state alone, which is
what every unsubscribe link already meant.
Then the four beside it. A record can belong to another record
(`type: record`, `of:`), with `where: { field, equals }` on a listing
as the other half, so an application's page lists the objections that
name it. A public view can be narrowed to the states worth showing,
so a register that is public by law is public about what was decided
and not about what was withdrawn. A state can grant a group, so an
approval that means membership needs no second step. And a state can
be moved by a clock (`after: { days, to }`, src/deadlines.rs) - held
to the same declared edge as a desk button, firing the same mail,
publishing the same event.
Also: the README is a README again, and everything that was crowding
it is in docs/ - architecture, content reference, state machines,
access, operations.
95 tests, up from 82.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
52 lines
1.9 KiB
Markdown
52 lines
1.9 KiB
Markdown
# 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](https://uhhm.no) and
|
|
[redoal.com](https://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/`](docs/README.md):
|
|
|
|
- [Architecture](docs/architecture.md) — what the engine is made of.
|
|
- [Content reference](docs/content-reference.md) — every key a content
|
|
repo may write.
|
|
- [State machines](docs/state-machines.md) — `aggregates.yaml`.
|
|
- [Access](docs/access.md) — the policy compiled from content.
|
|
- [Operations](docs/operations.md) — releasing, deploying, adding a site.
|
|
|
|
## Development
|
|
|
|
```sh
|
|
cargo leptos build # server + wasm
|
|
cargo test --features ssr # tests/jetstream.rs needs PORTAL_TEST_NATS_URL
|
|
```
|
|
|
|
Content is linted by [iris](https://project.uhhm.no/uhhm/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:
|
|
|
|
```sh
|
|
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](docs/operations.md).
|