row 173 (#1671) r2: rebased onto 78b69e1e6 as dewey/row173-r2 (cherry-pick of 25ff7cd3f, range-diff equal, no conflict); BUILD.md round 2 section with overlap note, run list from app.js readers, mutant procedure; no runs yet (sage-4361)

agents/dewey/work/queue-173/BUILD.md

@@ -0,0 +1,94 @@
+# Row 173 (#1671): a Seen click that waited out a Board read keeps the meaning it was clicked with
+
+Brief: docs/plans/2026-10-19_seen-click-intent.md (blob 225ac823b). Branch dewey/row173 off aca16404c.
+Queue reviewer: Darkwing. Gate (queue row): Darkwing approves on #1671 naming the candidate manifest; webui and
+every scripts/test-*.sh green on Sage's gate rerun.
+
+## Design
+
+- Intent. `seenButton` draws `data-intent="seen"` on a Seen button and `data-intent="unsee"` on an Unsee
+  button, from the same `r.seen` that picks the label. The click handler reads it into `mark` before
+  `writing = true` and before the wait, so the fresh row can't change it. I chose a `data-` value over reading the
+  label text so a later relabel can't change what a click posts.
+- The fresh row already holds the intent (`r.seen === mark`). This happens when another viewer marked or unmarked
+  the row while the read was in flight. Nothing is posted, the button is re-enabled, and the page announces
+  `<agent> already seen` or `<agent> already waiting`.
+  - Why post nothing. The route takes a repeat without harm: `markSeen` with `seen:true` rewrites the same mark,
+    and `seen:false` deletes a key that is already gone (control-board/src/scan.mjs:255-256). So posting the same
+    value would also be correct. It would cost a write and a rescan, though, and the read that just finished has
+    already drawn the row. The brief allows either.
+  - An unseen row can still hold an old mark for an earlier lastActivity. Posting nothing on Unsee leaves that
+    mark, which is harmless because `scanAgent` only counts a mark equal to the row's lastActivity (scan.mjs:340).
+- Otherwise the click posts `seen: mark` and announces from `mark`, not from the fresh row.
+- Unchanged: the row 172 wait, the single-click guard (`writing`), the no-row branch, and the `/api/seen` route
+  (out of scope).
+- `seen.disabled = false` in the new branch matches the no-row branch. After the read, `accept` redraws the
+  inspector and the cards, so `seen` is usually a detached button and the line has no visible effect. No test
+  can tell it apart; see M5.
+
+## Test
+
+packages/webui/tests/board-held.test.mjs gains one test: "a Seen or Unsee click that waited out a Board read
+keeps its meaning: another viewer's mark in that read posts nothing". `setup` returns `boardURL: f.boardURL` so
+the test can post to the board as the other viewer.
+- Steps, for each of Seen and Unsee:
+  - it holds `/api/board` with `window.__hold` and clicks Refresh;
+  - while the read is held, it posts the other viewer's mark straight to the board;
+  - it clicks the inspector's button and releases the read.
+- Checks: the announcement (`agent1 already seen`, then `agent1 already waiting`), `#seen-count` (1, then 0), and
+  that the page sent no `/api/seen` at all.
+- The held fetch hasn't reached the board when the other viewer posts (the stub awaits the hold before calling
+  the real fetch), so the released answer carries the other viewer's mark.
+
+Hash pins and readers checked (git grep, with a positive control for 64-hex): nothing pins app.js. shell.test
+counts existing app.js strings only. browser.test, sso-browser.test and the other board-held tests click
+`[data-seen]` buttons the page draws, so they get `data-intent` with them.
+
+## Mutants (run on CLEAR only; each one edit to app.js, then board-held.test.mjs whole)
+
+| id | edit | expected kill |
+|----|------|---------------|
+| M1 | post `seen: !r.seen` and drop the `r.seen === mark` branch (the old toggle) | new test (a post, and "returned to waiting") |
+| M2 | drop the `r.seen === mark` branch only (post the repeat) | new test (a post, and "marked seen") |
+| M3 | `seenButton` swaps the intent (`r.seen ? 'seen' : 'unsee'`) | row 172 test (`#seen-count` never 1) and the new test |
+| M4 | the new branch returns without `announce` | new test (announcement wait times out) |
+| M5 | drop `seen.disabled = false` in the new branch | equivalent: the button is redrawn by `accept`; named, not run |
+
+Each run: `timeout -k 10 180 node --test --test-force-exit packages/webui/tests/board-held.test.mjs`; a kill
+counts only as an assertion or a named wait failing in the named test.
+
+## Runs
+
+None yet. Gander holds the gate slot (row 253 run 5) from 16:32Z. The claim, the push and every run wait for
+Sage's CLEAR.
+
+## Round 2: rebase onto 78b69e1e6 (sage-4361)
+
+- Branch dewey/row173-r2 off refactor 78b69e1e6. The round 1 commit 25ff7cd3f (on aca16404c, 555 commits
+  behind) was cherry-picked as a new commit; dewey/row173 is untouched. No force-push.
+- The pick merged on its own. `git range-diff aca16404c..25ff7cd3f 78b69e1e6..<pick>` reports the commit equal.
+- Overlap with refactor: one app.js line, the `/api/config` handler at the end of the file (federation render).
+  It is far from both row 173 hunks and changes no assertion or reviewed line. board-held.test.mjs and the brief
+  (blob 225ac823b) are unchanged on refactor.
+- No test pins app.js by hash (grepped tests for app.js plus 64-hex).
+
+### Run list
+
+app.js is a page script, loaded by index.html, not imported by any module. Its test readers:
+- by name: board-held, browser, granted-user, serve, shell, sso-browser, user-option-swap;
+- by page load: every webui test that opens the Console through tests/browser.mjs (31 test files).
+No test outside packages/webui reads or serves app.js (`git grep` over packages/*/tests and scripts: none).
+
+Order, each run with `TMPDIR` from `mktemp -d /mnt/storage/scratch/tmp/d173XXXXXX` and absolute paths:
+1. M1-M4 below, each with board-held.test.mjs whole.
+2. board-held.test.mjs whole on the restored tree.
+3. packages/webui whole (all 70 test files), which covers both reader groups.
+case1-accept.test.mjs is not in the list (mos-1612). Runs need Sage's CLEAR.
+
+### Mutant procedure
+
+The M1-M5 table above stands. M5 stays equivalent: the new branch is reached only after the waited-out Board
+read's `accept` (refresh, app.js:372) has redrawn the row, so `seen` is the detached old button. Each mutant is one
+edit to app.js. Before the next mutant, the restored app.js must match the candidate's sha256. Each run is in its
+own process group so a timeout kill takes its browser with it. Afterwards I sweep for orphaned node/chromium
+processes in my run directory.

agents/launchpad/work/queue-255/DESIGN.md

@@ -1,402 +0,0 @@
-# Row 255 design: a bundled Pocket ID for users with no OIDC provider (Q203, Gitea #1760, Vikunja 458)
-
-Launchpad, draft 1, 2026-10-25, on `launchpad/row255` off refactor 78b69e1e6. Brief
-`docs/plans/2026-10-21_bundled-pocket-id.md` (blob 26f34400). Reviewer Webby. Sage checks it against Q203, O6,
-REQ-WEB-2 and REQ-INST-1. REQ-INST-2 (PRD 1.10) is post-v1 (mos-1204), and so is everything here.
-
-This is a design only. Nothing here installs, downloads or starts Pocket ID. It changes nothing on .53, .54 or
-dragon-lin, which keeps Authentik.
-
-## Sources
-
-- Q203 and O6 as the brief quotes them. PRD `docs/prd/mosaic-stack.md` REQ-WEB-2 (:902), REQ-INST-1 (:1509),
-  REQ-INST-2 (:1513) and REQ-INST-3 (:1528). Lead decision 44 items 5 and 6
-  (`docs/plans/2026-09-26_lead-decisions.md:655-663`).
-- The Q175 design `agents/sage/work/q175-sso/DESIGN.md` sections 4 and 10, and the code row 192 landed:
-  `packages/webui/src/sso-config.mjs` (the `console.sso` shape), `packages/webui/src/sso.mjs` (the slot read,
-  the discovery checks at :105-118, the client at :147-148, the callback at :133, the post-logout URI at :332).
-- Researcher's note `agents/researcher/work/2026-10-04_vikunja-pocketid.md` part 2 (v2.17.0).
-- A fresh read of upstream on 2026-10-25, from release metadata and source text only: no binary was fetched or
-  run. The latest stable release is **v2.19.1** (2026-10-22). Source paths below are under
-  `backend/internal/` at tag v2.19.1 in `github.com/pocket-id/pocket-id`, marked "P". Releases v2.18.0,
-  v2.19.0 and v2.19.1 are not marked breaking.
-
-## What the Console already needs from any provider
-
-This design keeps the Console's sign-in and start checks exactly as row 192 built them. Pocket ID becomes one
-`console.sso.providers` entry, the same shape any compliant OP uses (Q175 section 4, "Several providers"). The
-Console gets no new sign-in path, no password and no proxy-header identity (O6, REQ-WEB-2, REQ-INST-2). The
-facts that drive the rest of the design:
-
-- `publicOrigin` and every `issuer` must be https (`sso-config.mjs` `httpsURL`). A plain-http Pocket ID can't
-  be a provider at all.
-- Each provider needs 1 to 64 `subjects`. A `console.sso` with no subject refuses to load. So the first
-  person's subject has to exist before the Console starts with `--sso` (section 5).
-- The client authenticates with `client_secret_basic` (`sso.mjs:148`), so the client is confidential.
-- The slot is `<configDir>/secrets/mosaic-stack/<slot>`: a regular file, owned by the Console's uid, mode
-  with no group or other bits, and outside the repo and every stack copy (`readSlot`).
-- `config.json` is user-authored. bootstrap.sh creates it and nothing overwrites it (canon invariant 2, Q175
-  section 4). This matters for sections 1 and 5.
-
-## 1. The choice
-
-The installer is REQ-INST-3's install command (Vikunja #432; today `stack-upgrade.sh` and the per-case
-install scripts). It takes one sign-in option per instance:
-
-- `--oidc existing`. The user points the Console at one or more OIDC providers they already have. Nothing
-  is installed. The user writes `console.sso` themselves, as Q175 step 4 does today. The installer writes
-  nothing into `console.sso`; it prints the entry shape and the two URIs to register
-  (`<publicOrigin>/auth/callback`, `<publicOrigin>/auth/signed-out`).
-- `--oidc bundled`. The stack installs Pocket ID as an install component (section 2), and
-  `console.sso.providers` holds exactly one entry, `id: "pocket-id"`, whose `issuer` is the component's
-  origin.
-- No option keeps today's behaviour: no `console.sso`, and the Console runs without `--sso`.
-
-How the bundled choice is recorded. REQ-INST-1 lets a component be switched on "in the organization file
-or system config". It has to be the system config. The organization file can be written by agents through
-`organizationWriter`, which is the reason Q175 B1 put `console.sso` in config.json, and the same reason
-holds for a component that issues the Console's identities. So config.json gets one new optional key:
-
-```json
-"components": {
-  "pocket-id": {
-    "release": "v2.19.1",
-    "origin": "https://id.example.internal",
-    "port": 1411
-  }
-}
-```
-
-The loader (`scripts/mosaic-config.mjs`) checks the shape: `release` is a `vX.Y.Z` tag, and the component script refuses one that
-differs from the pin file (section 2), `origin` is an https origin, `port` is 1024 to 65535. It also cross-checks: when
-`components["pocket-id"]` is present, `console.sso` must have exactly one provider, `id` `pocket-id`,
-`issuer` equal to `origin`. A config with `console.sso` providers and no `components` is the existing
-choice and loads as today.
-
-**M1, approved by Mos with three conditions (mos-1666 item 3).** `components` is a new top-level config key.
-The loader refuses unknown keys today, so this is a config schema change. The conditions:
-
-1. **Rollback trap.** A copy older than P1 refuses a config that has the key, the same trap Q175 section 4
-   names for `console.sso`. P1 documents the order. On a rollback past P1, first take `components` out of
-   config.json (restore the backup made before the key went in), then roll back the pointer. The STATE check
-   after the rollback reads config.json and confirms the key is absent.
-2. **Strict inside the key.** The loader refuses any name under `components` other than `pocket-id`, and any
-   field under `pocket-id` other than `release`, `origin` and `port`. Each refusal names the key path and
-   quotes no value, as `checkConsole` does.
-3. **test-config.sh cases:**
-   - a valid `components` loads;
-   - a malformed one fails, naming the bad key path;
-   - a config without `components` loads;
-   - the cross-check refuses a `console.sso` whose provider doesn't match `origin`.
-
-What each choice writes into `console.sso` is in section 5. For the bundled choice, Pocket ID is the only
-providers entry. The design keeps it that way because REQ-INST-2 says "the Console's one providers entry".
-A user who later adds an existing provider moves to `--oidc existing` and removes the component (section 2).
-
-## 2. The component, against REQ-INST-1
-
-**Pinned.** A Pocket ID release is a set of raw binaries plus `checksums.txt` (sha256). From v2.16.0 there is
-an SPDX SBOM per binary, and the release workflow attests `checksums.txt` through Sigstore (`actions/attest`
-in `.github/workflows/release.yml`). The repo holds one pin file,
-`scripts/pocket-id-pins.sh`, sourced the way `scripts/case1-pins.sh` is: the tag, and for each supported platform (linux amd64 and arm64 to
-start) the asset name and its sha256. The build row copies the sha256 from `checksums.txt` at the tag and
-records the `gh attestation verify` output for each asset as its evidence. The pin is checked by hand at
-build time, not trusted at install time. No Pocket ID source and no binary goes in the repo. The binary is
-not in any image either, since the container install comes after v1 (REQ-INST-3).
-
-Recommended pin: v2.19.1, the current release. The build row checks it again, because Pocket ID ships a
-minor every one to four weeks. Upgrading is a pin file change in a reviewed commit.
-
-**Fetched and checked.** `scripts/component-pocket-id.sh fetch` downloads the pinned asset for the host's
-platform over https into a new 0700 staging directory, computes its sha256, and compares it with the pin.
-On a mismatch it deletes the file and refuses with `pocket-id-digest-mismatch`, naming the expected value
-and the computed one. On a match it installs the binary read-only (0555) at
-`<dataRoot>/components/pocket-id/bin/pocket-id-<tag>`. The fetch is the only network step, and the user
-runs it at install. Tests never run it against the network (section 9).
-
-**Runs.** A systemd user unit, `mosaic-pocket-id.service` (`mosaic-pocket-id-NAME.service` for a named
-instance, as row 190 names the bus and webui units), as the instance's user:
-
-- `ExecStart=<dataRoot>/components/pocket-id/bin/pocket-id-<tag>`.
-- `WorkingDirectory=<dataRoot>/components/pocket-id/run`, a directory the unit owns, so Pocket ID's habit of
-  reading `.env` from the working directory reads nothing we didn't write. The build row checks there is no
-  `.env` there at start.
-- Environment, all from the rendered unit:
-  - `APP_URL=<origin>` and `HOST=127.0.0.1` (P `common/env_config.go`: HOST defaults to `0.0.0.0`).
-  - `PORT=<port>`.
-  - `DB_CONNECTION_STRING` and `UPLOAD_PATH` as absolute paths under `<dataRoot>/components/pocket-id/data/`
-    (P defaults are `data/pocket-id.db` and `data/uploads`, relative to the working directory).
-  - `ALLOW_USER_SIGNUPS=disabled` and `ALLOW_INSECURE_CALLBACK_URLS=false`.
-  - `EMAIL_ONE_TIME_ACCESS_AS_UNAUTHENTICATED_ENABLED=false` and `..._AS_ADMIN_ENABLED=false`.
-  - The `OUTBOUND_ALLOWED_HOSTS_*` allowlists set empty (added in 2.19.0).
-  - No `TRUST_PROXY` unless section 6's proxy step sets it to the proxy's address.
-- `ENCRYPTION_KEY` (mandatory since v2.0, at least 16 bytes) never goes in the unit text. It lives in slot
-  `<configDir>/secrets/mosaic-stack/pocket-id-encryption-key`, 0600. The component script generates it from
-  `/dev/urandom` straight into the file and never prints it. The unit passes it with
-  `LoadCredential=` and `ENCRYPTION_KEY_FILE=%d/...`. The build row confirms `ENCRYPTION_KEY_FILE` at the pinned
-  tag; if it isn't there, it refuses rather than putting the key in `Environment=`.
-- The unit never carries `STATIC_API_KEY`. That key exists only during the enroll run (section 4).
-
-The data directory holds the SQLite database, Pocket ID's signing key (stored encrypted with
-`ENCRYPTION_KEY`), and the passkey registrations. It is 0700. Agent sandboxes bind only an allowlist
-(`packages/seat/src/sandbox.mjs`), and `<dataRoot>/components/` is not on it. The build row adds a sandbox
-test that pins that.
-
-**Health-checked.** `GET http://127.0.0.1:<port>/healthz` returns 204 (P `controller/healthz_controller.go`).
-`component-pocket-id.sh status` reports the unit state, the binary tag against the pin, the binary's sha256
-against the pin, and the health result. The Console's own `/healthz` already shows `sso: { "pocket-id": ready
-| unreachable | refused }` from its discovery retries, so an operator sees the provider from either side.
-
-**Removable.** `component-pocket-id.sh remove` refuses while `console.sso` still names `pocket-id`, so the
-Console can't be left pointing at a provider that's gone. Once the user has taken the entry out (or moved to
-`--oidc existing`), the script stops and removes the unit, then moves the data directory to
-`<dataRoot>/components/pocket-id.removed-<utc>` with a receipt line in `<dataRoot>/state/components.log`
-(append-only). It never deletes the passkey database outright. Deleting the moved directory and the
-encryption key slot is a separate `purge` verb that names both paths and needs `--yes`. Removing the
-`components` key from config.json is the user's edit.
-
-## 3. The Q175 start checks against the bundled instance
-
-The Console checks are unchanged. Here is each one against Pocket ID, and the setting it needs:
-
-| Check (row 192) | Pocket ID v2.19.1 | Default that fails | Fix |
-|---|---|---|---|
-| `issuer` is https (loader) | issuer = `APP_URL` exactly (P `controller/well_known_controller.go`) | `APP_URL` defaults to `http://localhost:1411` | `APP_URL=<https origin>`, section 6 |
-| discovery `issuer` equals config `issuer` | equal when `APP_URL` has no trailing slash; Pocket ID refuses a path | none | config `issuer` = `origin`, no trailing slash; the loader cross-check compares them |
-| `id_token_signing_alg_values_supported` overlaps `algs` | advertises only the current key's alg. RS256 (RSA-2048) by default (P `service/jwt_service.go`) | none | `algs: ["RS256"]` |
-| `code_challenge_methods_supported` has `S256` | advertises `plain` and `S256` | none | none. The Console always sends S256 (`sso.mjs:221`) |
-| JWKS has a usable key for `algs` | one key at `/.well-known/jwks.json` | none | none. The build row's fake OP pins `use`/`alg`/`kid` as Pocket ID emits them |
-| `end_session_endpoint` is https | `<APP_URL>/api/oidc/end-session` | http, if `APP_URL` is http | same fix as row 1 |
-| `redirect_uri` is registered | exact match first, then wildcard patterns; loopback callbacks match any port (P `utils/callback_url_util.go`) | `ALLOW_INSECURE_CALLBACK_URLS` defaults to true | register exactly `<publicOrigin>/auth/callback`, with no `*`; set `ALLOW_INSECURE_CALLBACK_URLS=false` |
-| post-logout URI | per-client `logoutCallbackURLs`, same matching | none | register exactly `<publicOrigin>/auth/signed-out` |
-| ID token alg in `algs`, `iss` match | as above | none | none |
-
-Two points the Console doesn't check, set on the client anyway:
-
-- `pkceEnabled: true`. Then Pocket ID refuses an authorize request that has no `code_challenge`. Pocket ID has
-  no per-client S256-only setting (P `oidc/provider.go` turns on `plain` for the server). That doesn't relax
-  anything: the Console sends S256 every time, and `plain` stays available only to other clients.
-- `isPublic: false`, which matches `client_secret_basic`.
-
-Key rotation. `pocket-id key-rotate --alg ...` replaces the one signing key (P `cmds/key_rotate.go`). After a
-rotation to another alg, the Console's discovery check refuses on the next restart (no overlap with
-`algs`), and that is the intended fail-closed result. A rotation is a user step that updates `algs` in the
-same edit. The component script never rotates.
-
-## 4. The client, and where its secret goes
-
-The person running the install creates the client through `component-pocket-id.sh enroll`. No agent runs
-this verb. It refuses when any agent marker is in its environment: the `MARKERS` list in
-`packages/bus/src/human.mjs` (`MOSAIC_RUN_ID`, `MOSAIC_BUS_CAP`, `CLAUDECODE` and the rest) that the human
-boundary uses. A test pins the refusal.
-
-Enroll needs admin rights before any person has a passkey. Pocket ID offers two ways to get them, and one of
-them is a hazard:
-
-- `/setup` and its backing `POST /api/signup/setup` are unauthenticated: whoever calls first becomes admin
-  (P `usersignup/service.go`). Sandboxed agents share the host's network namespace (`sandbox.mjs` unshares
-  user, pid and ipc, not net), so any agent could reach a loopback Pocket ID and take that first admin.
-- `STATIC_API_KEY` is a fixed admin key with no expiry (P `apikey/service.go`). It doesn't count as
-  completing setup, so `/setup` stays open while it's set.
-
-So enroll never lets the real unit serve before an admin person exists. It runs the pinned binary once in a
-**private network namespace** (`unshare --user --net`, or `bwrap --unshare-net` with the binary and data
-directory bound), where only enroll's own loopback can reach it:
-
-1. Generate a one-run static key into a 0600 temp file in a new 0700 directory, and start Pocket ID inside
-   the namespace with `STATIC_API_KEY_FILE` pointing at it, plus the unit's environment.
-2. Wait for `/healthz` 204.
-3. Create the admin user, `POST /api/users` with `isAdmin: true` and the username and email given with
-   `--admin-user` and `--admin-email`. Keep the returned `id`. That is the OIDC `sub` (P
-   `oidc/claims_service.go` uses `user.ID`, a UUIDv4 set at creation, so it's stable).
-4. Create the Console client: client id `mosaic-console-<instance>`, callback and logout URLs exactly as in
-   section 3, `pkceEnabled: true`, `isPublic: false`. Supply the secret instead of letting Pocket ID
-   generate it. Enroll generates 48 random bytes, base64url, and writes them straight to slot
-   `<configDir>/secrets/mosaic-stack/console-sso-pocket-id` (0600, `O_CREAT|O_EXCL`, not a symlink). It sends
-   the same bytes in the create body over the namespace's loopback (`dto/oidc_dto.go` accepts a supplied
-   secret of 16 or more characters). The value is never printed, logged or put in an argv, and a test pins
-   that it appears in no output.
-5. Mint a one-time access token for the admin, `POST /api/users/<id>/one-time-access-token`.
-6. Stop the namespaced process, then shred and remove the static key file. The real unit has never had a
-   static key, so no admin key survives enroll.
-7. Start the real unit and wait for `/healthz` 204.
-8. Print the sign-in link `<origin>/lc/<token>` to the user's terminal (section 5), and the `console.sso`
-   entry (section 5).
-
-The build row confirms each route and body against the pinned tag's source before it writes the client (the
-upstream read for this design didn't trace the create-client route). If any of steps 1 to 7 fails, enroll
-stops the process, removes the static key, leaves no slot file it created, and refuses with the step name.
-
-The secret never enters the repo or an image. It sits in two places only: the slot file and Pocket ID's
-database (stored as a hash). The Console's `readSlot` reads it as it does any provider's.
-
-## 5. The first person, and their subject in `console.sso`
-
-Pocket ID is passkey-only for people (REQ-INST-2). The installing user enrolls like this:
-
-1. Enroll prints `<origin>/lc/<token>`. The token is valid for one hour and is a credential, so it goes only
-   to the terminal of the person who ran enroll. It goes in no log and no file.
-2. The user opens it in a browser that can reach `origin` (section 6). Pocket ID signs them in and asks them
-   to add a passkey. Without one they can't sign in again. If the hour passes, `pocket-id
-   one-time-access-token <username>` (P `cmds/one_time_access_token.go`), run by the user against the data
-   directory, prints a new link. `component-pocket-id.sh relink` wraps that call.
-3. Enroll already has the subject, the `id` from step 3 of section 4. It doesn't wait for a sign-in or read a
-   `subject-unknown` log line.
-
-How the subject gets into `console.sso`. config.json is user-authored and never auto-written. Two ways
-to respect that; I recommend the first:
-
-- **R1 (recommended).** Enroll prints the full entry and writes nothing:
-
-  ```json
-  "console": { "sso": { "publicOrigin": "<publicOrigin>", "providers": [ {
-    "id": "pocket-id", "issuer": "<origin>", "clientId": "mosaic-console-<instance>",
-    "clientSecret": { "slot": "console-sso-pocket-id" }, "algs": ["RS256"],
-    "subjects": [ { "sub": "<id>", "name": "<admin-user>" } ] } ] } },
-  "components": { "pocket-id": { "release": "<tag>", "origin": "<origin>", "port": <port> } }
-  ```
-
-  The user pastes it into config.json, as with Q175 step 4. Rerunning `scripts/bootstrap.sh` (or
-  `--instance NAME`) then validates it through the loader, including the section 1 cross-check, and writes
-  nothing. Nothing changes in invariant 2.
-- **R2 (rejected, Sage sage-4401: R1 chosen).** `enroll --write-config` would write those two keys itself, with a backup of config.json first, and
-  refuse if `console` or `components` were already present. That would be the first tool to modify an
-  existing config.json, against canon invariant 2's "never overwritten" practice. Not built.
-
-Whose subject. Enroll creates one person, the one running it, and only that subject goes in the entry. On
-Jason's instances, only his subject goes into `console.sso` (mos-1197). Further people are added with
-Pocket ID's admin UI (a user plus a one-time link), and their subjects go into `console.sso` by the user's
-edit, never by an agent. Pocket ID users who aren't in `subjects` can sign in to Pocket ID, but the Console
-refuses them `subject-unknown`, so REQ-WEB-2's "must map to an authorized human" holds.
-
-## 6. Reach: origin, TLS and proxy
-
-WebAuthn takes its RP id from `APP_URL`'s host name, and its allowed origin is `APP_URL`
-(P `webauthn/module.go`). Browsers allow passkeys only on a secure origin. The Console also needs https for
-both `publicOrigin` and `issuer`. Pocket ID serves plain http, and I found no TLS listener setting in its
-environment config. So:
-
-- Pocket ID always binds `127.0.0.1:<port>`. That is the default, and the component never binds anything
-  else (`HOST=127.0.0.1`; the status verb refuses a unit whose `HOST` differs).
-- `origin` is an https origin served by a TLS front that the user already has for the Console. The Console
-  needs one anyway, since `publicOrigin` is https. Pocket ID goes behind the same front under **its own host
-  name**, for example `id.<console host>`. Pocket ID doesn't support a path prefix (`APP_URL` must have no
-  path). A separate host name also keeps Pocket ID's cookies apart from the Console's
-  `__Host-mosaic_*` cookies; the two share cookies if they sit on one host name on different ports.
-- The front reaches Pocket ID on loopback, so the front has to run on the same host. If it doesn't, Pocket
-  ID would need a non-loopback bind, and that is a `network.expose` hard wait (REQ-WAIT-1), not a component
-  option.
-- `TRUST_PROXY` is set to the front's address only, never `true`.
-- The Console fetches discovery and JWKS from `issuer` over https from the server side, so the Console's
-  node has to trust the front's certificate. A public CA does that. A private CA needs
-  `NODE_EXTRA_CA_CERTS` in the Console unit, which the build row adds as a render flag.
-
-These steps are the user's, and on Jason's hosts they are Jason's, because each one changes who can reach
-the Console or Pocket ID, or who the host trusts:
-- J1: the DNS name for `origin`;
-- J2: the certificate for it, or a private CA and its trust in the browser and in `NODE_EXTRA_CA_CERTS`;
-- J3: the TLS front's route from `origin` to `127.0.0.1:<port>` (a Traefik change on Jason's hosts);
-- J4: any listener off loopback.
-
-The component checks and refuses; it never does them itself. With none of them done, Pocket ID runs on
-loopback with an https `APP_URL` that nothing serves yet. Enroll's step 2 health probe goes straight to
-`127.0.0.1`, so enroll still works. The person can't add a passkey until J1 to J3 are done.
-
-## 7. Agents
-
-Unchanged. Agents keep their per-role service tokens (lead decision 44 item 6, REQ-INST-2). Pocket ID issues
-nothing an agent uses. The Console client is the only client enroll creates. No API, no client-credentials
-grant and no admin API key exist after enroll. Residuals, stated plainly:
-
-- Agents can reach `127.0.0.1:<port>`, because the sandbox shares the host network. What they can reach there
-  is the public sign-in pages, discovery and JWKS. Signup is disabled, email codes are off, `/setup` is
-  closed because an admin exists, and there is no static key. A test of the rendered unit pins all four
-  settings.
-- The data directory and the two slots are outside every sandbox bind (section 2).
-- A seat that ran as the same OS user outside a sandbox could read the data directory. The Console's
-  existing slot has the same exposure; this design adds no new class of it.
-
-## 8. Instances
-
-One Pocket ID per named instance, never shared:
-
-- Each instance has one system config (row 190), and `components` and `console.sso` live in it. A shared
-  Pocket ID would make one instance's config depend on a unit, a data directory and an encryption key that
-  belong to another instance's config and data root.
-- Unit names, ports, data directory, slots and removal are all per instance (`mosaic-pocket-id-NAME`,
-  `<dataRoot of NAME>/components/pocket-id`), so removing one instance's component can't break another's
-  sign-in.
-- Each instance needs its own `origin` (section 6), so passkeys are per instance too. A person enrolls once
-  per instance.
-- An instance that wants to use another instance's Pocket ID can still do it with `--oidc existing`. Then it
-  is just an OIDC provider, with its own client registered by that instance's owner. Nothing special-cases it.
-
-Two instances on one host each need their own `port`. The loader can't see other instances' configs, so
-`component-pocket-id.sh` refuses at fetch and enroll when the port is already bound on loopback.
-
-## 9. Tests, stand-ins only
-
-No test downloads or starts a real Pocket ID, and no test touches auth.diversecanvas.com,
-mosaic.woltje.com or 127.0.0.1:7332. The stand-ins:
-
-- **Fake Pocket ID OP**, a node server like row 192's fake OP, shaped from v2.19.1:
-  - the discovery fields `well_known_controller.go` emits (issuer = origin, `plain` and `S256`,
-    `end_session_endpoint` at `/api/oidc/end-session`, the three auth methods);
-  - one RS256 JWK at `/.well-known/jwks.json`;
-  - a token endpoint that takes only `client_secret_basic`;
-  - `/healthz` 204.
-
-  The Console starts against it under `--sso` with the section 5 entry, with no check changed. Negative
-  cases:
-  - an http issuer refuses at load;
-  - an ES256-only JWKS against `algs: ["RS256"]` refuses at discovery;
-  - an issuer with a trailing slash refuses on the cross-check.
-- **Fake admin API** on the same stand-in: `POST /api/users`, the client create, the one-time token, and a
-  static-key check. Enroll runs against it with the binary replaced by a stub script that serves the stand-in.
-  The tests pin:
-  - the namespace argv;
-  - the slot file's mode and `O_EXCL`;
-  - that the secret appears in no stdout, stderr or argv;
-  - the static key file gone after success and after a failure at each step;
-  - the refusal under an agent marker in the environment.
-- **Fetch**: a local file served by a test https server (self-signed, trusted only by the test) with a
-  matching pin, a mismatched pin and a truncated file.
-- **Unit render**: the environment table in section 2. `HOST=127.0.0.1`, no `STATIC_API_KEY`, no
-  `ENCRYPTION_KEY` value in the text, and `ALLOW_USER_SIGNUPS=disabled`.
-- **Loader**: test-config.sh cases for the `components` key and the cross-check, and the copy-rollback note.
-- **Sandbox**: `<dataRoot>/components/` is in no bind list.
-
-## 10. Build rows, in landing order
-
-All are post-v1 (REQ-INST-2). Each row has Webby or Sage's named reviewer and its own gate. None of them
-runs on .53, .54 or dragon-lin, and none installs Pocket ID on any host.
-
-1. **P1, loader key.** `components["pocket-id"]` in `mosaic-config.mjs`, strict inside the key, and the
-   cross-check against `console.sso` (section 1, M1 conditions from mos-1666 item 3). P1 also writes the
-   rollback order into `docs/TOOLS.md` beside Q175's: remove `components` (restore the backup) before the
-   pointer goes back, and the post-rollback STATE check confirms the key is absent from config.json. Gate:
-   test-config.sh green with the four M1 cases.
-2. **P2, pin and fetch.** `scripts/pocket-id-pins.sh` with the build-time sha256 and the
-   attestation evidence, and `component-pocket-id.sh fetch|verify`. Gate: the fetch tests against the local
-   stand-in; the evidence file shows `gh attestation verify` output for each pinned asset.
-3. **P3, unit.** The unit template, `render|install|status|remove|purge`, and the encryption key slot. Gate:
-   the render and remove tests, and the sandbox bind test.
-4. **P4, enroll.** The namespaced bootstrap, the client, the subject, `relink`, and printing the entry (R1),
-   (R2 rejected). Gate: the enroll tests in section 9, and a secret-leak grep over every test log.
-5. **P5, Console against the fake Pocket ID.** The section 9 fake-OP start tests, and the
-   `NODE_EXTRA_CA_CERTS` render flag for the Console unit. Gate: the webui suite, with no change to
-   `sso.mjs` checks (a diff of `sso.mjs` and `sso-config.mjs` against the base shows none).
-6. **P6, installer option.** `--oidc existing|bundled` on REQ-INST-3's install command, calling P2 to P4 in
-   order, and the docs: `docs/TOOLS.md`, the host run sheet's J1 to J4 steps. Gate: the installer's own
-   suite against the stubs; the docs list J1 to J4 as the user's steps.
-
-## Open items for review
-
-- M1 approved by Mos with three conditions (mos-1666 item 3), written into section 1 and P1.
-- M2 dropped: Sage chose R1 and rejected R2 (sage-4401).
-- **Q1 (Webby):** the private network namespace for enroll (section 4). The other option is to start the
-  real unit and race `/setup`, which I think is unsafe while agents share the host network.
-- **Q2 (Webby):** one-providers-entry for the bundled choice (section 1). REQ-INST-2's wording reads that
-  way. Mixing a bundled Pocket ID with existing providers would need Sage's ruling.
-- Not covered: Pocket ID for Vikunja or Gitea people sign-in (the Researcher note's part 3), and
-  client-credentials between Mosaic services. Neither is in Q203.

packages/webui/src/public/app.js

@@ -66,7 +66,7 @@
   $('mode').onchange = e => { mode = e.target.value; theme(); };
   function seenButton(r) {
     if (!['waiting', 'error'].includes(r.state) || !r.lastActivity) return '';
-    return `<button type="button" class="btn" data-seen="${esc(key(r))}" aria-label="${r.seen ? 'Unsee' : 'Mark seen'} ${esc(r.agent)}">${r.seen ? 'Unsee' : 'Seen'}</button>`;
+    return `<button type="button" class="btn" data-seen="${esc(key(r))}" data-intent="${r.seen ? 'unsee' : 'seen'}" aria-label="${r.seen ? 'Unsee' : 'Mark seen'} ${esc(r.agent)}">${r.seen ? 'Unsee' : 'Seen'}</button>`;
   }
   const historyButton = r => `<button type="button" class="btn conv-open" data-history="${esc(key(r))}" aria-label="History for ${esc(r.agent)}">History</button>`;
   const openButton = r => `<button type="button" class="session-open" data-open="${esc(key(r))}" aria-controls="inspector" aria-expanded="${selected === key(r)}">${esc(r.agent)}</button>`;
@@ -415,12 +415,16 @@
     if (!seen || writing) return;
     // A Board read in flight (reading) holds busy. The click waits for that read and posts on the row it
     // drew; dropping it left the click doing nothing (row 172). A second click while one waits or posts is dropped.
+    // The click means what the button said when clicked (Seen marks, Unsee returns the row to waiting), read before
+    // the wait. If the fresh row already holds that, another viewer got there first: nothing is posted (row 173).
+    const mark = seen.dataset.intent === 'seen';
     writing = true; seen.disabled = true;
     try {
       while (reading) await reading;
       const r = row(seen.dataset.seen); if (!r) { seen.disabled = false; return; }
+      if (r.seen === mark) { seen.disabled = false; announce(`${r.agent} already ${mark ? 'seen' : 'waiting'}`); return; }
       busy = true;
-      try { accept(await api('/api/seen', { project: r.project, agent: r.agent, lastActivity: r.lastActivity, seen: !r.seen })); announce(`${r.agent} ${r.seen ? 'returned to waiting' : 'marked seen'}`); }
+      try { accept(await api('/api/seen', { project: r.project, agent: r.agent, lastActivity: r.lastActivity, seen: mark })); announce(`${r.agent} ${mark ? 'marked seen' : 'returned to waiting'}`); }
       catch (err) { error(err); seen.disabled = false; }
       finally { busy = false; schedule(); }
     } finally { writing = false; }

packages/webui/tests/board-held.test.mjs

@@ -82,7 +82,7 @@ async function setup(machine, fast = false) {
   const polls = () => b.evaluate('window.__polls');
   const settle = () => new Promise(r => setTimeout(r, 600));
   const done = async () => { await b.close(); await close(web); await f.close(); store.close(); rmSync(root, { recursive: true, force: true }); };
-  return { b, base, wait, text, shown, reqs, polls, settle, done };
+  return { b, base, boardURL: f.boardURL, wait, text, shown, reqs, polls, settle, done };
 }
 
 const HELD = 'document.querySelectorAll("#held table tbody tr").length === 2';
@@ -191,6 +191,37 @@ test('a Seen click while a Board read is in flight waits for that read, then pos
   } finally { await done(); }
 });
 
+// Row 173 (#1671): the click took its meaning from the fresh row, so another viewer's mark landing in the read
+// it waited for turned "Seen" into an unsee. The click means what its button said; a fresh row that already
+// holds that posts nothing and says so. The other viewer posts straight to the board while the read is held.
+test('a Seen or Unsee click that waited out a Board read keeps its meaning: another viewer\'s mark in that read posts nothing', { timeout: 120000 }, async () => {
+  const { b, base, boardURL, wait, text, reqs, done } = await setup(false);
+  const posts = async () => (await reqs()).filter(r => r.path === '/api/seen').length;
+  const other = async seen => {
+    const r = (await (await fetch(`${boardURL}/api/board`)).json()).sessions.find(s => s.project === 'proj' && s.agent === 'agent1');
+    const res = await fetch(`${boardURL}/api/seen`, { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify({ project: 'proj', agent: 'agent1', lastActivity: r.lastActivity, seen }) });
+    assert.equal(res.status, 200);
+  };
+  try {
+    await b.navigate(base);
+    await wait(`${SESSIONS} && ${HELD}`);
+    await b.evaluate(`document.querySelector('table.sessions [data-open="proj/agent1"]').click(), true`);
+    await wait('document.querySelector("#inspection [data-seen]")');
+    for (const [label, seen, count, said] of [['Seen', true, '1', 'agent1 already seen'], ['Unsee', false, '0', 'agent1 already waiting']]) {
+      assert.equal(await text('#inspection [data-seen]'), label);
+      await b.evaluate(`window.__hold = '/api/board', document.querySelector('#refresh').click(), true`);
+      await wait('window.__held.length === 1');
+      // The held fetch has not reached the board yet, so its answer carries the other viewer's mark.
+      await other(seen);
+      await b.evaluate(`document.querySelector('#inspection [data-seen]').click(), true`);
+      await b.evaluate('window.__held.splice(0).forEach(r => r()), true');
+      await wait(`document.querySelector("#announce").textContent === ${JSON.stringify(said)}`);
+      assert.equal(await text('#seen-count'), count);
+      assert.equal(await posts(), 0);
+    }
+  } finally { await done(); }
+});
+
 test('a redirect answer on a Board read, a bus read, a conversation read, a board POST, a module read and a send signs the page out: one line, nothing stale, no further reads', { timeout: 120000 }, async () => {
   // The poll timers fire after 150 ms here, so the 600 ms settle below spans several ticks.
   const { b, base, wait, text, shown, reqs, polls, settle, done } = await setup(true, true);