feat(website): TRI tab, the app at app.t27.ai inside the Queen

[gHashTag]

Description

A thirteenth Queen tab, TRI (key r): the app at app.t27.ai inside the
game. A row of its screens (Feed, Agent, AI, Profile, CRM) sits over one frame
of the real app page, https://app.t27.ai/<route>?embed=1&lang=<lang>.

Every screen has its own address, #/queen?tab=tri&screen=chat, plus path=
for one profile. A click writes it and a reload reads it. An address changed
from outside (Back, a link, a script) moves the screen and the frame. Stages the
app switches inside the frame (the AI pipeline) come back as a route message and
are written to the address without reloading the frame.

Closes #1010

Related Issue

#1010. The player side is gHashTag/999-multibots-telegraf
feat/player-embed-for-game: it lets t27.ai frame the app, adds embed mode and
the route bridge, and keeps the tab's sign-in out of frames by other sites. It
ships and is verified live before this PR merges.

Changes Made

• src/lib/triScreens.ts (new): the screens, their app routes, the deep-path
  allowlist, the message filter and the address builder. Frame URLs are always
  APP_ORIGIN plus a listed route. Only plain-object messages from app.t27.ai
  and from TRI's own frame are heard, and nothing is posted into the frame.
• src/components/QueenTri.tsx + .css (new): the screen row, the frame, and
  a strip when the app has not answered 8 s after load (a frame refused by
  frame-ancestors still fires load). One frame element for the life of the
  view, moved with contentWindow.location.replace, so a screen click adds no
  history entry and Back walks the app's own pages.
