@bongos/core 1.19.815 → 1.19.817

package/modules/lifecycle/goal-suggest.js

@@ -18,12 +18,25 @@
 // so there is one notion of "these two texts are about the same thing" in the
 // module, not two.
 //
-// WHAT A GOAL IS MATCHED ON: its title and its scope_modules. Deliberately NOT
-// its description — a goal description is where a whole planning spec lives (goal
-// 1000062 carries an entire decision record in its), so it shares tokens with
-// almost any draft and would flatten every score toward the same number. Modules
-// are included because they are a strong, cheap signal: a draft about the hall
-// really does belong with a goal scoped to `hall-ui`.
+// WHAT A GOAL IS MATCHED ON: its title, its scope_modules, and its DONE-WHEN
+// CRITERIA (task 1003859). Criteria were added because title-only ranking went
+// dead the moment the goal board adopted ADR 0264's naming: all eleven open
+// BONGOS-V2 goals are titled 'Working area N — <subject>', so a real subject word
+// in a draft — 'release', 'grader', 'dependency' — had almost nothing to overlap,
+// every goal scored under threshold, and the suggester returned [] for every idea
+// walked at the 2026-09-12 triage. It also left suggested_goal_id NULL at capture
+// time on every BONGOS-V2 filing, so triage inherited nothing either. The criteria
+// carry the subject vocabulary the titles stopped carrying.
+//
+// Criterion terms are weighted BELOW title terms (see CRITERION_WEIGHT): a goal
+// named for the subject is still the stronger claim, and criteria are longer text
+// that would otherwise swamp it.
+//
+// Still deliberately NOT the goal DESCRIPTION — a goal description is where a whole
+// planning spec lives (goal 1000062 carries an entire decision record in its), so
+// it shares tokens with almost any draft and would flatten every score toward the
+// same number. Modules are included because they are a strong, cheap signal: a
+// draft about the hall really does belong with a goal scoped to `hall-ui`.
 
 const { tokenize } = require('./criterion-suggest.js');
 const { versionAcceptsNewWork } = require('./db-tasks.js');
