@bongos/core 1.21.69 → 1.21.71

package/.claude/skills/bongos-feedback/SKILL.md

@@ -7,61 +7,25 @@ plain: >-
 reach-for: >-
   When Bongos itself got in your way — a command that failed or confused you, or something you wish it did. You do not have to ask; complaining is enough.
 cost: >-
-  Free. It files one note with the Bongos maintainers and changes nothing in your project.
+  Free, and instant: one line back, and it sends in the background. It changes nothing in your project.
 ---
 
-**Script skill (authoritative).** The core action is `bongos feedback "<message>"` (or `--idea "<message>"`, or `--message-file <path>`). Run it and print its output verbatim.
+Sends a note about Bongos — the tool — straight to its maintainers (tasks 1004462, 1004591). One tool call, one line back.
 
-This **sends** a note about Bongos — the tool — upstream to its maintainers on Cloud Bongos, where a bug becomes a task waiting for a maintainer's approval (tasks 1004462, 1004467).
+**When.** File when the builder (a) labels it — "Bongos feedback: …", "tell the Bongos team" — that **is** the go; (b) wishes — "Bongos should…" (**Suggestions count**: send with `--idea`, even if you also fix it in their project); or (c) vents that Bongos is broken — **File it without being asked**, don't argue them out of it. Only about **Bongos itself** (a `bongos`/`/builder-*` command, claim, ship, grade, deploy, upgrade, hall, Settings, sign-in, credits, how it organises work). Not their own project's code, Claude, their laptop or GitHub, nor a rule working as designed. **One filing per distinct problem per session.**
 
-## Two ways in
+**Write it yourself — Never paste the rant.** First line = what went wrong (it becomes the title); then what they did, what they expected, what happened, the exact error line. No code, file contents, secrets or personal data.
 
-- **Asked** — the builder labels a message as feedback for Bongos ("Bongos feedback: …", "feedback for Bongos", "tell the Bongos team", "report this") or runs `/bongos-feedback`. A message that already says what the feedback is **is** the go: write the report, send it, and show them what was sent. Only when they ask you to report something without saying what, draft it and send on their go.
-- **Suggestions count.** Feedback is not only breakage. "Bongos should…", "I don't want Bongos to…", or a complaint about how Bongos organises their work (versions, goals, tasks, ranks) is feedback too — send it with `--idea`. Fixing it in their own project (moving the goal, saving a preference) is fine, but it does not replace sending it: the next project would hit the same thing.
-- **Proactive** — the builder is venting that Bongos is not working: frustration, swearing, "this is broken again", "why does X keep failing", "Bongos is useless today". **File it without being asked**, then tell them in one line (below). The owner's standing rule (2026-09-30): every rant about Bongos not working becomes something to fix. Do not ask permission first, and do not argue them out of it.
-
-## Is it about Bongos? (proactive mode files only when yes)
-
-File when the complaint is about **Bongos itself**: how it organises their work (a goal that forced a new version, a version they did not want), a `bongos`/`/builder-*` command, a claim, ship, grade, merge or deploy step, the hall, Settings, sign-in, credits, the upgrade, or a Bongos message that confused them.
-
-Do **not** file when it is about their **own project's** code, tests or design, about Claude itself, their laptop, GitHub or another service — or when the "problem" is a rule working as designed (an `[otb-plain]` card saying `By design: Yes`). If it is genuinely unclear, fix the thing in front of you first and file only if it turns out to be Bongos.
-
-**One filing per distinct problem per session.** A second rant about the same failure adds nothing; say it is already filed (with the number) instead.
-
-## Writing the report
-
-Write it yourself from what you saw. **Never paste the rant.** The maintainers need the facts, not the mood:
-
-1. A plain first line naming what went wrong — it becomes the title. (`bongos claim hung for two minutes, then failed with fetch failed`)
-2. What the builder was doing, what they expected, what happened instead, and the exact error line if there was one.
-3. Whether it happened more than once, and any workaround you found.
-
-**Leave out:** code, file contents, secrets, tokens, customer or personal data, and anything about their project the maintainers do not need. Only the text you send travels (plus the Bongos and CLI versions, added automatically). As a backstop the command runs every report through Bongos's secret scrubber and refuses to send if it can't, but it is a backstop, not permission to be careless.
-
-A report that is really a wish ("I'd like Bongos to…") goes with `--idea`.
-
-## Sending
-
-From the project checkout. For anything longer than one line, write the report to a file with the Write tool first — the shell eats backticks inside a quoted argument:
+**Send** (stdin, so nothing in the text is mangled by the shell):
 
 ```bash
-bongos feedback --message-file <path>
+bongos feedback --message-file - <<'EOF'
+<report>
+EOF
 ```
 
-## Telling the builder
-
-**Proactive:** one line, after sending, then carry on with what they were doing. For example: *"I've reported this to the Bongos team as task 1004500 — it's waiting for a maintainer to approve it."* No more than that, unless they ask what was sent — then show them the report.
-
-**Asked:** report the CLI's output verbatim.
-
-## If it refuses
-
-The CLI prints one plain line for each refusal. In proactive mode, a refusal is one line to the builder and nothing more — never retry in a loop.
-
-- **"not connected to Cloud Bongos"** — a self-hosted project has no link to the hub. Point the builder at the Bongos core repository's issue tracker.
-- **"does not yet know you as a member"** — the hub only accepts reports from someone it has seen sign in to this project. Signing in to the project once through Cloud Bongos in a browser fixes it.
-- **"Too much feedback"** — the hourly cap. Don't retry; mention it once.
+Add `--idea` for a wish. The command prints one line — relay it, then carry on. Proactive filing: one short sentence, e.g. *"I've sent that to the Bongos team."* If it says the project runs only on this computer, tell the builder in one line; never retry.
 
 ## Files this skill touches
 
-- Runs: `bongos feedback` → `scripts/gds/feedback-send.js` → `POST /api/bongos/feedback` on this project (`src/bongos/routes/feedback.js`) → the hub's `POST /api/bongos/sso/feedback` (`modules/platform-identity/instance-feedback.js`).
+- Runs: `bongos feedback` → `scripts/gds/feedback-send.js` → a receipt from this project (`POST /api/bongos/feedback/receipt`, `src/bongos/routes/feedback.js`) → the hub's `POST /api/bongos/sso/feedback/direct` (`modules/platform-identity/instance-feedback.js`), which redeems the receipt before filing.

package/.claude/skills/goal-create/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: goal-create
 description: >-
-  Plan and create ONE goal (the module-scoped workspace between a version and its criteria) with its done-when criteria and seed tasks. Metic+. Triggers: "/goal-create", "create a goal", "what goal should this live in", a task created with no goal.
+  Plan and create ONE goal (a module-scoped workspace) with its criteria and seed tasks, or spec one made in the hall. Metic+. Triggers: "/goal-create", "create a goal", "what goal should this live in", "spec goal N", a task created with no goal.
 plain: >-
   Helps you set up a new goal: what it is for, how you will know it is done, and the first tasks to get there.
 reach-for: >-