• Queen.tsx, queenHud.ts, queenModules.ts, QueenCommand.tsx: the tab,
  key r, command entry and copy. Both address writers (the shell's tab and
  TRI's screen) build from the live hash, because React Router 7.13 hands the
  updater stale params inside a pending transition.
• App.tsx: no TRI preview on the landing. An embedded Queen that reaches TRI
  frames nothing and says so.
• CRM client ids are never put in the address (they are customers' Telegram
  ids); the CRM is addressed at its list.
• QA: qa/tri-screens-contract.mjs (pure, in website-checks) and
  qa/queen-tri-contract.mjs (built site in Chrome, 14 checks). The viewport
  gate derives its command count from HUD_VIEWS, and agents-spec-contract
  knows the new module.

🔥 TOXIC VERDICT

What Works

• queen-tri-contract 14 of 14 on the build. Checks 5, 12 and 14 fail on the
  previous build with the real defects (a CRM id in the hash, Back stuck twice,
  an embedded Queen framing the app).
• tri-screens-contract kills 12 of 12 independent mutants of triScreens.ts,
  including the three a reviewer found surviving.

What Doesn't Work / Limits

• On t27.ai, TRI is a guest. Telegram's login widget only allows app.t27.ai as
  an ancestor, and the player deliberately keeps the tab's session out of
  frames by other sites. Agent, AI, Profile and CRM say "sign in inside the
  app" with a link out. Identity in the game comes with the single sign-on step.
• Until the app replaces instead of pushing in embed mode, history entries
  pushed in the frame before leaving TRI for another tab stay dead Back steps.
• The Chrome contract runs with site isolation off so CDP can stub the app
  frame; out-of-process iframe behaviour is not measured.
• check:tools and check:docs fail identically on the base commit.

Overall Assessment: APPROVE after the player is live. Self-Score: 7/10.

🌳 TECH TREE Options

1. Single sign-on via a scoped game token (identity chip, live sign-in/out). ★★★★★
2. Replace instead of push inside the embed so one Back always leaves TRI. ★★★☆☆
3. Measure the tab in Safari and Telegram WebViews. ★★★☆☆

{
  "version": 1,
  "head_sha": "fb11082699ab82a67749b922e8365d50fdc82710",
  "summary": "The Queen gains a TRI tab that frames the real app.t27.ai screens (feed, agent, AI pipeline, profile, CRM) with one address per screen, route sync from the app, a no-answer strip, and guards that keep customer ids out of the address and never post into the frame.",
  "changes": [
    "apps/website/src/lib/triScreens.ts: screen list, app routes, deep-path allowlist, message filter and address builder for the TRI tab.",
    "apps/website/src/components/QueenTri.tsx and QueenTri.css: the screen row, a single app frame moved with location.replace, and the strip shown when the app does not answer.",
    "apps/website/src/pages/Queen.tsx, components/queenHud.ts, lib/queenModules.ts, components/QueenCommand.tsx: the tri tab, key r, command entry and copy, with both address writers built from the live hash.",
    "apps/website/src/App.tsx: no TRI preview on the landing; an embedded Queen shows a notice instead of framing the app.",
    "apps/website/qa/tri-screens-contract.mjs, qa/queen-tri-contract.mjs, website-checks.yml, package.json: new contracts; queen-viewport-contract and agents-spec-contract updated for the thirteenth tab."
  ],
  "tests": [
    {
      "command": "npm run check:tri (qa/tri-screens-contract.mjs)",
      "status": "passed",
      "result": "10 screens, 29 app paths, key r at position 13; 12 of 12 independent mutants of triScreens.ts fail it.",
      "evidence": "Local run in the feat/queen-tri-tab worktree on 2026-09-14; mutants from the fix pass mutate.sh"
    },
    {
      "command": "node qa/queen-tri-contract.mjs --no-build on the branch build",
      "status": "passed",
      "result": "14 of 14 checks pass, including Back after in-frame pushes, the replace control and an embedded Queen asking app.t27.ai for nothing.",
      "evidence": "Session scratchpad tri-tab/game/fix2/tri-full.log"
    },
    {
      "command": "node qa/queen-tri-contract.mjs --only 1,5,12,13,14 on the previous build",
      "status": "failed",
      "result": "Control, expected to fail: check 5 shows a CRM id in the hash and check 12 shows Back staying on the same frame twice.",
      "evidence": "Session scratchpad tri-tab/game/fix2 logs of the previous build"
    },
    {
      "command": "npm run typecheck:ratchet; npx eslint on the changed files; npx vite build",
      "status": "passed",
      "result": "179 type errors against a baseline of 179 with no file gaining errors, eslint clean, production build succeeds.",
      "evidence": "Local runs in the feat/queen-tri-tab worktree on 2026-09-14"
    },
    {
      "command": "npm run check:tools; npm run check:docs",
      "status": "failed",
      "result": "Both fail with the same assertions and hashes on a git archive copy of the base commit, so the failures predate this change.",
      "evidence": "Local runs on the branch and on the base archive, 2026-09-14"
    }
  ],
  "limitations": [
    "On t27.ai the TRI frame is a guest: screens that need a person link out to app.t27.ai until single sign-on ships.",
    "History entries the app pushes inside the frame before the user leaves TRI for another tab remain dead Back steps until the app replaces in embed mode.",
    "The Chrome contract runs with site isolation off to stub the app frame, and Safari, Firefox and Telegram WebViews were not measured."
  ],
  "tags": ["Website", "Queen", "Integration"],
  "blog": {
    "title": "The app inside the game",
    "summary": "The Queen board on t27.ai now frames the TRI app's real screens, one address per screen, while the app keeps its sign-in out of frames by other sites.",
    "outline": [
      "The ask: every screen of the TRI app, from the feed to the CRM, reachable from inside the Queen game with its own address.",
      "The shape: one frame of the real app page in embed mode, a screen row, and route messages that write the app's stage back into the game's address.",
      "The traps: router updaters that erase each other inside a transition, a fresh iframe per screen that stranded Back, and customer ids leaking into links.",
      "The security turn: t27.ai and app.t27.ai are one site, so the frame shared the tab's sign-in until the app stopped trusting frames by other sites.",
      "What is next: a scoped game token for single sign-on, replace-only navigation inside the embed, and measurements beyond Chrome."
    ]
  }
}

🤖 Generated with Claude Code

[gHashTag]

Verified live on https://t27.ai after the publisher run (ghashtag.github.io "Publish assets/index-DRlHf4KG.js from trinity 4df991a"; tree of the merge equals the tree of the reviewed branch, 613407a0). The player side (gHashTag/999-multibots-telegraf#2407) was deployed and verified first.

Headless Chrome, one tab, the way a visitor gets there: an app.t27.ai document first stores a fake session value in that tab, then the same tab opens the Queen.

check	result
control: top-level app.t27.ai/chat renders its header	pass
#/queen?tab=tri&screen=chat shows TRI on chat	pass
frame is https://app.t27.ai/chat?embed=1&lang=ru and loads (not refused by frame-ancestors)	pass
frame in embed mode (marker set, no header), ancestor https://t27.ai	pass
armed: the frame can read the tab's fake session value	pass
TRI frame present and no "did not answer" strip after 9 s	pass
click Feed: address drops screen=, frame document moves to /feed	pass
outside hash change moves TRI to profile	pass
no request carries the tab's session as Authorization (146 requests, 8 API calls)	pass, 0 leaked

11 of 11, no page exceptions. The general Queen tab probe on the same bundle: 50 of 50 (the thirteenth tab included).

Negative control: the same probe on the previous live build (index-CDBPZ6ez.js, run finished one second before the switch) failed the TRI checks. It also exposed a vacuous check ("no strip" passes when there is no frame at all); that check now requires the frame first.

Not verified: Safari, Firefox, Telegram WebViews; identity inside TRI (the frame is a guest by design until single sign-on ships).