2 Commits

Author	SHA1	Message	Date
Krzysztof kuhy Rudnicki	9d546fef9a	feat: import a folder of photos without importing it twice ... tool/tagger.py did not run at all: 48957a1 renamed pack.default_dir to default_dirs and missed the caller, so the tagger raised ImportError at module scope through two releases. Nothing could have caught it -- tool/ is outside --cov and mypy ran with [signal_bot, fake_signal]. Both are widened here, and tests/test_tool_imports.py imports every script under tool/. --import was a filename check and shutil.copy2. Pointed at a phone export that overlaps the album it re-imported the same photo under whatever name the exporter used that time. It now identifies files by magic bytes, strips them through the same media_strip path !add_photo uses, and dedups on exact bytes twice: the source hash, then -- only for what survives -- the hash after stripping. sources.json records both, so a second run on the same folder is a no-op. What the album refuses is moved to _skipped/<reason>/ beside the source, never deleted. Two things that made "strip on import" impossible until now: media_tags claims -all= zeroes the QuickTime date tags and allows them by value. It does not; measured, it leaves CreateDate at its real value, and every mp4 was being refused. -time:all= is what zeroes them. And a tag allowlist cannot see the worst class at all. IMG_6924.mp4 carries mebx timed-metadata holding per-frame face bounding boxes and a face id, and those survive a complete tag strip because they live in mdat as opaque samples. media_tracks.py drops the track with ffmpeg and verifies with ffprobe that only video and audio survived. This is not the ffmpeg mistake media_strip warns about: that was ffmpeg replacing exiftool for tags, this is track removal with exiftool still doing every tag, and the gate is a positive read-back rather than an exit code. The roster was write-once. The setup form only appeared on an empty album, Album.setup overwrote the file whole, and keys were positional (p{len+1}), so inserting somebody renumbered everyone after them and repointed every tags.json entry at the wrong person. Keys now come from the highest number in use, the form merges, and a person can be added mid-session. --untagged filters the page and never the server's list. /media/{index} and /api/tag both index the full album, so a shorter list server-side would show item i of the album while tagging item i of the filtered set. Measured on the live album: 174 source files -> 1 not media, 82 already in pack, 24 duplicate in batch, 67 imported, and re-running imports nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WBrE1b9HvFw3xvG9bJiDFt	2026-08-31 13:22:57 +02:00
Krzysztof kuhy Rudnicki	48957a105d	feat: serve several photo albums at once, each scoped to its own groups ... You asked for !add_photo in testbot without the real album being reachable there. One album cannot do that: its people.json "groups" list *is* the privacy guarantee, so making the commands exist in a second group necessarily makes the real photos postable there. So the bot now loads several albums. PHOTO_PACK_DIR takes a comma-separated list, the spelling GROUP_IDS and TRUSTED_INVITERS already use. Each album carries its own group scope, its own people, its own tags and its own custom labels; they share nothing but the process they run in. That makes trigger collisions between albums legal for the first time, and the registry had to learn it. Two albums are two different sets of people and both may reasonably call somebody "!alfa" -- no message can ever mean both, because a command a group is not scoped to is not a command there at all. So a trigger may be claimed more than once, and DuplicateTriggerError now fires only where the group sets *overlap*. Overlapping albums are refused at startup rather than resolved by registration order: a coin toss about which private album receives a photo is the outcome this whole design exists to prevent. Two consequences worth naming: - registry.resolve() takes an optional group. Without one it still answers "does anything claim this word", which is what pack_add's mint check wants; with one it answers "what runs here", which is what the dispatcher wants. resolve_with_args no longer resolves-then-checks, because with two claimants the first one found may be the wrong group's. - CommandContext moved to signal_bot/context.py to keep registry.py under the 250-line cap. A filing change: that file is "which word runs what", this one is "what the thing that runs may do". DOCS-add-photo.md is likewise a split, not new prose -- DOCS-photo-pack.md had grown past the cap and the ingest path is its own subject now. Verified live: the unit serves both albums, the real group resolves its 13 album commands and testbot its 7, and !losowe / !alfa / !dodaj all fire in testbot through the live dispatcher. 997 tests, 100% branch coverage, 28 e2e scenarios. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JqqE22jp94B1ypwxppdr1o	2026-08-31 11:58:50 +02:00