fix: keep stars listed through a binding out of later scans

The scanner recognizes a star only when README links that exact repo, so a starred engine listed through its Python binding (llama.cpp as llama-cpp-python) came back as a new candidate every scan. The Record step now writes a ledger row for such stars. Also drops the last 'drop' verdict wording from preview-verdicts.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Vinta Chen
2026-10-16 17:42:06 +08:00
co-authored by Claude
parent e2ead5fc84
commit 9516fb7af5
2 changed files with 2 additions and 2 deletions
+1 -1
View File
@@ -18,7 +18,7 @@ Maintainer review happens through an interactive HTML page: one row per entry wi
- Proposed new entry: `add` or `reject` (not added, logged under "Rejected Additions").
- Structure question: `restructure` (take the change the reason or group note describes), `park` (no record, so it resurfaces), or `reject` (logged under "Rejected Additions"); seed it `restructure` or `park`.
- Show a replacement as two rows: the old entry `remove`, the new entry `add`.
- `reason` is plain language the maintainer reads cold — no invented shorthand. When fresh evidence contradicts the seeded verdict (a big download count on a drop, a dead repo on a keep), say so in that row's reason instead of silently changing the seed.
- `reason` is plain language the maintainer reads cold — no invented shorthand. When fresh evidence contradicts the seeded verdict (a big download count on a remove or reject, a dead repo on a keep), say so in that row's reason instead of silently changing the seed.
2. Copy `template.html` (sibling of this file) and replace the placeholders: `__TITLE__` (page title), `__SUB__` (sub-header: scope, seed provenance, fetch date, and the standing instruction to flip/comment then Copy feedback), `__KEY__` (localStorage key), `__DATA__` (the array). `__KEY__` must be unique per review — slug plus date, e.g. `awesome-python-science-2026-09-01` — because saved state under a reused key bleeds a previous review's flips into rows with the same section and entry name.
3. Write the page to `local/awesome-python-<slug>-preview.html` in the repo root (git-ignored; create the directory if needed), `open` it, and tell the maintainer the path and the return path: flip or comment rows (they highlight yellow), press **Copy feedback**, paste the JSON into the chat. Done when the page is open and the return path is stated.
+1 -1
View File
@@ -29,7 +29,7 @@ Run `preview-verdicts` over all groups: survivors as `add` or `reject` rows, dis
## 5. Record
- **Added**: follow `audit-the-list` step 5 for the README change, one commit per entry.
- **Added**: follow `audit-the-list` step 5 for the README change, one commit per entry. When the entry links a different repo than the star (a Python binding or client of a starred engine), also append a ledger row `already listed as <entry> (<owner/repo>)` for the star, since the script only recognizes a star whose own repo is linked.
- **Rejected**: a candidate that reached review and was not added gets one line under "Rejected Additions": `- owner/repo -- yyyy-mm-dd, <downloads>/month (<source>): <reason>.`, replacing its earlier line.
- **Parked**: a row the maintainer parks gets no record, so it resurfaces next run.