rbrooks/Quest-Board
Watch
1
0
Fork
You've already forked Quest-Board
 0
Code Issues 58 Pull requests 7 Projects Releases 76 Packages Wiki Activity Actions

[Foundry] Test (D337): a minimal Quest Board module pairs and round-trips in The Amberwake Accord #4

New issue
Closed
opened 2026-06-23 00:42:30 +00:00 by rbrooks · 4 comments
rbrooks commented 2026-06-23 00:42:30 +00:00
Owner
Copy link

Rewritten 2026-11-06 for D337. This replaces "install and validate foundryvtt-rest-api": D333 chose our own module instead (#143). It runs before anything else in v5.0.

Where: the test Foundry instance from #143. Core 14.369.0, pf2e 8.7.0, world The Amberwake Accord (the-amberwake-accord). It's LAN only, at https://foundry-dev.lan.ryanbrooks.dev on docker-test (foundry-dev, data in /opt/foundry-dev/data). Users: Ryan (GM), Test-GM (GM), Player2 (player).

What gets built (throwaway; not product code)

  1. A minimal module quest-board-test: module.json, one ES module, and a settings field for the pairing code.
  2. A minimal endpoint that stands in for Quest Board:
    • it hands out a pairing code and swaps it for a token;
    • it accepts wss:// with that token;
    • it checks Origin;
    • it sends one command and logs what comes back.

Checks, each recorded here with evidence

  1. Outbound from a launched world: the module opens wss:// from inside the world (not just from the setup page). There's no CSP header on 14.369 (checked in #143); this confirms it in practice.
  2. Pairing: a code typed in by a GM gives a token that's scoped to the campaign. A wrong or expired code is refused.
  3. Command in: the server sends "create actor" (a pf2e NPC with a name and level), and the actor appears in the world. A repeated command id doesn't create a second actor.
  4. Event out: activating a scene in Foundry reaches the server with the scene's id and name.
  5. One holder: with Ryan and Test-GM both in the world, only one holds the link. When that one leaves, the other takes over within a few seconds.
  6. No player link: Player2 never connects, and can't pair.
  7. Reconnect: restart the endpoint; the module reconnects by itself and nothing runs twice.
  8. Record: the core and pf2e versions, the browser used, and anything surprising.

Where the endpoint runs: to be decided with the owner. It needs a wss:// address with a certificate the browser trusts, because the Foundry page is https://. Dev Quest Board runs published images only and must not be built from source.

Install, for the test: copy the module to /opt/foundry-dev/data/Data/modules/quest-board-test/, chown -R 1226:1226, and reload the world.

**Rewritten 2026-11-06 for D337.** This replaces "install and validate foundryvtt-rest-api": D333 chose our own module instead (#143). It runs before anything else in v5.0. **Where:** the test Foundry instance from #143. Core **14.369.0**, pf2e 8.7.0, world **The Amberwake Accord** (`the-amberwake-accord`). It's LAN only, at https://foundry-dev.lan.ryanbrooks.dev on docker-test (`foundry-dev`, data in `/opt/foundry-dev/data`). Users: `Ryan` (GM), `Test-GM` (GM), `Player2` (player). **What gets built (throwaway; not product code)** 1. A minimal module `quest-board-test`: `module.json`, one ES module, and a settings field for the pairing code. 2. A minimal endpoint that stands in for Quest Board: - it hands out a pairing code and swaps it for a token; - it accepts `wss://` with that token; - it checks `Origin`; - it sends one command and logs what comes back. **Checks, each recorded here with evidence** 1. **Outbound from a launched world:** the module opens `wss://` from inside the world (not just from the setup page). There's no CSP header on 14.369 (checked in #143); this confirms it in practice. 2. **Pairing:** a code typed in by a GM gives a token that's scoped to the campaign. A wrong or expired code is refused. 3. **Command in:** the server sends "create actor" (a pf2e NPC with a name and level), and the actor appears in the world. A repeated command id doesn't create a second actor. 4. **Event out:** activating a scene in Foundry reaches the server with the scene's id and name. 5. **One holder:** with `Ryan` and `Test-GM` both in the world, only one holds the link. When that one leaves, the other takes over within a few seconds. 6. **No player link:** `Player2` never connects, and can't pair. 7. **Reconnect:** restart the endpoint; the module reconnects by itself and nothing runs twice. 8. **Record:** the core and pf2e versions, the browser used, and anything surprising. **Where the endpoint runs:** to be decided with the owner. It needs a `wss://` address with a certificate the browser trusts, because the Foundry page is `https://`. Dev Quest Board runs published images only and must not be built from source. **Install, for the test:** copy the module to `/opt/foundry-dev/data/Data/modules/quest-board-test/`, `chown -R 1226:1226`, and reload the world.
claude-bot commented 2026-07-27 23:15:00 +00:00
Collaborator
Copy link

Approach change: dev Foundry instance first (2026-07-27)

Decision from today's session: the Foundry pillar will be built against a dedicated dev Foundry instance, which does not exist yet. Standing one up is now the real first step of v4.0.0 — ahead of everything in this issue.

That partially supersedes this issue's "validate against the real instance, not a throwaway" instruction, so worth being precise about what still holds and what changes:

Still holds — and is now the thing to get right. The module is version-sensitive; that was the whole reason for insisting on the real instance. A dev instance is a perfectly good validation target provided it matches production's Foundry core version and module version. So the deliverable sharpens rather than weakens: record the tested (Foundry core version, foundryvtt-rest-api version) pair, and treat a drift between dev and prod on either as the compatibility risk to watch. A dev instance on a different core version would give false confidence — exactly what the original wording was guarding against.

Changes. Installing the module on production is no longer step one. Prod becomes a later verification step, once the adapter work is proven against dev.

Why a dev instance is worth the setup cost: this pillar writes into Foundry — actors, tokens, journal entries, live scenes (v4.2.0). Developing that against a live game world risks corrupting real campaign data, and there is no undo for a bad actor push. The same gap exists on the Discord side, incidentally: the dev bot has no DISCORD_BOT_TOKEN, so bot behaviour is currently only exercisable in production.

Suggested revised order for v4.0.0:

  1. Stand up a dev Foundry instance, matched to production's core version.
  2. Install and configure foundryvtt-rest-api on it; confirm reachability from the backend. (this issue)
  3. Document the tested core + module version pair in docs/. (this issue)
  4. Settle the connection topology and SSRF policy exemption — #143, which needs deciding before any connection code.
  5. Then the adapter work: #5, #6, #7, #8.
  6. Install and validate on production before the pillar ships.

No code has been written for this pillar yet, so nothing is invalidated by the change.

🤖 Generated with Claude Code

### Approach change: dev Foundry instance first (2026-07-27) Decision from today's session: **the Foundry pillar will be built against a dedicated dev Foundry instance**, which does not exist yet. Standing one up is now the real first step of v4.0.0 — ahead of everything in this issue. That partially supersedes this issue's "validate against the real instance, not a throwaway" instruction, so worth being precise about what still holds and what changes: **Still holds — and is now the thing to get right.** The module is version-sensitive; that was the whole reason for insisting on the real instance. A dev instance is a perfectly good validation target *provided it matches production's Foundry core version and module version*. So the deliverable sharpens rather than weakens: record the tested **(Foundry core version, `foundryvtt-rest-api` version)** pair, and treat a drift between dev and prod on either as the compatibility risk to watch. A dev instance on a different core version would give false confidence — exactly what the original wording was guarding against. **Changes.** Installing the module on production is no longer step one. Prod becomes a later verification step, once the adapter work is proven against dev. **Why a dev instance is worth the setup cost:** this pillar writes into Foundry — actors, tokens, journal entries, live scenes (v4.2.0). Developing that against a live game world risks corrupting real campaign data, and there is no undo for a bad actor push. The same gap exists on the Discord side, incidentally: the dev bot has no `DISCORD_BOT_TOKEN`, so bot behaviour is currently only exercisable in production. **Suggested revised order for v4.0.0:** 1. Stand up a dev Foundry instance, matched to production's core version. 2. Install and configure `foundryvtt-rest-api` on it; confirm reachability from the backend. *(this issue)* 3. Document the tested core + module version pair in `docs/`. *(this issue)* 4. Settle the connection topology and SSRF policy exemption — [#143](https://git.rhoving.com/rbrooks/Quest-Board/issues/143), which needs deciding before any connection code. 5. Then the adapter work: #5, #6, #7, #8. 6. Install and validate on production before the pillar ships. No code has been written for this pillar yet, so nothing is invalidated by the change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot commented 2026-10-27 17:54:00 +00:00
Collaborator
Copy link

Note, 27 Oct 2026: whether this is the step at all depends on #143. The owner wants every option weighed there, including a Quest Board Foundry module that connects back to the service. Don't start this before #143 is decided.

Note, 27 Oct 2026: whether this is the step at all depends on #143. The owner wants every option weighed there, including a Quest Board Foundry module that connects back to the service. Don't start this before #143 is decided.
claude-bot changed title from [Foundry P1] Install & validate foundryvtt-rest-api on the production Foundry instance to [Foundry] Test (D337): a minimal Quest Board module pairs and round-trips in The Amberwake Accord 2026-11-06 03:20:02 +00:00
claude-bot commented 2026-11-06 03:24:20 +00:00
Collaborator
Copy link

Decided (owner, 2026-11-06, Q238; to be recorded as D338): the test's stand-in endpoint runs as a small throwaway container on docker-test, behind int-proxy at a LAN name (qb-foundry-test.lan.ryanbrooks.dev), set up in iac-repo the same way as foundry-dev, and removed after the test. Quest Board itself isn't touched, and dev keeps running published images only.

Plan

  1. Test code on a Quest-Board branch (spike/foundry-module), never merged:
    • tools/foundry-test/module/: the quest-board-test Foundry module;
    • tools/foundry-test/server/server.py: the stand-in, using websockets, with in-memory pairing codes and tokens, an Origin check, a command queue with ids, and a JSON-lines log.
  2. iac-repo PR, for the owner to approve:
    • the container on docker-test at host port 18131;
    • the int-proxy vhost qb-foundry-test.lan.ryanbrooks.dev, LAN only;
    • no public DNS, no backup, and a removal step.
  3. Run the eight checks above in The Amberwake Accord and record the results here.
**Decided (owner, 2026-11-06, Q238; to be recorded as D338):** the test's stand-in endpoint runs as a small throwaway container on docker-test, behind int-proxy at a LAN name (`qb-foundry-test.lan.ryanbrooks.dev`), set up in iac-repo the same way as foundry-dev, and **removed after the test**. Quest Board itself isn't touched, and dev keeps running published images only. **Plan** 1. **Test code** on a Quest-Board branch (`spike/foundry-module`), never merged: - `tools/foundry-test/module/`: the `quest-board-test` Foundry module; - `tools/foundry-test/server/server.py`: the stand-in, using `websockets`, with in-memory pairing codes and tokens, an `Origin` check, a command queue with ids, and a JSON-lines log. 2. **iac-repo PR**, for the owner to approve: - the container on docker-test at host port 18131; - the int-proxy vhost `qb-foundry-test.lan.ryanbrooks.dev`, LAN only; - no public DNS, no backup, and a removal step. 3. **Run the eight checks** above in The Amberwake Accord and record the results here.
claude-bot commented 2026-11-07 00:41:54 +00:00
Collaborator
Copy link

Test results (2026-11-07, with the owner at the browser): all checks pass

Setup: Foundry 14.369 with pf2e 8.7.0, The Amberwake Accord, module quest-board-test 0.1.0, and the stand-in endpoint at wss://qb-foundry-test.lan.ryanbrooks.dev/ws (D338). Browser: the owner's. The endpoint's log is the evidence.

# Check Result
1 Outbound wss:// from a launched world ✅ connected from origin https://foundry-dev.lan.ryanbrooks.dev (00:29:46). No CSP got in the way.
2 Pairing ✅ Ryan (role 4) paired with a code, and the token is stored per user. Wrong, used and expired codes are refused (scripted tests).
3 Command in, applied once ✅ create_actor made "Quest Board Test Courier", a level 3 pf2e NPC (v1MyT9c5zO8g0Qgk), and the owner saw it. Re-sending the same id gave duplicate: true with the same actor, and it still did after a restart.
4 Event out ✅ activating "Test Scene" arrived as scene_activated {id: l7dMzZbEBIGr2kpV, name: "Test Scene"} from the holder.
5 One holder, handoff ✅ Test-GM paired and went to standby behind Ryan. Closing Ryan's window handed the link to Test-GM in the same second (00:34:27). A second tab of the same GM also waits on standby.
6 No player link ✅ Player2 never reached the endpoint: no connection and no pairing attempt, even after saving a valid code. The endpoint's own refusal of role 1 is covered by the scripted tests.
7 Reconnect, nothing twice ✅ After docker restart, Test-GM reconnected about 1 s after the endpoint was up, with no input. Both pairings and the acknowledged commands survived (state on disk).

Findings for the real module (v5.0, #5, #6, #7):

  1. restricted: true doesn't hide a client-scope setting from players. Player2 saw the "Pairing code" field. Register the pairing UI only for full GMs, as a settings menu (registerMenu with restricted: true) or with a check in ready, and say something to a non-GM rather than doing nothing silently.
  2. Status needs a lasting place. Foundry's notices fade, and the owner missed the reconnect notice while switching windows. The real module wants a small connection indicator, plus "Connected / Waiting (held by …) / Not connected" in its settings.
  3. The token per user works: each GM pairs once, and nothing a player can read holds it (world settings are readable by every client).
  4. Reconnect delay was the endpoint's own start-up (about 16 s, mostly pip installing at start). The module's backoff began at 1 s.

D333–D337 hold up as designed: our own module, connecting out, per-campaign tokens, one holder with handoff, and queued, idempotent commands. Closing. The real build starts with #5, #6 and #7. The stand-in endpoint can be removed whenever the owner likes (#877, set qb_foundry_test_enabled: false and apply).

## Test results (2026-11-07, with the owner at the browser): all checks pass **Setup:** Foundry **14.369** with pf2e **8.7.0**, The Amberwake Accord, module `quest-board-test` 0.1.0, and the stand-in endpoint at `wss://qb-foundry-test.lan.ryanbrooks.dev/ws` (D338). Browser: the owner's. The endpoint's log is the evidence. | # | Check | Result | |---|---|---| | 1 | Outbound `wss://` from a launched world | ✅ connected from origin `https://foundry-dev.lan.ryanbrooks.dev` (00:29:46). No CSP got in the way. | | 2 | Pairing | ✅ Ryan (role 4) paired with a code, and the token is stored per user. Wrong, used and expired codes are refused (scripted tests). | | 3 | Command in, applied once | ✅ `create_actor` made "Quest Board Test Courier", a level 3 pf2e NPC (`v1MyT9c5zO8g0Qgk`), and the owner saw it. Re-sending the same id gave `duplicate: true` with the same actor, and it still did after a restart. | | 4 | Event out | ✅ activating "Test Scene" arrived as `scene_activated {id: l7dMzZbEBIGr2kpV, name: "Test Scene"}` from the holder. | | 5 | One holder, handoff | ✅ Test-GM paired and went to **standby** behind Ryan. Closing Ryan's window handed the link to Test-GM **in the same second** (00:34:27). A second tab of the same GM also waits on standby. | | 6 | No player link | ✅ Player2 never reached the endpoint: no connection and no pairing attempt, even after saving a valid code. The endpoint's own refusal of role 1 is covered by the scripted tests. | | 7 | Reconnect, nothing twice | ✅ After `docker restart`, Test-GM reconnected about 1 s after the endpoint was up, with no input. Both pairings and the acknowledged commands survived (state on disk). | **Findings for the real module (v5.0, #5, #6, #7):** 1. **`restricted: true` doesn't hide a client-scope setting from players.** Player2 saw the "Pairing code" field. Register the pairing UI only for full GMs, as a settings menu (`registerMenu` with `restricted: true`) or with a check in `ready`, and say something to a non-GM rather than doing nothing silently. 2. **Status needs a lasting place.** Foundry's notices fade, and the owner missed the reconnect notice while switching windows. The real module wants a small connection indicator, plus "Connected / Waiting (held by …) / Not connected" in its settings. 3. **The token per user works:** each GM pairs once, and nothing a player can read holds it (world settings are readable by every client). 4. **Reconnect delay** was the endpoint's own start-up (about 16 s, mostly pip installing at start). The module's backoff began at 1 s. D333–D337 hold up as designed: our own module, connecting out, per-campaign tokens, one holder with handoff, and queued, idempotent commands. Closing. The real build starts with #5, #6 and #7. The stand-in endpoint can be removed whenever the owner likes (#877, set `qb_foundry_test_enabled: false` and apply).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/1328-fill-it-in
feat/1328-fill-frontend
feat/1328-fill-backend
feat/9-foundry-push
fix/9-foundry-live
feat/9-foundry-push-frontend
renovate/celery-5.x
feat/5-foundry-connect
feat/9-foundry-push-backend
feat/9-foundry-push-module
feat/5-foundry-frontend
feat/5-foundry-backend
feat/5-foundry-module
release/v4.8.0-rc1
docs/d341-convert-draft
feat/958-update-to-version
feat/958-convert-sheet
feat/958-pathbuilder-import-frontend
fix/1360-heading-order
feat/958-pathbuilder-import-backend
feat/11-weekly-digest
feat/1341-auto-update
docs/d332-superseded
chore/1345-names-cleanup
feat/1342-mentioned-pages
feat/1328-recipes
fix/1346-pgdg-key
perf/1247-shared-recording-stream
chore/132-gitleaks-allowlist
release/v4.7.1
spike/foundry-module
release/v4.7.1-rc1
docs/decisions-d332-d337
fix/bot-certifi
chore/release-4.7.0
chore/release-4.7.0-rc4
chore/deps-4.7.0
chore/release-4.7.0-rc3
fix/1280-quote-must-say-it
fix/1257-names-row-squeeze
chore/release-4.7.0-rc2
fix/1245-pg-upgrade-count
chore/release-4.7.0-rc1
feat/1257-names-in-prep
feat/1257-be
feat/1257-fe
feat/1257-rating-fixes
design/1328-fill-it-in
feat/1257-name-splits
fix/1326-redis-503
feat/1280-fact-suggestions
feat/1280-be
feat/1280-fe
design/1280-fact-suggestions
feat/1279-infobox
feat/1279-be
feat/1279-fe
feat/1321-shelf-copies
design/1279-infobox
feat/1243-table-find
feat/1257-who-rated
feat/1243-prep-drawer
feat/1243-sheet-pickers
design/1243-browse-in-place
feat/1315-hotwords-default
feat/1242-system-filters
feat/1257-more-name-styles
feat/506-leg3-hotwords
design/1242-system-filters
fix/1302-packs-polish
feat/1241-rules-library
design/1241-rules-library
feat/1245-postgres-18
integ/4.6.2
fix/1263-map-ui-2
fix/1263-map-server
fix/1263-map-ui-1
fix/1261-editor-link-menu
fix/1229-axe-4.14-name-mismatch
renovate/axllent-mailpit-1.x
renovate/eslint-monorepo
renovate/authlib-1.x
chore/release-4.6.0
chore/release-4.6.0-rc2
fix/460-rc2-screens
fix/460-rc2-server
fix/release-prerelease-exit
chore/release-4.6.0-rc1
feat/125-campaign-templates
feat/126-calendar
feat/1181-pictures-and-files
feat/1190-event-people
integ/4.6.0
feat/1191-line-of-the-night
feat/1200-starter-packs
chore/bot-multidict-and-playwright-group
fix/1202-this-week-answered-count
fix/122-124-leftovers
fix/1178-get-routes-that-write
fix/1203-journeys-check-names
design/125-campaign-templates
feat/126-calendar-engine
design/126-in-world-calendar
fix/1189-cited-stamp-in-range
fix/1189-v4-looser-check
fix/1189-richer-beats
fix/1113-export-bind-lists
fix/1154-release-notes-by-file
chore/release-4.5.0
chore/release-4.5.0-rc12
fix/1135-wiki-markup-as-text
fix/demo-usage-cost-in-window
chore/release-4.5.0-rc11
fix/1121-sheet-consistency
fix/1121-sheet-5e-terms-and-card-hp
copy/1122-busiest-pages
fix/1121-relevant-choices
fix/1121-wiki-create-npc-save-sheet-links
fix/1029-menu-stays-on-screen
docs/prototype-transcript-bin-wording
fix/1023-editor-save-row-back-scroll
fix/1020-search-exact-first
fix/1020-table-prep
fix/1020-shell-wordmark-footer-bell
fix/1020-wiki-article-party
fix/872-admin-kept-until-phone-tables
feat/l13-milestone-level-waiting
fix/1000-1001-bell-older-setup-context
fix/999-pronouns-in-prompts
fix/l19-other-class-feats
fix/1010-transcript-window-ordinary-confirm
docs/d254-d269-decisions
fix/702-member-search
fix/680-transcript-bin
fix/993-unidentified-prompts
fix/841-redis-timeouts
fix/990-binned-not-exported
fix/830-export-prep-shelf
fix/deps-audit-2026-10-01
fix/877-title-reads
fix/798-audio-received-at
build/lane11-17-j7
build/lane11-16-levelup
build/lane11-14-seams
build/lane11-14-seed
build/lane11-15-start
build/lane11-13-old-block-out
fix/980-review-r3
build/lane11-12-block
build/lane11-8-packs
fix/demo-seed-canonical-names
build/lane11-11-hot-half
docs/l11-decisions
build/lane11-7-convert
build/lane11-10-editing
fix/npm-audit-brace-expansion
build/lane11-9-sheet-page
fix/bot-pyjwt
build/lane11-6-content
fix/lane11-rank-names
build/lane11-2b-language
build/lane11-4-js-evaluator
build/lane11-3-server
build/lane11-5a-pf2e
build/lane11-5b-5e
feat/design-admin
build/lane11-2-evaluator
build/lane11-1-sheet-pieces
build/lane11-0-drawing
fix/943-quest-objectives-fk
fix/prepsheet-shelf-flake
fix/945-leftovers
build/demo-gm-copy
fix/901-email-landings
build/lane10-8-journeys
build/demo-seed-lanes-8-10
fix/887-gm-own-confirmation
build/lane9-5-j1-admin
fix/918-audience-click
fix/useasync-overtaken
ci/939-critical-path
test/937-backend-suite-speed
chore/claude-orchestration
fix/924-xp-gm-only
fix/session-stale-poll
docs/decisions-d239-d242
fix/930-pypdf
build/lane8-journeys
build/925-quest-editor
fix/894-private-page-pictures
build/lane8-p4-drafts
build/lane8-p7-map
build/lane8-p6-handouts-rules
fix/wiki-fixture-names
build/lane10-d227-test-usage
fix/rsvp-horizon-test-tuesday
fix/media-volume-owner
build/lane8-p3-editor
fix/912-unidentified-rename
build/lane8-p5-party-quests
build/lane8-handout-takeback
build/lane10-pickers
build/lane8-p2-article
build/lane8-6-map
build/lane10-7b-email-pages
build/lane8-5-handouts
build/lane10-7a-test-the-bot-pages
build/lane8-p1-pages
build/lane8-4-quests
build/lane8-2b-feeds
build/lane8-3-parties
build/lane8-2a-links
build/lane10-5-commands
build/lane9-6-seed
build/lane10-4b-reactions
build/lane9-4d-pages
build/lane9-4c-pages
build/lane10-4a-posts
build/lane10-3-email
fix/891-web-fonts
build/lane9-4b-pages
build/lane10-6-test-the-bot
build/lane10-2-notify-out
build/lane8-1-wiki-text
build/lane9-4a-frame
design/lane10-drawings
fix/j6-budget
fix/j5-phone-flake
fix/869-test-leaks
fix/843-record-start-followups
build/lane7-all
build/lane6-all
build/lane9-b2-server
chore/changelog-fragments
docs/decisions-d218
build/lane9-a-owner-overview
fix/rule-card-level-label
fix/834-retention-semantics
fix/o3c-record-without-announcement
docs/decisions-d179
docs/decisions-d131-d170
fix/851-commit-before-response
build/lane6-j3-seed
build/lane9-b1-d67-identity
fix/841-blocking-loop
build/lane9-c-backups-audit
fix/vote-race-and-start-commit
fix/recording-announcement
fix/proposal-read-leak
fix/last-admin-guard
build/lane6-p4c-planning
build/lane6-p4b-margin
build/lane6-p4a-sheet
build/lane5-j4-seed
build/lane6-base
build/lane7-pages-talk
build/lane5-pages
build/lane7-pages-safety
build/lane7-p3-safety
build/lane7-p2-notify
build/lane6-p3-planning
build/lane6-p2-history
build/lane6-p1b-items
build/lane7-p1-threads
build/lane5-p6-faces
build/lane6-p1a-sheet
build/lane5-p5-find
build/lane5-p4a-board
build/lane5-p4b-scenes
build/lane5-p3-live
build/lane5-base
build/lane5-p2-cards
docs/lane5-decisions
build/review-r2-wide
fix/review-r1
build/lane5-p1-scenes
build/demo-seed
build/lane4-journeys-j5
build/lane4-page-review-b
build/lane4-page-review-a
build/lane4-page-read
build/lane4-journeys
build/lane4-page-sess2
build/lane4-page-sess1
build/lane4-notes
build/lane4-discord-on-approval
build/lane4-scheduling
build/lane4-versions
build/760-session-number
build/lane4-decisions
build/797-erase-no-regenerate
build/test-race-audit
build/lane3-completions
build/794-dark-only
build/796-titles-scroll
build/791-retention-anchor
build/a11y-sweep
build/shell-followups
build/retention-preview
build/753-backup-readback
docs/d91-d93
build/lane3-j1
build/ci-harness-paths-selftest
fix/useauth-test-race
build/ci-harness-paths
build/777-ai-settings-read
build/lane3-settings-c
build/lane3-settings-b
build/lane3-j6
build/lane3-sessionform
build/lane3-settings-a
build/lane3-members
build/lane3-thisweek
build/lane3-story
chore/87-align-python-3.12
v4.8.0-rc1
v4.7.1
v4.7.1-rc1
v4.7.0
v4.7.0-rc4
v4.7.0-rc3
v4.7.0-rc2
v4.7.0-rc1
v4.6.2
v4.6.2-rc4
v4.6.2-rc3
v4.6.2-rc2
v4.6.2-rc1
v4.6.1
v4.6.1-rc1
v4.6.0
v4.6.0-rc2
v4.6.0-rc1
v4.5.3
v4.5.3-rc1
v4.5.2
v4.5.2-rc1
v4.5.1
v4.5.1-rc2
v4.5.1-rc1
v4.5.0
v4.5.0-rc12
v4.5.0-rc11
v4.5.0-rc10
v4.5.0-rc9
v4.5.0-rc8
v4.5.0-rc7
v4.5.0-rc6
v4.5.0-rc5
v4.5.0-rc4
v4.5.0-rc3
v4.5.0-rc2
v4.5.0-rc1
v4.4.1
v4.4.0
v4.3.0
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.2
v4.1.1
v4.1.0
v4.0.1
v4.0.0
v3.11.4
v3.11.3
v3.11.2
v3.11.1
v3.11.0
v3.10.0
v3.9.1
v3.9.0
v3.8.0
v3.7.0
v3.6.1
v3.6.0
v3.5.0
v3.4.1
v3.4.0
v3.3.0
v3.2.0
v3.1.0
v3.0.0
v2.1.0
v2.0.0
v1.1.0
v1.0.0
v0.12.0
v0.11.0
v0.10.0
v0.9.1
v0.3.3
v0.9.0
v0.8.0
v0.3.2
v0.3.1
v0.3.0
v0.7.0
v0.6.0
v0.5.0
v0.4.0
v0.2.1
v0.2.0
v0.1.1
v0.1.0
Labels
Clear labels   
backend
Issue related to the backend

  
bot
Issue related to the bot

  
bug
Something is not working

  
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
frontend
Issue related to the frontend

  
help wanted
Need some help

  
invalid
Something is wrong

  
question
More information is needed

  
recording
Issue related to the recording system

  
security
Security hardening / vulnerability work

  
wontfix
This won't be fixed

No labels
backend
bot
bug
duplicate
enhancement
frontend
help wanted
invalid
question
recording
security
wontfix
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#4
No description provided.