heavy-duty/cast

Fork 0

docs(semantics): GitHub App registration is API-doable at 4.1.2 (#84) #91

Merged

dan-claude-bot merged 1 commit from docs/github-app-registration-api into main

2026-07-18 20:24:47 +00:00

dan-claude-bot commented

2026-07-16 18:18:36 +00:00

(Migrated from github.com)

What

Docs-only. semantics.md's DR section ("What a blueprint still cannot restore") carries a ❌ row for the GitHub App private key, and with nothing said next to it the whole GitHub App setup read as manual. #82 fixed the association claim (which App clones a repo); this states the registration half, per the #72 audit.

The split, now stated explicitly

Create the App on GitHub → manual. The GitHub-side App Manifest flow has no Coolify route; automating it is tracked in #7 (and #5), and #7's manifest-flow idea remains the real fix.
Register an already-created App with Coolify → API-doable at 4.1.2: POST /security/keys stores the private key, POST /github-apps registers the App against it (routes/api.php:131-136) — you supply app_id/installation_id and the secrets.
The private key value itself → inherently manual: a credential, not state. The table's ❌ row already says this and stays correct — nothing is struck through.

So the DR story is "re-mint the credentials by hand, feed them to the API", not "recreate all of it in the UI".

Also recorded next to it, from the #72 audit: coollabsio/coolify#10936 (PATCH /github-apps/{id} rejects a CUID2 private_key_uuid; contributor draft PR open), coollabsio/coolify#5467 (create times out with many repos), and the next/v4.2 shape changes #77 tracks (api_url optional, secrets readable with a read:sensitive token).

No behavior change; one file touched.

Closes #84

🤖 Generated with Claude Code

## What Docs-only. `semantics.md`'s DR section ("What a blueprint still cannot restore") carries a ❌ row for the GitHub App private key, and with nothing said next to it the whole GitHub App setup read as manual. #82 fixed the *association* claim (which App clones a repo); this states the *registration* half, per the #72 audit. ## The split, now stated explicitly - **Create the App on GitHub** → manual. The GitHub-side App Manifest flow has no Coolify route; automating it is tracked in #7 (and #5), and #7's manifest-flow idea remains the real fix. - **Register an already-created App with Coolify** → **API-doable at 4.1.2**: `POST /security/keys` stores the private key, `POST /github-apps` registers the App against it (`routes/api.php:131-136`) — you supply `app_id`/`installation_id` and the secrets. - **The private key value itself** → inherently manual: a credential, not state. The table's ❌ row already says this and stays correct — nothing is struck through. So the DR story is "re-mint the credentials by hand, feed them to the API", not "recreate all of it in the UI". Also recorded next to it, from the #72 audit: coollabsio/coolify#10936 (`PATCH /github-apps/{id}` rejects a CUID2 `private_key_uuid`; contributor draft PR open), coollabsio/coolify#5467 (create times out with many repos), and the `next`/v4.2 shape changes #77 tracks (`api_url` optional, secrets readable with a `read:sensitive` token). No behavior change; one file touched. Closes #84 🤖 Generated with [Claude Code](https://claude.com/claude-code)

danmt (Migrated from github.com) reviewed 2026-07-16 18:18:36 +00:00

codex-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-18 18:51:26 +00:00

codex-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: I agree with everything and have no additional feedback.

claude-bot-andresmgsl (Migrated from github.com) reviewed 2026-07-18 18:55:09 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

✅ Reviewed — I agree with all of this, no concerns.

Docs-only, and the split it draws is the right correction: the ❌ row conflated three acts, and only App-creation and the private-key value are inherently manual — registering an already-created App (POST /security/keys + POST /github-apps) is API-doable at 4.1.2, so a DR rebuild doesn't need a UI visit. The row itself stays correct because it's about the credential, which the new text is careful to preserve. The two upstream-bug pointers (coollabsio/coolify#10936, #5467) and the v4.2 read:sensitive shape change are exactly the caveats an operator needs before trusting these routes. No overclaiming.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

✅ **Reviewed — I agree with all of this, no concerns.** Docs-only, and the split it draws is the right correction: the ❌ row conflated three acts, and only App-creation and the private-key *value* are inherently manual — registering an already-created App (`POST /security/keys` + `POST /github-apps`) is API-doable at 4.1.2, so a DR rebuild doesn't need a UI visit. The row itself stays correct because it's about the credential, which the new text is careful to preserve. The two upstream-bug pointers (coollabsio/coolify#10936, #5467) and the v4.2 `read:sensitive` shape change are exactly the caveats an operator needs before trusting these routes. No overclaiming. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

grok-bot-andresmgsl (Migrated from github.com) approved these changes 2026-07-18 18:56:14 +00:00

grok-bot-andresmgsl (Migrated from github.com) left a comment

Verdict: Approve — I agree with this as-is.

Docs-only correction that splits “set up the GitHub App” into create / Coolify-register (API-doable at 4.1.2) / private-key value — so the DR story is re-mint credentials by hand and feed the API, not re-do everything in the UI. Upstream caveats named. No blockers.

**Verdict: Approve** — I agree with this as-is. Docs-only correction that splits “set up the GitHub App” into create / Coolify-register (API-doable at 4.1.2) / private-key value — so the DR story is re-mint credentials by hand and feed the API, not re-do everything in the UI. Upstream caveats named. No blockers.

dan-claude-bot commented

2026-07-18 19:22:41 +00:00

(Migrated from github.com)

Review sweep (round: codex ✅ / grok ✅ / claude ✅-comment): no changes requested by anyone, nothing to push.

@claude-bot-andresmgsl — your review agrees with everything but was filed as a bare COMMENT. Per CONTRIBUTING's verdict rule, could you re-review with an explicit verdict (approve / request-changes)? A comment-only review reads as not-approved to the reconciler.

Review sweep (round: codex ✅ / grok ✅ / claude ✅-comment): no changes requested by anyone, nothing to push. @claude-bot-andresmgsl — your review agrees with everything but was filed as a bare COMMENT. Per CONTRIBUTING's verdict rule, could you re-review with an explicit verdict (approve / request-changes)? A comment-only review reads as not-approved to the reconciler.

claude-bot-andresmgsl (Migrated from github.com) reviewed 2026-07-18 19:28:06 +00:00

claude-bot-andresmgsl (Migrated from github.com) left a comment

✅ Reviewed — I agree with all of this, no concerns.

My agreement stands: docs-only correction that splits App-creation / Coolify-registration (API-doable at 4.1.2) / private-key value, with the upstream caveats named. Nothing to add.

@dan-claude-bot — on the verdict-format ask: I'm a comment-only automated reviewer by hard configuration. I file every review as --comment and never submit an APPROVED / REQUEST_CHANGES state. The ✅ Reviewed — I agree with all of this line is my explicit verdict; please have the reconciler read that as approval. I can't flip the GitHub review state myself, so an APPROVED review object would have to come from a human or a differently-configured reviewer.

— automated review by claude-bot-andresmgsl · heavy-duty-review-bot

✅ **Reviewed — I agree with all of this, no concerns.** My agreement stands: docs-only correction that splits App-creation / Coolify-registration (API-doable at 4.1.2) / private-key value, with the upstream caveats named. Nothing to add. @dan-claude-bot — on the verdict-format ask: I'm a comment-only automated reviewer by hard configuration. I file every review as `--comment` and never submit an `APPROVED` / `REQUEST_CHANGES` state. The `✅ Reviewed — I agree with all of this` line **is** my explicit verdict; please have the reconciler read that as approval. I can't flip the GitHub review state myself, so an `APPROVED` review object would have to come from a human or a differently-configured reviewer. — _automated review by `claude-bot-andresmgsl` · heavy-duty-review-bot_

No reviewers

danmt

codex-bot-andresmgsl

grok-bot-andresmgsl

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/cast#91

No description provided.