fix: give the catch-all zones a real owner, and catch silent CODEOWNERS breakage

[qiuethan]

What this changes

Closes two CODEOWNERS gaps, both of which fail silently — no error, no red X, reviews just quietly go to the wrong person or nobody.

No ownership is assigned here. Every line is still @qiuethan; this is the structural groundwork so that adding real owners is safe.

Why

1. Unregistered services and packages had no owner

docs/CODE-OWNERSHIP.md flagged this as "latent, not yet biting": services/other and packages/other had no CODEOWNERS line and resolved through the * fallback. Invisible while every owner is one person — wrong the moment they diverge, because a new service would auto-request whoever holds * rather than anyone who knows it.

Bare /services/ and /packages/ lines now own those buckets.

Their position is load-bearing, and it's the mirror image of pr-zone-check.yml:

	Resolution	So the catch-all goes
zone_for()	first match wins	below the specific arms
CODEOWNERS	last match wins	above the specific lines

Put /services/ below and it swallows every service — services/llm would be reviewed by the catch-all owner instead of its own. check-labels.mjs now enforces the position, not just the presence.

root still resolves through *, and always will: it isn't a directory, and "every top-level file" is exactly what * already means.

2. A broken owner entry is completely silent

Name someone who isn't a collaborator, or who has read-only access, and GitHub never requests them and never says why. The zone looks owned. You find out when something merges unreviewed.

codeowners-valid.yml asks GitHub's own parser (/codeowners/errors) on every change to the file. This is deliberately a separate job from label-consistency — that one is offline and structural (does the zone list agree with itself); this one is a live lookup against org membership. check-labels.mjs structurally cannot catch it: it sees a line per zone, not whether the handle on that line can review.

Zone

.github · docs · scripts

Three zones. The CODEOWNERS change, the check that enforces it, and the doc describing it have to land together or label-consistency fails on its own first run.

How to verify

make labels

Injected failures into a copy of the tree, all caught:

• catch-all moved below the specific lines → "'/services/connectors/' is listed ABOVE the '/services/' catch-all, so the catch-all overrides it (last match wins)"
• catch-all line deleted → "zone 'packages/other' has no owner: add a '/packages/' line…"

The new workflow was tested against a deliberately broken CODEOWNERS on a throwaway ref (created and deleted via the API). Both failure modes are reported with file, line and column:

::error file=.github/CODEOWNERS,line=31,col=8::Unknown owner on line 31: make sure
@definitely-not-a-real-user-9f3a exists and has write access to the repository
::error file=.github/CODEOWNERS,line=32,col=11::Invalid owner on line 32:

That test also caught a bug in my first draft: the API's message field is multi-line (it quotes the offending line and points a caret at the column), which broke both the markdown summary and the annotation. Fixed — summary takes the full message in a code block, annotation takes the first line only.

Checklist

• Branched off staging and targeting staging.
• make labels clean; all workflow YAML parses; the new run: block passes bash -n.
• Docs updated — the zone table's CODEOWNERS column, the "latent" note, and the opposite-resolution-order explanation.
• Python suites not run — this PR touches no Python.

Deployment notes

Nothing to do at deploy time. codeowners-valid is not a required status check; add it in branch protection if you want it to gate.

Anything you're unsure about

The /services/ and /packages/ lines change who gets auto-requested for an unregistered service — from the * fallback owner to the workspace catch-all owner. Identical today (both @qiuethan), diverges as soon as owners do. That's the intent, but it's the line to look hardest at.

🤖 Generated with Claude Code