v1.9.0-rc.6

Sixth release candidate for v1.9.0. Cut from protected main at
c33e76b05fda6a9bdaa7beea7527414b13d74c1b (release record PR #47), carrying the entry-lifecycle,
concept-search, search-performance, and searchable-deployments line merged in
PRs #43, #44, #45 and #46 (feature head
cf55fd735d091172222801d551ee989abb3b0319, all required contexts plus scale,
audit, and CodeQL green on each).

What changed since rc.5

• Search understands more than exact words — the build derives a concept
  map from the catalog's own writing and quietly widens each query with its
  top related words; a widened hit always ranks strictly below every literal
  one. Deterministic, tunable via _data/search.yml, off below 12 entries.
• Search at 1,000 entries is a measured budget, not a hope — the
  performance fixture builds 0/1/10/100/500/1,000-entry catalogs and real
  Chrome drives search, filtering, sorting and compare at every size against
  enforced scale_budgets; the measured table lives in docs/search.md.
• The cost of building search moved off the reader's path — where the
  browser has workers, the fetch/parse/index build runs in
  assets/js/search-worker.js and the page revives the serialized result; a
  finished build is kept in IndexedDB keyed to a version covering both the
  content and the index implementation, so a return visit to an unchanged
  catalog searches instantly and any upgrade retires stale caches on its own.
  A low-powered device facing a 300+-entry catalog gets an honest Load full
  search button with real progress instead of a silent stall; every worker
  or cache failure falls back to the original inline path.
• "How search works" — a public /about/search/ page explains the
  serverless, no-query-log architecture honestly, including the one caveat
  (the search persists in the address bar, so a shared or reloaded URL does
  travel to the host).
• Stale entries ask to be refreshed — the monthly sweep opens per-entry
  reminder issues @mentioning the submitter (new optional GitHub-username
  form field), the Refresh an entry form turns "still accurate" into a
  one-line verified: PR, and reminders close themselves once confirmed.
• Organizations can attach themselves to an entry — the Also deployed
  by form splices {label, url, email, note} items into the entry's list
  via a bot PR (resubmissions update in place, flagged as replacements for
  reviewer scrutiny), rendered wherever links render — and the listings are
  searchable, with contact addresses and URLs kept out of the index.
• Security signals, observed rather than asserted — a monthly sweep
  records each linked repository's existence, archive state, last push,
  license, security policy and OpenSSF Scorecard into deployment-owned data,
  rendered beside the maintainer-only security_review status under a
  standing disclaimer.

Full details: CHANGELOG
and the release-readiness status.

Known notes

• Code-scanning alerts #42 and #43 (js/client-side-request-forgery,
  js/missing-origin-check on assets/js/search-worker.js) are documented
  false positives — a dedicated worker reachable only by its creating page,
  with the fetch target pinned to a same-origin path — awaiting maintainer
  dismissal in the repository Security tab.
• BCHC consumed v1.9.0-rc.5 via
  its update PR #14
  on 2026-08-26 and is locked there. The rc.6 update requires the
  security-signals ownership migration
  (BCHC PR #29)
  first — the updater correctly fails closed on the contract change — and the
  candidate update PR follows from rerunning Update from PHCT after it.

Rollback point

v1.9.0-rc.5 at 607169f1b12c6bb44e959e626c19f2ca9eefa6f0.

🤖 Generated with Claude Code