@bongos/core 1.24.8 → 1.24.10

package/docs/module-api-changelog.md

@@ -3274,5 +3274,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.24.6 with no explicit bump. run 41030210485. (task 1002620)
   1.24.8 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.24.7 with no explicit bump. run 41031365595. (task 1002620)
+  1.24.9 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.24.8 with no explicit bump. run 41035048464. (task 1002620)
+  1.24.10 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.24.9 with no explicit bump. run 41037036590. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/modules-contract.md

@@ -176,7 +176,7 @@ closed on every unknown, including a ledger read it cannot complete.
 
 **Attribution (`author`/`origin`/`license`/`maintainer`) is portable metadata, not a cross-Bongos link** — each repo runs its own Bongos with its own builder identities ([ADR 0100](adr/0100-two-repo-instance-model.md) §3), so credit travels *with the module* rather than through a foreign key ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §2). `bongos module new` stamps all four as TODO placeholders (license defaults to `AGPL-3.0`) so a module carries its authorship from the day it's scaffolded, not bolted on later at upstream-submit time.
 
-**`bongos module store [--sort <part>] [--max-cents N] [--max-credits N] [--json]`** (task 1003811) is the **store** from the terminal: what the catalog lists, in its order — listed modules ranked, then New ones, unranked — with each module's score, price and place (parent, and sub-category once approved). It asks `GET /store/modules`, the same read the hall's "In the store" group makes, and filters, ranks and caps nothing itself: the quality floor, the ranking and the cap of ten per sub-category live only in `src/bongos/module-listing.js`, so the hall and the terminal cannot disagree about which modules are the best. `tests/module_store_cli.mjs` sends the same queries through the API and the CLI and requires the same modules in the same order.
+**`bongos module store [--sort <part>] [--max-cents N] [--json]`** (task 1003811) is the **store** from the terminal: what the catalog lists, in its order — listed modules ranked, then New ones, unranked — with each module's score, price and place (parent, and sub-category once approved). It asks `GET /store/modules`, the same read the hall's "In the store" group makes, and filters, ranks and caps nothing itself: the quality floor, the ranking and the cap of ten per sub-category live only in `src/bongos/module-listing.js`, so the hall and the terminal cannot disagree about which modules are the best. `tests/module_store_cli.mjs` sends the same queries through the API and the CLI and requires the same modules in the same order.
 
 **`bongos module list [--catalog] [--search <text>] [--json]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §2/§3, [ADR 0167](adr/0167-module-catalog-source-vs-provenance.md)) is the browsable catalog from the terminal: every module on disk with its enabled state, its author + origin credit, and its upkeep posture. `--catalog` narrows to the **core-shipped** modules — the shared catalog an instance opts into (§6, default-off). Two axes travel on each row and they are *not* the same question: **`source`** (which tree ships it — the core package or this instance's own repo, read structurally from the loader's discovery root, [ADR 0108](adr/0108-instance-composition-configurable-root.md) §1) and **`provenance`** (who built it, derived from the declared `origin`). A core module that declares no attribution is credited to the platform and the credit is **marked inferred** (`*`) rather than left blank or silently invented. The hall's Modules tab renders the same model (`src/module-loader/catalog.js`) via `GET /modules`, so the two surfaces cannot drift.
 
@@ -400,8 +400,8 @@ Run `bongos upgrade` to confirm coreVersion compatibility, then `node scripts/bo
 - **Tester feedback** (task 1003806, ADR 0344 D5). While a version is on the tester channel, what tester projects report about it becomes its Tester feedback part: the share of testers whose install worked and who hit no runtime errors, blended with ten neutral testers so a small sample cannot score high — `round(100 × (went well + 5) / (testers + 10))`. Reports from after the version left the tester channel, and the author's own, never count; under 3 testers it is not scored yet. The rule is `assessTesterFeedback` in `scripts/bongos/module-assess-installs.js`.
 - **What a module is strong and weak at** (task 1003799, ADR 0343 D4). Each catalog entry also carries `parts` (the current result of Tests, Clean installs, Reliability, Tester feedback and How-to) and a reading of them: `strengths` (a part scored **80 or more**), `weaknesses` (a part scored **below the floor**) and `unmeasured` (a part with no score yet, which is never counted as weak). Each strength and weakness has a one-sentence `detail` saying what the number rests on. Security is not among them: every listed version has passed it. The reading is `readParts` in `src/bongos/module-listing.js`; the hall's Modules tab shows it in its "In the store" group, so two modules with the same overall score can be told apart.
 - **Sorting by a part** (task 1003800). `GET /store/modules?sort=<part>` orders the listed modules by one part a buyer cares about: `tests`, `install`, `reliability`, `tester_feedback` or `docs` (the response lists them as `sort_parts`, and says which one it applied as `sort`). Modules with a score for that part come first, highest first; a tie goes to the higher overall score, then the module key. A module with no score for that part goes last, so missing data never wins or loses a place on its own. New modules are not sorted: they are never ranked. Any other `sort` value is refused with a 400. Without `sort`, the listed modules are in the ranking below; New stays in key order. The rule is `sortByPart` in `src/bongos/module-listing.js`.
