@bongos/core 1.19.936 → 1.19.938

package/modules/ideas/routes/ratify-goal.js

@@ -0,0 +1,163 @@
+// modules/ideas/routes/ratify-goal.js — POST /inbox/:id/ratify-goal, the route
+// that turns a Full Idea the board has carried into a GOAL (task 1004096 /
+// BV2.R17, spec R23, goal 1000095, criterion `ideator-full-idea-shapes-the-space`).
+//
+// WHY IT IS ITS OWN FILE, and not one more route in inbox.js. That file sits at
+// the 1,500-line size ratchet (`scripts/gds/fitness-ratchets.js` OVERSIZE_LINES)
+// and this route pushed it 24 lines over. Trimming back under would have left it
+// at ~1,497 — a landmine for whoever adds the next line — so the route moved
+// out instead. It is the same call `trail-descent.js`, `trail-size.js` and
+// `projection.js` were carved out on, and projection.js's own header names the
+// failure mode being avoided: a ceiling that has "started deciding the design
+// rather than the domain".
+//
+// It is also a clean cut on the domain, not only on the line count. Everything
+// in inbox.js is INTAKE — a thought entering the system and becoming work, or
+// not. This is the opposite end: a thought that has already been through the
+// Board Room, becoming the structure other people's work lands in. The
+// criterion half of ratification (`POST /inbox/:id/ratify`) stays in inbox.js
+// where it has always been; moving it would be a rename with no argument behind
+// it, and the two halves are documented as deliberately asymmetrical anyway
+// (see `../ratify.js`).
+//
+// ROUTE ORDER IS NOT AT RISK HERE, unlike the literal paths inbox.js warns
+// about. Express matches whole paths, so `/inbox/:id` cannot swallow
+// `/inbox/:id/ratify-goal` however the two files are mounted. A literal segment
+// AFTER a param — the `/tasks/removal-proposals` trap the lifecycle map
+// records — is a different shape from a literal segment after a param plus a
+// further segment, which is what this is.
+//
+// MODULE BOUNDARY (ADR 0093 §1): auth gates and request validators reach through
+// the published doorway `src/module-api.js`; `../inbox` is an intra-module
+// sibling. Never a core internal, never another module.
+
+const express = require('express');
+const api = require('../../../src/module-api');
+const inbox = require('../inbox');
+
+const log = api.logger('ideas');
+const { validateOrRespond, LIMITS, parseId } = api;
+
+module.exports = function buildRatifyGoalRouter() {
+  const router = express.Router();
+
+  // The fields a ratify-goal refusal may put on the wire — an ALLOWLIST, not a
+  // `{ ...err }` spread. Every shape thrown by `ratifyFullIdeaAsGoal` today is a
+  // plain typed refusal this code constructs itself, so a spread is harmless
+  // TODAY; what it is not is harmless tomorrow. A later call site that let a
+  // real exception carrying a `.code` fall into this catch would echo whatever
+  // else that object holds, and the refusals here already spread two internal
+  // objects into themselves (the composer's result, the lifecycle port's
+  // verdict) — so `ok`, `description` and `criterionMd` are all one edit away
+  // from the response body. Naming them explicitly costs nothing and means a
+  // new internal field is invisible by default rather than published by default.
+  const RATIFY_GOAL_DETAIL_FIELDS = [
+    'message',      // a gate's own sentence, written to be read by the caller
+    'reason',       // why the composer refused
+    'field',        // which answer was missing
+    'template_key', // which vintage has no goal shape
+    'grade',        // what the idea actually is, when it is not Full
+    'status',       // the idea's status, when it is no longer open
+    'version_status', 'unknown', 'valid', 'scope_modules', 'detail',
+  ];
+  const ratifyGoalDetail = (err) => {
+    const out = {};
+    for (const k of RATIFY_GOAL_DETAIL_FIELDS) {
+      if (err[k] !== undefined) out[k] = err[k];
+    }
+    return out;
+  };
+
+  // BV2.R17 (task 1004096, spec R23, goal 1000095) — ratify a FULL IDEA into a
+  // GOAL, atomically:
+  //   - INSERT goals (title from the idea, description = its five answers)
+  //   - INSERT done_when_criteria on that goal from the "what does a successful
+  //     implementation look like" answer
+  //   - UPDATE idea_inbox SET status='promoted', reviewed_at=now()
+  //   - INSERT ideas_goal_ratifications — who ratified, under which board
+  //     decision, with the author's own recommendation recorded beside it
+  // All of it in one transaction; a partial failure rolls back to an open idea.
+  //
+  // A SEPARATE ROUTE FROM /ratify, not a mode of it. The two take different
+  // subjects (a `criterion-proposal` idea whose body_md is JSON vs. a graded Full
+  // Idea whose answers are prose), produce different rows, and differ on whether
+  // the board has a say. One route with a discriminator would have to document
+  // which half of its own body applies, and a caller who got the discriminator
+  // wrong would be told about a field rather than about the act.
+  //
+  // THE SCOPE AND THE VERSION COME FROM THE REQUEST because nothing else can
+  // supply them: no prose answer says which version a goal belongs to or which
+  // modules it may touch. THE GATES DO NOT come from the request — the handler
+  // passes the caller's LIVE rank through to the lifecycle port, which applies
+  // every check POST /goals applies (unknown module key, protected scope →
+  // Archon, a building version's goal set closed without a named Archon
+  // admission). `idea.ratify`'s floor is Metic, so those gates are load-bearing
+  // here rather than ceremonial.
+  //
+  // Statuses: 400 a bad body / an unratifiable idea / an unmappable template ·
+  // 403 a rank gate · 404 no such idea · 409 the idea is not open, the board has
+  // not passed it, the version will not take a goal, or it is already ratified.
+  router.post(
+    '/inbox/:id/ratify-goal',
+    api.requireBuilder,
+    api.requirePermission('idea.ratify'),
+    async (req, res) => {
+      if (validateOrRespond(req, res, {
+        target_version: { required: true, type: 'string', minLength: 1, maxLength: 64 },
+        scope_modules: { type: 'array', maxItems: 64, itemsType: 'string' },
+        // Mirrors POST /goals: the PRESENCE of a reason IS the override, so one
+        // cannot be requested without stating a cause, and minLength 8 because
+        // 'ok' is not a reason.
+        admit_reason: { type: 'string', minLength: 8, maxLength: 500 },
+        notes_md: { type: 'string', maxLength: LIMITS.NOTES },
+      })) return;
+      const id = parseId(req, res, { code: 'bad_id' });
+      if (id === null) return;
+      try {
+        const result = await inbox.ratifyFullIdeaAsGoal(id, req.builder.id, {
+          targetVersion: req.body.target_version,
+          scopeModules: req.body.scope_modules || [],
+          admitReason: (req.body.admit_reason || '').trim() || null,
+          // The live rank read off the authenticated request, never a body field
+          // (ADR 0016) — the port denies when it is absent.
+          actorRank: req.builder.rank,
+          notesMd: typeof req.body.notes_md === 'string' ? req.body.notes_md : '',
+        });
+        res.status(201).json({ ok: true, ...result });
+      } catch (err) {
+        if (err && err.code) {
+          // A refusal that already carries its own status is one the lifecycle
+          // port named (the goal-creation gates) — rendered as given rather than
+          // re-mapped here, so the two files cannot disagree about what a gate
+          // returns.
+          if (Number.isInteger(err.status)) {
+            return res.fail(err.code, err.status, ratifyGoalDetail(err));
+          }
+          const status =
+            err.code === 'IDEA_NOT_FOUND' ? 404 :
+            err.code === 'NOT_A_FULL_IDEA' ? 400 :
+            err.code === 'CANNOT_COMPOSE_GOAL' ? 400 :
+            err.code === 'TARGET_VERSION_REQUIRED' ? 400 :
+            err.code === 'BAD_ID' ? 400 :
+            err.code === 'BAD_RATIFIER' ? 400 :
+            err.code === 'IDEA_NOT_OPEN' ? 409 :
+            err.code === 'BOARD_HAS_NOT_PASSED' ? 409 :
+            err.code === 'NO_LIFECYCLE' ? 503 :
+            err.code === 'NO_BOARD' ? 503 :
+            500;
+          if (status !== 500) return res.fail(err.code, status, ratifyGoalDetail(err));
+        }
+        // The UNIQUE trips are the double-ratification guards: one on the audit
+        // row's idea_id, one on (version_id, criterion_id). Either means this
+        // idea has already become a goal.
+        if (err && err.code === '23505') {
+          return res.fail('IDEA_ALREADY_RATIFIED', 409, { detail: 'This idea has already been ratified into a goal.' });
+        }
+        log.error('[gds] POST /inbox/:id/ratify-goal', err);
+        res.fail('ratify_goal_failed', { status: 500, message: 'internal error' });
+      }
+    }
+  );
+
+  return router;
+};

