@bongos/core 1.21.93 → 1.21.95

package/docs/design/project-startup-direction.md

@@ -54,6 +54,21 @@ This table replaces the blended flow's table below for every hub-side capability
 | Done: standup strip, the owner-only steps, invite | Part 03 on the same page: the GitHub checklist replaces the paged owner-only steps, then "is alive" with the invite box (once the hall is live, PS15) and the genesis door. |
 | Demo: fit check, settings, teammates, 30-day notice | The "Try a small demo instead" link opens the demo's people, hours, idea and teammates in place at the top of part 01, marks the page "demo", and shows the fit sentence; the rest of the page is unchanged. |
 
+### GitHub in one trip, as built (task 1004649)
+
+- **The trip.** "Connect GitHub ↗" posts the app manifest to GitHub. The manifest now carries a `setup_url` (the hub's `/provisioning/github-app/setup`). After the approval GitHub returns to the manifest callback, which waits until the runner has placed the app's keys and recorded its name, then sends the same tab straight to `github.com/apps/<app>/installations/new`. When GitHub will describe the repo to an anonymous caller (a public repo), the link is narrowed with `/permissions?suggested_target_id=<owner id>&repository_ids[]=<repo id>`, so the founder only has to confirm. After the install, GitHub sends them to the `setup_url` with the attempt's `state`, and that page hands them back to the checklist.
+- **The ticks are server facts, never clicks.** *Approve*: GitHub made the app and the runner placed its keys (the slug is recorded only after the placement write). *Install*: the runner asks GitHub `GET /repos/{owner}/{repo}/installation`, signed as the app with the app's own key. The `installation_id` GitHub appends to the `setup_url` is never trusted, because GitHub's docs warn it can be spoofed; it only makes the runner look again. *Builders can sign in*: the runner saw `auth_configured` on the project's `/api/bongos/healthz`. The root `/healthz` answers a plain "ok", and reading that one is why every setup used to be recorded as failed (task 1004577). *Command-line sign-in*: the runner starts a device sign-in with the app's client id, and GitHub does not refuse it with `device_flow_disabled`. The facts are rows in `provisioning_events`, so no new column was needed. The checklist is derived in `modules/provisioning/github-setup.js`; the runner's check is `scripts/gds/provision-github-setup.js`.
+- **Device flow cannot be switched on for the founder (spike, task 1004649).** GitHub's manifest parameters are `name`, `url`, `hook_attributes`, `redirect_url`, `callback_urls`, `setup_url`, `setup_on_update`, `request_oauth_on_install`, `public`, `default_permissions`, `default_events` and `description`, and none of them is device flow. The REST API for apps (`/app`, `/app/installations…`, `/app-manifests/{code}/conversions`) has no endpoint that changes an app's registration. GitHub's own guide says device flow has to be enabled in the app's settings first. So the fourth step is **optional**: it reads "Optional — turn it on later" with a link to the app's settings, ticks itself when the runner sees it on, and never holds back "connected" or "is alive". Web sign-in works without it, and the CLI falls back to a web token meanwhile (`scripts/gds/device-flow-help.js`).
+- **Left as seams for the sibling tasks.** The hand-back from any tab or device, and checking while the page is hidden (task 1004650, built: see below). The page already re-learns the checklist from the owner's instance read (`github_setup`), and that read never carries the state token. A personal or an organisation account (task 1004651). Resuming a stopped step, and a fixing button for every failure, including "check again" after the runner's two-hour window (task 1004652).
+
+### Coming back from any tab or device, as built (task 1004650)
+
+- **The server names the project.** The callback page and the setup page no longer send the founder to `/projects?view=new#ghstate=…` and trust the tab to know which project that was. They send them to `/api/bongos/provisioning/github-app/return?state=…`. That route looks the one-time state up, finds the project it was minted for, and, if the person signed in owns that project, sends them to `/projects?view=new&id=<project>#ghstate=…`. Nothing is read from browser storage, so approving on a phone, in another window or in a fresh tab lands on the right project at part 03.
+- **Only the owner lands.** Not signed in: through the web sign-in and back to the same return. Signed in as anyone else, an unknown or malformed state, or a project that is gone: one page that names no project ("This isn't your project"), the same for each case. There is no Archon override here. The state is still used once where it matters: only the manifest callback's code exchange uses it up, and the return route changes nothing.
+- **The page asks the server when its tab cannot say.** `GET /provisioning/github-app/resume?id=<project>` (signed in, own projects only) answers with what part 03 needs: id, slug, address, kind and repo. A hand-back named by the return route always opens that project's part 03. Without an id, the read names the founder's newest project whose GitHub checklist is not connected yet, if it was made or last tried within a week. Opening the create page later then reopens part 03 for it, unless the founder is typing a new project or clicked "New project" (then it is offered on the "still watching" line). "Start another project" sets it down for that tab. The hub's other views are unchanged.
+- **The page keeps checking while hidden.** Both of part 03's polls (the state-keyed checklist and the owner's project read) keep going while the tab is hidden, every 20 seconds instead of every 4 to 5. When the tab is seen again, a waiting check runs at once. They still stop when the founder leaves the create view (C8).
+- **Left for the sibling tasks.** A personal or an organisation account (task 1004651). Picking up a stopped step, and a fixing button for every failure (task 1004652); the resume read already reopens part 03 for a failed attempt, which is where those buttons go.
+
 ### Who builds it
 
 | Task | Builds |

package/docs/module-api-changelog.md

@@ -3023,5 +3023,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.21.91 with no explicit bump. run 37894940047. (task 1002620)
   1.21.93 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.21.92 with no explicit bump. run 37898035856. (task 1002620)
+  1.21.94 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.93 with no explicit bump. run 37901444360. (task 1002620)
+  1.21.95 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.94 with no explicit bump. run 37907054923. (task 1002620)
 ---------------------------------------------------------------------------
 ```