@@ -38,10 +51,47 @@ const captureErr = (err) => api.logger('lifecycle').error({ err: err && err.mess
 // Matches suggestCriteria's default so the two suggesters feel the same.
 const SUGGEST_LIMIT = 5;
 
+// A criterion term counts for less than the same term in the title. Criteria are
+// several sentences per goal against a title's handful of words, so equal weight
+// would let a goal that merely MENTIONS a subject outrank one NAMED for it.
+const CRITERION_WEIGHT = 0.5;
+
+// rankableCriteria — the criterion prose the ranker may read, for the goals it is
+// about to score. Both callers go through this, so the two rules below have ONE
+// home and cannot drift apart.
+//
+// RULE 1 — PRIVATE GOALS ARE EXCLUDED. This function's own header explains that
+// GET /goals (and therefore this suggester) already lists private goals' TITLES to
+// any signed-in builder, and that reconciling that is a decision about the goal
+// board as a whole rather than something a suggester settles. Criteria are a
+// different order of exposure: score + matched_terms make a ranker into a
+// word-guessing oracle, so ranking on a private goal's done-when prose would let
+// any builder probe the CONTENT of work they cannot see, one candidate word per
+// request. So this addition stops at the visibility line the status quo already
+// draws — a private goal keeps ranking exactly as it did before (title + modules),
+// and nothing new is disclosed. Widening or narrowing the title-level status quo
+// stays the separate decision it was.
+//
+// RULE 2 — BEST EFFORT. A criteria read that fails degrades to title-only ranking,
+// which is what this path did before the criteria existed. A suggester is advisory
+// everywhere it is called; taking down a bug report or 500ing a picker to protect
+// a ranking refinement would be the wrong trade.
+async function rankableCriteria(db, goals, onError) {
+  if (typeof db.listCriterionTextForGoals !== 'function') return null;
+  const rankable = (goals || []).filter((g) => g && g.visibility !== 'private');
+  if (rankable.length === 0) return null;
+  try {
+    return await db.listCriterionTextForGoals(rankable.map((g) => g.id));
+  } catch (err) { onError(err); return null; }
+}
+
 // Rank open goals against a DRAFT capture. Pure — no DB, no writes; the caller
 // supplies the goal rows.
 //
 //   goals   — open goal rows { id, title, scope_modules }
+//   opts.criteriaByGoal — Map<goalId, criterion prose> (db.listCriterionTextForGoals).
+//             Optional: omitted, this ranks exactly as it did before — the pure
+//             function stays callable with no DB anywhere near it.
 //   draft   — { title, body } (body optional: a capture's prose, weighted lower)
 //   opts    — { versionId, limit, includeZero }
 //
@@ -54,7 +104,7 @@ const SUGGEST_LIMIT = 5;
 // offer "browse all" without this function pretending to a confidence it lacks.
 function suggestGoals(goals, draft = {}, opts = {}) {
   const { title = '', body = '' } = draft;
-  const { versionId = null, limit = SUGGEST_LIMIT, includeZero = false } = opts;
+  const { versionId = null, limit = SUGGEST_LIMIT, includeZero = false, criteriaByGoal = null } = opts;
 
   // Weighted term map: body terms at 1, title terms override to 2 (a term in
   // both IS a title term — the stronger signal wins). suggestCriteria's rule.
@@ -73,10 +123,20 @@ function suggestGoals(goals, draft = {}, opts = {}) {
       // by the >=3-char filter, which is fine — 'hall' is the signal.
       ...tokenize((g.scope_modules || []).join(' ')),
     ]);
+    // Criterion terms that the title/modules already cover add nothing — they are
+    // scored at the full title weight above, and double-counting would reward a
+    // goal for repeating itself.
+    const criterionTerms = new Set();
+    if (criteriaByGoal) {
+      for (const t of tokenize(criteriaByGoal.get(String(g.id)) || '')) {
+        if (!goalTerms.has(t)) criterionTerms.add(t);
+      }
+    }
     let score = 0;
     const matched = [];
     for (const [term, w] of weights) {
       if (goalTerms.has(term)) { score += w; matched.push(term); }
+      else if (criterionTerms.has(term)) { score += w * CRITERION_WEIGHT; matched.push(term); }
     }
     return { ...g, score, matched_terms: matched.sort() };
   }).sort((a, b) => (b.score - a.score) || (Number(a.id) - Number(b.id)));
@@ -133,11 +193,16 @@ async function suggestGoalForCapture({ title = '', body = '' } = {}, deps = {})
       && g.title !== generalGoalTitle(g.version_id));
     if (homes.length === 0) return null;
 
+    // Criterion prose for the same goals — this is the capture-time half of task
+    // 1003859, and it is the half that matters most: suggested_goal_id is written
+    // HERE, and it was NULL on every BONGOS-V2 filing.
+    const criteriaByGoal = await rankableCriteria(db, homes, captureErr);
+
     // versionId is passed null: the catch-alls are already gone, and passing one
     // version's id here would only re-filter for that version. includeZero stays
     // false, so a filing that matches nothing gets NO goal rather than the
     // first one dressed up as a suggestion.
-    const [best] = suggestGoals(homes, { title, body }, { versionId: null, limit: 1 });
+    const [best] = suggestGoals(homes, { title, body }, { versionId: null, limit: 1, criteriaByGoal });
     if (!best) return null;
 
     // suggestGoals normalises to { id, title, scope_modules, … } and drops
