Skip to content

Document the normative authorization model #6860

Description

@ralphbean

What happens

ADR 0054 records why agent dispatch uses effective repository permissions instead of author_association, but the authorization contract has since spread across the ADR, normalized-event docs, agent docs, and workflow implementations.

The original ADR describes a write+ gate, while later changes allow triage+ for observation work and introduce exceptions for labels, bots, PR authors, and lifecycle events. It is difficult to tell from one place which rules are architectural and which are implementation details.

We also do not clearly state the broader principle that relationship or contribution-history fields such as author_association are not evidence of current authority.

What should happen

We should have a concise, living normative document that defines:

  • the forge-neutral role ordering: admin > maintain > write > triage > read > none/external
  • how forge-native permissions map into those roles
  • the default thresholds of triage+ for observation and write+ for mutation
  • fail-closed behavior for unknown roles, custom roles, and lookup failures
  • the documented exceptions for trusted platform actions, bots, and implicitly authorized actions such as label application
  • that association and contribution-history fields are not authorization evidence
  • where the platform gate is enforced, including whether CEL may tighten but never weaken it

ADR 0054 should remain the historical decision and rationale, with the living contract linked from it and from the normalized-event documentation.

Context

ADR 0054 is clear about the original decision, but appended notes and later implementation changes now carry part of the effective model. A single normative contract would let dispatch implementations, forge adapters, harness authors, and reviewers evaluate authorization behavior against the same rules.

Metadata

Metadata

Assignees

Labels

component/dispatchWorkflow dispatch and triggerscomponent/docsUser-facing documentationdocumentationpriority/mediumNormal priority, plan for next cycleready-to-codeTriaged and ready for the code agentsecuritySecurity threat model and related concerns

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions