-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
The plan, phase by phase. Spikes come first because they de-risk the whole approach before any polish is built.
-
S1 — Path P end-to-end. A bookmarklet
window.opens the app; the popup fetches an index and searches under a real GitHub wiki page's CSP. Status: built (spikes/s1/), pending the manual browser gate. -
S2 — Text-fragment positioning. Confirm
#anchor:~:text=highlight across browsers, spike same-tab navigation, confirm anchor-only fallback, and handle GitHub'suser-content-anchor quirk. Status: built (spikes/s2/) with a deterministic local probe, pending the cross-browser checklist. - S3 — Builder on a real wiki. Run the builder over a real wiki, compare relevance against GitHub's native search, and measure raw/gzip index size. Status: blocked on real wiki content — this very wiki is the corpus.
The versioned, self-describing Index Format and the wiki-index CLI
(Markdown → deterministic per-section index, GitHub-anchor-aware). Status:
shipped — builder/, with tests.
?wiki=owner/repo / ?index=url loading with full verify-or-explain (404 / bad
JSON / unsupported version / missing fields). In progress.
The window.open stub (generic-GitHub + bring-your-own-index), popup search
mode, a bookmarklet builder + bookmark host, and a read-only help/FAQ.
Text-fragment links and same-tab navigation via a named target (the only same-tab option that preserves the highlight).
An "add search to your own wiki/Pages" guide, plus folding the bookmarklet and standalone-search link into the wiki's own navigation.
The builder in the wiki's pre-commit hook, and a main-repo CI git diff --exit-code gate so a stale index can't land.
- Search engine: a hand-rolled ranker (current), MiniSearch, or Orama — decided at S3 against real relevance.
- Whether to keep or drop the
#anchoron GitHub (it can fight the text-fragment scroll) — decided from the S2 real-page result. - Same-tab navigation in v1, or new-tab-only to start.