@bongos/core 1.19.1069 → 1.19.1070

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.1069",
-  "core_contract": "1.19.1069",
-  "source_commit": "4c59b7289049e05edb0eea145d6fb49cbbee6198",
+  "core_version": "1.19.1070",
+  "core_contract": "1.19.1070",
+  "source_commit": "29b03916fdfb3db5873c375368034d583292771c",
   "source_ref": "HEAD",
-  "built_at": "2026-09-28T19:09:33.736Z",
+  "built_at": "2026-09-28T19:26:10.902Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 547,
+    "docs_redacted": 548,
     "agent_docs_stubbed": 26,
     "functional_verbatim": 2560,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 3134,
-  "tree_sha256": "537e8455ba0fa27c76b31b538e142554e4e40ecae9ea216212318d394bb06c44",
+  "file_count": 3135,
+  "tree_sha256": "5963a33209a60bdef8a18d5e3079f967a2904f56eb3d1c272ae6732bca49b6d7",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -127,7 +127,7 @@
     {
       "path": ".claude/skills/design/SKILL.md",
       "mode": "0000644",
-      "sha256": "2ffaa5f9c6b6ff5b9a3a4730b4d172cdb905f1ed5efa879d3b14dca5ae60aeeb"
+      "sha256": "cd200f943e1022cb023a40c936760c2471ea536e9bd74a258e4ecc1bdaf285a8"
     },
     {
       "path": ".claude/skills/feedback/SKILL.md",
@@ -2174,10 +2174,15 @@
       "mode": "0000644",
       "sha256": "9229f8449bfa7d80918239f031dd3b9147557be34109eb74841b740c8a90e36f"
     },
