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,30 @@
 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).
+
+## 0.5.7 (2026-09-30) - portal v0.5.7
+
+- Matches portal v0.5.7 (released by portal's publish job).
+
+## Unreleased
+
+- The effort budget counts what a person fills in: a `type: record` field (the case an answer is about, carried on the link) and a `hidden` preset are not asked and no longer count. An objection page whose form carried the application's id used to be one field over.
+
 ## 0.5.6 (2026-09-30) - portal v0.5.6
 
 - Matches portal v0.5.6 (released by portal's publish job).

Cargo.lock

@@ -2287,7 +2287,7 @@ checksum = "791930b43c0d5973160d90a8f3894509f2b273430f5c5c73b668636d0287c5c0"
 
 [[package]]
 name = "iris"
-version = "0.5.6"
+version = "0.5.10"
 dependencies = [
  "anyhow",
  "async-nats",
@@ -3406,8 +3406,8 @@ dependencies = [
 
 [[package]]
 name = "portal"
-version = "0.5.6"
-source = "git+https://project.uhhm.no/uhhm/portal.git?tag=v0.5.6#b9327a170f34daab3d47f9ffd307d3767e82fc1b"
+version = "0.5.10"
+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.6"
+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.6", 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
-content push is an incoming wormhole; nothing comes through until it
-checks out.
+The lint lives in [uhhm/portal](https://project.uhhm.no/uhhm/portal)
+since portal 0.6, as the `portal lint` command of the same binary that
+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`.
 
-```
-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.
+The `iris` releases up to v0.5.11 stay here and keep working for the
+`IRIS_RELEASE` pins that name them; nothing new is published.

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)]
@@ -157,11 +162,14 @@ fn visible(q: &Question, as_group: Option<&str>) -> bool {
     }
 }
 
+/// What a person has to fill in: required fields, less the ones that
+/// carry rather than ask - a `record` naming the case an answer is
+/// about, a `hidden` preset - which cost nobody anything.
 fn required_fields(alt: &Alternative) -> usize {
     alt.features
         .iter()
         .flat_map(|f| &f.requirements)
-        .filter(|r| !r.optional)
+        .filter(|r| !r.optional && r.kind != "record" && r.kind != "hidden")
         .count()
 }
 
@@ -860,6 +868,19 @@ mod tests {
         let (questions, aggregates) = site(FULL_DESK);
         let findings = check(&needs("    max_fields: 1\n"), &questions, &aggregates);
         assert_eq!(fails(&findings), vec!["the path asks for 2 required field(s), over the budget of 1"]);
+        // A field that carries rather than asks is not effort: the
+        // record an answer is about arrives on the link.
+        let (mut questions, aggregates) = site(FULL_DESK);
+        let front = questions.get_mut("/").unwrap();
+        let brief = &mut front.alternatives[0].features[0].requirements;
+        let mut carrier = brief[0].clone();
+        carrier.name = "case".into();
+        carrier.kind = "record".into();
+        carrier.of = Some("projects".into());
+        carrier.optional = false;
+        brief.push(carrier);
+        let findings = check(&needs("    max_fields: 2\n"), &questions, &aggregates);
+        assert!(fails(&findings).is_empty(), "{findings:?}");
     }
 
     #[test]