8 · Deep codebase audit

TL;DR

Objective — run a deeper codebase audit while staging is live and the stakes are low: project structure, composer security audit, Git hygiene, FVDUT storage persistence, secret + debug-code scans (with the word-boundary fix for dd()), storage-tracked-file triage, CodeCanyon frontend anti-patterns, and an optional schema audit — so every finding caught here is one that doesn’t surface in production.

User part + done-when

👤 User part — none: this audit is entirely terminal-runnable (grep/composer/git/ssh). A person only decides which backlog findings become actual fixes.

Done when structure is verified, composer audit is clean of Critical/High, Git history is free of vendor//node_modules//.env, storage persistence is confirmed, secret + debug scans are clear, storage/-tracked files are triaged, frontend anti-patterns are logged, and any fixes are redeployed.  ·  ⏱ ~1–2 hr  ·  🤖 agent-runnable.

Background

Staging is the right moment for a thorough codebase audit: the app is deployed and verifiable, but no real users depend on it. Work top to bottom; most findings become backlog items, a few are real fixes you redeploy.

Authority vs this page (don’t triplicate audits)

This is the staging-time deep pass (word-boundary dd() scan, git history, FVDUT). Phase 10 · Static audit is the pre-launch authority — run it again before sign-off to confirm production matches the audited commit. Don’t restate a weaker copy in Phase 10; cross-reference this page for debug/history checks Phase 10 omits.

Where this page sits in the phase:

🟡 SHOULD — recommended, not a phase gate

The Phase 5 gate (page 6) already passed. This is a deeper pass best done while staging is live and the stakes are low — every finding caught here is one that doesn’t surface in production.

flowchart LR
  Staging[Staging deploy live] --> Deep[Deep pass on this page]
  Deep --> Backlog[Most findings → backlog]
  Deep --> Fix[Few fixes → redeploy]
  Deep --> P10[Phase 10 static audit re-verify]

Steps

1. Verify project structure

Confirm the standard Laravel layout, the artisan version, and the vault .gitignore.

1. List the standard directories and the vault ignore.

   ls -la app/ config/ database/ public/ resources/ routes/ storage/
   ls -la artisan composer.json package.json .env.example
   php artisan --version
   cat Admin-Local/1-Project/2-ProjectVault/.gitignore   # expect `*` and `!.gitignore`
   # Expected: all standard dirs/files exist; Laravel version prints; vault ignores all but itself

   • ✅ All standard directories/files exist, Laravel version prints, and the vault .gitignore ignores everything but itself.

2. Composer security audit

Surface known vulnerabilities in dependencies, fix the urgent ones, and re-verify.

1. Run the audit.

   composer audit
   # Expected: a list of advisories (or "No security vulnerability advisories found")

   • ✅ The audit output is reviewed against the severity table.

2. Fix and re-verify the urgent advisories.

   composer update vendor/package && composer audit   # fix + re-verify
   git add composer.json composer.lock && git commit -m "Security: update packages for vulnerability fixes"
   # Expected: re-audit shows the fixed advisory gone; the lockfile change is committed

   • ✅ Critical/High advisories are resolved and the lockfile change is committed.

Triage by severity:

Severity	Action
Critical	Update immediately
High	Update before launch
Medium	Update soon
Low	Track for next release

3. Git hygiene

Confirm secrets and heavy trees never entered history.

1. Scan history for vendor/, node_modules/, and .env.

   git log --all --full-history -- vendor/ | head -5         # expect empty
   git log --all --full-history -- node_modules/ | head -5   # expect empty
   git log --all --full-history -- .env | head -5            # expect empty
   git log --all --full-history -- ".env.*" | head -5        # expect empty (except .env.example)
   # Expected: all four scans return empty (apart from .env.example)

   • ✅ vendor/, node_modules/, and .env are absent from Git history.

.env in Git history = rotate everything, then scrub

If .env ever appears in history, every credential it held is compromised. Rotate all of them first — DB, mail, API keys, APP_KEY — because scrubbing history does not un-leak anything already pushed.

After rotating, remove the file from history:

pip install git-filter-repo
git filter-repo --path .env --invert-paths
# Then force-push every branch — coordinate with the team first; this rewrites shared history.

Rotation is the real fix; the scrub is hygiene. Never force-push a shared branch without telling collaborators — they must re-clone or hard-reset afterward.

4. Storage persistence (FVDUT)

FVDUT = Files, Vendors, Directories, Uploads, Temp — folders that must survive a release swap via shared_dirs.

