@bongos/core 1.19.619 → 1.19.621

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.619",
-  "core_contract": "1.19.619",
-  "source_commit": "b3a494e84958a264492cf55b3525d70680f7bbda",
+  "core_version": "1.19.621",
+  "core_contract": "1.19.621",
+  "source_commit": "09c7ba3955b0789f34ce6265e17cfcf52de9f146",
   "source_ref": "HEAD",
-  "built_at": "2026-09-09T06:39:30.103Z",
+  "built_at": "2026-09-09T06:59:03.131Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 463,
+    "docs_redacted": 464,
     "agent_docs_stubbed": 24,
     "functional_verbatim": 2086,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2573,
-  "tree_sha256": "f0ad9c8d1e70405ab669163d2d2153cd7f6ae97a699036bb8e4278f1e3a435d5",
+  "file_count": 2574,
+  "tree_sha256": "76d591f3c619056f89124f5d2abb9e8d1fc2745277375693f575438d155faf7e",
   "files": [
     {
       "path": ".claude/skills/backlog-review/SKILL.md",
@@ -377,7 +377,7 @@
     {
       "path": "clients/bongos-client/README.md",
       "mode": "0000644",
-      "sha256": "7486f9978e473b0adf09f8bfcbe2a029eb2833636ae3bd55fc307ccb3e773963"
+      "sha256": "65fb7649709e966a90f431d57b8855bd39951684a754320c4a797da9e3ccac13"
     },
     {
       "path": "clients/bongos-client/bongos-client.global.js",
@@ -397,7 +397,7 @@
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "877ca14cd017c1392fcc5206c2f3603fb24becdc32670aa1e2ad0de9d930dfca"
+      "sha256": "07caf5c1db2cfd16c92713891055b477982aef4dd847af67042b742293e6a9ce"
     },
     {
       "path": "clients/bongos-client/index.mjs",
@@ -407,7 +407,7 @@
     {
       "path": "clients/bongos-client/package.json",
       "mode": "0000644",
-      "sha256": "ca32245dc6322f0399058b91f07fe12709fe7b97485fd5d8f5f37cb42f730aae"
+      "sha256": "d299252221daca415cf982b61fe5e3d9c3707c672a7d47adc052a9ee8166223f"
     },
     {
       "path": "config/branding.neutral.json",
@@ -1172,7 +1172,7 @@
     {
       "path": "docs/adr/0134-private-first-npm-distribution.md",
       "mode": "0000644",
-      "sha256": "ce1345a7de47416745964de31ec0d72cdf37f29fc1d41337b24d0e705710b0d7"
+      "sha256": "87b5f5038221e8244c3f98e6f9bc6bf64b23cf8cc758327dd5a58c9b31196fb2"
     },
     {
       "path": "docs/adr/0135-module-upstream-submission-interim-queue.md",
@@ -1812,7 +1812,7 @@
     {
       "path": "docs/adr/0258-the-public-cli-is-a-generated-client-package-not-the-published-core.md",
       "mode": "0000644",
-      "sha256": "43bf2232da3353ab49bfd956a73d09c5045e5fa155e0004d0855a50587c299cd"
+      "sha256": "e701aa98eddf2a0bde803fecfaf681502db33e67765f6a355e883cd3c714cd08"
     },
     {
       "path": "docs/adr/0259-a-projects-departure-from-the-public-list-is-public.md",
@@ -1872,17 +1872,17 @@
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "d660b4bc0bc3306f5fcf583118ca9149ba3deafe82dfe3894fe0b1c11b60cc2f"
+      "sha256": "6b90114abfa5e891a8f2ea16c547c960c982030d6228d43c2a833840123a3f69"
     },
     {
       "path": "docs/api-reference.md",
       "mode": "0000644",
-      "sha256": "b430ecad01c7458dc893c11d976d3ae35f2dd5b8310e451a38af387908f64659"
+      "sha256": "8adebe11d51d4bbce7e5acacc003ce923e820f0d8532541d3f5a74ed07570ce8"
     },
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "81485c0440de636511dc9ee723e18af89f313b175ea626723d0beeeed31bba2f"
+      "sha256": "2059cb9b02d6a20e4b1297c866db9f717bb3514ec49ab2454c776c806775d3da"
     },
     {
       "path": "docs/architecture.md",
@@ -2757,7 +2757,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "1fe02fc79e2952efb61450bbd45e6b09e41e8cf73453c6e0a2fbbf2944c1cdab"
+      "sha256": "37afa2a8a4f3e0d4b2689de8b45dfafa6c17569ff07575ff4b3d6b1b1393d683"
     },
     {
       "path": "docs/modules-contract.md",
@@ -2947,13 +2947,18 @@
     {
       "path": "docs/recipes/private-npm-distribution.md",
       "mode": "0000644",
-      "sha256": "3c6613920881220ec4a076b4608ed57557d645c43dee3fbb4086ad4adb81f593"
+      "sha256": "87851cddc742fb4c62de1cde8b0443a6b6fd800e753e715ed8d2ab838557d4b8"
     },
     {
       "path": "docs/recipes/redteam-patrol.md",
       "mode": "0000644",
       "sha256": "f6d2bb1da53f03f54080b8e0aec9f63390d3343c32917b64225ac47ae4ba7b42"
     },
+    {
+      "path": "docs/recipes/reranking-a-goals-board.md",
+      "mode": "0000644",
+      "sha256": "ecd8986c5e4831db53a803dae625e5f1b898b711911e8e6f1c4f1b79a98cbfe8"
+    },
     {
       "path": "docs/recipes/search-index-ingestion.md",
       "mode": "0000644",
@@ -5592,7 +5597,7 @@
     {
       "path": "modules/lifecycle/db-tasks.js",
       "mode": "0000644",
-      "sha256": "e978cadb879a57d8d7e3bb84657a787ac7e83125666fa2d31013ac64b37b0d7a"
+      "sha256": "15c9efea1fb5a8187fe5bae756777ebeb1a214e47e0434d7a8adeb156bd1e093"
     },
     {
       "path": "modules/lifecycle/db-versions.js",
@@ -5602,7 +5607,7 @@
     {
       "path": "modules/lifecycle/db.js",
       "mode": "0000644",
-      "sha256": "b4b2d6d7890ec67e52fc00718a814bf01a64f4432ed7380a175dca8bc794b0e4"
+      "sha256": "af6af95c05aa6cc76c0e49cb0a99bfb24685b3efb66df0f90883c3301baeede0"
     },
     {
       "path": "modules/lifecycle/dead-deps.js",
@@ -5832,7 +5837,7 @@
     {
       "path": "modules/lifecycle/routes/task-write-routes.js",
       "mode": "0000644",
-      "sha256": "87843c62d8ce7af3d7d6aa5772791bd52823afe5f2c4b9b7427ca9f00dd14c11"
+      "sha256": "cc86b3c05885c733cc28ba6e41f1b08cb8f0fe652e3181c1c88be4caabf18d61"
     },
     {
       "path": "modules/lifecycle/routes/tasks.js",
@@ -7657,12 +7662,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "41aca5e97b1cb72e389656c14ddd1bb35a3d5fdce8145f05e294c3fa3f52dc15"
+      "sha256": "cc6fce6807181651ec0ec230ad34473092623805b54a1ac9fbaa84e3092b3f34"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "2084b4c59fd9b3857bb83b5a4198d43c308f0180edc0e21a698e4285809323fd"
+      "sha256": "aa932c27317fc8f47d1939478cd55134c96eb1265357cc37de7765e98fe146fc"
     },
     {
       "path": "public-docs/index.html",
@@ -7867,7 +7872,7 @@
     {
       "path": "scripts/gds/build-cli-package.js",
       "mode": "0000644",
-      "sha256": "de1cdede17761775722509b1e1edb4bb43fbbf336450556f22119b18b93e43d3"
+      "sha256": "e24710d5546428beba9400831d69eb3101e76bfdb1083916bf12411839e16735"
     },
     {
       "path": "scripts/gds/bump-version.js",
@@ -8152,7 +8157,7 @@
     {
       "path": "scripts/gds/gen-api-client.js",
       "mode": "0000644",
-      "sha256": "e9a6c6498f41b51dbcc17a3538d997b220f671beb433ae65ebc5365727a444ec"
+      "sha256": "d363c76caf379a051faea40a2497db8bbba18effd68e9cd9922e9445638c57c5"
     },
     {
       "path": "scripts/gds/gen-api-docs.js",
@@ -9392,7 +9397,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "983d456cff4042137990a5baacb002919c3d213a33f663d6e8fcc7e9f5945ae6"
+      "sha256": "155f6fd854a43d20569e168af8238b3a082a03d74360d9e6248650ec453568a8"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -11432,7 +11437,7 @@
     {
       "path": "tests/migration_allocation.mjs",
       "mode": "0000644",
-      "sha256": "e2f03570b76b4d5af7af3c87a2a4989827eb71d1b50c92ab546a456e85c4024e"
+      "sha256": "0d1bc299555d98aa2ad8571e0a5a185776ca727f95577c3308a7e4b36efbfd97"
     },
     {
       "path": "tests/migration_namespace.mjs",
@@ -11672,7 +11677,7 @@
     {
       "path": "tests/patch_gate_ordering.mjs",
       "mode": "0000644",
-      "sha256": "b0690cf28c30bfa4ef1ecc4ceffa7d4be1666dbb09a6605ceb02cc057d2a9cc4"
+      "sha256": "27a3b5023b6857f3f53734966bc7685757383f2b8dadfa3c0bf1aca2e7db5517"
     },
     {
       "path": "tests/path_match.mjs",

package/clients/bongos-client/README.md

@@ -7,14 +7,26 @@ by hand; it regenerates when the spec changes, so it can never drift from the ro
 - API version: **v1** (served at `/api/bongos/v1`)
 - 360 operations across 55 resource groups
 
-## Install
+## Use it from your project
+
+**This is not an npm package** — it is not published, and nothing depends on it as one
+(task 1003742). Consume it by VENDORING the build you need, which is what every consumer
+in this repo already does:
 
 ```bash
-npm install @bongos/client   # internal registry / workspace path
+# ESM / bundler:  cp clients/bongos-client/index.mjs  <your project>/vendor/
+# CommonJS:       cp clients/bongos-client/index.cjs  <your project>/vendor/
+# Browser global: cp clients/bongos-client/bongos-client.global.js <your project>/public/
 ```
 
+Copy `index.d.ts` alongside it for types. Re-copy after `gen-api-client.js` runs, so the
+client cannot drift from the routes.
+
 ## Use
 
+The examples import by package name, which resolves in a workspace. A VENDORED copy is
+imported by its path instead — `from './vendor/index.mjs'` — everything below is identical.
+
 ```js
 import { createClient, ApiError } from '@bongos/client';
 

package/clients/bongos-client/index.d.ts

@@ -182,7 +182,7 @@ export interface PatchProvisioningInstancesIdDetailResponse { ok: boolean; descr
 export interface PatchProvisioningInstancesIdSettingsResponse { ok: boolean; saved: unknown; planet: unknown; push: unknown }
 export interface PatchTaskRecommendationsIdRequest { status: "declined" | "withdrawn" }
 export interface PatchTaskRecommendationsIdResponse { ok: boolean; recommendation: unknown }
-export interface PatchTasksIdRequest { kind?: string; discipline?: string; requires_rank?: string; module_key?: string; goal_id?: number; parent_task_id?: StringifiableId; parallel_safe?: unknown; newcomer_friendly?: boolean; xenos_claimable?: boolean; security_sensitive?: boolean; automation_tag?: string; needs_migration?: boolean; description?: string; title?: string; status?: unknown }
+export interface PatchTasksIdRequest { kind?: string; discipline?: string; requires_rank?: string; module_key?: string; goal_id?: number; parent_task_id?: StringifiableId; parallel_safe?: unknown; newcomer_friendly?: boolean; xenos_claimable?: boolean; security_sensitive?: boolean; automation_tag?: string; needs_migration?: boolean; description?: string; title?: string; priority?: unknown; status?: unknown }
 export interface PostAccessRequestsInviteRequest { github_login: string }
 export interface PostAccessRequestsInviteResponse { ok: boolean; already_invited?: boolean; github_login?: unknown; request?: unknown }
 export interface PostAccessRequestsRequest { github_login: string; display_name?: string; note?: string }

package/clients/bongos-client/package.json

@@ -25,8 +25,5 @@
     "README.md"
   ],
   "license": "AGPL-3.0-or-later",
-  "publishConfig": {
-    "access": "restricted"
-  },
   "sideEffects": false
 }

package/docs/adr/0134-private-first-npm-distribution.md

@@ -1,6 +1,6 @@
 # 0134 — Private-first npm distribution for the core + client (paid scoped, then public at launch)
 
-- **Status:** Accepted — publish path + private-by-default config built in task 2089; the real publish is a gated owner step.
+- **Status:** Accepted for the CORE; the **client half is superseded** by [task 1003742](https://cloudbongos.com/builders#/task/1003742) (2026-09-09) — see the note under Decision. Publish path + private-by-default config built in task 2089; the real publish is a gated owner step.
 - **Date:** 2026-07-07
 - **Deciders:** example-owner (owner/Archon), Claude. Owner asked to have the npm/CLI onboarding commands ready but kept private pre-launch, choosing paid private npm over the free GitHub Packages option.
 - **Task:** [#2089](https://example.com/builders#/task/2089) (publish path + private config) · [#2092](https://example.com/builders#/task/2092) (the `@cloudbongos` → `@bongos` scope rename + first real publish) · **Goal:** 35 (project-creation flow), criterion 165.
@@ -18,6 +18,25 @@ One npm rule forces the shape: **unscoped packages are always public — only *s
 
 Publish **`@bongos/core`** and **`@bongos/client`** as **scoped, private** npm packages during pre-launch, on the owner's **paid** `bongos` npm org — the **canonical** brand org.
 
+> **SUPERSEDED for the client (2026-09-09, [task 1003742](https://cloudbongos.com/builders#/task/1003742)).** `@bongos/client`
+> is no longer an npm package at all, and the reason is worth keeping so it does not come back.
+>
+> It was published **once** — 2026-07-07, version 0.0.2 — and never updated, while the API it is
+> *generated from* moved 500+ core versions. In that time it had **zero consumers**: a sweep of every
+> `package.json` across the core and every instance repo (hermeslines-marketing, cloudbongos-instance,
+> mercury, charter, demo) found no dependency on it; the only matches were its own manifest. Everyone
+> who needs the generated client **vendors a copy** — `modules/dev-box/app/src/vendor/bongos-client.cjs`,
+> and `build-cli-package.js` into `@cloudbongos/cli`, which as a *public* package could not have
+> depended on a private one anyway ([ADR 0258](<redacted>.md)).
+> A stale generated client that nobody installs is worse than none: the only thing it could do is
+> mislead someone into pinning a client 500 versions behind the routes.
+>
+> The owner removed it from the registry. The **generated artifact stays** and still regenerates
+> ([ADR 0118](<redacted>.md)) — `clients/bongos-client/` and
+> `gen-api-client.js` earn their place. What is retired is only the claim that it is a package: the
+> generator no longer emits a `publishConfig`, and its README now documents vendoring instead of
+> `npm install`. **This ADR's core half is unaffected.**
+
 > **Scope correction (task 2092).** The publish path first shipped (task 2089) under the `@cloudbongos` scope, matching the name the repo already used. But when publishing, the paid org turned out to be **`bongos`** (the canonical brand the owner put on Teams), while `cloudbongos` — one of the ~10 defensive orgs — was left on the free tier. Since a private scoped publish requires the scope to match a *paid* org, and `@bongos` is the intended canonical brand anyway, we **renamed the core + client package identity `@cloudbongos/*` → `@bongos/*`** (a consistent rename across the build + vendored-install flow, verified by the test suite) rather than pay for a second org. Existing vendored consumers keep their pinned `@cloudbongos/core` tarball; only new scaffolds use `@bongos`.
 
 - **Private by default in code, not just by flag.** The synthesized core `package.json` (`buildPackageJson`) and the generated client `package.json` (`gen-api-client.js`) both carry `publishConfig: { access: "restricted" }`. `package-core.js --publish` additionally passes `--access restricted` on the CLI — belt-and-suspenders so a stray config edit can't silently make the pre-launch artifact public.

package/docs/adr/0258-the-public-cli-is-a-generated-client-package-not-the-published-core.md

@@ -120,9 +120,11 @@ benefit. It gains one when ADR 0099's mirror lands.
 - **Publishing is the owner's action, not a builder's.** It is the owner's npm account, and a
   public package name cannot be un-taken. The build stops at a packed tarball and hands over one
   `npm publish --access public`.
-- `@bongos/client` stays private and is **vendored** as a single file rather than declared as a
-  dependency — a public package that depended on a private one would be uninstallable for
-  everyone.
+- `@bongos/client` is **vendored** as a single file rather than declared as a dependency — a public
+  package that depended on a private one would be uninstallable for everyone. (It was private then;
+  since [task 1003742](https://cloudbongos.com/builders#/task/1003742) it is not published at all,
+  which makes the vendoring not merely preferable but the only option. Vendoring was the right call
+  either way, and this package is one of the two reasons the client had no consumers to lose.)
 - Task 1002025 is superseded and should be closed against this ADR rather than done.
 - **The journey above is instance-dependent, and 0.1.1 shipped assuming it was not**
   ([task 1003730](https://cloudbongos.com/builders#/task/1003730)). `bongos shell` is the answer

package/docs/adr/README.md

@@ -208,7 +208,7 @@ This keeps the decision history honest and traceable.
 | 0131 | [Rank-scoped skill visibility — feasibility spike (task [#1650](https://example.com/builders#/task/1650)). Wanted: a session lists only the skills the builder's rank can use, via a SessionStart hook filtering the skill menu — pure UX declutter (the server rank gate + each skill's early self-check still enforce). Finding: Claude Code hooks CANNOT filter/hide/rewrite the skill listing — SessionStart offers only `additionalContext` (inject text) + `reloadSkills` (add-only), no hook subtracts a skill, and hooks can't mutate settings at runtime. A HARD menu hide needs a pre-launch step (the launcher that already fetches rank) writing per-builder `skillOverrides:"off"` into `.claude/settings.local.json` before `claude` starts (misses plugin skills; workspace-trust-gated). Recommendation: don't build the heavy launcher change for a cosmetic gain; if some declutter is wanted now, use the existing hook's `additionalContext` as a soft nudge; keep the server gate + self-checks. Owner to decide.](<redacted>.md) | dx / skills |
 | 0132 | [Migrate the co-hosting fleet to the control plane over an SSH DB tunnel (task [#2071](https://example.com/builders#/task/2071), BONGOS-V1, goal 26; extends ADR 0130, completes 2065 / blocker 64). Stripping the co-hosting box's tokens proved NOT a switch-flip: it runs FIVE token-consuming timers (the 4 `box.js` dev-box lifecycle sweeps + `provision-intent-runner`), each reading its queue from the box's LOCAL `example` Postgres (firewalled to localhost) — so a control-plane runner can't reach the queues, and ADR 0130 moved only box-step execution, not queue reading. Also `box.js` was never migrated. Decision: a persistent SSH tunnel (control-plane `127.0.0.1:5433` → co-hosting `127.0.0.1:5432`, `infra/cohost-db-tunnel.service`) + all five runners re-homed as `cohost-*` control-plane variants reading the example queues via `DATABASE_URL` through the tunnel (no public Postgres exposure), calling DO/CF with the control-plane tokens; provisioning remote-execs box steps per ADR 0130. DB auth: a scram password on the EXISTING `lars` role (identical privileges the runners already use; reachable only via `127.0.0.1`), stored only in chmod-600 `/etc/cloudbongos/cohost-fleet.env`. `box.js` unchanged (pure DO/CF API + Discord/DNS-hook execs, all on the control plane). `cohost-provision-intent-runner.*` supersedes 2065's `provision-intent-runner-cloudbongos.*`. Rejected: exposing Postgres over the VPC (opens a TCP surface + `pg_hba`/cred work; droplets not guaranteed same-VPC); a token-signing broker on the co-hosting box (leaves tokens' blast radius there — opposite of the goal); moving the queue tables to the cloudbongos DB (the OTB web tier can't reach it either — firewall symmetry). Units ship additive + not-enabled, self-healed install-only. Activation (SSH trust · DB password · tunnel · enable `cohost-*` + disable co-hosting timers same window · verify via drift-reconcile · bake · owner token rotate+strip · drop rollback DB) is a sequenced operator-op.](<redacted>.md) | infra / Cloud Bongos |
 | 0133 | [One-click GitHub sign-in for onboarding via the GitHub App Manifest flow (task [#2080](https://example.com/builders#/task/2080), BONGOS-V1, goal 35 / criterion 165). The last onboarding friction was wiring GitHub sign-in — the owner had to hand-create an OAuth App + paste a client secret, unscriptable because GitHub has NO create-OAuth-App API. Decision: use GitHub's App **Manifest** flow. The signed-in owner clicks one pre-filled link; GitHub creates the App and returns a temporary `code`; the control-plane runner (`provision.js`, sole token-holder) exchanges it for `client_id`/`client_secret`, writes them to `/etc/<slug>/web.env` (the `oauth-secret.js` path), restarts, and verifies `/healthz` auth_configured — the secret never touches the browser, chat, or web tier. Spans the trust boundary: web tier mints a one-time `state` + stores a `provisioning_oauth_manifests` row + a PUBLIC callback stores GitHub's code (`state` is the auth); the control-plane runner drains `code_received` rows on its existing timer tick (gated on instance=active). Sign-in code unchanged — a GitHub App's user token hits the same `GET /user`; GitHub ignores the extra `scope` for Apps. Back-compat: existing OAuth-app instances untouched; manifest is the new default, manual path kept as fallback. All three onboarding surfaces (hall wizard one-click button, `bongos onboard`, `/new-project`) updated in lockstep.](<redacted>.md) | onboarding / auth |
-| 0134 | [Private-first npm distribution for the core + client (task [#2089](https://example.com/builders#/task/2089), BONGOS-V1, goal 35 / criterion 165; refines [#2025](https://example.com/builders#/task/2025), builds on ADR 0108). Owner wants the npm/CLI onboarding commands ready but private pre-launch, choosing paid private npm over free GitHub Packages. npm rule forces the shape: unscoped names are always public, only SCOPED packages can be private (paid plan) — so the private form stays scoped `@bongos/core` + `@bongos/client` (zero rename; org already owned). Decision: publish both as scoped PRIVATE packages now via `publishConfig:{access:"restricted"}` baked into the synthesized core `package.json` (`package-core.js buildPackageJson`) + the generated client `package.json` (`gen-api-client.js`); `package-core.js --publish` dry-runs by default, real publish needs `--publish --live` + owner `npm login` (tooling holds no token). Consumers auth via env-fed `.npmrc` `_authToken=<redacted> Vendored-tarball install (task 2053) stays the working default; provision/init registry auto-pull is a follow-up. Going public at launch is one flag (`npm access public`) or task 2025's unscoped vanity `cloudbongos` — 2025 becomes the go-public step, not superseded. The daily `bongos` command is name-independent throughout. Runbook: docs/recipes/private-npm-distribution.md.](<redacted>.md) | distribution / npm |
+| 0134 | [Private-first npm distribution for the core + client (task [#2089](https://example.com/builders#/task/2089), BONGOS-V1, goal 35 / criterion 165; refines [#2025](https://example.com/builders#/task/2025), builds on ADR 0108). Owner wants the npm/CLI onboarding commands ready but private pre-launch, choosing paid private npm over free GitHub Packages. npm rule forces the shape: unscoped names are always public, only SCOPED packages can be private (paid plan) — so the private form stays scoped `@bongos/core` + `@bongos/client` (zero rename; org already owned). Decision: publish both as scoped PRIVATE packages now via `publishConfig:{access:"restricted"}` baked into the synthesized core `package.json` (`package-core.js buildPackageJson`) + the generated client `package.json` (`gen-api-client.js`); `package-core.js --publish` dry-runs by default, real publish needs `--publish --live` + owner `npm login` (tooling holds no token). Consumers auth via env-fed `.npmrc` `_authToken=<redacted> Vendored-tarball install (task 2053) stays the working default; provision/init registry auto-pull is a follow-up. Going public at launch is one flag (`npm access public`) or task 2025's unscoped vanity `cloudbongos` — 2025 becomes the go-public step, not superseded. The daily `bongos` command is name-independent throughout. Runbook: docs/recipes/private-npm-distribution.md. **CLIENT HALF SUPERSEDED** ([task 1003742](https://cloudbongos.com/builders#/task/1003742), 2026-09-09): `@bongos/client` is not an npm package at all — published once at 0.0.2 on 2026-07-07, never updated while the API moved 500+ core versions, and ZERO consumers the whole time (no package.json in the core or any instance repo ever declared it; every consumer vendors a copy, and `@cloudbongos/cli` could not have depended on a private package anyway). Removed from the registry; the generator no longer emits a `publishConfig` and its README documents vendoring. The generated artifact stays (ADR 0118). Core half unaffected.](<redacted>.md) | distribution / npm |
 | 0135 | [Module upstream submission: the review queue lives in the submitting instance's own DB, interim (task [#1770](https://example.com/builders#/task/1770), BONGOS-V1, builds on ADR 0107). ADR 0107 §1 says `bongos module submit` files a packaged module into a rank-gated review queue "on the core" — but the extracted core (`github.com/example-owner/cloud-bongos`) is a private GIT REPO, not a running service (no HTTP API), and per ADR 0100 §3 each project runs its OWN GDS DB, so there is no shared cross-repo queue to file into; R85 (the forcing-function second consumer) was also abandoned. Decision: the queue is a table (`module_submissions`, migration `<redacted>.sql`) in THIS instance's own Bongos DB. `bongos module submit <key>` and the hall's submit button both call the SAME route, `POST /modules/:key/submit` (metic+archon), which re-runs the ADR 0107 §4 pre-check against its OWN on-disk copy (authoritative — a local CLI pass is a courtesy) and refuses without a sign-off; `GET /modules/submissions` lists the queue for task 1771 (core-side review & accept, still backlog) to read from. Rejected: a live call to a not-yet-built core endpoint (guesses at 1771's contract); a GitHub Issue/PR against the private core repo (loses the structured queue, no standing credential); a dry-run-only local-file client mirroring do-api.js (a worse queue than a DB table this instance already operates). Forward-compatible: when a real core endpoint exists, filing becomes a network hop with no change to the CLI/UI contract.](<redacted>.md) | modules / upstreaming |
 | 0136 | [Update-channel subscription policy (task [#2150](https://example.com/builders#/task/2150), BONGOS-V1, goal 26; completes the update-consumption workstream on ADR 0100 §2 + ADR 0134 + task 2149). Answers "how do projects subscribe to regular @bongos/core updates?" with the owner-chosen policy: **patch-only by default, health-gated with auto-rollback, opt-in, autonomy-gated.** Per-instance `update_channel` = `pinned` (never) / `patch` (higher z within x.y — DEFAULT) / `minor` (higher y within the major); a MAJOR is never automatic, prereleases never auto-targeted — the pure math is `scripts/gds/update-channel.js` (`resolveChannelTarget`), unit-tested in `tests/update_channel.mjs`. The registry (npm view, ADR 0134) is the "what's newest" source. A new `mode:deterministic` instance-wide routine `core-update-subscription` reads the opt-in roster `config/update-subscriptions.json` (ships EMPTY) and runs `bongos upgrade --to <v> --registry` per subscribed instance with auto-rollback ON (task 2149). Triple-gated: autonomy flag OFF by default (ADR 0115) + empty roster + health-gated. Upstream auto-publish (whether main merges auto-publish a patch) is deliberately SPLIT to its own follow-up task, so goal 26 closes on the consumption half; the subscription just consumes whatever the owner publishes. Scope is local same-host instances; multi-host fleet orchestration is the deferred fleet-control-plane epic (task 1948). Rejected: a `provisioning_instances` DB column (presumes the still-unbuilt fleet-registry schema; a config manifest is migration-free + ADR-0115-shaped), minor-by-default (less conservative), deciding auto-publish here (orthogonal, would block consumption).](<redacted>.md) | distribution / updates |
 | 0137 | [Upstream publish policy: `@bongos/core` patches are published MANUALLY (owner-gated), NOT auto-published on merge (task [#2158](https://example.com/builders#/task/2158), BONGOS-V1, goal 26; the SUPPLY half split out of ADR 0136 §5 / task 2150, builds on ADR 0134). Owner chose manual over auto. Decision: the owner runs `package-core.js --publish --live` to cut a release (optional `core-v<version>` git tag as the auditable marker — triggers no CI); `CORE_VERSION` (src/module-api.js) is bumped by hand in-task with a changelog line (provenance stays in git, not a release-tool side effect); NO npm write-token at rest (preserves ADR 0134 tokenless tooling — owner auths at publish time; only the read token exists); the no-leak/mirror-redact gate is already fail-closed inside `package-core.js`, so `--publish` cannot upload a leaking artifact. The ADR 0136 subscription consumes whatever is published; freshness is owner-paced by design. Rejected: auto-publish-on-merge (needs a standing npm write-token as a CI secret — reverses the tokenless posture for little gain at low, deliberate release volume). Revisit as a tag-triggered CI publish when the managed-fleet epic (task 1948) makes the manual step a real bottleneck. Ritual: docs/recipes/private-npm-distribution.md "Cutting a core release".](<redacted>.md) | distribution / npm |

package/docs/api/openapi.json

@@ -18880,6 +18880,7 @@
             "minLength": 1,
             "maxLength": 200
           },
+          "priority": {},
           "status": {}
         },
         "additionalProperties": false

package/docs/api-reference.md

@@ -591,7 +591,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | GET | `/api/bongos/tasks` | `any-builder` | — |  |
 | POST | `/api/bongos/tasks` | `metic+archon` | `version_id`, `title`, `description`, `status`, `touches`, `est_minutes`, `est_cost_usd`, `manual_degree`, `priority`, `automation_tag`, `credits_reward`, `source`, `source_ref`, `value_summary`, `kind`, `discipline`, `parallel_safe`, `newcomer_friendly`, `security_sensitive`, `requires_rank`, `auto_detect_touches`, `criterion_ids`, `module_key`, `goal_id` | Task create/promote/edit (plan/scope mutation) is Metic+ as of ADR 0090 (owner decision 2026-06-26): a Metic who can run idea-triage may … |
 | GET | `/api/bongos/tasks/:id` | `any-builder` | — | single-task read; preserved per CRITICAL §4 (supervisor hot path). |
-| PATCH | `/api/bongos/tasks/:id` | `metic+archon` | `kind`, `discipline`, `requires_rank`, `module_key`, `goal_id`, `parent_task_id`, `parallel_safe`, `newcomer_friendly`, `xenos_claimable`, `security_sensitive`, `automation_tag`, `needs_migration`, `description`, `title`, `status` | PATCH /tasks/:id — supports body.parent_task_id (V2 C2), body.kind (V2 B1), body.discipline (mig 014), body.parallel_safe (mig 028), and … |
+| PATCH | `/api/bongos/tasks/:id` | `metic+archon` | `kind`, `discipline`, `requires_rank`, `module_key`, `goal_id`, `parent_task_id`, `parallel_safe`, `newcomer_friendly`, `xenos_claimable`, `security_sensitive`, `automation_tag`, `needs_migration`, `description`, `title`, `priority`, `status` | PATCH /tasks/:id — supports body.parent_task_id (V2 C2), body.kind (V2 B1), body.discipline (mig 014), body.parallel_safe (mig 028), and … |
 | POST | `/api/bongos/tasks/:id/abandon` | `metic+archon` | `reason` | POST /tasks/:id/abandon — terminal "retire this task" transition (task 987). |
 | POST | `/api/bongos/tasks/:id/attest-gate` | `any-builder` | `head_sha` | POST /tasks/:id/attest-gate — body: { head_sha }. |
 | POST | `/api/bongos/tasks/:id/confirm` | `any-builder` | `verified` |  |

package/docs/module-api-changelog.md

@@ -1687,5 +1687,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.617 with no explicit bump. run 34318552090. (task 1002620)
   1.19.619 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.618 with no explicit bump. run 34320024204. (task 1002620)
+  1.19.620 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.619 with no explicit bump. run 34321089991. (task 1002620)
+  1.19.621 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.620 with no explicit bump. run 34321546662. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/recipes/private-npm-distribution.md

@@ -1,8 +1,10 @@
-# Recipe — private-first npm distribution (core + client)
+# Recipe — private-first npm distribution (the core)
 
 > **This is one leg of three.** For the whole path from a change on core `main` to a live instance — and for when publishing to npm is *not* what moves an instance — start at [the core release pipeline](core-release-pipeline.md).
 >
-> Implements [ADR 0134](../adr/<redacted>.md). Pre-launch, `@bongos/core` and `@bongos/client` publish as **private, scoped** npm packages on the owner's paid `bongos` npm org (the canonical brand); at launch they flip to public. The daily command is `bongos` regardless of package name.
+> Implements [ADR 0134](../adr/<redacted>.md), **core half only**. Pre-launch, `@bongos/core` publishes as a **private, scoped** npm package on the owner's paid `bongos` npm org (the canonical brand); at launch it flips to public. The daily command is `bongos` regardless of package name.
+>
+> **`@bongos/client` is no longer part of this.** It was published once (2026-07-07, 0.0.2), never updated while the API moved 500+ core versions, and had **zero** consumers the whole time — every consumer vendors a copy instead. The owner removed it from npm on 2026-09-09; ADR 0134's client half is superseded ([task 1003742](https://cloudbongos.com/builders#/task/1003742)). The generated client still exists and still regenerates — it is simply not a package.
 >
 > **Why private must be scoped:** on npm, *unscoped* names are always public — only *scoped* names (`@bongos/…`) can be private, and only on a paid plan. So the packages publish under the `@bongos` scope, which maps to the paid `bongos` org.
 
@@ -11,9 +13,10 @@
 | Package | What it is | Built by |
 |---|---|---|
 | `@bongos/core` | the platform an instance installs + the `bongos` CLI (`bin`) | `bongos package-core` (`scripts/gds/package-core.js`) — synthesizes the package.json + a pruned lockfile, redacts, and packs a `.tgz` |
-| `@bongos/client` | the generated typed API client | `node scripts/gds/gen-api-client.js` (regenerates `clients/bongos-client/`) |
 
-Both carry `publishConfig: { access: "restricted" }`, so **publishing them is private by default** — no public leak if a flag is forgotten.
+`@bongos/core` carries `publishConfig: { access: "restricted" }`, so **publishing it is private by default** — no public leak if a flag is forgotten.
+
+The generated typed client (`node scripts/gds/gen-api-client.js` → `clients/bongos-client/`) is deliberately **not** in this table: it is not published, carries no `publishConfig`, and is consumed by vendoring. See its own README.
 
 ## One-time owner setup (only the owner can do these)
 
@@ -80,9 +83,10 @@ Then, with `NPM_TOKEN` set in the environment:
 
 ```sh
 npm install -g @bongos/core   # global → the `bongos` command, then `bongos init`
-npm install @bongos/client    # in a project that calls the API
 ```
 
+(A project that calls the API vendors the generated client instead — it is not installable.)
+
 Without a valid token + org membership the install 404s — that is the private gate working.
 
 ## Provisioning: registry pull vs vendored tarball (task 2090)
@@ -104,7 +108,6 @@ Pick either — both keep the daily `bongos` command working:
 - **Flip the same scoped packages public** (simplest):
   ```sh
   npm access public @bongos/core
-  npm access public @bongos/client
   ```
   (Or change `publishConfig.access` to `"public"` and republish.) Public installs need no token; the paid seats can be dropped.
 - **Also publish the unscoped vanity name** for `npm install -g cloudbongos` — that is [task 2025](https://example.com/builders#/task/2025) (rename in `package-core.js`/`upgrade.js` + docs), done at launch.

package/docs/recipes/reranking-a-goals-board.md

@@ -0,0 +1,93 @@
+# Re-ranking a goal's board — the needed-vs-nice rubric
+
+> Written at task 1003750 (2026-09-09), the first whole-goal re-rank the project ran. Read this before re-ranking any board: the rubric is here so it is applied consistently rather than re-invented per session, and the mechanics section records the two traps that made the first pass cost more than the analysis did.
+
+`tasks.priority` is an integer **1–5, where 1 is most urgent**. Two surfaces read it and both take low-as-urgent:
+
+- version progress is weighted `6 - COALESCE(t.priority, 5)` (`migrations/003_pms.sql`), so an unset priority weighs the same as a P5;
+- the session optimizer orders claimable work `priority ASC NULLS LAST` (`src/bongos/optimizer.js`).
+
+So priority is not a label. It steers what every builder is offered first, and an unset one is not neutral — it sits at the bottom.
+
+## The rubric
+
+The axis is **needed vs nice-to-have**, which is deliberately *not* "is this still true" (that is a relevance audit — see [the goal 1000090 one](../audits/<redacted>.md)) and not "how big is it". A task can be tiny and P1, or large and P5.
+
+| Tier | Test | What earns it |
+|---|---|---|
+| **P1** | Bleeding now | A live path is broken, or **reports success falsely**, or finished paid work is being lost. Fix regardless of what else is queued. |
+| **P2** | Needed, not bleeding | A defect with a workaround that taxes every session; a keystone freezing other tasks; a cost window closing on its own. |
+| **P3** | Should do | Real reliability or legibility gain, no forcing function. |
+| **P4** | Nice to have | Consistency, doc nits, cleanups, and work blocked behind a decision nobody has made yet. |
+| **P5** | Nice to have / speculative | Large refactors and research with no forcing function. Also: tasks whose premise is contested and needs an owner call — park them here rather than guessing. |
+
+Three rules that did the most work in practice:
+
+1. **"Reports success falsely" outranks "is broken".** A broken thing gets noticed; a lying one does not. Three of the five P1s on goal 1000090 were only P1 because a tool printed a success it had not verified.
+2. **Read the body, not the title.** [Task 1001479](https://cloudbongos.com/builders#/task/1001479) sat at P1 from June while its own description read *"Trivial, low priority."* Titles drift from bodies; bodies drift from reality.
+3. **A blocked task is not urgent, but its keystone is.** Where five tasks waited on one unwritten ADR, the ADR moved up and the five moved down. Prioritizing the blocked five would have produced five claims that cannot start.
+
+**Sanity check before writing:** a tier list that is mostly P1 has ranked nothing. Aim for a distribution that narrows sharply at the top — goal 1000090's 63 open rows came out 5 / 8 / 27 / 17 / 6.
+
+## Mechanics
+
+**Now:** `PATCH /api/bongos/tasks/:id` accepts `priority` (integer 1–5, or `null` to clear). It did not before task 1003750 — priority was write-once at create and immutable at every rank, which is why the first re-rank had to be SQL.
+
+```bash
+echo '{"priority":2}' > /tmp/p.json
+node scripts/gds/api.js PATCH /api/gds/tasks/1002884 --body-file /tmp/p.json
+```
+
+Two things to know before you batch this:
+
+- **Bulk PATCH is rate-limited to roughly 30 per minute.** A 63-row pass needs pacing, not a tight loop.
+- **`priority` is not settable at the same time as `status`.** Status moves only through its own transition routes (`/promote`, `/confirm`, …); a body carrying `status` is refused outright with `status_not_patchable`.
+
+**The trap that outlives this recipe: a P1 in `backlog` is inert.** Priority orders the *claimable* feed, and `backlog` rows are not in it. On goal 1000090, four of the five P1s were in `backlog`, so the re-rank changed nothing about what builders saw until they were promoted. **Always re-check status after re-ranking** — `/promote` the ones that should be live, and use [`/backlog-review`](../../.claude/skills/backlog-review/SKILL.md) to walk what is waiting on a person.
+
+And before promoting anything into the claimable pool, **check `requires_rank`.** New tasks floor at `xenos` and the auto-derivation has been inert since ADR 0049, so a task about the deploy or authority surface is newcomer-claimable unless someone raised it by hand. Promoting a P1 without checking that is how a deploy-authority design lands in the newcomer queue.
+
+### When the API cannot reach the live board
+
+Core reaches a live instance only through a release plus a pin move (gate 3, [`core-release-pipeline.md`](core-release-pipeline.md)) — so a *newly shipped* route is not callable against production for as long as the pin lags. In that window the board is only reachable by SQL on the control-plane box, and an agent cannot run it (the permission classifier blocks a mutating `sudo -u lars` over ssh, by design — see [task 1003159](https://cloudbongos.com/builders#/task/1003159), which exists to close exactly this gap).
+
+Generate the statements from a checked map rather than typing ids, keep it in one transaction, and **write the revert first** — the prior values are only recoverable if you captured them before the write:
+
+```bash
+node scripts/gds/api.js GET '/api/gds/tasks?goal_id=<goal>&limit=200' --quiet > before.json
+```
+
+Then group the ids by target tier and emit one `UPDATE` per tier, guarded to the goal and to open statuses so a concurrent ship cannot be clobbered:
+
+```sql
+BEGIN;
+UPDATE tasks SET priority=1, updated_at=now()
+ WHERE goal_id=<goal> AND status IN ('ready','backlog') AND id IN (<ids>);
+-- one statement per tier
+COMMIT;
+```
+
+Build the revert from `before.json` the same way, grouping by each row's *original* priority (including a `NULL` group — unset is a real prior value and restoring it as 5 is not the same thing). Verify every id in the map appears in the emitted SQL before running anything; a silently dropped id leaves a row at a priority nobody chose.
+
+## The goal 1000090 pass, as a worked example
+
+All 63 open rows of [goal 1000090](https://cloudbongos.com/builders#/goal/1000090) (working area 4 — Bongos Core distribution), 2026-09-09. 48 of 63 changed; 24 had no priority at all.
+
+| Tier | Tasks |
+|---|---|
+| **P1** | 1002708, 1002714, 1002884, 1003159, 1003200 |
+| **P2** | 1001431, 1002204, 1002205, 1002863, 1002869, 1003526, 1003537, 1003742 |
+| **P3** | 1000380, 1000861, 1000862, 1001219, 1001429, 1001433, 1001436, 1001930, 1002206, 1002531, 1002532, 1002583, 1002617, 1002622, 1002669, 1002707, 1002854, 1002880, 1002900, 1002903, 1003499, 1003502, 1003564, 1003625, 1003647, 1003648, 1003658 |
+| **P4** | 1001311, 1001441, 1001479, 1001641, 1001927, 1001929, 1002049, 1002208, 1002209, 1002842, 1002844, 1002879, 1002882, 1003563, 1003573, 1003651, 1003657 |
+| **P5** | 1002406, 1002413, 1002839, 1002840, 1002841, 1002843 |
+
+The five P1s all said the same thing, which is the finding the exercise produced: **shipped work does not reliably reach users, and the tooling misreports it.** Task 1002884 health-checked the old still-running process and printed "✓ upgrade complete" while live served the previous version; 1002708 and 1002714 leave the pin uncommitted so the next commit silently downgrades live; 1003159 is the owner having no deploy control at all; 1003200 is that nothing checks whether a claimed artifact ever reached a remote, found after three paid tasks turned out to exist only on laptops.
+
+1002406 and 1002413 sit at P5 as *contested*, not as unimportant — ADR 0062 §7 and task 1003740 now point against their premise, so they need an owner's kill-or-re-argue rather than a builder's guess.
+
+## Related
+
+- [`docs/audits/<redacted>.md`](../audits/<redacted>.md) — the relevance pass on the same board. Run relevance first: there is no point ranking a task whose premise is gone.
+- `/backlog-review` — walks `status='backlog'`, which is where a re-rank's P1s often turn out to be hiding.
+- `/priority-session` — reweights the **idea inbox**, not tasks, and writes no priorities. It ends in a recommendation; this recipe is the write.
+- [`core-release-pipeline.md`](core-release-pipeline.md) — why a shipped route is not a live route.

package/modules/lifecycle/db-tasks.js

@@ -272,7 +272,7 @@ async function findTaskBySourceRef({ source, sourceRef } = {}, deps = {}) {
 
 const TASK_SETTER_COLUMNS = new Set([
   'kind', 'discipline', 'newcomer_friendly', 'security_sensitive', 'parallel_safe', 'automation_tag',
-  'needs_migration', 'module_key', 'description', 'title',
+  'needs_migration', 'module_key', 'description', 'title', 'priority',
 ]);
 
 async function updateTaskColumn(id, column, value) {
@@ -339,6 +339,14 @@ async function updateTaskDescription(id, description) { return updateTaskColumn(
 // 1002791) was permanent. Same permission, same audit trail as the body.
 async function updateTaskTitle(id, title) { return updateTaskColumn(id, 'title', title); }
 
+// task 1003750: the third write-once planning field, and the one that steers
+// what gets claimed — version progress is weighted `6 - COALESCE(priority, 5)`
+// and the session optimizer orders claimable work by `priority ASC NULLS LAST`.
+// Set at create and then immutable at every rank, so re-ranking a goal's board
+// (needed vs nice-to-have) had no route at all and had to be done as raw SQL.
+// 1 = most urgent, 5 = least; null clears it back to unset (weighted as 5).
+async function updateTaskPriority(id, priority) { return updateTaskColumn(id, 'priority', priority); }
+
 
 async function updateTaskDiscipline(id, discipline) { return updateTaskColumn(id, 'discipline', discipline); }
 
@@ -936,6 +944,7 @@ module.exports = {
   updateTaskNeedsMigration,
   updateTaskNewcomerFriendly,
   updateTaskParallelSafe,
+  updateTaskPriority,
   updateTaskRequiresRank,
   updateTaskSecuritySensitive,
   updateTaskStatus,

package/modules/lifecycle/db.js

@@ -127,6 +127,7 @@ const {
   updateTaskNeedsMigration,
   updateTaskNewcomerFriendly,
   updateTaskParallelSafe,
+  updateTaskPriority,
   updateTaskRequiresRank,
   updateTaskSecuritySensitive,
   updateTaskStatus,
@@ -301,6 +302,7 @@ module.exports = {
   disambiguateWorktreeName,
   foldWorktreeName,
   updateTaskParallelSafe,
+  updateTaskPriority,
   updateTaskSecuritySensitive,
   updateTaskAutomationTag,
   updateTaskNeedsMigration,

package/modules/lifecycle/routes/task-write-routes.js

@@ -318,6 +318,14 @@ module.exports = function registerTaskWriteRoutes(router) {
       // briefs naming tables that hard-fail CI). Same shape as create, same
       // task.edit permission, same audit_log trail as a description edit.
       title: { type: 'string', minLength: 1, maxLength: LIMITS.TITLE },
+      // task 1003750: priority was accepted at create and then immutable at every
+      // rank — the same write-once defect title/description carried above. It is
+      // not cosmetic: the DB weights version progress as `6 - COALESCE(priority, 5)`
+      // and the session optimizer orders claimable work by `priority ASC NULLS LAST`,
+      // so a wrong value at create time steers what every builder claims, forever.
+      // A whole-goal re-rank (needed-vs-nice) had no route and had to run as SQL.
+      // null clears it back to unset; the 1..5 bounds mirror tasks_priority_check.
+      priority: {},                                      // 1..5 or null — checked inline
       // task 1002614 (map D-18): DECLARED so strict-mode admits the request far
       // enough to reach the deliberate status_not_patchable hint below (#514) —
       // the hint had been unreachable dead code behind unknown_field since the
@@ -345,6 +353,7 @@ module.exports = function registerTaskWriteRoutes(router) {
     const hasGoalId = Object.prototype.hasOwnProperty.call(body, 'goal_id');
     const hasDescription = Object.prototype.hasOwnProperty.call(body, 'description');
     const hasTitle = Object.prototype.hasOwnProperty.call(body, 'title');
+    const hasPriority = Object.prototype.hasOwnProperty.call(body, 'priority');
     // #514: status is a lifecycle field, not a PATCH-able column — it moves only
     // through the dedicated transition routes. The #506 session tried
     // `PATCH status=ready`, got the generic no_supported_fields error, and had
@@ -356,8 +365,8 @@ module.exports = function registerTaskWriteRoutes(router) {
     if (Object.prototype.hasOwnProperty.call(body, 'status')) {
       return res.fail('status_not_patchable', { status: 400, message: STATUS_HINT });
     }
-    if (!hasParent && !hasKind && !hasDiscipline && !hasNewcomerOrXenos && !hasParallelSafe && !hasSecuritySensitive && !hasAutomationTag && !hasNeedsMigration && !hasRequiresRank && !hasModuleKey && !hasGoalId && !hasDescription && !hasTitle) {
-      return res.fail('no_supported_fields', { status: 400, message: 'PATCH /tasks/:id supports parent_task_id, kind, discipline, title, description, parallel_safe, security_sensitive, automation_tag, needs_migration, requires_rank, module_key, goal_id, and newcomer_friendly (alias: xenos_claimable). ' + STATUS_HINT });
+    if (!hasParent && !hasKind && !hasDiscipline && !hasNewcomerOrXenos && !hasParallelSafe && !hasSecuritySensitive && !hasAutomationTag && !hasNeedsMigration && !hasRequiresRank && !hasModuleKey && !hasGoalId && !hasDescription && !hasTitle && !hasPriority) {
+      return res.fail('no_supported_fields', { status: 400, message: 'PATCH /tasks/:id supports parent_task_id, kind, discipline, title, description, priority, parallel_safe, security_sensitive, automation_tag, needs_migration, requires_rank, module_key, goal_id, and newcomer_friendly (alias: xenos_claimable). ' + STATUS_HINT });
     }
     // ---- task 1002609 (G-22): settle EVERY gate and validation before the ----
     // ---- FIRST write. The previous shape validated-and-wrote per field in ----
@@ -374,6 +383,16 @@ module.exports = function registerTaskWriteRoutes(router) {
     if (hasParallelSafe && body.parallel_safe !== null && typeof body.parallel_safe !== 'boolean') {
       return res.fail('bad_parallel_safe', { status: 400, message: 'parallel_safe must be true, false, or null' });
     }
+    // task 1003750: bounds mirror the tasks_priority_check DB constraint via the
+    // shared TASK_FIELD_BOUNDS the create schema uses, so the route and the
+    // column can't drift. Integer or null only — a float or "3" would pass a
+    // bare range test and then fail at the column.
+    if (hasPriority && body.priority !== null) {
+      const p = body.priority;
+      if (!Number.isInteger(p) || p < TASK_FIELD_BOUNDS.priority.min || p > TASK_FIELD_BOUNDS.priority.max) {
+        return res.fail('bad_priority', { status: 400, message: `priority must be an integer ${TASK_FIELD_BOUNDS.priority.min}-${TASK_FIELD_BOUNDS.priority.max} (1 = most urgent), or null to clear` });
+      }
+    }
     if (hasSecuritySensitive) {
       // task 990: explicit Archon-only-broadcast flag. Boolean only (no null) —
       // it gates whether ship.js routes the broadcast to the Archon-only
@@ -528,6 +547,15 @@ module.exports = function registerTaskWriteRoutes(router) {
         return res.fail('patch_failed', { status: 500, message: 'internal error' });
       }
     }
+    if (hasPriority) {
+      try {
+        updated = await db.updateTaskPriority(id, body.priority ?? null);
+        if (!updated) return res.fail('task_not_found', 404);
+      } catch (err) {
+        log.error('[gds] PATCH /tasks/:id priority', err);
+        return res.fail('patch_failed', { status: 500, message: 'internal error' });
+      }
+    }
     if (hasGoalId) {
       try {
         updated = await db.updateTaskGoal(id, body.goal_id);

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.619",
+  "version": "1.19.621",
   "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/scripts/gds/build-cli-package.js

@@ -87,11 +87,12 @@ const FILES = [
   'src/bongos/api-prefix.js',
 
   // The generated typed API client (ADR 0118), which cli-lib.js reaches by a dynamic
-  // `import()` of this exact path. Vendored as a single file rather than depended on: it is
-  // published as `@bongos/client`, which is PRIVATE, so a public package that declared it as a
-  // dependency would be uninstallable for everyone. index.mjs is self-contained and imports
-  // nothing; the sibling package.json is deliberately NOT shipped (it carries
-  // publishConfig.access=restricted and a nested manifest only confuses packing).
+  // `import()` of this exact path. Vendored as a single file rather than depended on: it is not
+  // published to npm at all (task 1003742 — it was private, had zero consumers, and was removed),
+  // so there is nothing to declare a dependency ON. Vendoring was already the right call while it
+  // was merely private, since a public package cannot depend on a private one. index.mjs is
+  // self-contained and imports nothing; the sibling package.json is deliberately NOT shipped —
+  // a nested manifest only confuses packing.
   'clients/bongos-client/index.mjs',
 
   // Neutral branding defaults, so the CLI has sane strings with no instance checkout present.

package/scripts/gds/gen-api-client.js

@@ -10,8 +10,9 @@
 //
 // Design (mirrors gen-api-docs.js / ADR 0063): deterministic (stable sort, no
 // clock), zero runtime deps, --check gate. The client itself has ZERO deps — it
-// uses the platform `fetch` (Node 18+ / browsers), so `npm i @bongos/client`
-// pulls nothing transitive.
+// uses the platform `fetch` (Node 18+ / browsers), so vendoring it pulls nothing
+// transitive. It is NOT published to npm (task 1003742) — consumers copy the build
+// they need; see the generated README.
 //
 // Usage:
 //   node scripts/gds/gen-api-client.js          # (re)generate the client package
@@ -372,10 +373,17 @@ function renderPackageJson(spec) {
     },
     files: ['index.mjs', 'index.cjs', 'index.d.ts', 'bongos-client.global.js', 'README.md'],
     license: 'AGPL-3.0-or-later',
-    // Pre-launch: publish PRIVATE (task 2089 / ADR 0134). Scoped + access:"restricted"
-    // = only paid-org members can install. Flip to "public" (or `npm access public
-    // @bongos/client`) at launch, alongside the core.
-    publishConfig: { access: 'restricted' },
+    // NO publishConfig — this client is NOT an npm package (task 1003742).
+    //
+    // It was published once, 2026-07-07 at 0.0.2, under ADR 0134's private-first plan, and never
+    // updated while the API it is generated FROM moved 500+ core versions. It had zero consumers
+    // the whole time: nothing across the core or any instance repo ever declared it as a
+    // dependency — every consumer VENDORS a copy instead (modules/dev-box/app/src/vendor/, and
+    // build-cli-package.js into @cloudbongos/cli, which could not depend on it anyway). The owner
+    // removed it from the registry on 2026-09-09.
+    //
+    // The manifest itself stays: `main`/`types`/`exports` are what make the vendored copy and a
+    // workspace link resolve. Declaring a publish posture is the part that was fiction.
     sideEffects: false,
   }, null, 2) + '\n';
 }
@@ -427,14 +435,26 @@ function renderReadme(spec, ops) {
     `- API version: **${spec['x-api-version'] || 'v1'}** (served at \`${base}\`)`,
     `- ${ops.length} operations across ${new Set(ops.map((o) => o.tag)).size} resource groups`,
     ``,
-    `## Install`,
+    `## Use it from your project`,
+    ``,
+    `**This is not an npm package** — it is not published, and nothing depends on it as one`,
+    `(task 1003742). Consume it by VENDORING the build you need, which is what every consumer`,
+    `in this repo already does:`,
     ``,
     '```bash',
-    `npm install @bongos/client   # internal registry / workspace path`,
+    `# ESM / bundler:  cp clients/bongos-client/index.mjs  <your project>/vendor/`,
+    `# CommonJS:       cp clients/bongos-client/index.cjs  <your project>/vendor/`,
+    `# Browser global: cp clients/bongos-client/bongos-client.global.js <your project>/public/`,
     '```',
     ``,
+    `Copy \`index.d.ts\` alongside it for types. Re-copy after \`gen-api-client.js\` runs, so the`,
+    `client cannot drift from the routes.`,
+    ``,
     `## Use`,
     ``,
+    `The examples import by package name, which resolves in a workspace. A VENDORED copy is`,
+    `imported by its path instead — \`from './vendor/index.mjs'\` — everything below is identical.`,
+    ``,
     '```js',
     `import { createClient, ApiError } from '@bongos/client';`,
     ``,

package/src/module-api.js

@@ -55,7 +55,7 @@ const { buildInfo } = require('./build-info');
 // 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.619'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.621'; // 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');

package/tests/migration_allocation.mjs

@@ -204,6 +204,7 @@ function shouldReserveMigrationNumber(task) {
         [() => db.updateTaskModuleKey(1, null), 'module_key'],
         [() => db.updateTaskDescription(1, 'edited body'), 'description'], // task 1002647
         [() => db.updateTaskTitle(1, 'corrected title'), 'title'], // task 1002792
+        [() => db.updateTaskPriority(1, 2), 'priority'], // task 1003750
       ];
       for (const [call, column] of setters) {
         const before = seen.length;
@@ -225,10 +226,35 @@ function shouldReserveMigrationNumber(task) {
       'the PATCH schema must declare title with the create-time limits — a title can be rewritten, never blanked'
     );
     assert.ok(/const hasTitle = Object\.prototype\.hasOwnProperty\.call\(body, 'title'\)/.test(routesSrc), 'title is gated like every other field');
-    assert.ok(/&& !hasTitle\) \{/.test(routesSrc), 'a title-only PATCH is a supported request, not no_supported_fields');
+    // Assert !hasTitle is a TERM of the no_supported_fields guard, not that it is
+    // the LAST term: pinning the final position made this red the moment task
+    // 1003750 appended !hasPriority, for a change that kept the stated intent
+    // (a title-only PATCH is supported) perfectly intact.
+    assert.ok(/if \(!hasParent &&[^)]*!hasTitle\b/.test(routesSrc), 'a title-only PATCH is a supported request, not no_supported_fields');
     assert.ok(/db\.updateTaskTitle\(id, body\.title\.trim\(\)\)/.test(routesSrc), 'the write goes through the allowlisted setter');
   });
 
+  // task 1003750: priority was the third write-once planning field (after title
+  // and description above) — accepted at create, then immutable at every rank.
+  // It is the one that steers what gets claimed: version progress is weighted
+  // `6 - COALESCE(priority, 5)` and the optimizer orders by `priority ASC NULLS
+  // LAST`, so re-ranking a goal's board had to be done as raw SQL against prod.
+  await test('PATCH /tasks/:id accepts priority so a board can be re-ranked (task 1003750)', () => {
+    assert.ok(/priority: \{\},\s*\/\/ 1\.\.5 or null/.test(routesSrc), 'the PATCH schema must declare priority so strict-mode admits it');
+    assert.ok(/const hasPriority = Object\.prototype\.hasOwnProperty\.call\(body, 'priority'\)/.test(routesSrc), 'priority is gated like every other field');
+    assert.ok(/if \(!hasParent &&[^)]*!hasPriority\b/.test(routesSrc), 'a priority-only PATCH is a supported request');
+    assert.ok(/db\.updateTaskPriority\(id, body\.priority \?\? null\)/.test(routesSrc), 'the write goes through the allowlisted setter, and null clears');
+    // The bounds must come from the shared TASK_FIELD_BOUNDS the create schema
+    // reads, never a literal 1..5 here — that is how a route and its column drift.
+    assert.ok(/TASK_FIELD_BOUNDS\.priority\.min.*TASK_FIELD_BOUNDS\.priority\.max/s.test(routesSrc), 'priority bounds are shared with the create schema, not re-typed');
+    // Validation must sit ABOVE the first write (the task 1002609 rule this
+    // handler documents): a body mixing a valid field with a bad priority must
+    // commit nothing.
+    const guardAt = routesSrc.indexOf("res.fail('bad_priority'");
+    const firstWriteAt = routesSrc.indexOf('await db.updateTaskKind(');
+    assert.ok(guardAt > 0 && firstWriteAt > 0 && guardAt < firstWriteAt, 'the priority bounds check must run before the first write, not after');
+  });
+
   await test('PATCH /tasks/:id accepts needs_migration so a wrong flag is correctable', () => {
     assert.ok(
       /needs_migration: \{ type: 'boolean' \}/.test(routesSrc),

package/tests/patch_gate_ordering.mjs

@@ -46,6 +46,9 @@ const REFUSALS = [
   // rendered from goalNotOpenRefusal, so the pin looks for the call.
   'goalNotOpenRefusal(goal)',
   "'bad_requires_rank'",
+  // task 1003750: priority joined the PATCH surface; its bounds check is a
+  // validation refusal like the rest, so it must settle before the first write.
+  "'bad_priority'",
   'badKind(res)',
   "'bad_discipline'",
 ];