-- **Setting a price** (task 1004894). A module's author sets its price with `bongos module price <key> [--cents N] [--credits N]` (or the same two flags on `bongos module publish`, which sets the price right after the upload), or `POST /store/modules/:key/price { cents?, credits? }` (the `module.submit` permission, the same one that publishes, and only the author passes; a delisted module takes no new price). Each amount is a whole number of 0 or more, or null for "not offered in that currency"; at least one is given, and 0 in either makes the module free. Every change appends a row to the price history (in one transaction, the module row locked) naming who set it and when, so the history is the audit of what each price replaced, and the newest is current: it is what the catalog shows and what acquire charges. A paid price may be set before buying exists (owner, 2026-10-26): the catalog lists the module with its price and `buyable: false`, `bongos module store` prints it as not yet buyable, and acquire keeps refusing it without an entitlement. When buying ships (task 1003788), `BUYING_OPEN` in `src/bongos/module-listing.js` is the one switch to flip. Price is never an input to the score (ADR 0343 D6).
-- **The ranking, and a maximum price** (task 1003808, owner decision 2026-10-23). Without `sort`, listed modules are ranked **quality first**: highest overall score first; between equal scores, free modules first, then the lowest cash price, then the lowest credit price, then the module key. Price never buys a better place, it only orders modules the score could not tell apart (and it is never an input to the score, ADR 0343 D6). The response states the rule as `ranking`, and each entry carries its current `price` (`cents`, `credits`, `free`). A buyer may add `?max_cents=` and/or `?max_credits=` (whole numbers, 0 or more): modules that cost more are left out of both lists, free modules always stay, and a priced module stays when it is offered at or under a cap the buyer set. The applied caps come back as `max_price`. The rules are `rankListed` and `withinMaxPrice` in `src/bongos/module-listing.js`.
+- **Setting a price** (task 1004894; cash only since task 1004989). A module's author sets its price with `bongos module price <key> --cents N` (or `--cents N` on `bongos module publish`, which sets the price right after the upload), or `POST /store/modules/:key/price { cents }` (the `module.submit` permission, the same one that publishes, and only the author passes; a delisted module takes no new price). The amount is a whole number of cents, 0 or more; 0 makes the module free. **Credits never price or buy a module** ([ADR 0385](adr/0385-money-lives-with-a-processor-credits-stay-a-project-meter.md) decision 2): the route refuses a `credits` field by name (`credit_price_refused`), the CLI refuses `--credits`, and `migrations/core_287_module_prices_cash_only.sql` refuses `price_credits` on any new row in the database (NOT VALID, so the old rows stay readable). An old row priced only in credits reads as **price coming** (`price.coming: true`): the module stays listed, is never buyable with credits, and its author sees `price_prompt` on `GET /store/modules/:key/listing` asking for a cash price (owner, 2026-10-29). An old row that offered the module at 0 credits stays free, as it was. Every change appends a row to the price history (in one transaction, the module row locked) naming who set it and when, so the history is the audit of what each price replaced, and the newest is current: it is what the catalog shows and what acquire charges. A paid price may be set before buying exists (owner, 2026-10-26): the catalog lists the module with its price and `buyable: false`, `bongos module store` prints it as not yet buyable, and acquire keeps refusing it without an entitlement. When buying ships (task 1003788), `BUYING_OPEN` in `src/bongos/module-listing.js` is the one switch to flip; a price-coming module stays unbuyable even then. Price is never an input to the score (ADR 0343 D6).
+- **The ranking, and a maximum price** (task 1003808, owner decision 2026-10-23). Without `sort`, listed modules are ranked **quality first**: highest overall score first; between equal scores, free modules first, then the lowest cash price, a price still coming last, then the module key. Price never buys a better place, it only orders modules the score could not tell apart (and it is never an input to the score, ADR 0343 D6). The response states the rule as `ranking`, and each entry carries its current `price` (`cents`, `free`, `coming`) — never a credit amount. A buyer may add `?max_cents=` (a whole number, 0 or more): modules that cost more are left out of both lists, free modules always stay, and a module whose price is still coming has no cash price to compare, so a cap leaves it out. There is no credit cap; `?max_credits=` is refused. The applied cap comes back as `max_price`. The rules are `rankListed` and `withinMaxPrice` in `src/bongos/module-listing.js`.
 - **The cap: at most ten per sub-category** (task 1003809, [ADR 0342](adr/0342-module-categories-are-eight-parents-with-approved-sub-categories.md) D2). Above the floor, at most **ten** modules are listed in each approved sub-category: the first ten in the ranking above, so a buyer's `sort` or maximum price reorders or narrows those ten but never lets the eleventh in. The cap is never applied to a parent. A module whose sub-category is only proposed is listed under its parent and counts toward no cap, and a New module is not ranked, so it neither takes a slot nor is held by one. The catalog returns the cap as `cap`. The rule is `applyCap` in `src/bongos/module-listing.js`.
 - **Why a module is not listed** (task 1003810). `GET /store/modules/:key/listing` says where one module stands, judging the same newest version the catalog does: `listed` (true or false), a `reason` (`not_assessed`, `security_not_passed`, `no_score`, `below_floor`, `delisted`, `no_version`, `over_cap`, `new` or `at_or_above_floor`), `why` in a sentence and `next_step` saying what would change it. A failed Security gate is told apart from one that has not finished, and names what it found to the module's author only (to anyone else it would point at a weakness not fixed yet); below the floor names the score, the floor and the weakest parts. It carries the same `parts`, `strengths`, `weaknesses` and `unmeasured` as the catalog, plus `security`. Any signed-in builder can read it. Past the cap it is `over_cap`, which names the score, the module's place in its sub-category and the cap, so an author can tell being eleventh apart from being below the floor. Both responses carry the module's `category` (`parent`, `parent_title`, and `sub` and `label` once its sub-category is approved). The rule is `explainPlacement` in `src/bongos/module-listing.js`.
 - **Sub-categories are approved before they count** (task 1004355, ADR 0342 D3). A module names `category: { parent, sub }` in `module.json`; `GET /store/subcategories` lists the approved ones under each of the eight parents. A `sub` the store has not seen under that parent is **proposed** at publish (labelled from its key) and the publish answer's `category` says so (`status: "proposed"`, `live: false`): until a Metic+ person decides, the module sits under its parent only and counts toward no cap. The review queue (`GET /store/subcategories/queue`, atom `module.subcategory.review`, metic + archon via `government_033`) shows each proposal with the modules that named it and its near-duplicate names; `POST /store/subcategories/:id/approve { label?, sub_key? }` makes it live, renamed first if asked (a rename onto an existing key is refused — merge instead), and `POST /store/subcategories/:id/merge { into }` folds it into an approved one and moves its modules there. A later publish naming a merged key lands on its target. Where a module sits is `store_module_categories` (core_278), apart from the manifest; `readModuleCategories` in `src/bongos/module-subcategories.js` is the read the cap uses.

