@bongos/core 1.19.918 → 1.19.919

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/.bongos-core.json CHANGED
@@ -2,22 +2,22 @@
2
2
  "artifact": "bongos-core",
3
3
  "manifest_schema": 1,
4
4
  "generator": "scripts/gds/package-core.js",
5
- "core_version": "1.19.918",
6
- "core_contract": "1.19.918",
7
- "source_commit": "d9c3f86944e01f8135ce13bc9476f2ef3c86c00a",
5
+ "core_version": "1.19.919",
6
+ "core_contract": "1.19.919",
7
+ "source_commit": "bc2cae9667f75f9a2df301fc776a5e0b79451325",
8
8
  "source_ref": "HEAD",
9
- "built_at": "2026-09-20T18:32:13.181Z",
9
+ "built_at": "2026-09-20T19:06:48.075Z",
10
10
  "redaction": {
11
11
  "model": "docs-redacted+functional-verbatim",
12
- "docs_redacted": 507,
12
+ "docs_redacted": 508,
13
13
  "agent_docs_stubbed": 26,
14
- "functional_verbatim": 2298,
14
+ "functional_verbatim": 2302,
15
15
  "rules": 3,
16
16
  "gate_literals": 3,
17
17
  "gate": "passed"
18
18
  },
19
- "file_count": 2831,
20
- "tree_sha256": "7ecf5ebe792ee91db6d6d40ef4e6b49ea2d375af7a1c100885d66c7e266e5171",
19
+ "file_count": 2836,
20
+ "tree_sha256": "fcb4d5d17d74106fc9ba7d49143956885bb9c5dadc48c2e1a3aa39ebcc76a851",
21
21
  "files": [
22
22
  {
23
23
  "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -347,12 +347,12 @@
347
347
  {
348
348
  "path": "clients/bongos-client/README.md",
349
349
  "mode": "0000644",
350
- "sha256": "3d49c3ab2ec849b4b6b8856fc33161dae6d4728565afc3e781c9f9b8c00068c5"
350
+ "sha256": "56d3e08ff4e4893d4d6b30c9292f2c1b0730deb2bff99ea64d7d5df7971995c1"
351
351
  },
352
352
  {
353
353
  "path": "clients/bongos-client/bongos-client.global.js",
354
354
  "mode": "0000644",
355
- "sha256": "2697c2c2ca3b5ede19b7f5511eb51ae6173973b4db01d20183ef560a95315c42"
355
+ "sha256": "7cfab2d88dc9d36fc57334db3b43c0c31b3656e2bff7ebff11d0c18b12a61850"
356
356
  },
357
357
  {
358
358
  "path": "clients/bongos-client/examples/hello-world.mjs",
@@ -362,17 +362,17 @@
362
362
  {
363
363
  "path": "clients/bongos-client/index.cjs",
364
364
  "mode": "0000644",
365
- "sha256": "b80472a5a66e342b8dc9c09c61a570cc3272756cf311eb16f77a125d8ae66afd"
365
+ "sha256": "8a5ed1946540c3adb30ff986f1845bdc65b5a6e441698723f8c31eb8e1374ef2"
366
366
  },
367
367
  {
368
368
  "path": "clients/bongos-client/index.d.ts",
369
369
  "mode": "0000644",
370
- "sha256": "de24c22270e6a95dcf5674aac3b445e08fce3cd1982d0e922d84ca9e199a36e0"
370
+ "sha256": "e84a082d51b6f1e3890886a087763ec155fa31d17ac697a291e557df5bce2345"
371
371
  },
372
372
  {
373
373
  "path": "clients/bongos-client/index.mjs",
374
374
  "mode": "0000644",
375
- "sha256": "084e5d2634ec4a5ddbc4a537ad32ec88296bb55f0439c7c4dc8e534eaad5fd71"
375
+ "sha256": "7676427e266c9528793e47c3c9431c329b67f0b29edff522724f430b4c29a37f"
376
376
  },
377
377
  {
378
378
  "path": "clients/bongos-client/package.json",
@@ -2084,20 +2084,25 @@
2084
2084
  "mode": "0000644",
2085
2085
  "sha256": "d5364169236db8c8d1a7968051fba352bb368aca53b19e554f172e0c3dc90d5d"
2086
2086
  },
2087
+ {
2088
+ "path": "docs/adr/0319-a-removal-verdict-is-a-row-beside-the-question.md",
2089
+ "mode": "0000644",
2090
+ "sha256": "2fbb3e040b55162284242f545af76b1254fafbecfe042b8c792dc0dca475c4f8"
2091
+ },
2087
2092
  {
2088
2093
  "path": "docs/adr/README.md",
2089
2094
  "mode": "0000644",
2090
- "sha256": "9cebfdfef7de4b2c0ede697b30f387121f2a4a0df695b21b205f16acea84bad9"
2095
+ "sha256": "087b5151c182476c1f541e239776099319ad7fa95e6ebc2dc5ccf2b320c84f0c"
2091
2096
  },
2092
2097
  {
2093
2098
  "path": "docs/api-reference.md",
2094
2099
  "mode": "0000644",
2095
- "sha256": "dfc37d531b880bc87d6d4e1b09eae50ef3e0301781ed84923304bc77b878b9b9"
2100
+ "sha256": "8c709c0a86391ef42df7c594087d8ebe77bb26c19b8f92f95a21c19da30de87e"
2096
2101
  },
2097
2102
  {
2098
2103
  "path": "docs/api/openapi.json",
2099
2104
  "mode": "0000644",
2100
- "sha256": "8ab5797e6b515965da750890ab78ae16d61326d19a26751a0dde3bc2f72b6797"
2105
+ "sha256": "6e2d8fc4d48d267ee7b16a81f48651c6d19dfa55716d7736c92e5cb734cc6b4f"
2101
2106
  },
2102
2107
  {
2103
2108
  "path": "docs/architecture.md",
@@ -2122,12 +2127,12 @@
2122
2127
  {
2123
2128
  "path": "docs/copy-inventory.md",
2124
2129
  "mode": "0000644",
2125
- "sha256": "cadfe92b87eaf4f2bb952debc703c53b833fd83badbefcce40e7203a0d150c95"
2130
+ "sha256": "4f848ba8e139ff864151d71e4f743f799b23cf1d6a59e3638aae13ed45bce4d6"
2126
2131
  },
2127
2132
  {
2128
2133
  "path": "docs/copy-registry.json",
2129
2134
  "mode": "0000644",
2130
- "sha256": "f6571a42a27d5cfeef058d06937fc669a31da076bc26972c5e29a8fa1d156b5d"
2135
+ "sha256": "dc177418430b6f87b508867d35d8ef7e821d113d0ede598462a690402d699f46"
2131
2136
  },
2132
2137
  {
2133
2138
  "path": "docs/design/apex-pass-2-direction.md",
@@ -2657,7 +2662,7 @@
2657
2662
  {
2658
2663
  "path": "docs/module-api-changelog.md",
2659
2664
  "mode": "0000644",
2660
- "sha256": "824b753887223eeba6c21424a6a1f0984235e33165799114ac4a40993bb9b080"
2665
+ "sha256": "e15b7bc78c0b64fc27725df643ec05f20e047322623ac182f3614fea341521bb"
2661
2666
  },
2662
2667
  {
2663
2668
  "path": "docs/modules-contract.md",
@@ -4842,7 +4847,7 @@
4842
4847
  {
4843
4848
  "path": "modules/hall-ui/public/goal-inbox.js",
4844
4849
  "mode": "0000644",
4845
- "sha256": "21a107078833924161c2111f40586272eed71eeba7eb1686088b1d2000d9ff78"
4850
+ "sha256": "8e8d581eb99bbff050e088b727266b9f4c0ab957d1c98fd407e2c4d592a5c8b3"
4846
4851
  },
4847
4852
  {
4848
4853
  "path": "modules/hall-ui/public/goals-lib.js",
@@ -5262,7 +5267,7 @@
5262
5267
  {
5263
5268
  "path": "modules/hall-ui/public/style.css",
5264
5269
  "mode": "0000644",
5265
- "sha256": "4eb1af09e4c3fde77f892f137f32ef768396eb9b0400515c01903128d394de9e"
5270
+ "sha256": "a7824a889c87fe40725350fd9543929e69e1370fb17023af0447f8254887d72e"
5266
5271
  },
5267
5272
  {
5268
5273
  "path": "modules/hall-ui/public/task-detail.js",
@@ -5507,7 +5512,7 @@
5507
5512
  {
5508
5513
  "path": "modules/lifecycle/cascade.js",
5509
5514
  "mode": "0000644",
5510
- "sha256": "52e63c329e4546f0a8ce2ca75157b9974b23eeaabf155f7ea02ead4d8f9bb8a8"
5515
+ "sha256": "fd8aeec221eede847aa3b0047c01721ac7e2076e95675a71a117eff3bf3bbc55"
5511
5516
  },
5512
5517
  {
5513
5518
  "path": "modules/lifecycle/check-rollup.js",
@@ -5744,6 +5749,11 @@
5744
5749
  "mode": "0000644",
5745
5750
  "sha256": "4e4099764712b6ac8ad322cb846eb1e4b1118e936d03628e01a6a04adb4d4ebf"
5746
5751
  },
5752
+ {
5753
+ "path": "modules/lifecycle/migrations/lifecycle_009_removal_verdicts.sql",
5754
+ "mode": "0000644",
5755
+ "sha256": "e98efbb1537f0d99adb6b6b66c1fdccfd4bbac16b97362d479af903eb9de492c"
5756
+ },
5747
5757
  {
5748
5758
  "path": "modules/lifecycle/mingle.js",
5749
5759
  "mode": "0000644",
@@ -5752,7 +5762,7 @@
5752
5762
  {
5753
5763
  "path": "modules/lifecycle/module.json",
5754
5764
  "mode": "0000644",
5755
- "sha256": "4c6e01ef15774232ad9284915546b2d9756dc89f85159980fb7087e7a6673d3c"
5765
+ "sha256": "01f96d398408491bc4f1d9357c23c259f16e52184569849a0caf775f5b38836b"
5756
5766
  },
5757
5767
  {
5758
5768
  "path": "modules/lifecycle/pg-constraint-fail.js",
@@ -5779,6 +5789,11 @@
5779
5789
  "mode": "0000644",
5780
5790
  "sha256": "ef63843d5d00230a90063c454a5ad7a9dc170ce26cedc99377807ae1ced3f7c0"
5781
5791
  },
5792
+ {
5793
+ "path": "modules/lifecycle/removal-proposals.js",
5794
+ "mode": "0000644",
5795
+ "sha256": "8270ce55255998a4f0bbf574a54df0ba2597013c727b4afb1ce2abad9c9d4d2a"
5796
+ },
5782
5797
  {
5783
5798
  "path": "modules/lifecycle/rot.js",
5784
5799
  "mode": "0000644",
@@ -5864,6 +5879,11 @@
5864
5879
  "mode": "0000644",
5865
5880
  "sha256": "a8e851ca630a24b197e7ecb8f8cd8ac3d169801bacbac72097528500f95d6cdb"
5866
5881
  },
5882
+ {
5883
+ "path": "modules/lifecycle/routes/removal-proposals.js",
5884
+ "mode": "0000644",
5885
+ "sha256": "329f130d3556dc05981ce6b4b6ce4d55984c6ca42fd0f421fd70cba63eb277ac"
5886
+ },
5867
5887
  {
5868
5888
  "path": "modules/lifecycle/routes/rot.js",
5869
5889
  "mode": "0000644",
@@ -7852,12 +7872,12 @@
7852
7872
  {
7853
7873
  "path": "package-lock.json",
7854
7874
  "mode": "0000644",
7855
- "sha256": "9842c68958d709653d9006a15332aa271621aaa6e4fac8de8411896a6c103042"
7875
+ "sha256": "c74ec04aa7a18c9c94e42afecaac34a114331a3769e1df4af00e192555155f66"
7856
7876
  },
7857
7877
  {
7858
7878
  "path": "package.json",
7859
7879
  "mode": "0000644",
7860
- "sha256": "31b797c1d71820a20e2744debb104990294e44cf943d24aeed1b77b35e2f1b2a"
7880
+ "sha256": "fc839d817a279254882dd33532bbbb2831174de15f28b3c72a3830021e8ded5f"
7861
7881
  },
7862
7882
  {
7863
7883
  "path": "public-docs/index.html",
@@ -9452,7 +9472,7 @@
9452
9472
  {
9453
9473
  "path": "scripts/hall-preview/refresh-fixtures.js",
9454
9474
  "mode": "0000644",
9455
- "sha256": "3faeb959f81f32e23b11c9ab623df7899bae647c07837bca54c946e7807ef0f6"
9475
+ "sha256": "3974f78c40edde5fd07b2e14dcb0c8ceb45e7b0bd510cafde3a0670b41421586"
9456
9476
  },
9457
9477
  {
9458
9478
  "path": "scripts/hall-preview/server.js",
@@ -9857,7 +9877,7 @@
9857
9877
  {
9858
9878
  "path": "src/module-api.js",
9859
9879
  "mode": "0000644",
9860
- "sha256": "250d1791c44836efe9407a5a524a0171bf7ad0c9b337c0cfaa6dd4c491b76d7c"
9880
+ "sha256": "e5fb0cc646c7821da2c99ceb43ee9a9214399fb81b1ee26e1c9bc84ff5bff380"
9861
9881
  },
9862
9882
  {
9863
9883
  "path": "src/module-loader/catalog.js",
@@ -10377,7 +10397,7 @@
10377
10397
  {
10378
10398
  "path": "tests/blockers_hall.mjs",
10379
10399
  "mode": "0000644",
10380
- "sha256": "3b3b24fe066acff344af8eabee0feb6df0b4129ad688d990cfed4c8a60d9cd33"
10400
+ "sha256": "b071e16e40b5acfeab02eb756c56ddba608d07068072b7f767737a4dcd588b68"
10381
10401
  },
10382
10402
  {
10383
10403
  "path": "tests/blockers_kit_pager.mjs",
@@ -13129,6 +13149,11 @@
13129
13149
  "mode": "0000644",
13130
13150
  "sha256": "b447287dca1ffe65a926715e0a5f07c0a05e3503066febf85b7f6d317b805c8f"
13131
13151
  },
13152
+ {
13153
+ "path": "tests/removal_verdict.mjs",
13154
+ "mode": "0000644",
13155
+ "sha256": "16017d19192929aea21956a6cf5e52fa1767e2c12a7e37c5453c17b9e83b8368"
13156
+ },
13132
13157
  {
13133
13158
  "path": "tests/rename_history_restraint.mjs",
13134
13159
  "mode": "0000644",
@@ -5,7 +5,7 @@ A **generated**, zero-dependency typed client for the Bongos API — produced fr
5
5
  by hand; it regenerates when the spec changes, so it can never drift from the routes.
6
6
 
7
7
  - API version: **v1** (served at `/api/bongos/v1`)
8
- - 401 operations across 60 resource groups
8
+ - 403 operations across 61 resource groups
9
9
 
10
10
  ## Use it from your project
11
11
 
@@ -802,6 +802,12 @@ function createClient(opts = {}) {
802
802
  // GET /public/versions — rank: public — GET /public/versions
803
803
  getPublicVersions: (args) => request("GET", "/public/versions", { hasBody: false }, args),
804
804
  },
805
+ "removalProposals": {
806
+ // GET /removal-proposals — rank: metic+archon — GET /removal-proposals
807
+ getRemovalProposals: (args) => request("GET", "/removal-proposals", { hasBody: false }, args),
808
+ // POST /removal-proposals/{id}/decide — rank: metic+archon — POST /removal-proposals/:id/decide
809
+ postRemovalProposalsIdDecide: (args) => request("POST", "/removal-proposals/{id}/decide", { hasBody: true }, args),
810
+ },
805
811
  "scouting": {
806
812
  // GET /scouting — rank: metic+archon — GET /scouting
807
813
  getScouting: (args) => request("GET", "/scouting", { hasBody: false }, args),
@@ -801,6 +801,12 @@ function createClient(opts = {}) {
801
801
  // GET /public/versions — rank: public — GET /public/versions
802
802
  getPublicVersions: (args) => request("GET", "/public/versions", { hasBody: false }, args),
803
803
  },
804
+ "removalProposals": {
805
+ // GET /removal-proposals — rank: metic+archon — GET /removal-proposals
806
+ getRemovalProposals: (args) => request("GET", "/removal-proposals", { hasBody: false }, args),
807
+ // POST /removal-proposals/{id}/decide — rank: metic+archon — POST /removal-proposals/:id/decide
808
+ postRemovalProposalsIdDecide: (args) => request("POST", "/removal-proposals/{id}/decide", { hasBody: true }, args),
809
+ },
804
810
  "scouting": {
805
811
  // GET /scouting — rank: metic+archon — GET /scouting
806
812
  getScouting: (args) => request("GET", "/scouting", { hasBody: false }, args),
@@ -128,6 +128,7 @@ export interface GetPublicRepoInfoResponse { blob_base: unknown; tree_base: unkn
128
128
  export interface GetPublicTasksIdResponse { task: unknown }
129
129
  export interface GetPublicUptimeResponse { services: unknown }
130
130
  export interface GetPublicVersionsResponse { versions: unknown; page: PageInfo }
131
+ export interface GetRemovalProposalsResponse { pending: unknown; count: unknown }
131
132
  export interface GetScoutingHandleResponse { sliver: unknown }
132
133
  export interface GetScoutingResponse { builders: unknown }
133
134
  export interface GetSecurityDocsResponse { docs: unknown }
@@ -372,6 +373,7 @@ export interface PostProvisioningInstancesIdGithubAppResponse { state: unknown;
372
373
  export interface PostProvisioningInstancesIdRestartResponse { ok: boolean; queued: unknown; action: unknown; status: unknown; message: unknown }
373
374
  export interface PostProvisioningInstancesIdTeardownResponse { ok: boolean; queued: unknown; action: unknown; status: unknown; superseded: unknown; message: unknown }
374
375
  export interface PostProvisioningInstancesRequest { slug: string; target_ref?: string; hosting_shape?: string; domain?: string; no_address?: boolean; tier?: string; onboard_mode?: string; type?: string; description?: string; detail?: Record<string, unknown>; modules?: string[] }
376
+ export interface PostRemovalProposalsIdDecideRequest { verdict: string; note?: string }
375
377
  export interface PostSearchMarkRequest { chunk_id?: StringifiableId; useful?: unknown }
376
378
  export interface PostSearchRequest { expand?: unknown; q?: string; source_kind?: string; limit?: unknown }
377
379
  export interface PostSearchResponse { expand?: unknown; chunk?: unknown; query?: unknown; count?: unknown; total_full_tokens?: unknown; results?: unknown; corpus?: unknown }
@@ -1175,6 +1177,12 @@ export interface BongosClient {
1175
1177
  /** GET /public/versions — rank: public */
1176
1178
  getPublicVersions(args?: RequestArgs): Promise<GetPublicVersionsResponse>;
1177
1179
  };
1180
+ "removalProposals": {
1181
+ /** GET /removal-proposals — rank: metic+archon */
1182
+ getRemovalProposals(args?: RequestArgs): Promise<GetRemovalProposalsResponse>;
1183
+ /** POST /removal-proposals/{id}/decide — rank: metic+archon */
1184
+ postRemovalProposalsIdDecide(args: RequestArgs & { body: PostRemovalProposalsIdDecideRequest }): Promise<ApiResponse>;
1185
+ };
1178
1186
  "scouting": {
1179
1187
  /** GET /scouting — rank: metic+archon */
1180
1188
  getScouting(args?: RequestArgs): Promise<GetScoutingResponse>;
@@ -798,6 +798,12 @@ export function createClient(opts = {}) {
798
798
  // GET /public/versions — rank: public — GET /public/versions
799
799
  getPublicVersions: (args) => request("GET", "/public/versions", { hasBody: false }, args),
800
800
  },
801
+ "removalProposals": {
802
+ // GET /removal-proposals — rank: metic+archon — GET /removal-proposals
803
+ getRemovalProposals: (args) => request("GET", "/removal-proposals", { hasBody: false }, args),
804
+ // POST /removal-proposals/{id}/decide — rank: metic+archon — POST /removal-proposals/:id/decide
805
+ postRemovalProposalsIdDecide: (args) => request("POST", "/removal-proposals/{id}/decide", { hasBody: true }, args),
806
+ },
801
807
  "scouting": {
802
808
  // GET /scouting — rank: metic+archon — GET /scouting
803
809
  getScouting: (args) => request("GET", "/scouting", { hasBody: false }, args),
@@ -0,0 +1,69 @@
1
+ # ADR 0319 — A removal verdict is a row beside the question, because both answers close it the same way
2
+
3
+ **Status:** accepted · **Date:** 2026-09-20 · **Task:** [task 1004095](https://cloudbongos.com/builders#/task/1004095) (goal 1000095 — BONGOS-V2)
4
+
5
+ **Related:** [ADR 0313](0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md) (the decision of record — the system proposes, a person confirms) · [ADR 0242](0242-a-cascade-is-a-declaration-table-on-the-event-that-already-exists.md) (the runner a rule is appended to, and may not fan out) · [ADR 0299](0299-the-nod-queue-stays-scoped-to-routed-filings.md) (why the nod queue is not widened) · [ADR 0312](0312-provenance-is-a-second-ideas-owned-edge-table.md) (the descent a confirmed removal dims)
6
+
7
+ ## Context
8
+
9
+ [ADR 0313](0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md) settled that a ship which deletes an earlier shipped task's files files a **question**, and that a person answers it: Metic+, `task.promote`, on the existing awaiting-nod surface, with an unanswered proposal rotting on the normal clock. Task 1004090 built the question. Nothing could answer it.
10
+
11
+ Answering turns out to have one property that decides the whole design: **both answers close the proposal the same way.** The proposal is a question, not work — confirming leaves nothing to build, and so does dismissing. Either way the only sensible end state for that task row is `abandoned`, the ledger's one spelling of "finished with the project, not delivered" (`modules/lifecycle/task-status.js`).
12
+
13
+ So a status alone cannot be the record. "Yes, that work is gone" and "no, that was a refactor" would be the same row, and brightness — the live share of a descent, the next task in this chain — would have no way to tell the star it must dim from the one it must not. ADR 0313 already ruled out the obvious alternative: a `removed` task status, because `shipped` is terminal by design and a removal is "a fact about work's fate, recorded beside it, not a new terminal state that ship rollup would have to learn."
14
+
15
+ ## Decision
16
+
17
+ ### The verdict is its own row, and there is exactly one of them per proposal
18
+
19
+ `lifecycle_removal_verdicts` (migration `lifecycle_009`) holds `proposal_task_id` (**primary key**), `ship_task_id`, `verdict ∈ {confirmed, dismissed}`, `decided_by`, `decided_at`, `note`. It is the "beside it" ADR 0313 asked for. The verdict write and the status change commit in **one transaction**: a verdict with no closed task would be re-answerable, and a closed task with no verdict is precisely the erasure this exists to prevent.
20
+
21
+ The primary key on `proposal_task_id` is a decision, not a default. A second answer is **refused** (`ALREADY_DECIDED`, 409), never upserted and never treated as an idempotent success, because overwriting destroys the only record that a person answered differently. The proposal row is locked `FOR UPDATE` before any of the row-scoped checks, so two people pressing Confirm and Dismiss at the same moment cannot both read "undecided"; the second loses on the refusal rather than winning on write order. Amending a verdict is deliberately not built: if it is ever needed it is a second row and an append-only history, not an UPDATE.
22
+
23
+ `ALREADY_DECIDED` is checked **before** `PROPOSAL_CLOSED`, because an answered proposal is also abandoned — checking status first would tell someone "this is not an open question" when the useful answer is "it was dismissed, by builder 7, yesterday".
24
+
25
+ ### The verdict is what this ships; the target list is not
26
+
27
+ The proposal names the affected tasks and paths as **prose in its body**, because a cascade files one task per rule per ship with no field for a target and ADR 0242 forbids widening the runner to fan out (owner decision, 2026-09-20, recorded in `cascade.js:removalProposalBody`). This ADR does not change that and does not parse it. A body is written for a person to read; a reader that silently depends on its line shape breaks the day somebody improves the wording.
28
+
29
+ What brightness gets from here is structured: the verdict, and `ship_task_id` — denormalised out of the proposal's `source_ref`, which encodes it as `cascade-removal-proposed-on-ship-<id>`, a string nothing can join on (the same complaint `ideas_007` makes about the same field). Brightness designs its own storage for targets when it needs one, which is where the owner put that decision.
30
+
31
+ A ref that cannot be parsed still yields an answerable proposal, with `ship_task_id` NULL. The verdict is the point; refusing to record one because a convenience column could not be filled would be the tail wagging the dog.
32
+
33
+ ### The proposals get their own slice on the attention card, not a row in the nod queue
34
+
35
+ Spec decision 15 says "the existing awaiting-nod surface". The **surface** is the hall's one Needs-your-attention card; the **queue** is `listRoutedAwaitingNod`, which filters `origin = 'route'` on `ideas_task_lineage` and which [ADR 0299](0299-the-nod-queue-stays-scoped-to-routed-filings.md) decided — on live numbers — stays scoped to routed filings and is honestly named for that population. A removal proposal has no idea lineage at all, so widening that predicate to reach it would both break ADR 0299 and make an ideas-owned table answer a lifecycle question.
36
+
37
+ So: same card, same floor, separate slice (`#attention-removals`, straight after the nod), fed by its own routes.
38
+
39
+ ### The permission is reused; the verb is not
40
+
41
+ `GET /removal-proposals` and `POST /removal-proposals/:id/decide` both gate on the **existing** `task.promote` atom — Metic+, the same floor as the nod, so a caller who can see the queue can act on it by construction rather than by coincidence. No new permission and no new page, as spec decision 15 requires.
42
+
43
+ A new *route* is nonetheless needed, and that is not a contradiction. The nod could reuse `POST /tasks/:id/promote` because promoting is exactly what a nod does; there is no existing route that means "that work is genuinely gone". `/tasks/:id/abandon` would close the question without recording which answer was given — the one thing this feature exists to produce.
44
+
45
+ The path is top-level (`/removal-proposals`, the `/override-requests` precedent) rather than `/tasks/removal-proposals`, because the manifest mounts the `tasks` route file first and its `/tasks/:id` would swallow a literal single segment declared in a later file — the trap `modules/ideas/routes/inbox.js` documents for `/inbox/awaiting-nod`, avoided here by not sharing the prefix.
46
+
47
+ ### Rot is inherited, not rebuilt
48
+
49
+ An unanswered proposal sits at `backlog`, which is in `rot.TASK_ROTTABLE_STATUSES`, so it enters the existing rot feed on the project's clock with no code written for it — spec decision 14, and why that decision had no competing option. Answering it writes `abandoned`, which is terminal and not rottable, so it leaves the feed by the same mechanism. Both halves are pinned against the rot module's own exported vocabulary rather than asserted in a comment.
50
+
51
+ ## Consequences
52
+
53
+ **A confirmed removal still changes nothing else.** No status on the removed work moves, no credit is clawed back, `shipped` stays terminal. The verdict is a fact recorded beside the work, and brightness is the only thing that will read it.
54
+
55
+ **A cascade task created before this shipped is answerable.** The predicate is `source = 'cascade'` plus the removal rule's ref prefix, both read from `cascade.js` rather than re-typed, so any proposal the rule has ever filed qualifies. In practice the set is empty: the rule could not fire in production until task 1004090's final commit.
56
+
57
+ **The rot feed shows these only to the owner.** A cascade-filed task has `created_by = NULL`, and `rottingFor` addresses a null-creator row solely to a caller holding `builder.roster.read` — the core_227 convention, deliberate rather than accidental, since there is no person a system-filed row could honestly be addressed to. The attention slice is not scoped that way: it shows every open proposal to every Metic+.
58
+
59
+ **A verdict cannot be corrected through the API.** Stated plainly because it will be noticed: the recovery for a mis-answered proposal is currently a row deletion by someone with SQL, and the right fix — should it ever be asked for — is an append-only amendment, not an UPDATE on this table.
60
+
61
+ ## Alternatives rejected
62
+
63
+ - **The status alone as the record.** Both answers close the same way, so it records neither.
64
+ - **A `removed` task status, or reusing `merged_into_task_id`.** ADR 0313 rejected the first; the second is CHECK-constrained to `abandoned` rows and describes work cut *before* it landed.
65
+ - **Parsing the affected tasks out of the proposal body at confirm time.** Couples a machine read to prose written for a person, and the owner already placed that storage decision with brightness.
66
+ - **Widening the nod queue to carry removal proposals.** Breaks ADR 0299 and makes an ideas-owned lineage table answer a lifecycle question.
67
+ - **Two routes, `/confirm` and `/dismiss`.** The same act with opposite content; splitting it invites the halves to drift in what they close, record and refuse.
68
+ - **Upserting a second verdict, or treating it as an idempotent 200.** Destroys the record that a person answered differently.
69
+ - **A `LIKE 'prefix%'` match on `source_ref`.** A rule key may contain an underscore, and an underscore is a LIKE wildcard — a silent widening of the read that decides what may be answered.
@@ -409,4 +409,5 @@ This keeps the decision history honest and traceable.
409
409
  | 0316 | [**The ignite floor is a scheduling dial, not the trusted tier** ([task 1004084](https://cloudbongos.com/builders#/task/1004084), goal 1000095 — BONGOS-V2). BV2 decision 3 makes the ignite floor — who may turn a quick idea straight into claimable work — a per-instance setting, and decision 16 adds the descent decay rate beside it, the two to share one home. Both the spec and the seeded task described the mechanism the same way: the floor IS the `METIC_PLUS` constant in `modules/ideas/routing.js`, so this is "a setting, not a refactor". Tracing the code before building refuted that: `METIC_PLUS` is spelled once but READ for four semantically different gates — the two `decideLanding` bug branches (land at `ready` or at `backlog`), `mayProposeCriterion` (who may file a `kind='criterion-proposal'`, a planning-scope write), and the protected-scope wall in `authorizeRoutedLanding` (who may route work into the permission / ship-grade / deploy / migration core). Only the first two are the ignite floor, so making the CONSTANT configurable would mean an instance setting its floor to `xenos` — exactly the "project of one wants every thought claimable" case the owner asked for — ALSO gaining the right to file criterion-proposals and to breach the protected core. The codebase already said so in three places nobody had read into the spec: the constant's own header ("It grants nothing — the server-side rank floor and the goal's scope wall are separate, load-bearing gates"), the protected-scope branch ("the two are layers, not alternatives"), and `tests/filing_abuse_matrix.mjs`, which models the widening as an ATTACK and pins the literal. Decision: a separate dial. `modules/ideas/config.js` + `config/ideas.neutral.json` carry both knobs on the `modules/government/config.js` precedence (env -> instance root `config/ideas.json` -> core root neutral; the ADR 0268 dual-root split matters, since one root reads the host pack out of `node_modules` where `npm ci` erases it). `igniteFloor` defaults to `metic`, resolving to exactly the `METIC_PLUS` set, and is threaded into `decideLanding` as a ready-made `trustedRanks` **Set** by the callers — `routing.js` is TOLD the floor and never reads config, staying pure and DB-free — while `METIC_PLUS` stays a FIXED constant for the other two gates, neither of which takes a floor argument (pinned structurally). `descentDecayRate` defaults to 0.5 and ships with no production caller, because R11 is its intended reader and depends on the unbuilt R08 — the same deliberate slice boundary `modules/government/config.js` documents for itself, and what decision 16 asked for. Everything fails to VANILLA rather than dead: a malformed pack, an unknown rank or an out-of-band rate falls back, and an unrecognised floor yields the DEFAULT set, never an empty one (failing closed would stop every ignition on a typo). Rejected: configuring `METIC_PLUS` as written (a security widening in a config file's clothes); splitting it into four named constants (the other three want the same fixed tier, and naming them invites configuring them); having `routing.js` read the config itself (makes the landing matrix impure and untestable at a different floor). Spec decision 3's "spelled in one place" describes the intent, not the mechanism; the spec was not edited and the task description was amended in flight.](0316-the-ignite-floor-is-not-the-trusted-tier.md) | ideas / permissions |
410
410
  | 0315 | [**A plane with no proxy is refused, not given a no-op ingress** ([task 1004017](https://cloudbongos.com/builders#/task/1004017), goal 1000106 — BONGOS-V2). The piece [ADR 0306](0306-instance-supervision-is-a-seam-with-systemd-as-the-default.md) explicitly deferred: the self-host image ships no proxy, so provisioning step 6's `<slug>.caddy` snippet write and `systemctl reload caddy` cannot work there and a child instance gets no front door. **Two failure shapes, only one visible**: a DOMAINED child already half-refused, because `caddy adapt` fails with no binary and [ADR 0303](0303-provisioning-verifies-the-base-caddyfile-and-never-edits-it.md)'s own catch turns that into a gap — but the message told the operator to add a directive to `/etc/caddy/Caddyfile`, a file the container does not have and that ADR 0303 §1 forbids provisioning from creating; a DOMAINLESS child skipped that preflight entirely (it is gated on `inst.domain`), reached step 6 and died on the `sudo` write, an uncaught throw that bypasses the `{ok:false}` pending-retry path and hard-errors the instance on attempt one — a crash recorded where a refusal was the honest answer. Decision: `ingressPlaneGap(exec)` probes the plane with `caddy version` — one cheap unprivileged read, the same posture as `checkCaddyWiring` — and both standup legs refuse with `Ingress preflight failed: …`, deliberately NOT domain-gated, because the domainless child is the one 0303 could not see. **Only a missing binary proves there is no proxy**: under remote exec `boxExec` is `ssh <host> bash -s`, so an unreachable co-hosting box throws here too, and diagnosing a network blip as 'this plane has no proxy, provision elsewhere' would be a confident wrong answer that burns the intent's retry budget — exit 127 is read as proof, anything else answers 'could not confirm a reverse proxy on this plane' with the real cause leading. The three refusals are ordered **capacity → ingress → wiring**, cheapest and most fundamental first and all before any mutation, which moves 0303's preflight behind the ADR 0285 capacity measurement; both still refuse before anything changes, so only the precedence between two refusals moves. **No ingress seam and no no-op backend**, despite the obvious symmetry with 0306: a `none` implementation whose `writeSite`/`reload` are no-ops lets the standup SUCCEED while leaving the child unreachable — neither half of the task's done-when, and exactly the silently-broken instance it exists to prevent. Does not decide: what a child's front door IS on a container plane (a published port, a bundled proxy, an explicit localhost-only shape) — a future ADR that adds one replaces this refusal rather than extending it. Teardown is left alone on purpose: it already reloads `allowFail`, and refusing there would strand a row instead of cleaning it.](0315-a-plane-with-no-proxy-is-refused-not-given-a-no-op-ingress.md) | provisioning / ingress |
411
411
  | 0317 | [**A plane that cannot give an instance its own account is refused, not given a shared uid** ([task 1004018](https://cloudbongos.com/builders#/task/1004018), goal 1000106 — BONGOS-V2). The last of the three container gaps [ADR 0306](0306-instance-supervision-is-a-seam-with-systemd-as-the-default.md) deferred, and the sibling of [ADR 0315](0315-a-plane-with-no-proxy-is-refused-not-given-a-no-op-ingress.md). [ADR 0281](0281-an-instance-identity-is-its-own-unix-account-and-pg-role.md) makes an instance's identity its own unix account, and the unit's `User=`/`Group=` is what stops one co-tenant reading a sibling's `/proc/<pid>/environ` — where every instance's `EnvironmentFile` carries its GitHub App private key and OAuth client secret (audit B3). `useradd` needs uid 0; the self-host image is `node:22-bookworm-slim` running `USER node` with **no sudo**, so there the account cannot be created at all. **Two failure shapes, neither honest**: today step 1c's `boxExec(ensureInstanceUserCmd(...))` is not `allowFail`, so it throws AFTER every preflight passed, AFTER the status flip to `provisioning`, and — for a standalone — after a repo pull and an `npm ci`, recording a crash with the box half-changed; and tomorrow it goes quiet, because a compose self-host only stops short of step 1c by ADR 0315's coincidence, and 0315 says in its own consequences that a future front door **replaces** that refusal. Decision: `accountPlaneGap(exec, { privileged })` in `provision-repo.js` probes with `${sudo}sh -c 'test "$(id -u)" = 0'` and `provisionInstance` refuses with `Account preflight failed: …` before any mutation. **The probe runs the SAME escalation the mutation will** (`PROVISION_SUDO=1` renders the same `sudo ` prefix `ensureInstanceUserCmd` uses), so a pass is evidence rather than inference. **`sh -c`, not a bare `test`, is load-bearing**: under sudo the outer unprivileged shell would expand `$(id -u)` first and answer about the wrong user, passing on exactly the plane this refuses — and for the same reason there is no pipeline, whose exit status is its last stage's. **Only a shell that ran and answered proves it**: `boxExec` is `ssh <host> bash -s` under remote exec, so exit 1 (`test` said no) and 127 (no sudo binary) are read as proof while ssh's own 255 answers "could not confirm" with the real cause leading — ADR 0315's rule applied to a different question. Ordered **third**, after capacity and ingress and before 0303's wiring check: the first three ask about the PLANE, 0303 asks about this instance's DOMAIN, and 0315's order is extended rather than rearranged. **Rejected: accepting it** — documenting a self-host container as single-tenant with a shared uid is a silent downgrade of the vector 0281 closed, observable nowhere on the running box, and "single-tenant" is not what a container hosting several child projects is; **an identity seam with a container implementation**, because nothing exists to put behind it and a seam whose second backend does nothing is 0315's no-op wearing a seam's clothes; **probing `useradd --help` / `command -v useradd`**, which succeed unprivileged on the very image this refuses; **`${sudo}id -u` compared against `0`**, which decides on captured stdout where every sibling preflight and every test fake treats exit status as the contract; and **refusing inside step 1c**, which keeps the refusal after the status flip. Not covered, deliberately: root-but-no-`useradd` (an Alpine-style plane fails loudly at step 1c as today), and teardown (0315's reason — a refusal there strands a row instead of cleaning it). No `PROVISION_ALLOW_SHARED_UID`: a runner either reaches root on this plane or it does not.](0317-a-plane-that-cannot-give-an-instance-its-own-account-is-refused.md) | provisioning / identity |
412
+ | 0319 | [**A removal verdict is a row beside the question, because both answers close it the same way** ([task 1004095](https://cloudbongos.com/builders#/task/1004095), goal 1000095 — BONGOS-V2). [ADR 0313](0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md) settled that a ship deleting an earlier shipped task’s files files a QUESTION and a person answers it; task 1004090 built the question and nothing could answer it. Building the answer surfaced the property that decides the design: a proposal is a question, not work, so CONFIRMING and DISMISSING both leave nothing to build and both end the task at `abandoned` — meaning a status alone records neither, and brightness could not tell the star it must dim from the one it must not. ADR 0313 had already rejected the obvious alternative (a `removed` status; `shipped` is terminal and much of the ledger leans on it — a removal is a fact recorded BESIDE work, not a new terminal state). Decision: `lifecycle_removal_verdicts` (migration `lifecycle_009`), PRIMARY KEY on `proposal_task_id` so one proposal holds one answer ever — a second decide is REFUSED (409), never upserted and never an idempotent 200, because overwriting destroys the record that a person answered differently; the row is locked `FOR UPDATE` first, so simultaneous Confirm and Dismiss cannot both read “undecided”, and `ALREADY_DECIDED` is checked BEFORE `PROPOSAL_CLOSED` because an answered proposal is also abandoned and the useful message is the one naming the earlier verdict. The verdict and the status change commit in ONE transaction. What this does NOT ship is the target list: the affected tasks and paths stay PROSE in the proposal body (the owner’s 2026-09-20 decision, since [ADR 0242](0242-a-cascade-is-a-declaration-table-on-the-event-that-already-exists.md) forbids widening the runner to fan out), and nothing here parses it — brightness designs that storage. What brightness does get is structured: the verdict plus `ship_task_id`, denormalised out of the `source_ref` that encodes it as a string nothing can join on. Surface: spec decision 15’s “existing awaiting-nod surface” is the CARD, not the QUEUE — [ADR 0299](0299-the-nod-queue-stays-scoped-to-routed-filings.md) keeps that queue scoped to routed filings and a removal proposal has no idea lineage at all, so it gets its own slice on the same card at the same floor. The PERMISSION is reused (`task.promote`, Metic+, read and write both) and the VERB is not: no existing route means “that work is genuinely gone”, and `/tasks/:id/abandon` would close the question without recording which answer was given. Top-level `/removal-proposals` rather than `/tasks/removal-proposals`, because the manifest mounts `tasks` first and its `/tasks/:id` swallows a later file’s literal segment. Rot is INHERITED: `backlog` is rottable and `abandoned` is not, so an unanswered proposal rots and an answered one leaves the feed with no code written for either — pinned against the rot module’s own exported vocabulary. Rejected: the status as the record; parsing the body at confirm time; widening the nod queue; separate `/confirm` and `/dismiss` routes; upserting a second verdict; a `LIKE ‘prefix%’` match (a rule key may contain an underscore, which is a LIKE wildcard).](0319-a-removal-verdict-is-a-row-beside-the-question.md) | ideas / lifecycle |
412
413
  | 0318 | [**Listing a file for task affinity is not claiming to own it** ([task 1004110](https://cloudbongos.com/builders#/task/1004110), goal 1000095 — BONGOS-V2). The case [ADR 0314](0314-module-protection-is-per-path-not-per-module.md) named and left open, closed by neither of the two routes it predicted. `builder-settings` derived `protected` — Archon-only to scope a goal to — on exactly one glob, `src/bongos/routes/me.js`, caught by the blanket `src/bongos/routes/` prefix. **That glob was never an ownership claim:** `MODULE_GLOBS` listed it for task AFFINITY and said in the same comment that the `GET /me` aggregator stays a thin core facade, and `isProtected()` cannot tell the two apart. **Both predicted routes were measured and rejected.** Narrowing the blanket prefix: all eighteen files under `src/bongos/routes/` are protected by that prefix AND NOTHING ELSE, so narrowing unwalls `auth.js`, `builders.js`, `backup.js` and `core-update.js` together — now pinned as a tripwire test rather than left as a caution. Moving `me.js` into `modules/builder-settings/`: the aggregator resolves TEN module ports (`lifecycle`, `reward`, `onboarding`, `government`, `specialities`, `grade`, `box`, `art` ×2, `discord`) and `builder-settings` is one of them, so hosting it inside one module means resolving nine foreign ports from the inside — the `core -> module` edge [ADR 0083](0083-modular-architecture-strangler-build-plan.md) rule 1 forbids. Decision: **ownership follows what the file is** — `me.js` moves to `kernel`, which already owns `src/bongos/routes/security.js`. This is 0314 one step on: owning the command is not owning the authority, and **being listed next to a module is not owning it either**. **Rejected: a general affinity tier** in `MODULE_GLOBS` mirroring `isCommandPath` — the audit does not support it. Three other modules (`kernel`, `devsecops`, `methodology`) are also protected only by paths outside their own directory, but in each the foreign path genuinely IS the domain; `builder-settings` was the only module protected by a path its own source called core, so a new tier would be a new place for a hole to hide, built for a population of one. `protectedModules()` goes 9 -> 8. **The wall that matters does not move:** a sub-Metic builder touching `/me` is still refused by `checkPermissionPaths`, asserted directly rather than assumed. The sixteen still-unowned route files remain [task 1004116](https://cloudbongos.com/builders#/task/1004116), whose option (a) this de-risks.](0318-listing-a-file-for-task-affinity-is-not-owning-it.md) | permissions / module scope |
@@ -213,6 +213,10 @@
213
213
  "name": "public",
214
214
  "description": "Endpoints under `/api/bongos/public`."
215
215
  },
216
+ {
217
+ "name": "removal-proposals",
218
+ "description": "Endpoints under `/api/bongos/removal-proposals`."
219
+ },
216
220
  {
217
221
  "name": "scouting",
218
222
  "description": "Endpoints under `/api/bongos/scouting`."
@@ -14126,6 +14130,106 @@
14126
14130
  "security": []
14127
14131
  }
14128
14132
  },
14133
+ "/removal-proposals": {
14134
+ "get": {
14135
+ "operationId": "get_removal_proposals",
14136
+ "tags": [
14137
+ "removal-proposals"
14138
+ ],
14139
+ "summary": "GET /removal-proposals",
14140
+ "description": "GET /removal-proposals — the removal questions nobody has answered yet. rank: metic+archon (task.promote). No client-side rank gate is needed or wanted in the hall: a non-triager's fetch 403s and the slice renders nothing. One gate, on the server, beats a client check that can disagree with it.\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `task.promote` (all required).",
14141
+ "x-rank": "metic+archon",
14142
+ "x-source": "modules/lifecycle/routes/removal-proposals.js",
14143
+ "x-permissions": [
14144
+ "task.promote"
14145
+ ],
14146
+ "responses": {
14147
+ "200": {
14148
+ "description": "Success.",
14149
+ "content": {
14150
+ "application/json": {
14151
+ "schema": {
14152
+ "$ref": "#/components/schemas/GetRemovalProposalsResponse"
14153
+ }
14154
+ }
14155
+ }
14156
+ },
14157
+ "400": {
14158
+ "$ref": "#/components/responses/BadRequest"
14159
+ },
14160
+ "401": {
14161
+ "$ref": "#/components/responses/Unauthorized"
14162
+ },
14163
+ "403": {
14164
+ "$ref": "#/components/responses/Forbidden"
14165
+ }
14166
+ },
14167
+ "security": [
14168
+ {
14169
+ "builderSession": []
14170
+ }
14171
+ ]
14172
+ }
14173
+ },
14174
+ "/removal-proposals/{id}/decide": {
14175
+ "post": {
14176
+ "operationId": "post_removal_proposals_id_decide",
14177
+ "tags": [
14178
+ "removal-proposals"
14179
+ ],
14180
+ "summary": "POST /removal-proposals/:id/decide",
14181
+ "description": "POST /removal-proposals/:id/decide — confirm or dismiss ONE proposal. ONE ROUTE WITH AN ENUM rather than /confirm and /dismiss, because the two answers are the same act with opposite content and splitting them would invite the two halves to drift in what they close, what they record and what they refuse. The enum is validated against an allow-list in the domain layer and by the CHECK in lifecycle_009 — neither admits a value the other does not. rank: metic+archon (task.promote), the same atom as the read above.\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `task.promote` (all required).",
14182
+ "x-rank": "metic+archon",
14183
+ "x-source": "modules/lifecycle/routes/removal-proposals.js",
14184
+ "x-permissions": [
14185
+ "task.promote"
14186
+ ],
14187
+ "parameters": [
14188
+ {
14189
+ "name": "id",
14190
+ "in": "path",
14191
+ "required": true,
14192
+ "schema": {
14193
+ "type": "string"
14194
+ },
14195
+ "description": "Path parameter `id`."
14196
+ }
14197
+ ],
14198
+ "requestBody": {
14199
+ "required": true,
14200
+ "content": {
14201
+ "application/json": {
14202
+ "schema": {
14203
+ "$ref": "#/components/schemas/PostRemovalProposalsIdDecideRequest"
14204
+ }
14205
+ }
14206
+ },
14207
+ "x-validated": true
14208
+ },
14209
+ "responses": {
14210
+ "200": {
14211
+ "description": "Success."
14212
+ },
14213
+ "400": {
14214
+ "$ref": "#/components/responses/ValidationFailed"
14215
+ },
14216
+ "401": {
14217
+ "$ref": "#/components/responses/Unauthorized"
14218
+ },
14219
+ "403": {
14220
+ "$ref": "#/components/responses/Forbidden"
14221
+ },
14222
+ "404": {
14223
+ "$ref": "#/components/responses/NotFound"
14224
+ }
14225
+ },
14226
+ "security": [
14227
+ {
14228
+ "builderSession": []
14229
+ }
14230
+ ]
14231
+ }
14232
+ },
14129
14233
  "/scouting": {
14130
14234
  "get": {
14131
14235
  "operationId": "get_scouting",
@@ -20092,6 +20196,17 @@
20092
20196
  "page"
20093
20197
  ]
20094
20198
  },
20199
+ "GetRemovalProposalsResponse": {
20200
+ "type": "object",
20201
+ "properties": {
20202
+ "pending": {},
20203
+ "count": {}
20204
+ },
20205
+ "required": [
20206
+ "pending",
20207
+ "count"
20208
+ ]
20209
+ },
20095
20210
  "GetScoutingHandleResponse": {
20096
20211
  "type": "object",
20097
20212
  "properties": {
@@ -23988,6 +24103,22 @@
23988
24103
  ],
23989
24104
  "additionalProperties": false
23990
24105
  },
24106
+ "PostRemovalProposalsIdDecideRequest": {
24107
+ "type": "object",
24108
+ "properties": {
24109
+ "verdict": {
24110
+ "type": "string"
24111
+ },
24112
+ "note": {
24113
+ "type": "string",
24114
+ "maxLength": 2000
24115
+ }
24116
+ },
24117
+ "required": [
24118
+ "verdict"
24119
+ ],
24120
+ "additionalProperties": false
24121
+ },
23991
24122
  "PostSearchMarkRequest": {
23992
24123
  "type": "object",
23993
24124
  "properties": {
@@ -25421,9 +25552,9 @@
25421
25552
  "description": "A required dependency/feature is not configured or is temporarily down."
25422
25553
  }
25423
25554
  },
25424
- "x-endpoint-count": 401,
25425
- "x-schema-count": 440,
25555
+ "x-endpoint-count": 403,
25556
+ "x-schema-count": 442,
25426
25557
  "x-undocumented-bodies": 9,
25427
- "x-response-schemas": 300,
25558
+ "x-response-schemas": 301,
25428
25559
  "x-generated-by": "scripts/gds/gen-api-docs.js"
25429
25560
  }
@@ -2,7 +2,7 @@
2
2
 
3
3
  # Bongos API reference
4
4
 
5
- > **Generated from the live route files** — the route file is authoritative. 401 endpoints across 64 route files.
5
+ > **Generated from the live route files** — the route file is authoritative. 403 endpoints across 65 route files.
6
6
  > Machine-readable spec: [`docs/api/openapi.json`](api/openapi.json) (OpenAPI 3.1). Rendered docs site: **`/docs`** (e.g. `cloudbongos.com/docs`).
7
7
 
8
8
  Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/0016-trust-boundary-server-enforced-permissions.md)): `public` < `any-builder` < `metic+archon` < `archon`.
@@ -558,6 +558,13 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/0016-trust
558
558
  | GET | `/api/bongos/public/uptime` | `public` | — | Uptime: current status + 90-day history bucketed by hour. |
559
559
  | GET | `/api/bongos/public/versions` | `public` | — | read-only surface for the status dashboard (status.<apex>). |
560
560
 
561
+ ## `removal-proposals` (2)
562
+
563
+ | Method | Path | Rank | Body | Description |
564
+ |---|---|---|---|---|
565
+ | GET | `/api/bongos/removal-proposals` | `metic+archon` | — | GET /removal-proposals — the removal questions nobody has answered yet. |
566
+ | POST | `/api/bongos/removal-proposals/:id/decide` | `metic+archon` | `verdict`, `note` | POST /removal-proposals/:id/decide — confirm or dismiss ONE proposal. |
567
+
561
568
  ## `scouting` (2)
562
569
 
563
570
  | Method | Path | Rank | Body | Description |