@bongos/core 1.21.14 → 1.21.16

package/docs/recipes/upgrading-the-core.md

@@ -222,6 +222,7 @@ running a go-live.
 ## Gotchas
 
 - **The Deploy door fixes three known snags by itself, once** (task 1004448, `scripts/gds/wedge-remedy.js`). When a core move through `/deploy` fails on a **dirty tree** (it commits the tracked changes inside the project), a **full disk** (it prunes that project's own nightly dumps down to the newest 7) or a **database behind its code** (it migrates that database with its own `PGDATABASE` before the code moves), the runner applies the fix, records a `core-upgrade-remedy` event on the project, and tries the move once more on the next tick. If the retry fails for the same reason, or the fix itself fails, the move is retired as `unknown` (`remedy_did_not_hold` / `remedy_failed`) for a person — never a second fix. The manual fixes below still apply to the unattended nightly sweep, which does not go through the door.
+- **A core move uses TWO unix accounts, and which one does what is not interchangeable** (task 1004512, `resolveRunAs` in `scripts/gds/provision-core-upgrade.js`). The move runs as the account that owns the checkout — the app user, on every hosting shape — because everything it writes lives there: the pin, `node_modules`, `.claude/`, the pin commit, and the `git status` it starts with. Only the **database** steps (identity pre-check, migrate, the ledger insert) run as the project's own `bongos-<slug>` account, handed over with `--migrate-as`; that account owns the database and `PUBLIC` has no `CONNECT`, so nothing else can reach it. The flag is emitted only when the two differ, so a control plane and a project older than ADR 0281 run the command they always did. *The symptom when this is wrong:* every move on a project with its own account fails with `fatal: detected dubious ownership in repository`, which the clean-tree pre-flight used to report as a dirty tree — the remedy below then commits a tree nobody touched and the retry fails identically. A `git status` that could not answer is now its own reason (`git_unreadable`, class `unknown`), so it goes to a person instead of to that fix. **Do not "fix" a recurrence with `safe.directory`** — git would then read the tree and the next write step would fail instead.
 - **A Deploy-door move nobody can fix files a blocker and posts to Discord — once** (task 1004449, `scripts/gds/move-escalation.js`). A move retired as `unknown` (including `remedy_did_not_hold`, `remedy_failed` and a failed rollback) files one blocker (`source=provisioning`, `source_ref=core-move:<instance id>:<intent id>`) with the reason and what the move reported, and posts one notice to `#ship-news` that names the project only if it is public. The next core move on that project that lands closes the blocker by itself and posts an all-clear. Refusals the owner can act on (`needs_decision`) are shown on the deploy page instead, not filed.
 - **`--registry` needs no credential at all** (task 1003878). `@bongos/core` is **public** on npm (task 1003872), so `bongos upgrade --registry` resolves it from the default registry like any other dependency — no token, no login, and no instance `.npmrc`. An install failure on this path is therefore a *real* failure (network, registry outage, or a version that was never published), never a missing credential.
   *History, so the symptom is recognisable on an old instance:* the core used to publish private, and the instance `.npmrc` read `_authToken=<redacted> npm gives that per-project key precedence, so with the env var unset it expanded EMPTY and **masked a perfectly valid literal token in `~/.npmrc`** — npm went anonymous, the private core 404'd, and the error blamed a credential the box actually held. Task 1002754 worked around it by resolving the token in-process; task 1003878 deleted the whole mechanism along with the `.npmrc` that caused it. An instance still carrying a committed `.npmrc` from a pre-1003878 scaffold can safely delete it.

package/modules/hall-ui/public/deploy.js

@@ -142,6 +142,9 @@
     not_published: 'that version is not published yet',
     npm_install: 'installing the new core stopped part-way',
     dirty_tree: 'the project had unsaved file changes on its machine',
+    // Deliberately not a variant of dirty_tree above: nothing is known about the files here,
+    // which is the whole difference (task 1004512).
+    git_unreadable: 'the project’s files could not be read on its machine, so the move never started — nothing changed, and someone is looking at it',
     disk_full: 'the machine ran out of disk space',
     schema_pending: 'the project’s database was behind its code',
     outside_channel: 'that version is outside this project’s update rule',

package/modules/public-landing/public/account.html

@@ -104,7 +104,7 @@
     <!-- the identity chip IS the profile trigger; paintBar fills it from GET /me.
          Signed out it stays hidden and the sign-in door takes its slot. -->
     <button class="trig who" type="button" id="who" data-menu="profile" aria-expanded="false" aria-controls="menuProfile" hidden><img id="whoImg" alt="" hidden><span class="whoName" id="whoLogin"></span><svg class="cv" viewBox="0 0 20 20" aria-hidden="true"><path d="m5.6 8 4.4 4.4L14.4 8"/></svg></button>
-    <a class="signinDoor" id="signinTop" hidden href="/api/bongos/auth/web/start?return=/account">Sign in</a>
+    <a class="signinDoor" id="signinTop" hidden href="/api/bongos/auth/web/start?return=/account&amp;repos=1">Sign in</a>
   </div>
 </header>
 
@@ -138,7 +138,7 @@
   <section class="aDoor" id="door" hidden aria-labelledby="door-h">
     <h2 class="vh" id="door-h">Sign in</h2>
     <p>Sign in with GitHub to change your handle, your bio and links, and who can find you.</p>
-    <a class="btn" id="signin" href="/api/bongos/auth/web/start?return=/account">
+    <a class="btn" id="signin" href="/api/bongos/auth/web/start?return=/account&amp;repos=1">
       <!-- keep the spaces inside this path's numbers: same shape, and they are load-bearing (task 1004401) -->
       <svg class="gh" viewBox="0 0 16 16" aria-hidden="true"><path d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23 .82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2 .82.64-.18 1.32-.27 2-.27s1.36.09 2 .27c1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12 .51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29 .25.54.73 .54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15 .46.55.38A8.01 8.01 0 0 0 16 8c0-4.42-3.58-8-8-8z"/></svg>
       Sign in with GitHub

package/modules/public-landing/public/account.probes.json

@@ -5,7 +5,7 @@
   "probes": [
     { "name": "signed out: the door, and sign-in returns to /account", "auth": false, "width": 1440,
       "steps": [["wait", 300]],
-      "expect": { "visible": ["#door"], "hidden": ["#acctBody"], "href": [["#signin", "/api/bongos/auth/web/start?return=/account"]] } },
+      "expect": { "visible": ["#door"], "hidden": ["#acctBody"], "href": [["#signin", "/api/bongos/auth/web/start?return=/account&repos=1"]] } },
     { "name": "signed in: nothing changed saves nothing", "auth": true, "width": 1440,
       "steps": [["wait", 400], ["click", "#profileSave"], ["wait", 150]],
       "expect": { "text": [["#profileMsg", "Nothing has changed."]] } },
@@ -56,7 +56,7 @@
       "expect": { "closed": "#menuProjects" } },
     { "name": "signed out: no chip, the sign-in door in its slot, returning to /account", "auth": false, "width": 1440,
       "steps": [["wait", 300]],
-      "expect": { "hidden": ["#who"], "visible": ["#signinTop", "#projTrig"], "href": [["#signinTop", "/api/bongos/auth/web/start?return=/account"]] } },
+      "expect": { "hidden": ["#who"], "visible": ["#signinTop", "#projTrig"], "href": [["#signinTop", "/api/bongos/auth/web/start?return=/account&repos=1"]] } },
     { "name": "signed out the Projects band is Sky / Table / New project (no Your projects)", "continue": true,
       "steps": [["click", "#projTrig"], ["wait", 120]],
       "expect": { "open": "#menuProjects", "count": [["#menuProjects .bandCell:not([hidden])", 3]], "hidden": ["#mineCell"] } },

package/modules/public-landing/public/index.html

@@ -673,7 +673,7 @@ composition A; landing composition v3, picked by the owner 2026-08-27. No roll,
     <!-- the identity slot: the sign-in door signed out; the chip (the profile trigger) once
          the session resolves — swapped client-side, never a wrong-state flash -->
     <span class="whoSlot" id="who">
-      <a class="pill signin" href="/api/bongos/auth/web/start?return=/">Sign in</a>
+      <a class="pill signin" href="/api/bongos/auth/web/start?return=/&amp;repos=1">Sign in</a>
     </span>
   </div>
 </header>

package/modules/public-landing/public/projects.html

@@ -705,7 +705,7 @@ summary{min-height:24px;padding:3px 0;}
     <!-- the identity chip IS the profile trigger; renderWho fills it. Signed
          out it does not exist and the sign-in door takes its slot. -->
     <button class="trig who" type="button" id="who" data-menu="profile" aria-expanded="false" aria-controls="menuProfile" hidden></button>
-    <a class="signinDoor" id="signinTop" hidden href="/api/bongos/auth/web/start?return=/projects">Sign in</a>
+    <a class="signinDoor" id="signinTop" hidden href="/api/bongos/auth/web/start?return=/projects&amp;repos=1">Sign in</a>
   </div>
 </header>
 
@@ -897,7 +897,7 @@ summary{min-height:24px;padding:3px 0;}
            /create, listing your own instances needs no repo scope) -->
       <section id="gate" hidden>
         <p class="lede">Every project you own, in one place — its live status, its address, and the controls that matter. Sign in with GitHub to see yours.</p>
-        <a class="btn" id="signin" href="/api/bongos/auth/web/start?return=/projects%3Fview%3Dmine">
+        <a class="btn" id="signin" href="/api/bongos/auth/web/start?return=/projects%3Fview%3Dmine&amp;repos=1">
           <svg class="gh" viewBox="0 0 16 16" aria-hidden="true"><path d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27s1.36.09 2 .27c1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.01 8.01 0 0 0 16 8c0-4.42-3.58-8-8-8z"/></svg>
           Sign in with GitHub
         </a>
@@ -999,7 +999,7 @@ summary{min-height:24px;padding:3px 0;}
     <!-- signed out: the same identity-only door the mine view uses (ADR 0143) -->
     <section id="mGate" class="card" hidden>
       <p class="lede">This is a project’s management page — it answers only to the person who owns it. Sign in with GitHub to open yours.</p>
-      <a class="btn" id="mSignin" href="/api/bongos/auth/web/start?return=/projects%3Fview%3Dmine">
+      <a class="btn" id="mSignin" href="/api/bongos/auth/web/start?return=/projects%3Fview%3Dmine&amp;repos=1">
         <svg class="gh" viewBox="0 0 16 16" aria-hidden="true"><path d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27s1.36.09 2 .27c1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.01 8.01 0 0 0 16 8c0-4.42-3.58-8-8-8z"/></svg>
         Sign in with GitHub
       </a>
@@ -1395,7 +1395,8 @@ summary{min-height:24px;padding:3px 0;}
             <!-- The wizard's own sign-in opts into repo scope (read:user + repo, ADR 0155) up
                  front (&repos=1) — anyone here intends to create a project, which needs repo
                  access, so we ask once at sign-in instead of a second "Connect" step later.
-                 Hall + CLI sign-in stay identity-only (ADR 0143 least-privilege default). -->
+                 Every hub sign-in door does the same since ADR 0364; the hall + CLI
+                 sign-ins stay identity-only (ADR 0143 least-privilege default). -->
             <a class="btn big" id="wizSignin" href="/api/bongos/auth/web/start?return=/projects%3Fview%3Dnew&amp;repos=1">
               <svg class="gh" viewBox="0 0 16 16" aria-hidden="true"><path d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27s1.36.09 2 .27c1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.01 8.01 0 0 0 16 8c0-4.42-3.58-8-8-8z"/></svg>
               Continue with GitHub
@@ -2494,11 +2495,12 @@ summary{min-height:24px;padding:3px 0;}
       else history.replaceState(null, '', '?view=' + v + idPart);
     } catch (e) {}
     if (v !== 'manage') document.title = BASE_TITLE;
-    /* the shell's sign-in door returns the visitor to the view they left, and
-       carries the repo scope when that view is the wizard (ADR 0143: the
-       create path asks once up front instead of a second consent at Home) */
+    /* the shell's sign-in door returns the visitor to the view they left. Every
+       sign-in door on the hub's own pages carries the repo scope (task 1004549,
+       ADR 0364): it is asked once, at sign-in, and held for the whole session, so
+       no flow ever stops halfway to ask for it */
     $('signinTop').href = '/api/bongos/auth/web/start?return=/projects%3Fview%3D' + v +
-      idPart.replace('&', '%26').replace('=', '%3D') + (v === 'new' ? '&repos=1' : '');
+      idPart.replace('&', '%26').replace('=', '%3D') + '&repos=1';
     /* the mine view is the only one that polls; it re-reads on entry so a
        card that changed while you were on the map is not stale — including
        the membership + invitations lists (task 1003774), the same re-read
@@ -7190,8 +7192,15 @@ summary{min-height:24px;padding:3px 0;}
     function enter(focus) {
       if (authKnown && !me) { show(0, !!focus); return; }
       var created = authKnown ? createdRecord() : null;
-      if (created && created.id) { enterCreated(created, !!focus); return; }
-      paintResumeOffer(null);
+      /* A draft part-way through the wizard (steps 1–5) beside a stored create is a
+         SECOND project being typed. A reload or a GitHub round-trip (repo access) is
+         that same visit continuing, so the draft keeps its place and the earlier
+         project stays one click away on the resume line — it used to land on the
+         earlier project's done panel, dropping the founder out of the draft
+         (task 1004549). A deliberate nav still goes through enterCreated. */
+      var draftInFlight = state.step >= 1 && state.step <= 5;
+      if (created && created.id && (focus || !draftInFlight || resumeIntent)) { enterCreated(created, !!focus); return; }
+      paintResumeOffer(created && created.id ? created : null);
       /* before identity settles, never render past step 1 (the fork and its terms
          tick, since task 1004504): deeper steps carry authenticated side effects (the Home-step repo
          probe), and onAuth() re-enters to the real draft step the moment /me answers */
@@ -7345,8 +7354,8 @@ summary{min-height:24px;padding:3px 0;}
   function jsonOrEmpty(res) { return res.json().catch(function () { return {}; }); }
 
   function signInAgain() {
-    /* from the wizard, the re-sign-in keeps the repo scope it already granted */
-    var back = currentView === 'new' ? '/projects%3Fview%3Dnew&amp;repos=1' : '/projects';
+    /* the re-sign-in keeps the repo scope, like every hub sign-in door (ADR 0364) */
+    var back = (currentView === 'new' ? '/projects%3Fview%3Dnew' : '/projects') + '&amp;repos=1';
     return 'Your session expired — <a href="' + API + '/auth/web/start?return=' + back + '">sign in again</a>.';
   }
 
@@ -7948,7 +7957,7 @@ summary{min-height:24px;padding:3px 0;}
      in hand so "checked Xm ago" keeps telling the truth (C6). ── */
 
   function manageSignin() {
-    return API + '/auth/web/start?return=' +
+    return API + '/auth/web/start?repos=1&return=' +
       encodeURIComponent('/projects?view=manage&id=' + manageId);
   }
 

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.21.14",
+  "version": "1.21.16",
   "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/release-notes.json

@@ -8840,5 +8840,17 @@
       "id": "1004537",
       "text": "Autobongos no longer picks tasks that can only be done by logging into a live server. They are skipped before any claim and listed as \"needs_host_access\", so no more wasted runs and pointless owner blockers."
     }
+  ],
+  "1.21.15": [
+    {
+      "id": "1004512",
+      "text": "Deploying a core update to a project that runs under its own account used to fail every time, blaming unsaved file changes that were never there. The update now writes files as the account that owns them and touches the databa"
+    }
+  ],
+  "1.21.16": [
+    {
+      "id": "1004549",
+      "text": "Signing in on cloudbongos.com now asks GitHub for repo access once and keeps it while you stay signed in, so project setup no longer stops to ask — and a trip to GitHub mid-setup brings you back exactly where you were."
+    }
   ]
 }

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

@@ -319,8 +319,8 @@ async function coreUpgradeInstance(inst, deps, intent) {
   // The preview probes; the move must probe identically or the two commands diverge on
   // the one field task 1004121 exists to keep identical. Skipped when !apply, where the
   // command is printed and never run — a plan should not spend a subprocess per tick.
-  const { runAs } = resolveRunAs(inst, deps, { probe: apply });
-  const { cmd, runDir } = upgradeInvocation(inst, to, { privileged, requestedBy, selfRoot, runAs });
+  const { runAs, migrateAs } = resolveRunAs(inst, deps, { probe: apply });
+  const { cmd, runDir } = upgradeInvocation(inst, to, { privileged, requestedBy, selfRoot, runAs, migrateAs });
 
   if (!apply) {
     // A --dry-run runner tick used to only PRINT this command. It now runs the CLI's own
@@ -571,7 +571,24 @@ function parsePreflight(out) {
 }
 
 /**
- * Which unix account should this instance's upgrade run as? Asks the box (task 1004128).
+ * Which unix accounts does this instance's upgrade need? Asks the box (task 1004128).
+ *
+ * TWO ANSWERS, NOT ONE (task 1004512). Task 1004128 asked a single question — "which
+ * account does this instance run as?" — and ran the WHOLE move as it. That is right for
+ * the database and wrong for the files, and the two have different owners on every
+ * project provisioned since task 1003369:
+ *
+ *   • `runAs` — the account that owns the CHECKOUT, which is the app user on every
+ *     hosting shape (provision-repo.js scaffolds /srv/<base>/<slug> as the runner, and
+ *     grantInstanceRepoReadCmd gives the project's own account group READ, nothing more).
+ *     Everything the move writes — the pin, node_modules, .claude/, the pin commit — and
+ *     the `git status` it starts with, belong to this account. Running them as the
+ *     project's account is what made every such move die on `fatal: detected dubious
+ *     ownership in repository` and report a dirty tree that did not exist.
+ *   • `migrateAs` — the project's OWN account, which is also its Postgres login role
+ *     (provision-repo.js instanceDbRole); its database is owned by that role with CONNECT
+ *     revoked from PUBLIC, so this is the only identity that can migrate it. That is where
+ *     the isolation of task 1003369 actually lives, and it is kept.
  *
  * 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
@@ -580,13 +597,15 @@ function parsePreflight(out) {
  * tenant leg has been broken.
  *
  * Falling back is NOT a privilege escalation: an instance with no account of its own is
- * 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.
+ * already running as the app user (its unit says so), so this migrates as precisely the
+ * account that owns 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. On that shape the two answers coincide and the move is byte-for-
+ * byte what it was before this task.
  */
 function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
-  if (inst.hosting_shape === 'control-plane') return { runAs: appUser(), fellBack: false };
+  const owner = appUser(); // owns the checkout on every shape — see above
+  if (inst.hosting_shape === 'control-plane') return { runAs: owner, migrateAs: owner, 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.
@@ -594,7 +613,7 @@ function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
     throw new Error(`resolveRunAs: refusing to probe an account for invalid slug ${JSON.stringify(inst && inst.slug)}`);
   }
   const wanted = instanceUser(inst);
-  if (!allowProbe) return { runAs: wanted, fellBack: false };
+  if (!allowProbe) return { runAs: owner, migrateAs: wanted, fellBack: false };
   // THE SAME EXECUTOR THE UPGRADE ITSELF WILL USE. Every sibling here picks
   // `standalone ? (controlExec || exec) : exec`, because under PROVISION_REMOTE_HOST
   // (ADR 0130) `exec` is the REMOTE ssh executor while `controlExec` stays local. A
@@ -604,7 +623,7 @@ function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
   const boxExec = inst.hosting_shape === 'cloud-host' ? (deps.controlExec || deps.exec) : deps.exec;
   const r = boxExec(`id -u ${wanted}`, { allowFail: true });
   const failed = !r || r.softFailed === true || r.ok === false;
-  if (!failed) return { runAs: wanted, fellBack: false };
+  if (!failed) return { runAs: owner, migrateAs: wanted, fellBack: false };
   // ONLY A DEFINITIVE "no such user" JUSTIFIES THE FALLBACK. A probe that could not
   // answer — an exec timeout, an NSS hiccup — must not silently narrow the per-instance
   // isolation of task 1003369 for this operation. So an inconclusive probe keeps the
@@ -612,9 +631,9 @@ function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
   // task a failure now carries the reason instead of "the dry run did not complete".
   const said = `${(r && r.stdout) || ''}\n${(r && r.stderr) || ''}`;
   if (!/no such user|unknown user/i.test(said)) {
-    return { runAs: wanted, fellBack: false, probeInconclusive: true };
+    return { runAs: owner, migrateAs: wanted, fellBack: false, probeInconclusive: true };
   }
-  return { runAs: appUser(), fellBack: true, wanted };
+  return { runAs: owner, migrateAs: owner, fellBack: true, wanted };
 }
 
 // ONE BUILDER FOR BOTH LEGS (task 1004121).
@@ -630,7 +649,7 @@ function resolveRunAs(inst, deps, { probe: allowProbe = true } = {}) {
 // HERE rather than left to instanceUser()'s own throw: that throw is correct today, but
 // a call site whose safety depends on a helper's internals is one refactor away from a
 // shell-injection path (and the apply leg's own guard sits at the route, not here).
-function upgradeInvocation(inst, to, { privileged = false, dryRun = false, requestedBy = '', selfRoot = selfInstanceRoot, runAs = null } = {}) {
+function upgradeInvocation(inst, to, { privileged = false, dryRun = false, requestedBy = '', selfRoot = selfInstanceRoot, runAs = null, migrateAs = null } = {}) {
   if (!isValidSlug(inst && inst.slug)) {
     throw new Error(`upgradeInvocation: refusing to build a shell command from an invalid slug ${JSON.stringify(inst && inst.slug)}`);
   }
@@ -665,11 +684,22 @@ 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' ? appUser() : instanceUser(inst));
+  //
+  // AND WHICH ACCOUNT DOES WHAT (task 1004512). `account` runs the move; `dbAccount` runs
+  // its three database steps. They differ on exactly the projects that have an account of
+  // their own, because the checkout is the app user's and the database is theirs —
+  // resolveRunAs above argues the split. `--migrate-as` is emitted ONLY when they differ,
+  // so a control plane and a pre-1003369 project produce the command they always did.
+  const account = runAs || appUser();
+  const dbAccount = migrateAs || (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}`,
-    instanceDir === REPO_ROOT ? '' : `--instance ${instanceDir}`];  // REPO_ROOT is where the CLI runs (runDir below)
+    instanceDir === REPO_ROOT ? '' : `--instance ${instanceDir}`,  // REPO_ROOT is where the CLI runs (runDir below)
+    // SHARED, not in the tail: the dry run's own database pre-check connects as this
+    // account too, so a preview that omitted it would test a different identity than the
+    // move — the exact drift one builder for both legs exists to prevent.
+    dbAccount === account ? '' : `--migrate-as ${dbAccount}`];
   const tail = dryRun
     ? ['--dry-run']
     : [`--service ${inst.slug}`,
@@ -681,7 +711,7 @@ function upgradeInvocation(inst, to, { privileged = false, dryRun = false, reque
       hubPushesPin(inst) ? '--pin-no-push' : '',
       requestedBy ? `--requested-by ${requestedBy}` : '',
       requestedBy ? '--upgrade-source owner-control' : ''];
-  return { cmd: [...shared, ...tail].filter(Boolean).join(' '), runDir: REPO_ROOT, instanceDir, runAs: account };
+  return { cmd: [...shared, ...tail].filter(Boolean).join(' '), runDir: REPO_ROOT, instanceDir, runAs: account, migrateAs: dbAccount };
 }
 
 // Ask the upgrade CLI what it WOULD do, changing nothing. `allowFail` because a refusal
@@ -692,8 +722,8 @@ function preflightUpgrade(inst, to, deps) {
   // A distinct local name: `deps.selfInstanceRoot || selfInstanceRoot` with a const of
   // the same name would TDZ-shadow the import and crash every uninjected call.
   const selfRoot = deps.selfInstanceRoot || selfInstanceRoot;
-  const { runAs, fellBack, wanted } = resolveRunAs(inst, deps);
-  const { cmd, runDir } = upgradeInvocation(inst, to, { privileged, dryRun: true, selfRoot, runAs });
+  const { runAs, migrateAs, fellBack, wanted } = resolveRunAs(inst, deps);
+  const { cmd, runDir } = upgradeInvocation(inst, to, { privileged, dryRun: true, selfRoot, runAs, migrateAs });
   const r = boxExec(cmd, { cwd: runDir, allowFail: true });
   const out = `${(r && r.stdout) || ''}\n${(r && r.stderr) || ''}`;
   const { checks, error } = parsePreflight(out);
@@ -709,10 +739,12 @@ function preflightUpgrade(inst, to, deps) {
   const raw = out.trim().split('\n').filter(Boolean).slice(-4).join('\n').slice(0, 600);
   const why = error || (raw || null);
   const note = fellBack
-    ? `ran as ${runAs} — this instance has no ${wanted} account yet (it predates the per-instance account model)`
+    ? `migrated as ${migrateAs} — this instance has no ${wanted} account yet (it predates the per-instance account model)`
     : null;
   return {
-    target: to, ok, lines: checks, ran_as: runAs, account_note: note,
+    // Both accounts, because since task 1004512 there are two and "which user did this run
+    // as" has no single answer: `ran_as` writes the files, `migrated_as` touches the database.
+    target: to, ok, lines: checks, ran_as: runAs, migrated_as: migrateAs, account_note: note,
     error: ok ? null : (why || 'the dry run did not complete, and said nothing this could report'),
   };
 }

package/scripts/gds/upgrade-migrate.js

@@ -1,8 +1,9 @@
 'use strict';
 
-// scripts/gds/upgrade-migrate.js — WHICH command `bongos upgrade` migrates an instance
-// with (task 1004274, found preparing the task 1004047 catch-up pass). Kept out of
-// upgrade.js, which sits at the 1500-line cap.
+// scripts/gds/upgrade-migrate.js — the DATABASE side of a core move: which command
+// migrates this instance (task 1004274, found preparing the task 1004047 catch-up pass),
+// WHICH ACCOUNT that command runs as, and whether that account can reach the database at
+// all (task 1004512). Kept out of upgrade.js, which sits at the 1500-line cap.
 //
 // THE GAP. upgrade.js migrated with `npm run migrate`, and that only works where the
 // instance's package.json DECLARES a migrate script. A greenfield scaffold always does
@@ -26,6 +27,7 @@
 
 const fs = require('node:fs');
 const path = require('node:path');
+const { spawnSync } = require('node:child_process');
 
 // Relative to the instance root, POSIX on purpose: it is an argument to bash, and it
 // must stay byte-identical to the scaffold's script (tests/upgrade_migrate.mjs pins it
@@ -64,4 +66,99 @@ function migratePlan(instanceDir, { fsImpl = fs, env = process.env } = {}) {
   };
 }
 
-module.exports = { migratePlan, CORE_MIGRATE_SCRIPT };
+// ---- which ACCOUNT the database work runs as (task 1004512) -----------------
+//
+// THE BUG THIS EXISTS FOR. A core move on a project provisioned since task 1003369 ran
+// the WHOLE of upgrade.js as the project's own `bongos-<slug>` account. That account only
+// READS the checkout (provision-repo.js grantInstanceRepoReadCmd adds it to the app user's
+// group; /srv/<base>/<slug> is owned by the app user), so the move died at its very first
+// step: `git status` refused with `fatal: detected dubious ownership in repository`, the
+// clean-tree pre-flight reported "working tree not clean", and the self-heal chain
+// committed a tree that was never dirty and retried into the identical failure. Every move
+// on such a project ended in a blocker, and the dirt it named did not exist. Had git been
+// appeased, `npm install`, the pin commit and the .claude materialization — all WRITES to a
+// checkout that account cannot write — would have failed next.
+//
+// SO THE MOVE IS SPLIT, rather than papered over with a `safe.directory` entry:
+//   • everything that touches the CHECKOUT runs as the account that owns it (the app
+//     user) — that is also what pushUpgradePin and the wedge remedy's `git` already do;
+//   • everything that touches the DATABASE runs as the project's own account, which is
+//     where the isolation actually lives: it is the project's Postgres login role
+//     (provision-repo.js instanceDbRole), the database is owned by it, and CONNECT is
+//     revoked from PUBLIC — so the app user cannot reach it even by accident.
+//
+// The runner passes `--migrate-as <account>` ONLY when the two differ. A control plane and
+// a project old enough to still run as the app user emit no flag and behave exactly as
+// they did before, which is the half of the fleet that was already working.
+//
+// Narrower than a unix account name may legally be, on purpose: the value arrives on a
+// command line and is refused rather than quoted if it falls outside. ONE copy for the
+// upgrade CLI — wedge-remedy.js imports this rather than re-declaring it, because two
+// copies of a security predicate drift one edit at a time. provision-repo.js keeps its own
+// UNIX_ACCOUNT_RE: that file is the control-plane provisioner and nothing it does should
+// depend on the upgrade CLI, so the duplication there buys a layer boundary.
+const ACCOUNT_RE = /^[a-z_][a-z0-9_-]{0,31}$/;
+
+/**
+ * `cmd args` as `account`, or unchanged when there is no account to drop to. PURE.
+ *
+ * argv form, never a shell string, so nothing here is quoted or interpolated. `sudo -n`
+ * because a sudoers rule that would PROMPT must fail fast: an upgrade runs unattended and
+ * a password prompt nobody can answer would hang the deploy rather than fail it.
+ *
+ * sudo resets the environment, so the variables migrate genuinely needs are re-stated as
+ * `env K=V` arguments: PGDATABASE (migrate.sh defaults to production when it is unset, so
+ * it is always passed and never inherited) and, for the core-script fallback, INIT_CWD
+ * (which is how migrate.sh finds the instance — task 2180).
+ */
+function asAccount(account, cmd, args, extraEnv = {}, env = process.env) {
+  if (!account) return { cmd, args };
+  if (!ACCOUNT_RE.test(String(account))) throw new Error(`asAccount: ${JSON.stringify(account)} is not a unix account name`);
+  const carry = { ...(env.PGDATABASE ? { PGDATABASE: env.PGDATABASE } : {}), ...extraEnv };
+  const pairs = Object.entries(carry).map(([k, v]) => `${k}=${v}`);
+  return { cmd: 'sudo', args: ['-n', '-u', account, 'env', ...pairs, cmd, ...args] };
+}
+
+// migrate.sh reaches Postgres over the local socket as the CURRENT OS USER (peer
+// auth) — so running an upgrade under `sudo` connects as `root`, which usually has
+// no Postgres role. The failure surfaces mid-run as a raw
+// `FATAL: role "root" does not exist`, AFTER the pin has already moved, which then
+// triggers the whole auto-rollback dance for what is really an operator mistake.
+// This names it up front instead (task 1002712). `account` (task 1004512) makes the
+// probe connect as whoever migrate will, so the pre-flight and the migration cannot
+// disagree about which role is being tested.
+function preflightDbIdentity({ instanceDir, db, account = null }, run = spawnSync) {
+  const q = asAccount(account, 'psql', ['-tAc', 'select 1'], db ? { PGDATABASE: db } : {});
+  const r = run(q.cmd, q.args, {
+    cwd: instanceDir, encoding: 'utf8',
+    env: { ...process.env, ...(db ? { PGDATABASE: db } : {}) },
+  });
+  if (!r || r.error) return { ok: true, skipped: 'psql not on PATH — leaving it to migrate' };
+  if (r.status === 0) return { ok: true };
+
+  const out = `${r.stderr || ''}${r.stdout || ''}`;
+  // The escalation itself not working is this pre-flight's business, not migrate's (task
+  // 1004512). Soft-skipping it would let the pin move and then fail at migrate for the one
+  // reason that was knowable up front, costing a full rollback — the exact shape the
+  // role-does-not-exist check below exists to avoid. Only ever reachable with an account.
+  if (account && /^sudo:/m.test(out)) {
+    return { ok: false, reason: `the database steps cannot run as "${account}" — sudo refused.\n`
+      + `    ${out.trim().split('\n').find((l) => l.startsWith('sudo:')) || ''}\n`
+      + `    The move writes files as the account that owns the checkout and hands only the\n`
+      + `    database to the project's own account (--migrate-as), so the first needs\n`
+      + `    passwordless sudo to the second. Checked BEFORE the pin moves.` };
+  }
+  const m = out.match(/role "([^"]+)" does not exist/i);
+  if (!m) return { ok: true, skipped: 'psql failed for another reason — leaving it to migrate' };
+  return {
+    ok: false,
+    role: m[1],
+    reason: `Postgres has no role "${m[1]}" — migrate would fail after the pin moved.\n`
+      + `    migrate.sh connects over the local socket as the CURRENT OS USER. Running the\n`
+      + `    upgrade under sudo connects as root, which is almost never a Postgres role.\n`
+      + `    Re-run as the user that owns the instance (e.g. sudo -u <owner> …), passing the\n`
+      + `    npm token through if the core comes from the registry.`,
+  };
+}
+
+module.exports = { migratePlan, preflightDbIdentity, asAccount, ACCOUNT_RE, CORE_MIGRATE_SCRIPT };

