ajbeck · Sep 27, 2026 · Sep 27, 2026 · Sep 27, 2026
diff --git a/.github/workflows/go.yml b/.github/workflows/go.yml
@@ -1,7 +1,6 @@
 name: Go
 
 on:
-  workflow_call:
   pull_request:
     branches: [main]
     types: [opened, synchronize, reopened, ready_for_review]

diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml
@@ -12,29 +12,25 @@ concurrency:
   cancel-in-progress: false
 
 jobs:
-  validate:
-    uses: ./.github/workflows/go.yml
-
   release:
-    needs: validate
     runs-on: ubuntu-latest
     # Repository writes use the scoped App token, not GITHUB_TOKEN.
     permissions: {}
     steps:
       - name: Check App configuration
         env:
-          APP_CLIENT_ID: ${{ vars.RELEASE_PLEASE_CLIENT_ID }}
+          APP_CLIENT_ID: ${{ secrets.RELEASE_PLEASE_CLIENT_ID }}
           APP_PRIVATE_KEY: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }}
         run: |
           if [ -z "$APP_CLIENT_ID" ] || [ -z "$APP_PRIVATE_KEY" ]; then
-            echo '::error::Set RELEASE_PLEASE_CLIENT_ID and RELEASE_PLEASE_PRIVATE_KEY; see docs/releases.md.'
+            echo '::error::Grant this repository access to the RELEASE_PLEASE_CLIENT_ID and RELEASE_PLEASE_PRIVATE_KEY organization secrets; see docs/releases.md.'
             exit 1
           fi
       - name: Create repository-scoped App token
         id: app-token
         uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
         with:
-          client-id: ${{ vars.RELEASE_PLEASE_CLIENT_ID }}
+          client-id: ${{ secrets.RELEASE_PLEASE_CLIENT_ID }}
           private-key: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }}
           owner: ${{ github.repository_owner }}
           repositories: ${{ github.event.repository.name }}

diff --git a/docs/decisions/0024-release-automation.md b/docs/decisions/0024-release-automation.md
@@ -4,6 +4,54 @@ Status: accepted and locally implemented on 2026-09-21. The user approved
 GitHub App authentication and initial v0.1.0 following the recommended v0 policy.
 Release Please, its GitHub Action and PR checks against main are user-directed.
 
