docs: Add ADR 074 with a single-auth

docs/ADRs/0033-per-repo-installation-mode.md

@@ -66,6 +66,20 @@ Use one GitHub App for triage, code, review, and fix roles to simplify per-repo
 
 **Rejected**: GitHub suppresses events triggered by pushes made with any `GITHUB_TOKEN` or GitHub App installation token, to prevent infinite loops. Two separate Apps work because a push made with App-A's token _does_ generate events that trigger workflows authenticated as App-B. The fix→review loop requires the coder/fix agent to push commits that trigger review — if both roles share one App, the push token matches the workflow's App and the event is silently suppressed, breaking the feedback cycle. At minimum, coder and review must be separate Apps.
 
+_Clarification (2026-07):_ GitHub's event-suppression is specific to the
+built-in `GITHUB_TOKEN`; App installation tokens and PATs are documented as
+exempt, so a shared App's pushes/labels would trigger downstream workflows
+normally — the fix→review loop this alternative worried about is not
+actually broken by sharing one App. The one thing a single App genuinely
+cannot do is approve-and-merge a PR it authored (`422 Can not approve your
+own pull request`), regardless of token type. A single App can still cover
+triage, code, and review as long as review stops at a `COMMENT`-type verdict
+and a human merges — see [ADR 0075](0075-lite-auth-mode.md),
+which documents exactly this as the opt-in path for per-repo Lite Auth
+Mode. Separate Apps per role remain the right call at org scale, but for
+[ADR 0007](0007-per-role-github-apps.md)'s least-privilege/blast-radius
+reasoning, not because sharing one App is technically broken.
+
 ### Alternative 3: Per-repo as a separate codebase
 
 Build a standalone per-repo tool or action that does not share infrastructure with per-org fullsend.

docs/ADRs/0075-lite-auth-mode.md

@@ -0,0 +1,61 @@
+---
+title: "75. Lite auth mode"
+status: Accepted
+relates_to:
+  - agent-architecture
+  - security-threat-model
+topics:
+  - identity
+  - per-repo
+  - least-privilege
+---
+
+# 75. Lite auth mode
+
+Date: 2026-07-22
+
+## Status
+
+Accepted
+
+<!-- ADRs are point-in-time records, but not fully frozen after acceptance.
+     Minor annotations are welcome: cross-references to related ADRs, short
+     notes linking to newer decisions, or clarifying remarks. However, do not
+     substantially rewrite the Context, Decision, or Consequences sections. If
+     the decision itself needs to change, write a new ADR that supersedes this
+     one. For evolving design narrative, use docs/architecture.md. -->
+
+## Context
+
+Per-repo installation ([ADR 0033](0033-per-repo-installation-mode.md)) historically required provisioning per-role GitHub Apps ([ADR 0007](0007-per-role-github-apps.md)) and a token mint ([ADR 0029](0029-central-token-mint-secretless-fullsend.md)), creating nontrivial setup friction. While the Per-role App + Mint architecture remains the default for scaled, highly isolated environments, some per-repo adopters need a zero-ceremony opt-in path using the default `secrets.GITHUB_TOKEN`.
+
+A design spike investigated using `secrets.GITHUB_TOKEN` (`github-actions[bot]`). Because GitHub suppresses events triggered by `GITHUB_TOKEN`, standard stage handoffs (`labeled`, `pull_request_review.submitted`) cannot initiate subsequent workflow steps natively. However, `workflow_dispatch` is exempt from event suppression and can be invoked securely to chain stages without over-privileged scopes (maintaining `contents: read` for triage and review, per `internal/mintcore/github.go`).
+
+Additionally, native auto-merge requires `APPROVE` reviews, which fail with a 422 error if the same identity that authored the PR (e.g., `GITHUB_TOKEN`) tries to approve it. Exchanging a Bring-Your-Own-App (BYOA) PEM for a separate token bypasses this restriction, but exposes the PEM to prompt-injection or runner-compromise threats if not properly isolated.
+
+## Options
+
+- **`GITHUB_TOKEN` with native event triggers:** Rejected because GitHub suppresses downstream workflows triggered by `GITHUB_TOKEN` events.
+- **`GITHUB_TOKEN` with `repository_dispatch` handoffs:** Rejected because `repository_dispatch` requires `contents: write` on triage/review, violating least-privilege role definitions.
+- **`GITHUB_TOKEN` with `workflow_dispatch` handoffs:** Chosen. Only requires `actions: write` (already held), preserving `contents: read` for triage/review.
+- **Single self-owned App with native handoffs (no mint):** Rejected for default lite mode because storing the PEM as a static secret introduces standing-credential risk.
+- **Bring Your Own App (BYOA) for Review:** Chosen for auto-merge. Bypasses the 422 self-approval error by using a dedicated Reviewer App token for the review approval step.
+
+## Decision
+
+Introduce **Lite Auth Mode** as an opt-in alternative to the default Per-role GitHub App + Mint architecture for per-repo installations. In Lite Auth Mode:
+
+1. **Authentication:** The default `GITHUB_TOKEN` is used for triage, code, and review steps instead of a mint-provided token.
+2. **Handoffs:** Stage handoffs use `workflow_dispatch` (`gh workflow run`) rather than `repository_dispatch` or native events. This requires only `actions: write`, allowing triage and review to maintain least-privilege `contents: read`. `post-review.sh` and `post-retro.sh` will also be updated to use `workflow_dispatch` to close pipeline loops.
+3. **Auto-Merge (BYOA):** To bypass GitHub's self-approval 422 restriction, operators can provide a dedicated "Reviewer" App ID and PEM as repository secrets (`FULLSEND_REVIEWER_APP_ID`, `FULLSEND_REVIEWER_APP_PEM`).
+4. **BYOA Security Architecture:** To mitigate prompt-injection threats, the Reviewer App token **MUST** be minted in an isolated workflow step or job *after* the LLM agent has safely exited, ensuring the PEM is never exposed to the LLM execution context.
+
+## Consequences
+
+- Per-repo installations can adopt Lite Auth Mode with zero GitHub-credential secrets, though GCP inference credentials are still required.
+- Auto-merging PRs requires provisioning a dedicated Reviewer App to bypass the 422 self-approval restriction.
+- Isolating the Reviewer App token exchange in a post-execution job eliminates the threat of exposing the PEM to an untrusted LLM context.
+- Triage and review jobs maintain least-privilege `contents: read` scopes, while only code and fix carry `contents: write`.
+- The reusable-dispatch workflow and shim configurations require updating to handle `workflow_dispatch` inputs and routing hints.
+- Per-role least-privilege scoping is lost at the identity level, but GHA job-level permissions still restrict the ephemeral `GITHUB_TOKEN`.
+- Lite Auth Mode remains a strictly opt-in mechanism, preserving the Per-role GitHub App + Mint mode as the default for scaled installations.