package/docs/page-inventory.json

@@ -10,10 +10,10 @@
     "An id changes only when the host prefix, the data-page value or the file name changes; that is a rename, and records keyed on the old id move with it."
   ],
   "counts": {
-    "pages": 49,
+    "pages": 50,
     "surfaces": 3,
-    "with_states": 42,
-    "states": 369
+    "with_states": 43,
+    "states": 371
   },
   "surfaces": [
     {
@@ -22,7 +22,7 @@
       "at": "modules/hall-ui/public",
       "answers_at": "host prefix builders.",
       "origin": "https://builders.{apex}",
-      "pages": 37
+      "pages": 38
     },
     {
       "id": "landing",
@@ -783,6 +783,36 @@
         "out"
       ]
     },
+    {
+      "id": "builders:market-watch-settings",
+      "surface": "builders",
+      "module": "hall-ui",
+      "page": "market-watch-settings",
+      "id_from": "data-page",
+      "title": "Market Watch",
+      "document_title": "Market Watch settings — {{worldName}}",
+      "path": "/market-watch-settings",
+      "url": "https://builders.{apex}/market-watch-settings",
+      "files": [
+        "modules/hall-ui/public/market-watch-settings.html",
+        "modules/hall-ui/public/style.css",
+        "modules/hall-ui/public/market-watch-settings.css",
+        "modules/hall-ui/public/dom-utils.js",
+        "modules/hall-ui/public/shell-trail.js",
+        "modules/hall-ui/public/craft-mode.js",
+        "modules/hall-ui/public/shell.js",
+        "modules/hall-ui/public/palette.js",
+        "modules/hall-ui/public/hall-kit.js",
+        "modules/hall-ui/public/market-watch-settings.js"
+      ],
+      "states_files": [
+        "modules/hall-ui/public/market-watch-settings.states.json"
+      ],
+      "states": [
+        "gauge",
+        "out"
+      ]
+    },
     {
       "id": "builders:modules",
       "surface": "builders",