One catalogue.
Two ways to use it.

Historical screening and archive
How to read the numbers: the list keeps about one candidate in four. "From your bookmarks" counts every kept repository you bookmarked; the "Your bookmarks only" collection leaves out those that are also in the Omni catalogue. A repository can come from more than one place (for example the Omni catalogue and your bookmarks), so the tags on a card can overlap.
The historic selection examined 412 candidates at v1.3.0; currently retained and archived records are browsable, while only a small, task-relevant subset should enter an AI run. The initial v1.3.0 Pareto Via Negativa selection kept 115 candidates and left out 297; subsequent changes are in the dated change history. Left-out entries are not banned: they stay listed below so an AI does not add them back without new evidence.
Each candidate was scored from 1 to 5 on six criteria by two independent raters (their scores were averaged):
fit
(does it improve an Omni run or a real task),
distinct
(is it not duplicated by a better entry in the same category),
clarity
(is it clear what it is),
breadth
(useful across many tasks),
safety
(small footprint, low risk) and
appeal
(interesting to browse). Four option profiles weigh the criteria differently (Omni first, balanced, billboard, low risk). An entry is kept by the vote if it ranks in the top quarter (a tie at the cut counts as inside) under at least three of the four profiles, so no single set of weights decides. The other kept entries are your own projects, one category's best entry, and entries that your development notes or stated needs call for (rules 4 to 7 in the AI guide). This is the historical screening rule, not a rule for rejecting otherwise viable domain-specific or lifecycle-critical candidates; use-case indexing is independent of the old selection vote. The overall score on a card is the Balanced profile's weighted mean. Two gates apply first: an entry with clarity below 2 is left out, and so is an entry that a same-category peer matches or beats on all six criteria and beats on at least one, unless it is in the top quarter under all four profiles. Entries kept for development use or a stated need override the gates (rules 6 and 7 in the AI guide).
The scores used no star counts and no live GitHub data: they come from the catalogue's own descriptions and notes, so they are judgements, not measurements. After the selection, the kept repositories were checked on GitHub at the 1.3.0 selection on 2026-11-01 (existence, archived state, licence, last push); the left-out entries were not.