package/scripts/gds/upgrade-outcome.js

@@ -45,6 +45,11 @@ const REASON_CLASS = Object.freeze({
   schema_pending: 'known_wedge', // the database is behind the code it runs NOW (task 1004448)
   // upgrade.js refusals, before the pin moves
   dirty_tree: 'known_wedge',
+  // git REFUSED to read the checkout, so nothing is known about the tree (task 1004512).
+  // Deliberately NOT known_wedge: the dirty_tree remedy commits whatever git reports, and
+  // here git reported nothing — the live shape is `detected dubious ownership`, a tree that
+  // was never dirty. The fix is which ACCOUNT the move runs as, which no remedy can apply.
+  git_unreadable: 'unknown',
   downgrade: 'needs_decision',
   artist_gate: 'needs_decision',
   module_incompatible: 'needs_decision',
@@ -73,6 +78,7 @@ const UPGRADE_REASONS = [
   [/no space left on device|ENOSPC/i, 'disk_full'],
   [/^refusing to DOWNGRADE/, 'downgrade'],
   [/^already on /, 'already_on'],
+  [/^git could not read the working tree/, 'git_unreadable'],
   [/^working tree not clean/, 'dirty_tree'],
   [/^module pre-check failed/, 'module_incompatible'],
   [/^cannot determine which database/, 'db_unresolvable'],