Skip to content

chore: update CODEOWNERS for the usik-luke -> usik-luke-trl rename - #19

Merged
usik-luke-trl merged 1 commit into
mainfrom
chore/codeowners-rename
Oct 6, 2026
Merged

usik-luke-trl merged 1 commit into
mainfrom
chore/codeowners-rename

Conversation

@usik-luke-trl

Copy link
Copy Markdown
Contributor

@usik-luke was renamed to @usik-luke-trl. GitHub redirects the user's URLs, but CODEOWNERS does not follow a rename — and the old handle no longer resolves at all:

$ gh api users/usik-luke
{"message":"Not Found","status":"404"}

Every rule in the file silently lost one of its three owners while still looking correct. CODEOWNERS ignores unknown handles with no error and no warning.

No damage yet, only because require_code_owner_review is still false on the ruleset. Turning it on would have enforced two owners where three were intended — and the symptom would have been hard to trace back to this.

Changes

  • .github/CODEOWNERS — 12 lines
  • docs/community/LAUNCH_PLAN.md:125 — owner column
  • Header note explaining the failure mode, since the next rename will look just as harmless

Verified

All three handles resolve: guks-trl, hongjoonahn-tri, usik-luke-trl.

Worth knowing: the collaborator list has moved too — trl-bot → bot-trl, hoon-trl added, devholic no longer listed. Nothing else in the repo references those.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K599fUWZZYdiL4ekUq4Vhs

GitHub redirects a renamed user's URLs but CODEOWNERS does not follow the rename,
and @usik-luke no longer resolves at all -- the API returns 404 rather than a
redirect. Every rule in the file silently lost one of its three owners while
continuing to look correct, because CODEOWNERS ignores unknown handles with no error
and no warning.

No damage yet only because require_code_owner_review is still false on the branch
ruleset. Turning it on would have enforced two owners where three were intended,
and the cause would have been hard to find from the symptom.

12 lines in CODEOWNERS plus the owner column in the launch plan. The header now says
what bit us, since the next rename will look exactly as harmless.

Verified all three handles resolve: guks-trl, hongjoonahn-tri, usik-luke-trl.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K599fUWZZYdiL4ekUq4Vhs
@usik-luke-trl
usik-luke-trl merged commit 9e8796b into main Oct 6, 2026
6 checks passed
@usik-luke-trl
usik-luke-trl deleted the chore/codeowners-rename branch October 6, 2026 05:43
usik-luke-trl added a commit that referenced this pull request Oct 13, 2026
hongjoonahn-tri became hongjoonahn-trl. That is the second owner rename in a week --
usik-luke -> usik-luke-trl was #19 six days ago -- and both left every rule in the
file one owner short while continuing to look correct, because CODEOWNERS ignores
unknown handles with no error, no warning and no annotation.

Both were found by accident. Rather than rely on noticing a third time,
tools/check_codeowners.py resolves every handle against the API and fails CI when one
404s. Wired into community-check.yml, which already runs on every push and PR.

The checker treats network trouble and non-404 errors as unverified rather than dead,
so a flaky API cannot fail the build, and skips @org/team handles since a default
token cannot read org membership.

Verified both directions: it failed on hongjoonahn-tri before the fix and passes on
the three current handles after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K599fUWZZYdiL4ekUq4Vhs
usik-luke-trl added a commit that referenced this pull request Oct 13, 2026
hongjoonahn-tri became hongjoonahn-trl. That is the second owner rename in a week --
usik-luke -> usik-luke-trl was #19 six days ago -- and both left every rule in the
file one owner short while continuing to look correct, because CODEOWNERS ignores
unknown handles with no error, no warning and no annotation.

Both were found by accident. Rather than rely on noticing a third time,
tools/check_codeowners.py resolves every handle against the API and fails CI when one
404s. Wired into community-check.yml, which already runs on every push and PR.

The checker treats network trouble and non-404 errors as unverified rather than dead,
so a flaky API cannot fail the build, and skips @org/team handles since a default
token cannot read org membership.

Verified both directions: it failed on hongjoonahn-tri before the fix and passes on
the three current handles after.


Claude-Session: https://claude.ai/code/session_01K599fUWZZYdiL4ekUq4Vhs

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant