iris

The iris over a portal site. A content push is an incoming wormhole; nothing comes through until it checks out.

iris check --path questions                      # a local checkout
iris check --repo https://project.uhhm.no/uhhm/questions
iris --path questions                            # the same, for one-line CI

check loads a content repo exactly the way the running site does, validates it (every action lands on a page, every transition is one the state machine allows, every recorded bucket is read back somewhere), and then holds it to the business needs the repo declares in needs.yaml, when it has one:

• a path of submissions gets each kind of visitor's answer into the bucket it names, within a submission and required-field budget;
• the handling group holds a desk over that bucket, and every finished state is reachable through the buttons it (and any also_moved_by group) offers; no record strands on the way;
• every stage the business named is a state of the machine.

A need marked planned warns instead of failing. Exit status is the verdict, so a content repo's CI is one line.

Beyond the verdict, check exports what a trainer needs to grade the wording: --needs-tasks writes the personas as typed choice tasks (--skim for headings only), --needs-score grades an engine's answers, and --needs-sim writes a resolved model of the whole site. iris replay runs simulated cases through the site's real aggregate engine on a throwaway JetStream and reports every bucket by state; --report-only takes the same scorecard from a live site's buckets. See portal-trainer for what sits around those.

Matching the site

Every type iris reads is portal's own: portal is a library dependency pinned to a release tag in Cargo.toml, and iris carries the same version number as that tag, so iris v0.3.39 is the lint for portal v0.3.39 and nothing else. A content repo pins IRIS_RELEASE to the PORTAL_RELEASE its site runs. Portal's own release tarball ships the matching iris binary too, at /srv/app/<instance>/current/iris.

Release

Iris is released by portal's publish job, never by hand: when a portal tag is pushed, that job re-pins this crate to the tag, sets the version to match, builds and tests it, adds the changelog line, and pushes the commit and the tag here. This repo's own CI then attaches the binary to the Gitea release as iris. A portal change to something the lint reads fails the portal release at that step. Changes to iris itself land on main between releases and ship with the next portal tag.