setup:full Supabase slug uses stale app.config.js; rename does not update apps/mobile branding

[ZappoMan]

Summary

During npm run setup:full, the supabase phase suggests project slugs like beakerstack-staging even after the identity phase successfully renames the product (e.g. to "NewApp") via npm run rename.

Two related problems:

1. readSupabaseProjectSlugBase() reads apps/mobile/app.config.js, which still contains template defaults (name: 'Beaker Stack', slug: 'beaker-stack') after rename.
2. npm run rename only walks adopter/ and does not update apps/mobile/app.config.js, so mobile Expo identity (name, slug, scheme, bundle IDs) stays on the template values unless adopters edit it manually.

The identity phase and supabase phase therefore disagree about the product name.

Steps to reproduce

1. Fork/use the template and run npm run setup:full.
2. At identity, enter a new display name (e.g. NewApp) and choose N for full npm-scope rebrand (--preserve-upstream).
3. Proceed to the supabase phase.

Actual behavior

Setup logs:

[setup] Default new Supabase project slug per tier: beakerstack-<staging|production|preview> (from apps/mobile/app.config.js; same word rules as rename).

Meanwhile adopter/config/branding.ts correctly shows the new name (e.g. displayName: 'NewApp', flatName: 'newapp'), because rename only processes files under adopter/.

Expected behavior

After a successful identity/rename step, the supabase phase should suggest slugs derived from the canonical adopter branding (e.g. newapp-staging), consistent with:

• detectRepoIdentity() in scripts/lib/detect-repo-identity.mjs, which reads adopter/config/branding.ts first
• The comment on readSupabaseProjectSlugBase() claiming it uses "same word rules as rename"

Adopters should not need to manually fix apps/mobile/app.config.js before Supabase project creation to get sensible default slugs.

Root cause

Supabase slug source (scripts/setup-full.mjs):

async function readSupabaseProjectSlugBase() {
  const text = await fs.readFile(MOBILE_APP_CONFIG, 'utf8'); // apps/mobile/app.config.js
  const nameM = text.match(/\bname:\s*['"]([^'"]+)['"]/);
  // ...
}

Rename scope (scripts/rename-project.mjs):

const files = await walkDirectory(path.join(repoRoot, 'adopter'));

Rename updates adopter/config/branding.ts but not apps/mobile/app.config.js. Docs in docs/renaming.md still describe renaming "bundle IDs, slugs" across the repo, but the script no longer reaches apps/mobile/.

Impact

• Misleading default Supabase project names during first-time cloud setup
• Confusing UX right after a successful rename ("Rename complete" → immediately offered beakerstack-* slugs)
• apps/mobile/app.config.js remains out of sync with adopter branding unless adopters follow the manual checklist in docs/BRANDING.md

Suggested fix

Pick one or combine:

1. Setup: Change readSupabaseProjectSlugBase() to prefer adopter/config/branding.ts (flatName or slug), reusing detectRepoIdentity() / readBrandingSource(), with app.config.js as fallback only.
2. Rename: Extend rename (or a post-rename sync step) to patch apps/mobile/app.config.js fields (name, slug, scheme, bundle/package identifiers) from adopter branding variants — at least for display name and slug.
3. Docs: If app.config.js is intentionally adopter-maintained, update docs/renaming.md and the setup log message so they don't imply rename/setup keeps them in sync.

Workaround (adopters)

• Override the slug at the [tier] project name slug [...] prompt when creating projects, or
• Manually edit apps/mobile/app.config.js before the supabase phase, or
• Re-run: npm run setup:full -- --from=supabase after fixing app.config.js