@bongos/core 1.19.1044 → 1.19.1046

package/docs/adr/0337-the-hub-account-is-the-person-a-hall-account-is-their-seat-in-one-project.md

@@ -4,6 +4,7 @@
 - **Date:** 2026-09-25
 - **Deciders:** the owner (direction given 2026-09-24 while reviewing goal 1000110 Wave 1; the D4 calls answered 2026-09-25), Claude.
 - **Task:** [task 1004255](https://cloudbongos.com/builders#/task/1004255) (goal 1000110, Working area 2: account creation, management & community)
+- **Amended:** 2026-09-25 evening, D5 — the owner's four placement calls from the Wave 2 review sheet, recorded by [task 1003444](https://cloudbongos.com/builders#/task/1003444).
 - **Amends:** [ADR 0336](0336-a-guilds-record-is-the-sum-of-what-its-members-already-show.md) D5 (superseded by D4.4 below) and D8 (the map ranks by the rounded total); `docs/specs/<redacted>.md` D8 (D4.1); the privacy spec's "`hide_stats` beats everything" rule, for guild totals only, and only for a member who was told and left counting on (D4.4). ADR 0336 D4 (a guild's size is its public roster length) is **unchanged**.
 - **Relates to:** [ADR 0141](<redacted>.md) (the hub is the identity provider; authority stays local), [ADR 0217](0217-rank-gates-inviting-not-viewing.md) (rank gates inviting, not viewing), [ADR 0334](0334-the-recruiting-directory-lists-a-hidden-builder-by-name.md) (the name-only recruiting tier), [ADR 0335](0335-an-invite-is-a-pre-approved-row-on-the-projects-own-instance.md) (an invite is the project's own row), [ADR 0255](0255-a-public-lists-ordering-is-part-of-its-payload.md) (a public list is ordered only by what it publishes)
 
@@ -21,9 +22,9 @@ Goal 1000110 Wave 1 (2026-09-24) showed what that costs. R15 ([task 1002291](htt
 
 | A surface goes on… | when what it shows is… | e.g. |
 |---|---|---|
-| **the HUB** (`modules/public-landing/`, `modules/platform-identity/`) | the person across projects, or more than one project | the people directory, community (leaderboards, search, builder of the week), guilds, connections, recruiting and scouting, the public profile, platform-account settings (D4.3) |
+| **the HUB** (`modules/public-landing/`, `modules/platform-identity/`) | the person across projects, or more than one project | the people directory, community (leaderboards, search, builder of the week), guilds, connections (primary home, D5.4), recruiting and scouting, the public profile (with "Projects you build on" in its own view, D5.3), platform-account settings (D4.3), project invitations and the "join a project" field on their own page (D5.2) |
 | **the HALL** (the project's own instance, `modules/hall-ui/`) | this project's people and work | `/roster` (Builders), the project console (invites, admission, ranks), tasks, goals, in-project activity and achievements |
-| **both** | a person-centred view that has a useful in-project cut | "Builders you may know" (D4.2) |
+| **both** | a person-centred view that has a useful in-project cut | "Builders you may know" (D4.2); connections, where the hall's tab shows only your connections who also build on that project (D5.4) |
 
 `modules/status-ui/` is neither: it is the public status dashboard at `status.<apex>`, not the hall. A hall page may *link* to the hub for the cross-project view, but it does not rebuild it. When a task's text places a cross-project surface in the hall, the task is re-scoped before anyone claims it, never built as written.
 
@@ -35,6 +36,8 @@ D1 decides where pages go. It moves no authority. ADR 0141's line stands: the hu
 
 The hall's `/people` retires ([task 1003444](https://cloudbongos.com/builders#/task/1003444)). Its cross-project job, including ADR 0334's two-tier recruiting directory, moves to the one hub community page ([task 1003363](https://cloudbongos.com/builders#/task/1003363)). ADR 0334's predicates move unchanged; only the page that renders them changes. `/roster` ("Builders") stays as the in-project directory and stops linking out to `/people`.
 
+**Amended by D5.1:** `/people` is deleted now, without waiting for [task 1003363](https://cloudbongos.com/builders#/task/1003363). Until that page ships, `/people` (and its legacy door `/scouting`) redirects to `/roster`.
+
 ### D4 — The owner's calls from the re-scope
 
 1. **Hidden builders open to recruiters: the recruiter panel is recruiter-only, and public search is unchanged.** A builder who hides their numbers but stays open to recruiters appears in ADR 0334's name-only panel (login, display name, avatar) on the hub community page. The panel is shown only to a signed-in viewer that the recruiting door admits, which ADR 0334 defines as a project owner or a holder of `project.curate`. The public builder search (`GET /community/search`, [task 1002979](https://cloudbongos.com/builders#/task/1002979)) keeps listing such a builder by name with no numbers, the same as their public profile page already does. Private accounts stay out of both, and the private-and-discoverable sliver keeps its archon floor (ADR 0217 D2). This amends community-tab spec D8's "to every viewer identically": the public view stays the same for every viewer, and a signed-in recruiter also sees the panel. It adds no new disclosure class.
@@ -55,6 +58,15 @@ The hall's `/people` retires ([task 1003444](https://cloudbongos.com/builders#/t
 
    The notice and the switch exist for this reason. A non-public member is told that their numbers count, and can turn it off for any guild they don't trust. This relaxes the owner-signed privacy rule "`hide_stats` beats everything" (privacy spec D2) for **guild totals only**, and only for a member who was told and left counting on. Every other surface keeps the rule.
 
+### D5 — The owner's calls of 2026-09-25 evening (Wave 2 review)
+
+Reviewing the Wave 2 sheet, the owner made four placement calls. They amend the D1 table above.
+
+1. **Delete the hall's People page now.** The hall already has a Builders page (`/roster`), so `/people` goes without waiting for the hub community page ([task 1003363](https://cloudbongos.com/builders#/task/1003363)). The owner accepted that cross-project search and the recruiter name-only panel (D4.1) are absent until that page ships. [Task 1003444](https://cloudbongos.com/builders#/task/1003444) deleted the page, its nav entry and its page gate; `/people` and `/scouting` redirect to `/roster`. The recruiting API (`GET /scouting`, its own route gate and ADR 0334's predicates) is unchanged and waits for the hub page to render it.
+2. **A builder's project invitations get their own hub page.** The invitations a builder has received (today a section of the hub's `/projects` page) move to a standalone hub page, and the "join a project" field (a project address and an optional note) moves there with them.
+3. **"Projects you build on" moves to the builder's own profile, own view only.** Today a section of the hub's `/projects` page; a builder will see it on their own profile, and a visitor will not.
+4. **Connections live on the hub first.** The hub is the primary home for connections. A project hall's connections tab becomes project-specific: it shows only your connections who also build on that project.
+
 ## Consequences
 
 - Goal 1000110 is re-scoped against D1 before its Wave 2, in one owner-run script. Retargeted tasks carry a description append citing this ADR. Duplicates of the hub community page merge into task 1003363. Dependency edges are re-pointed before any merge or abandon, so no dependent is left on a dead edge. The goal's module scope widens to `public-landing` and `hall-ui`.

package/docs/adr/README.md

@@ -428,7 +428,7 @@ This keeps the decision history honest and traceable.
 | 0334 | [**The recruiting directory lists a hidden builder by name, and hide changes a row's shape, not whether it exists** ([task 1002291](https://cloudbongos.com/builders#/task/1002291), R15 — goal 1000110). Privacy spec D2 (owner-signed) lists an active, public, hidden account on the recruiter surface "name-only (if not opted out)"; the directory dropped it outright, making hide a second opt-out while Settings told that builder recruiters would see their name and picture. `GET /scouting` now answers two tiers: `builders` (ranked, `scoutingListableSql`, unchanged) and `name_only` (`scoutingNameOnlySql` = the same predicate with the hide term flipped, so the tiers partition the directory and only the opt-out removes anyone), projected to `github_login`, `display_name`, `avatar_url` by `scouting-name-only.js`. The existence floor stays (a private account is the archon-floor D3 sliver's, never the directory's); presence never depends on activity; the only order is the login; the predicate is pinned to that one reader and its three columns. The hall's `/people` renders the tier as its own panel, never ranked, found by name, never by a role filter. Rejected: fixing only the copy; trailing rows in the ranked ledger; listing private discoverable accounts by name.](0334-the-recruiting-directory-lists-a-hidden-builder-by-name.md) | privacy / recruiting / hall |
 | 0335 | [**An invite is a pre-approved row on the project's own instance, and `project.recruit` says who may send one** ([task 1002813](https://cloudbongos.com/builders#/task/1002813), R1 of the project admin console wave, goal 1000110 — BONGOS-V2). Supersedes ADR 0141 §5's "Invitations (deferred slice)" paragraph only. Formalises spike task 1002786's three decisions and reconciles them with six weeks of shipping: the instance invite route (task 1003044), the PATCH rescind (ADR 0201 D4.2) and the composed join door (ADR 0247) already exist, and the hub invite's dead end is now reachable from the creation wizard. **Decisions:** (D1) authority lives on the project's own instance, and the instance IS the project; the hub is identity, relay, echo, notification and links, and never writes a project's admission row; (D2) a recruit invite is an `access_requests` row with `status='invited'`, so signing in is the acceptance act and the gate is untouched; the row gains `kind ∈ (application, invite)` and `created_by` (the inviter, which a rescind would otherwise overwrite), reuses `note`, backfills exactly (`created_at = resolved_at`), and neither column ever enters an admission read; (D3) one new grantable atom, `project.recruit` (`system:false`, floor archon, widened per instance through the existing governance tab), guards the invite, the outstanding list, the invite rescind and the queue read, while `access_request.review` keeps the verdict; because inviting is admitting, a recruiter without the review atom may not approve or re-admit an APPLICANT through the invite route (409 to the queue); the hub sliver moves onto the atom, and the hub directory and hub invite KEEP `project.curate`, revising ADR 0210/0215/0248, since swapping the directory would raise a gate on a viewing surface (ADR 0217). **Task map:** R2 (task 1002814) = the migration, the invite writes and the sender list, still on `access_request.review`; R3 (task 1002815) = mint the atom, move the gates, the 409 clause, the sliver swap and the pins, and it lands after R2; R5 (task 1002817) is already delivered, so close it into task 1002331; task 1003362 folds into R3. Rejected: a new invitations table; the hub pending row as the invite; widening `access_request.review` instead of minting an atom; a per-project settings row for the floor; letting a recruiter's invite approve applications; `system:true`; swapping `project.curate` on the hub directory.](0335-an-invite-is-a-pre-approved-row-on-the-projects-own-instance.md) | governance / onboarding / platform-identity |
 | 0336 | [**A guild is a hub-side group whose members each consent twice, and its collective record is only ever the sum of what those members already show** ([task 1002299](https://cloudbongos.com/builders#/task/1002299), goal 1000110 — the R23 design spike for goal 1000045's C7/C8/C9). No platform guild existed (every "guild" in the tree is Discord's). Decisions: (1) three hub tables in `platform-identity`, in their own `guilds.js` (the 1,500-line ratchet), distinct from instance-local `goal_members`: guilds (slug, name, `visibility ∈ public|unlisted` with **no default**), members (`membership_kind ∈ owner|member`, never `role` per ADR 0174; a partial unique index holds exactly one owner; a per-member `shown_publicly`), and requests; (2) two consents to join, no self-join, through ADR 0202's connections lifecycle verbatim (silent decline, 90-day swallowed re-ask, 30-day read-time expiry); `accountActiveSql` floors the feature; an **unlisted guild 404s to everyone on the public read, members included**, and takes invites only, because a slug is guessable; (3) the public roster is `shown_publicly AND accountVisibleSql`, and widening a guild to public changes no member's flag but the flipping owner's, so consent given to a small audience is never reused for a large one; (4) **the privacy resolution — NOT ratified; superseded by [ADR 0337](0337-the-hub-account-is-the-person-a-hall-account-is-their-seat-in-one-project.md) D4.4:** it proposed that a member is counted iff shown AND `rollupVisibleSql`, read-time, `no-store`, never stored, and N and M are both lengths of lists the reader can see. The guild record is therefore always a sum of numbers already on members' own public profiles, so nothing can be subtracted out. All-or-nothing is rejected (one member blanks everyone and hiding becomes costly), as is per-member consent to count hidden numbers (it breaks "hide_stats beats everything"). The trade-off: guilds of privacy-minded builders look smaller and rank lower. A union count of all members' projects is refused because it reveals shared private projects; (5) the namespace is `/g/<slug>`, `g` is reserved in the SEO spec's project-slug list, the slug is fixed in V1, and `tests/guild_namespace_reserved.mjs` pins the two documents together; (6) a guild engages a project only through the individual door: a guild application is each member's own vouched application, labelled through ADR 0260's live applicant-profile read (no new instance field); inviting a guild fans out ordinary individual invites to its public roster at that moment, **never a guild-level pre-approval** (that would let a guild owner decide admission to someone else's project); (7) the map ranks public guilds by size and counted works shipped, read-time, with a slug tiebreak, and R29 narrows to the visual. Scope changes for R24–R37 are tabled in the ADR, including R28's dependency on the abandoned R11 and R29/R31's archived orb goals.](0336-a-guilds-record-is-the-sum-of-what-its-members-already-show.md) | platform identity / privacy / social graph |
-| 0337 | [**The hub account is the person, a hall account is their seat in one project, so anything that spans projects lives on the hub** ([task 1004255](https://cloudbongos.com/builders#/task/1004255), goal 1000110 — the owner's hub/hall re-scope, 2026-09-24/25). Extends [ADR 0141](<redacted>.md) from identity to placement: (1) a surface about the person across projects, or about more than one project, goes on the HUB (`public-landing`, `platform-identity`): people directory, community, guilds, connections, recruiting, platform-account settings; one about this project goes in the HALL (`hall-ui`); "Builders you may know" is on both; `status-ui` is the status dashboard, not the hall; (2) no authority moves, and hub actions still land as the project's own rows; (3) hall `/people` retires, ADR 0334's recruiting directory moves unchanged to the hub community page, `/roster` is the in-project directory; (4) owner calls: the hidden-builder recruiter panel is recruiter-only while public search is unchanged (amends community-tab spec D8); platform-account settings get a new hub page; **guild totals count hidden and private members by default, with a notice on the join card and a per-guild off switch (`counted_in_totals`), rounded to a 1–2–5 band, only once a guild has at least 3 of them, refreshed weekly; size stays the public roster length** (supersedes ADR 0336 D5; relaxes the privacy spec's "`hide_stats` beats everything" for guild totals only, for a member who was told), with the fake-account padding limit stated and accepted.](0337-the-hub-account-is-the-person-a-hall-account-is-their-seat-in-one-project.md) | platform identity / placement / privacy |
+| 0337 | [**The hub account is the person, a hall account is their seat in one project, so anything that spans projects lives on the hub** ([task 1004255](https://cloudbongos.com/builders#/task/1004255), goal 1000110 — the owner's hub/hall re-scope, 2026-09-24/25). Extends [ADR 0141](<redacted>.md) from identity to placement: (1) a surface about the person across projects, or about more than one project, goes on the HUB (`public-landing`, `platform-identity`): people directory, community, guilds, connections, recruiting, platform-account settings; one about this project goes in the HALL (`hall-ui`); "Builders you may know" is on both; `status-ui` is the status dashboard, not the hall; (2) no authority moves, and hub actions still land as the project's own rows; (3) hall `/people` retires, ADR 0334's recruiting directory moves unchanged to the hub community page, `/roster` is the in-project directory; (4) owner calls: the hidden-builder recruiter panel is recruiter-only while public search is unchanged (amends community-tab spec D8); platform-account settings get a new hub page; **guild totals count hidden and private members by default, with a notice on the join card and a per-guild off switch (`counted_in_totals`), rounded to a 1–2–5 band, only once a guild has at least 3 of them, refreshed weekly; size stays the public roster length** (supersedes ADR 0336 D5; relaxes the privacy spec's "`hide_stats` beats everything" for guild totals only, for a member who was told), with the fake-account padding limit stated and accepted; (5) amended 2026-09-25 evening ([task 1003444](https://cloudbongos.com/builders#/task/1003444)): hall `/people` is deleted now rather than when the hub community page ships (it redirects to `/roster`, and cross-project search plus the recruiter name-only panel wait for task 1003363), a builder's invitations and the join-a-project field get their own hub page, "Projects you build on" moves to the builder's own profile (own view only), and connections live on the hub first while a hall's connections tab shows only connections who build on that project.](0337-the-hub-account-is-the-person-a-hall-account-is-their-seat-in-one-project.md) | platform identity / placement / privacy |
 | 0338 | [**Modules travel through a Bongos-hosted store, and an acquired module keeps working forever** ([task 1003782](https://cloudbongos.com/builders#/task/1003782), goal 1000091 — working area 5, owner Will). A module had no transport of its own: it reached an instance only inside the core (ADR 0107 §6) or in the instance's repo. Weighed npm packages, a Bongos-hosted store and git refs against the four things area 5's criteria require — entitlement before install, a per-version score, a tester channel, and a delist that stops distribution. npm and git refs fail entitlement and delist by construction. **D1:** Cloud Bongos hosts the store; a module version is a tarball + hash manifest in the same format `package-core.js` already emits (same `isPublishable()` gate), registry rows on the control-plane DB, artifacts in the already-paid DO Spaces bucket, served by the control plane only after an entitlement + channel check; free modules take the same path at price zero; install/update verify hashes on arrival; modules' own npm deps still travel via npm (ADR 0138). No new fixed cost. **D2 (owner):** delisting, author withdrawal or deletion removes a module from the catalog and stops new acquisitions and updates, but **an acquired module keeps working forever** — the store never disables or removes an installed copy and a delist never revokes an entitlement; the holder is told no more updates will come. Security issues are not a special case; a remote kill switch would need a superseding ADR. Rejected: npm, git refs, remote disable on delist.](0338-modules-travel-through-a-bongos-hosted-store.md) | modules / distribution / economy |
 | 0339 | [**A project's owner upgrades it, and a hosted project hands off to the hub's door** ([task 1004174](https://cloudbongos.com/builders#/task/1004174), goal 1000090 — the owner's ruling of 2026-09-26 that only a project's owner upgrades it). Amends ADR 0293 D5. **D1:** the deploy door's preview and move routes admit the OWNER of a tenant row (`co-tenant`/`cloud-host`) for that row, asked first; every other caller meets the unmodified `core.pin.move` gate, so a non-owner's refusal is unchanged whether or not the id exists and the widening can only admit. **D2:** the platform's own row stays atom-only. **D3:** `GET /core-update` names `<hub>/deploy?project=<slug>` on a federated project, and the hosted hall's banner and rail hand off there (the dead local Deploy item is gone); the hub's `/deploy` shell admits a project owner through `alsoAdmits: 'isProjectOwner'`. **D4:** the intent's actor records the door (`api:owner:<id>` / `api:archon:<id>`), both attributed on the `core_upgrades` ledger. Rejected: a tenant-side API that performs the upgrade, granting the system atom to owners, owners moving the platform row. ADR 0328 Phase 1 (task 1004159) should fold this gate into `requireProjectOwner`.](0339-a-projects-owner-upgrades-it-and-a-hosted-project-hands-off-to-the-hub-door.md) | provisioning / deploy door / permissions |
 | 0340 | [**Every hall takes its update from Settings, and /deploy is the platform hall's page** ([task 1004296](https://cloudbongos.com/builders#/task/1004296), goal 1000090 — the owner's 2026-09-25 asks: a Settings version panel "just like iOS", and /deploy only in the Bongos hall). Amends ADR 0339 D3 and the reach of ADR 0293's page. **D1:** Settings → Software update in the core — the running core, the newest release the runner's own channel rule allows, and what each version in between carries from the newest package's release notes; every signed-in builder reads it, and "up to date" is said only from an answer. **D2:** its Update button leads to the door (local /deploy, the hub's /deploy?project=, or a `bongos upgrade` sentence), drawn only for holders of core.pin.move. **D3:** /deploy 302s to Settings on a hall without the provisioning module. **D4:** the banner links Settings everywhere but the platform; the rail is no longer re-pointed; /core-update drops deploy_url. **D5:** the registry reader moved into the core (module-api readPackageRegistry). Rejected: a second copy of the two-step door, gating the panel on the atom, a "moved" page.](0340-every-hall-takes-its-update-from-settings-and-deploy-is-the-platform-halls-page.md) | deploy door / settings / core update |