Remove the duplicated new-issue-approval link from the agenda Prework section

Inizia con l’issue #162 e conferma che i punti elenco Prework e Recurring contengano ancora i filtri citati qui. Recupera ed esegui il backup del body corrente, quindi applica una patch solo al link New Issue Review duplicato, preservando le sezioni e i link denominati. Recupera nuovamente il body e verifica che il commento generato il lunedì successivo contenga esattamente un link a quella colonna.

Overview

We need to remove the duplicated link to the New Issue Review column from the Leads and PM meeting agenda template (#162), because since the 2026-08-24 repair the Prework bullet queries the same board column as the Recurring bullet, so a single agenda now sends the reader to one column twice.

Action Items

• Confirm both bullets still read as below before changing anything — #162's body is edited by several people through the web UI, so it may have moved since this was written. As of 2026-08-27:
  • Prework, line 13: "project board, new issue approval, no ready for no draft" → status:"New Issue Review" -label:"ready for CoP Lead","ready for product","ready for prioritization" -label:draft
  • Recurring items, line 18: "review any issues that are in the new issue approval column" → status:"New Issue Review"
• Verify the subset relationship rather than assuming it. The Recurring filter is a bare status term with no negations, so everything the Prework link returns is also returned by the Recurring link. That is what makes this a duplicate rather than two genuinely different views.
• Decide which one survives. The negations are the useful part — a bare status:"New Issue Review" returns items already marked ready for ..., which is exactly what the reviewer does not need to look at again. Recommendation, to accept or overrule: keep the Prework bullet's filter and drop the Recurring one, folding the Recurring wording into the Prework bullet so the agenda keeps the instruction "review any issues in the new issue approval column" but points it at the filtered view.
• Do not remove the -label:draft term while you are in there. draft was dropped as a template default on 2026-08-09, so it now matches almost nothing — but it still catches a manually applied draft label, and the label deliberately still exists for that purpose. Leaving it is correct; it is not dead weight to tidy up.
• Edit #162's body following the "Editing procedure issues in place" discipline — fetch fresh and diff against the last copy, save a pre-edit backup, patch the specific bullets rather than regenerating the body, then re-fetch and assert both the change and that the Prework icebox link, the three PM review links and the Task Items / FYIs sections are untouched.
• After the edit, verify at the next weekly run, not only on save: the agenda comment generated for the following Monday should contain exactly one link to the New Issue Review column. That is the real test — the body is a template, and what matters is what the copied comment looks like.

Resources/Instructions

• The issue to edit: #162 "CoP DevOps: 2026 Leads and PM meeting Agenda". Its body holds the template; each week's run is a new comment. Edit the body template only — never a past comment.
• How this arose: the Prework bullet used to carry no state or status term at all, so a link labelled "new issue approval" returned 87 board items, 55 of them Done, going back to 2022. It was repaired on 2026-08-24 by adding status:"New Issue Review" — which fixed the link and, as a side effect, made it a strict subset of the Recurring bullet. This ticket is the second half of that repair.
• Scope boundary, deliberate. #162 needs a wider restructure — it still hardcodes three PM review links by GitHub handle and two Google Sheets roster links, and its text has drifted from what its filters actually do. That work is separate, larger and currently unticketed. This ticket is only the duplicated column link. Do not fold the restructure in; if you find yourself rewriting whole sections, stop and raise it.
• Worth knowing while editing these filters: no:assignee is silently ignored in a Projects v2 filterQuery — no error, no warning, it just does not apply. That is why the Prework link no longer mentions it, and it is why any filter change here has to be checked against a board item you know should be excluded rather than trusted because the syntax looks valid.