docs/architecture.md

@@ -182,6 +182,7 @@ Identity is not the same as trust. An agent's identity lets it authenticate to e
 - Standalone mint deployment: `cmd/mint/` provides a self-contained HTTP server that uses direct JWKS verification and filesystem PEM storage instead of GCP infrastructure. It shares the `internal/mintcore/` library with the GCF mint and adds support for custom role permissions and a fallback proxy to an upstream mint. Custom role permissions live in mintcore (not `cmd/mint/`) so that `RolePermissionsFor`, `HasRole`, and `CreateInstallationToken` return a unified view without callers needing to distinguish built-in from custom roles. The GCF mint never calls `RegisterCustomRolePermissions`, so the code is inert there. See the [standalone mint guide](guides/infrastructure/standalone-mint.md).
 - Hosted public community mint: steady-state deployment on Cloudflare Workers (JWKS + WAF + single ops console), with interim GCP Cloud Function acceptable until the Worker port is production-ready. Trust policy (`ALLOWED_ORGS=*`, upstream-only workflow provenance) is in [ADR 0059](ADRs/0059-public-mint-mode-with-wildcard-allowlists.md); deployment, edge security, monitoring, and phasing are in [ADR 0068](ADRs/0068-public-community-mint-architecture.md). Enrollment is installing the shared Apps—no per-org mint env registration ([#1145](https://github.com/fullsend-ai/fullsend/issues/1145)).
 - Named privilege levels: each role defines ordered named levels (`read`, `write`), where each level's permissions are a superset of preceding levels. `read` for built-in roles is derived by downgrading `*:write` permissions to their `read` counterparts. The mint API accepts an optional `level` field (default `read`); omitting it produces narrower tokens than the current behavior. `write` is defined as the current max permission set for each built-in role. `CUSTOM_ROLE_PERMISSIONS` auto-detects a multi-level JSON shape alongside the existing flat format, with mixed format supported per role. The harness `privilege_levels` flag maps run-stages to levels; omitting it defaults to `write`, preserving backward compatibility for existing harness configurations ([ADR 0073](ADRs/0073-named-mint-privilege-levels.md)).
+- Single-identity Lite Auth Mode: an opt-in alternative to the default Per-role GitHub App + Mint architecture for per-repo installations. Uses the default `GITHUB_TOKEN` for triage, code, and review, with `workflow_dispatch` (not label/review events) for stage handoffs — chosen over `repository_dispatch` because it needs only `actions: write`, letting triage and review keep `contents: read` per the canonical Go role definitions; merging requires a human approval by default — a BYOA escape hatch for fully autonomous auto-merge is available. Trades away per-role least-privilege scoping at the identity level; org-scoped or highly-automated installs use the default full App + mint stack ([ADR 0075](ADRs/0075-lite-auth-mode.md)).
 
 One concrete implementation option is [`oidcx`](https://github.com/oxidecomputer/oidcx): a service that accepts OIDC identity tokens and exchanges them for short-lived access tokens. It can mint tokens scoped to selected GitHub repositories and permissions, or to selected Oxide silos and permissions, and it also ships with a GitHub Action wrapper. In a Fullsend deployment, this can be used by the sandbox entrypoint to narrow a broad GitHub App identity down to only the specific permissions an agent needs for the current run.