@bongos/core 1.19.467 → 1.19.468

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.467",
-  "core_contract": "1.19.467",
-  "source_commit": "ca27d74624afc9f0a8310e29b2efaa2c5bb993c8",
+  "core_version": "1.19.468",
+  "core_contract": "1.19.468",
+  "source_commit": "46a154331618a8c57ed0d178e7bfe13e180b7559",
   "source_ref": "HEAD",
-  "built_at": "2026-09-02T13:55:51.607Z",
+  "built_at": "2026-09-02T14:11:23.358Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 407,
+    "docs_redacted": 408,
     "agent_docs_stubbed": 24,
     "functional_verbatim": 1823,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2254,
-  "tree_sha256": "8d432d170e40887e5a113bf2531114e2e0b29f4e8dd8aada1b61ae25b764b597",
+  "file_count": 2255,
+  "tree_sha256": "96abcd9bb3bfd8f8bfc4930c27fe91aa04b9f59717743a5b059f768854c865c3",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1629,10 +1629,15 @@
       "mode": "0000644",
       "sha256": "717bdc174891ccf5bc8756b25f53eca016d4d6dfaeebec8d12bb2a6bfef56976"
     },
+    {
+      "path": "docs/adr/0225-privacy-suppresses-cross-project-surfaces-only.md",
+      "mode": "0000644",
+      "sha256": "f9f3a0b8ebe2d161e17e1c632bbbda71842c9476958294330420f28c6301f7db"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "ec731cb900dc5b30287a370325042a4ead509759aba5688c32d91f293047c491"
+      "sha256": "7b353237a164c704ac247646b93c419b26cc5fd8e53ac81e63b553146df76c85"
     },
     {
       "path": "docs/api-reference.md",
@@ -2122,7 +2127,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "f5622e8a177e977aedade86d47f76e7669f2f417a1d88d5cd63c66949fe9d8c2"
+      "sha256": "b0ee40d833a5f28cba9450cc355d4b2b922def1e95fed5725ebee8796f2918a6"
     },
     {
       "path": "docs/modules-contract.md",
@@ -6622,12 +6627,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "fecffff8fe1b80ab540c5212c13d5056d722e897b824afdc2ebeaae24738935b"
+      "sha256": "775fa829d773f6c39be8c93c544e77c005304ff78a3c879778292fd5dc806ee8"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "f4a08b3e124eba41cb2e39cea9a79ede0858c5e1496f2ce1531030814df04d12"
+      "sha256": "0d5b71ad68cce7afe9f0d4b35f8f4105fad5f00f46e91f60659ebf064f288f62"
     },
     {
       "path": "public-docs/index.html",
@@ -8277,7 +8282,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "30e8f24ef0a0f45e8c4172c98daee61756ba74acf0d55f100ae8cc6c7b7540e2"
+      "sha256": "97199ab275115c07426ca83be7b0c618b3aebdb4b1e9349ab90ea989f8d625b4"
     },
     {
       "path": "src/module-loader/catalog.js",

package/docs/adr/0225-privacy-suppresses-cross-project-surfaces-only.md

@@ -0,0 +1,84 @@
+# 0225 — Privacy suppresses cross-project surfaces only: a private builder still appears on their own project's roster
+
+- **Status:** Accepted
+- **Date:** 2026-09-02
+- **Tasks:** [#1003443](https://cloudbongos.com/builders#/task/1003443) (goal 1000075 — collaboration and the social hall; criterion `community-is-one-builders-page`)
+- **Related:** [ADR 0171](<redacted>.md) (owns `hide_stats` + `profile_state`, fail-closed consent in the READ path) · [`docs/specs/<redacted>.md`](../specs/<redacted>.md) (the spec this amends)
+
+## 1. Why this ADR exists
+
+The privacy spec is **accepted**, and for one case it defined its two flags
+inconsistently. Found 2026-08-30 while scoping the Builders page:
+
+- `hide_stats` suppresses *"everything derived from the **cross-project rollup**"* —
+  qualified, so a project's own in-hall leaderboard is plainly out of scope.
+- `account_visibility: private` said *"absent from search, **leaderboards**, sitemap"* —
+  **not** qualified, so it read as covering the in-project leaderboard too.
+
+Two readers could act on the same accepted spec and build opposite behaviour. Worse,
+PV2 requires *"ONE shared predicate used by every public read: … leaderboards …"*,
+while `modules/economy/credits.js`'s `leaderboard()` is a bare
+`SELECT … FROM builders ORDER BY total_credits DESC` — no join to
+`platform_identity_accounts`, no predicate at all. Read one way that is an unshipped
+PV2 violation sitting in main; read the other way it is correct. Nothing in the
+documents settled which.
+
+## 2. The decision
+
+**Privacy suppresses CROSS-PROJECT surfaces only.** Owner, 2026-08-30.
+
+A builder marked `private` is absent from `/u/<handle>`, platform search, the sitemap,
+Explore-adjacent surfaces and the recruiting reach — every surface that is *about the
+platform*. They still appear on the roster and leaderboard of a project they actually
+build on, because **a project's record of its own work is the project's business**. The
+flag governs how far a builder's identity travels, not whether the work they did for
+you is yours to show.
+
+Two things follow, and they are the point of writing this down:
+
+- **`credits.leaderboard()` is correct as written and needs no change.** Adding a
+  visibility predicate there would be a regression, not a fix — which is exactly what
+  a future session reading PV2 literally would have done.
+- **PV2's "every public read … leaderboards" means the cross-project leaderboards.**
+  The shared predicate still owns every surface it names; the in-project ledger was
+  never one of them.
+
+## 3. What changed
+
+The spec was amended rather than left to be re-litigated — the ambiguity was in its
+wording, so the wording is the fix (task 1003443):
+
+- the D1 `account_visibility` row now says *cross-project* leaderboards, and says
+  outright that the flag does not reach a project's own roster;
+- the two `active · private` matrix rows no longer say **"absent everywhere"** — the
+  single most misreadable phrase in the file — but "absent from every cross-project
+  surface";
+- the `active · public` rows qualify their "leaderboards" the same way, so the matrix
+  cannot be read against the table;
+- PV2's own ship-table row is qualified too;
+- and the boundary is stated as the **third rule** under D2, beside "`hide_stats`
+  beats everything", because that block is where a reader looks for the rules the
+  matrix encodes.
+
+## 4. Rejected
+
+**Making `private` hide a builder from the projects they build on.** It reads as the
+more privacy-protective option and is the reason the ambiguity was worth an owner
+decision rather than a coin flip. Rejected because it breaks the ledger: a project
+whose roster silently omits contributors cannot show who built it, credits and karma
+would be awarded to someone invisible on the surface that explains them, and the
+in-hall leaderboard would disagree with the task history any builder can already read.
+Privacy about *the platform* does not imply anonymity *inside a project you joined*.
+
+**Leaving it as a dated note in the spec.** The task offered this and it is the wrong
+shape: the decision resolves a stated ambiguity in an accepted spec and pins a piece
+of shipped code as deliberately predicate-free. That is an ADR's job — a note in a
+spec is not what a future session greps when it wonders why one leaderboard query has
+no visibility join.
+
+## 5. What this does not decide
+
+Whether an in-project roster may be made public to the world (a per-project
+visibility question the platform owns — goal 1000058's `platformVisibility`), and
+whether a builder can leave a project's roster entirely. Both are about the
+*project's* surface, not the account flag this ADR scopes.

package/docs/adr/README.md

@@ -311,5 +311,6 @@ This keeps the decision history honest and traceable.
 | 0222 | [**The image family under the hero-only rule: plates and hero objects, never screens; the mark is drawn; the board is a contact sheet; the pair and the sidecar are the output contract** ([task 1003328](https://cloudbongos.com/builders#/task/1003328) · goal 1000083). The four image skills of `Leonxlnx/taste-skill` (scanned `dangerous`, ADR 0198) are built around pictures of interfaces: one reference image per section, one app screen per flow step in a phone mockup, an identity board with the brand name rendered in, and a build loop whose truth is the generated image; the panel flagged the eagerness mandate, the image-count rule and the must-invoke-any-tool directive by name, and the owner's rule (2026-08-26/27) forbids the category. Decisions: **D1** the subject is the composition's plate slots and the count is the slot count; variety survives as anchors (field, beside-bleeding, masthead, orb, backdrop; text-left image-right refused), the palette lock is the pack, cross-frame consistency is one family (material, light, lens, ground). **D2** a screen is the surface itself: the mobile skill makes portrait plates for 390 / 320, the flow is the states file rendered by the kit, the bible is `DESIGN.md`, no phone mockup, native declines to `/design`. **D3** the source of truth for UI is the owner's references and the world; `image-to-code` reads them (analysis, extraction spec, faithful translation, drift as the failure mode, the clarity checklist) and the only image it may cause is the hero plate. **D4** the mark is drawn as inline SVG, the colour system is the pack, the type specimen is the faces on a real page, the applications are the kit's renders, the image direction is a hero-object family, the nine-panel board is a contact sheet of real parts. **D5** the output contract is DESIGN.md's pair and sidecar (JPEG dark plate, WebP alpha cutout, `<file>.<ext>.json` beside each, `--plate-*` tokens on `body`) through the instance's art pipeline key, the spend logged, a white ground through the remover, alpha verified with ffmpeg, never a crop. **D6** the worked example is the grove specimen's hero object, not the front door. **D7** the pins: the four declared, each naming the sidecar, "text-free" and the art key; no eagerness / count / per-section / must-invoke directive. Rejected: per-section images for reference only; phone mockups around real shots; a generated logo as a start; the plate on the front door; a shared base skill with wrappers.](<redacted>.md) | ui-design / skills / imagery |
 | 0223 | [**The anti-pattern detector is two tiers inside the kit: mechanical floors fail, craft tells warn, a false positive is waived in the file with its reason, and nothing new is installed** ([task 1003329](https://cloudbongos.com/builders#/task/1003329) · goal 1000083). The [detector] group of impeccable's rebuild spec (about sixty rules, a CLI plus a browser bundle wired to hooks, per-project ignores, in-file waivers, "a clean scan is a floor and never proof") lands as RULES in the kit that already exists, per the task body: no second tool, no bundle, no hook. Decisions: **D1** `kit/tells.js` carries the static rules and `check-mock.js` runs them after the platform rules and taste bans; `lib.js`'s `factsInPage` collects the computed-value twins as `tells` and `render.js` prints them as `~ tell:` lines per render, recorded in `report.json`, never counted as problems. Two tiers: floors FAIL (a bounce easing; a card nested in a card) and tells WARN (the icon-heading-text grid, hero metrics, section numbering, a kicker above the h1, a side stripe, a hard offset shadow, a coloured halo, decorative blur, a default typeface, a wide measure, a long headline, the same entrance everywhere, a geometric mask on a plate, glyphs as icons, a rainbow gradient, the browser surfaces nobody themed, proportional numerals, tiny type; rendered: measure, tiny text, numerals in cells, headline lines, an overshooting curve). **D2** the world decides which tells are floors: a kicker above the h1 is a FAIL where the instance's `DESIGN.md` bans the eyebrow (a new `eyebrow` taste key), a WARN elsewhere. **D3** a false positive is waived in the file with its reason (`kit-ignore: <rule prefix> (reason)` → a WAIVE row), `--raw` runs with none, `--no-tells` runs the platform rules only, `--json` prints rows with `fails` / `warns` counts; no per-project ignore config. **D4** not ported: the purple-to-blue tell (a literal colour already fails; hue is unresolvable under the fifteen), an injected overlay, the screenshot sampler (`contrast.js --url` is that pass), a cascade resolver (the browser is the resolver), native code, every hook. **D5** the pins: a clean fixture passes every rule, every rule class trips at its tier with the case count equal to the rule count, the promotion, the waiver / raw / json paths through the real CLI, `craftTells` as warnings; the hub mock and the three specimens still pass, `/projects` and the grove specimen still render ALL CLEAN. Rejected: a second CLI; every tell as a floor (the kit as the taste and the instance as the exception); a project-wide ignore config; an edit-time hook.](0223-the-detector-is-two-tiers-in-the-kit.md) | ui-design / kit |
 | 0224 | [**Module-owned skills reach the core checkout as untracked, self-ignored copies with a manifest: the self-copy guard stays, the dev path is a flag, and the file map skips what the module documents** ([task 1003330](https://cloudbongos.com/builders#/task/1003330) · goal 1000083). `materializeClaude`'s self-copy guard is right (a core copying itself is a no-op at best), but Claude Code discovers only `.claude/skills/` at the project root, so a builder IN the core checkout could not invoke any of the nine ui-design skills written there. Decisions: **D1** `node scripts/gds/claude-materialize.js --module-skills-only [--dry-run] [--clean]` calls `materializeModuleSkillsIntoCore`: the same roster, gate and slug rule as step 1b, verbatim copies (no bongosify: the checkout runs `node scripts/gds/…`), a core-owned name kept, a disabled module's excluded; the guard untouched. **D2** untracked and self-ignored: a generated `.claude/skills/.module-skills.json` manifest and a `.gitignore` that ignores itself, the manifest and every materialised dir; each run removes what the last manifest named then lands the current set (byte-identical on repeat; a dropped declaration disappears); `--clean` stops after the removal. **D3** `gen-file-map.js` and `tests/file_map.mjs` skip materialised names by the manifest (a module skill is documented by its module's README, not by the notes sidecar). **D4** init from a checkout that carries the copies still lands them through step 1b, transformed, and never the dotfiles. **D5** pinned end to end in `tests/claude_materialize.mjs`. Rejected: dropping the guard; committing the copies; symlinks or junctions; notes for dirs not in the repository.](<redacted>.md) | materialiser / skills |
+| 0225 | [**Privacy suppresses cross-project surfaces only: a private builder still appears on their own project's roster** ([task 1003443](https://cloudbongos.com/builders#/task/1003443) · goal 1000075). The accepted privacy spec defined its two flags inconsistently for one case: `hide_stats` suppresses "everything derived from the CROSS-PROJECT rollup" (qualified, so an in-project leaderboard is out of scope) while `account_visibility: private` said "absent from search, LEADERBOARDS, sitemap" (unqualified, so it read as covering the in-project one too) — and PV2 demands "ONE shared predicate used by every public read: … leaderboards …" while `modules/economy/credits.js`'s `leaderboard()` is a bare `SELECT … FROM builders` with no join and no predicate. Read one way that is an unshipped PV2 violation in main; read the other it is correct, and nothing settled which. **Owner decision (2026-08-30): privacy suppresses CROSS-PROJECT surfaces only.** A `private` builder is absent from `/u/<handle>`, platform search, the sitemap, Explore and the recruiting reach, and still appears on the roster of a project they build on — a project's record of its own work is the project's business. Two consequences are the point of recording it: `credits.leaderboard()` is **correct as written** (adding a predicate there would be a regression, not a fix — exactly what a literal PV2 reading would have done), and PV2's "leaderboards" means the cross-project ones. The spec was amended rather than annotated: the D1 row and both `active · public` matrix rows now say *cross-project*, the two `active · private` rows drop "absent everywhere" (the file's most misreadable phrase) for "absent from every cross-project surface", PV2's ship-table row is qualified, and the boundary lands as the **third rule** under D2 beside "`hide_stats` beats everything". Rejected: making `private` hide a builder from projects they build on (it reads as more protective and breaks the ledger — a roster that omits contributors cannot show who built the thing, and credits would accrue to someone invisible on the surface explaining them); and leaving it as a dated spec note (it pins shipped code as deliberately predicate-free, which is an ADR's job).](<redacted>.md) | privacy / spec |
 
 > ⚠️ **Numbering collisions are now machine-enforced, not narrated.** Twenty numbers are shared by two ADRs each — assigned in parallel sessions before anything checked. The files keep their filenames (renumbering would break every existing citation, and a number once assigned is never reused), and this table disambiguates each pair as `NNNN-a` / `NNNN-b`. The authoritative list is `LEGACY_DUPLICATE_ADRS` in [`scripts/gds/adr-namespace.js`](../../scripts/gds/adr-namespace.js), frozen by exact filename: a **new** collision — or a third file joining a legacy number, or a rename of either half — hard-fails the `unit` CI gate, as does an index row that points at no file or an ADR with no row. The list may only shrink. This paragraph used to narrate the collisions one by one and had fallen eight behind reality; see [ADR 0195](<redacted>.md) for why the check exists and why the pairs are grandfathered rather than renumbered.

package/docs/module-api-changelog.md

@@ -1371,5 +1371,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.465 with no explicit bump. run 33583122775. (task 1002620)
   1.19.467 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.466 with no explicit bump. run 33638703282. (task 1002620)
+  1.19.468 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.467 with no explicit bump. run 33640370009. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.467",
+  "version": "1.19.468",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.467",
+      "version": "1.19.468",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.467",
+  "version": "1.19.468",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/src/module-api.js

@@ -33,7 +33,7 @@ const { validateOrRespond, LIMITS, parseId, asyncHandler, corsPublicGet, parsePa
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.467'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.468'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');