2 Commits

Author	SHA1	Message	Date
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
Krzysztof kuhy Rudnicki	21ccf8d8eb	fix: find exiftool the way the service does, and self-test with a photo ... Two things the first live run found, neither of which any test could have. **exiftool was invisible to the unit.** Arch's perl-image-exiftool installs to /usr/bin/vendor_perl/exiftool. That is on an interactive shell's PATH, because perl's profile.d puts it there, and it is *not* on a systemd user unit's, whose default is "/usr/local/bin:/usr/bin". So shutil.which found it in every test and in every shell, and the first real !add_photo under the unit answered "exiftool is not installed; refusing to store .jpg" -- with exiftool plainly installed. media_strip.locate() now tries PATH and then the known install locations, and install_service.sh verifies the result through the bot's own resolver under the unit's PATH rather than through `command -v`, which answers for the wrong shell. Fixing the lookup rather than setting PATH in the unit: the latter is a note somebody has to remember on the next machine. The absent-exiftool test had to blind *both* lookups to keep covering its branch -- on a machine that has the package the fallback finds it, which is precisely how the gap survived. **The self-test could not carry a photo.** Signal never delivers an account its own sends: measured against the live container, a single-device account gets no sync copy either, and a sent attachment is not added to the container's attachment store (only inbound ones are). So !add_photo could not be exercised the way every other command is. selftest.build_frame and POST /_selftest now take attachment ids that the container's store already holds, so the handler fetches them back over the real GET /v1/attachments/{id} -- the ingest path under test is the live one, not a hand-fed buffer. Still fail-closed on SELFTEST_GROUPS. Verified live, against real Signal and the real container, in the testbot group, on a throwaway album scoped to that group so the private one was neither read nor written: - a geotagged JPEG (GPS + Make) went in as "!dodaj alfa wakacjelive" - the stored file reports zero non-structural tags, and neither the GPS marker nor the Make string survives in its bytes - GET /v1/attachments/<id> now 404s and the file is gone from disk, so the second copy really is deleted - the typed label appears zero times in the journal - !losowe wakacjelive, !alfa and an unknown label all answered without error Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JqqE22jp94B1ypwxppdr1o	2026-08-31 11:40:07 +02:00