1. Confirm shared_dirs covers storage + uploads, and symlinks are present.

   grep -A10 "shared_dirs" deploy.php                  # expect `storage` + any custom upload dirs
   ls -la public/ | grep "^l"                          # local symlinks present
   ssh <staging-alias> "ls -la ~/domains/staging.yourapp.com/deploy/current/public/ | grep '^l'"
   # Expected: shared_dirs lists storage + uploads; symlinks present locally and on the server

   • ✅ shared_dirs persists storage + uploads and symlinks are present on both ends.

5. Secret + debug-code scans

Scan app code for hardcoded credentials and leftover debug calls.

1. Scan for secrets, debug code, and confirm APP_DEBUG=false.

   grep -rn "password\s*=" --include="*.php" app/ config/ | grep -v ".env\|example\|fake\|test" | head
   grep -rn "api_key\|apikey\|secret_key" --include="*.php" app/ config/ | grep -v ".env\|example" | head
   grep -rn "://.*:.*@" --include="*.php" app/ config/ | head        # credentials in URLs
   
   # Debug code — word-boundary regex so `->add(` does NOT false-positive on `dd(`
   grep -rnE "(^|[^a-zA-Z_>])(dd|dump|var_dump|print_r)\(" --include="*.php" app/ | head
   grep -rn "console.log" resources/js/ | head
   
   ssh <staging-alias> "grep APP_DEBUG ~/domains/staging.yourapp.com/deploy/shared/.env"   # expect false
   # Expected: no hardcoded secrets, no real debug calls in shipped paths, APP_DEBUG=false

   • ✅ No hardcoded secrets, no debug code in staging paths, and APP_DEBUG=false.

Why the debug grep uses word boundaries

