@bongos/core 1.19.319 → 1.19.320

package/scripts/gds/doc-cli-guard.js

@@ -15,7 +15,7 @@
 //
 // WHAT IT CHECKS, deliberately narrow: for every `node scripts/gds/<x>.js` in a
 // tracked .md, (a) the script exists, and (b) each `--flag` written next to it
-// appears in that script's source. Nothing else — this is not a prose linter.
+// appears in that script's source (or in a same-directory module it requires — a CLI may be carved into phase files). Nothing else — this is not a prose linter.
 //
 // STATIC ONLY, NEVER EXECUTED. The reason matters: running every documented CLI
 // would be slow, would need a session, and a command that blocks on a prompt
@@ -203,6 +203,38 @@ const readFileOrNull = (rel) => {
 
 const NAME = 'a doc that names a CLI matches the real CLI (G01)';
 
+// readCliSource — a CLI's source PLUS the source of the same-directory modules
+// it requires, concatenated.
+//
+// A big CLI is allowed to be more than one file: task 1003205 carved
+// scripts/gds/ship.js into ship-*.js phase modules, and the flag parsing for
+// e.g. `--no-surprise` moved with the phase that reads it. Scanning ship.js
+// alone then reports a documented, genuinely-honoured flag as a violation —
+// a false alarm that pushes the next agent toward silencing the rule via
+// DOC_CLI_ALLOW, which is exactly the outcome the rule exists to prevent.
+//
+// One level of same-directory relative requires is enough (it is where a carve
+// puts things) and keeps the read bounded. A missing sibling is skipped: the
+// point is to find the flag, not to prove the require graph.
+function readCliSource(rel) {
+  const src = readFileOrNull(rel);
+  if (src === null) return null;
+  const dir = path.dirname(rel);
+  const seen = new Set([rel]);
+  const parts = [src];
+  const RE = /require\(\s*['"](\.\/[^'"]+)['"]\s*\)/g;
+  let m;
+  while ((m = RE.exec(src))) {
+    let sib = path.join(dir, m[1]);
+    if (!sib.endsWith('.js')) sib += '.js';
+    if (seen.has(sib)) continue;
+    seen.add(sib);
+    const sibSrc = readFileOrNull(sib);
+    if (sibSrc !== null) parts.push(sibSrc);
+  }
+  return parts.join('\n');
+}
+
 function checkDocNamesRealCli({ files = null } = {}) {
   const docs = files || trackedMarkdown();
   // A lint that reports on nothing is worse than one that fails (the
@@ -217,7 +249,7 @@ function checkDocNamesRealCli({ files = null } = {}) {
   }
 
   const { violations, warnings, invocations } = scanDocs(docs, {
-    readDoc: readFileOrNull, readScript: readFileOrNull,
+    readDoc: readFileOrNull, readScript: readCliSource,
   });
 
   return {

package/scripts/gds/fitness.js

@@ -1023,9 +1023,14 @@ const IDENTITY_SCAN_ALLOWED = {
   'scripts/gds/fitness.js': 2,
   'scripts/gds/package-core.js': 1,
   'scripts/gds/seed-v3-tasks.js': 14,
-  'scripts/gds/audit-replay.sh': 1,
-  'scripts/gds/db-backup-nightly.sh': 1,
-  'scripts/gds/db-backup-offsite.sh': 2,
+  // audit-replay.sh + db-backup-{nightly,offsite}.sh were carved out here as
+  // "host-pinned ops"; task 1002757 RETIRED that justification for them — each
+  // now resolves its database from the branding pack (the migrate.sh pattern) and
+  // fails loudly rather than defaulting, so their counts ratcheted to zero and the
+  // entries are gone. seed-staging.sh keeps its carve-out on the OPPOSITE
+  // rationale: its literal is a fail-CLOSED safety interlock (the script wipes
+  // STAGING_DB and refuses unless the name matches exactly), so on any other
+  // instance it declines to run instead of destroying the wrong database.
   'scripts/gds/seed-staging.sh': 4,
   'scripts/gds/backfill-sessions.js': 2,
   'scripts/gds/box.js': 3,
@@ -1649,7 +1654,6 @@ function checkWriteRoutesValidated() {
   };
 }
 
-
 // ── Check 19 — the ADR 0174 vocabulary wall (goal 1000068 R07, task 1003008) ──
 //
 // "Role" means ONE thing in this codebase: a craft — Artist, Ideator, or Builder.

package/scripts/gds/gds-db-backup.service

@@ -1,13 +1,24 @@
+# TEMPLATE — not installable as-is (task 1002757). The __TOKENS__ below MUST be
+# substituted at install time; a provisioned instance gets a correct per-instance
+# unit pair generated by scripts/gds/provision.js (task 2213) and never needs this
+# file. Substitute:
+#   __SERVICE_USER__     the unix user that owns the instance + its Postgres role
+#   __INSTANCE_ROOT__    the instance checkout root (docs live under it)
+#   __CORE_SCRIPTS_DIR__ the deployed core's scripts/gds dir:
+#                          standalone: <instance-root>/node_modules/@bongos/core/scripts/gds
+#                          full clone: <instance-root>/scripts/gds
+#   __CONFIG_DIR__       the instance config dir name (offsite unit only)
+# One-liner: sed -e 's|__SERVICE_USER__|<user>|g' -e … gds-db-backup.service | sudo tee /etc/systemd/system/…
 [Unit]
 Description=Nightly pg_dump of GDS Postgres DB (filed by #412)
-Documentation=file:///home/lars/amazonprimea/docs/recipes/gds-db-backup.md
+Documentation=file://__INSTANCE_ROOT__/docs/recipes/gds-db-backup.md
 After=postgresql.service
 Requires=postgresql.service
 
 [Service]
 Type=oneshot
-User=lars
-Group=lars
+User=__SERVICE_USER__
+Group=__SERVICE_USER__
 # Run the canonical script from the deployed repo. Keep this path stable;
 # the recipe doc points at it for restore + manual-one-shot use cases.
 #
@@ -25,7 +36,7 @@ Group=lars
 #   vendored/standalone: /home/<user>/<instance>/node_modules/@bongos/core/scripts/gds/db-backup-nightly.sh
 #   full clone:          /home/<user>/<repo>/scripts/gds/db-backup-nightly.sh
 # See docs/recipes/gds-db-backup.md.
-ExecStart=/usr/bin/env bash /home/lars/amazonprimea/scripts/gds/db-backup-nightly.sh
+ExecStart=/usr/bin/env bash __CORE_SCRIPTS_DIR__/db-backup-nightly.sh
 # Modest hardening — the script only needs read on the socket + write on
 # /var/backups/gds. Anything else is gravy for forensics.
 NoNewPrivileges=true

package/scripts/gds/gds-db-backup.timer

@@ -1,6 +1,17 @@
+# TEMPLATE — not installable as-is (task 1002757). The __TOKENS__ below MUST be
+# substituted at install time; a provisioned instance gets a correct per-instance
+# unit pair generated by scripts/gds/provision.js (task 2213) and never needs this
+# file. Substitute:
+#   __SERVICE_USER__     the unix user that owns the instance + its Postgres role
+#   __INSTANCE_ROOT__    the instance checkout root (docs live under it)
+#   __CORE_SCRIPTS_DIR__ the deployed core's scripts/gds dir:
+#                          standalone: <instance-root>/node_modules/@bongos/core/scripts/gds
+#                          full clone: <instance-root>/scripts/gds
+#   __CONFIG_DIR__       the instance config dir name (offsite unit only)
+# One-liner: sed -e 's|__SERVICE_USER__|<user>|g' -e … gds-db-backup.service | sudo tee /etc/systemd/system/…
 [Unit]
 Description=Daily timer for GDS DB pg_dump (filed by #412)
-Documentation=file:///home/lars/amazonprimea/docs/recipes/gds-db-backup.md
+Documentation=file://__INSTANCE_ROOT__/docs/recipes/gds-db-backup.md
 
 [Timer]
 # Run every day at 04:00 UTC. That's a low-traffic window for a

package/scripts/gds/gds-db-offsite.service

@@ -1,13 +1,24 @@
+# TEMPLATE — not installable as-is (task 1002757). The __TOKENS__ below MUST be
+# substituted at install time; a provisioned instance gets a correct per-instance
+# unit pair generated by scripts/gds/provision.js (task 2213) and never needs this
+# file. Substitute:
+#   __SERVICE_USER__     the unix user that owns the instance + its Postgres role
+#   __INSTANCE_ROOT__    the instance checkout root (docs live under it)
+#   __CORE_SCRIPTS_DIR__ the deployed core's scripts/gds dir:
+#                          standalone: <instance-root>/node_modules/@bongos/core/scripts/gds
+#                          full clone: <instance-root>/scripts/gds
+#   __CONFIG_DIR__       the instance config dir name (offsite unit only)
+# One-liner: sed -e 's|__SERVICE_USER__|<user>|g' -e … gds-db-backup.service | sudo tee /etc/systemd/system/…
 [Unit]
 Description=Weekly offsite archive of GDS Postgres dumps to DigitalOcean Spaces (filed by #415)
-Documentation=file:///home/lars/amazonprimea/docs/recipes/gds-db-backup.md
+Documentation=file://__INSTANCE_ROOT__/docs/recipes/gds-db-backup.md
 After=network-online.target
 Wants=network-online.target
 
 [Service]
 Type=oneshot
-User=lars
-Group=lars
+User=__SERVICE_USER__
+Group=__SERVICE_USER__
 # Run the canonical script from the deployed repo. Keep this path stable;
 # the recipe doc points at it for restore + manual-one-shot use cases.
 #
@@ -18,12 +29,12 @@ Group=lars
 # this unit would have hit it on its first run.
 #
 # EDIT THIS PATH when installing (layout differs — vendored vs full clone).
-ExecStart=/usr/bin/env bash /home/lars/amazonprimea/scripts/gds/db-backup-offsite.sh
+ExecStart=/usr/bin/env bash __CORE_SCRIPTS_DIR__/db-backup-offsite.sh
 # S3 credentials for the Space live outside the repo (ADR 0022). systemd
 # injects them; the file is chmod 600, owned by lars. Missing-file is
 # tolerated here (the script fails loudly if the vars are unset) so a
 # fresh install doesn't fail to load the unit before creds are dropped in.
-EnvironmentFile=-/etc/amazonprimea/spaces.env
+EnvironmentFile=-/etc/__CONFIG_DIR__/spaces.env
 # Hardening — the script reads dumps from /var/backups/gds and talks to the
 # network. It needs no write access to the local filesystem.
 NoNewPrivileges=true

package/scripts/gds/gds-db-offsite.timer

@@ -1,6 +1,17 @@
+# TEMPLATE — not installable as-is (task 1002757). The __TOKENS__ below MUST be
+# substituted at install time; a provisioned instance gets a correct per-instance
+# unit pair generated by scripts/gds/provision.js (task 2213) and never needs this
+# file. Substitute:
+#   __SERVICE_USER__     the unix user that owns the instance + its Postgres role
+#   __INSTANCE_ROOT__    the instance checkout root (docs live under it)
+#   __CORE_SCRIPTS_DIR__ the deployed core's scripts/gds dir:
+#                          standalone: <instance-root>/node_modules/@bongos/core/scripts/gds
+#                          full clone: <instance-root>/scripts/gds
+#   __CONFIG_DIR__       the instance config dir name (offsite unit only)
+# One-liner: sed -e 's|__SERVICE_USER__|<user>|g' -e … gds-db-backup.service | sudo tee /etc/systemd/system/…
 [Unit]
 Description=Weekly timer for GDS DB offsite archive to Spaces (filed by #415)
-Documentation=file:///home/lars/amazonprimea/docs/recipes/gds-db-backup.md
+Documentation=file://__INSTANCE_ROOT__/docs/recipes/gds-db-backup.md
 
 [Timer]
 # Run weekly on Sunday at 05:00 UTC. That's one hour after the daily local

package/scripts/gds/instance-apex.js

@@ -0,0 +1,28 @@
+'use strict';
+// instance-apex.js — the instance's own registrable apex + the addresses derived
+// from it, read from its branding pack (task 1002757).
+//
+// WHY THIS EXISTS. Operator-plane defaults used to carry the founder's apex as a
+// literal (box DNS zones, the Cloudflare zone, the provisioner's git identity),
+// so another operator's fleet pointed at the founder's DNS and its commits were
+// attributed to the hub. These resolvers return NULL rather than guessing when the
+// pack names no public origin: every caller treats null as "not configured" and
+// refuses, which fails loudly instead of minting an unreachable host.
+function instanceApex() {
+  try {
+    const host = new URL(require('../../src/branding').branding().domains.publicOrigin).hostname;
+    return host && !/^localhost$/i.test(host) ? host : null;
+  } catch { return null; }
+}
+
+// The git identity a provisioner commits scaffold/pin changes as: explicit env →
+// bot@<instance apex> → a neutral, deliberately-undeliverable platform address
+// (never a live inbox by accident).
+function provisionerBotEmail(env = process.env) {
+  const explicit = String(env.PROVISION_BOT_EMAIL || '').trim();
+  if (explicit) return explicit;
+  const apex = instanceApex();
+  return apex ? `bot@${apex}` : 'bot@cloud-bongos.invalid';
+}
+
+module.exports = { instanceApex, provisionerBotEmail };

package/scripts/gds/newcomer-floor.templates.json

@@ -49,7 +49,7 @@
       "est_minutes": 55,
       "credits_reward": 15,
       "title": "Generate one new in-world art asset of your choice (a prop, plant, animal, or accessory) via the pixel-art pipeline",
-      "description": "## What you're doing\n\nAmazonprimea is a young ancient-Greek coastal world, and it always needs more to look at. Your first ship as an artist is to **generate ONE new in-world asset of your own choosing** and add it to the world. You pick the subject — that's the fun part. Good candidates, all in-world (Mediterranean coast just south of Athens, mythic 'discovered secret' tone):\n- **Props**: amphora, fishing net, basket, crate, urn, torch, market awning, oar, clay pot.\n- **Plants**: olive tree, cypress, reeds, grapevine, shrub, wild herbs.\n- **Animals**: goat, chicken, duck, donkey, fish, gull, lizard.\n- **Accessories**: a sandal, a sun hat, a length of rope, a string of beads.\n\nIt is identical for every newcomer and **always valuable**, because a growing world has effectively unbounded demand for new props, flora, fauna, and detail — every newcomer picks a different subject, so two runs never collide.\n\n## How to find your way in\n\n1. Read `art/README.md` and `docs/recipes/pixel-art-pipeline.md`, plus `modules/art-pipeline/template/style_guide.md`, `modules/art-pipeline/template/rubric.json`, and `modules/art-pipeline/template/palette.json` — that's the look you must hit: 16-bit pixel art, early-Pokémon (FireRed) touchstone, top-down, 32×32, locked 64-colour Mediterranean palette (olive greens, warm tans, turquoise sea, weathered marble — NOT spring green, NOT navy, NOT pine).\n2. **Pick ONE subject.** Keep it to a SINGLE 32×32 tile/sprite — not a whole spritesheet or family (that's a bigger task).\n3. **Check the budget first**: `python3 modules/art-pipeline/pipeline/cost_ledger.py status` (the pipeline hard-stops at $80; one asset is ~$0.05–0.45).\n4. **Generate via the pipeline — do not hand-draw or freelance.** Use the `/otb-tile-generate` skill: it appends your new entry to `modules/art-pipeline/template/vocabulary.json`, runs the generate → post-process-to-32×32 → score-against-rubric → retry orchestrator, saves the final PNG to `modules/art-pipeline/generated/tiles/<id>.png`, and logs cost. (This needs the art pipeline's `GOOGLE_AI_STUDIO_KEY`, which resolves from `~/.config/otb/env`; most builder setups have it. If yours doesn't, claim the engineer or ideator newcomer chore instead, or ask an Archon to enable it.)\n5. **Confirm it PASSED** the rubric (`modules/art-pipeline/iterations/run_summary.json` shows `status: \"pass\"`). If it only reached best-effort, regenerate with the fix_hint — never paper over a fail.\n6. **See it in-game**: `node scripts/gds/art-stage.js` rebuilds the atlas and surfaces it on your sandbox preview (`sandbox-<login>.amazonprimea.com`).\n7. Ship via `/builder-ship`; the ship notes name your asset and its rubric score.\n\n## Stay clear of (READ-ONLY)\n\nNever modify the locked palette (`modules/art-pipeline/template/palette.json`) or the rubric (`modules/art-pipeline/template/rubric.json`) — those are theme-defining and changing them needs an ADR (out of scope for a first ship). Touch only art assets/vocabulary under `art/` (and, only if your asset is a genuinely new base-tile TYPE, the `public/game/world/tilePalette.js` mapping). Do not touch any permission/pipeline-core/migration/infra file.",
+      "description": "## What you're doing\n\nThis instance's world always needs more to look at. Your first ship as an artist is to **generate ONE new in-world asset of your own choosing** and add it to the world. You pick the subject — that's the fun part. Good candidates, all in-world (Mediterranean coast just south of Athens, mythic 'discovered secret' tone):\n- **Props**: amphora, fishing net, basket, crate, urn, torch, market awning, oar, clay pot.\n- **Plants**: olive tree, cypress, reeds, grapevine, shrub, wild herbs.\n- **Animals**: goat, chicken, duck, donkey, fish, gull, lizard.\n- **Accessories**: a sandal, a sun hat, a length of rope, a string of beads.\n\nIt is identical for every newcomer and **always valuable**, because a growing world has effectively unbounded demand for new props, flora, fauna, and detail — every newcomer picks a different subject, so two runs never collide.\n\n## How to find your way in\n\n1. Read `art/README.md` and `docs/recipes/pixel-art-pipeline.md`, plus `modules/art-pipeline/template/style_guide.md`, `modules/art-pipeline/template/rubric.json`, and `modules/art-pipeline/template/palette.json` — that's the look you must hit: 16-bit pixel art, early-Pokémon (FireRed) touchstone, top-down, 32×32, locked 64-colour Mediterranean palette (olive greens, warm tans, turquoise sea, weathered marble — NOT spring green, NOT navy, NOT pine).\n2. **Pick ONE subject.** Keep it to a SINGLE 32×32 tile/sprite — not a whole spritesheet or family (that's a bigger task).\n3. **Check the budget first**: `python3 modules/art-pipeline/pipeline/cost_ledger.py status` (the pipeline hard-stops at $80; one asset is ~$0.05–0.45).\n4. **Generate via the pipeline — do not hand-draw or freelance.** Use the `/otb-tile-generate` skill: it appends your new entry to `modules/art-pipeline/template/vocabulary.json`, runs the generate → post-process-to-32×32 → score-against-rubric → retry orchestrator, saves the final PNG to `modules/art-pipeline/generated/tiles/<id>.png`, and logs cost. (This needs the art pipeline's `GOOGLE_AI_STUDIO_KEY`, which resolves from `~/.config/otb/env`; most builder setups have it. If yours doesn't, claim the engineer or ideator newcomer chore instead, or ask an Archon to enable it.)\n5. **Confirm it PASSED** the rubric (`modules/art-pipeline/iterations/run_summary.json` shows `status: \"pass\"`). If it only reached best-effort, regenerate with the fix_hint — never paper over a fail.\n6. **See it in-game**: `node scripts/gds/art-stage.js` rebuilds the atlas and surfaces it on your sandbox preview (`sandbox-<login>.<instance-apex>`).\n7. Ship via `/builder-ship`; the ship notes name your asset and its rubric score.\n\n## Stay clear of (READ-ONLY)\n\nNever modify the locked palette (`modules/art-pipeline/template/palette.json`) or the rubric (`modules/art-pipeline/template/rubric.json`) — those are theme-defining and changing them needs an ADR (out of scope for a first ship). Touch only art assets/vocabulary under `art/` (and, only if your asset is a genuinely new base-tile TYPE, the `public/game/world/tilePalette.js` mapping). Do not touch any permission/pipeline-core/migration/infra file.",
       "done_when": [
         "Exactly one NEW in-world asset (your chosen subject) was generated via the pixel-art pipeline (`/otb-tile-generate` / orchestrator.py); the final PNG exists at modules/art-pipeline/generated/tiles/<id>.png.",
         "It PASSED the rubric (modules/art-pipeline/iterations/run_summary.json status 'pass', or /otb-design-review numbers reported at/above the bar) and every pixel is on the locked palette (modules/art-pipeline/template/palette.json).",
@@ -70,7 +70,7 @@
       "est_minutes": 45,
       "credits_reward": 12,
       "title": "Idea-seed pass: file 5-8 fresh in-world ideas (names, lore, or builder-UX) into the idea inbox",
-      "description": "## What you'll do\n\nThe seed of almost everything built here is the **idea_inbox** — a queue anyone can drop ideas into, which trusted builders later triage into real tasks. Your first ship as an ideator is simple and concrete: **add a small batch of fresh ideas to that inbox.** You write no code, touch no game, change no system — you think, write a few short well-shaped ideas, and file them with one command each.\n\nIt is identical for every newcomer and **always valuable**: the inbox is never \"done\" — every triage pass consumes ideas (promote/discard/merge), so it is permanently hungry for fresh input, and a world the size of Amazonprimea always wants more names, more lore, more texture. Your batch is brand-new content, so it can never duplicate \"the work\" — the supply IS the work.\n\n## Pick ONE branch\n\n- **Branch A — PRODUCT flavour (default).** Ideas that grow the world players see: **names + one line of lore** for a character, structure, landmark, district, ship, or festival; or a world-background snippet (a custom, a superstition, a line a named NPC says). Tone: mythic, mysterious, a \"discovered secret\"; Mediterranean ancient-Greek coast (just south of Athens); NOT modern, NOT tongue-in-cheek-modern. Ground it in CLAUDE.md §3/§6/§7.\n- **Branch B — INTERNAL / builder-UX.** Small user-experience improvement ideas for the GDS / builders' hall (the surfaces builders use, not the game): a clearer label, a confusing onboarding message, a quality-of-life tweak to a status page or a slash-command's output. See `docs/TRACKS.md` for product vs internal.\n\n## How to find your way in\n\n1. (Branch A) Read CLAUDE.md §3/§6/§7 for tone. (Branch B) Skim `docs/TRACKS.md` and click around https://amazonprimea.com/builders for the rough edge you'll write up.\n2. See what's already filed so you don't repeat it: `node scripts/gds/api.js GET /api/gds/inbox`.\n3. File each idea with `node scripts/gds/capture.js \"<title>\" --body-file <path>` (filing an idea is the open-to-all path — a Xenos/Thetes session is allowed to do it; you just can't triage them). Put one line of detail + a `track: product` or `track: internal` line in each body file.",
+      "description": "## What you'll do\n\nThe seed of almost everything built here is the **idea_inbox** — a queue anyone can drop ideas into, which trusted builders later triage into real tasks. Your first ship as an ideator is simple and concrete: **add a small batch of fresh ideas to that inbox.** You write no code, touch no game, change no system — you think, write a few short well-shaped ideas, and file them with one command each.\n\nIt is identical for every newcomer and **always valuable**: the inbox is never \"done\" — every triage pass consumes ideas (promote/discard/merge), so it is permanently hungry for fresh input, and a growing world always wants more names, more lore, more texture. Your batch is brand-new content, so it can never duplicate \"the work\" — the supply IS the work.\n\n## Pick ONE branch\n\n- **Branch A — PRODUCT flavour (default).** Ideas that grow the world players see: **names + one line of lore** for a character, structure, landmark, district, ship, or festival; or a world-background snippet (a custom, a superstition, a line a named NPC says). Tone: mythic, mysterious, a \"discovered secret\"; Mediterranean ancient-Greek coast (just south of Athens); NOT modern, NOT tongue-in-cheek-modern. Ground it in CLAUDE.md §3/§6/§7.\n- **Branch B — INTERNAL / builder-UX.** Small user-experience improvement ideas for the GDS / builders' hall (the surfaces builders use, not the game): a clearer label, a confusing onboarding message, a quality-of-life tweak to a status page or a slash-command's output. See `docs/TRACKS.md` for product vs internal.\n\n## How to find your way in\n\n1. (Branch A) Read CLAUDE.md §3/§6/§7 for tone. (Branch B) Skim `docs/TRACKS.md` and click around your instance's /builders hall for the rough edge you'll write up.\n2. See what's already filed so you don't repeat it: `node scripts/gds/api.js GET /api/gds/inbox`.\n3. File each idea with `node scripts/gds/capture.js \"<title>\" --body-file <path>` (filing an idea is the open-to-all path — a Xenos/Thetes session is allowed to do it; you just can't triage them). Put one line of detail + a `track: product` or `track: internal` line in each body file.",
       "done_when": [
         "You filed 5–8 fresh ideas into the idea_inbox via `node scripts/gds/capture.js` (each prints a `Captured idea #N` confirmation), all in ONE branch (A product, or B internal/UX).",
         "Each idea has a clear title and a body with at least one sentence of detail — for Branch A, one line of in-world lore (who/what it is); for Branch B, what the rough edge is and what 'better' looks like.",

package/scripts/gds/provision.js

@@ -169,6 +169,10 @@ const CONFIG = {
   sshOpts: process.env.PROVISION_SSH_OPTS || '-o BatchMode=yes -o StrictHostKeyChecking=accept-new',
 };
 
+// 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 MAX_INTENT_ATTEMPTS = numEnv('PROVISION_INTENT_MAX_ATTEMPTS', 3);
 
 // Manifest-placement verification budget (task 1002720 / QA-walk F23): a child
@@ -709,7 +713,7 @@ async function scaffoldStandaloneRepo(inst, deps) {
       writeFile(giPath, INSTANCE_GITIGNORE);
     }
     exec(`git -C ${root} config user.name "Cloud Bongos"`);
-    exec(`git -C ${root} config user.email "bot@cloudbongos.com"`);
+    exec(`git -C ${root} config user.email "${provisionerBotEmail()}"`);
     exec(`git -C ${root} add -A`);
     const commitMsg = mode === 'adopt'
       ? `chore: adopt Cloud Bongos onto ${inst.slug} on a pinned @bongos/core ${coreV} (provision.js, ADR 0121)`
@@ -939,7 +943,7 @@ function buildCorePinRefreshCommit({ root, fromVersion, toVersion, repo, ownerTo
   return {
     config: [
       `git -C ${root} config user.name "Cloud Bongos"`,
-      `git -C ${root} config user.email "bot@cloudbongos.com"`,
+      `git -C ${root} config user.email "${provisionerBotEmail()}"`,
     ],
     add: `git -C ${root} add -A`,
     commit: `git -C ${root} commit -m "${msg}"`,
@@ -2477,7 +2481,7 @@ async function main() {
 if (require.main === module) main();
 
 module.exports = {
-  CONFIG, MAX_INTENT_ATTEMPTS,
+  CONFIG, MAX_INTENT_ATTEMPTS, provisionerBotEmail,
   // pure step generators (tested directly)
   dbName, dbCreateCmd, migrateCmd, seedFirstVersionCmd, serviceUnit, serviceUnitPath, webEnvBody, webEnvPath,
   backupUnitName, backupServicePath, backupTimerPath, backupScriptPath, backupService, backupTimer,