package/modules/ideas/templates.js

@@ -35,13 +35,25 @@
 // resolve its own registry and pass it through; nothing below cares where a
 // registry came from. No customization UI, no config plumbing — just the seam.
 //
-// Same-module import: DEFAULT_TEMPLATE_KEY and the payload cap live in inbox.js
-// (declared there for the route validators, mirroring the DB constraints) — one
-// source, so this file can never drift from what the store accepts.
+// Same-module import: DEFAULT_TEMPLATE_KEY and the payload cap live in
+// projection.js (declared there for the route validators, mirroring the DB
+// constraints) — one source, so this file can never drift from what the store
+// accepts.
+//
+// IT READS THEM FROM projection.js, NOT FROM inbox.js, and that is load-bearing
+// rather than tidy. Both names are the same constants either way — inbox.js only
+// re-exports what the 1004115 carve moved down to projection.js — but inbox.js
+// requires ./ratify, so importing them from there makes this file part of a
+// require CYCLE the moment anything in the ratify half wants a template
+// (BV2.R17 wants exactly that: a Full Idea's answers are ordered by the
+// declaration here). projection.js requires NOTHING, by design — its own header
+// calls that out as the property that keeps the module acyclic — so reading the
+// constants from the file that declares them is both shorter and the only
+// spelling that stays acyclic.
 
 'use strict';
 
