Bendik Aagaard LynghaugandClaude Opus 5.5
b619926a11
Each structure round is logged as fixed, still open, new and reopened; a fix round sees the open findings with their fixes and only the files they name; a change that reopens a closed finding is undone; a round that closes nothing ends the phase with what is left in run.log. A hesitant visitor alone no longer triggers a wording rewrite. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.