From 1c39ae06202241ff348360948fb84dc73e8b2dd5 Mon Sep 17 00:00:00 2001
From: Oluwaseun Ismaila <oluwaseun.ismaila@tether.io>
Date: Tue, 12 May 2026 16:34:51 +0100
Subject: [PATCH] QVAC-18613 infra: recognise verified label as explicit tier 1
 in approval bot

The tier-based approval check previously defaulted to tier 1 if no
\`tier2\` label was present, treating tier 1 as an implicit fallback.
Per QVAC-18190 the \`verified\` label landing in #1997 should also be
the explicit tier-1 marker, so reviewers can see in the bot comment
*why* a PR is at tier 1 (because it's verified, vs. because no tier
label is set).

Behaviour matrix (matches QVAC-18613 acceptance criteria):

| Labels on PR     | Tier  | Bot comment "Tier source"                          |
|------------------|-------|----------------------------------------------------|
| neither          | tier1 | default (no tier label applied)                    |
| \`verified\` only  | tier1 | \`verified\` label applied (explicit tier 1)         |
| \`tier2\` only     | tier2 | \`tier2\` label applied                              |
| both             | tier2 | \`tier2\` label applied (overrides \`verified\`)       |

Precedence rationale: \`tier2\` wins when both labels are present.
Stricter requirements take priority on conflict. The matrix above
is preserved verbatim in the bot comment so the reviewer can verify
the active rule without reading code.

Backwards compatibility: PRs with neither label keep the prior
behaviour exactly (tier 1 default, same requirements computation).
PRs with only \`tier2\` keep the prior behaviour exactly. The only
new code paths are the \`verified\`-only and both-labels cases.

Implementation:
- New \`hasVerified\` / \`hasTier2\` locals.
- New \`tierSource\` string threaded through
  \`checkTierRequirements\` and \`comment\` so the bot output mentions
  \`verified\` per AC #2.
- Bot comment gains a \`**Tier source:**\` line right under
  \`**PR Tier:**\` so the source is visible without expanding logs.

Validation plan:
- Marked draft pending #1997 (label-gate fan-out) merge so the
  \`verified\` label is actually applied in the wild.
- Test matrix walkthrough on a throwaway PR with each of the 4
  label combinations + \`/review\` comment to trigger the worker.
- Confirm the bot comment shows the expected "Tier source" string
  in each case and the requirementsMet decision is unchanged from
  the previous logic.

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .github/workflows/approval-check-worker.yml | 37 +++++++++++++++++----
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/.github/workflows/approval-check-worker.yml b/.github/workflows/approval-check-worker.yml
index 31827ae5c6..5696420fd7 100644
--- a/.github/workflows/approval-check-worker.yml
+++ b/.github/workflows/approval-check-worker.yml
@@ -243,7 +243,8 @@ jobs:
               context,
               approvals,
               tier,
-              prNumber
+              prNumber,
+              tierSource
             ) {
               const { teamMemberApprovals, teamLeadApprovals, managementApprovals } = approvals;
 
@@ -289,7 +290,8 @@ jobs:
                 approvals,
                 tier,
                 prNumber,
-                bypass ? bypassReason : null
+                bypass ? bypassReason : null,
+                tierSource
               );
               return { requirementsMet, statusMessage };
             }
@@ -302,7 +304,8 @@ jobs:
               approvals,
               tier,
               prNumber,
-              bypassReason
+              bypassReason,
+              tierSource
             ) {
               console.log(`\nStatus: ${statusMessage}`);
 
@@ -353,6 +356,7 @@ jobs:
                 const commentBody = `## Tier-based Approval Status
                             
                 **PR Tier:** ${tier.toUpperCase()}
+                **Tier source:** ${tierSource}
 
                 **Current Status:** ${requirementsMet ? "✅ APPROVED" : "❌ PENDING"}
 
@@ -390,17 +394,36 @@ jobs:
             // Get PR labels
             const labels = approvals.pr.labels.map(label => label.name);
 
-            // Determine tier - default to tier1 if no label
+            // Determine tier and a human-readable source for the bot comment.
+            //
+            //   - `verified`           -> explicit tier 1 (set by label-gate / a
+            //     trusted reviewer; QVAC-18613).
+            //   - `tier2`              -> tier 2 (unchanged from previous
+            //     behaviour).
+            //   - both labels present  -> `tier2` wins. Stricter requirements
+            //     take priority when there is a conflict.
+            //   - neither              -> default tier 1 (unchanged from
+            //     previous behaviour).
+            const hasVerified = labels.includes('verified');
+            const hasTier2 = labels.includes('tier2');
+
             let tier = 'tier1';
-            if (labels.includes('tier2')) {
+            let tierSource = 'default (no tier label applied)';
+            if (hasVerified) {
+              tierSource = '`verified` label applied (explicit tier 1)';
+            }
+            if (hasTier2) {
               tier = 'tier2';
+              tierSource = hasVerified
+                ? '`tier2` label applied (overrides `verified`)'
+                : '`tier2` label applied';
             }
 
-            console.log(`PR #${prNumber} is classified as: ${tier}`);
+            console.log(`PR #${prNumber} is classified as: ${tier} (${tierSource})`);
             console.log(`PR Labels: ${labels.join(', ')}`);
 
             // Check requirements
-            const result = checkTierRequirements(github, context, approvals, tier, prNumber);
+            const result = checkTierRequirements(github, context, approvals, tier, prNumber, tierSource);
             
             console.log(`Repository: ${approvals.repoOwningTeam}`);
             console.log(result.statusMessage);