-const { DEFAULT_TEMPLATE_KEY, FIELD_VALUES_MAX } = require('./inbox');
+const { DEFAULT_TEMPLATE_KEY, FIELD_VALUES_MAX } = require('./projection');
 
 // The five base fields, verbatim from the owner's brief. `key` is the stable
 // snake_case identity `field_values` is stored under (renaming a label is free;

package/modules/lifecycle/goal-from-idea.js

@@ -0,0 +1,131 @@
+'use strict';
+
+// modules/lifecycle/goal-from-idea.js — creating the GOAL a ratified Full Idea
+// becomes, inside somebody else's transaction (task 1004096 / BV2.R17, spec R23,
+// goal 1000095, criterion `ideator-full-idea-shapes-the-space`).
+//
+// WHY THIS LIVES IN LIFECYCLE AND NOT IN modules/ideas. `goals`, `versions` and
+// `done_when_criteria` are this module's tables, and the ideas module may not
+// import lifecycle (the one-way module rule, ADR 0083). The alternative was to
+// widen the `lifecycle` port with four primitives — getVersion, createGoal,
+// createCriterion, authorizeGoalCreate — and let the ideas module compose them.
+// That is the shape to avoid: composing them IS the policy, and the policy is
+// "may a goal be created here, by this rank, with this scope", which is a
+// lifecycle judgement. Handing a caller the four pieces hands them four chances
+// to leave one out, and the one most easily left out is the gate.
+//
+// SO THIS IS ONE PORT CALL THAT EITHER CREATES BOTH ROWS OR NAMES ITS REFUSAL.
+// The ideas module supplies the DATA a ratification carries (title, the five
+// answers, the version and scope the board chose) and the actor's live rank; it
+// never gets to decide whether the create is allowed.
+//
+// IT RUNS IN THE CALLER'S TRANSACTION (`deps.client`, required — see below), for
+// the ensureMaintenanceGoal reason: a goal committed on its own connection would
+// survive a rolled-back ratification as an empty goal nobody asked for, pointing
+// at an idea still sitting `open` in the inbox.
+//
+// EVERY GATE POST /goals APPLIES IS APPLIED HERE, and that is the point of the
+// file rather than a courtesy. `idea.ratify`'s floor is METIC (ADR 0157 lowered
+// it from archon), while `POST /goals` refuses a protected-`scope_modules` goal
+// to anyone below Archon and refuses to grow a BUILDING version's goal set at
+// all without a named Archon admission. A ratification path that skipped either
+// would be a Metic-reachable way around both — the scope wall and the R03 gate
+// would still be in the code and no longer in the way of anything.
+
+const api = require('../../src/module-api');
+const db = require('./db.js');
+const { authorizeGoalCreate } = require('./routes/goal-route-authz.js');
+
+const { isModuleKey, scopeIncludesProtected, moduleKeys } = api.moduleScopeMap;
+
+// A typed refusal, never a throw: the caller is inside a transaction it has to
+// roll back itself, and an exception thrown across a port is the thing that
+// makes a rollback easy to forget. `status` travels with the refusal so the
+// route renders it without a second mapping table.
+function refuse(code, status, extra = {}) {
+  return { ok: false, code, status, ...extra };
+}
+
+// createRatifiedGoal — the goal + its first done-when criterion, in the caller's
+// transaction, or a named refusal.
+//
+// `criterionMd` is REQUIRED and is not a convenience. The criterion is what makes
+// the created row a goal in this project's sense rather than an empty container:
+// ADR 0263's close gate reads done-when criteria, so a goal born with none can
+// never be achieved and holds its version open forever. BV2.R17's whole claim is
+// that a Full Idea's "what does a successful implementation look like" answer IS
+// that criterion — so the two rows are one act, and this function will not make
+// the first without the second.
+//
+// `criterionRef` is the stable `criterion_id` text. The caller derives it from
+// the source idea (`idea-<n>`), which makes the UNIQUE (version_id,
+// criterion_id) constraint a second, database-level guard against ratifying the
+// same idea twice onto the same version — the `proposal-<idea_id>` trick
+// ratifyCriterionProposal already uses, for the same reason.
+async function createRatifiedGoal(
+  { versionId, title, description = null, subtitle = null, scopeModules = [], createdBy = null,
+    criterionMd, criterionRef, admitReason = null, actorRank = null },
+  deps = {}
+) {
+  if (!deps.client) {
+    // Not a policy refusal — a programming error, and one whose consequence is a
+    // half-committed ratification. It throws rather than returning, because no
+    // caller can sensibly handle it and none should try.
+    throw new Error('createRatifiedGoal requires deps.client — it must run in the ratification transaction');
+  }
+  if (typeof title !== 'string' || !title.trim()) return refuse('TITLE_REQUIRED', 400);
+  if (typeof criterionMd !== 'string' || !criterionMd.trim()) return refuse('CRITERION_REQUIRED', 400);
+  if (typeof criterionRef !== 'string' || !criterionRef.trim()) return refuse('CRITERION_REF_REQUIRED', 400);
+
+  const scope = Array.isArray(scopeModules) ? scopeModules : [];
+  // Fail closed on an unknown module key, POST /goals' first gate: a scope wall
+  // that can name a module which does not exist is not a wall.
+  const unknown = scope.filter((k) => !isModuleKey(k));
+  if (unknown.length) return refuse('UNKNOWN_MODULE', 400, { unknown, valid: moduleKeys() });
+  // The two RANK gates. `actorRank` is the caller's LIVE rank read (ADR 0016) —
+  // never a value a request body carried — and an absent rank denies, because a
+  // rank we were not told is not a rank we may assume.
+  if (scopeIncludesProtected(scope) && actorRank !== 'archon') {
+    return refuse('ARCHON_REQUIRED_FOR_PROTECTED_SCOPE', 403, { scope_modules: scope });
+  }
+  const reason = typeof admitReason === 'string' ? admitReason.trim() || null : null;
+  // Refused by RANK before the version is fetched, the POST /goals ordering: a
+  // Metic must not learn whether the override would have worked.
+  if (reason !== null && actorRank !== 'archon') {
+    return refuse('ARCHON_REQUIRED_FOR_ADMISSION', 403);
+  }
+
+  // FOR UPDATE, so a version freeze committing between this read and this
+  // transaction's COMMIT cannot leave the goal and its criterion on a version
+  // that closed underneath them (getVersion's own note explains why a plain read
+  // is not enough under READ COMMITTED).
+  const version = await db.getVersion(versionId, { client: deps.client, forUpdate: true });
+  const decision = authorizeGoalCreate({ version, override: reason !== null });
+  if (!decision.ok) {
+    return refuse(decision.body.error, decision.status, { message: decision.body.message, version_status: decision.body.status });
+  }
+
+  const goal = await db.createGoal({
+    versionId,
+    title: title.trim(),
+    subtitle,
+    description,
+    scopeModules: scope,
+    createdBy,
+    // The admission row is written ONLY when the override actually opened the
+    // gate — `overrideApplied`, not "a reason was supplied". A reason on a
+    // planning version changed nothing and must not be filed as a skipped gate.
+    admission: decision.overrideApplied ? { admittedBy: createdBy, reason } : null,
+  }, { client: deps.client });
+
+  const criterion = await db.createCriterion({
+    versionId,
+    criterionId: criterionRef.trim(),
+    criterionMd,
+    goalId: goal.id,
+  }, { client: deps.client });
+
+  return { ok: true, goal, criterion, admitted: decision.overrideApplied };
+}
+
+module.exports = { createRatifiedGoal };

