@bongos/core 1.19.1070 → 1.19.1072
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 +23 -13
- package/docs/adr/0343-a-module-score-is-a-security-gate-then-an-average-of-visible-parts.md +86 -0
- package/docs/adr/0344-a-tester-is-a-project-that-opts-in-once.md +77 -0
- package/docs/adr/README.md +2 -0
- package/docs/module-api-changelog.md +4 -0
- package/package-lock.json +2 -2
- package/package.json +1 -1
- package/release-notes.json +12 -0
- package/src/module-api.js +1 -1
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.
|
|
6
|
-
"core_contract": "1.19.
|
|
7
|
-
"source_commit": "
|
|
5
|
+
"core_version": "1.19.1072",
|
|
6
|
+
"core_contract": "1.19.1072",
|
|
7
|
+
"source_commit": "48d55ade62291fbba8936935b42af6a649afe2fb",
|
|
8
8
|
"source_ref": "HEAD",
|
|
9
|
-
"built_at": "2026-09-28T19:
|
|
9
|
+
"built_at": "2026-09-28T19:44:55.659Z",
|
|
10
10
|
"redaction": {
|
|
11
11
|
"model": "docs-redacted+functional-verbatim",
|
|
12
|
-
"docs_redacted":
|
|
12
|
+
"docs_redacted": 550,
|
|
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":
|
|
20
|
-
"tree_sha256": "
|
|
19
|
+
"file_count": 3137,
|
|
20
|
+
"tree_sha256": "9f1989ff166c82430f3ddabbe39fefb2fb4ddee0f2e12cf747c100b5954c9957",
|
|
21
21
|
"files": [
|
|
22
22
|
{
|
|
23
23
|
"path": ".claude/skills/ask-for-help/SKILL.md",
|
|
@@ -2179,10 +2179,20 @@
|
|
|
2179
2179
|
"mode": "0000644",
|
|
2180
2180
|
"sha256": "f847a769842c5c57a86ef8951e685da3b61474029b54b6620046713de7c6c93c"
|
|
2181
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
|
+
},
|
|
2187
|
+
{
|
|
2188
|
+
"path": "docs/adr/0344-a-tester-is-a-project-that-opts-in-once.md",
|
|
2189
|
+
"mode": "0000644",
|
|
2190
|
+
"sha256": "ca2a376a0c555f28a3ce82542f9e7b5ac4d5da1713bf0a423087515a81d8ee7e"
|
|
2191
|
+
},
|
|
2182
2192
|
{
|
|
2183
2193
|
"path": "docs/adr/README.md",
|
|
2184
2194
|
"mode": "0000644",
|
|
2185
|
-
"sha256": "
|
|
2195
|
+
"sha256": "f319359f17b3ae842b73ea32f7150915189048d7faf55b77d43fa0129835daf0"
|
|
2186
2196
|
},
|
|
2187
2197
|
{
|
|
2188
2198
|
"path": "docs/api-reference.md",
|
|
@@ -2752,7 +2762,7 @@
|
|
|
2752
2762
|
{
|
|
2753
2763
|
"path": "docs/module-api-changelog.md",
|
|
2754
2764
|
"mode": "0000644",
|
|
2755
|
-
"sha256": "
|
|
2765
|
+
"sha256": "45f4eae24f6557f3bbec81455b4ec6020f9941477f557415f184ff2c0287490e"
|
|
2756
2766
|
},
|
|
2757
2767
|
{
|
|
2758
2768
|
"path": "docs/modules-contract.md",
|
|
@@ -8642,12 +8652,12 @@
|
|
|
8642
8652
|
{
|
|
8643
8653
|
"path": "package-lock.json",
|
|
8644
8654
|
"mode": "0000644",
|
|
8645
|
-
"sha256": "
|
|
8655
|
+
"sha256": "6d69aeb12a310ff98b05459e0a7a9d070267e953de7d9dc9836368b4d3034090"
|
|
8646
8656
|
},
|
|
8647
8657
|
{
|
|
8648
8658
|
"path": "package.json",
|
|
8649
8659
|
"mode": "0000644",
|
|
8650
|
-
"sha256": "
|
|
8660
|
+
"sha256": "45e245a9e6d915f4e6625b5bf21be85d69a5d97a787acf1f790ff75e65f41d46"
|
|
8651
8661
|
},
|
|
8652
8662
|
{
|
|
8653
8663
|
"path": "public-docs/index.html",
|
|
@@ -8667,7 +8677,7 @@
|
|
|
8667
8677
|
{
|
|
8668
8678
|
"path": "release-notes.json",
|
|
8669
8679
|
"mode": "0000644",
|
|
8670
|
-
"sha256": "
|
|
8680
|
+
"sha256": "f04ac4ef2f41e8c246bc190e16b649ff8251a49d682a3eec0830a6595d816756"
|
|
8671
8681
|
},
|
|
8672
8682
|
{
|
|
8673
8683
|
"path": "scripts/bongos-mcp.js",
|
|
@@ -10757,7 +10767,7 @@
|
|
|
10757
10767
|
{
|
|
10758
10768
|
"path": "src/module-api.js",
|
|
10759
10769
|
"mode": "0000644",
|
|
10760
|
-
"sha256": "
|
|
10770
|
+
"sha256": "c62ff0384b44fb6900657484cd1e5d53e8920d1f815d8af3b247aecc605f795c"
|
|
10761
10771
|
},
|
|
10762
10772
|
{
|
|
10763
10773
|
"path": "src/module-loader/catalog.js",
|
|
@@ -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.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# ADR 0344 — A tester is a project that opts in once; an untested version reaches everyone after seven days
|
|
2
|
+
|
|
3
|
+
- **Status:** accepted
|
|
4
|
+
- **Date:** 2026-09-28
|
|
5
|
+
- **Task:** [task 1003801](https://cloudbongos.com/builders#/task/1003801) (goal 1000091 — working area 5, Module distribution & economy)
|
|
6
|
+
- **Deciders:** Will (owner of working area 5) chose the opt-in shape and the no-volunteer rule, and accepted the defaults for updates and tester pricing; Claude wrote the record.
|
|
7
|
+
- **Related:** [ADR 0338](0338-modules-travel-through-a-bongos-hosted-store.md) (the hosted store and its channel check) · [ADR 0343](0343-a-module-score-is-a-security-gate-then-an-average-of-visible-parts.md) (the security gate and tester feedback as a score part) · [ADR 0264](0264-the-ten-working-areas.md)
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
|
|
11
|
+
Criterion `wa5-staged-rollout` says willing users test a version before everyone gets it.
|
|
12
|
+
"Willing" was undecided, and the build depends on it. The open questions: does a project opt in
|
|
13
|
+
once or per module; who can opt in; what happens when nobody volunteers; does this cover
|
|
14
|
+
updates; and do testers pay.
|
|
15
|
+
|
|
16
|
+
## Decision
|
|
17
|
+
|
|
18
|
+
### D1 — A project opts in once, and can skip individual modules (owner)
|
|
19
|
+
|
|
20
|
+
Being a tester is a **per-project** setting, switched on by that project's own admin. A tester
|
|
21
|
+
project gets tester-channel versions of **every module it has**, except any module it has
|
|
22
|
+
switched to "general only".
|
|
23
|
+
|
|
24
|
+
- It is the **project**, not an individual builder, that opts in, because the project is what
|
|
25
|
+
runs the module. A builder cannot opt in someone else's project.
|
|
26
|
+
- The switch is visible and reversible. Turning it off puts the project back on general
|
|
27
|
+
versions from its next update.
|
|
28
|
+
- "Willing" is load-bearing: a project is never a tester by default.
|
|
29
|
+
|
|
30
|
+
### D2 — Testing covers updates, not only first releases
|
|
31
|
+
|
|
32
|
+
Every new version, first release or update, goes to the tester channel first. An update to a
|
|
33
|
+
module people already rely on is where an untested version does the most damage.
|
|
34
|
+
|
|
35
|
+
### D3 — An untested version reaches everyone after seven days (owner)
|
|
36
|
+
|
|
37
|
+
A new version moves from the tester channel to general **after seven days**, if it still passes
|
|
38
|
+
the security gate and its tests (ADR 0343). This applies whether or not any tester picked it up,
|
|
39
|
+
so a module nobody volunteers for still gets updated.
|
|
40
|
+
|
|
41
|
+
The seven days is the baseline. The promotion gate (task 1003804) may also promote **earlier** on
|
|
42
|
+
evidence (for example, enough clean tester installs) or **hold** a version on evidence (tester
|
|
43
|
+
errors), but it never holds one forever for lack of testers.
|
|
44
|
+
|
|
45
|
+
### D4 — Testers pay the normal price
|
|
46
|
+
|
|
47
|
+
A tester gets an early version of a module it already has, on the same terms. Being a tester is
|
|
48
|
+
not a way to get a paid module for free. **A discount or free access for testers is area 8's
|
|
49
|
+
call** (credits and payments, goal 1000092). This ADR names the question rather than deciding it.
|
|
50
|
+
|
|
51
|
+
### D5 — What testers see feeds the score
|
|
52
|
+
|
|
53
|
+
A tester project's install success, errors and crashes on a tester version are the tester
|
|
54
|
+
feedback part of the module's score (ADR 0343 D1, task 1003806).
|
|
55
|
+
|
|
56
|
+
## Consequences
|
|
57
|
+
|
|
58
|
+
- **Task 1003802** (opt in) builds a per-project tester switch plus a per-module
|
|
59
|
+
"general only" override, on the project's own admin surface.
|
|
60
|
+
- **Task 1003803** (tester channel first) applies to every published version, updates included.
|
|
61
|
+
- **Task 1003804** (promotion gate) builds to D3: seven days by default, may promote earlier or
|
|
62
|
+
hold on evidence, and never waits forever.
|
|
63
|
+
- **Task 1003805** (install/update honour the channel) serves a tester project tester versions,
|
|
64
|
+
except for its "general only" modules.
|
|
65
|
+
- **Removal is unchanged.** Under ADR 0338 D2, a version a tester already installed keeps
|
|
66
|
+
working even if it is later withdrawn.
|
|
67
|
+
|
|
68
|
+
## Rejected
|
|
69
|
+
|
|
70
|
+
- **Opt in per module only.** More control, but few projects would bother, leaving too few
|
|
71
|
+
testers.
|
|
72
|
+
- **One all-or-nothing switch.** There'd be no way to avoid early versions of a module a project
|
|
73
|
+
depends on heavily.
|
|
74
|
+
- **Waiting for a tester before general release.** A module nobody volunteers for would never be
|
|
75
|
+
updated.
|
|
76
|
+
- **Releasing to everyone at once.** Testing would only happen when volunteers happened to be
|
|
77
|
+
there.
|
package/docs/adr/README.md
CHANGED
|
@@ -434,3 +434,5 @@ This keeps the decision history honest and traceable.
|
|
|
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
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 |
|
|
438
|
+
| 0344 | [**A tester is a project that opts in once; an untested version reaches everyone after seven days** ([task 1003801](https://cloudbongos.com/builders#/task/1003801), goal 1000091 — working area 5, owner Will). Settles "willing user" for criterion `wa5-staged-rollout`. **D1 (owner):** a project's own admin switches on "tester" once and gets tester versions of every module it has, with a per-module "general only" override; never on by default; a builder cannot opt in someone else's project. **D2:** first releases and updates alike go to testers first. **D3 (owner):** a version moves to general after seven days if it still passes the security gate and tests, tested or not; the promotion gate may promote earlier or hold on evidence, never forever. **D4:** testers pay the normal price; any tester discount is area 8's call, named not decided. **D5:** tester installs, errors and crashes feed the score (ADR 0343). Rejected: per-module-only opt-in, one all-or-nothing switch, waiting for a tester, releasing at once.](0344-a-tester-is-a-project-that-opts-in-once.md) | modules / store / rollout |
|
|
@@ -2627,5 +2627,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
|
|
|
2627
2627
|
landed since 1.19.1068 with no explicit bump. run 36470192310. (task 1002620)
|
|
2628
2628
|
1.19.1070 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
|
|
2629
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)
|
|
2632
|
+
1.19.1072 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
|
|
2633
|
+
landed since 1.19.1071 with no explicit bump. run 36474285523. (task 1002620)
|
|
2630
2634
|
---------------------------------------------------------------------------
|
|
2631
2635
|
```
|
package/package-lock.json
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@bongos/core",
|
|
3
|
-
"version": "1.19.
|
|
3
|
+
"version": "1.19.1072",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "@bongos/core",
|
|
9
|
-
"version": "1.19.
|
|
9
|
+
"version": "1.19.1072",
|
|
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.
|
|
3
|
+
"version": "1.19.1072",
|
|
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",
|
package/release-notes.json
CHANGED
|
@@ -7725,5 +7725,17 @@
|
|
|
7725
7725
|
"id": "1003783",
|
|
7726
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
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
|
+
}
|
|
7734
|
+
],
|
|
7735
|
+
"1.19.1072": [
|
|
7736
|
+
{
|
|
7737
|
+
"id": "1003801",
|
|
7738
|
+
"text": "Decided who tests new module versions first: projects that switch on testing once, and a version nobody tests still reaches everyone after seven days."
|
|
7739
|
+
}
|
|
7728
7740
|
]
|
|
7729
7741
|
}
|
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.
|
|
74
|
+
const CORE_VERSION = '1.19.1072'; // 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');
|