@bongos/core 1.19.1069 → 1.19.1071

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/.bongos-core.json CHANGED
@@ -2,22 +2,22 @@
2
2
  "artifact": "bongos-core",
3
3
  "manifest_schema": 1,
4
4
  "generator": "scripts/gds/package-core.js",
5
- "core_version": "1.19.1069",
6
- "core_contract": "1.19.1069",
7
- "source_commit": "4c59b7289049e05edb0eea145d6fb49cbbee6198",
5
+ "core_version": "1.19.1071",
6
+ "core_contract": "1.19.1071",
7
+ "source_commit": "e952aeff8fd966ba7aea8a72df82e4d825c22648",
8
8
  "source_ref": "HEAD",
9
- "built_at": "2026-09-28T19:09:33.736Z",
9
+ "built_at": "2026-09-28T19:35:40.500Z",
10
10
  "redaction": {
11
11
  "model": "docs-redacted+functional-verbatim",
12
- "docs_redacted": 547,
12
+ "docs_redacted": 549,
13
13
  "agent_docs_stubbed": 26,
14
14
  "functional_verbatim": 2560,
15
15
  "rules": 3,
16
16
  "gate_literals": 3,
17
17
  "gate": "passed"
18
18
  },
19
- "file_count": 3134,
20
- "tree_sha256": "537e8455ba0fa27c76b31b538e142554e4e40ecae9ea216212318d394bb06c44",
19
+ "file_count": 3136,
20
+ "tree_sha256": "364a060541bc6ea130edf33f92ee954d0ccf420f8727ea29239c18392f5621c1",
21
21
  "files": [
22
22
  {
23
23
  "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -127,7 +127,7 @@
127
127
  {
128
128
  "path": ".claude/skills/design/SKILL.md",
129
129
  "mode": "0000644",
130
- "sha256": "2ffaa5f9c6b6ff5b9a3a4730b4d172cdb905f1ed5efa879d3b14dca5ae60aeeb"
130
+ "sha256": "cd200f943e1022cb023a40c936760c2471ea536e9bd74a258e4ecc1bdaf285a8"
131
131
  },
132
132
  {
133
133
  "path": ".claude/skills/feedback/SKILL.md",
@@ -2174,10 +2174,20 @@
2174
2174
  "mode": "0000644",
2175
2175
  "sha256": "9229f8449bfa7d80918239f031dd3b9147557be34109eb74841b740c8a90e36f"
2176
2176
  },
2177
+ {
2178
+ "path": "docs/adr/0342-module-categories-are-eight-parents-with-approved-sub-categories.md",
2179
+ "mode": "0000644",
2180
+ "sha256": "f847a769842c5c57a86ef8951e685da3b61474029b54b6620046713de7c6c93c"
2181
+ },
2182
+ {
2183
+ "path": "docs/adr/0343-a-module-score-is-a-security-gate-then-an-average-of-visible-parts.md",
2184
+ "mode": "0000644",
2185
+ "sha256": "821f3c073de063aa9f3df9622a5b138cc5060754bb986cd5c747494150ec59db"
2186
+ },
2177
2187
  {
2178
2188
  "path": "docs/adr/README.md",
2179
2189
  "mode": "0000644",
2180
- "sha256": "33c5508da42392b6ecc70ef3a0c1951714cb0a22551765c3e87213c1fc9bc253"
2190
+ "sha256": "36568b2672c4b2ea76feda41fa9fe5bdffa3c10a1aaa56f862c663559712ed8b"
2181
2191
  },
2182
2192
  {
2183
2193
  "path": "docs/api-reference.md",
@@ -2747,7 +2757,7 @@
2747
2757
  {
2748
2758
  "path": "docs/module-api-changelog.md",
2749
2759
  "mode": "0000644",
2750
- "sha256": "48c692393e73b1e449efb38943ea3da0a729ab4da17b800a42bb2d8b664732c3"
2760
+ "sha256": "e8f17d79acc62fcacbcdb415295e23a8385bb050cc544b1c20fb3328b05eaa49"
2751
2761
  },
2752
2762
  {
2753
2763
  "path": "docs/modules-contract.md",
@@ -2822,12 +2832,12 @@
2822
2832
  {
2823
2833
  "path": "docs/packs/artist.md",
2824
2834
  "mode": "0000644",
2825
- "sha256": "ef94247b390fe32676c910545c35a7cfd39bb2ed87680174d7bd590eb1fbe2af"
2835
+ "sha256": "9d317443b3676bf68b7818473e75448e26a16c6316cad7298de7a4037d73cf5c"
2826
2836
  },
2827
2837
  {
2828
2838
  "path": "docs/packs/engineer.md",
2829
2839
  "mode": "0000644",
2830
- "sha256": "942fcc04e8e47520f6ea071fae30ab0d1ad6c86f4c241c489ded38793650cfa9"
2840
+ "sha256": "416aa7f4303a0148d52ab5c0e5720a327fa260a034a9558774df125e8876eee2"
2831
2841
  },
2832
2842
  {
2833
2843
  "path": "docs/packs/ideator.md",
@@ -8637,12 +8647,12 @@
8637
8647
  {
8638
8648
  "path": "package-lock.json",
8639
8649
  "mode": "0000644",
8640
- "sha256": "de479d6d3ae388d49f8adb2d8945ba24f23235de3276bfd9eaa4b43fb7e6c405"
8650
+ "sha256": "b8899117fdc884212b4d763f9a01641137ac5e5b148f2b608d5866137ec86afe"
8641
8651
  },
8642
8652
  {
8643
8653
  "path": "package.json",
8644
8654
  "mode": "0000644",
8645
- "sha256": "e0e5e53a67714ab29b287611770cf7f43fb845ca5f8a254e3f71dfd622ffab2c"
8655
+ "sha256": "d5ff7c99d5927cf91fc93d442725c14383695ed34576cd76840ae3d1579336a3"
8646
8656
  },
8647
8657
  {
8648
8658
  "path": "public-docs/index.html",
@@ -8662,7 +8672,7 @@
8662
8672
  {
8663
8673
  "path": "release-notes.json",
8664
8674
  "mode": "0000644",
8665
- "sha256": "49cde2a1d388b5ee848bfed8c77a05ea19235bd435e4e0be35d881ba2b0e967d"
8675
+ "sha256": "71549984e44e3f37dd1b858db883c2f9916ad409dff338a42e2664258980c420"
8666
8676
  },
8667
8677
  {
8668
8678
  "path": "scripts/bongos-mcp.js",
@@ -10752,7 +10762,7 @@
10752
10762
  {
10753
10763
  "path": "src/module-api.js",
10754
10764
  "mode": "0000644",
10755
- "sha256": "e9280eaa631dbe84e6bd882305919b8ad956bc642ecd2d2a5d7aa7639dc05789"
10765
+ "sha256": "f05875c00f06c453f995f13626deff2da66a9a31730d4f483756f4d74cbcc588"
10756
10766
  },
10757
10767
  {
10758
10768
  "path": "src/module-loader/catalog.js",
@@ -98,7 +98,7 @@ A look that is not listed here is not in the library. Adding one is the README's
98
98
 
99
99
  - The pack's neutral values and `DESIGN.md`'s named rules — changing the world is the owner's decision and an ADR, not a session's taste.
100
100
  - A page-private palette, a hex that isn't one of the fifteen, a `:root` in a page, motion in JavaScript.
101
- - Text: the copy half belongs to `copy-desk` — flag a string, don't rewrite the product's voice in passing.
101
+ - Text: the words belong to the artists, who rewrite whole pages in Tweak Mode (ADR 0341) — don't rewrite the product's voice in passing. A page whose words your ship changes rises in their queue on its own.
102
102
  - Image generation for anything but text-free hero plates (the owner's rule); UI is rebuilt from templates and the instance's world, not painted.
103
103
 
104
104
  ## How sessions reach this skill
@@ -0,0 +1,83 @@
1
+ # ADR 0342 — Module categories are eight fixed parents, with narrow sub-categories an author proposes and Metic+ approves
2
+
3
+ - **Status:** accepted
4
+ - **Date:** 2026-09-28
5
+ - **Task:** [task 1003783](https://cloudbongos.com/builders#/task/1003783) (goal 1000091 — working area 5, Module distribution & economy)
6
+ - **Deciders:** Will (owner of working area 5) approved the parent list and chose who creates sub-categories; Claude derived the candidates from the live module roster and wrote the record.
7
+ - **Related:** [ADR 0338](0338-modules-travel-through-a-bongos-hosted-store.md) (the hosted store) · [ADR 0264](0264-the-ten-working-areas.md) (area 5) · [session log 2026-09-10](../session-logs/2026-09-10-goal-1000091-area-5-criteria.md) (the owner's cap-of-ten and nested-category rulings)
8
+
9
+ ## Context
10
+
11
+ The owner's listing rule is a quality floor, then ranking, then **at most ten listed per
12
+ comparable category** — "fifteen Stripe modules all over 94% still show only the top ten". A
13
+ cap needs a set to count within, and nothing in the module contract carries a category today.
14
+ The owner has already ruled that categories are **nested**: a module sits in a sub-category
15
+ inside a parent.
16
+
17
+ The comparable set is the narrow one a buyer actually chooses between ("Stripe payments"), not
18
+ a broad department. If it's too broad, the cap hides good modules that don't compete with each
19
+ other. If it's too narrow, every module is top-ten in a category of one and the cap does nothing.
20
+
21
+ ## Decision
22
+
23
+ ### D1 — Eight parent categories, fixed
24
+
25
+ Derived from the modules that exist today (the roster under `modules/`):
26
+
27
+ | Parent | Key | Today's modules that would sit in it |
28
+ |---|---|---|
29
+ | Work & planning | `work` | lifecycle, ideas, agents, autonomy |
30
+ | Team & people | `people` | onboarding, government, platform-identity, builder-settings, specialities |
31
+ | Quality & review | `quality` | grading, security, copy-desk |
32
+ | Money | `money` | economy |
33
+ | Communication | `communication` | discord |
34
+ | Pages & design | `pages` | hall-ui, public-landing, status-ui, ui-design |
35
+ | Hosting & deploy | `hosting` | provisioning, npm-release, dev-box |
36
+ | Knowledge | `knowledge` | memory, sessions |
37
+
38
+ A parent is for browsing only. **The cap is never applied at the parent level.** Changing the
39
+ parent list needs a new ADR.
40
+
41
+ ### D2 — The sub-category is the comparable set, and the cap applies there
42
+
43
+ Every listed module has exactly one sub-category under exactly one parent. The cap of ten, the
44
+ ranking and the per-category comparison (task 1003800) all run within a sub-category.
45
+
46
+ ### D3 — The author proposes a sub-category; Metic+ approves it
47
+
48
+ When publishing, an author picks a parent and either picks an existing sub-category or proposes
49
+ a new one. A proposed sub-category is **not live** until a Metic+ builder approves it, renames
50
+ it, or merges it into an existing one. Until then the module is listed under its parent with no
51
+ sub-category, and it counts toward no cap.
52
+
53
+ This is the owner's choice, and the reason is the cap itself. If authors named sub-categories
54
+ freely, "Stripe", "Stripe payments" and "Payments (Stripe)" would become three categories with
55
+ five modules each, and the cap would never bite. An approver merging near-duplicates is what
56
+ keeps the comparable set real.
57
+
58
+ ### D4 — One sub-category per module
59
+
60
+ A module that does two unrelated jobs picks the one it competes on. Multiple sub-categories
61
+ would let one module take a top-ten slot in several places, and the cap is meant to make slots
62
+ scarce.
63
+
64
+ ## Consequences
65
+
66
+ - **Task 1003784** (nested category in the manifest and both catalog surfaces) builds to this:
67
+ `category: { parent, sub }`. `parent` is one of the eight keys, and `sub` is the key of an
68
+ approved sub-category or absent while a proposal is pending.
69
+ - **An approval queue** for proposed sub-categories is new work, not yet filed. It needs a
70
+ Metic+ permission key and follows the same pattern as the score override (task 1003796).
71
+ - **Core modules get categories too**, so the catalog is consistent. The table in D1 is their
72
+ starting assignment.
73
+ - **The cap (task 1003809)** counts listed modules per approved sub-category, never per parent.
74
+
75
+ ## Rejected
76
+
77
+ - **Authors name sub-categories freely.** Near-duplicate names defeat the cap.
78
+ - **Only Metic+ creates sub-categories.** An author with a genuinely new kind of module would
79
+ have to wait for someone else to make the category first.
80
+ - **A flat list of categories.** The owner specified nested. A flat list forces a choice
81
+ between browsable-but-broad and comparable-but-endless.
82
+ - **Capping at the parent level.** Ten modules across all of "Money" would hide good modules
83
+ that don't compete with each other.
@@ -0,0 +1,86 @@
1
+ # ADR 0343 — A module's score is a security gate, then an average of parts every buyer can see
2
+
3
+ - **Status:** accepted
4
+ - **Date:** 2026-09-28
5
+ - **Task:** [task 1003790](https://cloudbongos.com/builders#/task/1003790) (goal 1000091 — working area 5, Module distribution & economy)
6
+ - **Deciders:** Will (owner of working area 5) chose how the signals combine, and added that each part's score must be visible; Claude inventoried the measurable signals and wrote the record.
7
+ - **Related:** [ADR 0338](0338-modules-travel-through-a-bongos-hosted-store.md) (the hosted store) · [ADR 0342](0342-module-categories-are-eight-parents-with-approved-sub-categories.md) (the sub-category the ranking runs in) · [ADR 0027](0027-bfg-session-inefficiency-evaluator.md) (prior art: a multi-dimension evaluation) · [session log 2026-09-10](../session-logs/2026-09-10-goal-1000091-area-5-criteria.md)
8
+
9
+ ## Context
10
+
11
+ Criterion `wa5-quality-assessed` says Bongos scores each module **from what the platform can
12
+ measure itself**, with a Metic+ override and delist, and free modules assessed identically. No
13
+ module score exists today. `bongos module check` is a pass/fail submit gate, not a grade. The
14
+ quality floor (task 1003807), the ranking (task 1003808) and the cap (task 1003809) all derive
15
+ from this score. That makes the formula the thing an author appeals against, so it has to be
16
+ explainable in a sentence.
17
+
18
+ ## Decision
19
+
20
+ ### D1 — The parts, and when each one arrives
21
+
22
+ | Part | What it measures | Available |
23
+ |---|---|---|
24
+ | **Security** | dependency and code scan (task 1003792) | day one |
25
+ | **Tests** | pass rate of the module's own tests, run by the platform (task 1003791) | day one |
26
+ | **Install** | share of installs that complete cleanly (task 1003793) | once real installs exist |
27
+ | **Reliability** | runtime error and crash rate from real installs (task 1003793) | once real installs exist |
28
+ | **Tester feedback** | what testers hit during staged rollout (task 1003806) | once staged rollout exists |
29
+
30
+ Each part is scored 0–100 per module **version**, because a new version can be better or worse
31
+ than the last.
32
+
33
+ ### D2 — Security is a gate, not an ingredient
34
+
35
+ A version that **fails the security check is not listed**, whatever else it scores. Security is
36
+ never averaged in, so a module can't make up for a vulnerability with good tests.
37
+
38
+ ### D3 — The overall score is the plain average of the other parts that have data
39
+
40
+ Overall = the unweighted average of whichever of Tests, Install, Reliability and Tester
41
+ feedback have data for that version. A part with no data yet is left out, not counted as zero.
42
+
43
+ Unweighted on purpose: an author who asks "why did I score 71?" gets an answer they can check
44
+ themselves. Weights can be added later by a superseding ADR, if real data shows one part
45
+ predicts quality better than the others.
46
+
47
+ ### D4 — Every part is visible, not just the overall number (owner)
48
+
49
+ The owner's addition: **each part's score is shown to buyers alongside the overall score**, so
50
+ someone comparing two modules can pick the one that is strongest where it matters to them. One
51
+ buyer might care most about reliability, another about test coverage. The overall number sorts
52
+ the listing; the parts explain it. This is the requirement tasks 1003798 (store per-part
53
+ scores) and 1003799 (show strengths and weaknesses in the API and hall) build to.
54
+
55
+ ### D5 — A version without real-world data is labelled "New", not scored low
56
+
57
+ Until a version has Install or Reliability data, it shows as **New**, with its day-one parts
58
+ (Security passed, Tests score) visible. It isn't pushed below the floor for lacking data it
59
+ couldn't have yet. The floor and the ranking decide how New modules are placed (tasks 1003807,
60
+ 1003808). This ADR only says a missing part is never a zero.
61
+
62
+ ### D6 — Free and paid are scored identically; Metic+ can override with an audit entry
63
+
64
+ Price is never an input. The Metic+ override (task 1003796) and delist (task 1003797) sit on
65
+ top of the computed score and never replace how it is computed. Every override is recorded.
66
+
67
+ ## Consequences
68
+
69
+ - **Day one, only Tests counts toward the overall score**, behind the Security gate. The number
70
+ becomes more meaningful as installs and testers arrive. The "New" label (D5) makes that honest
71
+ rather than hidden.
72
+ - **Re-assessment runs per version** (task 1003794) and whenever new install, reliability or
73
+ tester data arrives.
74
+ - **A score an author can reproduce** is the appeal path: every part and the averaging rule are
75
+ public.
76
+
77
+ ## Rejected
78
+
79
+ - **A simple average including security.** A module with a known vulnerability could still
80
+ score well.
81
+ - **A weighted average from day one.** The weights would be guesses, and harder to justify to an
82
+ author asking why they scored low.
83
+ - **One overall number only.** Two modules with the same score can be good at different things,
84
+ and the owner wants buyers to see that.
85
+ - **Counting a missing part as zero.** It would punish every new module for data it couldn't
86
+ have yet.
@@ -433,3 +433,5 @@ This keeps the decision history honest and traceable.
433
433
  | 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 |
434
434
  | 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 |
435
435
  | 0341 | [**The page is the unit of Tweak Mode: one tweak task per page round, its status derived from the ledger** ([task 1004332](https://cloudbongos.com/builders#/task/1004332), goal 1000095 — BV2.TW03, the owner's Tweak Mode decisions of 2026-09-27 written down). Amends ADR 0233 (a proposal becomes a page batch); replaces the artist-review-on-ship cascade rule. **D1-D3:** every record keys on a page id from docs/page-inventory.json; a round is a `page-tweak` task (`source_ref page-tweak/<page>/r<n>`, 30c, catch-all goal, one open round per page under an advisory lock); TW04 commits docs/page-readings.json (line keys, placed/shared/unplaced, reading and files hashes, no browser in ship-check). **D4:** the draft, the frozen batch, the apply record and each send-back are fenced blocks on the task, parsed by a pure pages.js; unplaced rewrites file their own engineer task; copy_no_cms.mjs grows in reviewed diffs. **D5-D6:** artist-craft builders claim with a web claim; anyone asks, and a page ask is a copy_desk_flags row with scope page. **D7:** round states are derived; a passed grade on a page tweak holds at completed until the artist approves (the confirm) or sends it back to the apply queue, with the owner override as the escape hatch. **D8:** count, status, changelog, drift (against the last round's lines_after), N of M per surface, the tally and the recommendation order are all reads. **D9:** the cascade rule is removed; hasCopyOrVisualWork stays for the reader lens. **D10:** the reviews paid 30c per task on the estimate stream (withheld under cost-plus-only) plus the session's cost-plus; an approved page pays its artist 30c on a new artist lane that cost-plus-only does not suppress, payee from the claims table, applier keeps its session reward. **D11-D12:** the route table; a dependency-free .docx with content-control line tags, refused as structure_changed, wrong_page or reading_moved. Twelve builder picks are listed for the owner to confirm.](0341-the-page-is-the-unit-of-tweak-mode.md) | copy desk / artist loop / economy |
436
+ | 0342 | [**Module categories are eight fixed parents, with narrow sub-categories an author proposes and Metic+ approves** ([task 1003783](https://cloudbongos.com/builders#/task/1003783), goal 1000091 — working area 5, owner Will). The owner's cap of ten listed modules needs a comparable set, and nothing carried a category. **D1:** eight parents derived from the live roster — Work & planning, Team & people, Quality & review, Money, Communication, Pages & design, Hosting & deploy, Knowledge — for browsing only; the cap never applies to a parent. **D2:** the sub-category (the narrow set a buyer chooses between, e.g. "Stripe payments") is where the cap, ranking and comparison run. **D3 (owner):** an author proposes a sub-category and a Metic+ builder approves, renames or merges it, because free-naming would split one comparable set into near-duplicates and the cap would never bite; a pending module lists under its parent and counts toward no cap. **D4:** one sub-category per module. Rejected: free naming, Metic+-only creation, a flat list, parent-level caps.](0342-module-categories-are-eight-parents-with-approved-sub-categories.md) | modules / store / economy |
437
+ | 0343 | [**A module's score is a security gate, then an average of parts every buyer can see** ([task 1003790](https://cloudbongos.com/builders#/task/1003790), goal 1000091 — working area 5, owner Will). No module score existed; the floor, ranking and cap all derive from this one. **D1:** five parts, each 0–100 per version — Security and Tests day one; Install, Reliability (from real installs) and Tester feedback later. **D2 (owner):** failing Security means not listed, never averaged in. **D3 (owner):** overall = unweighted average of the other parts that have data; a missing part is left out, not zero. **D4 (owner):** every part's score is shown to buyers beside the overall, so they can pick the module strongest where they care (tasks 1003798/1003799). **D5:** a version without real-world data is labelled "New". **D6:** price is never an input; the Metic+ override/delist sits on top and is audited. Rejected: security in the average, day-one weights, a single number, missing-as-zero.](0343-a-module-score-is-a-security-gate-then-an-average-of-visible-parts.md) | modules / store / quality |
@@ -2625,5 +2625,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
2625
2625
  landed since 1.19.1067 with no explicit bump. run 36467481353. (task 1002620)
2626
2626
  1.19.1069 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
2627
2627
  landed since 1.19.1068 with no explicit bump. run 36470192310. (task 1002620)
2628
+ 1.19.1070 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
2629
+ landed since 1.19.1069 with no explicit bump. run 36472133987. (task 1002620)
2630
+ 1.19.1071 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
2631
+ landed since 1.19.1070 with no explicit bump. run 36473239367. (task 1002620)
2628
2632
  ---------------------------------------------------------------------------
2629
2633
  ```
@@ -6,71 +6,95 @@ An art session is not the engineer's text-heavy build loop. The artist's subject
6
6
 
7
7
  ---
8
8
 
9
+ ## Where the artist works: the studio
10
+
11
+ The artist's whole loop is one page in the hall, **`/builders/studio`**: Tweak Mode ([ADR 0341](../adr/0341-the-page-is-the-unit-of-tweak-mode.md)). The unit is a **page** (an id such as `landing:index` or `builders:studio`, from [`docs/page-inventory.json`](../page-inventory.json)): the artist takes one whole page, rewrites its words as one document, submits it, and approves the applied result before it ships. No terminal, no claim command, no diff. Your first move is to open the studio in their browser and let them look.
12
+
13
+ **The studio.** A calm night room. Top right, the **tally**: credits, pages tweaked, this week. Under the greeting, Resume and three quick actions, each opening a glass panel in place:
14
+
15
+ - **Resume** — shown only while they hold a page; back into the editor on it, with "N of M lines" rewritten so far.
16
+ - **Tweak/CopyWrite Flow** — the page to do next, with its reason ("2 people asked for it", "4 lines changed since your last pass", "untweaked"). **take it** claims that page and opens the editor; **pick another** shows four more as chips. The order is: asked for, then changed since the last tweak, then untweaked.
17
+ - **Approval queue** — the pages a session has applied, waiting for them (below).
18
+ - **Artist Review Status** — three lines, landing, builders hall and status, each "N of M tweaked".
19
+
20
+ The studio's own words (the greeting and its sub-line) are the studio page itself: clicking them offers to take `builders:studio`, and then they type over them where they stand.
21
+
22
+ **The editor: `/builders/tweak-editor?page=<id>`.** Every line of the page, in page order, on one sheet of paper, typed over in place and **autosaved**. A changed line keeps a faint "was:". A line marked "changes this on every page" is shared shell text; one marked "goes to an engineer" cannot be placed in the code, so submitting files it as an engineer task and the page does not wait for it. The top bar holds:
23
+
24
+ - **open the page ↗** — the live page in a new tab, to read it in place;
25
+ - **download .docx / upload .docx** — work offline in Word, then upload; it merges into the draft, never straight to the site. Keep the paragraphs as they are: added, dropped or reordered lines are refused by name, and a page that changed since the download asks for a fresh one;
26
+ - **submit page** — freezes the words and puts the page in the queue. Then "The page is in." with **take next**, **pick another**, or back to the studio.
27
+
28
+ Only the holder writes. A page someone else holds is read-only and names them. A draft left unsubmitted keeps its words and can be taken up again.
29
+
30
+ **Between submit and approval, a session applies it.** Submitted pages wait for a builder session running `/tweak` ([the skill](../../.claude/skills/tweak/SKILL.md), Metic+). It transcribes every line, renders the page before and after, and parks it. **It never lands the page.**
31
+
32
+ **The Approval queue.** Pictures of the applied page, desktop or phone, light or dark, flipped **before / after**. Beside them, the changed lines ("was:" / "becomes:"); a line the applier could not apply says why. Then:
33
+
34
+ - **approve and ship** — it lands, the page's count goes up, and the artist is paid **30 credits** for the page, shown in the tally;
35
+ - **send it back** — with a note of at least ten characters; it returns to the `/tweak` queue and comes back once it is re-applied.
36
+
37
+ **Gone from the artist's loop:** the per-ship "Artist review" task (a ship that changes a page's words now marks it "changed since last tweak", and the Flow raises it) and flagging single strings on the copy desk (archived; a page is the unit now). Reviews filed before Tweak Mode are still answered behind the studio's quiet door under the actions ("1 review from before Tweak Mode still waits"), shown only while one does.
38
+
39
+ **When the artist is at the terminal instead.** You are their hands. The same routes the pages use are on `node scripts/gds/api.js` under `/api/bongos/copy-desk/`: `GET next`, `POST pages/<id>/claim`, `GET pages/<id>/draft`, `PUT pages/<id>/draft` (the whole draft, `{ reading_hash, lines: [{ key, after }] }`), `POST pages/<id>/submit`, `GET approvals`, `POST pages/<id>/approve`, `POST pages/<id>/send-back` (`{ note }`). Put *their* words in, then open the editor or the queue so they see the result. Never approve on their behalf.
40
+
41
+ ---
42
+
9
43
  ## The first rule: show, don't narrate
10
44
 
11
45
  In every other craft Claude narrates — diffs, logs, paragraphs about what it is doing. **Here that is the failure mode.** An artist judges with their eyes.
12
46
 
13
47
  > **Show, then briefly caption. Never narrate the pipeline at length.** Every step ends in something the artist can *look at*, with at most a one-line caption. The plumbing still runs; it runs quietly.
14
48
 
15
- - **End every step with something visual.** After a generation, display the image. After a copy change, show the rendered text in place, not a diff. After a check, show the scorecard, not a prose summary. They should see the result before they read a word.
16
- - **Collapse the plumbing to one-liners.** Budget checks, config edits, retry tiers, atlas rebuilds — do them, report them as a single line or a number. "Generated, scored 0.91, on-palette, staged ✓" beats three paragraphs.
17
- - **Verification is looking, not reading.** Surface the rendered surface and the sandbox preview, not console logs. Logs are for when something breaks, not for routine success.
18
- - **Nothing that changes a page ships until they have seen it** (the project default, owner 2026-09-23). Show the before and after in both modes at desktop and phone width, opened in their browser with `node scripts/gds/review-sheet.js` (a terminal shows no images), and ship on their OK.
49
+ - **End every step with something visual.** After a generation, display the image. After a copy change, show the rendered text in place (the studio, the editor, the Approval queue), not a diff. After a check, show the scorecard, not a prose summary.
50
+ - **Collapse the plumbing to one-liners.** "Saved, 12 of 38 lines rewritten" beats three paragraphs.
51
+ - **Verification is looking, not reading.** Surface the rendered page, not console logs. Logs are for when something breaks.
52
+ - **Nothing that changes a page ships until they have seen it** (owner, 2026-09-23). In Tweak Mode the Approval queue is that look. For other work, show the before and after in both modes at desktop and phone width with `node scripts/gds/review-sheet.js` (a terminal shows no images), and ship on their OK.
19
53
 
20
54
  ## The second rule: as little interpretation as possible
21
55
 
22
56
  The artist owns the look; you own the rendering. **You are their hands, not their art director.**
23
57
 
24
- - **Take the brief literally.** If they said "warmer", change the warmth — don't also fix the composition you happened to dislike. An unrequested improvement is an interpretation, and interpretation is what this rule is against.
25
- - **Don't explain your reasoning about taste.** They did not ask why; they asked to see it. If a request is genuinely impossible, say what stopped you in one line and show the nearest thing you could make.
26
- - **Don't offer a critique they didn't ask for.** When they want a second opinion they will ask, and there are graded review loops for it.
27
- - **Ask at most one question, and only when you truly cannot proceed.** Everything else you resolve by making something and showing it — a wrong first attempt they can react to is worth more than a right question they have to answer.
58
+ - **Take the brief literally.** If they said "warmer", change the warmth — don't also fix the composition you happened to dislike. Put their words on the page exactly; an unrequested improvement is an interpretation.
59
+ - **Don't explain your reasoning about taste.** They did not ask why; they asked to see it. If a request is impossible, say what stopped you in one line and show the nearest thing you could make.
60
+ - **Don't offer a critique they didn't ask for.** When they want a second opinion they will ask.
61
+ - **Ask at most one question, and only when you truly cannot proceed.** A wrong first attempt they can react to is worth more than a right question they have to answer.
28
62
 
29
63
  ## The third rule: arrive precalculated
30
64
 
31
65
  Setup is your job, and it should already be done when they get here. **A session that opens with questions is a form.**
32
66
 
33
- - **Load the look before you make anything.** The instance's palette, tokens, voice and style rules live in [`config/branding.neutral.json`](../../config/branding.neutral.json) ([contract](../branding-contract.md)), `DESIGN.md`, and the instance's own identity scaffold [`docs/project-context.template.md`](../project-context.template.md). Read them first, silently.
34
- - **Have the options ready.** Where a choice is coming, generate the candidates before you ask, so the question is "which of these" over pictures — never "what would you like" over a blank.
35
- - **Never present a checklist.** No numbered intake questions, no "please confirm the following", no form. One line of orientation, then the work.
36
- - **Locked things stay locked.** A palette, a rubric, or a token contract is not edited to make one asset pass — that is whole-project drift. Changing one needs an ADR.
67
+ - **Load the look before you make anything.** The palette, tokens, voice and style rules live in [`config/branding.neutral.json`](../../config/branding.neutral.json) ([contract](../branding-contract.md)), `DESIGN.md`, and the identity scaffold [`docs/project-context.template.md`](../project-context.template.md). Read them first, silently.
68
+ - **Have the options ready.** Where a choice is coming, make the candidates before you ask, so the question is "which of these" over pictures — never "what would you like" over a blank.
69
+ - **Never present a checklist.** One line of orientation, then the work.
70
+ - **Locked things stay locked.** A palette, a rubric, or a token contract is not edited to make one asset pass. Changing one needs an ADR.
37
71
 
38
72
  ---
39
73
 
40
74
  ## Step 0 — is an artist here?
41
75
 
42
- - Someone is present to look and react → **interactive mode**: show, react, iterate. Loop until they are happy; each pass ends in a picture.
43
- - Autonomous, bypass-permissions, or scheduled → **autonomous mode**: nobody is watching the images, so do not narrate into the void and do not lower the bar. Make it, gate it hard against whatever standard the surface has, stage the passes for review, and park them. In the session log give the preview URL and one line per asset — so the first thing the returning artist does is *look*, not read.
76
+ - Someone is present to look and react → **interactive mode**: show, react, iterate, each pass ending in a picture.
77
+ - Autonomous, bypass-permissions, or scheduled → **autonomous mode**: nobody is watching, so do not narrate into the void and do not lower the bar. Make it, gate it hard, stage it for review, and park it. **Never approve a page in the Approval queue for an absent artist.** In the session log give the preview URL and one line per item, so the returning artist's first act is to *look*.
44
78
 
45
79
  If unsure, ask once; if no answer, treat it as autonomous.
46
80
 
47
81
  ---
48
82
 
49
- ## What the artist's work actually is here
50
-
51
- The subject varies by instance; the stance above does not. In this core the standing surfaces are:
52
-
53
- - **The project's user-facing text** — the copy desk (`modules/copy-desk/`) is the artist's review loop over live copy. It is deliberately **not a CMS**: nothing on that page edits a string. A bad line becomes a claimed, graded task like any other change.
54
- - **The project's interface** — visual and layout work is the `ui` discipline and has its own playbook (`/design`), contributed by `modules/ui-design/`. Adjacent craft, separate lane.
55
- - **A pixel-art or asset pipeline**, when the instance ships one. It is a host module and is **not** part of the portable core, so its commands, palette, and rubric live with that module rather than here; on a core-only checkout those files are simply absent. Drive whatever pipeline the instance has via its own skills — never freelance around it, and never hand-edit its locked palette or rubric without an ADR.
83
+ ## The other surfaces
56
84
 
57
- The artist role also carries a deploy-time gate of its own in some instances (ADR 0241) — the artist's authority over what the project looks like when it goes out.
58
-
59
- ---
85
+ - **The interface's form** — visual and layout work is the `ui` discipline with its own playbook (`/design`, from `modules/ui-design/`). Adjacent craft, separate lane.
86
+ - **A pixel-art or asset pipeline**, when the instance ships one. It is a host module, not the portable core, so its commands, palette and rubric live with it; on a core-only checkout they are absent. Drive it via its own skills, and never hand-edit its locked palette or rubric without an ADR.
87
+ - The artist role can carry a deploy-time gate in some instances (ADR 0241).
60
88
 
61
89
  ## Scoping art work
62
90
 
63
- When you scope or present an art task, factor in that the reader judges by eye:
64
-
65
- - **Lead with the visual target**, not paragraphs — the subject, the reference it should sit beside, an example if one exists. "Make this," shown.
66
- - **Express done-when in visual terms** — "reads as weathered marble in-world, every pixel on the locked palette" — not a procedural step list.
91
+ - **Lead with the visual target**, not paragraphs — the subject, the reference it should sit beside, an example. "Make this," shown.
92
+ - **Express done-when in visual terms**, not a procedural step list.
67
93
  - **Keep procedure out of the task.** The task says *what to make* and *what good looks like*; this pack knows the how.
68
94
 
69
- ---
70
-
71
95
  ## Feedback becomes a durable rule
72
96
 
73
- When the artist reacts — "too saturated", "that reads as modern", "weather the marble" — don't just tweak once. Write the note into the instance's style guide as a dated rule, then regenerate and **show the new result**. The loop is see → react → see again, and the guide gets smarter every pass. A tweak that lives only in one asset is a tweak you will be asked for again.
97
+ When the artist reacts — "too saturated", "that reads as modern" — don't just tweak once. Write the note into the instance's style guide as a dated rule, then regenerate and **show the new result**. A tweak that lives only in one asset is a tweak you will be asked for again.
74
98
 
75
99
  ---
76
100
 
@@ -88,6 +88,8 @@ Three manual slash-commands keep the methodology surfaces from accumulating drif
88
88
  - **`/blocker-review`** — walk the open blockers: resolved (which auto-promotes linked tasks via a DB trigger), still blocked with a note, or escalate.
89
89
  - **`/backlog-review`** — walk `status='backlog'`, the pre-workable state a human must say go on. Rows waiting on a **person** get walked (promote / kill / water); rows waiting on a **trigger** are counted, never walked (a satisfied dep auto-promotes). It also surfaces rows stranded behind an abandoned dep, which the trigger can never fire for. `/demote` is invalid on a backlog row (409 `cannot_demote` — it requires `ready`).
90
90
 
91
+ **`/tweak`** (Metic+) works a fourth queue: pages an artist submitted from the studio wait there until a session applies them. It never lands one; the artist approves first (ADR 0341).
92
+
91
93
  If a day passes without them, the queues quietly grow. Running them is the structural cure for the markdown-graveyard pattern.
92
94
 
93
95
  > **`/merge-mode` is not a daily chore** — don't run it on a schedule or tell builders to. The server lands merges itself: green PRs auto-merge, a 5-min reconciler flips `confirmed → shipped`, and the ADR 0082 resolver self-heals generated-file conflicts. It is the rare manual fallback for a strand still stuck after that sweep.
package/package-lock.json CHANGED
@@ -1,12 +1,12 @@
1
1
  {
2
2
  "name": "@bongos/core",
3
- "version": "1.19.1069",
3
+ "version": "1.19.1071",
4
4
  "lockfileVersion": 3,
5
5
  "requires": true,
6
6
  "packages": {
7
7
  "": {
8
8
  "name": "@bongos/core",
9
- "version": "1.19.1069",
9
+ "version": "1.19.1071",
10
10
  "license": "AGPL-3.0-or-later",
11
11
  "dependencies": {
12
12
  "express": "^4.21.2",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bongos/core",
3
- "version": "1.19.1069",
3
+ "version": "1.19.1071",
4
4
  "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
5
5
  "license": "AGPL-3.0-or-later",
6
6
  "main": "src/platform-server.js",
@@ -7715,5 +7715,21 @@
7715
7715
  "id": "1004326",
7716
7716
  "text": "The Ideas and Copy desk tabs are gone from the hall's sidebar, as you decided. Nothing was deleted: both pages still open from their old links and bookmarks, and every idea and flag is kept. New ideas are filed from Your think"
7717
7717
  }
7718
+ ],
7719
+ "1.19.1070": [
7720
+ {
7721
+ "id": "1004333",
7722
+ "text": "The artist's guide now starts with the studio. An artist's AI session reading it learns the whole Tweak Mode loop: pick up where they left off, take the suggested page or pick another, rewrite every word in the editor (or in W"
7723
+ },
7724
+ {
7725
+ "id": "1003783",
7726
+ "text": "Decided how modules in the store are grouped: eight broad sections, each with narrow sub-categories that authors suggest and trusted builders approve, so the top-ten limit compares like with like."
7727
+ }
7728
+ ],
7729
+ "1.19.1071": [
7730
+ {
7731
+ "id": "1003790",
7732
+ "text": "Decided how the store scores modules: a failed security check keeps a module out, the rest is averaged, and buyers can see each part of the score to pick the module that is best at what they need."
7733
+ }
7718
7734
  ]
7719
7735
  }
package/src/module-api.js CHANGED
@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
71
71
  // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
72
72
  // the entry to that file. Look for a version's history there, not here.
73
73
  // ---------------------------------------------------------------------------
74
- const CORE_VERSION = '1.19.1069'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
74
+ const CORE_VERSION = '1.19.1071'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
75
75
 
76
76
  // A namespaced logger so a module's log lines are attributable + consistent.
77
77
  // Usage: const log = api.logger('dev-box'); log.info('mounted');