Roadmap: restrict code authorship to the AI engineer; humans keep observe/promote/issue rights

[devantler]

🤖 Generated by the Daily AI Engineer

Intent (maintainer direction, 2026-07-16)

Restrict code authorship in devantler-tech to the AI engineer, so the agent owns the code and the
products. The maintainer's retained surface is deliberately narrow:

• observe results,
• promote PRs from draft to ready-for-review (and merge),
• create and comment on issues, and comment on PRs.

Explicitly not retained: authoring code, creating PRs. In his words — "I will never be the one to
create them myself. You own the code and products, I own you."

Evidence — this codifies what already happens

• Of the last 40 merged PRs org-wide, zero were human-authored: 29 dependabot[bot], 5
  devantler (all agent-authored), 3 renovate[bot], 2 ksail-bot[bot], 1 botantler-1[bot].
• The org has exactly one human member (devantler). "Restrict all humans" therefore reduces to
  restricting a single account — the same account the agent currently operates as (see the blocker).
• Every product already ships through the draft-PR + promotion flow defined in the monorepo's
  AGENTS.md.

So this is mostly making the real policy enforceable, not changing how work happens.

🔴 Blocking prerequisite — the agent has no identity of its own

The agent commits and opens PRs as devantler (a User, the maintainer's own account) — this is
written into the engineering contract's trust gate, and every PR it authored today
(ksail#6164 @3317b55a9, ksail#5775 @12d894e02) carries that identity.

Consequence: restricting devantler from writing code disables the agent. The two are the same
principal on GitHub. No org ruleset can distinguish them, because there is nothing to distinguish.

This is the first child and a hard gate on everything else: mint a dedicated agent identity
(a GitHub App — the org already runs botantler-1[bot] and ksail-bot[bot], so the pattern exists),
migrate the agent's git/gh credentials to it, and update the trust gate + disclosure conventions to
match. Only once the agent is a distinct principal can "humans cannot write code" mean anything.

Second-order effects to handle in that child:

• The sibling ChatGPT/Codex instance also authors code (codex/* branches) and must be moved to
  its own identity, or it gets locked out too.
• CODEOWNERS is @devantler-tech/maintainers; review/ownership semantics need rechecking once the
  author is a bot.
• Some gh subcommands need broader scopes than the raw API (see cask-handoff-never-promotes) —
  the App's permission set must be validated against the real workflows, least-privilege, before cutover.

Target state (proposed)

Actor	Push to main	Create PR	Author code	Promote draft → ready	Merge	Issues / comments	Admin
AI engineer (new App identity)	❌ (never — via PR only)	✅	✅	❌ (gate stays human)	✅ (own, per merge policy)	✅	❌
Trusted release bots	❌	✅	✅ (programmed paths)	n/a	✅ (auto-merge)	✅	❌
devantler (human)	❌	❌	❌	✅	✅	✅	✅ (owner, break-glass)
Everyone else	❌	❌	❌	❌	❌	✅ (issues only)	❌

The promotion gate is preserved and becomes more load-bearing, not less. It is the only human
checkpoint in the agent's definition; the agent never self-promotes. Tightening human write access
must not touch it.

🔴 Break-glass is non-negotiable

The maintainer is the org owner and must retain an unconditional emergency path to change code — org
owners can always edit rulesets, so this is inherent, but it must stay explicit and tested, not
incidental.

Live evidence from today: an org ruleset change at 06:07Z froze every non-bot merge portfolio-wide
(monorepo#2184) — the agent could diagnose it but not fix it, because org config is out of its reach by
design. Had the maintainer also been locked out of authoring code, recovery would have depended on the
very agent that could not ship. A lockdown must never create a state only the agent can exit.

Concretely: keep the owner's ruleset-bypass, and add a documented, periodically-exercised break-glass
procedure. Note the current stack already relies on bypass_actors: [OrganizationAdmin:always].

Honest trade-off

This concentrates delivery on a single automated actor and raises the bus factor: if the agent is
wedged, misconfigured, or wrong, nothing ships until the maintainer intervenes through a path this
issue is deliberately preserving. The mitigation is the break-glass above plus the promotion gate —
the maintainer still approves every change before it merges. Ownership of the code and accountability
for it remain his; this issue delegates authorship, not responsibility.

Proposed children (decompose; each independently shippable)

1. Mint a dedicated agent identity (App), migrate credentials, update the trust gate + disclosure
   conventions. (hard gate on 2–5; includes the Codex sibling)
2. Document + test the break-glass path, before any restriction lands.
3. Restrict PR creation / code authorship to the agent + trusted bot identities (declaratively, via
   deploy/).
4. Restrict direct pushes for all human actors on every repo (extends the existing
   Require a pull request before merging).
5. Sweep repository-permission grants to least privilege for every non-agent principal; keep issue
   • comment + promote rights intact.

Order matters: 1 → 2 → (3,4,5). Landing 3–5 before 1 locks out the agent; landing them before 2
risks an unrecoverable state.

Acceptance criteria

• The agent authors code under an identity distinct from any human account; the sibling Codex
  instance likewise.
• No human account can push to a default branch or create a PR in devantler-tech.
• devantler can still: promote drafts, merge, create/comment on issues, comment on PRs.
• A documented break-glass procedure exists and has been exercised at least once.
• All of it expressed declaratively in .github deploy/ (per Roadmap: declarative GitHub-org-as-code — extend coverage & sustain the source of truth #56), not clicked in the UI.
• The promotion gate is unchanged — the agent still never self-promotes.

Open questions for the maintainer

1. Identity: new dedicated App, or reuse botantler-1[bot]? A fresh, purpose-named App is
   cleaner for audit and least privilege.
2. Should the agent keep merge rights, or should merge also collapse into your promote action
   (i.e. promotion == merge via auto-merge)? Today the contract has the agent merge its own promoted PRs.
3. Scope: all 19 repos at once, or pilot on one (e.g. ksail) first? A pilot is the lower-risk path
   and matches feature-flag-first delivery.

Size

L (epic). Child 1 is M and gates the rest.

Relates to #56 (declarative GitHub-org-as-code) and #69 (adopt remaining rulesets declaratively) —
the enforcement here should land through that same declarative source of truth.

[coderabbitai]

🔗 Related PRs

#74 - feat(rulesets): require the CodeRabbit review status check org-wide [merged]
#75 - revert(rulesets): drop the provider-uncreatable CodeRabbit required-check ruleset [merged]
#78 - feat(repositories): declare provider-upjet-unifi (net-new Library repo) [merged]
#88 - feat: archived-repo pattern + reusable-workflows archival groundwork [merged]
#92 - docs: complete agent and deploy contributor guidance [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!