The lint moves out to uhhm/iris

question_lint, needs_replay, the needs module and the local-checkout
loaders now live in uhhm/iris, which depends on this crate as a
library pinned to a release tag. The tarball ships the matching iris
binary (IRIS_RELEASE in publish.yml) in place of question_lint, so a
site that pins nothing extra keeps a lint at current/iris. Portal
loses about 1,100 lines and keeps only what runs at request time.

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

README.md

@@ -30,7 +30,7 @@ stream.
 
 ## What the engine provides
 
-- **Content-driven pages** (`src/content.rs`, `src/app.rs`): YAML
+- **Content-driven pages** (`src/content/`, `src/app.rs`): YAML
   loaded from Gitea at boot and hot-swapped on a NATS reload signal;
   a bad push keeps the last-good content serving. The `questions/`
   tree IS the router — file paths become URLs, `_section.yaml`
@@ -75,17 +75,12 @@ stream.
   it - the chain verifiably answered the alternative that leads there,
   or it hangs off an earned page by a link that records nothing. A
   page behind an answer they have not given is never offered.
-- **Business needs as a checkable spec** (`src/needs.rs`,
-  `question_lint`): a content repo may ship a `needs.yaml` saying who
-  wants what, which bucket the answer must land in, and which group
-  has to carry it to a finished state. The lint proves the structure
-  (a path of submissions within an effort budget, a desk held by that
-  group, every finished state reachable, no record stranding; a
-  `planned` need warns instead of failing). Its personas - visitors in
-  their own words - become typed `choice` tasks for any external
-  answering engine (`--needs-tasks`, `--skim` for headings only) whose
-  picks are graded with `--needs-score`: a misroute is a wording
-  defect. The runtime never reads the file.
+- **Business needs as a checkable spec** (in
+  [uhhm/iris](https://project.uhhm.no/uhhm/iris)): a content repo may
+  ship a `needs.yaml` saying who wants what, which bucket the answer
+  must land in, and which group has to carry it to a finished state.
+  `iris check` proves the site meets it. The runtime never reads the
+  file; portal only provides the content types iris reads.
 - **Live resources** (`src/resource.rs`): content can pull a KV
   bucket, Gitea starred/org repos/releases, or any public JSON URL
   (SSRF fail-closed), reshaped by a content-declared `jq` filter.
@@ -102,17 +97,18 @@ stream.
 ## Binaries
 
 - `portal` — the server (Leptos SSR + hydrate, Axum underneath).
-- `question_lint` — headless content validation, shipped inside every
-  release artifact so each content repo's CI lints with the exact
-  portal version its instance runs; also works offline:
-  `question_lint --path <dir>`.
+- `iris` — the lint, from [uhhm/iris](https://project.uhhm.no/uhhm/iris),
+  which depends on this crate as a library pinned to a release tag.
+  Every release tarball ships the matching `iris` binary
+  (`IRIS_RELEASE` in `publish.yml`), so each content repo's CI can
+  lint with the exact portal version its instance runs:
+  `iris check --path <dir>`.
 
 ## Development
 
 ```sh
 cargo leptos build            # full app (server + wasm)
-cargo test --features ssr     # engine tests
-cargo build --features ssr --bin question_lint
+cargo test --features ssr     # engine tests; tests/jetstream.rs needs PORTAL_TEST_NATS_URL
 ```
 
 Runtime configuration is env vars (see `src/main.rs`, and each
@@ -136,7 +132,7 @@ cargo release patch        # or minor / major
 
 That bumps `Cargo.toml`, tags `v<version>`, and pushes; CI
 (`.gitea/workflows/publish.yml`) reacts to the tag, builds once, and
-attaches `portal-v<version>.tar.gz` (`portal` + `question_lint` +
+attaches `portal-v<version>.tar.gz` (`portal` + `iris` +
 `hash.txt` + `site/`) to the Gitea release. Pkg files are
 content-hashed (`hash-files = true`; instances run with
 `LEPTOS_HASH_FILES=true`), so a freshly served page can never pair a