3 · Credentials & branding

TL;DR

Objective — lock the account before anything public ships: rotate the default admin login, upload a coherent brand kit, resolve the server PHP binary, then strip the vendor’s demo content — because the default creds are a security hole and fake testimonials are a legal one.

User part + done-when

👤 User part — log into the running app to change the admin email + password, click through the asset uploads in the panel, and approve the generated logos/hero images; an agent runs the audits, greps, and updateOrCreate writes but can’t click “Save” in a browser for you.

Done when creds are rotated on every DB (old ones dead), the brand kit is uploaded and verified in incognito, STAGING_PHP_BIN is persisted, and curl of staging returns 0 demo markers.  ·  ⏱ 90–180 min  ·  🔀 mixed (👤 panel + approvals, 🤖 audits + writes).

Background

This page is the MUST core of Phase 6. It does four things, in this order, and the order is not negotiable: rotate the admin credentials, produce the brand asset kit, resolve the server PHP binary, then strip the vendor’s demo content. Skipping the rotation or the demo-content audit are both ship-blockers — the first is a security hole, the second is a legal one. Everything here reads from the brand profile you built on the previous page. If _CUSTOMIZATIONS.md → ## Project Brand Profile is incomplete, stop and finish it — these tasks are “read the row, apply the value”, not “decide the value now”.

flowchart LR
    R["1 · Rotate creds<br/>(security first)"] --> A["2 · Brand assets<br/>(generate kit)"]
    A --> U["3 · Upload identity<br/>(config branding)"]
    U --> P["4 · PHP binary<br/>(SSH prereq)"]
    P --> D["5 · Demo content<br/>(replace, don't delete)"]
    classDef must fill:#0d7b6e22,stroke:#0d7b6e;
    classDef warn fill:#f4a26122,stroke:#f4a261;
    class R,U,D must;
    class A,P warn;

Steps

1. Rotate the admin credentials

Do this FIRST — before any other configuration

Default credentials (e.g. superadmin@example.com / 123456) are published in CodeCanyon documentation. Anyone who knows the script name can log in. Herd’s herd share can expose a .test site publicly in one click, so “it’s only local” is not a defence.

The email/password change happens in the running app’s profile page — a person logging into the panel. The agent can audit and store secrets, but the panel form itself is human-driven (or a clipboard-bridged Playwright pass).

Who does this

👤 User changes the admin email + password in the running app’s Profile / Account Settings — a logged-in browser action only a person (or a clipboard-bridged Playwright pass) completes.

1. Change the email. Admin → Profile / Account Settings (the exact path is in your vendor-capabilities.md § Admin menus; commonly /user/profile on Jetstream apps). Change from the vendor’s example.com address to a real inbox you control — you need it for password resets.

   • ✅ The admin email is a real inbox you control, not the vendor’s example.com.

2. Change the password. Same page → Change Password. Use a generated 20+ char password. Save it to your password manager and credentials.md before you submit.

   • ✅ A 20+ char password is set and already saved to the vault before submit.

Configure SMTP before you lock yourself out

If you change the email and then forget the new password, you need working email (page 4) to receive a reset. Either do SMTP first, or guarantee the new password is stored before saving.

The installer seeds demo users independently in every database (local, staging, production) — audit each one. Pick whichever query path your environment supports; the only invalid choice is “skip it because I have no SQL client”.

1. List every user via tinker (the universal fallback — works on any machine where the app runs).

   php artisan tinker --execute="\
     App\Models\User::select('id','name','email')->get()->each(function(\$u){
       echo \$u->id.'|'.\$u->email.'|'.\$u->name.PHP_EOL;
     });"
   # Expected: one id|email|name line per user

   • ✅ Every user row prints, so demo/test identities are visible.

2. List users on staging / production over SSH (respects the User model + soft-deletes).

   dep ssh staging "cd ~/domains/staging.[DOMAIN]/deploy/current && \
     php artisan tinker --execute=\"
       \App\Models\User::select('id','name','email')->get()->each(function(\$u){
         echo \$u->id.'|'.\$u->email.'|'.\$u->name.PHP_EOL;
       });
     \" 2>&1 | grep -v '^$'"
   # Expected: the same id|email|name listing, from the remote DB

   • ✅ For each result: delete demo/test identities (demo@example.com, Emma Holden, etc.), rotate the password on any account you keep, and record the action in credentials.md.