A naive grep "dd(\|dump(" matches the substring dd( anywhere — flagging legitimate $validator->errors()->add(...) and Carbon::now()->add(...) as “debug code.” The ERE above requires dd/dump/etc. to be preceded by start-of-line or a non-identifier character, ruling out ->add(. No ERE support? Use rg '\bdd\(|\bdump\(|\bvar_dump\('.

A related noise source is the server log itself when you scan it for real errors:

Filter your own noise from the log scan

When scanning staging’s laravel.log for real errors, window it to the last ~15 minutes so you don’t panic over exceptions you caused with tinker/SSH during the deploy session:

CUTOFF=$(date -u -v-15M +"%Y-%m-%d %H:%M:%S" 2>/dev/null || date -u -d "15 minutes ago" +"%Y-%m-%d %H:%M:%S")
ssh <staging-alias> "awk -v c='$CUTOFF' '/^\[[0-9]{4}-/{ts=substr(\$0,2,19);keep=(ts>c)} keep' \
  ~/domains/staging.yourapp.com/deploy/current/storage/logs/laravel.log" | grep -iE 'error|exception|fatal' | tail

6. Triage files tracked in storage/

Files committed under storage/ are ambiguous: Deployer replaces storage/ with a symlink to shared/storage/, so tracked files never reach the running app — but vendor packages often write runtime config to storage_path('<file>'), and deleting those breaks the package silently. This scan is investigation only; the default action for every file is KEEP.

1. List tracked storage/ files and search for their references.

   git ls-files storage/ | grep -vE '\.gitkeep$|\.gitignore$|^storage/installed$'
   # For each suspect, search reads AND writes across vendor/packages/app:
   #   B=$(basename <FILE>)
   #   grep -rnE "$B|storage_path.*$B|file_put_contents.*$B|->put\(.*$B" vendor/ packages/ app/ config/ routes/
   # Expected: a list of suspect files; default action for each is KEEP

   • ✅ Each tracked storage/ file is triaged (default KEEP) using the reference table.

Classify each suspect:

Reference found in	Action
vendor/ or packages/	KEEP + add to shared_files
app/ / config/ / project code	KEEP + shared_files (or move out of storage/)
Nowhere	Default KEEP; remove only if certain it has no vendor origin — and log it
Uncertain	KEEP + shared_files

Empty content is not proof, and never both lists

An empty []/{}/"" file may still be written by a vendor on first use — a matching file_put_contents/->put() means KEEP. And a file may be in shared_files or inside a shared_dirs directory, never both — listing a storage/ file in shared_files triggers Too many levels of symbolic links at deploy:shared.

7. CodeCanyon frontend anti-patterns

None block a deploy; all are worth logging as VENDOR/Frontend backlog items.

1. Scan for global SDKs, unguarded charts, duplicate includes, and double-registered service workers.

   # Global third-party SDKs that should be route-scoped
   grep -rln "js.stripe.com\|paypal.com/sdk\|checkout.razorpay.com" resources/views/layouts/ resources/views/components/ 2>/dev/null
   # Charts (check for empty-state guards)
   grep -rln "ApexCharts\|Chart.js\|echarts\|chartist" resources/views/ 2>/dev/null
   # Duplicate framework includes
   grep -rcn "@livewireScripts\|livewire.min.js" resources/views/ 2>/dev/null
   # Service worker double-registration
   grep -rn "serviceWorker.register" resources/views/ public/ 2>/dev/null
   # Expected: hits become VENDOR/Frontend backlog items (none block the deploy)

   • ✅ Any anti-pattern hits are logged as VENDOR/Frontend backlog items.

Fixes: scope payment SDKs to checkout via @stack('scripts'); guard charts with @if($data->count()) + a “no data” fallback; keep @livewireScripts in the root layout only; register the service worker once.

8. Schema audit (optional)

Inspect the staging schema with Atlas or a free tool and categorize tables so you know what’s safe to touch.

1. Inspect and categorize the staging tables.

   With Atlas or a free tool (mysqldump --no-data, TablePlus, DBeaver), inspect the staging schema and categorize tables.

   • ✅ Tables are categorized so you know what’s safe to modify.

Category rules:

Category	Examples	Rule
Core vendor	users, settings, payments	NEVER modify
Plugin / feature	ai_*, chat_*, blog_*	Check vendor docs first
Laravel system	migrations, jobs, cache	NEVER modify
Custom (_zaj)	users_zaj, custom_*	Yours — safe to modify

Optional — connect staging to Bytebase for schema review

Beyond mysqldump --no-data plus free GUIs (TablePlus, DBeaver, phpMyAdmin), some teams register staging in Bytebase for change review. First-time setup is dashboard work:

1. Enable Remote MySQL in the hosting panel.
2. Add the Bytebase Cloud IP to the Remote MySQL allowlist. Get the current Cloud IP from the Bytebase dashboard — do not hardcode it.
3. Copy host / port / database / username / password from the hosting panel.
4. In Bytebase Cloud: Settings → Instances → Add Instance, configure, and test the connection.

This is user/dashboard work, not agent-runnable. Skip entirely if you use a local GUI.

9. Database performance baseline (optional)

Capture a DB performance baseline and surface obvious slow queries / N+1 patterns before any real traffic arrives — every slow path caught here is one you don’t debug live.

Keep the password out of ps aux and history

Inline -p<pass> leaks the password to every other user on the box. Prefer a mode-600 ~/.my.cnf; the commands below show explicit flags for clarity only.

1. Check the slow query log and threshold.

   ssh <staging-alias> "mysql -e \"SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';\""
   ssh <staging-alias> "tail -100 /var/log/mysql/mysql-slow.log 2>/dev/null \
     || echo 'Slow query log not accessible on shared hosting — use EXPLAIN on hot queries instead'"
   # Expected: the log's on/off state + threshold, or a fallback note for shared hosting

   • ✅ You know whether the slow query log is available.

2. EXPLAIN a hot query and list the largest tables.

   ssh <staging-alias> "mysql DB_NAME -e \"EXPLAIN SELECT * FROM HOT_TABLE WHERE HOT_COL = 1 LIMIT 10;\""
   ssh <staging-alias> "mysql -e \"SELECT table_name, table_rows FROM information_schema.tables \
     WHERE table_schema=DATABASE() ORDER BY table_rows DESC LIMIT 10;\""
   # Expected: hot table uses an index (`key` is not NULL); top tables are recorded

   • ✅ Hot tables use indexes and the heaviest tables are recorded.

If Debugbar or Telescope is installed on staging, hit the dashboard and two or three list pages as an authenticated user and record: no single query > 1s, no N+1 pattern, hot tables show key used in EXPLAIN, and average page query count is reasonable.

Record in ProjectLog (DATABASE/Performance): homepage query count ___, dashboard query count ___, slowest observed query ___ ms.

10. Deploy any fixes

Commit any real fixes found above and redeploy.

1. Commit and redeploy the audit fixes.

   git add . && git commit -m "Audit: investigation fixes — <describe>"
   git push origin staging && dep deploy staging
   # Expected: fixes committed, pushed, and redeployed to staging

   • ✅ Any audit fixes are committed and redeployed.

Checklist

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

• 🤖 Structure + audit — structure verified; composer audit clean of Critical/High.
• 🤖 Git history clean — vendor/, node_modules/, .env absent from Git history.
• 🤖 Storage persists — shared_dirs persists storage + uploads; symlinks present on server.
• 🤖 No secrets / debug — no hardcoded secrets; no debug code in staging paths; APP_DEBUG=false.
• 🤖 Triage + anti-patterns — storage/-tracked files triaged (default KEEP); frontend anti-patterns logged.
• 🤖 Fixes redeployed — any fixes committed and redeployed.

→Next step

Atlas Cloud (optional)