@bongos/core 1.19.897 → 1.19.899

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.897",
-  "core_contract": "1.19.897",
-  "source_commit": "bee6c40d5b1e4600a59cace9b3068cfb1626de0d",
+  "core_version": "1.19.899",
+  "core_contract": "1.19.899",
+  "source_commit": "18e19a9f8472cc87ac263b0266d11f1d87e352d4",
   "source_ref": "HEAD",
-  "built_at": "2026-09-20T02:58:37.233Z",
+  "built_at": "2026-09-20T04:05:43.927Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 500,
+    "docs_redacted": 502,
     "agent_docs_stubbed": 26,
     "functional_verbatim": 2277,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2803,
-  "tree_sha256": "649ca49d792d2d5a87fa5ae51bad0373270f0551dc7d8f82929bfa9112592e21",
+  "file_count": 2805,
+  "tree_sha256": "02493e71ddfd64f20d5be962a0a967ab57c24e1cac948681b566a8a7d87dcc75",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -2049,10 +2049,20 @@
       "mode": "0000644",
       "sha256": "6046995188cef5e8652787eca38ccc6a69393f0985891764d6573f3379bbe6ab"
     },
+    {
+      "path": "docs/adr/0312-provenance-is-a-second-ideas-owned-edge-table.md",
+      "mode": "0000644",
+      "sha256": "be07bd84a0167bbadfd3569286a5a69da403336739a88fccb5a5b6231e225af6"
+    },
+    {
+      "path": "docs/adr/0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md",
+      "mode": "0000644",
+      "sha256": "9b301cd17f96c3f0b49010f046b994e112a5e1f971797964b836bc578578dd70"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "16fdd3b239a9a161d70e3432c35705590d0103f798f2e5f00db53cffcbf5cb81"
+      "sha256": "85bb537649c78b08e36e2de94dfde8449760ca163577a7fac63603da4074dd37"
     },
     {
       "path": "docs/api-reference.md",
@@ -2622,7 +2632,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "a14d4e32aa8cd8793cdc535db0aa0047d7381de2e95cd6dd629c15b3ba0089b5"
+      "sha256": "7c5f4afd7ed31a886824fdce76aea1f7a5e4ff5e0d05ac40358a18fbceb6ac58"
     },
     {
       "path": "docs/modules-contract.md",
@@ -7732,12 +7742,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "ea53354ce229c7ec74a1909c0d0153363ee9f18969b0916c6dc832e36d2e9e8f"
+      "sha256": "640f2bc9b3f15ca82640c73a681425eb06518b9fceb1d649486c55ad3cf73469"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "6cec6fa876274d23ee1da877b77841482b5b2558ddebac5adad801535deffa0d"
+      "sha256": "d04cbdbb7e6b3f4788c1b161337a4aa7935811a50100c6779e80b177f7ce7505"
     },
     {
       "path": "public-docs/index.html",
@@ -9747,7 +9757,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "dc291210b4d1b471b7e946fc451381204d9eece987e0d0df49f364e41a240594"
+      "sha256": "452208ca788059958d16240ae3c879df1ce3ecb1db4a7084c19aeba9a453aa84"
     },
     {
       "path": "src/module-loader/catalog.js",

package/docs/adr/0312-provenance-is-a-second-ideas-owned-edge-table.md

@@ -0,0 +1,78 @@
+# ADR 0312 — Provenance is a second ideas-owned edge table, written by the seams that already know
+
+**Status:** accepted · **Date:** 2026-09-19 · **Task:** [task 1004080](https://cloudbongos.com/builders#/task/1004080) (goal 1000095 — BONGOS-V2)
+
+**Related:** [ADR 0311](0311-an-idea-is-a-permanent-origin-tag.md) (the origin tag this records the descent of) · [ADR 0236](0236-many-ideas-one-task-the-lineage-key-is-the-pair.md) (made co-source ideas real, which is why the edge cannot live on the lineage row) · [ADR 0083](0083-modular-architecture-strangler-build-plan.md) §Decision 5 (a module migration may only touch its own namespace) · [ADR 0054](0054-session-token-reward-cost-plus.md) (the credit the payout rides on) · [ADR 0015](0015-task-dependencies-and-auto-promotion.md)
+
+## Context
+
+A descent — `idea → task → rewrite → split → removal` — is four levels deep and crosses a version boundary. The obvious place to put it is the task hierarchy, and that place is closed.
+
+`modules/lifecycle/hierarchy.js` `attachParent` enforces four invariants, verified by reading the code rather than the comment:
+
+| Invariant | Error code |
+|---|---|
+| `target !== parent` | `SELF_PARENT` |
+| `target.version_id === parent.version_id` | `VERSION_MISMATCH` |
+| `parent.parent_task_id IS NULL` (depth cap, side 1) | `PARENT_HAS_PARENT` |
+| target has no children (depth cap, side 2) | `TARGET_HAS_CHILDREN` |
+
+All four are deliberate; ship rollup and claim safety lean on them, and spec decision 8 puts widening them out of scope. So provenance needs its own relation.
+
+**The spike was told to confirm `ideas_task_lineage` rather than assume it. Confirmed for one half, and refuted for the other.**
+
+## Decision
+
+**Two tables, not one.** `ideas_task_lineage` stays exactly as it is and anchors depth 0. A new ideas-owned table records task→task edges.
+
+### Why the edge cannot go on `ideas_task_lineage`
+
+The table is bipartite (ideas × tasks) with `PRIMARY KEY (task_id, idea_id)` since `ideas_006`. It carries none of the hierarchy's invariants — no depth cap, no version predicate, no self-reference hazard — so as the **idea→task anchor** it is right, and that half of the assumption holds.
+
+But a derivation is a property of the **task pair**, not of the (task, idea) pair. Adding `derived_from_task_id` to the lineage row would write the same derivation once per co-source idea, and `ideas_006` made co-source ideas both legal and expected (merging duplicate reports into one task is the triage move the inbox is built to encourage). Two rows for one task could then disagree about where that task came from, with nothing to arbitrate. That is not a hypothetical: `ideas_006` exists precisely because an under-keyed row silently lost attribution on prod, and it took months to notice.
+
+A merge also gives a task **several** parents, so the relation is a DAG, not a tree — a single nullable column could not express it regardless.
+
+### The edge table
+
+`ideas_task_descent`, in the `ideas_` namespace (ADR 0083 §5 — `tasks` belongs to the protected `lifecycle` module and may not be altered from here; a FK to it is a read, the `ideas_002` precedent).
+
+- `task_id` → the derived task, `parent_task_id` → what it came from, both FK to `tasks`.
+- `relation` — a CHECK'd vocabulary: `rewrite`, `split`, `merge`, `fold`, `cascade`. Extended the `ideas_003` way (drop and re-add the same-named constraint, which `isConstraintWidening` exempts), with that migration's safety net proving the widening took.
+- `PRIMARY KEY (task_id, parent_task_id)` — a task may have several parents; one pair is recorded once.
+- Indexed both directions: descent walks down from a parent, payout walks up from a ship.
+
+**No depth cap and no version predicate** — that is the entire point, and it is what the hierarchy could not give.
+
+**Cycles must be refused at write time.** The payout walks this graph, so a cycle is a non-terminating walk, not a cosmetic error. A self-edge is refused by CHECK; a longer cycle is refused by the writer, which walks to the root before inserting. The walk is also depth-bounded when read, so a cycle that somehow lands cannot hang a page.
+
+### Who writes the edge
+
+The task set the real question: parentage today is a manual act, so an edge that depends on someone remembering will have holes. It does not have to. **Three seams already know a task was derived, and none of them is currently telling anyone:**
+
+| Seam | What it already records | What it becomes |
+|---|---|---|
+| `modules/lifecycle/cascade.js` | `source_ref: cascade-<key>-<id>` — the originating task id, **encoded in a string** | `relation='cascade'`, written at creation |
+| `tasks.merged_into_task_id` | supersede/fold provenance, CHECK'd to `abandoned` rows (`core_232`) | `relation='fold'` — the mockup's "satellite" |
+| `tasks.parent_task_id` | the one-level split | `relation='split'` |
+
+The cascade case is the telling one. The derivation is *already there* and already correct — it is simply stored as text inside `source_ref`, where nothing can join on it. Promoting it to an edge is not new bookkeeping, it is writing down a fact the system already computes.
+
+That leaves `rewrite` and cross-version `merge` as genuinely manual, which is honest: those are editorial acts with no automatic signal behind them. They get an explicit write, and their absence degrades the picture rather than corrupting it.
+
+## Consequences
+
+**What this fixes.** `sourceIdeaForTask` (`inbox.js:870`) and `awardIdeaTaskShipCredit` (`credits.js:540`) both read `ideas_task_lineage` with `ORDER BY created_at, idea_id LIMIT 1` — a **direct, one-hop point read**. A derived task has no lineage row of its own, so today it resolves to `no_source_idea` and the origin idea is not paid at all. The descent walk is what closes that, and spec decision 6's depth decay is what keeps it from paying unboundedly.
+
+**Two relations over the same pair of tasks now exist** — `parent_task_id` (work decomposition, capped, same-version) and this one (provenance, unbounded, cross-version). They are not redundant and must not be merged: the first answers "what is this work part of", the second "where did this work come from". The split edge is written to both, which is the only overlap.
+
+**The display is wider than the count.** Per spec decision 7 the descent *shows* more than size *counts* — a separate thought citing an origin appears in the picture and pays nothing. The edge table carries both; the payout walk filters. Conflating them would let early filers farm the project.
+
+**A backfill is possible and partial.** Every existing cascade task can be recovered by parsing `source_ref`, and every `merged_into_task_id` is already an edge. Historical rewrites are unrecoverable, which is consistent with spec decision 17: pre-existing ideas get lineage backfilled but not payouts, and the number must be marked as historical rather than quietly presented as a sum of payouts made.
+
+## Alternatives rejected
+
+- **Widen the task hierarchy.** Out of scope by spec decision 8, and the invariants are load-bearing for ship rollup and claim safety.
+- **`derived_from_task_id` on `ideas_task_lineage`.** Duplicates the derivation per co-source idea and cannot express a merge. The reason it looks attractive — "extend, don't add" — is real, and the extension is of the lineage *ledger*, which is now two tables.
+- **A column on `tasks`.** Forbidden from a module migration (ADR 0083 §5); `tasks` is the protected `lifecycle` module.
+- **Derive the descent at read time from `source_ref` strings.** It covers only the cascade case, cannot express rewrite or merge, and makes a string format load-bearing for money.

package/docs/adr/0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md

@@ -0,0 +1,69 @@
+# ADR 0313 — A removal is derived from the server's own merge diff and confirmed by a person
+
+**Status:** accepted · **Date:** 2026-09-19 · **Task:** [task 1004081](https://cloudbongos.com/builders#/task/1004081) (goal 1000095 — BONGOS-V2)
+
+**Related:** [ADR 0311](0311-an-idea-is-a-permanent-origin-tag.md) (deferred exactly this) · [ADR 0312](0312-provenance-is-a-second-ideas-owned-edge-table.md) (the descent this dims) · [ADR 0242](0242-a-cascade-is-a-declaration-table-on-the-event-that-already-exists.md) (the runner a rule is appended to) · [ADR 0055](0055-server-mediated-branch-publish.md) (why the server holds the authoritative diff) · [ADR 0049](0049-split-parallel-safety-contract.md) (`touches[]` is advisory)
+
+## Context
+
+Brightness is the live share of a descent (spec decision 20), so something has to be able to say that shipped work was later removed. **Nothing records that today.** `shipped` is terminal — `modules/lifecycle/rot.js` says so in as many words — there is no reverted status, and `tasks.merged_into_task_id` is CHECK-constrained to `abandoned` rows (`core_232`), so it can only ever describe work cut *before* it landed.
+
+The owner settled the shape and not the detail (spec decision 13): **the system proposes, a person confirms.** A derived-only signal dims the sky for refactors, renames and file moves; a declared-only one rots because nobody remembers. This ADR settles the detail.
+
+## What the spike found
+
+**1. `cascade.js` no longer ships with an empty rule set.** The task description says it does; that was true when the task was written and is not true now. `CASCADES` carries a production rule (`artist-review-on-ship`), and ADR 0242 fixed the extension contract: *append an entry, never touch the runner.* This strengthens the decision rather than weakening it — there is a working precedent to copy, including the anti-recursion guard (`source !== CASCADE_SOURCE`) that a removal rule needs for the same reason.
+
+**2. `netNegativeBonusAmount` cannot be the trigger.** The task names it as the nearest existing signal, and it is — in spirit. Structurally it is unusable:
+
+- **It has no target.** `removed > added` over a whole ship says *that* deletion happened, never *what* was deleted or whose work it was. Brightness needs the target; the boolean carries none.
+- **It is client-supplied.** It reads `signals.diff_stats`, which arrives in the grade request body. `grader-score.js` documents the exact forgery it already defends against — a `diff_stats` claiming a net-negative that the submitted diff does not support.
+- **Brightness affects money.** Size is a payout sum and brightness sits beside it. Deriving either from a forgeable, target-less counter would be wrong even if it were convenient.
+
+**3. There is no durable record of what any ship touched.** `committed_files` exists at grade time for the protected-path check and `diff_stats` for the bonus, both client-supplied, and **neither is persisted** — no table stores them. `touches[]` is advisory by ADR 0049. So a removal cannot be reconstructed from history at all; it can only be derived at the moment a ship lands.
+
+## Decision
+
+### The signal's source is the server's own merge diff
+
+Landing is server-mediated (ADR 0055): the server holds the repository and performs the merge, so it can compute the real diff rather than be told about one. The removal signal is derived **there**, from the merge the server just made, and never from a client-supplied signal. This is the only reason the derivation can be trusted with something that moves credits.
+
+### Attribution runs through `claims.published_head_sha`, not commit text
+
+To say *whose* work was deleted, the deleted hunks are blamed back to the commit that introduced them, and that commit is resolved to a task through **`claims.published_head_sha`** (`migrations/171`) — the server-pushed tip, already persisted per claim.
+
+The obvious alternative, parsing `(task NNNN)` out of commit messages, was rejected: of the last 15 commits on `main`, **7** carry a task id. Merge commits and release carriers do not, and a convention that holds most of the time is not a basis for a payout. The sha mapping is written by the server at publish time and cannot be forgotten by an author.
+
+`published_head_sha` is nullable, so attribution can come back empty — a ship that predates `migrations/171`, or one that rode in on another branch. **An unattributable deletion files no proposal.** Silence is the correct output: a wrong removal proposal costs a person's attention and dims a real star.
+
+### What counts as removed
+
+Only **work that shipped and was later deleted**. Three exclusions, each of which the Sky artboard already draws:
+
+- A **rename or move is not a removal.** Git's own rename detection resolves it; the work still stands.
+- A **rewrite in place is not a removal.** Lines changing is how code lives.
+- A **cold body is not a remnant.** An idea declined at triage never ignited — nothing was built, so nothing was lost. Removal applies only below a task that actually shipped.
+
+### The proposal, the confirmation, and the clock
+
+- **Propose:** a new entry appended to `CASCADES` on the ship trigger. It files a *question*, never a verdict, and carries the anti-recursion guard the existing rule uses.
+- **Confirm:** Metic+, `task.promote`, on the existing awaiting-nod surface (spec decision 15). No new permission and no new page.
+- **Rot:** an unanswered proposal enters the existing rot feed on the normal clock (spec decision 14), so the queue cannot silently grow.
+
+Only a **confirmed** proposal dims a star. A pending one changes nothing the ideator sees.
+
+## Consequences
+
+**Brightness can only fall forward from here.** The derivation runs at merge time and nothing durable records the past, so removals before this ships are not recoverable. That is consistent with spec decision 17 — pre-existing ideas get lineage backfilled but not payouts — and it means a historical marker is required on those sizes, or the number quietly lies about what it means.
+
+**The server gains a git-reading step on the merge path.** It is the one place with both the repository and the authority, but it is also the path a stranded ship already fails on. The rule must be non-blocking: a derivation that errors files nothing and never fails the merge. Landing work is more important than dimming a star on time.
+
+**Two signals now exist over the same diff, and they must not be confused.** `netNegativeBonusAmount` rewards a builder for simplifying, and this one records that an origin's descendant work is gone. The same net-negative ship can legitimately trigger the bonus and no removal at all.
+
+## Alternatives rejected
+
+- **Derived-only, no confirmation.** The owner's decision, and correct: refactors, renames and moves would dim the sky continuously.
+- **Declared-only** (a human marks work removed). Rots because nobody remembers — the same reason the descent edges are not left to memory in ADR 0312.
+- **`netNegativeBonusAmount` as the trigger.** Target-less, client-supplied, already known-forgeable.
+- **Commit-message parsing for attribution.** Holds for under half of `main`'s recent commits.
+- **A `removed` task status.** `shipped` is terminal by design and much of the ledger leans on that. A removal is a fact about work's *fate*, recorded beside it, not a new terminal state that ship rollup would have to learn.

package/docs/adr/README.md

@@ -403,3 +403,5 @@ This keeps the decision history honest and traceable.
 | 0309 | [**Module enablement is a database row, above the committed pack and below env** ([task 1002857](https://cloudbongos.com/builders#/task/1002857), goal 1000091). The hall Modules-tab toggle ([ADR 0107](0107-module-upstreaming-contribution-to-core-catalog.md) §9) wrote `config/modules.json` and reloaded the cache, so it looked like it worked — but that file is the committed instance pack and the pull-deploy runs `git reset --hard origin/main`, so the toggle reverted on the next deploy, **silently**. Enablement moves to `module_enablement_overrides` (migration `core_248`), read as one precedence layer: neutral pack → instance pack → **DB override** → env → default. **Above the pack** because the pack is what a deploy restores, so an override below it would be erased by the event it exists to survive; **below env** because `<PREFIX>_MODULE_<KEY>` is the incident knob and must not need a reachable database. **Auto-committing to `main` stays rejected** ([ADR 0016](<redacted>.md)): durability belongs in the DB, not in an HTTP handler that writes to the default branch. Two open design points settled: the **scope key** is the resolved instance pack path (the only axis two instances sharing one database differ on, so one sibling's toggle cannot flip the other's module), and the DB is read into a **snapshot** refreshed at boot and on write rather than inline, because `loadModules()` is synchronous and making it async would ripple into every consumer of a module flag. An unreachable database is a **no-op** — no row means "no opinion", not "off". Does not decide: whether a toggle should also restart the process so remounting is immediate.](0309-durable-module-enablement-db-override.md) | modules / ops |
 | 0310 | [**A speciality OFFERS skills; the adopter turns them on, one at a time, having been shown what each does** ([task 1003978](https://cloudbongos.com/builders#/task/1003978), goal 1000095). Completes [ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md), which defined a speciality as knowledge + skills + an interaction contract and shipped two of the three: `grep -i skill` across the module's schema, domain and routes returns only the header sentences describing a thing that is not there — prose asserting behaviour the code does not have, and the feature's own definition at that. Task 1003978 withheld an implementation until the authority question was answered, and the answer is the strong one: **naming a skill GRANTS NOTHING**. Skills are materialised by `claude-materialize.js` and permission is rank-gated server-side with no caching ([ADR 0016](<redacted>.md)); a speciality offers a menu, and a menu is not an entitlement. **Two layers, because one layer is the blanket the owner ruled against**: the catalog holds what a speciality OFFERS, the already-per-builder `specialities_adoptions` row holds what THIS builder turned on — so two economist ideators share a speciality's knowledge and contract and need not share one enabled skill. **The default is nothing enabled, and that is a position about LEARNING rather than a safe default**: the owner's ruling is that adoption must *walk through what comes with each* because *people need to learn the system*. A settings page of unchecked boxes satisfies the letter and defeats the intent, so the bar is a user test — a person who has finished adopting can say what each skill does. Sharing needs no new mechanism: `owner_kind` / `visibility` / `offered` / `sellable` already ship the private→project→public ladder, and skills ride it. Builds nothing; the three-task order (schema, walkthrough, injection) is filed, and the four documentation sites that claimed a shipped ingredient now say decided-not-built.](0310-a-speciality-offers-skills-and-the-adopter-chooses-them.md) | specialities / methodology |
 | 0311 | [**An idea is a permanent origin tag, and the payout follows its descent** ([task 1004076](https://cloudbongos.com/builders#/task/1004076), goal 1000095 — BONGOS-V2). An idea today is a CONTAINER for work: it leaves `idea_inbox` when it names a goal and lives on as a task, so the better-aimed the thought the faster it vanishes from whoever had it. Reported as a small confusion — a thought filed from the hall routed into a goal, the confirmation line cleared on the next keystroke, and five minutes later the owner could not find it. The idea becomes an **immutable origin tag** instead, the only thing that can answer where a piece of work came from, and **the ideator payout follows its whole descent** rather than stopping at the earliest lineage link (`awardIdeaTaskShipCredit`), decaying by depth — full at the direct task, halving each hop — so an infinite descent is worth at most twice the direct task. That is what gives the tag teeth: if it does not survive a fork, someone does not get paid. **Size and brightness are two channels, not one number**: size is the sum of those payouts and never falls, brightness is how much of that work is still alive, so a thought whose work the project tore out renders LARGE AND DEAD rather than looking like one that never mattered. **Karma was rejected as the basis** — `karma_log` carries no task key and no idea key, deliberately ([`migrations/040_builder_karma.sql`](../../migrations/040_builder_karma.sql)), so "the karma a thought caused" is not computable; credits already are idea-attributed. **The task hierarchy is NOT widened** to carry the descent — it is capped at one level and refuses cross-version parents because ship rollup and claim safety lean on it, and provenance is a different relation from work decomposition. **Nothing records that shipped work was later removed** (`shipped` is terminal, `merged_into_task_id` is CHECK-constrained to abandoned rows), so the first `cascade.js` rule PROPOSES a removal and a person confirms it — derived-only would dim for refactors and renames, declared-only would rot. A ratified **Full Idea becomes a goal or a criterion**, carrying a recommendation the board rules on, because scope is the thing you learn last; the five questions are replaced and VERSIONED so prior filings keep their own. Dropped three tasks this invalidated and amended a fourth whose title asserted the exact exclusivity it reverses. Does not decide: the decay rate beyond its default, what precisely counts as removed, how the edges are physically recorded, or how any of it is drawn.](0311-an-idea-is-a-permanent-origin-tag.md) | ideas / economy |
+| 0312 | [**Provenance is a SECOND ideas-owned edge table, written by the seams that already know** ([task 1004080](https://cloudbongos.com/builders#/task/1004080), goal 1000095 — BONGOS-V2). The spike [ADR 0311](0311-an-idea-is-a-permanent-origin-tag.md) deferred: how the descent edges are physically recorded. A descent (`idea → task → rewrite → split → removal`) is four levels deep and crosses a version boundary, and the task hierarchy refuses both — `attachParent` enforces `SELF_PARENT`, `VERSION_MISMATCH`, `PARENT_HAS_PARENT` and `TARGET_HAS_CHILDREN`, all load-bearing for ship rollup and claim safety. The spike was told to CONFIRM `ideas_task_lineage` rather than assume it, and confirmed one half while refuting the other: the table is right as the **idea→task anchor** (bipartite, no depth cap, no version predicate) but CANNOT carry the task→task edge, because a derivation is a property of the task PAIR and [ADR 0236](0236-many-ideas-one-task-the-lineage-key-is-the-pair.md) made co-source ideas both legal and common — a `derived_from_task_id` column would write the same derivation once per co-source idea and let two rows disagree about where a task came from, the same under-keying that silently lost attribution on prod once already. A merge also gives a task SEVERAL parents, so the relation is a **DAG, not a tree**. Decision: a new `ideas_task_descent` (`task_id`, `parent_task_id`, CHECK'd `relation`, PK on the pair, indexed both ways), with NO depth cap and NO version predicate, and **cycles refused at write time** because the payout walks this graph and a cycle is a non-terminating walk rather than a cosmetic error. On who writes it — the question the task actually set, since an edge depending on memory will have holes — **three seams already know and none is telling anyone**: `cascade.js` encodes the originating task id inside `source_ref` as a STRING nothing can join on, `tasks.merged_into_task_id` already records the fold, and `parent_task_id` already records the split. Only `rewrite` and cross-version `merge` stay manual, which is honest — they are editorial acts with no automatic signal, and their absence degrades the picture rather than corrupting it. What it fixes: `sourceIdeaForTask` and `awardIdeaTaskShipCredit` are both one-hop `LIMIT 1` point reads, so a DERIVED task resolves to `no_source_idea` and the origin is not paid at all. Does not decide: the decay rate beyond its default, what counts as removed ([ADR 0313](0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md)), or how any of it is drawn.](0312-provenance-is-a-second-ideas-owned-edge-table.md) | ideas / lifecycle |
+| 0313 | [**A removal is derived from the SERVER's own merge diff and confirmed by a person** ([task 1004081](https://cloudbongos.com/builders#/task/1004081), goal 1000095 — BONGOS-V2). The other half [ADR 0311](0311-an-idea-is-a-permanent-origin-tag.md) deferred: what counts as removed, so that brightness can fall at all. Nothing records it today — `shipped` is terminal (`rot.js` says so outright) and `merged_into_task_id` is CHECK'd to `abandoned` rows, describing only work cut BEFORE it landed. Owner decision 13 set the shape (system proposes, person confirms); this settles the detail, and corrects two premises the task was written on. **`cascade.js` is no longer empty** — it carries a production rule and [ADR 0242](0242-a-cascade-is-a-declaration-table-on-the-event-that-already-exists.md) fixed the contract (append an entry, never touch the runner), so there is a precedent to copy including its anti-recursion guard. **`netNegativeBonusAmount` cannot be the trigger** despite being the named nearest signal: it is an aggregate with NO TARGET (it says deletion happened, never what or whose), it is CLIENT-SUPPLIED via `signals.diff_stats`, and `grader-score.js` already documents the forgery it defends against — and brightness sits beside a payout, so a forgeable target-less counter cannot carry it. **Nothing durable records what any ship touched**: `committed_files` and `diff_stats` are client-supplied at grade time and never persisted, `touches[]` is advisory ([ADR 0049](0049-split-parallel-safety-contract.md)), so a removal cannot be reconstructed from history — only derived as a ship lands. Decision: derive it from the SERVER's own merge diff ([ADR 0055](0055-server-mediated-branch-publish.md) — the server holds the repo and does the merge, so it computes the diff rather than being told one), and attribute the deleted hunks through **`claims.published_head_sha`** (`migrations/171`), NOT by parsing `(task NNNN)` out of commit text — only 7 of `main`'s last 15 commits carry a task id, and a convention that holds most of the time cannot underwrite a payout. An UNATTRIBUTABLE deletion files nothing: a wrong proposal costs attention and dims a real star. A rename, a move and a rewrite-in-place are NOT removals, and a cold body is not a remnant — removal applies only below a task that actually shipped. The proposal is an appended `CASCADES` entry filing a QUESTION; confirmation is Metic+/`task.promote` on the existing awaiting-nod surface; an unanswered one rots on the normal clock. Only a CONFIRMED proposal dims a star. The derivation must be NON-BLOCKING — landing work matters more than dimming a star on time. Brightness can only fall forward from here, so historical sizes need a marker or the number lies.](0313-a-removal-is-proposed-by-the-ship-and-confirmed-by-a-person.md) | ideas / lifecycle |

package/docs/module-api-changelog.md

@@ -2268,5 +2268,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.895 with no explicit bump. run 35478072367. (task 1002620)
   1.19.897 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.896 with no explicit bump. run 35485346707. (task 1002620)
+  1.19.898 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.897 with no explicit bump. run 35487863230. (task 1002620)
+  1.19.899 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.898 with no explicit bump. run 35488237998. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.897",
+  "version": "1.19.899",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.897'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.899'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');