@bongos/core 1.21.95 → 1.21.97

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

@@ -67,7 +67,28 @@ This table replaces the blended flow's table below for every hub-side capability
 - **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.
+- **Left for the sibling tasks.** A personal or an organisation account (task 1004651, built: see below). 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.
+
+### A personal or an organisation account, as built (task 1004651)
+
+- **Two choices, one picker.** Part 03 shows the mockup's "On my account" / "On an organisation" select beside Connect GitHub, while Connect is offered. Part 02's Code row has the same picker under the new repo's name ("Whose account"), so a new repo can be made under an organisation too. The founder's own account is the default in both, and it sends exactly what it always did: `{}` to mint the app, `{name}` to make the repo. Part 03 starts on the organisation the new repo went to, when it went to one.
+- **The organisations come from GitHub.** `GET /github/orgs` lists them with whether the founder can make apps there. Only an organisation's owners can; one the founder only belongs to (or is still invited to) is listed with the reason and cannot be picked. "Another organisation…" opens a typed name with a **Check** button (`GET /github/orgs/<name>`).
+- **The scope limit.** The hub's sign-in asks GitHub for `read:user repo`, not `read:org`, so GitHub may refuse to show the founder's memberships. Then the list falls back to the organisations the founder's repos sit in, with the role unknown, and the typed name is always there. A role GitHub did not give is said as such ("GitHub didn't tell us your role…"), never guessed, and GitHub's own page still refuses a non-owner. Asking for `read:org` at sign-in is the fix for a full list; it is `src/bongos/auth-config.js`'s call (a protected surface), so it was not made here.
+- **The server checks the name, never the page's copy.** The mint route takes `{ account: 'org', org }`, checks the name against GitHub's login rules (letters, digits and single inner dashes, up to 39), and builds `github.com/organizations/<org>/settings/apps/new`. `account: 'org'` with no usable organisation is refused (`org_required`) rather than quietly made personal. The organisation is recorded as a `github-app-org` event, and the checklist reads give it back as `app_org`, so the app's settings link points at the organisation from any tab or device. The repo route makes the repo with `POST /orgs/{org}/repos`, private and empty like the personal one. GitHub's refusals come back as a 409 with the reason (the organisation restricts which apps may act for it; the founder may not create repos there; no such organisation), never as a 403, which the page reads as "sign in again".
+- **The install follows the repo.** The install step already targets the repo's owner (the project's `target_ref`), so an organisation-owned repo installs there. Proof: `tests/github_org_account.mjs`.
+
+### Picking up where it stopped, as built (task 1004652)
+
+- **Never a second app.** The mint route reads the latest attempt first. A link still waiting on GitHub is handed back, with the same state (a second click, "Reopen GitHub", another device). Once GitHub has approved an app for the project, no new link is made (`app_exists`, or `github_in_progress` while the runner converts it). A new link is minted only when nothing was made on GitHub: the link lapsed, or the runner never took it up.
+- **Every state has its sentence and its button.** The server names what picking it up does (`pick_up`, from `pickUpFor` in `modules/provisioning/github-setup.js`), and the stopped step carries it:
+  - waiting on GitHub → "Reopen GitHub", the same link posted again. A tab that opened behind the window, or was closed before the approval, is noticed within a few seconds (it used to take 90).
+  - the link lapsed, or GitHub setup never started → "Connect GitHub ↗", a fresh link (nothing was made).
+  - approved, but the conversion stopped while GitHub's code is under an hour old → "Pick up where it stopped" re-queues the same attempt with the code it holds.
+  - approved, but the app's keys never reached the project (code spent or too old) → "Send it to the platform team" files a blocker from the page; GitHub offers no way to delete an app or re-issue its keys by API, so only a person can finish it.
+  - keys placed but sign-in unconfirmed → the runner asks the project again on every tick in its checking window, and the attempt becomes done with the same app. After the window: "Pick up where it stopped", plus "Send it to the platform team" for a project that still will not answer.
+  - the install never confirmed after the window → the mockup's "GitHub stopped before the app was installed on your repo. Nothing is lost, and no second app will be made." with "Pick up where it stopped ↗", which opens the same app's install page and asks the runner to look again.
+  - device flow still off after the window → "Turned it on? Check again".
+- **Check again re-opens the window.** `POST /provisioning/instances/:id/github-app/pick-up` (the owner only) re-queues a young conversion or records a `github-app-check-requested` event, which re-opens the runner's two-hour window exactly as an install report does. A runner placement that fails after GitHub's conversion now says the code is spent, and GitHub's 404 on a conversion drops the dead code, so a pick-up never re-queues a code that cannot convert. Proof: `tests/github_pick_up.mjs`.
 
 ### Who builds it
 

package/docs/module-api-changelog.md

@@ -3027,5 +3027,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         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)
+  1.21.96 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.95 with no explicit bump. run 37914843597. (task 1002620)
+  1.21.97 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.96 with no explicit bump. run 37920956545. (task 1002620)
 ---------------------------------------------------------------------------
 ```