From 92c5b1ab71e1fe659e029b1b51568cff0132bc40 Mon Sep 17 00:00:00 2001 From: "ReARM Agent (claude2)" Date: Wed, 12 Aug 2026 12:31:12 +0000 Subject: [PATCH 1/2] fix(ui): the perspectives hint states the opposite of what the code does Found while writing the Teams documentation, by checking a claim rather than copying it across. The hint said perspectives are "resolved from the affected releases, which only vulnerability events carry: with perspectives set, release and approval events match nothing". Every part of that is wrong. ReleaseChangeHookImpl stamps ReleaseNotificationSupport.buildAffectedReleases onto RELEASE_CREATED, RELEASE_LIFECYCLE_CHANGED and RELEASE_BOM_DIFF; ApprovalEventNotifierImpl does the same for APPROVAL_REQUESTED and APPROVAL_RESOLVED; and that helper copies the component's perspectives onto each AffectedRelease. A perspective-scoped route matches those event types perfectly well. This mattered beyond the wording. The same claim is why the perspectives control was a candidate to be hidden alongside the minimum-severity one in this PR, and it was cited in the review as an unexplained inconsistency. The inconsistency is real but the direction is the opposite of what it looked like: severity IS inapplicable outside the two vuln event types (no producer resolves one), so hiding it is right; perspectives apply everywhere, so hiding them would have removed a working feature on the strength of a false comment. The deferral note added earlier in this PR is replaced by the finding. What an operator actually needs to know is what the gate requires -- a component that belongs to the perspective -- so that is what the hint now says. The identical claim survives in perspectiveGateMatches' javadoc in rearm-saas and is tracked on the board (t20260812-121545-31450); it is a comment-only fix in the other repo, not folded in here. Co-Authored-By: Claude Opus 5 ReARM-Agent: a7dbfd07-7512-451d-8883-2e047dff3a50 ReARM-Agentic-Session: 3b26cb26-2a38-4ed6-811b-d008781071f1 --- ui/src/components/SubscriptionsOfOrg.vue | 28 ++++++++++++++---------- 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/ui/src/components/SubscriptionsOfOrg.vue b/ui/src/components/SubscriptionsOfOrg.vue index e149b461..70c582bb 100644 --- a/ui/src/components/SubscriptionsOfOrg.vue +++ b/ui/src/components/SubscriptionsOfOrg.vue @@ -126,19 +126,23 @@
Perspectives gate what this subscription delivers — they do not affect the in-app inbox or the bell. Leave empty for no restriction. - Note they are resolved from the affected releases, which only vulnerability - events carry: with perspectives set, release and approval events match - nothing. Keep those on their own subscription. + They are resolved from the event's affected releases, so a route only + fires when an affected release's component belongs to one of the chosen + perspectives -- a component with no perspectives set matches none of them.
- +
Destination
From ea4410e578f1dc4ddf7793b2be202e1d5669c965 Mon Sep 17 00:00:00 2001 From: "ReARM Agent (claude2)" Date: Wed, 12 Aug 2026 12:39:15 +0000 Subject: [PATCH 2/2] fix(ui): one word for one state -- an archived team reads "(archived)" everywhere The Layer 2 review of the docs PR found three pickers naming the same team state three ways: the route-target picker said "(deactivated)", the owner and assignment-rule pickers say "(archived)", and the Teams tab itself calls the action Archive and toasts "Team archived". The status stored underneath is INACTIVE in all three. Nothing was broken, which is exactly why it survived -- but an operator reading "deactivated" in one picker and "archived" in the next has no way to know they are the same state, and the documentation being written for this feature had to either pick one and be wrong somewhere or name all three. Aligned on "archived", the verb the feature's own control uses. Co-Authored-By: Claude Opus 5 ReARM-Agent: a7dbfd07-7512-451d-8883-2e047dff3a50 ReARM-Agentic-Session: 3b26cb26-2a38-4ed6-811b-d008781071f1 --- ui/src/components/SubscriptionsOfOrg.vue | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ui/src/components/SubscriptionsOfOrg.vue b/ui/src/components/SubscriptionsOfOrg.vue index 70c582bb..e00f44e5 100644 --- a/ui/src/components/SubscriptionsOfOrg.vue +++ b/ui/src/components/SubscriptionsOfOrg.vue @@ -504,8 +504,13 @@ const teamOptions = computed(() => { for (const r of subForm.value.routes) for (const t of (r.teams || [])) referenced.add(t) // Same shared builder as the channel picker, so the "keep dangling refs // visible and removable" behaviour cannot drift between the two. + // + // "(archived)" rather than "(deactivated)": the Teams tab calls the action + // Archive and reports "Team archived", and the assignment-rule picker + // already says archived. Three words for one state across three pickers is + // how an operator ends up wondering whether they mean different things. return withGhosts(selectable, teams.value, referenced, - (t: any, uuid) => t ? `${t.name} (deactivated)` : `(deleted team) ${String(uuid).slice(0, 8)}`) + (t: any, uuid) => t ? `${t.name} (archived)` : `(deleted team) ${String(uuid).slice(0, 8)}`) }) const channelGroupOptions = computed(() =>