EPIC: Make the public QUEEN board repository-aware for TurboBaby and future worlds

[gHashTag]

Outcome

Allow the public QUEEN board to represent accepted work from more than one GitHub repository, beginning with gHashTag/turbobaby-user-bot, without changing the meaning or availability of the existing Trinity board.

This is the upstream publication dependency for:

• Wire the TurboBaby specs into the Queen game and the spec browser turbobaby-user-bot#22
• EPIC: Consolidate, execute, and publish the TurboBaby .t27 contracts turbobaby-user-bot#30

Measured problem

As of 2026-09-13, the production source in apps/website/src/pages/Queen.tsx models a board with one top-level repo: string. Individual cards do not carry repository identity. Foundation/epic state follows the same single-repository assumption, and the page reads /queen/public-board.

That shape cannot safely add a second repository:

• issue numbers collide across repositories;
• card and foundation links inherit one board-wide repository;
• filters cannot select a world/repository;
• a TurboBaby card could be rendered as a Trinity issue;
• the downstream repository cannot truthfully claim QUEEN publication from its own code.

Scope and work plan

1. Define the multi-repository board contract

• Choose and document the request shape: one repository per request, a bounded repos query, or a server-defined world collection.
• Put an explicit normalized repository identifier on every card, epic/foundation item, pulse aggregate, and error attributable to one source.
• Use a collision-safe identity such as (repo, issue_number) throughout the API and UI; never use issue number alone.
• Specify stable ordering, pagination/bounds, partial-source failure semantics, cache keys, and freshness metadata.
• Preserve a compatibility path for the existing single-repository response during rollout.

2. Extend the supervisor/public-board implementation

• Fetch only allowlisted public repositories and validate owner/repo input.
• Apply the same acceptance/status rules to every selected repository.
• Return source-scoped errors without dropping healthy repositories.
• Keep credentials, private issue content, and user PII out of the public payload and logs.
• Add metrics for requested repositories, successful sources, stale sources, rejected inputs, and response age.

3. Extend the QUEEN frontend

• Render the repository/world on cards and in accessible link labels.
• Build every GitHub link from the card's repository identity.
• Add a repository/world filter that does not reset the current board state unexpectedly.
• Make foundation/epic views and counts repository-aware.
• Preserve the current Trinity-only experience when the server returns the legacy payload or only one source.
• Show partial and stale states explicitly; never imply that an unavailable repository has no work.

4. Contract and regression tests

• Two repositories with the same issue number render as two distinct cards with correct links.
• Mixed-repository foundation/epic data retains its source through filtering and navigation.
• Invalid, private, unallowlisted, timed-out, and partially failing sources fail safely.
• Legacy single-repository fixtures still render correctly during the compatibility window.
• Cache keys and ETags vary by the normalized repository selection.
• A browser-level test proves that a TurboBaby epic resolves from /queen/public-board to the correct public GitHub issue.

5. Rollout and evidence

• Document the contract version and compatibility window.
• Deploy supervisor and frontend changes in an order that keeps the current board usable.
• Add gHashTag/turbobaby-user-bot to the approved public sources only after its canonical .t27 files are tracked and published.
• Capture deployed API and browser evidence before closing the downstream publication issue.
• Remove the compatibility shape only in a separate, explicitly tracked cleanup.

Acceptance criteria

• /queen/public-board can return at least Trinity and TurboBaby data with unambiguous repository identity.
• Issue identity, links, filters, foundation/epic aggregation, cache behavior, and error reporting are repository-aware.
• Existing Trinity-only consumers retain a safe compatibility path during rollout.
• Invalid or failed secondary sources cannot corrupt or erase healthy board data.
• Automated contract, unit, and browser tests cover collisions and partial failure.
• A deployed proof shows one real gHashTag/turbobaby-user-bot epic on https://t27.ai/#/queen linking to the correct issue.
• No downstream repository claims QUEEN publication before that deployed proof exists.

Non-goals

• This epic does not deploy TurboBaby itself.
• It does not make a formal GitHub fork discoverable by the t27 world scanner.
• It does not move operational spreadsheet data, customer records, pricing internals, or secrets into QUEEN.