package/modules/lifecycle/lifecycle.js

@@ -19,6 +19,7 @@
 const db = require('./db');
 const classifier = require('./task-classifier');
 const goalSuggest = require('./goal-suggest');
+const goalFromIdea = require('./goal-from-idea');
 const helpRequests = require('./help-requests');
 const taskRecommendations = require('./task-recommendations');
 const activity = require('./activity');
@@ -66,6 +67,19 @@ module.exports = {
   // lifecycle tables and the ideas module may not import lifecycle (ADR 0083).
   ensureMaintenanceGoal: (...a) => db.ensureMaintenanceGoal(...a),
   currentBuildingVersionId: (...a) => db.currentBuildingVersionId(...a),
+  // createRatifiedGoal (task 1004096 / BV2.R17): the GOAL a ratified Full Idea
+  // becomes, plus the done-when criterion its "what does a successful
+  // implementation look like" answer supplies — both rows, in the ideas module's
+  // ratification transaction, or one named refusal.
+  //
+  // ONE CALL RATHER THAN FOUR PRIMITIVES, deliberately. The ideas module could
+  // have been handed getVersion + createGoal + createCriterion +
+  // authorizeGoalCreate and left to compose them, but composing them IS the
+  // goal-creation policy — the scope wall, the rank gates, the R03 building-
+  // version gate — and that policy is a lifecycle judgement. `idea.ratify`'s
+  // floor is Metic, so a caller free to leave the gate out would be a
+  // Metic-reachable way around it. See modules/lifecycle/goal-from-idea.js.
+  createRatifiedGoal: (...a) => goalFromIdea.createRatifiedGoal(...a),
 
   // --- work-tracking READS the staying-core read routes resolve --------------
   // public.js (the status surface): version/ship feed + grade trend.

package/modules/provisioning/core-upgrade.js

@@ -7,7 +7,7 @@
 // that makes shipped work visible to users. It was reachable from exactly one
 // place — a shell on the control-plane box with an ssh key — so the owner could not
 // take it, and neither could an agent (the permission classifier blocks a mutating
-// `sudo -u lars` over ssh by design).
+// `sudo -u <app user>` over ssh by design).
 //
 // THIS FILE ONLY ASKS. It validates and queues an intent; the control-plane runner
 // drains it and drives the proven `bongos upgrade` path with its health gate and

package/modules/provisioning/routes/core-upgrade.js

@@ -8,7 +8,7 @@
 // reachable from exactly one place — a shell on the control-plane box holding an
 // ssh key — which is why the owner said "I don't think I can make anything live",
 // and why an agent could not close the loop for them either: the permission
-// classifier blocks a mutating `sudo -u lars` over ssh by design.
+// classifier blocks a mutating `sudo -u <app user>` over ssh by design.
 //
 // THE WEB TIER ONLY ASKS. This queues an intent; the control-plane runner drains it
 // and drives the proven `bongos upgrade` path with its health gate and auto-rollback

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.936",
+  "version": "1.19.938",
   "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/audit-authorship.sh

@@ -13,6 +13,8 @@
 #     during a builder's session. (Use `req.builder.id` / the active claim.)
 #   * `lars589` / `larskristensen` literals in setup-path code or test data
 #     that would mis-attribute a second builder's work.
+#   * The founder's unix account in account position (`-o`/`-u <it>`,
+#     `User=<it>`, `APP_USER = '<it>'`) in runtime code — section 6.
 #
 # What is INTENTIONAL and allow-listed (NOT a violation):
 #   * Archived shipping docs in `limitations/*-shipped.md` — historical record.
@@ -280,6 +282,36 @@ fi
 grep -vE "$OPS_ALLOWLIST_PATTERN" "$TMP_HITS" \
   | grep -vE "$SPEC_ALLOWLIST_PATTERN" > "$TMP_FILTERED" || true
 
+# ----------------------------------------------------------------------------
+# 6. The founder's UNIX ACCOUNT in account position (task 1002719). Family (c)
+#    greps the GitHub login, and a unix name is not a GitHub login — which is
+#    how the standup's `install -d -o <founder> …` reached every operator's box
+#    unseen. Runtime code only (tests/ pin fixtures by design), and the ops
+#    allowlist above does NOT apply: "that is the droplet's unix user" is the
+#    very assumption this family refuses in code that runs on other planes.
+#    Derive the account instead (provision-repo.js appUser()).
+# ----------------------------------------------------------------------------
+UNIX_USER_PATTERN='((^|[^A-Za-z0-9_.-])(-o|-g|-u)[ =]lars\b)|(\b(User|Group)=lars\b)|(\bchown( -R)? lars\b)|([A-Za-z_]*[Uu][Ss][Ee][Rr][A-Za-z_]*\s*[:=]\s*["'"'"']lars["'"'"'])'
+UNIX_ALLOWLIST=(
+  # One-off backfill sweeps (tasks 1003939, 1003947), run by hand on the plane
+  # whose rows predate the fix; they name that plane's account on purpose.
+  'scripts/gds/address-park-sweep.sh'
+  'scripts/gds/stray-unit-sweep.sh'
+
+  # This script's own pattern.
+  'scripts/gds/audit-authorship.sh'
+)
+UNIX_ALLOWLIST_RE=''
+for e in "${UNIX_ALLOWLIST[@]}"; do
+  UNIX_ALLOWLIST_RE+="^${e//./\\.}:|"
+done
+UNIX_ALLOWLIST_RE="${UNIX_ALLOWLIST_RE%|}"
+
+grep -RIn -E "${EXCLUDE_DIRS[@]}" --exclude-dir=tests --exclude-dir=test "${EXCLUDE_FILES[@]}" -e "$UNIX_USER_PATTERN" . 2>/dev/null \
+  | sed 's|^\./||' \
+  | sort -u \
+  | grep -vE "$UNIX_ALLOWLIST_RE" >> "$TMP_FILTERED" || true
+
 HIT_COUNT=$(wc -l < "$TMP_FILTERED" | tr -d ' ')
 
 if [ "$VERBOSE" = "1" ]; then
@@ -306,6 +338,7 @@ echo "Remediation:"
 echo "  * Paths like /Users/larskristensen/...  ->  use \$HOME or os.path.expanduser('~')"
 echo "  * builder_id = 1 / shipped_by = 1       ->  use req.builder.id / the active claim"
 echo "  * lars589 / larskristensen literals     ->  use the current builder's github_login"
+echo "  * -o/-u lars, User=lars, *user = 'lars' ->  derive the account (appUser() in provision-repo.js)"
 echo ""
 echo "If a hit IS intentional (historical doc, droplet operational identity,"
 echo "or a frozen seed/import script), add it to the ALLOWLIST or"

package/scripts/gds/db-backup-nightly.sh

@@ -69,7 +69,7 @@ DUMP_GLOB="${DB_NAME}-${D}${D}${D}${D}-${D}${D}-${D}${D}T${D}${D}${D}${D}${D}${D
 if [ ! -d "$BACKUP_DIR" ]; then
   echo "ERROR: backup dir $BACKUP_DIR does not exist." >&2
   echo "       Create it with:" >&2
-  echo "         sudo install -d -o lars -g lars -m 0750 $BACKUP_DIR" >&2
+  echo "         sudo install -d -o $(id -un) -g $(id -gn) -m 0750 $BACKUP_DIR" >&2
   exit 2
 fi
 

package/scripts/gds/instance-apex.js

@@ -25,4 +25,14 @@ function provisionerBotEmail(env = process.env) {
   return apex ? `bot@${apex}` : 'bot@cloud-bongos.invalid';
 }
 
-module.exports = { instanceApex, provisionerBotEmail };
+// The name that identity commits under: the pack's product name, else the platform's
+// (task 1002719). Every caller builds `git config user.name "<name>"`, so a name the
+// shell cannot carry inside double quotes falls back instead of being interpolated.
+function brandProductName() {
+  try { return String(require('../../src/branding').branding().identity.productName || '').trim(); } catch { return ''; }
+}
+function provisionerBotName(name = brandProductName()) {
+  return name && !/["`$\\\r\n]/.test(name) ? name : 'Cloud Bongos';
+}
+
+module.exports = { instanceApex, provisionerBotEmail, provisionerBotName };

package/scripts/gds/provision-config.js

@@ -108,7 +108,7 @@ const CONFIG = {
   standaloneBase: process.env.PROVISION_STANDALONE_BASE || '/srv/cloudbongos',
   // ── Privilege escalation (task 2066, ADR 0128) ───────────────────────────
   // The intent runner runs as a NON-root user (provision-intent-runner.service:
-  // User=lars) that holds passwordless sudo. That user cannot itself write under
+  // User= the app user) that holds passwordless sudo. That user cannot itself write under
   // /etc, reload systemd/Caddy, or peer-auth to Postgres as a superuser — so the
   // runbook steps below FAIL as bare commands (the goal-35 blocker). With
   // PROVISION_SUDO=1 (alias PROVISION_PRIVILEGED=1) the privileged steps escalate:
@@ -163,7 +163,7 @@ const CONFIG = {
 
 // task 1002757 — the provisioner's git identity resolves from the instance's own
 // apex (env → bot@<apex> → neutral), never the hub's address hardcoded.
-const { provisionerBotEmail } = require('./instance-apex');
+const { provisionerBotEmail, provisionerBotName } = require('./instance-apex');
 
 const MAX_INTENT_ATTEMPTS = numEnv('PROVISION_INTENT_MAX_ATTEMPTS', 3);
 
@@ -229,5 +229,6 @@ module.exports = {
   numEnv,
   oauthSecret,
   provisionerBotEmail,
+  provisionerBotName,
   softFailResult,
 };

package/scripts/gds/provision-core-upgrade.js

@@ -30,7 +30,7 @@
 
 const path = require('path');
 const { CONFIG, MANIFEST_VERIFY_INTERVAL_MS, MANIFEST_VERIFY_TRIES, REPO_ROOT } = require('./provision-config.js');
-const { APP_USER, dbName, instanceUser, selfInstanceRoot, standaloneRoot } = require('./provision-repo.js');
+const { appUser, dbName, instanceUser, selfInstanceRoot, standaloneRoot } = require('./provision-repo.js');
 const { isValidSlug } = require('../../modules/provisioning/provisioning.js');
 
 // The shapes whose box this runner can actually reach. Mirrors UPGRADE_SHAPES in the
@@ -277,19 +277,19 @@ function parsePreflight(out) {
  * Which unix account should this instance's upgrade run as? Asks the box (task 1004128).
  *
  * The fleet is heterogeneous: instances provisioned before task 1003369 run as the
- * shared APP_USER, instances provisioned after run as their own `bongos-<slug>`. Neither
+ * shared app user, instances provisioned after run as their own `bongos-<slug>`. Neither
  * is guessable from the row, and getting it wrong is not a soft failure — `sudo` refuses
  * an unknown user and the upgrade dies before pre-flight, which is exactly how the
  * tenant leg has been broken.
  *
  * Falling back is NOT a privilege escalation: an instance with no account of its own is
- * already running as APP_USER (its unit says so), so this runs the upgrade as precisely
+ * already running as the app user (its unit says so), so this runs the upgrade as precisely
  * the account that owns the files and the database it is about to touch. It IS reported,
  * because a missing per-instance account is a provisioning gap someone should close, and
  * a silent fallback would hide it forever.
  */
 function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
-  if (inst.hosting_shape === 'control-plane') return { runAs: APP_USER, fellBack: false };
+  if (inst.hosting_shape === 'control-plane') return { runAs: appUser(), fellBack: false };
   // Re-checked HERE rather than left to instanceUser()'s own throw, for the reason
   // upgradeInvocation states about itself: a call site whose safety depends on a
   // helper's internals is one refactor away from a shell-interpolation path.
@@ -317,7 +317,7 @@ function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
   if (!/no such user|unknown user/i.test(said)) {
     return { runAs: wanted, fellBack: false, probeInconclusive: true };
   }
-  return { runAs: APP_USER, fellBack: true, wanted };
+  return { runAs: appUser(), fellBack: true, wanted };
 }
 
 // ONE BUILDER FOR BOTH LEGS (task 1004121).
@@ -357,7 +357,7 @@ function upgradeInvocation(inst, to, { privileged = false, dryRun = false, reque
   // half right. The control-plane leg is correct and verified live. The tenant leg
   // assumed the per-instance account model of task 1003369 is provisioned everywhere —
   // and on the live box NO `bongos-*` account exists, no such Postgres role exists, and
-  // every instance unit still says `User=lars`. So the fix for "Postgres has no role
+  // every instance unit still names the shared app user. So the fix for "Postgres has no role
   // root" swapped one absent account for another, and every tenant upgrade died with
   // `sudo: unknown user bongos-test4`.
   //
@@ -368,7 +368,7 @@ function upgradeInvocation(inst, to, { privileged = false, dryRun = false, reque
   // (resolveRunAs below) instead of either side assuming. Passing it in keeps this
   // builder pure; the default preserves the old derivation for callers that have not
   // probed.
-  const account = runAs || (inst.hosting_shape === 'control-plane' ? APP_USER : instanceUser(inst));
+  const account = runAs || (inst.hosting_shape === 'control-plane' ? appUser() : instanceUser(inst));
   const sudoP = privileged ? `sudo -u ${account} env PGDATABASE=${dbName(inst)} ` : '';
   const cli = path.posix.join('scripts', 'gds', 'upgrade.js');
   const shared = [`${sudoP}node ${cli}`, '--registry', `--to ${to}`,

package/scripts/gds/provision-process.js

@@ -20,7 +20,7 @@
 const fs = require('node:fs');
 const path = require('node:path');
 const { CONFIG, REPO_ROOT } = require('./provision-config.js');
-const { APP_USER, CORE_PKG_DIR, instanceUser, standaloneRoot } = require('./provision-repo.js');
+const { CORE_PKG_DIR, appGroupExpr, appUser, instanceUser, standaloneRoot } = require('./provision-repo.js');
 const {
   backupScriptPath, backupService, backupServicePath, backupTimer, backupTimerPath,
   backupUnitName, serviceUnit, serviceUnitPath,
@@ -39,7 +39,7 @@ const systemd = {
   // The backup DIR belongs to this step, not to the runbook: it exists only to serve the
   // schedule, so a manager that installs no schedule must not create it either.
   installBackup(inst, { exec, writeFile, sudoP }) {
-    exec(`${sudoP}install -d -o ${APP_USER} -g ${APP_USER} -m 0750 ${CONFIG.backupDir}`);
+    exec(`${sudoP}install -d -o ${appUser()} -g ${appGroupExpr()} -m 0750 ${CONFIG.backupDir}`);
     writeFile(backupServicePath(inst), backupService(inst), { mode: 0o644, sudo: true });
     writeFile(backupTimerPath(inst), backupTimer(inst), { mode: 0o644, sudo: true });
     exec(`${sudoP}systemctl daemon-reload`);