Store the new secret correctly — two valid homes, never leaving a rotated password only in /tmp/ or the clipboard:

• 1Password (preferred): op item edit "superadmin" --vault "[PROJECT]-Local" "username=…" "password=…". If op vault list doesn’t show your vault and op vault get returns 403 Forbidden, a service account lacks per-vault access — grant it in the web UI (Integrations → service account → Vaults → Add), or fall back to credentials.md.
• credentials.md (fallback): edit with Python, not sed/echo — passwords contain $ / + & ! that break shell escaping. Mark old defaults as “rotated”, don’t delete them — the audit trail shows which environments still need work.

If you fall back to credentials.md, fix the header AND add the TODO

Most credentials.md templates ship with a header that claims “all passwords in 1Password” as the aspirational policy. Add plaintext entries without updating that header and the file lies to every future reader. Pair every plaintext entry with two edits: a dated state warning at the top, and a migration TODO at the bottom.

Header — paste at the top of credentials.md:

# Credentials

> **⚠️ Current state ([YYYY-MM-DD]):** Staging superadmin password stored as
> plaintext in this file — temporary until the 1Password service account is
> granted access to the [PROJECT] vault. See the TODO at the bottom.

> **Storage policy:** Passwords should live in 1Password → [PROJECT] vault.
> This file is the fallback when the 1Password CLI cannot reach a vault.
> Gitignored via Admin-Local/1-Project/2-ProjectVault/.gitignore.

TODO — paste at the bottom of credentials.md:

---
## TODO — Migrate to 1Password

- [ ] Grant 1Password service account access to the [PROJECT] vault
- [ ] Move `Superadmin (Staging)` password to a 1Password item
- [ ] Move `Superadmin (Local)` password to a 1Password item
- [ ] Replace plaintext blocks with `op://` references
- [ ] Remove the "Current state" warning from the header

When the TODO is done, the warning disappears, the entries become op:// references, and the header’s “all passwords in 1Password” claim becomes true again.

Default credentials live in the database, not the code, so every environment with its own DB needs its own rotation — local included.

Environment	When	Tracking entry	Entropy — and why
Local dev	Phase 3, or earliest Phase 6 touch	Superadmin (Local)	12 chars, pronounceable — typed often
Staging	This task	Superadmin (Staging)	24 chars, random — never typed
Production	Phase 12, after first deploy + installer	Superadmin (Production)	24 chars, random — stored in the vault

If you copy the staging DB → production at deploy time, production inherits the staging password and needs no separate rotation. Document which path you took.

Do NOT skip local on the grounds that “.test is private”

Herd Pro’s herd share creates a public HTTPS tunnel to any .test site in one click. Demo the app to a client, QA from your phone, or leave a tunnel running overnight, and the default superadmin@example.com / 123456 is live on the public internet. Rotate all environments; only the entropy differs.

For AI-assisted rotation, use the clipboard bridge so the password never becomes a tool parameter (passing it as a browser_type argument leaks it into the tool-call log and transcript). The password lives in a 600-mode file, is loaded into the OS clipboard, and is read by in-browser JS.

