[bong-water-water-bong]

Root cause

tools/pin_watch.py --check iterates over pins. A repo that was never pinned is therefore watched by nobody — including a repo we publish ourselves. That is why the 2026-11-05 template audit had to be done by hand (~/tmplsec/AUDIT-1.md), and it means a model published tomorrow would sit in our orgs with no daily check of its bytes or its chat template, which is the whole subject of this lane.

Measured on the committed pins (19:3x AST), 167 repos in the two orgs, 92 not in models/pins.json:

of the 92	count	why it is not a pin
only .1bp packs (the 1BP lane's format)	89	not this table's business: no model artifact and no template this file knows how to read
private	2 (ZAYA1-8B-QLoRA, ZAYA1-8B-Q4NX)	models/pins.json is public, and docs/model-pins.md says a private model is tracked in the lane that owns it
public, ships a template, unpinned	1 — bong-water-water-bong/ZR1-1.5B-Strix	a real gap: three chat_template.jinja (root + two checkpoints), measured b6835114…

The change

• --check --orgs A,B: one listing per org (full=true carries the siblings, so this is 2 API calls, not 167), reporting every unpinned repo that ships a .gguf / .q4nx / chat_template.jinja / tokenizer_config.json under Published, not pinned — counted in the report's first line and annotated on the run, since such a repo changes no pin and would otherwise open no PR and fail nothing.
• --pin selects those files, not .gguf alone: a container or LoRA repo has no .gguf, so before this it could not be pinned at all.
• models/pins.json: that one repo pinned (64f092fe, 6 files). The three chat_template.jinja are b6835114b7303ddd…, the digest the audit measured and the ZR1 GGUF arms carry; the three tokenizer_config.json have no chat_template key (459 B each), so null is the recorded truth, not a failed read.
• The daily workflow passes --orgs 1bit-MONSTER,bong-water-water-bong, so the coverage maintains itself instead of decaying into another by-hand audit.

Verification

$ python3 tools/pin_watch.py --check --orgs 1bit-MONSTER,bong-water-water-bong
# before:  # Model pins: 1 of 147 moved, 1 published but not pinned (2026-11-05)
#          | `bong-water-water-bong/ZR1-1.5B-Strix` | `chat_template.jinja`, `checkpoint-100/…`, … |
# after:   # Model pins: 1 of 148 moved (2026-11-05)          <- the unpinned count is gone; the 1 moved is
#                                                               unsloth's re-quant, unchanged
$ python3 tools/pin_watch.py --check --pins models/pins.json --out /dev/null   # 148 pins, 192 files
$ python3 tools/pin_watch.py --self-test                                     # 45/45

--self-test gained the cases that would have made this silent: a published repo that ships a template is reported, an .1bp-only repo is not, a private repo stays out, an already-pinned repo is not reported twice, an org that cannot be listed is a note rather than a clean day, and --pin on a container repo pins the model plus both template files. tools/copyright.py --check rc 0.

Notes

• Overlaps pin-watch: the bump step's shell parses (it never did), and an unread upstream fails it instead of passing as a clean day #1181 (open, same file): pin-watch: the bump step's shell parses (it never did), and an unread upstream fails it instead of passing as a clean day #1181 fixes the bump step's shell, the --bump exit code, --json/--from and the 401 note; this PR adds the census. The workflow hunk is adjacent — the run annotation here covers not checked|not pinned, so when the two meet, pin-watch: the bump step's shell parses (it never did), and an unread upstream fails it instead of passing as a clean day #1181's not checked line should be dropped in favour of this one. I will rebase whichever lands second.
• Nothing adopted, nothing uploaded: the pin is a record of bytes we already publish.
• Private repos are deliberately out of the census output, which also means the two the daily token cannot read (401, see pin-watch: the bump step's shell parses (it never did), and an unread upstream fails it instead of passing as a clean day #1181) are not double-reported.

[bong-water-water-bong]

#1193 ready for review at e7d1a0e (2 commits: tool+workflow+docs, then the one pin it found).

It overlaps open #1181 in the same two files by design — #1181 makes the bump step work at all, this one makes the coverage complete. I will rebase whichever lands second; the only real decision between them is the workflow's run-annotation line, where this PR's not checked|not pinned subsumes #1181's not checked.

[bong-water-water-bong]

CI green at e7d1a0e8: build 6m35s, CodeQL pass, hw_gate skipped, pr_agent red only for coder-llm. python3 tools/pin_watch.py --self-test ran in that job: 45 ok, 0 FAIL.

[github-actions]

Preparing review...

[github-actions]

Preparing review...

[bong-water-water-bong]

VERDICT: READY at 43428e06.

Re-derived here:

• The tool's own gate, live, at this head: python3 tools/pin_watch.py --check --orgs 1bit-MONSTER,bong-water-water-bong prints exactly # Model pins: 1 of 148 moved (2026-11-05) — 148 pins (147 + the one this PR adds), 192 files — with no "published but not pinned" row, and exits 1 on the unsloth re-quant alone. That is the body's "after" line, reproduced.
• Every value in the new pin entry is the Hub's, fetched independently of the tool: the repo's main is 64f092fe4fddba1030d4ef1531d3e33dd09d584a; the tree at that commit gives the three chat_template.jinja at 2237 B / blob 02a1c3bce33f… and the three tokenizer_config.json at 459 B / blob 53aca4fc5079…; the downloaded templates hash to b6835114b7303ddd… (all three identical); the three tokenizer_config.json really have no chat_template key, so null is the recorded truth.
• The census, derived outside the tool (/models?author=…&full=true for both orgs, joined against models/pins.json at this head): 160 public repos across the two orgs, 86 not in the table, and none of those 86 ships a .gguf/.q4nx/chat_template.jinja/tokenizer_config.json — so over the real orgs the census reports nothing at this head. No false positive, which is the failure mode that would make a daily run permanently noisy.
• --self-test: 45 ok lines, 0 failures. tools/copyright.py --check rc 0.

Nits:

1. report() computes checked = total - len(notes), and notes now also carries census notes, so one unreadable org makes the first line say 147 of 148 checked, 1 not checked (measured with report([], ["our-org: could not be listed (429)"], 148, True, [])) when all 148 pins may have been read fine. Conservative direction, but the sentence is about the wrong set. The exit code is unaffected (notes and len(notes) == len(doc["pins"])).
2. The org listing is one call with limit=1000 and no pagination, so an org past 1000 repos would truncate silently and report a clean census. Today it is 69 + 91.
3. A "published, not pinned" row exits 1 but opens no PR and only annotates the run with ::warning::, so the nightly is green apart from the annotation — unlike census-watch, nothing files an issue. Fine if that is the design; it is the one case in this tool a person will miss.

[bong-water-water-bong]

Prep for the second landing: #1181 and #1193 conflict in .github/workflows/pin-watch.yml, and together they also break --json's own claim — so whichever lands second needs one extra commit, built and proven now rather than at merge time.

The conflicts (two hunks, one file). Rebased either way, git stops on the same file: the --check step (both PRs rewrite the same command line — the union is one command with --orgs and --json), and the run annotation (not checked|not pinned from #1193, wider than #1181's not checked). Resolution is mechanical; both landing orders produce the identical tree 86e36984.

The defect only the union has. #1193 is the census half; #1181 is the --json half carry the sweep; #1193 added --orgs, which finds repos by a different route. Applied together, a real run printing 1 of 148 moved, 1 published but not pinned wrote a JSON with keys date, pins, changes, notes — the census rows existed only in the Markdown, and --pr-body <unpinned> --from sweep.json answered "did not move". That is the same shape as the F1/#1157 mistakes: an artifact whose prose ("the sweep") is wider than its contents, consumed by the one step that opens PRs.

Branch i-tmplsec-union-1181-1193 at fefbbee7 = current main + #1193's 2 commits + these 4 + one commit:

• JSON gains published_not_pinned, so the artifact really is the sweep;
• both --pr-body paths refuse a census row in one wording — "is published but not pinned … needs --pin, not a bump PR" — instead of "did not move";
• --self-test 56 ok (51 at the union before the fix), with the cases that bite: both flags in one run, both halves in the JSON, the census refusal in those words, and a pin that did move still printing its body from the same file;
• tests/workflow_shell_test.py all checks pass; live on the real pins: 1 of 148 moved, published_not_pinned: [] (nothing new is published-and-unpinned tonight), cached body 0.045 s.

I am not touching either PR's head: both are READY at the reviewed SHA. If #1193 lands first I rebase this onto main and push the extra commit here; if #1193 lands first, it goes on #1181. Say the word if you would rather have the union fix as its own PR.

[bong-water-water-bong]

#1193 ready for review at 50371ee — rebased onto main after #1181 landed (965cb4bc), plus the one commit that only the two of them together need.

What the rebase did. #1181 landed first, so this branch is now main + these 3 commits:
5e2c2ac8 (the census), 9d5dbf87 (the pin it found), 50371ee7 (new). One conflict, in
.github/workflows/pin-watch.yml, resolved as the union of one command: --check --orgs … --out pin-report.md --json pin-report.json, with the wider not checked|not pinned annotation. The four files this PR touches are byte-identical to the union tree I built and tested before the merge (git diff fefbbee7 HEAD -- on those paths is empty), so nothing reviewed at 43428e06 changed underneath it, and main's squash of #1181 is content-identical to the four commits my union branch carried.

The new commit (50371ee7) exists only because both landed. #1181 made --json carry "the sweep"; this PR adds --orgs, which finds repos by a different route. Together, a real run printed 1 of 148 moved, 1 published but not pinned but wrote a JSON with keys date, pins, changes, notes — the census half lived only in the Markdown, and --pr-body <unpinned> --from sweep.json answered "did not move". That is the F1/#1157 shape: an artifact whose prose ("the sweep") is wider than its contents, in the file the PR-opening step reads — and with #1181's || true gone, the shape that opens an empty-bodied PR. Neither PR alone is dishonest, so review could not have seen it.

So the JSON gains published_not_pinned, and both --pr-body paths (the --from one and the in-memory one after --check --orgs) refuse a census row in one wording: "is published but not pinned … needs --pin, not a bump PR".

Re-derived at this head, just now:

• python3 tools/pin_watch.py --self-test → 56 ok, 0 FAIL (45 as reviewed + 6 from pin-watch: the bump step's shell parses (it never did), and an unread upstream fails it instead of passing as a clean day #1181 now on main + 5 new: both flags in one run → exit 1; both halves in the JSON; the census refusal in those words; and a pin that did move still printing its body from the same file, so the fix cannot be "refuse everything").
• python3 tests/workflow_shell_test.py → all checks passed.
• live on the real pins: --check --orgs 1bit-MONSTER,bong-water-water-bong → 1 of 148 moved, JSON keys [date, pins, changes, notes, published_not_pinned], published_not_pinned: [] (true tonight: the census finds nothing new), notes: []; the sweep is 67 s.
• --pr-body unsloth/Qwen3.8-Flash-Next-GGUF --from that sweep → correct 5-file body in 0.074 s.

Lane state: ~/briefs/TTEMPLATE-SEC-STATE.md; audit ~/tmplsec/AUDIT-1.md.

[bong-water-water-bong]

Two lines in this PR's own files state exit codes the tool does not return — measured on your head 50371ee and on main 872dbe3, so it is #1181's loose end rather than something your rebase broke. Posted here because you own these two files right now and a second PR on the same lines would only conflict.

1. tools/pin_watch.py:35 says a --pr-body for a repo that did not move is "a usage error (3)". It is 1:

$ printf '{"date":"2026-11-05","pins":1,"changes":[],"notes":[]}' > sweep.json
$ python3 tools/pin_watch.py --pr-body fake/moved --from sweep.json
pin_watch: fake/moved did not move (see sweep.json)
$ echo $?
1

That is sys.exit("pin_watch: … did not move …") — a string, so Python exits 1. Code 3 is --self-test failing (self_test() ends return 3 if failures else 0).

2. The exit paragraph says "1 a pin moved (or --check found nothing readable)" — the nothing-readable run is 2, which the tool's own self-test asserts (expect("nothing checked -> exit 2", …)) and main() ends with return 2 when every pin is in notes. Meanwhile 2 also covers usage: an unknown flag and a bare invocation both exit 2 (argparse, and print_help()).

So the real branches are: 0 nothing moved / the requested output printed; 1 a pin moved (a 404 row included) or --pr-body asked for a repo that did not move; 2 usage, or --check could read no pin at all; 3 --self-test failed; 4 --bump needs a human.

3. docs/model-pins.md:69 opens "There are three outcomes" and its table stops at 2, so 3 and 4 are undocumented and 2 is described only as the outage. On a page whose subject is how to tell a clean run from a could-not-check, a reader who scripts against those codes gets --bump's human-decision code wrong.

Suggested wording (yours to take or leave, ~6 lines):

-  repo. A repo that did not move is a usage error (3), not a body.
+  repo. A repo that did not move exits 1 with that message: no body exists for it.
-Exit codes: 0 nothing moved, 1 a pin moved (or --check found nothing readable), 2 usage,
-3 --self-test failed, 4 --bump needs a human (the repo or a tracked file is gone upstream).
+Exit codes: 0 nothing moved (or the requested output was printed), 1 a pin moved or the requested
+--pr-body repo did not move, 2 usage or --check could read no pin at all, 3 --self-test failed,
+4 --bump needs a human (the repo or a tracked file is gone upstream).

and in docs/model-pins.md: "There are three outcomes" becomes "The exit code keeps them apart (--help carries the same five)", with rows added for 3 (--self-test failed → the job fails) and 4 (--bump needs a human → the workflow skips that repo and says so), and row 2 widened to "a usage error, or no pin could be read at all".

If you would rather not carry it, say so and I will open it as its own PR against main after yours lands — either way the codes should stop disagreeing with the code. (Lane pi-docs; my state file records this as handed to #1193.)

[bong-water-water-bong]

Known-answer probe on real Hub data, because the census has so far only ever printed an empty result in production (nothing new was published today) and a feature that has only been tested against its own fixture is a feature I cannot vouch for.

Method, no writes to the tree: copy models/pins.json to /tmp/pins-probe.json, drop the one pin this PR added (bong-water-water-bong/ZR1-1.5B-Strix) — i.e. re-create the exact condition the census exists for — then run the real sweep against both orgs.

what	result (real API, 64 s)
first line	# Model pins: 1 of 147 moved, **1 published but not pinned** (2026-11-05)
the row	bong-water-water-bong/ZR1-1.5B-Strix with its six files (chat_template.jinja, checkpoint-{100,200}/…, tokenizer_config.json)
the JSON	published_not_pinned: [{repo, files, more}]
grep -c '^## \' pin-report.md(what the workflow'smoved=` counts)	1 — the census row is a table, not a ## \repo`` heading, so it can never inflate the bump loop into opening a PR for a repo that has no pin to bump
--pr-body bong-water-water-bong/ZR1-1.5B-Strix --from	rc 1, "is published but not pinned … needs --pin, not a bump PR"
--pr-body unsloth/Qwen3.8-Flash-Next-GGUF --from	rc 0, the correct five-file body

And the before/after on the same sweep file, which is what the union commit in this PR is for:

main (e0e177cc):   pin_watch: bong-water-water-bong/ZR1-1.5B-Strix did not move (see /tmp/probe.json)
this head:         pin_watch: bong-water-water-bong/ZR1-1.5B-Strix is published but not pinned … needs `--pin`, not a bump PR

Same input, same exit code — different sentence, and the first one sends a reader to the wrong question. (Also worth noting for #1181's side of it: the production run 42139845712 that merged it opened #1215 for the unsloth re-quant, so the bump step that never parsed now works; that PR is the owner's to take.)

[bong-water-water-bong]

VERDICT: READY at 50371ee7 (re-verdict: #1181's merged content is now in this branch, so the file is the two changes together).

What I re-derived at this head rather than assuming a clean rebase:

• --self-test: 56 ok lines, no failures (45 at the head I verdicted; the 11 new ones are #1181's: the --json sweep, --from, exit 4 for a vanished file, the 401/403 note).
• The tool's own gate, live, with a token: --check --orgs 1bit-MONSTER,bong-water-water-bong -> # Model pins: 1 of 148 moved (2026-11-05), no "published but not pinned" row, the 1 moved being unsloth's re-quant. Same answer as before the rebase.
• The census half is intact and unmoved: SHIPPED/shipped()/census() are the same code, models/pins.json is byte-identical (7e4f1829…) to the head I verdicted, docs/model-pins.md keeps its "The repos we publish" section, and the workflow runs both halves in one step (--check --orgs … --out pin-report.md --json pin-report.json) with the not checked|not pinned annotation still on line 71 — i.e. the two PRs' overlapping hunk resolved as one call rather than one of them dropped.

The three nits from my first verdict are unchanged and still non-blocking: the first line's checked = total - len(notes) subtracts census notes from the pin count (an unreadable org reports 147 of 148 checked when the pins were fine), the org listing is one limit=1000 call with no pagination, and a "published, not pinned" hit only annotates the run. #1181's rewrite already fixed the one that mattered for the merge gate (the bump step's shell and exit-code path).

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1181 - Partially compliant Compliant requirements: The bash syntax error in pin-watch.yml is fixed The bump step now fails when upstream is unreadable instead of passing as a clean day The workflow now correctly handles the case where a failed earlier iteration left its branch behind The --bump command returns 4 for repos or tracked files that are gone upstream The workflow now runs with proper shell parsing Tests are added to verify the fixed behavior Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect file filtering in --pin The --pin command now considers all files ending with SHIPPED extensions (".gguf", ".q4nx", "chat_template.jinja", "tokenizer_config.json") instead of just ".gguf" files. This change is correct for container/LoRA repos that may not have ".gguf" files but still ship templates or tokenizer configs. However, the implementation may need to be verified to ensure it correctly handles all edge cases, especially when a repo has multiple files of different types. paths = sorted(e["path"] for e in tree(repo, now) if e.get("type") == "file" and e["path"].endswith(SHIPPED)) Potential performance issue in census function The census function makes API calls to list models in each organization with a limit of 1000. If an organization has more than 1000 models, this could miss some models. While the limit is set to 1000, it's important to verify that this is sufficient for the current use case and that the implementation correctly handles pagination if needed. listed = api(f"/models?author={org}&limit=1000&full=true") Exit code handling for fresh repos The exit code logic in main() now returns 1 if either changes or fresh repos exist, but the workflow expects exit code 1 to mean "a pin moved". This change in behavior could be confusing for the workflow logic, which needs to distinguish between moved pins and newly discovered published repos that are not pinned. return 1 if (changes or fresh) else 0