@bongos/core 1.19.1026 → 1.19.1028

package/docs/adr/0213-platform-terms-acceptance-is-the-hubs-own-witness.md

@@ -27,6 +27,8 @@ Three things were found on picking the task up, and they changed its shape:
 
 This is deliberately the ADR 0205 D3 property, reused. An acceptance record a caller could assert is evidence of nothing; the only thing that makes the record mean "this human accepted" is that no request-controlled value can reach the statement that writes it. `ensureAccount` — the federated check-in / device-poll path, which takes an *unproven* `github_id` from a request body — writes NULL, exactly as it writes `provisional`.
 
+> **Amended 2026-09-25 ([task 1003353](https://cloudbongos.com/builders#/task/1003353); [blocker 1000124](https://cloudbongos.com/builders#/blocker/1000124)) — what "the hub's own sign-in" means.** `GET /sso/authorize` is reached when a builder uses their platform account to sign in to a **project**; the only builder of that URL is a child instance's `idpAuthorizeUrl`. Signing in to the hub itself creates a hub session and never touches `platform_identity_accounts`, so it records no acceptance. `/terms` said "signed in here"; it now names a project sign-in. The owner chose to also capture the hub's own sign-in ([task 1003361](https://cloudbongos.com/builders#/task/1003361)), which will make this a second capture point rather than a wording fix. Two smaller corrections to the text above: the device poll does not go through `ensureAccount`, it is a non-activating `upsertAccount`, and so is `PATCH /me/handle`; `ensureAccount` is the federated membership check-in alone. The outcome was always the same (neither writes an acceptance), and both paths are now executed in `tests/terms_acceptance.mjs` rather than asserted as text.
+
 ### D2 — Written once. The first acceptance is the one that stands
 
 The conflict branch writes `COALESCE(platform_identity_accounts.terms_accepted_at, now())`. Signing in again re-reads the terms but does not restamp them, so the column keeps meaning *when consent was given* rather than *when this account was last seen*. `terms_version` is COALESCE'd the same way and always written in the same statement, so the pair cannot diverge.
@@ -58,10 +60,10 @@ The mechanism ships complete. The text of the new section is a draft on [blocker
 ## Consequences
 
 - The premise the public-profile surfaces rest on becomes true for every account activated from here, and fail-closed for every account that predates it.
-- **Every currently-`active` account is unpublished until its next hub sign-in** (D4). Reversible in one line; on the owner's blocker.
+- ~~**Every currently-`active` account is unpublished until its next hub sign-in** (D4).~~ Superseded by the grandfather (amendment under D4): nothing went dark after migration 024.
 - `platform-identity.js` sat at 1497 lines against a hard `oversized_file_count: 0` ratchet, so the write-side SQL lives in a new `terms-acceptance.js` — the fifth instance of the "new file beside it" precedent (`account-visibility.js`, `application-echo.js`, `routes/connections.js`, `src/bongos/routes/my-sessions.js`). The file now measures exactly 1500 and **has no headroom left**; the next change to it must shrink it.
 - The read/write split is load-bearing: `terms-acceptance.js` owns only statements that SET the columns, `account-visibility.js` owns the one that TESTS them. The guard's spelling rules deliberately do not match writes, which is what lets both files exist without one of them being a drift copy.
-- **Settings will read wrong for a legacy account under D4** until someone closes it: `GET /me/cross-project` returns `profile_state` raw and the Settings consent note branches on it alone, so an account that signed in before the terms existed reads "active" while its profile is published nowhere. One own-scope boolean plus a copy change fixes it - filed as idea 1000875, and it disappears entirely if the owner grandfathers on blocker 1000123.
+- *(Superseded by the grandfather, amendment under D4: after migration 024 every `active` account has an acceptance, so the case below no longer arises.)* **Settings will read wrong for a legacy account under D4** until someone closes it: `GET /me/cross-project` returns `profile_state` raw and the Settings consent note branches on it alone, so an account that signed in before the terms existed reads "active" while its profile is published nowhere. One own-scope boolean plus a copy change fixes it - filed as idea 1000875, and it disappears entirely if the owner grandfathers on blocker 1000123.
 - `docs/specs/<redacted>.md`'s standing note that the consent premise "is not currently true for every account" is now addressed rather than outstanding.
 
 ## Rejected alternatives