The label guard lets through two kinds of label the rule says it strips

[macanderson]

The problem

The rule about who may put a priority or size label on an issue is written in
docs/scr/SCR-005-triage-separation-of-duties.md. The thing that is supposed to
enforce it is .github/workflows/triage-guard.yml. They no longer agree, in two
ways, and in both of them the guard is the looser one.

1. The guard stops at P3, but P4 is a real label and the rule now covers it

triage-guard.yml's script matches priority labels with:

const P = /^P[0-3]$/;

P4 does not match. So if anyone other than the triage authority adds P4 to
an issue, the guard leaves it alone: it is not removed, and the issue is not
re-queued as triage.

P4 is not hypothetical. It exists in this repository's label set:

$ gh label list
...
P4	Someday/maybe — speculative, deprioritized	#eeeeee

And commit a01ca64 ("docs(scr): resync SCR-005 to the P4-tier revision", #100),
which is on main right now, added P4 to the rule the guard implements.
SCR-005 today reads:

Priority scheme: P0 drop everything · P1 this cycle · P2 next cycle ·
P3 backlog · P4 someday, speculative.

and

Never add, remove, or change P0–P4 or size/* labels — the triage-guard
workflow strips such labels and re-queues the issue.

The workflow was not updated in that commit.

2. The guard never touches size/* labels at all

The same SCR-005 sentence promises the workflow strips size/*. It does not.
There is no occurrence of the string size anywhere in
.github/workflows/triage-guard.yml — the only label logic in the file is the
P regex above and the triage label it adds. Five size/* labels exist
(size/XS, size/S, size/M, size/L, size/XL), and any issue creator can
apply one and keep it.

3. CONTRIBUTING.md describes a label set this repository does not have

While confirming the above I checked the label list a contributor is actually
shown. CONTRIBUTING.md's "Issues and labels" section says:

Labels you'll see: area:* routes an issue to a crate; P0–P2 is priority;
good first issue and help wanted mean what they say; needs-witness means
a PR is waiting on its witness test.

Checked against gh label list: there is no area:* label of any kind and
no needs-witness label in this repository, and the priority range is
P0–P4, not P0–P2. Three of the four claims in that sentence are wrong.
It belongs in the same fix because it is the same drift, and a contributor
reading it will look for labels that are not there.

What I verified vs. inferred

Verified, against origin/main at a01ca64:

• git show origin/main:.github/workflows/triage-guard.yml contains
  const P = /^P[0-3]$/ and no other label matching.
• rg size .github/workflows/triage-guard.yml returns nothing.
• gh label list shows P0–P4 and size/XS…size/XL, and shows no
  area:* and no needs-witness.
• git show origin/main:docs/scr/SCR-005-triage-separation-of-duties.md names
  P0–P4 and size/* as labels the workflow strips.
• No open pull request (chore: sync /triage-sweep with the copy in the sibling repos #101, ci(sdk): typecheck both typed SDKs, and catch a pin that drifted from its manifest #106, feat(schema): name the schemas' identity on a branded, family-versioned URL #109, feat(contextgraph-host): cross-provider ranking is a seam, not raw score #113, feat(contextgraph-types): implement record_hash and RecordAttestation #114, feat(sdk): port provenance attestation to the TypeScript, Python, and Go SDKs #131) touches
  triage-guard.yml, SCR-005, or CONTRIBUTING.md's label section.

Inferred, not verified: I did not fire a live labeled webhook to watch the
guard skip a P4. The conclusion follows from reading the regex, which is the
only place the workflow decides what counts as a priority label.

Why it matters

SCR-005 exists so that backlog order does not reflect who filed the issue. Two
of the label families it covers are unenforced, and one of them — P4,
"someday/maybe" — is the single most useful label for an issue creator who wants
their own finding quietly deprioritized or, in the other direction, for anyone
who wants to bury a report. The rule reads as enforced. It is enforced for three
of the five priority tiers and none of the sizes.

How to reproduce

1. Open any issue.
2. Add the P4 label as a non-whitelisted user (the whitelist is
   TRIAGE_LOGINS: triage-bot macanderson in the workflow's env:).
3. The triage-guard run fires on the labeled event, matches nothing, and
   exits. P4 stays.
4. Repeat with size/M. Same result.

What "done" looks like

• triage-guard.yml strips a creator-applied label in every family SCR-005
  names — the priority tiers P0–P4 and size/* — and re-queues the
  issue as triage, with the existing explanatory comment.
• The regex is not the only copy of the tier list. Either derive the tiers from
  the repository's own labels, or add a check that fails when SCR-005's tier
  list and the workflow's pattern disagree. This drift happened because a
  documentation commit and a workflow file are two places to write one fact, and
  a straight regex widening will let it happen again the day a P5 appears.
• CONTRIBUTING.md's "Issues and labels" paragraph names only labels that
  exist, with the correct priority range.
• A witness: a test or dry-run over the guard's script showing that P4 and
  size/M from a non-whitelisted login are removed and triage is restored,
  and that a whitelisted login's labels survive.

Constraints

• The workflow calls actions/github-script@v7 with an inline script, so there
  is no unit-test harness in the repo today. Extracting the label decision into
  a small pure function that a test can call is the durable shape; a
  workflow_dispatch dry-run against a scratch issue is the cheap one.
• SCR-005's frontmatter enforcement: line also says the workflow "strips
  creator-applied P-labels" and says nothing about sizes. Whichever way the fix
  goes, that line and the body's "How an agent complies" list must end up saying
  the same thing as the code.
• Do not add priority or size labels to this issue; per SCR-005 it carries
  triage only.