chore: add CODEOWNERS file

[ralphbean]

Summary

• Adds CODEOWNERS with * @fullsend-ai/core to match fullsend repo
• Companion to ruleset update enabling require_code_owner_review and merge queue

Context

Ruleset on fullsend-ai/agents has been updated to match fullsend-ai/fullsend:

• ✅ require_code_owner_review: true
• ✅ merge queue enabled
• ⏭️ required_status_checks deferred (no test/commit-lint workflows yet)
• ⏭️ bypass actor for renovate-fullsend deferred (app may need repo access granted first)

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Add repository-wide CODEOWNERS entry for @fullsend-ai/core

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Add a CODEOWNERS file to require code-owner review for all paths.
• Set wildcard ownership to @fullsend-ai/core to match the fullsend repo ruleset.

High-Level Assessment

The following are alternative approaches to this PR:

1. Directory-scoped CODEOWNERS

• ➕ Allows different teams to own different areas of the repo
• ➕ Reduces review load on a single team for unrelated changes
• ➖ Requires upfront ownership mapping and ongoing maintenance
• ➖ May not align with current branch protection intent of always requiring @fullsend-ai/core review

2. Start with wildcard + add exceptions over time

• ➕ Keeps current protection behavior intact
• ➕ Enables incremental refinement without blocking the ruleset rollout
• ➖ Still routes all reviews through @fullsend-ai/core until exceptions are added

Recommendation: The wildcard owner approach is appropriate for enforcing require_code_owner_review immediately and matching the referenced fullsend repo setup. If review load becomes a bottleneck, evolve toward directory-scoped ownership or add targeted exceptions incrementally.

Files changed (1) +2 / -0

Other (1) +2 / -0

CODEOWNERSAdd wildcard CODEOWNERS mapping to @fullsend-ai/core +2/-0

Add wildcard CODEOWNERS mapping to @fullsend-ai/core

• Introduces a CODEOWNERS file that assigns ownership of all paths (*) to @fullsend-ai/core, enabling repository-wide code-owner review enforcement.

CODEOWNERS

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 4:58 PM UTC · Completed 5:02 PM UTC
Commit: 48f9832 · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (1)

Context used

✅ Compliance rules (platform): 55 rules

✅ Skills: 4 invoked

  code-review

  code-implementation

  pr-review

  docs-review

1. Protected CODEOWNERS modified 📜 Skill insight § Compliance

Description

This PR adds/modifies CODEOWNERS, which is a protected governance/infrastructure path and must not
be auto-approved. Ensure explicit human review and add a linked issue/ADR if required by your
governance process.

Code

CODEOWNERS[R1-2]

+# These users have approval access to all resources (wildcard)
+* @fullsend-ai/core

Evidence

The compliance checklist requires raising a finding for any PR that modifies protected
governance/infrastructure paths, explicitly including CODEOWNERS. The diff adds a new CODEOWNERS
file with a wildcard rule, so this requirement is triggered.

CODEOWNERS[1-2]
Skill: pr-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`CODEOWNERS` is a protected governance/infrastructure file; changes here must be explicitly justified and require human review (must not be auto-approved).

## Issue Context
This PR introduces a wildcard ownership rule (`* @fullsend-ai/core`). Even if intended, governance changes should carry an explicit authorization reference (issue/ADR) and be routed for human approval.

## Fix Focus Areas
- CODEOWNERS[1-2]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Misleading CODEOWNERS comment 🐞 Bug ⚙ Maintainability

Description

The header comment says code owners have "approval access", but CODEOWNERS only defines who is
requested/required for review (it does not grant repo permissions). This can mislead maintainers
about what the wildcard entry actually enforces when code-owner review is enabled.

Code

CODEOWNERS[1]

+# These users have approval access to all resources (wildcard)

Evidence

The added comment explicitly states "approval access", while the file content is only a CODEOWNERS
pattern mapping and does not control repository permissions.

CODEOWNERS[1-2]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The CODEOWNERS file header comment claims the listed owners have "approval access", which is inaccurate/misleading because CODEOWNERS does not grant permissions; it defines ownership for review-routing / required code owner review.

### Issue Context
This PR introduces a wildcard rule (`* @fullsend-ai/core`). With required code-owner review enabled, this will require/request review from that team, but it still does not change repository access rights.

### Fix Focus Areas
- CODEOWNERS[1-1]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Protected codeowners modified 📜 Skill insight § Compliance

