Bendik Aagaard LynghaugandClaude Opus 5.5
6b91258ebe
{site} and {site_name} everywhere; a state mail adds {self_link} (the
submitter's own page, when their record's state allows a move there),
{desk_link} and {link}, which picks by who the mail is to. gullberg's
{link} mails went out blank until now. Documented in docs/mail.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MznPTC31w5mSUK4XMehcpi
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.
| Getting started | Bringing your people in: from an empty Kanidm to everyone at their own desk, from what the content says. |
| 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. |
| Storylines | The same site told several ways: lists of texts, one storyline per visitor, counted per storyline. |
| Memberships | Groups kept by portal itself: a membership as a case, a person as a phone number first, and the provider only saying who. |
| Operations | Releasing, deploying, adding a site, environment variables. |
| Training a site | portal plan and portal build: a business in plain words becomes a content repo, held to the lint. |
| The lint | portal lint: what a content repo's CI runs before anything reaches a site. |
| Filesystem routes | Why the questions/ tree is the router. |
One repo in the same family carries its own docs:
- uhhm/gdo — the mailer. Delivers what content asked to be sent, and carries replies back.
The lint (once uhhm/iris) and the trainer (once uhhm/portal-trainer)
are commands of the portal binary since 0.6; their chapters are
above, and the trainer's runs stay in the old repo.