Document Forgejo bot user vs GitHub App identity

coilyco-ops commented

2026-07-09 18:05:04 +00:00

Member

Write specific-purpose docs that distinguish the Forgejo automation bot from the GitHub automation App.

Kai's correction:

Forgejo side: coilyco-ops is a real Forgejo bot user with tokens, org/team grants, summons, and repo permissions.
GitHub side: this is not a bot user. It is a GitHub App with installations and short-lived per-repo installation access tokens.

Why this matters:

The GitHub <=> Forgejo coordination hub belongs in infrastructure, but the two auth models have different failure modes, audit trails, permissions, and rotation paths.
Calling both of them bots will cause wrong operator decisions, especially around repo creation, PR attribution, token rotation, and external comments.
ward and inbox issues are currently splitting responsibility across infrastructure#489, infrastructure#491, ward#823, ward#830, and inbox#184.

Docs should cover:

Identity model: Forgejo bot user vs GitHub App installation.
Durable secrets: Forgejo bot password/token SSM paths vs GitHub App id/private key SSM paths.
Minted credentials: Forgejo PATs vs GitHub installation tokens.
Scope and permissions: org/team grants on Forgejo vs per-installation repo permissions on GitHub.
Attribution: visible actor names in commits, comments, PRs, and issue activity.
Rotation and revocation paths.
Which repo owns what: infrastructure owns credentials and hub state, ward owns bounded verbs/dispatch, inbox owns personal migration policy.

Acceptance:

A doc exists in infrastructure and is linked from docs/FEATURES.md or another appropriate index.
Existing docs that say "GitHub bot" are corrected to "GitHub App" where that is the actual model.
infrastructure#491 and infrastructure#489 are linked from the doc.

Write specific-purpose docs that distinguish the Forgejo automation bot from the GitHub automation App. Kai's correction: * Forgejo side: `coilyco-ops` is a real Forgejo bot user with tokens, org/team grants, summons, and repo permissions. * GitHub side: this is not a bot user. It is a GitHub App with installations and short-lived per-repo installation access tokens. Why this matters: * The GitHub <=> Forgejo coordination hub belongs in infrastructure, but the two auth models have different failure modes, audit trails, permissions, and rotation paths. * Calling both of them bots will cause wrong operator decisions, especially around repo creation, PR attribution, token rotation, and external comments. * ward and inbox issues are currently splitting responsibility across `infrastructure#489`, `infrastructure#491`, `ward#823`, `ward#830`, and `inbox#184`. Docs should cover: * Identity model: Forgejo bot user vs GitHub App installation. * Durable secrets: Forgejo bot password/token SSM paths vs GitHub App id/private key SSM paths. * Minted credentials: Forgejo PATs vs GitHub installation tokens. * Scope and permissions: org/team grants on Forgejo vs per-installation repo permissions on GitHub. * Attribution: visible actor names in commits, comments, PRs, and issue activity. * Rotation and revocation paths. * Which repo owns what: infrastructure owns credentials and hub state, ward owns bounded verbs/dispatch, inbox owns personal migration policy. Acceptance: * A doc exists in infrastructure and is linked from `docs/FEATURES.md` or another appropriate index. * Existing docs that say "GitHub bot" are corrected to "GitHub App" where that is the actual model. * `infrastructure#491` and `infrastructure#489` are linked from the doc.

coilyco-ops referenced this issue

2026-07-09 18:05:13 +00:00

Make infrastructure the GitHub <=> Forgejo coordination hub #489

coilyco-ops referenced this issue

2026-07-09 18:05:13 +00:00

Provision GitHub App identity and secret plumbing for fleet git hygiene #491

coilyco-ops commented

2026-07-09 18:07:06 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-infrastructure-492 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T18:07:04Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/infrastructure#492 · branch issue-492 · harness codex · workflow direct-to-main
Run: engineer-codex-infrastructure-492 · ward v0.493.0 · dispatched 2026-07-09T18:07:04Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-infrastructure-492` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:07:04Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/infrastructure#492` · branch `issue-492` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-infrastructure-492` · ward `v0.493.0` · dispatched `2026-07-09T18:07:04Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 18:09:42 +00:00

Author

Member

Correction from Kai: the GitHub App auth is already configured. The likely gap is that the configuration is not mounted or surfaced into the runtime paths that need it. Also, model this as a multi-part GitHub App configuration, not as a single token like Forgejo. The current minting path documents app-id + private-key, but the operator-facing docs should also account for installation scope, permission configuration, and any App/client/webhook metadata needed by the specific GitHub flow. The implementation should first audit what is already in SSM/GitHub and then wire/mount the existing config, not assume a new GitHub identity must be created.

Correction from Kai: the GitHub App auth is already configured. The likely gap is that the configuration is not mounted or surfaced into the runtime paths that need it. Also, model this as a multi-part GitHub App configuration, not as a single token like Forgejo. The current minting path documents `app-id` + `private-key`, but the operator-facing docs should also account for installation scope, permission configuration, and any App/client/webhook metadata needed by the specific GitHub flow. The implementation should first audit what is already in SSM/GitHub and then wire/mount the existing config, not assume a new GitHub identity must be created.

coilyco-ops commented

2026-07-09 18:13:04 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: review skipped; review summary: skipped because ~/.ward/config.yaml default
felt: straightforward docs pass with one size-cap rerun
confidence: high
surprises: pre-commit pylint needed UV_PYTHON_INSTALL_DIR set in this container
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: review skipped; review summary: skipped because ~/.ward/config.yaml default felt: straightforward docs pass with one size-cap rerun confidence: high surprises: pre-commit pylint needed UV_PYTHON_INSTALL_DIR set in this container follow-ups: none </details>

coilyco-ops added the

headless

P2

labels

2026-07-09 21:46:10 +00:00

coilyco-ops added

consult

and removed

headless

labels

2026-07-10 08:59:53 +00:00