Category: forge parity
Gap: grep -rni CODEOWNERS src/ returns nothing. reviewDecision — the field that would carry required-review state — is hard-coded undefined on GitLab, Bitbucket, and Gitea (gitlabListData.ts:177,314, bitbucketListData.ts:144, giteaListData.ts:127), so even the read-only signal only works on GitHub.
Why it matters: "Who must approve this, and are they blocking?" decides whether a PR row in triage is actionable. Without it, coco ui's triage view ranks a PR that needs one specific reviewer identically to one that needs nothing. On three of four forges coco can't even say whether review is satisfied.
Sketch: Two halves. (a) src/git/codeowners.ts — parse .github/CODEOWNERS / CODEOWNERS / docs/CODEOWNERS with minimatch (already a dependency) and map changed paths to owners; surface owners in the pullRequest and diff surfaces and as a pr create reviewer suggestion. (b) Populate reviewDecision for the other three forges: GitLab approval rules (/approval_state), Gitea /reviews, Bitbucket participant approvals — the raw data is already fetched by the detail fetchers, just not normalized into the list row.
Already-there leverage: minimatch is a dependency; pullRequestDetailData.ts and its three siblings already fetch approval/review payloads for the inspector, so half of (b) is a normalization pass over data already in memory. headerChips.ts already renders review state for GitHub.
Effort notes / risks: M. CODEOWNERS is a deceptively fiddly format (ordering, negation, team handles that can't be resolved without an API call) — v1 should resolve patterns and show raw handles without expanding teams. Populating reviewDecision per forge must keep the GitHub vocabulary as the normalized target so surfaces stay provider-blind.
Extracted from a repo audit performed 2026-07 (the audit doc it came from was proposed via an unmerged docs PR).
Category: forge parity
Gap:
grep -rni CODEOWNERS src/returns nothing.reviewDecision— the field that would carry required-review state — is hard-codedundefinedon GitLab, Bitbucket, and Gitea (gitlabListData.ts:177,314,bitbucketListData.ts:144,giteaListData.ts:127), so even the read-only signal only works on GitHub.Why it matters: "Who must approve this, and are they blocking?" decides whether a PR row in triage is actionable. Without it,
coco ui's triage view ranks a PR that needs one specific reviewer identically to one that needs nothing. On three of four forges coco can't even say whether review is satisfied.Sketch: Two halves. (a)
src/git/codeowners.ts— parse.github/CODEOWNERS/CODEOWNERS/docs/CODEOWNERSwithminimatch(already a dependency) and map changed paths to owners; surface owners in thepullRequestanddiffsurfaces and as apr createreviewer suggestion. (b) PopulatereviewDecisionfor the other three forges: GitLab approval rules (/approval_state), Gitea/reviews, Bitbucket participant approvals — the raw data is already fetched by the detail fetchers, just not normalized into the list row.Already-there leverage:
minimatchis a dependency;pullRequestDetailData.tsand its three siblings already fetch approval/review payloads for the inspector, so half of (b) is a normalization pass over data already in memory.headerChips.tsalready renders review state for GitHub.Effort notes / risks: M. CODEOWNERS is a deceptively fiddly format (ordering, negation, team handles that can't be resolved without an API call) — v1 should resolve patterns and show raw handles without expanding teams. Populating
reviewDecisionper forge must keep the GitHub vocabulary as the normalized target so surfaces stay provider-blind.Extracted from a repo audit performed 2026-07 (the audit doc it came from was proposed via an unmerged docs PR).