# iris

The iris over a [portal](https://project.uhhm.no/uhhm/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](https://project.uhhm.no/uhhm/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.