fix(automation): fire tag_added only when the tag is actually added (#554)

[laithalenooz]

Summary

Fixes #554. The tag_added automation trigger matched whenever the configured tag was present on the task, and every update to the tags field produced a tag_added candidate. Any later, unrelated tag edit (or a removal) therefore re-fired automations whose tag had been added long before. In multi-stage review pipelines, where each stage's sign-off is a tag, tasks bounced back to earlier stages and duplicate agent runs started.

The automation consumer now derives the tags an update added from the change's old/new values and passes them to trigger matching:

• a configured tag must be among the added tags, and still present on the task;
• an unconfigured tag_added trigger ("any tag") needs at least one addition;
• a removal-only edit no longer produces a tag_added candidate at all.

This matches what the trigger is documented to do ("a tag is added"; {tag?}, omit = any tag), so no docs change was needed.

Type of Change

• Other (bug fix)

Checklist

• The change is focused and scoped: services/api/internal/worker/automation_consumer.go and its tests.
• Tests added: the regression case (an unrelated tag added while the configured tag is already present must not match), "any tag" with a removal-only edit, and addedTags across a JSON round trip; the existing triggerMatches tests were updated for the new parameter. go vet clean; go test ./... in services/api passes.
• Related documentation already describes the corrected behaviour.
• I avoided unnecessary detail or premature abstraction.

[pullfrog]

✅ No new issues found.

Reviewed changes

• tag_added fires only on an actual addition — handle now computes the tags an update introduced via the new addedTags(change) helper (new-minus-old over the decoded FieldChange.Old/.New), only appends TriggerTagAdded when the set is non-empty, and threads added through processEvent into triggerMatches.
• triggerMatches conditions tightened — a configured tag matches only when it is in added and still on the task; an unconfigured ("any tag") trigger requires at least one addition, so a removal-only edit no longer matches.
• Tests — regression case for an unrelated tag added while the configured tag is already present, the removal-only/any-tag case, and an addedTags JSON round-trip; existing triggerMatches callers updated for the new parameter.

I verified the surrounding contracts: FieldChange{Old,New any} decodes JSON arrays to []any (which addedTags handles, including null old and empty new); the only two producers of a tags change (task_handler.go:1307, task_autofill_consumer.go:686) both populate Old/New, so no path silently stops firing; tags are persisted verbatim (task_service.go:668), so added and task.Tags cannot diverge. go vet ./internal/worker/ is clean and the targeted tests pass, and the existing e2e happy path (add urgent to an empty task) still matches.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pikann]

LGTM! Please fix the failing lint check before merging.
Thank you for your contribution! 🚀

[laithalenooz]

Thanks for the review!

The Lint failure wasn't from this change: it was internal/platform/plugin/email_test.go:12 (noctx, net.Listen), which master fixed in 88bca4f after this branch was cut. I merged the latest master into the branch, and golangci-lint run (v2.14.0, same as CI) now reports 0 issues in services/api; the worker and plugin tests pass too.

[pullfrog]

✅ No new issues found.

Reviewed changes

The only commit since the prior pullfrog review is 2cc35a44, a merge of upstream/master into the branch. It does not touch this PR's own files, and the tag_added fix is byte-identical to the version reviewed at e92af8bb.

• Merged upstream/master — brings in the notification-title work (#553) plus 88bca4fa, which fixes the pre-existing noctx lint violation in internal/platform/plugin/email_test.go (net.Listen → (*net.ListenConfig).Listen) that was unrelated to this PR but had turned the api-pr-ci Lint job red. The Lint run at e92af8bb reported exactly one issue — that email_test.go line — so the PR-authored automation_consumer.go code is lint-clean.

No inline comments: the delta carries no behavioral change authored by this PR.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}