+    {
+      "path": "docs/adr/0342-module-categories-are-eight-parents-with-approved-sub-categories.md",
+      "mode": "0000644",
+      "sha256": "f847a769842c5c57a86ef8951e685da3b61474029b54b6620046713de7c6c93c"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "33c5508da42392b6ecc70ef3a0c1951714cb0a22551765c3e87213c1fc9bc253"
+      "sha256": "9191ebf6660a5edb6ab14ece27019e8c1a5a6dae90df22dc1ec90b0cb1f331d1"
     },
     {
       "path": "docs/api-reference.md",
@@ -2747,7 +2752,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "48c692393e73b1e449efb38943ea3da0a729ab4da17b800a42bb2d8b664732c3"
+      "sha256": "9b2a2c13ff569477f2f082fa8b9d55b8d0a67ba4bbb4984f082b622d1e11020b"
     },
     {
       "path": "docs/modules-contract.md",
@@ -2822,12 +2827,12 @@
     {
       "path": "docs/packs/artist.md",
       "mode": "0000644",
-      "sha256": "ef94247b390fe32676c910545c35a7cfd39bb2ed87680174d7bd590eb1fbe2af"
+      "sha256": "9d317443b3676bf68b7818473e75448e26a16c6316cad7298de7a4037d73cf5c"
     },
     {
       "path": "docs/packs/engineer.md",
       "mode": "0000644",
-      "sha256": "942fcc04e8e47520f6ea071fae30ab0d1ad6c86f4c241c489ded38793650cfa9"
+      "sha256": "416aa7f4303a0148d52ab5c0e5720a327fa260a034a9558774df125e8876eee2"
     },
     {
       "path": "docs/packs/ideator.md",
@@ -8637,12 +8642,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "de479d6d3ae388d49f8adb2d8945ba24f23235de3276bfd9eaa4b43fb7e6c405"
+      "sha256": "3019ba0c99d39d85cc43a7d282172015e852587e60a74d25488747923c86fd09"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "e0e5e53a67714ab29b287611770cf7f43fb845ca5f8a254e3f71dfd622ffab2c"
+      "sha256": "d72cc720cb066ca355eacbf9cb7dfe58b705321eb8f6f7c399bea6ce595cff77"
     },
     {
       "path": "public-docs/index.html",
@@ -8662,7 +8667,7 @@
     {
       "path": "release-notes.json",
       "mode": "0000644",
-      "sha256": "49cde2a1d388b5ee848bfed8c77a05ea19235bd435e4e0be35d881ba2b0e967d"
+      "sha256": "2af6ab7d17b6dbe0b5d4cd3f4b78cc6867b3e15c9ea184e464b8d34a5b6637ca"
     },
     {
       "path": "scripts/bongos-mcp.js",
@@ -10752,7 +10757,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "e9280eaa631dbe84e6bd882305919b8ad956bc642ecd2d2a5d7aa7639dc05789"
+      "sha256": "0a84382c9ce6c0a49fe3e6bcc694047b8cda6c731c57d10e99c71819d606d340"
     },
     {
       "path": "src/module-loader/catalog.js",

package/.claude/skills/design/SKILL.md

@@ -98,7 +98,7 @@ A look that is not listed here is not in the library. Adding one is the README's
 
 - 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.
 - A page-private palette, a hex that isn't one of the fifteen, a `:root` in a page, motion in JavaScript.
-- Text: the copy half belongs to `copy-desk` — flag a string, don't rewrite the product's voice in passing.
+- 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.
 - 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.
 
 ## How sessions reach this skill

package/docs/adr/0342-module-categories-are-eight-parents-with-approved-sub-categories.md

@@ -0,0 +1,83 @@
+# ADR 0342 — Module categories are eight fixed parents, with narrow sub-categories an author proposes and Metic+ approves
+
+- **Status:** accepted
+- **Date:** 2026-09-28
+- **Task:** [task 1003783](https://cloudbongos.com/builders#/task/1003783) (goal 1000091 — working area 5, Module distribution & economy)
+- **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.
+- **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)
+
+## Context
+
+The owner's listing rule is a quality floor, then ranking, then **at most ten listed per
+comparable category** — "fifteen Stripe modules all over 94% still show only the top ten". A
+cap needs a set to count within, and nothing in the module contract carries a category today.
+The owner has already ruled that categories are **nested**: a module sits in a sub-category
+inside a parent.
+
+The comparable set is the narrow one a buyer actually chooses between ("Stripe payments"), not
+a broad department. If it's too broad, the cap hides good modules that don't compete with each
+other. If it's too narrow, every module is top-ten in a category of one and the cap does nothing.
+
+## Decision
+
+### D1 — Eight parent categories, fixed
+
+Derived from the modules that exist today (the roster under `modules/`):
+
+| Parent | Key | Today's modules that would sit in it |
+|---|---|---|
+| Work & planning | `work` | lifecycle, ideas, agents, autonomy |
+| Team & people | `people` | onboarding, government, platform-identity, builder-settings, specialities |
+| Quality & review | `quality` | grading, security, copy-desk |
+| Money | `money` | economy |
+| Communication | `communication` | discord |
+| Pages & design | `pages` | hall-ui, public-landing, status-ui, ui-design |
+| Hosting & deploy | `hosting` | provisioning, npm-release, dev-box |
+| Knowledge | `knowledge` | memory, sessions |
+
+A parent is for browsing only. **The cap is never applied at the parent level.** Changing the
+parent list needs a new ADR.
+
+### D2 — The sub-category is the comparable set, and the cap applies there
+
+Every listed module has exactly one sub-category under exactly one parent. The cap of ten, the
+ranking and the per-category comparison (task 1003800) all run within a sub-category.
+
+### D3 — The author proposes a sub-category; Metic+ approves it
+
+When publishing, an author picks a parent and either picks an existing sub-category or proposes
+a new one. A proposed sub-category is **not live** until a Metic+ builder approves it, renames
+it, or merges it into an existing one. Until then the module is listed under its parent with no
+sub-category, and it counts toward no cap.
+
+This is the owner's choice, and the reason is the cap itself. If authors named sub-categories
+freely, "Stripe", "Stripe payments" and "Payments (Stripe)" would become three categories with
+five modules each, and the cap would never bite. An approver merging near-duplicates is what
+keeps the comparable set real.
+
+### D4 — One sub-category per module
+
+A module that does two unrelated jobs picks the one it competes on. Multiple sub-categories
+would let one module take a top-ten slot in several places, and the cap is meant to make slots
+scarce.
+
+## Consequences
+
+- **Task 1003784** (nested category in the manifest and both catalog surfaces) builds to this:
+  `category: { parent, sub }`. `parent` is one of the eight keys, and `sub` is the key of an
+  approved sub-category or absent while a proposal is pending.
+- **An approval queue** for proposed sub-categories is new work, not yet filed. It needs a
+  Metic+ permission key and follows the same pattern as the score override (task 1003796).
+- **Core modules get categories too**, so the catalog is consistent. The table in D1 is their
+  starting assignment.
+- **The cap (task 1003809)** counts listed modules per approved sub-category, never per parent.
+
+## Rejected
+
+- **Authors name sub-categories freely.** Near-duplicate names defeat the cap.
+- **Only Metic+ creates sub-categories.** An author with a genuinely new kind of module would
+  have to wait for someone else to make the category first.
+- **A flat list of categories.** The owner specified nested. A flat list forces a choice
+  between browsable-but-broad and comparable-but-endless.
+- **Capping at the parent level.** Ten modules across all of "Money" would hide good modules
+  that don't compete with each other.

package/docs/adr/README.md

@@ -433,3 +433,4 @@ This keeps the decision history honest and traceable.
 | 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 |
 | 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 |
 | 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 |
+| 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 |

package/docs/module-api-changelog.md

@@ -2625,5 +2625,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.1067 with no explicit bump. run 36467481353. (task 1002620)
   1.19.1069 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.1068 with no explicit bump. run 36470192310. (task 1002620)
+  1.19.1070 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.1069 with no explicit bump. run 36472133987. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/packs/artist.md

@@ -6,71 +6,95 @@ An art session is not the engineer's text-heavy build loop. The artist's subject
 
 ---
 
+## Where the artist works: the studio
+
+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.
+
+**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:
+
+- **Resume** — shown only while they hold a page; back into the editor on it, with "N of M lines" rewritten so far.
+- **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.
+- **Approval queue** — the pages a session has applied, waiting for them (below).
+- **Artist Review Status** — three lines, landing, builders hall and status, each "N of M tweaked".
+
+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.
+
+**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:
+
+- **open the page ↗** — the live page in a new tab, to read it in place;
+- **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;
+- **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.
+
+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.
+
+**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.**
+
+**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:
+
+- **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;
+- **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.
+
+**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.
+
+**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.
+
+---
+
 ## The first rule: show, don't narrate
 
 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.
 
 > **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.
 
-- **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.
-- **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.
-- **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.
-- **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.
+- **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.
+- **Collapse the plumbing to one-liners.** "Saved, 12 of 38 lines rewritten" beats three paragraphs.
+- **Verification is looking, not reading.** Surface the rendered page, not console logs. Logs are for when something breaks.
+- **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.
 
 ## The second rule: as little interpretation as possible
 
 The artist owns the look; you own the rendering. **You are their hands, not their art director.**
 
-- **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.
-- **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.
-- **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.
-- **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.
+- **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.
+- **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.
+- **Don't offer a critique they didn't ask for.** When they want a second opinion they will ask.
+- **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.
 
 ## The third rule: arrive precalculated
 
 Setup is your job, and it should already be done when they get here. **A session that opens with questions is a form.**
 
-- **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.
-- **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.
-- **Never present a checklist.** No numbered intake questions, no "please confirm the following", no form. One line of orientation, then the work.
-- **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.
+- **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.
+- **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.
+- **Never present a checklist.** One line of orientation, then the work.
+- **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.
 
 ---
 
 ## Step 0 — is an artist here?
 
-- Someone is present to look and react → **interactive mode**: show, react, iterate. Loop until they are happy; each pass ends in a picture.
-- 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.
+- Someone is present to look and react → **interactive mode**: show, react, iterate, each pass ending in a picture.
+- 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*.
 
 If unsure, ask once; if no answer, treat it as autonomous.
 
 ---
 
-## What the artist's work actually is here
-
-The subject varies by instance; the stance above does not. In this core the standing surfaces are:
-
-- **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.
-- **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.
-- **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.
+## The other surfaces
 
-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.
-
----
+- **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.
+- **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.
+- The artist role can carry a deploy-time gate in some instances (ADR 0241).
 
 ## Scoping art work
 
-When you scope or present an art task, factor in that the reader judges by eye:
-
-- **Lead with the visual target**, not paragraphs — the subject, the reference it should sit beside, an example if one exists. "Make this," shown.
-- **Express done-when in visual terms** — "reads as weathered marble in-world, every pixel on the locked palette" — not a procedural step list.
+- **Lead with the visual target**, not paragraphs — the subject, the reference it should sit beside, an example. "Make this," shown.
+- **Express done-when in visual terms**, not a procedural step list.
 - **Keep procedure out of the task.** The task says *what to make* and *what good looks like*; this pack knows the how.
 
----
-
 ## Feedback becomes a durable rule
 
-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.
+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.
 
 ---
 

package/docs/packs/engineer.md

@@ -88,6 +88,8 @@ Three manual slash-commands keep the methodology surfaces from accumulating drif
 - **`/blocker-review`** — walk the open blockers: resolved (which auto-promotes linked tasks via a DB trigger), still blocked with a note, or escalate.
 - **`/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`).
 
+**`/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).
+
 If a day passes without them, the queues quietly grow. Running them is the structural cure for the markdown-graveyard pattern.
 
 > **`/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

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.1069",
+  "version": "1.19.1070",
   "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/release-notes.json

@@ -7715,5 +7715,15 @@
       "id": "1004326",
       "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"
     }
+  ],
+  "1.19.1070": [
+    {
+      "id": "1004333",
+      "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"
+    },
+    {
+      "id": "1003783",
+      "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."
+    }
   ]
 }

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // 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.1069'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.1070'; // 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');