7 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	2f9e35390e	fix: the matcher sees a drop's names, finds merged trickles, and catches up on its own (4390, 4392) ... Three defects found while answering "is the linking automatic": 1. The name and image checks never worked on a live drop. The corpus keyed every image by primary_post_id, but a drop's images belong to its member messages and the drop claims them only through provenance, so a drop looked nameless and hashless. The tests attached images to the drop itself, which discord_grouping never does. Images now count under the post a reader sees them on: a message's absorbing drop, else the post itself. 2. The trickle merge (e08401c) dates a drop by its first stage, days before the release a teaser announces, which put merged trickles outside the 24h window. Candidates are now found and timed by their closest member message. The sweep follows recently grown drops by their messages' times the same way. 3. A pair left pending was skipped forever: the matcher skipped every recorded pair, not only decided ones. Pending pairs are now re-scored in place and linked once conclusive. Linked and dismissed pairs are still never touched. Also, "Scan now" shared the sweep's 48-hour horizon, so it could not reach the history it is described as being for. It now scores every post by an artist with Discord drops (rescan(full=True)). New tests build drops the way the grouper does, with images owned by the member messages. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 14:01:07 -04:00
bvandeusenandClaude Opus 5	f7b3e15014	feat: the drop carrying the teaser's own image links it (4392) ... Crop-to-source matching was held until the cheap signals could be shown insufficient. They can: of artist 8's 27 teasers with a drop inside a day, 11 go unlinked, and five are screenshot teasers with no working name at all. So it was tried, on exactly those pairs. Every teaser image correlated against every window of every nearby drop image at five scales, ground truth being the pairs the working name independently confirms, control being unrelated same-artist posts a month away. **It does not separate** — true pairs score as low as 0.401 while the control reaches 0.605, and no threshold divides them. The reason is the one the naive version was rejected for, which turns out to apply just as hard to the careful one: a single artist's work is stylistically homogeneous, so a whole-image comparison between two of their pieces is high whether or not it is the same piece. That is now written down in the module docstring with its numbers, so the next person to reach for it inherits the measurement instead of repeating it. What survived asks a narrower question the measurement shows IS answerable: not "is this a crop of that" but "is this the same image". Same pairs, same control, using the pHash FC already stores on every image — pairs the name confirms score 0, 0 and 20 bits of 256; the nearest unrelated pair in a 29-sample control scores 108. The threshold sits at 32, which is the number gallery_service already calls a near-duplicate, inside a 76-bit gap. It earns its place by being the only signal needing no cooperation from the creator: it works on a teaser called `Screenshot 2026-08-13`, and on a creator whose two platforms share no naming convention. It is quiet most of the time, because a teaser is usually a crop rather than a copy — but where it fires it is close to certain, and it recovers `Cute Selfie, Cute Dress` from the unreachable list. utils/phash warns the hash alone must not decide a MERGE, since variants of one piece collide at this distance. That does not invert here — it is the point. A merge destroys a file, so a variant colliding with its original is a loss; this asks whether two POSTS are about the same piece, and a variant of the drop's image is exactly that. Nothing is deleted either way. Gated on posts like the other two: an image on many of the creator's posts is a banner, not a piece. `_rarity` is public as `rarity` now that all three signals share it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 08:27:20 -04:00
bvandeusenandClaude Opus 5	941f1c6e07	fix: run 7464's two failures — an unused loop target and a missed call site (4392) ... Both mine, both from the same change. `identity` is unpacked in the write loop and never read there — the decision it feeds happens above it, when `conclusive` is built. flake8-bugbear is on repo-wide and B007 is exactly this. Renamed `_identity`, and `linked += status == "linked"` spelled out as the `if` it actually is. The second is worse, because it was a real assertion silently pointed at the wrong shape. `match_post` now returns `(proposed, linked)`, and when I rewrote the call sites I matched on `) == 0` — so the one comparison in the file that reads `) == 1` kept comparing a tuple to an integer. Found by walking the module's AST for every comparison against `match_post` and every use of a name assigned from it, rather than grepping again with the pattern that had already missed it once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 08:20:12 -04:00
bvandeusenandClaude Opus 5	31de54e326	feat: FC links a conclusive pair itself instead of asking (4392) ... Operator, 2026-09-24: *"I don't want this to be manual that defeats the convenience that I'm going for."* Confirm-only was right while every signal was circumstantial. Time proximity and a body that mentions Discord can never be more than suggestive, so asking was the honest response to what FC actually knew. A shared working name is different in kind: when the creator's own name for a piece appears in exactly these two posts and nowhere else in their library, there is nothing left for the operator to adjudicate, and asking is a chore FC invented for them. AUTO_LINK_FLOOR is 1.0 and sits deliberately above IDENTITY_FLOOR's 0.75. The gap between them IS the review queue — real evidence, not certain enough for FC to act on alone. Measured on artist 8, of 15 name-sharing pairs: 11 are conclusive, 2 more propose, 2 fall short of both. Three refusals, because an auto-link is FC asserting something the operator never saw: * Exactly one candidate may be conclusive. Two is not a tie to be broken by score — one post can tease two pieces dropped separately, and then each drop carries a different name from the same teaser, each individually conclusive. Two conclusive answers to "which drop is this" means the question was wrong, so both queue and FC says nothing. * Neither end may already be claimed by an accepted link. That link is the operator's decision and reassigning its other end would overrule them silently. * The whole thing is one setting, defaulting on, reversible in the UI — an accepted link is a row they can dismiss. `match_post` now returns (proposed, linked) so a sweep can report what it did on its own rather than only what it queued. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 08:14:04 -04:00
bvandeusenandClaude Opus 5	81f23991e9	fix: a sweep follows the drops FC has just authored, not only recent posts (4392) ... #4392's third cause, and the only one of the three about whether a pair is SCORED AT ALL rather than how well. A drop's post_date is backdated to its first message, but FC cannot author the drop until that message has an embedding and the hourly grouper has run. So a drop created this minute lands wherever its messages were — days or weeks back in the feed. The sweep only looked at announcements published within twice the window of NOW, so by the time the drop existed its neighbours were already outside the horizon, and nothing brought the sweep back to them. Measured on the live instance: a pair scoring 0.800 with `associations: []` and an empty queue. The two scoring fixes in the previous commit would not have helped it, because nothing scored it. So the sweep now also gathers announcements sitting beside any drop whose `last_grew_at`/`downloaded_at` is inside the horizon — the drop's own clock rather than its backdated position. Capped at MAX_RECENT_DROPS so a backfill authoring thousands at once does not quietly become the full-library rescan the manual button exists for, and the id set is sorted before the loop because a sweep visiting posts in a different order each run is one whose failures cannot be reproduced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 08:09:09 -04:00
bvandeusenandClaude Opus 5	fd214f3a08	feat: the matcher gets an identity route, so a name can link what time cannot (4392) ... #4392 measured three compounding reasons the announcement matcher could not fire for this creator. This is the first two. **Vocabulary.** `discord` is not how these creators write once the audience already knows where the server is. Across 20,558 Patreon bodies `discord` appears in 486 and `the server` in 37 — but the distribution is the point, not the totals: for artist 8, 21 of 42 posts say `discord`, 7 say `the server`, and it is the RECENT ones that say the latter. A vocabulary list written from old posts silently stops matching the posts that still need it. **Two routes.** Circumstance and identity answer different questions. Proximity and a declaration say two things happened near each other; a working name the creator uses on these two posts and nowhere else says they are the same piece. Averaging those makes the threshold uninterpretable and costs both ways — adding identity as a fourth weight dilutes the others enough that measured teaser/drop pairs an hour apart stop proposing, while capping identity at a weight means the strongest evidence available can never carry a pair alone. So identity may OVERRIDE, never dilute; below IDENTITY_FLOOR it is recorded for the operator and moves nothing, which is the conservative direction, since a wrong link asserts two different pieces are one. The circumstantial bundle is now proximity/declared/marker at .45/.35/.20. Rebalanced rather than extended: the existing guard still holds arithmetically (no single weight reaches the threshold) and the existing pairs still score where they did — a teaser and its drop an hour apart with an invite link go from 0.815 to 0.781, both well over. Measured against the live instance, artist 8: 17 candidate pairs, 14 carried by a shared name, no false positives, and no drop claimed by two posts. The operator's own example — `Anya -- 🍈🍈` and the drop 75 minutes before it — links on the token `0-k`, which is what its two files are called on either platform. Two pairs 21h apart that proximity scores 0.10 are reached, and two more (`680lc`, `cnni18x`, four posts each) are the stated cost of the floor. Both rare-token signals are artist-scoped and loaded once per artist per sweep, not per candidate pair. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 08:07:25 -04:00
bvandeusenandClaude Opus 5	235393c08b	feat: link the Patreon teaser to the Discord drop it announced (388 step E5) ... The point of the milestone rather than its tail. Two of the operator's artists post a deliberately cropped fragment on Patreon to signal that the real thing has landed in their Discord; this proposes those pairs. Confirm-only, following the FC-6.3 series matcher. A wrongly-asserted association tells the operator two different pieces are one, which is strictly worse than no link: no link leaves them where they already were, a wrong one actively misinforms and then propagates into whatever reads it. So the matcher's job is a SHORT list worth reading, not a long list worth trusting. **The threshold sits above every single signal weight, and that is the design.** Proximity is 0.55, declaration 0.45, the cut 0.60 — so neither signal can carry a pair alone. That makes "time proximity alone is never sufficient" an arithmetic property rather than an aspiration: on a busy day an artist posts several times, and a matcher that could pair on proximity alone would turn every one of those days into false pairs until the review queue got abandoned. A guard test asserts the relationship against WEIGHTS directly, so it survives any refactor of the scorer, and says in its own failure message not to fix it by lowering the assertion. **Crop-to-source matching is HELD, on the plan's instruction** — real work with real false-positive risk, worth building only once signals 1 and 2 are shown insufficient against the operator's actual artists. Worth stating: a naive whole-image SigLIP similarity is NOT that signal. A cropped teaser and its full version are precisely the pair a whole-image comparison handles worst, so adding one as a "bonus" would mostly add noise while looking like progress. Two premises in the plan corrected in the building: * **E4 is not actually a prerequisite.** A Patreon Source and a Discord Source the operator has added under one Artist already share `Post.artist_id`, and the synthetic grouping inherits it. E4 EXTENDS this to creators FC has to learn the association for; it is not needed to represent one FC was told. Same-artist is then a hard filter, not a scored signal — two different creators posting minutes apart is a coincidence, not evidence. * **`link_extract` cannot supply the declaration signal.** It exists, but `SUPPORTED_HOSTS` is file hosts only and `host_for()` returns None for a Discord URL, so no ExternalLink row is ever written for one. The signal reads the post body directly instead. And a bug my own test would have caught: `declared_signal` stripped the HTML before looking for an invite, but `html_to_plain` discards attributes and these creators put the invite in an anchor's `href` — so the strongest form of the signal was being thrown away, leaving only whatever the link text said. The invite now matches the raw body; the bare mention still matches stripped text, so `\bdiscord\b` is tested against prose rather than against markup. Dismissed rows are kept, not deleted: the row is what remembers the rejection, and re-proposing a rejected pair on every scan is the one behaviour that makes a review queue get ignored. Both FKs CASCADE, so E3's one-DELETE reversal cannot leave a proposal pointing at a post that no longer exists. Only ACCEPTED links reach the post payload. A pending proposal is a question for the review queue, not a claim to render beside the artwork. UI (rule 27) follows in the next commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LNXXULQDjVZmbuNa2G9mD9	2026-09-10 11:47:28 -04:00