@bongos/core 1.21.70 → 1.21.72

package/clients/bongos-client/bongos-client.global.js

@@ -1081,6 +1081,8 @@ function createClient(opts = {}) {
     "softwareUpdate": {
       // GET /software-update — rank: any-builder — GET /software-update
       getSoftwareUpdate: (args) => request("GET", "/software-update", { hasBody: false }, args),
+      // POST /software-update/request — rank: archon — POST /software-update/request
+      postSoftwareUpdateRequest: (args) => request("POST", "/software-update/request", { hasBody: true }, args),
     },
     "specialities": {
       // GET /specialities — rank: any-builder — GET /specialities

package/clients/bongos-client/index.cjs

@@ -1080,6 +1080,8 @@ function createClient(opts = {}) {
     "softwareUpdate": {
       // GET /software-update — rank: any-builder — GET /software-update
       getSoftwareUpdate: (args) => request("GET", "/software-update", { hasBody: false }, args),
+      // POST /software-update/request — rank: archon — POST /software-update/request
+      postSoftwareUpdateRequest: (args) => request("POST", "/software-update/request", { hasBody: true }, args),
     },
     "specialities": {
       // GET /specialities — rank: any-builder — GET /specialities

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

@@ -167,7 +167,7 @@ export interface GetSessionsIdResponse { session: unknown }
 export interface GetSessionsIdTranscriptResponse { transcript: unknown }
 export interface GetSessionsMineResponse { sessions: unknown; count: unknown }
 export interface GetSessionsSearchResponse { sessions: unknown; count: unknown; total: unknown; totals: unknown; limit: unknown; offset: unknown; session_types: unknown }
-export interface GetSoftwareUpdateResponse { ok: boolean; update: unknown; door: unknown; can_update: unknown }
+export interface GetSoftwareUpdateResponse { ok: boolean; update: unknown; door: unknown; can_update: unknown; ask: unknown }
 export interface GetSpecialitiesIdDocumentsResponse { documents: unknown }
 export interface GetSpecialitiesIdResponse { speciality: unknown }
 export interface GetSpecialitiesIdSkillsResponse { speciality: unknown; adopted: boolean; enabled: unknown; skills: unknown }
@@ -354,8 +354,8 @@ export interface PostGoalsIdTransferRequest { builder_id?: StringifiableId }
 export interface PostGoalsIdTransferResponse { ok: boolean; goal: unknown; changed: boolean }
 export interface PostGoalsReorderRequest { version_id: string; ordered_ids: number[] }
 export interface PostGoalsReorderResponse { ok: boolean; goals: unknown }
-export interface PostGoalsRequest { version_id: string; title: string; subtitle?: string; description?: string; scope_modules?: string[]; succeeds_goal_id?: number; category_id?: number; admit_reason?: string }
-export interface PostGoalsResponse { ok: boolean; goal: unknown; succeeds_goal_id: unknown; category_advisory: unknown; admitted: unknown }
+export interface PostGoalsRequest { version_id: string; title: string; subtitle?: string; description?: string; scope_modules?: string[]; succeeds_goal_id?: number; category_id?: number; admit_reason?: string; spec_task?: boolean }
+export interface PostGoalsResponse { ok: boolean; goal: unknown; succeeds_goal_id: unknown; category_advisory: unknown; admitted: unknown; spec_task: unknown }
 export interface PostGovernmentAssignmentsRequest { builder_id: number; rank_key: string }
 export interface PostGovernmentBoardCharterRequest { form?: string; franchise?: string; council_rank?: string; pass_rule?: string; rationale_md?: string; acknowledge_self_removal?: boolean }
 export interface PostGovernmentBoardCharterResponse { ok: boolean; amendment: unknown; item: unknown; reads_as: unknown }
@@ -1578,6 +1578,8 @@ export interface BongosClient {
   "softwareUpdate": {
     /** GET /software-update — rank: any-builder */
     getSoftwareUpdate(args?: RequestArgs): Promise<GetSoftwareUpdateResponse>;
+    /** POST /software-update/request — rank: archon */
+    postSoftwareUpdateRequest(args?: RequestArgs): Promise<ApiResponse>;
   };
   "specialities": {
     /** GET /specialities — rank: any-builder */

package/clients/bongos-client/index.mjs

@@ -1077,6 +1077,8 @@ export function createClient(opts = {}) {
     "softwareUpdate": {
       // GET /software-update — rank: any-builder — GET /software-update
       getSoftwareUpdate: (args) => request("GET", "/software-update", { hasBody: false }, args),
+      // POST /software-update/request — rank: archon — POST /software-update/request
+      postSoftwareUpdateRequest: (args) => request("POST", "/software-update/request", { hasBody: true }, args),
     },
     "specialities": {
       // GET /specialities — rank: any-builder — GET /specialities

package/docs/adr/0368-red-and-blue-teams-practice-on-a-range-never-on-live.md

@@ -0,0 +1,99 @@
+# ADR 0368 — Red and blue teams practise on a range, never on live
+
+- **Status:** proposed
+- **Date:** 2026-10-06
+- **Goal:** goal 1000094 (Working area 10 — Security, BONGOS-V2)
+- **Builds on:** [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (the server enforces rank), [ADR 0019](0019-red-team-bounty-payout-table.md) (the bounty table), [ADR 0188](0188-patrol-runs-on-ci-not-the-server.md) (the weekly deterministic patrol), [ADR 0292](0292-both-install-paths-stay-and-vendoring-is-the-production-one.md) (a project is built from a release package), [ADR 0346](0346-dev-boxes-are-retired.md) (no staging since the dev boxes went), [ADR 0361](0361-merges-publish-as-candidates-release-decides-what-others-are-offered.md) (releases publish as candidates before anyone is offered them)
+- **Decided with:** the owner, in a 2026-10-06 scoping interview. Every decision below is theirs; the D-numbers record the answer, not a recommendation.
+
+## Context
+
+Goal 1000094 states its target as *"Red-teaming is consistent"*, and says the server should not be hackable by Claude's latest model. What exists today is all prevention, and some of it is only partly real:
+
+- **Report inbox.** `/builder-redteam` files to `vulnerability_reports` and the Archon adjudicates. Its SKILL.md promises an auto-repro subagent that does not exist (task 1003431).
+- **Bounty table.** The table is in `modules/security/security.js` (10/50/200/1000, overridable with `GDS_BOUNTY_*`). **No bounty has ever been paid:** confirming a report sets `drachmae_awarded` on the report, but nothing writes to `credit_log`.
+- **Patrol.** The weekly CI run (`scripts/gds/redteam-patrol.js`) checks secrets in git history, dependency drift and action pins. It cannot attack a running server.
+- **Detection.** `audit_log` records every authenticated write, refused ones included. It does not record reads or anonymous requests, and nothing alerts anyone.
+- **Rules.** The only written rules are one line in the `#red-team` Discord channel topic: responsible disclosure, no live exploitation.
+- **Staging.** None. There is also no fixture of fake builders at each rank.
+- **Candidates are frequent.** Every merge publishes a candidate (161 in the week to 2026-10-06, about 23 a day). Only the one the owner presses Release on reaches other projects.
+
+The established professional practice has four parts. Bongos has fragments of the second and none of the rest:
+
+1. a practice copy (a *range*) running the exact release about to go live, on fake data;
+2. rules of engagement;
+3. a blue team that detects as well as defends;
+4. a loop that turns every break into a fix plus a permanent check.
+
+## Decision
+
+**D1 — Outcome.** The first version delivers all four of these: an advisory release check (D7), a scoreboard, sides with points (D8), and live detection (D9).
+
+**D2 — The range is its own small server.**
+- It runs on its own server (~$12/month, about 2 GB), separate from the shared box, so attackers may go after the machine itself.
+- **It tests the candidate about to be released, not every candidate.** On `/deploy` the owner marks a candidate "stage for attack". The range is then rebuilt from scratch from that exact version, using the same vendored package a real project gets (ADR 0292). It rebuilds only when the owner chooses to.
+- There is one range at a time. Staging a new candidate replaces the old one.
+- It holds only fake data: fake builders at every rank, at least two fake tenants, and planted *canary secrets* (fake keys whose appearance anywhere proves a breach).
+- It uses stand-ins for GitHub and Discord, so attacking the ship/deploy pipeline or the bot never touches the real services.
+
+**D3 — The range shares nothing with live.**
+- **Logins are already separate.** A session is a random token looked up in each server's own database (`db-kernel.js` `lookupSession`). A range login is therefore unknown to cloudbongos.com, and the reverse holds too.
+- **The real coupling is the identity hub.** An ordinary project signs builders in through cloudbongos.com and reports activity back to it (ADR 0141, `modules/platform-identity`). The range must do neither. It runs its own stand-in hub, and fake builders sign in there.
+- **No real secret is ever placed on the range.** That covers GitHub app keys, the Discord token, npm tokens and DigitalOcean tokens. The range is also never seeded from a copy of the live database.
+- **A test proves the separation.** The range's configuration must name no live hub address and hold no real secret. Only the planted canaries look like secrets.
+
+**D4 — Rules of engagement.**
+- **In bounds:** everything on the range: rank escalation, cross-tenant reach, credit minting, the ship/deploy pipeline (against the stand-ins), the bot stand-in, and the range server itself.
+- **Always out of bounds:**
+  - cloudbongos.com and the real box;
+  - denial of service, meaning flooding the range until it goes down;
+  - social engineering of real people.
+
+  Breaking these rules is a ban, not a bounty. Real GitHub and Discord are out of reach by construction, because the range only knows the stand-ins.
+
+**D5 — Who plays.**
+- **Red (attack):** AI sessions, plus human builders at Metic or above.
+- **Blue (defend):** any builder may take a fix task, as today. The blue area of the hall shows confirmed-but-unfixed breaks, so seeing it requires Metic or above, the same bar as red.
+- **One side at a time.** A builder may switch sides once every 30 days. When a red builder switches, their unconfirmed attempts stay theirs: they are still adjudicated and still credited to that builder as finder. That builder may never claim the fix for their own finding.
+
+**D6 — AI attacks run on subscriptions, never the metered API.**
+- Attack sessions run in a builder's own Claude Code session or headless through the Claude CLI, including under Autobongos.
+- No Bongos-paid API key is used, so the practice adds no model spend.
+- A finding from a session is credited to the builder who ran it, Autobongos runs included.
+
+**D7 — Release check: advisory now, a gate later.**
+- Each candidate's bar is **at least 3 attack runs, on Claude's newest model, each starting as xenos from a fixed attack brief, with no confirmed high or critical break.**
+- While only our own projects run on Bongos, the bar is **advisory**: the deploy page shows a candidate's result beside its Release button, and releasing is unchanged.
+- It becomes a blocking gate when the first outside tenant goes live; that switch is its own decision. Once it blocks, only the Archon may override, and the override records a typed reason in Bongos.
+
+**D8 — Visibility and rewards.**
+- Red attempts are private to the attacker and the Archon. Blue sees a break only once it is confirmed and turned into a fix task.
+- Red and blue each get **their own area of the hall**, with a shared scoreboard (runs per candidate, breaks by severity, fixes, detections).
+- **Points only, no credits yet.** ADR 0019's table stays as the severity scale. Paying it out, the missing `credit_log` write, is deferred until the range has proven itself. When it pays, the finder is the session owner (D6).
+
+**D9 — Live detection.** On cloudbongos.com, alert on three signals:
+- **repeated refusals:** many `rank_forbidden`/`permission_forbidden` responses from one builder or token in a short window;
+- **odd CLI-token use:** a new origin, or unusual volume. Tokens never expire ([ADR 0294](0294-cli-sessions-do-not-expire.md)), so a leaked token is the largest live risk;
+- **credits without a ship:** a credit appearing with no matching shipped task.
+
+Alerts go to a new private `#security-alerts` Discord channel, visible to Archons only and added through `docs/discord/channels.json`. They do not go to the existing channels:
+- `#red-team` is open to every Metic and is where reports are filed;
+- `#security-ship-feed` announces shipped fixes.
+
+The first two signals can be built from `audit_log`, which already records refused authenticated writes. Mass-read detection is deferred, because reads are not logged today.
+
+**D10 — Blue's starting backlog.**
+- The goal's still-valid open tasks become blue's backlog. On 2026-10-06 it had 48 open tasks (44 ready, 1 blocked, 3 backlog), and an audit that day judged about 40 of them still real.
+- The four most urgent go first: 1004380 (a non-ASCII pre-launch password guess crashes the server), 1003412 (the re-auth skill wrongly says re-issuing a token kills the leaked one), and 1004382 + 1004383 (rank, credit and fitness files missing from `protected-surfaces.json`).
+
+## Consequences
+
+- **Cost** is ~$12/month for the range server, and there is no model spend.
+- **Release speed is unchanged while the check is advisory.** Once it is a gate, releasing becomes two steps: stage the candidate, then wait for three attack runs to finish against it.
+- **"Not hackable by Claude's latest model"** becomes a measured, per-release claim instead of an aspiration.
+- **Deferred, each its own later decision:**
+  - credit payouts;
+  - the blocking gate;
+  - mass-read detection;
+  - outside researchers.
+- **A known gap:** with no API spend, attack runs happen only when a builder or Autobongos picks one up. A candidate can sit with zero runs, and the check will show that plainly rather than pass it.

package/docs/adr/README.md

@@ -486,3 +486,4 @@ These 20 numbers are each shared by exactly two files. They are **accepted histo
 | 0365 | [**A guild engages a project through each member's own door** ([task 1002303](https://cloudbongos.com/builders#/task/1002303)). Amends ADR 0336 D7's invite half after ADR 0353. **D1:** the engagement row as D7 specified, plus `guild_id` on the echo (the latest application decides the label). **D2:** a guild applies = each member applies as themselves through the relay, naming the engagement. **D3:** a project invites a guild = the hub records it and returns one hall hand-off link per public-roster member; no hub-written invites, the one-step relay stays deferred. **D4:** a project is named only when on the map and public, for both kinds. **D5:** the label rides the applicant-profile read; the queue is R28's. **D6:** the D4.4 guild cards are their own task.](0365-a-guild-engages-a-project-through-each-members-own-door.md) | guilds / invites / applications |
 | 0366 | [**Hall planning is forms; a goal made there carries its own spec task, and the interviews stay in the CLI** ([task 1003461](https://cloudbongos.com/builders#/task/1003461), goal 1000089). Spike answer. **D1:** form-shaped, build in the hall: create a task under a goal, create a goal (name + subtitle, version, category, no scope field), attach a criterion to a goal you hold; every server refusal rendered as copy. **D2:** interview-shaped, deliberately absent from the hall: version planning, scope inference, drafting criteria and seed tasks, reuse-vs-create judgement, carry-forward. **D3 (owner):** a hall-made goal is created with a "Spec goal N" task (`POST /goals` `spec_task: true`, `source_ref goal-<id>-spec`) and every task in the goal depends on it until it ships; no new permission, no migration. **D4:** an optional "Plan with Claude" hand-off button.](0366-hall-planning-is-forms-and-a-goal-made-there-carries-its-own-spec-task.md) | lifecycle / planning |
 | 0367 | [**The Discord support bot answers from public docs only, under a monthly cap that fails closed** ([task 1002534](https://cloudbongos.com/builders#/task/1002534), goal 1000110). **D1:** one pinned channel, only when @-mentioned; the first gateway reply. **D2:** the corpus is an allowlist (`README.md`, `docs/onboarding/`, `docs/api-reference.md`) served by a new `memory.searchPublicDocs` port whose scope (doc, xenos, no owner, allowlisted ref) is fixed in SQL; the asker is never looked up. **D3:** no writes but the reply and one `audit_log` row per answer, which is also the spend ledger, so no migration. **D4:** a nonce-fenced prompt, no tools, mentions disabled. **D5:** `claude-haiku-4-5`, `DISCORD_SUPPORT_MONTHLY_CAP_USD` default $5, fail closed, with in-flight answers reserved at worst case. **D6:** off by default; its own switch and an env-only, namespaced key. **D7:** the channel's humans review wrong answers; the fix is the doc.](0367-the-support-bot-answers-from-public-docs-only.md) | discord / support / spend |
+| 0368 | [**Red and blue teams practise on a range, never on live** (goal 1000094 — *Working area 10, Security*; proposed). **D2:** the range is its own small server, rebuilt from the candidate the owner marks "stage for attack". **D3:** it shares no identity hub, secret or data with live. **D5:** red is AI plus Metic+, with one side at a time and a 30-day switch. **D6:** attacks run on subscriptions, never the metered API. **D7:** 3 runs on the newest model with 0 high+ breaks, advisory until an outside tenant exists. **D8:** points only, no credits yet. **D9:** three live signals to `#security-alerts`.](0368-red-and-blue-teams-practice-on-a-range-never-on-live.md) | security / red-team / range |

package/docs/api/openapi.json

@@ -20153,6 +20153,40 @@
         ]
       }
     },
+    "/software-update/request": {
+      "post": {
+        "operationId": "post_software_update_request",
+        "tags": [
+          "software-update"
+        ],
+        "summary": "POST /software-update/request",
+        "description": "POST /software-update/request — \"Ask for this upgrade\" (task 1004595). On a project the hub's operator runs, sends one request for the version this project is offered to the operator, through the direct feedback door, and remembers it so the page can say it is pending. The version is the server's own reading, never the caller's. Idempotent per version; a different version waits out a 24h cooldown (429). rank: core.pin.move — the same atom as the Update button the panel draws.\n\n**Rank:** `archon` — Archon only (rank and identity management + the escalation keys — the trust boundary).\n\n**Permissions:** `core.pin.move` (all required).",
+        "x-rank": "archon",
+        "x-source": "src/bongos/routes/core-update.js",
+        "x-permissions": [
+          "core.pin.move"
+        ],
+        "responses": {
+          "200": {
+            "description": "Success."
+          },
+          "400": {
+            "$ref": "#/components/responses/BadRequest"
+          },
+          "401": {
+            "$ref": "#/components/responses/Unauthorized"
+          },
+          "403": {
+            "$ref": "#/components/responses/Forbidden"
+          }
+        },
+        "security": [
+          {
+            "builderSession": []
+          }
+        ]
+      }
+    },
     "/specialities": {
       "get": {
         "operationId": "get_specialities",
@@ -26700,13 +26734,15 @@
           },
           "update": {},
           "door": {},
-          "can_update": {}
+          "can_update": {},
+          "ask": {}
         },
         "required": [
           "ok",
           "update",
           "door",
-          "can_update"
+          "can_update",
+          "ask"
         ]
       },
       "GetSpecialitiesIdDocumentsResponse": {
@@ -29690,6 +29726,9 @@
             "type": "string",
             "minLength": 8,
             "maxLength": 500
+          },
+          "spec_task": {
+            "type": "boolean"
           }
         },
         "required": [
@@ -29707,14 +29746,16 @@
           "goal": {},
           "succeeds_goal_id": {},
           "category_advisory": {},
-          "admitted": {}
+          "admitted": {},
+          "spec_task": {}
         },
         "required": [
           "ok",
           "goal",
           "succeeds_goal_id",
           "category_advisory",
-          "admitted"
+          "admitted",
+          "spec_task"
         ]
       },
       "PostGovernmentAssignmentsRequest": {
@@ -33570,7 +33611,7 @@
       "description": "A required dependency/feature is not configured or is temporarily down."
     }
   },
-  "x-endpoint-count": 522,
+  "x-endpoint-count": 523,
   "x-schema-count": 564,
   "x-undocumented-bodies": 12,
   "x-response-schemas": 374,

package/docs/api-reference.md

@@ -2,7 +2,7 @@
 
 # Bongos API reference
 
-> **Generated from the live route files** — the route file is authoritative. 522 endpoints across 93 route files.
+> **Generated from the live route files** — the route file is authoritative. 523 endpoints across 93 route files.
 > Machine-readable spec: [`docs/api/openapi.json`](api/openapi.json) (OpenAPI 3.1). Rendered docs site: **`/docs`** (e.g. `cloudbongos.com/docs`).
 
 Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/0016-trust-boundary-server-enforced-permissions.md)): `public` < `any-builder` < `metic+archon` < `archon`.
@@ -307,7 +307,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/0016-trust
 | Method | Path | Rank | Body | Description |
 |---|---|---|---|---|
 | GET | `/api/bongos/goals` | `any-builder` | — | GET /goals?version=&status= — list goals (read); each row carries `viewer_is_member` for the reader. |
-| POST | `/api/bongos/goals` | `metic+archon` | `version_id`, `title`, `subtitle`, `description`, `scope_modules`, `succeeds_goal_id`, `category_id`, `admit_reason` | POST /goals — create a goal. |
+| POST | `/api/bongos/goals` | `metic+archon` | `version_id`, `title`, `subtitle`, `description`, `scope_modules`, `succeeds_goal_id`, `category_id`, `admit_reason`, `spec_task` | POST /goals — create a goal. |
 | GET | `/api/bongos/goals/:id` | `any-builder` | — | GET /goals/:id — one goal with its members + linked criteria (read). |
 | PATCH | `/api/bongos/goals/:id` | `any-builder` | — | PATCH /goals/:id — correct a goal's own title/subtitle/description (tasks 1003102, 1003224). |
 | PATCH | `/api/bongos/goals/:id/accepting-requests` | `any-builder` | — | PATCH /goals/:id/accepting-requests { accepting_requests } — a private goal's lead closes or re-opens it to join-requests (task 1002971, … |
@@ -768,11 +768,12 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/0016-trust
 | GET | `/api/bongos/sky` | `any-builder` | — | GET /sky, the whole project sky (task 1004230, ADR 0331). |
 | GET | `/api/bongos/sky/mine` | `any-builder` | — | GET /sky/mine, every thought the SIGNED-IN builder filed with its state, size and descent, capped at 1000 (task 1004230). |
 
-## `software-update` (1)
+## `software-update` (2)
 
 | Method | Path | Rank | Body | Description |
 |---|---|---|---|---|
 | GET | `/api/bongos/software-update` | `any-builder` | — | GET /software-update — Settings → Software update (task 1004296): this project's core, the newest release its channel allows, what the ve… |
+| POST | `/api/bongos/software-update/request` | `archon` | — | POST /software-update/request — "Ask for this upgrade" (task 1004595). |
 
 ## `specialities` (15)