The lint moved into uhhm/portal as portal lint

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt

CHANGELOG.md

@@ -3,6 +3,18 @@
 One line per change, grouped by the release that shipped it. Newest
 first. Each release names the portal tag it is built against.
 
+## Unreleased
+
+- `needs.yaml` may name the site's `tones`, one storyline each; the checks read the first storyline, which is what `build_questions` gives.
+
+## 0.5.10 (2026-09-30) - portal v0.5.10
+
+- Matches portal v0.5.10 (released by portal's publish job).
+
+## 0.5.9 (2026-09-30) - portal v0.5.9
+
+- Matches portal v0.5.9 (released by portal's publish job).
+
 ## 0.5.8 (2026-09-30) - portal v0.5.8
 
 - Matches portal v0.5.8 (released by portal's publish job).

Cargo.lock

@@ -2287,7 +2287,7 @@ checksum = "791930b43c0d5973160d90a8f3894509f2b273430f5c5c73b668636d0287c5c0"
 
 [[package]]
 name = "iris"
-version = "0.5.8"
+version = "0.5.10"
 dependencies = [
  "anyhow",
  "async-nats",
@@ -3406,8 +3406,8 @@ dependencies = [
 
 [[package]]
 name = "portal"
-version = "0.5.8"
+version = "0.5.10"
-source = "git+https://project.uhhm.no/uhhm/portal.git?tag=v0.5.8#f4ed98322fd9ec2a68762ca2402249315e473151"
+source = "git+https://project.uhhm.no/uhhm/portal.git?tag=v0.5.10#cb31995299a61fd3bf8a245e5b1d943e3c073043"
 dependencies = [
  "anyhow",
  "arc-swap",

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "iris"
-version = "0.5.8"
+version = "0.5.10"
 edition = "2021"
 description = "The iris over a portal site: nothing from a content repo comes through until it checks out"
 license = "MIT"
@@ -10,7 +10,7 @@ repository = "https://project.uhhm.no/uhhm/iris"
 # The site's own content types and loaders, so iris reads a repo exactly
 # the way the running site does. Pinned to the portal release it
 # matches; bumping this tag is what a new iris release is.
-portal = { git = "https://project.uhhm.no/uhhm/portal.git", tag = "v0.5.8", features = ["ssr"] }
+portal = { git = "https://project.uhhm.no/uhhm/portal.git", tag = "v0.5.10", features = ["ssr"] }
 anyhow = "1"
 serde = { version = "1", features = ["derive"] }
 serde_json = "1"

README.md

@@ -1,57 +1,10 @@
-# iris
+# iris, now `portal lint`
 
-The iris over a [portal](https://project.uhhm.no/uhhm/portal) site. A
+The lint lives in [uhhm/portal](https://project.uhhm.no/uhhm/portal)
-content push is an incoming wormhole; nothing comes through until it
+since portal 0.6, as the `portal lint` command of the same binary that
-checks out.
+runs a site; its documentation is
+[The lint](https://portal.uhhm.no/lint.html). A content repo's CI
+downloads the release's `portal` and runs `portal lint --path questions`.
 
-```
+The `iris` releases up to v0.5.11 stay here and keep working for the
-iris check --path questions                      # a local checkout
+`IRIS_RELEASE` pins that name them; nothing new is published.
-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.

src/needs.rs

@@ -36,6 +36,11 @@ pub struct NeedsFile {
     pub needs: Vec<Need>,
     #[serde(default)]
     pub personas: Vec<Persona>,
+    /// The tones of voice the site is told in, one storyline each
+    /// (portal docs, Storylines). Named here so the report can say
+    /// which tone a storyline index is; the checks read the first.
+    #[serde(default)]
+    pub tones: Vec<String>,
 }
 
 #[derive(Debug, Deserialize)]