For an AI: how to use and update this catalogue
1. What this is
This file is the companion catalogue of the Omni method (the owner's AI work method): one self-contained, read-only HTML file indexing broad AI use cases and listing GitHub resources that may help in an Omni run or a domain task, plus a few the owner finds interesting. It is a cold reference. Nothing here is qualified, installed or adopted, and a listing is not a recommendation to install. The data is in the JSON block with id
catalogueData
in a script element just before the page script, near the end of the file, on a single long line; this page only displays it. The approved catalogue release filename pattern is
TECH-AINT-Omni-Resource-Catalogue-v
2.0.1
.html
. Its version is the number in the release filename, the page title, the
catalogue-version
meta tag and the data field
catalogue_version
. The older Markdown catalogue (v1.2.5) is superseded by this file.
2. Use it in 30 seconds
Start from the requested outcome and the capabilities the host already provides and permits. Load zero entries by default.
Search the live field first (Omni section 17). This list only suggests where to look: it never limits or outranks the search (except a qualification record whose recheck trigger has not fired, Omni section 17), is never required, and if the live field disagrees, the live field wins and the entry is stale (say so in the task record; edit the data block only when the update rules are triggered).
Choose the relevant major AI-use-case family (or multiple families) first, with its five lifecycle checkpoints and known gaps. Then, only if a concrete capability gap survives, inspect the smallest relevant A or B category and both retained and archived leads. The use-case tags are tentative metadata matches and do not establish qualification.
Keep A3, A4, A7, A8, all of B and C cold for ordinary tasks, and open them at once when the task needs them.
Compare only materially different alternatives, qualify before adoption (README, licence, maintenance, permissions, egress, hooks, telemetry, token cost, rollback), and record the observed net benefit.
Omni test: a resource serves Omni only if it helps discover current practice, save context, remember, orchestrate, check or test, or write polished output, and it is actually present, installed and permitted in that run after a qualification check. Omni text does not create host capability. Star counts are deliberately absent: stars measure attention, not quality or safety.
Overlap archive:
The
302
currently archived records are accessible under Archive rather than deleted. Four same-family peer comparisons show historical six-criterion screening dominance; no current SPVN dominance is established without comparable real-task feasibility and lifecycle evidence. Reassess on changed constraints, a specific MPES need or new verified evidence. Do not treat archive status as a ban.
3. Operating policy
Task first, catalogue second.
Support every major AI-use-case family in the index (including zero-lead gaps), but claim operational coverage only after real-workflow testing and authorization. Establish the task, the required checks and the permitted capabilities first. Default to no new external repositories. A cold category is not a banned one.
Smallest useful surface.
Avoid blanket scans, overlapping skill packs, competing agent harnesses and routers without routing pressure. Add a tool only if the task-specific gain outweighs setup, review, permission, egress, telemetry, token, maintenance and rollback cost. Never reduce essential security, quality, accessibility or recovery checks just to cut tool count. A skills bundle, an examples repository, a reference index and an experimental runner are different kinds of resource.
Remove with evidence.
Exclude verified duplicates, superseded, archived or unavailable entries, and entries with unsubstantiated provenance. Do not remove only for popularity, inactivity inferred without evidence, or category size. The Pareto selection below is the method for shortening the list; it is a recorded judgement, not a quota.
Qualify on material use.
GitHub Trending, Explore and independently identified repository indexes supply leads, not reliability or safety. Do not use YouTube playlists or video series for discovery or refresh. Before a specific adoption, check canonical identity, the primary README and function, licence, maintenance and archival state, permissions, hooks, egress and telemetry, supply-chain exposure, compatibility, resource burden, host authorisation and a reversible recovery. For a trial, record: the task need, the existing baseline, the candidate and its evidence, the expected gain, the measured or observed result, adverse effects and the rollback. If the gain is not supported, leave the existing tool surface intact. OpenSSF Scorecard (scorecard.dev) can add risk indicators but cannot certify safety.
Refresh in proportion.
Refresh only triggered domains or sources, or a claim you rely on that can go stale. A catalogue-wide currency claim needs a catalogue-wide live check; a sample supports only the sample. Where a source is inaccessible, record "not checked".
3A. Hard-remove verified equivalents (new v1.5.0 rule)
Do not carry proven-equivalent lower-value repositories, including in the archive; a lesser duplicate that is not proven equivalent is archived under the lesser-duplicate gate with a re-entry trigger, never hard-removed.
Before admission and during a triggered review of existing records, compare the candidate with current native/authorized capabilities and the nearest functionally substitutable repositories. Only call them equivalent for a specified task when both deliver the same required outcomes, environment/engine coverage, integration, validation, permissions, licence, safety and recovery with no material advantage unique to the lesser one. Use canonical current READMEs, release/licence/security notes and a task-matched test where feasible. Ranking, stars, descriptions, or category overlap alone never establish equivalence.
When the stronger equivalent demonstrably meets the task at no greater justified lifecycle burden,
hard-remove
the lesser identity from retained and archived candidates, identity exclusion lists if applicable, snapshots, overlap comparisons and search/display metadata; do not keep a searchable tombstone. Retain the prior record, replacement, evidence, measured comparison, qualification limits, and rollback path in an
off-catalogue removal receipt
. Never silently rewrite history; if a legacy log has an obsolete slug reference, place its original text in the off-catalogue receipt before redacting the active HTML. If equivalence cannot be proved, do not delete on inference alone; retain as a cold alternative pending a relevant recheck.
3B. Discover missing domain specialists on every triggered refresh
Enumerate all 14 AI-use-case families, compare their uncovered lifecycle checkpoints and unserved needs against current native tools, then search live GitHub Trending, Explore, canonical repo/topic queries and independent indexes for
specific missing capabilities
. For game development, search for agentic game studios, Claude Code game agents, Godot/Unity/Unreal integration, QA/playtesting, build/release orchestration and deterministic simulation, not merely engine-name matches. Validate the actual repo slug, README, licence, maintenance, permission hooks, egress and recovery. Compare nearest peers and register genuinely distinct useful leads even when historical category scores are weak. Keep a dated admission/decline decision off-target and update this index when evidence changes; no automatic install or standing broad sweep is authorized by this offline file.
4. Categories (classify by primary function, not by name or deployment)
A1 Discover at runtime: search, docs, retrieval, ingestion.
A2 Save tokens and context: compaction, trimming, planning files, context tracking.
A3 Remember across sessions: persistent agent memory.
A4 Agent runtimes and orchestration: coding and GUI agents, harnesses, worktrees, parallel runtimes.
A5 Check, test and prove: code review, security testing, real-use and browser testing, gates.
A6 Write polished output: design, diagrams, output style and anti-slop, design tools.
A7 General skills and workflow packs: installable skills, plugins, marketplaces, method packs that are not single-domain.
A8 Route models and track usage: routing, proxies, usage, cost and limit monitoring.
B1 Web and app building: web and app frameworks, UI kits, templates, runtimes. B2 Mobile and platform: mobile, desktop-platform and embedded-platform tools, emulators. B3 Finance, data, SEO and marketing: tools and models. B4 Media: video, audio, voice and image production, editing and frameworks. B5 Research, learning and knowledge: courses, references, research tools and knowledge bases that are not runtime retrieval tools. B6 Self-hosted products and productivity: standalone self-hosted or local end-user products and utilities. B7 Security, reverse engineering and infrastructure: security tools, containers, networks, platforms, and inference and serving frameworks. B8 Workspace and service integrations: bridges and CLIs for named external services (mail, docs, chat, cloud, automation). B9 Game development and interactive simulation: multi-agent game studios, engine integrations, QA and production workflows.
C Interesting, not Omni runtime: end-user products, games, fun and niche tools that do not make a general Omni run better. Keep separate.
Bookmark categories (BK-...) and OWN hold the owner's bookmarks and own projects that fit no section above.
Tie-breaks: a single-domain skill goes to its domain, not A7; a self-hosted agent platform goes to A4, not B6; an inference or serving framework goes to B7, not B6; a retrieval tool goes to A1, not B5; an output-style skill goes to A6, not A2. If two categories are defensible, keep the current one and note the contest. Contested placements of the retired Markdown version are not recorded one by one: treat the current placement as the precedent. An earlier placement precedent in a record's
catalogue_note
or in the
change_log
overrides a first guess. When you add or move a record, also check the kept records of its category against it under rule 2 and move any that it now dominates to
removed
(protected
kept_by
values excepted). On a move, append "moved from X: reason" (ASCII) to the record's
catalogue_note
(
note
for a left-out record, and re-check its peer reason and the floor), name the move in the
change_log
detail and re-check the category floor for the category left emptier, re-apply rule 2 to the moved record in its new category, and re-check every left-out record whose reason names it as the peer. Section B categories are domain capsules, which are lists of leads and not Omni capsules (rules); before building something, search first (Omni).
5. How to update (edit the JSON block, keep these rules, then check the page)
Work on a copy (do this first).
All steps below act on a copy of the file kept outside
sources/method
. Validate the copy, show the owner the new
change_log
detail and the affected records, and replace the live file only after validation and assurance pass and the owner agrees; the order is: finish and assure the copy, show the owner, and only after the owner agrees rename, delete the previous file, put the new file in place in
sources/method
and then run
builder/build.py
and update the documents that cite its name. If validation fails, nothing changes.
Trigger.
Update on a real trigger: a requested coverage refresh, a task-specific gap, a new domain, a verified change in an approved discovery source (record the source, observation date, evidence and any unavailable checks in the
change_log
; a check with no data change is a PATCH entry), or evidence of a repository move, archival, deprecation or security issue. Do not expect or force additions. New leads from Trending, Explore or independent repository indexes are only leads. YouTube playlists and video roundups are not discovery sources.
Admit with evidence.
For each proposed addition, verify the current canonical GitHub identity and independently corroborate where it was found; check the primary function, not just a matching name. A redirect to another slug is the same repository: keep the new slug and put the old one in
previous_slugs
when the repository is kept; the old slug of a repository that is not kept goes to
excluded_identities
instead. A snippet, a name-only mention, a guessed video-to-repository match or an unattributed lead is excluded, not parked.
Score it.
Give the candidate the six scores (below) from its description and note, using two independent raters if you can, apply the selection rule, then record
pareto
(fit, distinct, clarity, breadth, safety, appeal, score, votes) if it is kept, or
scores
if it is left out. If it does not clear the rule, add it to
removed
with the reason, not to
repositories
.
Record provenance.
Give each record you add one
evidence
entry (kind, url, observed_at), or write "date not recorded" in its
catalogue_note
; the checker does not enforce this. The data block is one line of UTF-8 JSON: change it by parsing and re-serialising, and never put a literal closing script tag in any text (escape the less-than, greater-than and ampersand characters as the JSON escapes backslash u003c, backslash u003e and backslash u0026 when you serialise).
AI use-case and Omni-function tags.
Preserve use_cases independently from omni.roles. Every scored record has an omni object: roles (zero or more canonical OM ids), relation (omni-runtime-lead, domain-lead or not-established), how (record-level potential contribution), and basis (stored-description-and-category, historical-category-only, historical-note-only or insufficient-for-omni-link). New and moved records require these fields updated from the actual evidence. Zero roles is valid and does not establish irrelevance. Never infer current host access, safe adoption, role success or installation from a tag. A task-specific trial must independently qualify functionality and permissions. Refresh roles if the recorded source changes; record version/revision details. The global omni_functions and omni_tagging_provenance document the controlled vocabulary and evidence limits.
Record fields.
The schema is version 2 (the
schema_version
field). Top-level fields:
schema_version
,
catalogue_version
,
title
,
revision
,
updated_at
,
inventory_manifest
(scored, retained, archived, excluded, use_case_families, omni_functions; update whenever the collections change),
categories
(code to {name, collection}; collection is A, B, C, F for bookmark categories or G for your own projects),
repositories
,
removed
,
excluded_identities
(slug, reason),
anticipated_needs
(a list of {area, need, search_seeds, category_hint}; category_hint is a category code, or "new" when no category fits yet),
unserved_needs
(a list of plain strings),
overlap_reviews
(exactly 4),
use_case_families
,
omni_functions
,
use_case_index_provenance
,
omni_tagging_provenance
and
change_log
. To create a category, add it to
categories
with a new code and one of the collection letters above. Allowed
description_source
values: readme-excerpt, readme-summary, catalogue-note, bookmark-note, editor-note, github-api, manual, category-only, dedupe-audit-2026-11-04. Allowed
evidence.kind
and
sources
values: catalogue, bookmarks, github, trending, explore, roundup, manual. The roundup value is retained only to interpret historical records; do not add it as a discovery source. A repository found by a live search (a code-host topic search, a registry, an official marketplace) gets
sources
["manual"] and one evidence entry of kind manual whose url is the search or listing page and whose observed_at is the date.
pareto.kept_by
is robust (passed the vote rule), floor (category floor), own (your own project), used (a development note names it), dev (added for a development need) or need (added for a need found in the owner's notes); for used, dev and need the record also has a top-level
used_by
list of {doc, how} (not inside
pareto
);
pareto.why
is a plain phrase (about 12 words for new records; some earlier records are longer). Required in a kept record: slug, category, sources, description, description_source, pareto, github_check, use_cases and omni (every scored record, kept or removed, needs use_cases and omni); the rest is optional. A removed record uses the same sources values. A kept record has:
slug
(owner/repo, exact case),
category
,
sources
(catalogue, bookmarks, github, trending, explore, roundup, manual),
description
(one plain sentence, at most 25 words copied from a source, otherwise a paraphrase) with
description_source
,
pareto
,
github_check
, optional
catalogue_note
(provenance, quoted as found),
account_note
,
saved_url
,
previous_slugs
,
evidence
(a list of {kind, url, observed_at}; never invent a date: if it is unknown, omit the evidence entry and write "date not recorded" in
catalogue_note
; an object instead of a list breaks the page) and
readme_checked_at
. One record per repository, case-insensitive. Keep third-party text paraphrased unless it is a short attributed quote.
Removal and exclusion.
A repository that GitHub answers with 404 is "unavailable to this check", not "deleted", and no continuity with another repository is claimed. A repository that is archived, deprecated, unavailable, the same as another entry, or a lead with unsubstantiated discovery provenance (no score needed) goes to
excluded_identities
with the reason; a repository that only scored low remains in
removed
if not verified redundant; a proven inferior functional equivalent is hard-removed from all candidate collections with an off-catalogue removal receipt under rule 3A. Never delete silently: an unqualified low-scored entry moves to
removed
with
slug
,
category
,
sources
,
note
,
score
,
scores
and
reason
. When a kept or left-out record is removed, excluded or renamed, re-check every left-out record whose reason names it as the peer (rewrite a renamed slug in those reasons). Re-admit a removed or excluded entry only on new, independently supported evidence, and in the same edit delete its old record from
removed
or
excluded_identities
and name the re-admission in the
change_log
detail.
Prose that must follow the data.
Current counts in the introduction, status options, summaries, stat tiles and footer are filled from the data by the script. On a legitimate corpus or taxonomy change, update
inventory_manifest
in the same revision and validate the rendered counts; keep dated historical-selection statements unchanged. The footer, the notice "About this catalogue", the GitHub-check sentence in the how-chosen note and the closing summary of section 6 describe the 1.3.0 round, are historical and stay unchanged; each card shows its own check date. Edit the guide text only when a rule changes.
Log and version (edits before Check; file moves after Assurance).
Make the
change_log
entry,
revision
,
updated_at
,
catalogue_version
, meta tag and title edits in the copy before Check. Do the renaming, archiving, hashing and document updates only after the live check, the validation and the assurance passes; if any later edit changes the bytes, redo the hash and any recorded pins and re-run Check and Assurance. Re-check the other records'
github_check
only on a trigger, and claim catalogue-wide currency only after checking all of them. Append one
change_log
entry (revision = last revision + 1, date, action, detail; the detail names every add, move and removal, and a contested category is noted in the record's
catalogue_note
), set
revision
and
updated_at
to match. Never rewrite earlier entries. A change of selection (adds, removals, moves) is a MINOR version bump; wording or data corrections are a PATCH. A bump changes the version in the static text and data: the
<title>
, the
catalogue-version
meta tag and
catalogue_version
(the masthead, the guide file name and the version sentences are filled from the data by the script; the copy may keep any name outside
sources/method
). After Check and Assurance, and once the owner agrees, do the file moves in this order: (a) compute the size in bytes and the sha256 of the final bytes; (b) delete the previous file from
sources/method
(git history keeps it; never leave two versions there); (c) rename the copy to
TECH-AINT-Omni-Resource-Catalogue-vX.Y.Z.html
and put it in
sources/method
; (d) update every document that cites the name, size, hash or counts (search the repository for the old file name and update every hit, including
docs/FRAMEWORK.md
), then run
builder/build.py
. The method is the core
TECH-AINT-Omni-v*.md
(highest-numbered) plus the four
TECH-AINT-Omni-XPRT-*.md
expert files, which the core's router loads on demand, all in
sources/method
.
Live check.
For each repository you add or whose slug you change, record
github_check
(checked_at, archived, license as an SPDX id, or "not stated" (also use it when GitHub returns null or NOASSERTION), pushed_at as YYYY-MM-DD) from the GitHub API (for example
gh api repos/OWNER/REPO
). A rename means: update the slug and
previous_slugs
. A 404, an archived or a disabled repository goes to
excluded_identities
(see Removal and exclusion).
Check.
Open the page in a browser (a headless browser works too: confirm that no red "Catalogue data problem" banner is shown and that the element with id
loadError
is hidden; the validator is private to the page script). The checks are: schema version 2, catalogue_version equal to the meta tag, every kept record has a known category, valid sources, a description, six pareto scores from 1 to 5 plus score, votes, kept_by and why (robust entries need 3 or more votes), a github_check, and unique slugs across kept, previous, removed and excluded identities; the change log runs 1 to revision in order; evidence needs a string kind, url and observed_at, and used, dev and need entries need used_by. The banner does not check optional text (for example
note
beyond its type), so check that by hand. A red "Catalogue data problem" banner means the data failed its checks (unknown category, duplicate repository, bad scores, change log out of order). Fix it before delivering. Confirm the counts in the header and
inventory_manifest
match the data, including any authorized addition, move or exclusion. Historical source checks and observations must not postdate the catalogue update date, and push dates must not postdate their recorded observation or check. Live GitHub timestamps must not materially postdate the check.
Assurance.
Before claiming the file is converged, freeze the copy (sha256, bytes) and run fresh coverage, adversarial and executed passes on the same bytes; all must find nothing material, otherwise fix, refreeze and rerun. State the scope: metadata identity and internal consistency are not source completeness, maintenance, code security, licence qualification or permission to install.
6. The selection rule (Pareto Via Negativa, reproducible)
Scores run 1 to 5 per criterion, averaged over two raters. The overall
score
is the Balanced profile's weighted mean of the six criteria, rounded to two decimals for display only. Rank on the unrounded weighted mean; a score that ends in exactly .005 may be stored rounded either way. The four option profiles weigh the criteria like this:
Option
fit
distinct
clarity
breadth
safety
appeal
Omni first
.35
.20
.15
.15
.10
.05
Balanced
.25
.15
.15
.15
.15
.15
Billboard
.20
.10
.20
.10
.05
.35
Low risk
.20
.15
.20
.10
.30
.05
Leave out an entry whose clarity is below 2 (the description does not verify what it is).
Leave out an entry that a same-category peer matches or beats on all six criteria and beats on at least one, unless it is in the top quarter under all four profiles.
Rank all candidates under each profile (the pool is every stored candidate, kept and left out, plus any new one, and a peer is any other record of the same category in the pool, kept or left out;
excluded_identities
are not in the pool). The top 25 percent is the top quarter of the pool by count, rounded down (103 for a pool of 412, the size in version 1.3.0); a tie at the cut counts as inside. Compare exactly, not with floating point: work in integers (each score times each weight in percent) or use Decimal, because a float cut can fall one step off and drop a tied entry. Count the profiles in which an entry is inside (the
votes
field); keep it if votes is 3 or more. When you add a new candidate, rank it against the stored pool and do not recompute the other records; recompute all of them only in a full selection round.
Floor: if one of the categories A1 to A8, B1 to B8 or C would be empty, keep its best entry by the Balanced profile when its clarity is at least 3 (
kept_by
floor). The floor does not apply to bookmark categories (BK-...) or OWN.
The owner's own projects stay unless they are plumbing or unverified (profile readmes, site config).
Stated needs: a candidate that serves a need in section 7 may be kept as
kept_by
need, one at a time, with the need written in
used_by
, and the need then moves out of
unserved_needs
(or its search seeds are updated in
anticipated_needs
); keep the count small, because anything can be added at the next update.
Development use protects an entry (kept_by used, dev and need override rules 1 and 2 and the vote rule): a repository that one of the owner's development notes names as a chosen or relied-on tool (a bare product name in a list of options or a comparison does not count) (for example the framework, the knowledge distiller or the prompt clipboard) stays whatever its rank (
kept_by
used, with
used_by
naming the note), and an entry may be added for a development need those notes describe (
kept_by
dev). Before an update leaves out or moves any entry, search those notes (the documents in
sources/method
and any other note the owner names; a
used_by.doc
label such as "Needs scan" records a scan, not a note) for its slug or name; a named entry stays until the note changes.
The version 1.3.0 selection round applied this rule to 412 candidates and kept 115 (later updates add or move single records and are listed in the change history). The six raw scores of every candidate are stored (in
pareto
for kept entries, in
scores
for left-out entries), so the selection can be recomputed;
votes
is stored only for kept entries.
7. What the owner will want next (for the next update)
A read of the owner's notes on 2026-11-01 (development notes, plans, learning, home, devices, apps) found the capability needs below. Listed repositories serve some of them today; the unserved needs are where an updater should search next, using the seeds, then admit and score candidates by the rules above. The list holds themes only, no personal data.
Not yet served by any candidate:
8. Standing prohibitions and character rule
GitHub star and fork counts may be displayed as dated, source-attributed observations for browsing, but must never change the historical selection vote or substitute for SPVN qualification. Do not add popularity-based rankings, install instructions, pending or unresolved name lists, mandatory preloads, tool quotas or standing scheduled sweeps. Keep one active catalogue file; excluded-lead manifests, rater sheets and assurance receipts live outside it. Text you write in this file (interface text, guide, descriptions you paraphrase) uses plain ASCII punctuation: no em or en dashes, arrows, smart quotes, ellipsis character or emoji (Omni section 4.9). Quoted third-party text, catalogue notes and bookmark titles keep their original characters.
9. Sources and history
Current discovery sources:
canonical GitHub repositories and their READMEs/API, GitHub Trending, GitHub Explore, official project documentation, independently verified repository indexes, and owner-provided bookmarks or project notes where accessible. Check primary sources before admission.
Excluded:
YouTube playlists and video roundups; do not search, poll, or cite them as fresh discovery evidence.
Historical provenance:
earlier catalogue rounds (2026-10-24 through 2026-11-01) used owner screenshots, bookmarks, GitHub account listings and third-party media references. Existing record notes, source tags, and previous change-log details are retained verbatim as historical audit evidence, including legacy playlist references. Such attributions are not standalone evidence of GitHub identity or quality and are not active sources. The retired Markdown appendices cannot be verified from this HTML. Re-admission of previously excluded entries needs new, independently supported primary evidence. GitHub checks are dated observations, never safety or maintenance certification.
Recent history (newest first):
10. Update protocol for future AI agents (v2.0.1, machine-readable in data.update_protocol)
The JSON block is the single source of truth; the rendered page is derived from it. Never edit rendered text without the matching data change, and never change data without re-running the validation checklist. Main flow is listings plus filters plus the shortlist tray only; detail that must be preserved goes in collapsed details after the tray, never as a new section that repeats tag information. Tags on every card and the toolbox filters carry use-case and Omni information.
Duplicate gate, before adding anything:
check slug uniqueness, then purpose duplication (same category plus overlapping use-cases plus purpose keywords) against retained records, archived records, and duplicate_clusters. A duplicate of a retained winner goes to archive with reason 'lesser duplicate of <winner slug>', unless its evidence now beats the winner. Record every new record's cluster decision in change_log.
Recheck rule:
archive is not a ban. On new evidence (releases, independent verification, fixed breakage), re-check an archived loser against the winner on maintenance, clarity, breadth, safety, and evidence. If it now beats the winner, promote it and archive the former winner, and update duplicate_clusters with date and evidence. If not, it stays archived and the recheck is still recorded.
Evidence standard:
a repo's own marketing is not evidence. Corroborate with code, commits, releases, tests/CI, issues, and an independent reputable source where available. Record source and date for every material claim. A false claim gets the exact claim plus counter-evidence; a clearly false, dead, or valueless record is archived, or removed from the catalogue (recorded in change_log, never silent, never from GitHub). Borderline stays retained.
Token efficiency:
retained descriptions at most 15 words, evidence-based, no superlatives, no claim words without evidence, no repeating the category or use-case name when the tag already carries it. Change_log entries stay short and evidence-focused.
Validate before assurance:
open the file in a browser, run node --check on its inline scripts, and fix every failure. JSON parses, counts agree with data lengths, no duplicate slugs, all required fields present, all use-case and Omni ids valid, every script-referenced id (especially currentStatusNotice) exists exactly once, both scripts pass node --check, no external loads, contrast 4.5:1 or better in all three themes, OLED paper exactly #000000, and no shfqrkhn/ record re-added without an explicit owner instruction.
Version and assure:
bump version, revision, and date on every change, add a change_log entry with evidence, refreeze on a new key, and run 3 fresh same-key ConvergeWork passes (coverage, adversarial, execution). Fix any material defect, refreeze, and restart the chain. Assurance is SINGLE_AGENT_ASSURED on that key only, never independent certification or functional qualification. Promotion to live is a separate owner action.
Standing rules:
never install, qualify, or adopt a listed repo on the basis of this catalogue; never delete from GitHub; never invent a URL, star count, date, licence, or capability; if a source is unavailable, say so.
11. Omni compliance, especially SPVN (Pareto Via Negativa, Omni §6.3)
Follow all Omni principles, not just the ones in section 10 above. For any material choice, select the smallest sufficient feasible option with the greatest justified robust whole-system value over its lifecycle, at proportionate depth, modelling only distinctions capable of changing the decision. SPVN evaluates choices; it creates no authority to act.
Frame, then subtract, then rank.
Separate binding constraints from preferences; an option violating a binding constraint is infeasible, and no score or popularity compensates. Remove unsupported extras without discarding safeguards or distinct capability. A candidate is dominated only when another feasible, comparably measured candidate is at least as good on every relevant objective and strictly better on one, at confidence adequate to the decision. Keep non-dominated trade-offs.
Absent evidence is not inferiority.
Unknown feasibility is unqualified, not failure. Never archive or demote a record solely because its maintenance, star, or issue data could not be retrieved, or solely because its title or category resembles a peer. If an apparent duplicate differs in risk, timing, reversibility, or combination value, preserve that difference.
Archive is not a state.
Archive is a reversible attention aid, not a feasibility or dominance state. Every archive must carry its grounds, uncertainties, and a re-entry trigger (the evidence that would reverse the winner, per SPVN step 5), and must be reversible under the recheck rule.
Stars do not measure fitness.
Stars and forks can locate candidates but do not measure lifecycle fitness, causal value, safety, or SPVN preference. If a star count is ever displayed, mark its observation date and never convert it into a weight or a qualification.
Claim status, distinctly.
Screened is a signal only; qualified is proven on the real device, task, and environment; tested, untested, assumed, and inferred are labelled as such, never as facts. A high composite score is never itself qualification or permission.
Other invariants that bind every update:
smallest complete reliable result and total burden minimisation (§1); irreducibility and DRY (§1.6); authority from the owner's grant and polished-only delivery (§3); truth and source fidelity (§4); runtime discovery - live current practice wins over this cold catalogue (§4.7, §17); privacy, security, and least privilege - no external loads, no telemetry (§5); honest check status - NOT_RUN and BLOCKED are not passes, a null is not a value (§7); convergence and single-agent assurance only (§8); anti-slop and first-time-user standards (§10); handover sufficient for a future agent alone (§11); versioned self-update with a recorded deletion disposition (§16, §16.4).
Merit rule (owner correction 2026-11-04):
do not archive or delete a record unless merited on evidence. Default is keep. Archive needs proven SPVN dominance, lifecycle failure with positive evidence, a false claim with exact claim and counter-evidence, or a binding-constraint violation. Deletion from the catalogue needs no distinct value at all with positive evidence, recorded in change_log, catalogue-only, reversible only by fresh research. Popularity, absent evidence, title resemblance, a low score alone, and any wholesale 'delete all archived' rule are not merit. Reduce cognitive load by presentation - retained tools only in the main flow, archive collapsed below, plain language first - not by unmerited deletion.
12. Update harness (self-contained: this file is the only file to keep)
Single-file rule (owner instruction 2026-11-04):
build everything into this one HTML file. The full gate and merit rules live in the catalogue data itself (update_protocol), the clusters live in duplicate_clusters, and every update run is summarised in change_log. External scripts are scratch and are not required. A future update needs only this file plus the reputable sources below. Do not split the catalogue, and do not leave a rule, record, or gate report only outside this file.
Reputable sources, in order:
GitHub Trending and GitHub Explore/search, with the repo page, commits, releases, tests/CI, and open issues actually read; Hacker News, Lobsters, Changelog News, and Console as discovery only; official documentation, peer-reviewed or reputable technical press, and independent reviews as corroboration; existing awesome lists and the use-case seeds as discovery only. Not evidence on their own: the repo's own README or marketing, a star/fork/download count, a social-media post, or an AI-generated summary of the repo.
Entry bar - every check must pass before a candidate is retained:
(1) working code, demonstrably usable from code and docs, not only claimed; (2) licence stated and compatible, permissions and egress disclosed, no undisclosed telemetry or hooks; (3) not GitHub-archived, last push within 12 months (a stale repo fails for a new entry; a gap does not waive this; an earlier retained record is rechecked on a trigger); (4) clarity: a cold reader can tell what it does and how to use it; (5) evidence beyond the repo itself, at least one independent source or code/test/CI evidence, with source and date recorded - a claim without a source is a hypothesis, labelled as such; (6) distinctness in one sentence: what it does that the cluster winner does not - no distinct sentence means duplicate; (7) description at most 15 words, evidence-based, no superlatives or claim words without evidence in the record.
Lesser-duplicate gate:
before retaining, compare the candidate against every retained record in the same category with overlapping use_cases and purpose keywords, and against duplicate_clusters. If a retained winner exists and the candidate does not beat it on maintenance, clarity, breadth, safety, evidence, and distinctness together, with comparably measured evidence, the candidate is a lesser duplicate: archive it with reason 'lesser duplicate of <winner slug>' or reject it outright if it has no distinct value at all. It is never retained alongside the winner. If it does beat the winner, promote it and archive the former winner, updating the cluster with date, evidence, and reason. If there is no winner, the candidate still needs its distinct sentence and either a cluster entry or an explicit 'no duplicate found' note in the change_log.
Merit rule:
do not archive or delete a record unless merited on evidence. Default is keep. Archive needs proven SPVN dominance, lifecycle failure with positive evidence, a false claim with exact claim and counter-evidence, or a binding-constraint violation. Deletion from the catalogue needs no distinct value at all with positive evidence, recorded in change_log, catalogue-only, reversible only by fresh research. Popularity, absent evidence (null data, failed lookup, rate limit), title/category resemblance alone, a low score alone, and any wholesale 'delete all archived' rule are not merit. Wholesale deletion is prohibited.
Candidate record for gating (JSON, one per candidate):
slug, category, description (1-15 words), use_cases (UC ids), omni_roles (OM ids, or empty if unsure - never guessed), license (a real licence; 'unknown', 'unverified', 'none', or empty fails the gate), pushed_at (YYYY-MM-DD; use the GitHub search updated_at date and say so if REST pushed_at was not fetched), github_archived (true/false), evidence (list of source, date, what - at least one independent source), distinct_sentence, cluster_winner (retained slug or null), beats_winner (true/false), beats_evidence (required if beats_winner is true), proposed (retain).
Gate algorithm, in order:
(1) slug must not already be in repositories, removed, or excluded_identities, and must not be shfqrkhn/ without an explicit owner instruction; (2) use_cases and omni_roles must be valid ids; (3) description 1-15 words, no superlative/claim word; (4) licence must be known, repo must not be GitHub-archived, pushed_at must be known and within 12 months; (5) evidence must exist, include something beyond the repo page, and carry a date; (6) if cluster_winner is set, it must be retained, and beats_winner with beats_evidence is required - otherwise the candidate is a lesser duplicate and is rejected or archived, never retained; (7) if cluster_winner is null, distinct_sentence is required. A candidate proposed for retention that fails any step is rejected (no record) or, only where archiving is merited, archived with a merit reason. The gate report (screened, retained, archived, rejected, with reasons) goes into that revision's change_log entry, inside this file.
Merging a retained record (fields the page script itself validates - if any is wrong, the page throws and the lists do not render):
slug matching owner/repo; category must be an existing category key; sources must each be one of catalogue, bookmarks, github, trending, explore, roundup, manual; description plus description_source, where description_source must be one of readme-excerpt, readme-summary, catalogue-note, bookmark-note, editor-note, github-api, manual, category-only, dedupe-audit-2026-11-04; catalogue_note as a string; readme_checked_at within the catalogue date; pareto with fit, distinct, clarity, breadth, safety, appeal each 1-5 and score equal to (fit*25 + distinct*15 + clarity*15 + breadth*15 + safety*15 + appeal*15) / 100 within 0.011, votes an integer 0-4, kept_by one of robust, floor, own, used, dev, need (robust requires votes of at least 3; used, dev, and need require a used_by entry with doc and how), why a non-empty string; github_check with checked_at within the catalogue date, archived true/false,
license
a non-empty string, pushed_at either 'not stated' or a date on or before checked_at; use_cases valid UC ids; omni with roles (valid OM ids, unique), relation one of omni-runtime-lead, domain-lead, not-established, how a non-empty string, basis one of the stored values - and roles empty exactly when relation is not-established. Then update the static counts, inventory_manifest (retained, archived, scored, excluded), duplicate_clusters, and change_log, bump revision and updated_at, and keep change_log length equal to revision with the last entry dated updated_at and entries in chronological order.
Validating without external scripts:
open this file in a browser - the page script validates every record and throws on the first invalid one, so a rendered list is itself a validation pass. Then check: retained plus archived equals scored; excluded count agrees; every script-referenced id exists exactly once; no cluster winner is archived; OLED paper is exactly #000000; ink, muted, and accent text meet 4.5:1 on paper, raised, warm, and selected surfaces in every theme; no external loads (no link element, image element, import, or CSS address function in the body); no shfqrkhn/ record without an explicit owner instruction. Then run 3 fresh same-key ConvergeWork passes (coverage, adversarial, execution); fix any material defect, refreeze on a new key, and restart. Deliver SINGLE_AGENT_ASSURED on the final key only - never independent, external, or human certification, and never a functional qualification, installation, or adoption. Promotion to live is a separate owner action; do not promote without an explicit owner instruction. Do not install, qualify, or adopt any listed repository on the basis of this catalogue.