# I1 GitHub App Publication Authority — 2026-08-24 **Status:** COMPLETE — source-side repository-scoped GitHub App publication authority landed **Branch:** `fix/github-app-publication-authority-20260824` **Worktree:** `/home/user/Projects/.worktrees/awp-github-app-publication-20260824` ## Goal Close the remaining source-side trusted-publication credential limitation without weakening I1 repository-scoped authority. AWP must support a short-lived GitHub App installation-token path in addition to the existing static fine-grained token-file path. No ambient `gh` token may become runtime publication authority. ## Baseline - Lane started from canonical `main@c076455e51d82f0f80b11c31b92460262e582517`. - Live dogfood already has one owner-authorized Codex account and healthy exact-source deployment, but no repository-scoped GitHub publication credential. - Debian3 ambient `gh` auth is broad and therefore explicitly not reused. - Current VCS and required-check providers already lease a `GitHubCredentialResolver` per operation; only control-plane composition was hard-wired to a static token file. - Concurrent main advanced by I7a machine-enrollment recovery commits only; this lane owns disjoint publication-auth paths and will converge current main before final testing. ## Security contract - GitHub App tokens are minted per installation and narrowed to exactly one configured repository. - Requested permissions are only those needed by I1 trusted publication/readback: Contents write, Administration read, Checks read, Commit statuses read. - The minted token is verified through `/installation/repositories`; anything exposing zero or multiple/different repositories fails closed. - App private key stays behind a file reference; key material is never written into PostgreSQL, environment values, logs, receipts, workspaces or AgentRuns. - Static token-file and GitHub App modes are mutually exclusive and partial App configuration fails closed. - No fallback to `gh auth`, workstation credentials, Systray/Overdeck credentials, or any ambient token. ## Completion ledger - [x] P1 Add provider-level GitHub App JWT/installation-token credential resolver. - [x] P2 Narrow minted token to one repository and verify scope before lease use. - [x] P3 Add control-plane all-or-none publication credential composition. - [x] P4 Add closed bootstrap allowlist keys and dogfood config-file wiring. - [x] P5 Add provider/config/deployment/security regressions. - [x] P6 Document exact repository-scoped GitHub App setup and required permissions. - [x] P7 Merge latest canonical main and resolve only publication-lane conflicts. - [x] P8 Run focused tests, `bash -n`, lint/format on authorized buildbox. - [x] P9 Run full exact-head `pnpm check`. - [x] P10 Fresh race check against main/dogfood and converge compatible work. - [x] P11 Push exact green branch, fast-forward canonical main, fetch back and verify equality. ## Guardrails - Do not create/install a GitHub App or mint a real production token in this lane. - Do not copy the broad Debian3 `gh` token into AWP. - Do not touch the Codex login/account session. - Do not mark I1 GOLIVE accepted from source tests alone. ## Convergence checkpoint - Partial implementation checkpoint `8c609dd` preserved the provider/control-plane/deploy seam before convergence. - Canonical main then advanced with I7a interrupted-enrollment recovery only (`81ad0ff`, `c3f07fd`); those changes were path-disjoint and merged cleanly before publication-auth tests/docs were completed. - Added provider tests for JWT shape/signature, exact repository/permission token minting, token caching and overbroad-scope refusal. - Added control-plane configuration tests for disabled/static/App/partial/dual authority modes. - Extended deployment-boundary security regression to require App file references while rejecting private-key value projection. - Dogfood README now documents the exact GitHub App permission set and three local secret files. ## Verification and landing - Focused candidate verification on Debian2: - provider/control-plane builds PASS; - `bash -n infra/dogfood/deploy-debian3.sh` PASS; - GitHub App provider/config/deployment/config-authority regressions **4 files / 20 tests PASS**; - ESLint PASS; repository formatting normalized. - One Debian2 full run hit unrelated 5-second PostgreSQL test timeouts under host load. Immediate isolated rerun of `persistence.test.ts` + `verification-merge-gate.test.ts` passed **22/22**; no publication-auth failure occurred. No unrelated timeout was weakened or changed. - Fresh Debian1 exact-head full gate at `be1edcf` passed **77 files / 325 tests**, then canonical main advanced with authorized I2 Planner provider-catalog/config-definition work. - Current main (`d8b97b8`) merged cleanly into the publication lane. Overlapping `server.ts`/`packages/config` changes auto-merged while preserving both provider-catalog/versioned-definition behavior and the publication credential factory/App bootstrap keys. - Final converged semantic candidate `f327573bba54c6aa4a82b7cddc17c8b27f3770d2` passed a fresh Debian1 full `pnpm check`: - **77 test files / 330 tests PASS**, 5 files / 9 tests skipped; - typecheck/lint/build PASS; - architecture **6/6 PASS**; - dependency-cruiser **0 violations** across 136 modules / 268 dependencies; - Prettier PASS. - Immediate post-gate fetch proved `origin/main@d8b97b8` and `origin/ops/i1-dogfood-deploy@144bfe6` were both ancestors of `f327573`; no main-only/dogfood-only durable work was outside the candidate. - Canonical `origin/main` fast-forwarded normally to exact green `f327573`; fetch-back returned the same SHA. No force push or credential provisioning was used. ## Resulting credential contract AWP now supports either: 1. an existing repository-scoped static fine-grained token file; or 2. the preferred GitHub App installation path: App ID + installation ID + PEM file + canonical repository key. The App path signs a bounded RS256 JWT, mints a short-lived installation token narrowed to repository `awp` and minimal I1 permissions, then verifies the lease exposes exactly `platform-modules/awp` before trusted publication/required-check operations may use it. Dual/partial configuration fails closed and there is no ambient `gh auth` fallback. Real GitHub App creation/installation/private-key provisioning remains an owner/admin trust boundary and was not fabricated by this source lane. I1 GOLIVE remains separate and unaccepted until the real authenticated owner journey runs. This final closure edit is documentation-only and receives an exact-head gate before its own SHA is advanced to canonical main.