@@ -89,8 +89,10 @@ The order is forced: a criterion needs `goal_id`, a task needs both `goal_id` an
 > **Always `--body-file`, never inline `--body`, for anything carrying a title, description or criterion prose.** Those strings are authored in this session and routinely contain an apostrophe ("the builder's hall"), which terminates a single-quoted shell argument and corrupts the JSON — or, with a hostile string, runs whatever follows on the builder's machine. Write the body to a temp `.json` file and pass its path. On Windows also heed `scripts/gds/CLAUDE.md`: do **not** create that file with `Out-File`/`>` (the UTF-8 BOM breaks `JSON.parse`), and never pipe `api.js` through `2>&1` (its banner goes to stderr by design).
 
 ```
-# 5a — the goal. STRICT validation: exactly these seven fields are accepted
-#      (version_id*, title*, subtitle, description, scope_modules[], succeeds_goal_id, category_id).
+# 5a — the goal. STRICT validation: exactly these fields are accepted
+#      (version_id*, title*, subtitle, description, scope_modules[], succeeds_goal_id, category_id,
+#      plus admit_reason — Archon only — and spec_task, which ONLY the hall form sends: it makes
+#      the goal arrive with a "Spec goal N" task, the job this skill does inline. Never send it here).
 #      ANY other key is a 400 unknown_field — do NOT pass criteria, tasks, lead or visibility.
 #   goal.json: {"version_id":"<ver>","title":"...","description":"...","scope_modules":["<key>"],"category_id":<id>}
 #   category_id comes from GET /api/bongos/work-categories (task 1003277); omitting it is
@@ -159,6 +161,22 @@ Run the phases above **with the orphan task as the seed** — its title, descrip
 
 **A goal-less task is not an error and was never blocked.** `goal_advisory` is advice on a request that already succeeded. Never fail a build, refuse work, or badger the builder over it — if they say "later", file the idea and move on.
 
+## Finishing a hall-made goal's spec task (task 1004586, ADR 0366 D3)
+
+A goal created from the hall's form has only a name, a description, a version and a category. It arrives with one task inside it, **"Spec goal N: its scope, criteria and first tasks"** (`source: goal-spec`, `source_ref: goal-<N>-spec`), and every other task in that goal waits on it: the server gives each one a dependency on the spec task, so nothing in the goal can be claimed until the spec ships. This skill is how that task gets done. Invoke it with the goal id ("spec goal 1000123") or from the claimed spec task.
+
+1. **Claim the spec task** (`/builder-claim <id>`) if it is not already yours. Find it with `GET "/api/bongos/tasks?goal_id=<N>"` — the row whose `source_ref` is `goal-<N>-spec`.
+2. **Phase 1, with the goal fixed.** Read the goal (`GET /api/bongos/goals/<N>`), its version's other open goals and criteria, and the live module roster exactly as above. The goal's name and description are the person's statement of intent: they are your evidence, as an orphan task's text is in the orphan hook.
+3. **Phase 2 becomes a duplicate check.** Do not create a goal. If another open goal already owns this outcome, raise it in the grey-area round (archive one, or move the work) rather than speccing a duplicate.
+4. **Phase 3 drafts what the form could not ask:** `scope_modules` (inferred and verified exactly as above, never ticked from a list), 2–4 criteria, and the seed tasks with their dependencies. Do not re-draft the name or description; suggest an edit in the grey-area round if one is wrong.
+5. **Phase 4 is unchanged:** at most one grey-area round, then one approval round.
+6. **Phase 5 writes onto the EXISTING goal**, in this order:
+   - **Scope:** `POST /api/bongos/goals/<N>/scope --body '{"add":["<key>"]}'` (keys only, safe inline). The goal's owner or a manager; an Archon for a protected key.
+   - **Criteria:** `POST /api/bongos/versions/<ver>/done-when` with `"goal_id":<N>`, exactly as 5b.
+   - **Seed tasks:** `POST /api/bongos/tasks` with `"goal_id":<N>`, exactly as 5c. **Each one is automatically made to wait on the spec task** — do not remove that edge, and **do not promote them**: they move to `ready` by themselves the moment the spec task ships (the ordinary auto-promotion). Add their own dependency edges (5d) as usual.
+   - **Then ship the spec task** with `/builder-ship`. That ship is what releases the goal's work. Its value summary says what the goal now owns and which tasks became claimable.
+7. **If you do not own or manage the goal,** the scope and criteria writes are refused (403 / `400 bad_goal_id`, see above). Do not work around it: send the drafted scope, criteria and task table to the goal's owner (`/ask-for-help` naming them, or paste it on the spec task), file the seed tasks you are allowed to file, and leave the spec task claimed until the owner has written the rest. A spec task shipped with no scope and no criteria releases a goal that is still undefined, which is the state this task exists to prevent.
+
 ## The sibling advisory: `dependency_advisory` (task 1002827)
 
 The same `POST /tasks` response can also carry a non-null **`dependency_advisory`** — a *different* check, unrelated to which goal the task landed in: it names OPEN tasks in the same version whose `touches[]` overlap this one's, with no declared dependency between them (`scripts/gds/audit-deps.js`'s detector, run live for the first time).

package/clients/bongos-client/README.md

@@ -5,7 +5,7 @@ A **generated**, zero-dependency typed client for the Bongos API — produced fr
 by hand; it regenerates when the spec changes, so it can never drift from the routes.
 
 - API version: **v1** (served at `/api/bongos/v1`)
-- 520 operations across 75 resource groups
+- 523 operations across 75 resource groups
 
 ## Use it from your project
 

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

@@ -385,8 +385,10 @@ function createClient(opts = {}) {
       getDoneWhenPendingReview: (args) => request("GET", "/done-when/pending-review", { hasBody: false }, args),
     },
     "feedback": {
-      // POST /feedback — rank: any-builder — POST /feedback
-      postFeedback: (args) => request("POST", "/feedback", { hasBody: true }, args),
+      // POST /feedback/receipt — rank: any-builder — POST /feedback/receipt
+      postFeedbackReceipt: (args) => request("POST", "/feedback/receipt", { hasBody: true }, args),
+      // GET /feedback/receipt/{id} — rank: public — GET /feedback/receipt/:id
+      getFeedbackReceiptId: (args) => request("GET", "/feedback/receipt/{id}", { hasBody: false }, args),
     },
     "founding": {
       // POST /founding/alive — rank: any-builder — POST /founding/alive
@@ -1079,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
@@ -1125,6 +1129,8 @@ function createClient(opts = {}) {
       postSsoDeviceStart: (args) => request("POST", "/sso/device/start", { hasBody: true }, args),
       // POST /sso/feedback — rank: public — POST /sso/feedback
       postSsoFeedback: (args) => request("POST", "/sso/feedback", { hasBody: true }, args),
+      // POST /sso/feedback/direct — rank: public — POST /sso/feedback/direct
+      postSsoFeedbackDirect: (args) => request("POST", "/sso/feedback/direct", { hasBody: true }, args),
       // POST /sso/invites/clear — rank: public — POST /sso/invites/clear
       postSsoInvitesClear: (args) => request("POST", "/sso/invites/clear", { hasBody: true }, args),
       // POST /sso/invites/notify — rank: public — POST /sso/invites/notify

package/clients/bongos-client/index.cjs

@@ -384,8 +384,10 @@ function createClient(opts = {}) {
       getDoneWhenPendingReview: (args) => request("GET", "/done-when/pending-review", { hasBody: false }, args),
     },
     "feedback": {
-      // POST /feedback — rank: any-builder — POST /feedback
-      postFeedback: (args) => request("POST", "/feedback", { hasBody: true }, args),
+      // POST /feedback/receipt — rank: any-builder — POST /feedback/receipt
+      postFeedbackReceipt: (args) => request("POST", "/feedback/receipt", { hasBody: true }, args),
+      // GET /feedback/receipt/{id} — rank: public — GET /feedback/receipt/:id
+      getFeedbackReceiptId: (args) => request("GET", "/feedback/receipt/{id}", { hasBody: false }, args),
     },
     "founding": {
       // POST /founding/alive — rank: any-builder — POST /founding/alive
@@ -1078,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
@@ -1124,6 +1128,8 @@ function createClient(opts = {}) {
       postSsoDeviceStart: (args) => request("POST", "/sso/device/start", { hasBody: true }, args),
       // POST /sso/feedback — rank: public — POST /sso/feedback
       postSsoFeedback: (args) => request("POST", "/sso/feedback", { hasBody: true }, args),
+      // POST /sso/feedback/direct — rank: public — POST /sso/feedback/direct
+      postSsoFeedbackDirect: (args) => request("POST", "/sso/feedback/direct", { hasBody: true }, args),
       // POST /sso/invites/clear — rank: public — POST /sso/invites/clear
       postSsoInvitesClear: (args) => request("POST", "/sso/invites/clear", { hasBody: true }, args),
       // POST /sso/invites/notify — rank: public — POST /sso/invites/notify

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 }
@@ -316,7 +316,8 @@ export interface PostDoneWhenCriterionIdUatRequest { kind: string; recording?: s
 export interface PostDoneWhenCriterionIdUatResponse { ok: boolean; signoff: unknown; criterion_closed: unknown; achieved_goals: unknown; closed_versions: unknown }
 export interface PostDoneWhenCriterionIdUnsatisfyRequest { reason?: string }
 export interface PostDoneWhenCriterionIdUnsatisfyResponse { criterion: unknown }
-export interface PostFeedbackRequest { message: string; kind?: "bug" | "idea"; context?: unknown }
+export interface PostFeedbackReceiptRequest { sha256: string; kind?: "bug" | "idea" }
+export interface PostFeedbackReceiptResponse { ok: boolean; receipt: unknown; hub: unknown }
 export interface PostFoundingPlanRequest { days?: Record<string, unknown>; passes?: number; advisors?: string; government?: string; expected_builders?: number; existing?: boolean }
 export interface PostGithubRepoVisibilityRequest { repo: string; visibility: "public" | "private" }
 export interface PostGithubRepoVisibilityResponse { ok: boolean; repo: unknown; private_deployable: boolean }
@@ -353,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 }
@@ -496,6 +497,8 @@ export interface PostSsoApplicantProfileRequest { client_id: string; client_secr
 export interface PostSsoApplicantProfileResponse { profile: unknown; guild: unknown }
 export interface PostSsoDevicePollRequest { device_code: string }
 export interface PostSsoDeviceStartRequest { origin: string }
+export interface PostSsoFeedbackDirectRequest { origin: string; receipt: string; message: string; kind?: string; context?: unknown }
+export interface PostSsoFeedbackDirectResponse { ok: boolean; accepted: boolean }
 export interface PostSsoFeedbackRequest { client_id: string; client_secret: string; github_id: StringifiableId; message: string; kind?: string; context?: unknown }
 export interface PostSsoInvitesClearRequest { client_id: string; client_secret: string; github_login: string }
 export interface PostSsoInvitesNotifyRequest { client_id: string; client_secret: string; github_login: string }
@@ -879,8 +882,10 @@ export interface BongosClient {
     getDoneWhenPendingReview(args?: RequestArgs): Promise<GetDoneWhenPendingReviewResponse>;
   };
   "feedback": {
-    /** POST /feedback — rank: any-builder */
-    postFeedback(args: RequestArgs & { body: PostFeedbackRequest }): Promise<ApiResponse>;
+    /** POST /feedback/receipt — rank: any-builder */
+    postFeedbackReceipt(args: RequestArgs & { body: PostFeedbackReceiptRequest }): Promise<PostFeedbackReceiptResponse>;
+    /** GET /feedback/receipt/{id} — rank: public */
+    getFeedbackReceiptId(args?: RequestArgs): Promise<ApiResponse>;
   };
   "founding": {
     /** POST /founding/alive — rank: any-builder */
@@ -1573,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 */
@@ -1619,6 +1626,8 @@ export interface BongosClient {
     postSsoDeviceStart(args: RequestArgs & { body: PostSsoDeviceStartRequest }): Promise<ApiResponse>;
     /** POST /sso/feedback — rank: public */
     postSsoFeedback(args: RequestArgs & { body: PostSsoFeedbackRequest }): Promise<ApiResponse>;
+    /** POST /sso/feedback/direct — rank: public */
+    postSsoFeedbackDirect(args: RequestArgs & { body: PostSsoFeedbackDirectRequest }): Promise<PostSsoFeedbackDirectResponse>;
     /** POST /sso/invites/clear — rank: public */
     postSsoInvitesClear(args: RequestArgs & { body: PostSsoInvitesClearRequest }): Promise<ApiResponse>;
     /** POST /sso/invites/notify — rank: public */

package/clients/bongos-client/index.mjs

@@ -381,8 +381,10 @@ export function createClient(opts = {}) {
       getDoneWhenPendingReview: (args) => request("GET", "/done-when/pending-review", { hasBody: false }, args),
     },
     "feedback": {
-      // POST /feedback — rank: any-builder — POST /feedback
-      postFeedback: (args) => request("POST", "/feedback", { hasBody: true }, args),
+      // POST /feedback/receipt — rank: any-builder — POST /feedback/receipt
+      postFeedbackReceipt: (args) => request("POST", "/feedback/receipt", { hasBody: true }, args),
+      // GET /feedback/receipt/{id} — rank: public — GET /feedback/receipt/:id
+      getFeedbackReceiptId: (args) => request("GET", "/feedback/receipt/{id}", { hasBody: false }, args),
     },
     "founding": {
       // POST /founding/alive — rank: any-builder — POST /founding/alive
@@ -1075,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
@@ -1121,6 +1125,8 @@ export function createClient(opts = {}) {
       postSsoDeviceStart: (args) => request("POST", "/sso/device/start", { hasBody: true }, args),
       // POST /sso/feedback — rank: public — POST /sso/feedback
       postSsoFeedback: (args) => request("POST", "/sso/feedback", { hasBody: true }, args),
+      // POST /sso/feedback/direct — rank: public — POST /sso/feedback/direct
+      postSsoFeedbackDirect: (args) => request("POST", "/sso/feedback/direct", { hasBody: true }, args),
       // POST /sso/invites/clear — rank: public — POST /sso/invites/clear
       postSsoInvitesClear: (args) => request("POST", "/sso/invites/clear", { hasBody: true }, args),
       // POST /sso/invites/notify — rank: public — POST /sso/invites/notify

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 |