@bongos/core 1.21.95 → 1.21.96

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

@@ -67,7 +67,15 @@ 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`.
 
 ### Who builds it
 

package/docs/module-api-changelog.md

@@ -3027,5 +3027,7 @@ 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)
 ---------------------------------------------------------------------------
 ```