queen: cover closed gHashTag/t27 issues by merged PR + sealed spec (Closes #1504)

[dmitrii-f-t27]

Closes #1504

Queen: closed issues of gHashTag/t27 are painted covered by a dynamic rule, no hash table.

Rule (specs/queen/t27_issue_proof.t27, sealed): a merged PR closed the issue with a Closes #N line; every .t27 spec that PR added or changed is present at the repository head with a seal whose spec_hash equals the file's current sha256 and tests.passed == tests.total > 0 (nothing blocked or failed); validate, check-linked-issue and parse-ratchet are green on the PR's head commit (what branch protection gates the merge on). Compiler-only PRs and specs without tests stay unknown. A changed spec without a fresh seal turns its issue unknown again.

Reader createMergedPrSpecReader in queenIssueProof.ts, same refresh/invalidation discipline as the other readers. It is anonymous and runs in the browser, so it reads the head commit, raw spec and seal files, and spends the GitHub API only on the merged-PR record and the PR's check runs (kept for the session, they never change once merged). Budget MAX_PR_LOOKUPS bounds API reads per view; past it, or on a rate limit, rows stay unknown and never turn green on a guess.

Index: the issue to PR to spec mapping is a hint on branch queen-t27-coverage-index (seeded with dmitrii-f-t27's PRs since 2026-09-01), rebuilt every 10 minutes by .github/workflows/t27-coverage-index.yml via scripts/t27-coverage-index.mjs. Every claim in it is re-verified by the reader. Merge-to-green delay is therefore: raw CDN cache (about 5 min) plus the index rebuild (up to 10 min) plus the 1 min reader cache.

Checks run locally

• node scripts/issue-proof-from-spec.mjs --check; node --experimental-strip-types qa/queen-issue-proof.mjs: 44 + 11942 + 78 cases, conformance vectors PASS.
• 9 mutations of the reader (zero tests allowed, no hash check, blocked/failed allowed, unmerged allowed, merge sha unchecked, closing line unchecked, no-spec PR accepted, check conclusion unchecked, budget off) are each caught by a test.
• typecheck:ratchet: 179 errors across 26 files, baseline 179 across 26; eslint clean on the touched files.
• Live dry run against GitHub with the seeded index: 80 indexed issues, 39 painted covered; the 41 others are PRs whose specs are unsealed, sealed with zero or blocked tests, or compiler-only. 75 API reads for the whole run.

Not part of this PR: moving QUEEN_REF in 999-multibots-telegraf (release by the co-founder) and the live check on app.t27.ai after that.

{
 "version": 1,
 "head_sha": "f86fd6ee25c2d56a2e6ea40af5ef5acd0c488897",
 "summary": "Queen can now paint closed issues of gHashTag/t27 as covered by a rule it re-evaluates against the live head instead of a table of pinned file hashes: a merged PR with a closing line, sealed specs with the file's current hash and passing tests, and green required checks.",
 "changes": [
  "apps/website/specs/queen/t27_issue_proof.t27 holds the policy as a sealed spec: repository, index location, required check names, lookup budget, cache time and the sixteen-row acceptance table where only the all-true row is accepted.",
  "apps/website/src/lib/queenIssueProof.ts gains createMergedPrSpecReader, which reads the head commit and raw spec and seal files, spends the anonymous GitHub API only on the merged PR record and its check runs, and leaves a row unknown on any doubt or rate limit.",
  "scripts/t27-coverage-index.mjs and .github/workflows/t27-coverage-index.yml rebuild the issue to PR to spec index on its own branch every ten minutes; the reader treats it only as a hint and re-verifies each claim."
 ],
 "tests": [
  {
   "command": "node scripts/issue-proof-from-spec.mjs --check && node --experimental-strip-types qa/queen-issue-proof.mjs",
   "result": "44 and 11942 existing cases plus 78 new t27 cases pass, 16 conformance vectors per policy",
   "status": "passed",
   "evidence": "Local run 2026-10-07 in apps/website over origin/main 5b781309"
  },
  {
   "command": "nine mutations of the reader, each removing one condition (zero tests, hash, blocked or failed, merged, merge sha, closing line, spec presence, check conclusion, API budget)",
   "result": "every mutation is caught by at least one test case",
   "status": "passed",
   "evidence": "Local run 2026-10-07; three mutations first survived and gained cases"
  },
  {
   "command": "npm run typecheck:ratchet and eslint on the touched files",
   "result": "179 errors across 26 files equals the baseline, eslint reports nothing",
   "status": "passed",
   "evidence": "Local run 2026-10-07 after npm ci"
  },
  {
   "command": "live dry run of the reader against GitHub with the seeded index",
   "result": "80 indexed issues, 39 painted covered, 75 API reads, 93 seconds sequentially",
   "status": "passed",
   "evidence": "Run 2026-10-07 with an authenticated token; anonymous allowance not exercised end to end"
  }
 ],
 "limitations": [
  "The painted result on app.t27.ai depends on QUEEN_REF moving in the release repository, which is a separate merge by the co-founder, so no live cell has changed yet.",
  "Delay from merge to green is the raw content cache plus the index rebuild plus the reader cache, about fifteen minutes at worst, not instant; the real figure is measured only after the release.",
  "Specs without tests, with blocked tests or sealed with zero tests stay unknown by design, and compiler-only pull requests have no spec to prove."
 ],
 "tags": [
  "queen",
  "t27",
  "coverage",
  "seals"
 ],
 "blog": {
  "title": "Queen learns to check t27 issues against live seals",
  "summary": "Closed issues of the t27 repository can now show as covered when a merged pull request, current seals with passing tests and green required checks all agree, without a table of pinned hashes.",
  "outline": [
   "The Queen map showed every closed issue of the t27 repository as red because its readers only knew two repositories and each needed a table of pinned hashes that cannot keep up with hundreds of changing specs.",
   "The new rule is read live: a merged pull request closed the issue with a closing line, each spec it touched has a seal recording the file's current hash and passing tests, and the required checks were green on the pull request head.",
   "A browser reader cannot spend much of the anonymous API allowance, so it reads raw files for specs and seals and uses the API only for the pull request record, keeping results per pull request and staying unknown when the budget runs out.",
   "The mapping from issue to pull request to specs lives on its own branch and is rebuilt every ten minutes, but it is only a hint, because the reader re-checks every claim before it paints a cell."
  ]
 }
}

Dmitrii Fedorov (@dmitrii-f-t27)