1. Generate the password, load it to the clipboard via Python (no shell expansion of `$ ! “).

   python3 - <<'PY'
   import secrets, pathlib, subprocess
   alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
   pwd = "".join(secrets.choice(alphabet) for _ in range(24))
   pathlib.Path("/tmp/new_admin_pass.txt").write_text(pwd + "\n")
   subprocess.run(["pbcopy"], input=pwd, text=True, check=True)
   print(f"loaded ({len(pwd)} chars)")
   PY
   # Expected: "loaded (24 chars)" — the value is never printed

   • ✅ The clipboard holds exactly 24 characters; only the length was printed.

Then in Playwright’s browser_evaluate (not browser_type), read navigator.clipboard.readText(), set the three password fields via the prototype value setter (so Vue/React/Livewire bindings fire), and return only lengths + a match boolean — never the value.

Re-load the clipboard in the SAME tool call as the browser read

The OS clipboard is volatile shared state — anything can overwrite it between your pbcopy and the browser_evaluate that reads it: macOS Universal Clipboard syncing from another Apple device, a clipboard manager (Paste / Raycast / Alfred / Maccy) cycling history, another tool call that runs | pbcopy as a side effect, or the browser re-populating stale clipboard state on focus. One run hit exactly this — pbcopy ran once at the top of the task, and 8 bash commands later the clipboard held 734 chars instead of the expected length. The fix is a discipline rule, not a technical one.

✅ Do — re-load, then read immediately, no intervening bash:

1. Re-load the clipboard from the 600-mode file (Python pbcopy, same call or the one immediately before the browser read) → confirm the printed length is correct.
2. browser_evaluate(navigator.clipboard.readText()) immediately after, with no intervening tool calls, and verify pwd.length === 24 inside the browser read (not wc -c, which counts the temp file’s trailing newline).
3. Click Save / submit the form.

❌ Don’t — load once, drift for several tool calls, then read:

Step 1: Load clipboard at start of task
Step 2: Navigate browser
Step 3: Take snapshot
Step 4: Find form fields
Step 5: Read clipboard in browser  ← stale now, 4 tool calls later

If the length the browser reads doesn’t match what you loaded, stop and re-load — never paste the wrong value into a password field, or you lock yourself out of the admin account.

After saving, clear everything: printf '' | pbcopy and shred -uz /tmp/new_admin_pass.txt. Then verify it actually took — don’t trust in-page success text (Jetstream’s only signal is the fields emptying). The reliable check: log out, confirm old credentials fail, confirm new credentials work. A successful change invalidates the session, so navigating to any auth-required page should redirect to /login — that redirect is the proof. If the dashboard still loads, the change did not work. (Jetstream logout is POST-only; GET /logout returns 405.)

2. Generate the brand asset kit

Skip if

The vendor ships complete default branding and the customer accepts it, or a designer is providing custom assets. Otherwise generate a coherent set now (~10–15 min, ~$2–3) rather than hunting stock images mid-deploy.

If your project has the image-gen toolchain wired (brand-profile + deployment-map from Phase 1B), the pipeline produces everything section 3 of this page and the landing page need:

Step	Output	Cost
Source logos	3 SVGs (square / horizontal / vertical)	~$0.24
Derive variants	12 SVGs (light / dark / mono / inverted × 3)	$0 (pure SVG)
Favicons	16→1024 PNGs + .ico + site.webmanifest	$0
Hero / feature imagery	per-scene PNGs	~$0.039 each
Icons	MIT-licensed (Lucide via CDN)	$0
Deploy	copies to vendor paths per asset-deployment-map.json	$0

Two human approval gates are built in — the agent pauses, a person reviews, then responds.

Who does this

👤 User reviews the 3 source logos (recognizable at 16×16? monochrome-safe? on-brand colours?) and the first 3 hero images (style matches the logo? no AI-slop artifacts? overlay-friendly?), responding approve / regenerate: <feedback> / abort — a taste judgment only a person makes.

1. Pass both human approval gates before the pipeline deploys assets.

   • ✅ The 3 source logos and first 3 hero images were each answered approve, regenerate: <feedback>, or abort.

Sync the deployment map with what the capabilities survey found

The capabilities survey (page 2) discovered the exact image paths your vendor reads. If the Phase 1B deployment map disagrees, update it before deploying assets — otherwise you’ll copy logos where the admin panel can’t find them and section 3 below will fail.

No toolchain? Resize a single master with ImageMagick (magick "$MASTER" -resize ${size}x${size} …) into the sizes the panel asks for, build the multi-size favicon with -define icon:auto-resize=16,32,48,64, and make the Apple touch icon at 180×180 with no transparency (-background white -alpha remove). Commit the kit under Admin-Local/1-Project/0-Brand/assets/ (same tree as Phase 8 · Brand kit); keep machine-readable inputs in Admin-Local/1-Project/0-Brand/brand-profile.json.

3. Upload identity & branding

Narrow scope — this is CONFIG branding only

This covers the ~5–10 admin settings fields: logos, favicon, app name, company info, currency, timezone, locale. It does not cover vendor demo content (hero copy, testimonials, FAQs) — that’s section 5. Finishing this section does not make the landing page customer-ready.

Most CodeCanyon apps cluster these under one Settings → App / Settings → Branding tab. These are panel uploads and field edits — a person clicking through the admin UI (or a Playwright pass driving it).

Who does this

👤 User fills the identity/company fields and uploads each logo/favicon in the admin panel — browser uploads and form saves only a person (or a driven Playwright session) completes.

1. Fill app identity in Settings → App.

   Admin field	Brand-profile source	Notes
   App name	Identity → App name	Exact capitalization — shows everywhere
   Tagline	Identity → Tagline	≤80 chars — mobile truncates
   Timezone	App settings → Timezone	IANA, e.g. Asia/Dubai
   Default currency	App settings → Currency	ISO 4217 — also drives Stripe
   Default locale	App settings → Locale	e.g. en_AE, ar_AE
   First day of week	App settings → First day	Sunday ME/US, Monday EU/Asia

   • ✅ App name, tagline, timezone, currency, locale, and first-day are set from the brand profile.

2. Fill company information (feeds invoices, PDF exports, email footers).

   • Required: legal entity name (matches business registration), company address (use registered, not residential).

   • Recommended: support email (support@[domain]), website URL.

   • Optional: support phone, registration number, VAT/Tax ID, founding year.

   • ✅ Legal entity name and address are real (no placeholder); a grep-able REPLACE_ME_* marks any required-but-unknown field.

3. Collect every asset variant before uploading, then upload in the typical Froiden-family order.

   Asset	Light	Dark	Size	Format
   Main logo (wide)	✅	✅	~400×100	SVG / transparent PNG
   Logo square / icon	✅	✅	512×512	SVG / PNG
   Login logo	✅	✅	~300×80	transparent PNG
   Email header logo	✅	—	~600×150	PNG (SVG fails in email)
   Invoice / PDF logo	✅	—	300×100	PNG 300 DPI
   Favicon	one	—	32×32	ICO / SVG
   Apple touch icon	one	—	180×180	PNG, no transparency
   PWA icon	one	—	512×512	PNG
   OG / social preview	one	—	1200×630	PNG / JPG

   Typical upload order: main logo light → dark → favicon → login logo (often a separate sub-tab) → email logo (Settings → Email) → app/PWA icon → invoice logo (Settings → Finance). After each upload click Save, refresh, and confirm the preview updates — some panels silently reject non-PNG or >500KB files.

   • ✅ Every variant uploaded; each save refreshed and confirmed (no silent reject).

Don’t invent placeholder data

If a field is required but you have no real value, use a grep-able placeholder like REPLACE_ME_PHONE — never a fake number (555-0123). Fakes get baked into the first customer’s invoice. Run grep REPLACE_ME pre-launch to find everything still pending.

Verify in incognito at desktop + mobile breakpoints: logo in header (light + dark), favicon in tab, logo on /login, logo on a sample invoice, and the og:image meta tag in the landing page <head>. If the app uses a service worker, a new favicon may stay cached up to 24h — bump the PWA manifest version and note it in _CUSTOMIZATIONS.md so you don’t chase a ghost.

4. Resolve the server PHP binary (SSH prerequisite)

Required before any SSH artisan command in Phase 6+

On shared hosting the SSH default /usr/bin/php is often a different version than the app needs. A bare php artisan config:clear can run on the wrong PHP minor, print a Composer warning, and run anyway — poisoning the config cache with a half-broken parse. Always use the explicit binary that deploy.php uses.

Resolve it once and persist it so every later page (theme/error publishing, SMTP test, payment config) reuses it.

1. Reuse the path deploy.php already captured, and verify it runs the required version.

   PHP_BIN=$(grep "set('bin/php'" deploy.php | grep -oE "/[^'\"]+/php" | head -1)
   dep ssh staging "test -x $PHP_BIN && $PHP_BIN -v | head -1"   # expect the version composer.json requires
   # Expected: the PHP version line composer.json requires

   • ✅ $PHP_BIN is executable and prints the version composer.json requires.

2. If deploy.php has none, probe the known CloudLinux / Hostinger paths.

   dep ssh staging 'for p in /opt/alt/php83/usr/bin/php /opt/cpanel/ea-php83/root/usr/bin/php /usr/local/bin/php83 /usr/bin/php; do
     [ -x "$p" ] && echo "  $p → $($p -v 2>/dev/null | head -1)"; done'
   # Expected: each existing binary path with its version

   • ✅ A correct PHP binary path is identified.

3. Persist it for future sessions/phases.

   grep -q "STAGING_PHP_BIN" CLAUDE.local.md 2>/dev/null || \
     printf '\n## Server PHP binaries (Phase 6 prerequisite)\n- STAGING_PHP_BIN: %s\n- PRODUCTION_PHP_BIN: [fill in when Phase 12 runs]\n' \
       "$PHP_BIN" >> CLAUDE.local.md
   # Expected: the binary path is written to CLAUDE.local.md (idempotent)

   • ✅ STAGING_PHP_BIN is recorded in CLAUDE.local.md.

From here on, no bare php over SSH

Every SSH artisan command in this phase uses $PHP_BIN, never bare php. If you spot bare php artisan inside an SSH block, replace it with the resolved path.

5. Audit & replace demo content

Ship-blocker — never skip the audit

Vendor demo content on a public URL is a branding problem (looks unfinished) and a legal one — fake testimonials like “Michael Davis, Owner of Greenview Residency” violate FTC/EU/UK/UAE advertising law. You may defer replacement of individual blocks (document them for Phase 9), but fake testimonials must be removed or replaced unconditionally, and the audit itself is never optional once staging is publicly reachable.

Apply the same three-source protocol from page 2, scoped to content.

1. Inventory demo content from seeders and content tables.

   # Codebase — seeders
   grep -rn "Faker\|demo\|seed" database/seeders/ 2>/dev/null | head -30
   # DB schema — content tables
   mysql -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
     "SHOW TABLES LIKE '%review%'; SHOW TABLES LIKE '%testimonial%'; SHOW TABLES LIKE '%faq%'; SHOW TABLES LIKE '%feature%'; SHOW TABLES LIKE '%price%';"
   # Expected: seeder hits + the content tables (reviews/testimonials/faqs/features/prices)

   • ✅ A table in _CUSTOMIZATIONS.md records Category | Table | Current state | Decision (replace/remove/defer) | Target source.

Deleting demo rows is almost never enough — two mechanisms silently undo it:

flowchart TD
    Del["You DELETE the<br/>demo testimonial row"] --> T1{"Observer bound to<br/>language / tenant / setting?"}
    T1 -->|Yes| Re["Next activation re-inserts<br/>the fake row"]
    Del --> T2{"Blade @else falls back<br/>to @lang('landing.*')?"}
    T2 -->|Yes| Lang["Page renders the SAME<br/>fake name from lang/*.php"]
    Re --> Fix["✅ REPLACE via updateOrCreate<br/>on the vendor's exact key"]
    Lang --> Fix2["✅ ALSO hide the @else block<br/>(3-file deviation pattern)"]
    classDef bad fill:#e6394622,stroke:#e63946;
    classDef good fill:#0d7b6e22,stroke:#0d7b6e;
    class Re,Lang bad;
    class Fix,Fix2 good;

1. Scan for both mechanisms before touching anything.

   ls app/Observers/ 2>/dev/null                                  # observer re-seeding (Froiden family)
   grep -rn "firstOrCreate\|updateOrCreate" app/Observers/*.php 2>/dev/null
   grep -rn "@else" resources/views/ | head -30                   # blade fallbacks
   grep -rn "@lang('landing\|@lang('home" resources/views/ | head -30
   cat lang/en/landing.php 2>/dev/null | head -50                 # hardcoded demo strings
   # Expected: any re-seeding observers + blade @else fallbacks + hardcoded lang strings

   • ✅ Each category is classified as DB-only, blade-fallback-only, or both in a new “Source classification” column.

2. Replace fake testimonials with updateOrCreate, keyed on the vendor’s exact primary key (usually id, or language_code + slot_index).

   php artisan tinker --execute="
   \App\Models\FrontReviewSetting::updateOrCreate(
     ['id' => 1],
     ['reviewer_name' => '[PROJECT] beta customer (pending permission)',
      'content' => '[Real testimonial pending — replace or hide the section]']
   );
   echo 'rows: ' . \App\Models\FrontReviewSetting::count();
   "
   curl -sS https://staging.[DOMAIN] | grep -c "Michael Davis\|Greenview\|Lakeside"   # expect 0
   # Expected: a rows count, then 0 fake-name matches in the rendered page

   • ✅ The fake testimonial is replaced (not deleted); the curl count is 0. If it still matches, the blade @else fallback is rendering the fake name — hide that block with an attributed comment wrapper ({{-- [PROJECT] Phase 6 — hidden pending real content --}}).

For each remaining category (hero, features, FAQs): replace now (read the Livewire form → read the model → updateOrCreate for bulk, or drive the admin form via Playwright if there are post-save hooks → screenshot-verify → document the UI path), or defer to Phase 9 by logging it in the task ledger with the current placeholder. For more than a few rows, persist a script at Admin-Local/1-Project/4-Scripts/Content/DemoContentCleanup/ (with --dry-run + rollback) rather than nesting tinker inside SSH.

1. Verify the replacement survives an observer trigger.

   curl -sS https://staging.[DOMAIN] | grep -iE "lorem ipsum|john doe|jane smith|faker"   # expect nothing
   # Expected: no output — no demo markers remain

   • ✅ No demo markers render. Then fire the seeding observer once (activate/deactivate a language, or create/delete a tenant) and re-render — your replacement still holds. If a new demo row appears alongside yours, your updateOrCreate key didn’t match the observer’s — fix the key and re-run.

6. Audit tracking files for infra-path drift

Why now

Phase 6 touches infrastructure paths — the shared .env location, admin URLs, credential homes, server PHP binary, and vendor gotchas. Any file that references those can drift from reality: CLAUDE.md, CLAUDE.local.md, credentials.md, _CUSTOMIZATIONS.md, DECISIONS.md, ProjectCard.md. Run the audit now, while the correct values are fresh.

1. Run the drift scan — pull path and alias references, then cross-check against deploy.php and ~/.ssh/config.

   grep -rhnE '/home/[a-zA-Z0-9_-]+/domains/[^ "`]+|~/domains/[^ "`]+|/opt/alt/[^ "`]+' \
       CLAUDE.md CLAUDE.local.md \
       Admin-Local/1-Project/2-ProjectVault/credentials.md \
       Admin-Local/1-Project/1-ProjectInfo/ProjectCard.md \
       _CUSTOMIZATIONS.md DECISIONS.md 2>/dev/null | sort -u
   
   grep -E "deploy_path|domains/" deploy.php 2>/dev/null | head -10
   grep -B1 -A5 "Host.*[Ss]taging\|Host.*[Pp]roduction" ~/.ssh/config 2>/dev/null
   # Expected: tracked references next to the deploy.php / ssh-config truth

   • ✅ Tracking-file references are visible next to authoritative values.

2. Resolve each finding by type, then commit the fixes.

   Drift type	Action
   Wrong absolute path	Fix immediately — it will mislead debugging
   Stale credentials reference	Update to match the rotation tracking
   Stale domain name	Fix immediately
   Outdated vendor gotcha	Update the entry; link the vendor changelog
   Dead external link	Update to current URL, or archive via archive.org

   • ✅ Every drift finding is fixed and committed.

Cadence

Run the full scan at the end of each infrastructure phase, after server/domain changes, after credential rotation, and quarterly. Leave a marker:

> **Last tracking audit:** [YYYY-MM-DD] (end of Phase 6)
> **Next scheduled audit:** [YYYY-MM-DD] (quarterly)

Checklist

Do not mark this step done until every box below is checked.

• 👤 Creds rotated — admin email + password rotated on every environment with a DB; old credentials confirmed dead; new secret stored in 1Password or credentials.md (header fixed if plaintext).
• 🔀 Users audited — demo/test users deleted, kept users re-passworded, audit logged in credentials.md.
• 👤 Branding uploaded — brand asset kit generated/collected and uploaded; logo, favicon, login logo, invoice logo, and og:image all verified in incognito (light + dark, desktop + mobile).
• 🤖 PHP binary resolved — STAGING_PHP_BIN resolved and persisted to CLAUDE.local.md.
• 🔀 Demo content handled — inventoried; observer + blade-@else traps scanned; fake testimonials replaced (not deleted); replacement verified to survive an observer trigger.
• 🤖 Staging clean — curl of the staging landing page returns 0 demo markers; deferred blocks logged for Phase 9.

→Next step

4 · Email (SMTP)