@@ -184,7 +249,8 @@ function goalSuggestHandler({ db, LIMITS }) {
     // was an oversight, not a decision.
     try {
       const open = await db.listGoals({ versionId, status: 'open' });
-      const suggestions = suggestGoals(open, { title, body }, { versionId, limit });
+      const criteriaByGoal = await rankableCriteria(db, open || [], proseErr);
+      const suggestions = suggestGoals(open, { title, body }, { versionId, limit, criteriaByGoal });
       return res.json({
         version_id: versionId,
         // `kind` is echoed, NOT ranked on. Kind decides how a capture LANDS (the

package/modules/lifecycle/routes/task-route-helpers.js

@@ -45,8 +45,50 @@ const VALID_FITS = new Set(['autonomous', 'parallel']);
 // whole-token, case-insensitive. The former scripts/gds/capture.js mirror was
 // deleted with the same task: captured ideas have no touches[] and the server
 // re-detects on create, so the CLI copy earned its keep no longer.
+// task 1003910: "schema" is QUALIFIED, not bare.
+//
+// WHAT ACTUALLY WENT WRONG. The bug was filed as "the non-DB compound strip does
+// not cover --json-schema". It does (the `json` arm below has always been there),
+// and the live false positive it cites — task 1003902, flagged though it alters no
+// table — was not triggered by the flag at all. It was triggered by a LATER,
+// unqualified back-reference in the same paragraph: "`result` is EMPTY when a
+// schema is in play". A bare noun, with no compound around it for any strip to
+// catch.
+//
+// WHY THE SHAPE CHANGED RATHER THAN THE LIST. A blocklist of non-database
+// compounds cannot be finished: every new way of saying "schema" about something
+// that is not a table is another false positive, and each one costs a reserved
+// migration number (task 1002614 burned 213), floors the task at Metic (ADR 0270)
+// and halts an unattended chain. Enumerating `json-schema`, `schema.org` and
+// `--output-schema` would have bought three phrasings and left the one in the bug
+// report still flagging. So "schema" now has to be ATTACHED to a database noun or
+// to a change verb to count — an allowlist, which fails the safe way: an
+// unrecognised phrasing no longer flags, instead of flagging on sight.
+//
+// The other three keywords are untouched: `migration(s)`, `alter table` and
+// `create table` are already unambiguous, and they are what catches genuine
+// schema work whose prose never says the word "schema".
+//
+// A missed detection stays correctable by PATCH, exactly as a false one was.
+const DB_SCHEMA_RE = [
+  // a database noun in front: "DB schema", "table-schema", "column schema"
+  /\b(?:db|database|table|column|postgres|pg|sql|index)[-\s]+schemas?\b/.source,
+  // a change noun behind: "schema change", "schema migration", "schema bump"
+  /\bschemas?[-\s]+(?:migrations?|changes?|bumps?|updates?|diffs?|drift)\b/.source,
+  // a change verb in front: "change the schema", "alter the table schema"
+  // The noun slot before "schema" excludes the API/transport nouns the old
+  // blocklist covered: a change verb is not evidence on its own, and "update the
+  // response schema" is the task 1002648 false-positive class wearing a verb.
+  // Anything else ("the task schema", "the tasks schema") still counts.
+  // The noun slot before "schema" excludes the API/transport nouns the old
+  // blocklist covered: a change verb is not evidence on its own, and "update the
+  // response schema" is the task 1002648 false-positive class wearing a verb.
+  // Anything else ("the task schema", "the tasks schema") still counts.
+  /\b(?:change|changing|alter|altering|update|updating|modify|modifying|extend|extending)\s+(?:the\s+)?(?:(?!(?:request|response|body|validation|patch|post|put|delete|json|openapi|api|error|output|input|result|payload|event)\b)\w+\s+)?schemas?\b/.source,
+].join('|');
+
 const MIGRATION_KEYWORD_RE =
-  /\bmigrations?\b|\bschema\b|\balter\s+table\b|\bcreate\s+table\b/i;
+  new RegExp([/\bmigrations?\b/.source, DB_SCHEMA_RE, /\balter\s+table\b/.source, /\bcreate\s+table\b/.source].join('|'), 'i');
 
 // task 1002648 (idea 1000642): compounds where the keyword is qualified by a
 // NON-database noun are refactor/API language, not schema work, and are blanked
@@ -59,8 +101,13 @@ const NON_DB_COMPOUND_RE = new RegExp(
   [
     /\b(?:gate|route|code)s?[-\s]+migrations?\b/.source,
     /\bmigrations?\s+of\s+(?:gate|route|code)s?\b/.source,
-    /\b(?:request|response|body|validation|patch|post|put|delete|json|openapi|api|error)[-\s]+schemas?\b/.source,
-    /:\d+[-\s]+schemas?\b/.source,
+    // The API-schema arms this list used to carry (`request schema`, `:751
+    // schema`, `json schema`) are GONE, not lost: they existed only to subtract
+    // from a bare-"schema" rule that no longer exists. "the PATCH schema declares
+    // 11 keys" has no database noun and no change verb, so it never reaches a
+    // strip — and neither does the phrasing they missed. Keeping them would leave
+    // two mechanisms answering the same question, which is how the list grew a
+    // gap in the first place.
   ].join('|'),
   'gi'
 );

package/modules/specialities/db.js

@@ -17,7 +17,8 @@ const exec = (executor) => executor || ((text, params) => pool.query(text, param
 
 const COLUMNS = `id, slug, name, discipline, summary, contract_md,
                  owner_kind, owner_builder_id, owner_project_id,
-                 visibility, sellable, created_by, created_at, updated_at`;
+                 visibility, sellable, offered, offered_by, offered_at,
+                 created_by, created_at, updated_at`;
 
 async function createSpeciality(row, executor) {
   const q = exec(executor);
@@ -225,8 +226,46 @@ async function taskDiscipline(taskId, executor) {
   return (r.rows[0] && r.rows[0].discipline) || null;
 }
 
+// Flip the recommendation. `offered_by` and `offered_at` are written together
+// with it so a suggestion always carries whose judgement it is — a builder
+// deciding whether to accept a standing instruction can see who stood behind it.
+// Clearing an offer clears the witness too rather than leaving a stale name on a
+// recommendation nobody is making any more.
+async function setOffered(id, { offered, builderId }, executor) {
+  const q = exec(executor);
+  const r = await q(
+    `UPDATE specialities_catalog
+        SET offered = $2,
+            offered_by = CASE WHEN $2 THEN $3::bigint ELSE NULL END,
+            offered_at = CASE WHEN $2 THEN now() ELSE NULL END,
+            updated_at = now()
+      WHERE id = $1
+      RETURNING ${COLUMNS}, offered, offered_by, offered_at`,
+    [id, !!offered, builderId || null],
+  );
+  return r.rows[0] || null;
+}
+
+// Everything on offer that this viewer could see at all. The RULE that decides
+// what is actually suggested is specialities.offeredTo — this is the cheap
+// prefilter, exactly as listVisibleTo is for the catalogue.
+async function listOffered({ builderId, projectIds = [], discipline = null }, executor) {
+  const q = exec(executor);
+  const params = [builderId, projectIds.length ? projectIds : [null]];
+  let sql = `SELECT ${COLUMNS}, offered, offered_by, offered_at
+               FROM specialities_catalog
+              WHERE offered
+                AND (visibility = 'public'
+                     OR (owner_kind = 'builder' AND owner_builder_id = $1)
+                     OR (owner_kind = 'project' AND visibility = 'project' AND owner_project_id = ANY($2)))`;
+  if (discipline) { params.push(discipline); sql += ` AND discipline = $${params.length}`; }
+  sql += ' ORDER BY discipline ASC, name ASC';
+  const r = await q(sql, params);
+  return r.rows;
+}
+
 module.exports = {
-  UPDATABLE, taskDiscipline,
+  UPDATABLE, taskDiscipline, setOffered, listOffered,
   createSpeciality, getSpeciality, listVisibleTo, updateSpeciality,
   addDocument, listDocuments, getDocument, deleteDocument,
   linkLearning, countTraining,

package/modules/specialities/migrations/specialities_002_offered.sql

@@ -0,0 +1,57 @@
+-- specialities_002_offered.sql — a project OFFERS a speciality to its builders
+-- (task 1003972; the micro-roles residue of task 1003856, built on ADR 0296).
+--
+-- WHAT THIS IS. Task 1003855 let a builder or a project OWN a speciality and set
+-- who may adopt it. What it could not express is a recommendation: "this is the
+-- set we suggest you start from." That is what `offered` adds, and it is one
+-- column rather than a preset table because a preset IS a speciality — the list
+-- is just the specialities someone chose to put their name behind.
+--
+-- IT OFFERS. IT DOES NOT ADOPT. This is the whole design decision and it is not a
+-- convenience call. A speciality's `contract_md` is injected into every session
+-- where the adopter holds a claim in that craft, and ADR 0296's consent work
+-- (task 1003855's second grade) exists because that text is ANOTHER BUILDER'S
+-- text arriving in this builder's session. Auto-adopting a project's presets on
+-- join would hand every new builder a standing instruction they never read, which
+-- is precisely the failure that grade caught — so an offer is a suggestion a
+-- person accepts, every time, and there is no column here that could make it
+-- otherwise.
+--
+-- WHY NO MEMBERSHIP LOOKUP IS NEEDED FOR THE COMMON CASE. "Project" in the
+-- platform-identity sense is a HUB concept (ADR 0141 §3): a `client_id` in the
+-- hub's cross-project directory, keyed by `github_id`. A normal instance is not a
+-- hub and has no such rows — it simply IS the project. So an instance-level
+-- recommendation is a speciality at `visibility='public'` (already "anyone on
+-- this instance may adopt it") flagged `offered` — no membership resolution, no
+-- optional seam, nothing to be absent. The federated case rides the same column
+-- once the `project.membership` port exists: a project-owned speciality at
+-- `visibility='project'` and `offered` is a suggestion to that project's members.
+
+ALTER TABLE specialities_catalog
+  ADD COLUMN IF NOT EXISTS offered BOOLEAN NOT NULL DEFAULT FALSE;
+
+-- You cannot recommend something nobody may adopt. Same shape as the `sellable`
+-- constraint beside it, and for the same reason: a private-but-offered row is
+-- incoherent rather than merely useless, and the DB is where that is cheapest to
+-- refuse. Named for what it protects.
+ALTER TABLE specialities_catalog
+  DROP CONSTRAINT IF EXISTS specialities_catalog_offered_needs_visibility;
+ALTER TABLE specialities_catalog
+  ADD CONSTRAINT specialities_catalog_offered_needs_visibility
+  CHECK (offered = FALSE OR visibility <> 'private');
+
+-- The suggestions read: "what does this instance/project recommend to me". Partial
+-- because the offered set is by nature small and the unoffered majority is never
+-- scanned by it.
+CREATE INDEX IF NOT EXISTS specialities_catalog_offered_idx
+  ON specialities_catalog (discipline) WHERE offered;
+
+-- WHO OFFERED IT, and when. Recorded because a recommendation carries someone's
+-- name by definition — the settings surface says who suggested it, so a builder
+-- deciding whether to accept a standing instruction can see whose judgement they
+-- are taking. Nullable: a row offered before this column existed has no witness,
+-- and inventing one would be worse than admitting it.
+ALTER TABLE specialities_catalog
+  ADD COLUMN IF NOT EXISTS offered_by BIGINT REFERENCES builders(id) ON DELETE SET NULL;
+ALTER TABLE specialities_catalog
+  ADD COLUMN IF NOT EXISTS offered_at TIMESTAMPTZ;

package/modules/specialities/routes/specialities.js

@@ -246,6 +246,22 @@ module.exports = function buildSpecialitiesRouter() {
     }
   }));
 
+  // GET /specialities/offered — the suggestions for THIS builder. Mounted before
+  // '/specialities/:id' would otherwise capture 'offered' as an id.
+  router.get('/specialities/offered', api.requireBuilder, asyncHandler('GET /specialities/offered', async (req, res) => {
+    const builder = req.builder;
+    const projectIds = await viewerProjectIds(builder);
+    const [rows, adoptions] = await Promise.all([
+      db.listOffered({ builderId: builder.id, projectIds, discipline: req.query.discipline || null }),
+      db.listAdoptions(builder.id),
+    ]);
+    // The SQL is the prefilter; offeredTo is the rule — it drops what this
+    // builder already holds and what would collide with a craft they have already
+    // chosen for. Nothing here adopts anything.
+    const suggestions = S.offeredTo(rows, { builderId: builder.id, projectIds }, adoptions);
+    res.json({ suggestions });
+  }));
+
   router.get('/specialities/:id', api.requireBuilder, asyncHandler('GET /specialities/:id', async (req, res) => {
     const id = parseId(req, res, { code: 'bad_id' });
     if (id === null) return;
@@ -371,6 +387,54 @@ module.exports = function buildSpecialitiesRouter() {
     res.json({ ok: true, was_active: dropped });
   }));
 
+  // ── offering: a project puts its name behind a speciality ─────────────────
+  //
+  // OFFERING IS CURATION, NOT OWNERSHIP, so it is gated differently from every
+  // other write here. Editing your own speciality is yours; recommending one to
+  // everybody on the instance is a claim on their attention and their sessions,
+  // which is the same act `project.curate` already governs for featuring a
+  // project (metic floor). An owner may therefore edit a speciality they cannot
+  // offer, and a curator may offer one they do not own — which is correct: the
+  // two decisions are about different things.
+  router.post('/specialities/:id/offer', api.requireBuilder, api.requirePermission('project.curate'),
+    asyncHandler('POST /specialities/:id/offer', async (req, res) => {
+      const id = parseId(req, res, { code: 'bad_id' });
+      if (id === null) return;
+      const s = await db.getSpeciality(id);
+      // visibleTo, like every sibling route. project.curate says "you may
+      // curate", NOT "you may curate this row" — without this a curator could
+      // offer a project-owned speciality belonging to a project they are not in,
+      // and the 403-vs-404 shape would confirm its existence besides.
+      if (!s || !(await visibleTo(s, req.builder))) return res.fail('not_found', 404);
+      // The DB refuses this too; refusing here as well turns a constraint
+      // violation into a sentence that says what to do about it.
+      if (s.visibility === 'private') {
+        return res.fail('offer_needs_visibility', {
+          status: 400,
+          message: 'A private speciality cannot be offered — nobody it is offered to could adopt it. Share it first.',
+        });
+      }
+      res.json({ speciality: await db.setOffered(id, { offered: true, builderId: req.builder.id }) });
+    }));
+
+  router.post('/specialities/:id/unoffer', api.requireBuilder, api.requirePermission('project.curate'),
+    asyncHandler('POST /specialities/:id/unoffer', async (req, res) => {
+      const id = parseId(req, res, { code: 'bad_id' });
+      if (id === null) return;
+      const s = await db.getSpeciality(id);
+      if (!s || !(await visibleTo(s, req.builder))) return res.fail('not_found', 404);
+      // Withdrawing a recommendation does NOT un-adopt anybody. A builder who
+      // accepted it chose it; taking that away silently would be the auto-adopt
+      // mistake in reverse.
+      //
+      // The actor is passed even though the row stores it only while an offer
+      // stands (setOffered nulls the witness on withdrawal, because a
+      // recommendation nobody is making has nobody behind it). WHO withdrew it is
+      // not lost: every authenticated POST through this router is recorded by
+      // src/bongos/middleware/audit.js with the builder, the body and the status.
+      res.json({ speciality: await db.setOffered(id, { offered: false, builderId: req.builder.id }) });
+    }));
+
   router.get('/me/specialities', api.requireBuilder, asyncHandler('GET /me/specialities', async (req, res) => {
     res.json({ adoptions: await db.listAdoptions(req.builder.id) });
   }));

package/modules/specialities/specialities.js

@@ -195,4 +195,33 @@ function describeForApi(active, { documentCount = 0, learningCount = 0, selfAuth
   return { inject: contract.trim().length > 0, contract, speciality_id: active.id, slug: active.slug };
 }
 
-module.exports = { VISIBILITIES, LIMITS, slugify, validateDraft, canAdopt, describeForApi };
+// WHAT A BUILDER IS OFFERED. The suggestions half of task 1003972: a speciality
+// someone with project.curate has put the project's name behind.
+//
+// IT OFFERS, IT DOES NOT ADOPT — and this function is where that is enforced in
+// the read, not merely intended. It returns suggestions; nothing here adopts, and
+// the caller has no adoption path that does not go through the builder's own
+// explicit POST. A speciality's contract is injected into every session in its
+// craft, so handing someone a standing instruction they never accepted is the
+// exact failure ADR 0296's consent work exists to prevent.
+//
+// Three filters, in the order that makes each one cheap:
+//   1. offered      — somebody recommended it
+//   2. canAdopt     — and this viewer may actually take it (the SAME rule the
+//                     catalogue uses; never a second, looser copy)
+//   3. not already  — a speciality you already hold is not a suggestion, and one
+//                     in a craft you already have an ACTIVE speciality for is a
+//                     conflict rather than an offer (the adoption index allows one
+//                     active per craft), so it is surfaced as neither.
+function offeredTo(specialities, viewer, adoptions = []) {
+  const held = new Set((adoptions || []).map((a) => String(a.id ?? a.speciality_id)));
+  const activeCrafts = new Set((adoptions || []).filter((a) => a.active).map((a) => a.discipline));
+  return (specialities || []).filter((s) => {
+    if (!s || !s.offered) return false;
+    if (!canAdopt(s, viewer)) return false;
+    if (held.has(String(s.id))) return false;
+    return !activeCrafts.has(s.discipline);
+  });
+}
+
+module.exports = { VISIBILITIES, LIMITS, slugify, validateDraft, canAdopt, describeForApi, offeredTo };

package/package-lock.json

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

package/package.json

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

package/scripts/gds/capture.js

@@ -50,8 +50,12 @@
 //                                 the active-claim default below is skipped —
 //                                 an opt-out that still guessed a goal would not
 //                                 be an opt-out.
-//                  (neither)    → default to the ACTIVE CLAIM's goal, if this
-//                                 builder holds one and its task has a goal
+//                  (neither)    → default to the ACTIVE CLAIM's goal — but ONLY
+//                                 when the captured text and the claimed task
+//                                 share a subject word (task 1003859); an
+//                                 unrelated filing says so and stays homeless.
+//                                 Applies if this builder holds a claim and its
+//                                 task has a goal
 //                                 ("capturing mid-work almost always concerns
 //                                 the work" — the interview's own words). With
 //                                 no default to offer, the R07 suggester
@@ -160,6 +164,29 @@ function sanitizeForTerminal(s) {
   return String(s == null ? '' : s).replace(/[\x00-\x1f\x7f]/g, '');
 }
 
+// claimShareSubject — does the captured text have ANYTHING in common with the
+// task I happen to be holding? (task 1003859)
+//
+// WHY THE DEFAULT NEEDED A GUARD. The active-claim default is a convenience for
+// the ordinary case: you are working on X and you file something about X. But it
+// fired unconditionally, so filing an UNRELATED bug mid-session minted it into
+// the claim's goal — this very bug was filed from a session holding a security
+// task and landed in Working area 10 (Security), which has nothing to do with it,
+// and had to be moved by hand. ADR 0234's owner-interview decision is that a
+// guess must not mint work into a goal, and an inherited goal with no subject in
+// common is exactly a guess.
+//
+// Reuses criterion-suggest's tokenize — the same notion of 'these two texts are
+// about the same thing' the goal suggester ranks with, so the guard and the
+// suggester cannot disagree about what a subject word is.
+const { tokenize } = require('../../modules/lifecycle/criterion-suggest.js');
+
+function claimShareSubject(capturedText, claimTitle) {
+  const theirs = new Set(tokenize(claimTitle));
+  if (theirs.size === 0) return true; // nothing to disagree with — keep the old behaviour
+  return tokenize(capturedText).some((t) => theirs.has(t));
+}
+
 // resolveGoalForCapture — the WHOLE of --goal resolution for one capture, in the
 // interview's own precedence: an explicit id wins outright; 'none' is a hard
 // opt-out (no default, no hint); otherwise the active-claim default runs, and
@@ -168,26 +195,34 @@ function sanitizeForTerminal(s) {
 // is testable without capturing stdout. Never throws (both collaborators above
 // already degrade to null on their own).
 async function resolveGoalForCapture({ goalArg, version, title, kind, client = cliClient } = {}) {
+  const claimLines = [];
   const parsed = parseGoalArg(goalArg);
   if (parsed.kind === 'id') return { goalId: parsed.id, lines: [] };
   if (parsed.kind === 'none') return { goalId: null, lines: [] };
 
   const defaulted = await resolveActiveClaimGoal({ client });
   if (defaulted) {
-    return {
-      goalId: defaulted.goalId,
-      lines: [`↪ defaulting --goal to ${defaulted.goalId} from your active claim on task #${defaulted.taskId} ("${sanitizeForTerminal(defaulted.taskTitle)}") — override with --goal <id>, or --goal none to file homeless.`],
-    };
+    // Only inherit when the two are actually about the same thing. When they are
+    // not, say so and fall through to the suggester — which ranks on what was
+    // WRITTEN rather than on what happens to be open — instead of filing silently
+    // into the wrong goal.
+    if (claimShareSubject(title, defaulted.taskTitle)) {
+      return {
+        goalId: defaulted.goalId,
+        lines: [`↪ defaulting --goal to ${defaulted.goalId} from your active claim on task #${defaulted.taskId} ("${sanitizeForTerminal(defaulted.taskTitle)}") — override with --goal <id>, or --goal none to file homeless.`],
+      };
+    }
+    claimLines.push(`↪ NOT defaulting to your active claim's goal: task #${defaulted.taskId} ("${sanitizeForTerminal(defaulted.taskTitle)}") shares no subject with what you filed — pass --goal ${defaulted.goalId} if it really belongs there.`);
   }
 
   const hint = await fetchGoalSuggestion({ client, version, title, kind });
   if (hint) {
     return {
       goalId: null,
-      lines: [`💡 possible home: goal ${hint.id} "${sanitizeForTerminal(hint.title)}" (score ${hint.score}) — re-run with --goal ${hint.id} (or --goal none to stay homeless on purpose).`],
+      lines: [...claimLines, `💡 possible home: goal ${hint.id} "${sanitizeForTerminal(hint.title)}" (score ${hint.score}) — re-run with --goal ${hint.id} (or --goal none to stay homeless on purpose).`],
     };
   }
-  return { goalId: null, lines: [] };
+  return { goalId: null, lines: claimLines };
 }
 
 // DEFAULT IS NO, and only an explicit yes counts. Extracted so the done-when

package/scripts/gds/category-advisory-guard.js

@@ -71,15 +71,56 @@ const FEATURE_ANCHORS = [
 // table name needs no boundary — nothing else is called that.
 const CATEGORY_RE = /\bcategor(y|ies|ised|ized|isation|ization)\b|\bcategory_id\b|work_categories/i;
 
-// Strip // line comments and /* */ blocks so a citation of the rule is legal and
-// only executable text is judged. Crude on purpose: it errs toward keeping text
-// (a `//` inside a string literal turns the rest of that line into a "comment"),
-// and erring toward keeping text would make the check LOUDER, not quieter — which
-// is the safe direction for a guard.
+// Strip // line comments and /* */ blocks so a citation of a rule is legal and only
+// executable text is judged.
+//
+// String-aware, and that is the whole point rather than a refinement. The direction
+// a stripper errs in is a safety property: keeping a comment only re-raises a false
+// alarm, which is LOUD and gets fixed, while dropping real code makes a guard report
+// clean over a live violation, which is indistinguishable from a tree that is
+// actually clean. So the scanner must never remove text it is not sure about.
+//
+// The previous regex pair claimed to err that way and did the opposite. `//` inside
+// an ordinary string literal — a protocol-relative URL, a path fragment — matched the
+// line-comment rule and erased the rest of the line, real code included:
+//
+//   router.post('//legacy', requirePermission('task.abandon.own'), handler);
+//
+// stripped to `router.post('`, so the guard scanning for that very call found nothing
+// (task 1003832; the equivalent hole in the ownership-scope scan in
+// tests/government_require_permission.mjs). Tracking quotes fixes it at the root, for
+// both callers, and makes the erring-toward-keeping promise above actually true.
+//
+// Unterminated constructs deliberately keep their text rather than swallowing to EOF.
+// A regex literal is not tracked: an unescaped `//` cannot appear in one (it would be
+// an empty regex), so the only way in is a `/`-delimited literal containing an escaped
+// pair, which reads as escaped here too.
 function stripComments(src) {
-  return src
-    .replace(/\/\*[\s\S]*?\*\//g, ' ')
-    .replace(/(^|[^:])\/\/[^\n]*/g, '$1');
+  let out = '';
+  let quote = null; // ' " or ` — inside a string literal, nothing is a comment
+  for (let i = 0; i < src.length;) {
+    const c = src[i];
+    const d = src[i + 1];
+    if (quote) {
+      if (c === '\\') { out += c + (d ?? ''); i += 2; continue; }
+      if (c === quote) quote = null;
+      out += c; i += 1; continue;
+    }
+    if (c === '"' || c === "'" || c === '`') { quote = c; out += c; i += 1; continue; }
+    if (c === '/' && d === '/') {
+      while (i < src.length && src[i] !== '\n') i += 1; // stop AT the newline, never past it
+      continue;
+    }
+    if (c === '/' && d === '*') {
+      const end = src.indexOf('*/', i + 2);
+      if (end === -1) { out += src.slice(i); break; } // unterminated: keep it
+      out += ' ';
+      i = end + 2;
+      continue;
+    }
+    out += c; i += 1;
+  }
+  return out;
 }
 
 function readFromDisk(rel) {