+## Revision: Organization App credentials (2026-09-27)
+
+The user created and installed astrocompute-release-please and directed that both
+its Client ID and private key be organization secrets. Use organization Actions
+secrets RELEASE_PLEASE_CLIENT_ID and RELEASE_PLEASE_PRIVATE_KEY, with selected
+repository access for go-lambda-edge. Read both through the secrets context;
+remove the old repository credential entries after provisioning and verifying
+organization access so a repository key cannot override the new organization key.
+This supersedes the original repository variable/private-key-secret setup below.
+
+The new key was validated without printing it. App-authenticated read-only API
+calls confirmed the supplied Client ID and key identify astrocompute-release-please
+and that installation 165295608 includes this repository with Contents, Issues
+and Pull requests write permissions. The installation is not suspended. No
+installation token or release was created by these checks.
+
+[GitHub's organization secret documentation](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)
+supports selected-repository access and requires admin:org for CLI management.
+Both organization secrets were provisioned and their selected-repository access
+verified. The obsolete repository private-key secret and Client ID variable were
+removed. Local actionlint and whitespace checks pass. Remote token creation and
+release execution remain pending until the workflow change merges.
+
+## Revision: PR-only validation (2026-09-27)
+
+The user rejected repeating the PR validation after merge. This supersedes the
+main-validation dependency in accepted A and the original implementation below.
+Run the Go matrix only for PRs against main, including generated release PRs.
+On main pushes, run only credential setup and Release Please. Remove the unused
+workflow_call entry point. This avoids a second full matrix for each merge.
+
+The alternative was retaining validation of the exact main push. The chosen
+workflow relies on reviewing passing PR checks before merge; direct main pushes
+will not run Go validation. No branch-protection change is part of this revision.
+The [official release action example](https://github.com/googleapis/release-please-action/tree/v5.0.0)
+also runs Release Please directly on main pushes; a reusable Go validation job
+is a repository policy choice, not an action requirement.
+
+The [first main run](https://github.com/asteroid-computing/go-lambda-edge/actions/runs/36281181036)
+passed all four repeated validation jobs, then failed in App token creation.
+GET /repos/asteroid-computing/go-lambda-edge/installation returned 404. The
+organization installation listing returned total_count=0. The App credentials
+are provisioned, but the App needs installation on the organization with access
+to this repository and the permissions documented in the release guide.
+[GitHub's installation lookup](https://docs.github.com/en/rest/apps/apps#get-a-repository-installation-for-the-authenticated-app)
+looks up the authenticated App's installation for the specified repository.
+Release Please never ran; removing duplicate validation does not fix installation.
+
 ## Evidence
 
 The existing Go workflow already runs formatting, race tests, vet, module

diff --git a/docs/decisions/README.md b/docs/decisions/README.md
@@ -32,5 +32,5 @@ Keep related decisions small enough to review and implement independently.
 | [0021: Authorization rules](0021-authorization-rules.md) | Accepted; rules, examples and local validation implemented | What rule API, IAM/JWT predicates, failure semantics and consumer resolution/dispatch boundaries should authz expose? |
 | [0022: Streaming writer review](0022-streaming-writer-review.md) | Accepted; writer, public entry points and local validation complete; SDK deployment gate retained | Should streaming omit inferred lengths, how should empty Content-Encoding affect sniffing, and what SDK evidence remains missing? |
 | [0023: Consumer readiness](0023-consumer-readiness.md) | R1–R5 accepted; local implementation complete; external release prerequisites open | What complete consumer example, test support, deferred scope and release preparation should follow the implemented packages? |
-| [0024: Release automation](0024-release-automation.md) | Accepted; credentials provisioned and PR CI passed; main release execution pending | How should release PRs, validation, credentials and initial versioning work? |
+| [0024: Release automation](0024-release-automation.md) | Accepted; PR-only validation and organization credentials; App installation verified, release execution pending | How should release PRs, validation, credentials and initial versioning work? |
 | [0025: Main-branch protection](0025-main-branch-protection.md) | Proposed; awaiting owner review | Should the existing four CI checks and PR workflow be enforced before merging to main? |
diff --git a/docs/plan.md b/docs/plan.md
@@ -449,21 +449,29 @@ qualifications remain open; no release publication or AWS deployment occurred.
 Release automation follow-up (2026-09-21): the user selected Release Please and
 its GitHub Action, plus checks on PRs against main. [Decision 0024](decisions/0024-release-automation.md)
 records the approved GitHub App credential and initial v0.1.0, with pre-major
-versioning. Release Please will run after reusable main validation; PRs continue
-to use the same Go checks. Local wiring and validation are complete: both workflows
+versioning. The original main-validation dependency is superseded by the
+2026-09-27 user direction: Go validation runs on PRs only, including release PRs;
+main pushes run only release automation. Local wiring and validation are complete: both workflows
 pass actionlint, release JSON passes the bundled schema, and existing Go jobs are
 unchanged. See the [release guide](releases.md).
 
 Subsequent authorized setup and publication of the working branch are complete:
-the App client ID variable and private-key secret are configured, and
-[PR #1](https://github.com/asteroid-computing/go-lambda-edge/pull/1) is open.
+the new App Client ID and private key are configured as organization Actions
+secrets with access granted to this repository, and
+[PR #1](https://github.com/asteroid-computing/go-lambda-edge/pull/1) merged at
+24f7686 on 2026-09-27.
 [The PR run at f6a2624](https://github.com/asteroid-computing/go-lambda-edge/actions/runs/35619720590)
 passed both Go test jobs and both Linux build jobs, verified on 2026-09-27. The action
 review verified all four latest stable releases and pinned checkout/setup-go to
 their release commits; those aliases already selected the same versions. App
-installation, permissions and the main-branch release path still need execution
-evidence. No release was published, and the license and deployment qualifications
-remain open.
+installation initially blocked the main run with a 404 during repository lookup.
+The owner subsequently installed astrocompute-release-please; read-only checks
+confirmed the new credentials and repository installation permissions. Both
+organization secrets and their repository access are verified, and the old
+repository credentials have been removed. The workflow now reads both values
+from secrets. Token creation and Release Please execution still need a successful
+run after merge. No release was published, and the license and deployment
+qualifications remain open.
 
 ## Findings carried forward from the Beakley review
 

diff --git a/docs/release-readiness.md b/docs/release-readiness.md
@@ -18,25 +18,32 @@ automation does not resolve the remaining readiness items below.
 
 ## Verified readiness (2026-09-27)
 
-[PR #1](https://github.com/asteroid-computing/go-lambda-edge/pull/1) is open on
-`work/edge-foundation`. All four jobs in
+[PR #1](https://github.com/asteroid-computing/go-lambda-edge/pull/1) merged on
+2026-09-27. All four jobs in
 [the run for f6a2624](https://github.com/asteroid-computing/go-lambda-edge/actions/runs/35619720590)
 passed: test (1.27.0), test (1.27.x), lambda-build (arm64) and lambda-build (amd64).
 This provides GitHub evidence for formatting, race tests, vet, module
 verification, external consumer checks and both Linux builds. Later commits
-require their own passing checks. The same workflow validates main pushes before
-Release Please runs.
-
-The repository variable RELEASE_PLEASE_CLIENT_ID and encrypted Actions secret
-RELEASE_PLEASE_PRIVATE_KEY are provisioned; their names were verified on
-2026-09-27 without reading the private key. No branch protection was configured.
+require their own passing PR checks. Per the user's 2026-09-27 direction, Go
+validation runs only on PRs; main pushes run only release automation.
+
+The organization Actions secrets RELEASE_PLEASE_CLIENT_ID and
+RELEASE_PLEASE_PRIVATE_KEY are provisioned with selected-repository access for
+go-lambda-edge. Secret metadata and repository access were verified on 2026-09-27;
+the obsolete repository variable and private-key secret were removed. The new
+key and Client ID were verified against the astrocompute-release-please App and
+its repository installation using read-only API calls without printing credentials.
+Its installation grants all three required write permissions. No branch
+protection was configured.
 
 ## Outstanding evidence and owner choices
 
-After the foundation PR merges, verify main validation, App token creation and
-the generated v0.1.0 release PR and its checks. Credential provisioning does not
-establish App installation, granted permissions or successful release execution.
-Obtain passing validation for the actual release commit before publication.
+The [first main run](https://github.com/asteroid-computing/go-lambda-edge/actions/runs/36281181036)
+passed the original repeated validation but failed at App token creation: the
+repository installation lookup returned 404. The owner subsequently installed
+astrocompute-release-please, and installation access is now verified. After the
+workflow credential migration merges, verify token creation, the generated v0.1.0
+release PR and its checks. Release Please has not yet executed successfully.
 
 The owner's license and copyright holder remain undecided. No license, repository
 visibility change, release tag or release publication has been performed.

diff --git a/docs/releases.md b/docs/releases.md
@@ -9,14 +9,12 @@ decision. The Go toolchain directive is independent of the module version.
 
 1. Opening or updating a PR against main runs the Go workflow. Reopening a PR
    or marking it ready for review also runs checks. Superseded PR runs cancel.
-2. A push to main starts Release Please's workflow. It calls the same Go workflow
-   for formatting, race tests, vet, module verification, external consumption and
-   Linux arm64/amd64 builds. No separate push-triggered Go run duplicates it.
-3. Only after validation succeeds does the release job mint a GitHub App token
-   and run Release Please. It creates or updates a release PR with CHANGELOG.md
-   and the version manifest. The App's PR events can run CI automatically.
-4. Review and merge that release PR when ready to publish. After the main checks
-   succeed, Release Please creates the version tag and GitHub release. There is
+2. A push to main starts only the release job. It mints a GitHub App token and
+   runs Release Please without repeating the Go checks completed on the PR.
+3. Release Please creates or updates a release PR with CHANGELOG.md and the
+   version manifest. The App's PR events run the same Go validation as other PRs.
+4. Review the release PR and its passing checks, then merge when ready to publish.
+   Release Please creates the version tag and GitHub release. There is
    no automatic merge, binary deployment or separate package-registry upload.
 
 Release runs share one concurrency group and do not cancel a running release.
@@ -32,24 +30,28 @@ prefix. CHANGELOG.md is created by the first release PR.
 
 ## GitHub App setup
 
-Use an organization-owned App installed on `asteroid-computing/go-lambda-edge`.
+Use `astrocompute-release-please`, installed on `asteroid-computing/go-lambda-edge`.
 Its repository permissions must include:
 
 - Contents: read and write.
 - Pull requests: read and write.
 - Issues: read and write, for release labels and related operations.
 
-In this repository's **Settings → Secrets and variables → Actions**, configure:
+In the organization's **Settings → Secrets and variables → Actions**, configure
+both values as organization Actions secrets and grant `go-lambda-edge` access:
 
 | Kind | Name | Value |
 | --- | --- | --- |
-| Variable | `RELEASE_PLEASE_CLIENT_ID` | The App's Client ID |
-| Secret | `RELEASE_PLEASE_PRIVATE_KEY` | Its PEM private key |
+| Organization secret | `RELEASE_PLEASE_CLIENT_ID` | The App's Client ID |
+| Organization secret | `RELEASE_PLEASE_PRIVATE_KEY` | Its PEM private key |
 
-Organization-level settings are also usable when explicitly granted to this
-repository. Use the Client ID, not the installation ID; the current token action
-prefers `client-id` over its deprecated `app-id` input. Store the private key as
-an Actions secret, not in this repository.
+Use selected-repository access for this setup; grant other repositories access
+when they adopt the same automation. Both workflow inputs use the `secrets`
+context. Remove any same-name repository secrets when migrating: a repository
+secret takes precedence over an organization secret. The old repository Client
+ID variable is no longer used. Use the Client ID, not the installation ID; the
+token action prefers `client-id` over its deprecated `app-id` input. Keep the
+private key out of this repository.
 
 The workflow explicitly requests only this repository and the three permissions
 above. The token action revokes its short-lived token after the job. The release
@@ -62,7 +64,11 @@ The workflow does not create/install the App, provision secrets, change rulesets
 or bypass branch protection. Configure required PR checks using the check names
 observed in the first successful run, and review any existing rules that restrict
 the App's release-branch or version-tag writes. PR checks use the proposed merge
-result; main checks validate the push that triggered the release workflow.
+result. Validation runs only on PRs; direct main pushes do not run Go checks.
+
+If token creation fails with a 404 looking up the repository installation,
+check that the configured App is installed on the organization and includes this
+repository. Storing its Client ID and private key does not install the App.
 
 ## Commit and release review