This PR adds/modifies CODEOWNERS, which is a protected governance/infrastructure path and must not
be auto-approved. Ensure explicit human review and add a linked issue/ADR if required by your
governance process.

Agent Prompt

## Issue description
`CODEOWNERS` is a protected governance/infrastructure file; changes here must be explicitly justified and require human review (must not be auto-approved).

## Issue Context
This PR introduces a wildcard ownership rule (`* @fullsend-ai/core`). Even if intended, governance changes should carry an explicit authorization reference (issue/ADR) and be routed for human approval.

## Fix Focus Areas
- CODEOWNERS[1-2]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Misleading codeowners comment 🐞 Bug ⚙ Maintainability

The header comment says code owners have "approval access", but CODEOWNERS only defines who is
requested/required for review (it does not grant repo permissions). This can mislead maintainers
about what the wildcard entry actually enforces when code-owner review is enabled.

Agent Prompt

### Issue description
The CODEOWNERS file header comment claims the listed owners have "approval access", which is inaccurate/misleading because CODEOWNERS does not grant permissions; it defines ownership for review-routing / required code owner review.

### Issue Context
This PR introduces a wildcard rule (`* @fullsend-ai/core`). With required code-owner review enabled, this will require/request review from that team, but it still does not change repository access rights.

### Fix Focus Areas
- CODEOWNERS[1-1]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[fullsend-ai-review]

Review

Findings

High

• [protected-path] CODEOWNERS — This PR modifies CODEOWNERS, which is a protected path requiring human approval. The PR has no linked issue providing explicit authorization for modifying governance/infrastructure files. A human reviewer from @fullsend-ai/core must approve this PR.
  Remediation: Link this PR to an issue that authorizes the CODEOWNERS addition, or obtain explicit human reviewer approval.

Previous run

Review — Approve

Scope: Adds a CODEOWNERS file assigning @fullsend-ai/core as the required reviewer for all paths.

Correctness

No issues. The CODEOWNERS syntax is valid: the * glob matches all files, @fullsend-ai/core follows the @org/team-slug format, and the file is placed at the repository root (one of the three locations GitHub recognizes). No conflicting CODEOWNERS files exist elsewhere in the repo.

Security

No issues. The file contains no secrets, no injection surface, and no hidden Unicode or bidirectional text. The permission effect is restrictive — it requires review approval from @fullsend-ai/core for every PR — which is the standard bootstrapping pattern for code-owner review enforcement.

Intent & Coherence

The change is a mechanical governance configuration that mirrors the existing fullsend-ai/fullsend repo setup, as documented in the PR body. Scope authorization is implicit for this class of infrastructure change.

Style, Docs, Cross-Repo Contracts

No findings. The file follows standard CODEOWNERS conventions. No existing documentation references need updating. No exported interfaces or cross-repo contracts are affected.

---

Protected paths detected — this PR modifies files under one or more
protected paths. The review agent cannot approve PRs that touch these paths.
A human reviewer must approve this PR.

Protected files in this PR:

• CODEOWNERS

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:52 PM UTC · Completed 6:00 PM UTC
Commit: cd788f5 · View workflow run →

[fullsend-ai-review]

See the review comment for full details.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 10:33 PM UTC · Completed 10:37 PM UTC
Commit: cd788f5 · View workflow run →

[fullsend-ai-retro]

Retro: PR #27 — chore: add CODEOWNERS file

PR #27 was the initial setup of the fullsend-ai/agents repository, adding 97 files (14,285 lines) including agent definitions, skills, harness configs, policies, schemas, scripts, and documentation. It was authored and merged by a human maintainer (Ralph Bean).

No agent workflow to evaluate. This PR was not created by the code agent, was not triaged by the triage agent, and there is no evidence of review agent involvement. As an initial repo bootstrap PR by a maintainer, it falls outside the scope of agent workflow retrospective analysis.

Observability limitation: The GitHub API token available to this retro run was invalid, preventing workflow run tracing, PR comment/review analysis, and duplicate issue searches. The repository was also available only as a shallow clone (single merge commit), limiting git history analysis. These constraints prevented deeper investigation, but given the nature of the PR (human-authored repo initialization), additional data would be unlikely to surface agent workflow improvement opportunities.

No proposals filed — this is a valid outcome when the workflow went well or when there is no agent workflow to evaluate.