LocalBoost AI

1. Use a dedicated test host or VM with a separate database and per-project hostname. Do not point any snapshot at production databases, queues, mailboxes, payment accounts or customer channels.
2. Obtain named read-only GitHub access through the repository owner’s access process. Use your normal authenticated Git workflow; never embed access tokens in clone URLs or documents.
3. Check out the exact commit shown in the project guide. Keep the working copy and evidence logs separate from the local documentation folder.
4. Verify every recorded file against the source manifest before making local changes. The manifest covers every other prepared file; its own hash and the Git commit should be recorded separately.
5. Provision a PHP runtime satisfying composer.json and composer.lock, a reviewed Composer installation, required PHP extensions and a web server serving only public/. Use MySQL with pdo_mysql for the seven browser installers. Exact database server compatibility remains a test item.
6. Create empty writable bootstrap/cache and storage runtime directories from the included placeholders. Give the application service account the required write access; do not make the entire code tree globally writable.
7. Resolve the project-specific assets/build gap and obtain approved schema/anonymized fixtures where required. Do not copy an old release’s vendor, assets, database or .env into this snapshot without provenance and version checks.

Clone and pin each repository

Each project section gives the exact commands. A new source checkout is recommended so existing local application changes cannot be overwritten. The clone destination must be empty.

Verify prepared file hashes in PowerShell

Run from the root of the checked-out repository before installing dependencies or editing configuration. A clean Git status is a separate check.

$manifest = Get-Content -LiteralPath 'DD-SNAPSHOT.json' -Raw | ConvertFrom-Json -AsHashtable
foreach ($entry in $manifest.files) {
    $file = Join-Path (Get-Location) $entry.path
    if (-not (Test-Path -LiteralPath $file -PathType Leaf)) { throw "Missing: $($entry.path)" }
    if ((Get-FileHash -LiteralPath $file -Algorithm SHA256).Hash -ne $entry.sha256) {
        throw "Hash mismatch: $($entry.path)"
    }
}
git rev-parse HEAD
git status --short

Environment templates are inventories

The supplied .env.example files contain names only. They are not ready-to-run configurations. An empty variable can override a useful config default, so do not leave every listed variable blank and expect the application to work. Review config/*.php, use a minimal isolated configuration, then add values needed by enabled features. Provider options may also live in the database/admin UI.

Create .env only in a new source working copy. Use the values below as a starting checklist, replacing the hostname, database identity and password privately. APP_KEY is initially empty and must be generated locally; no application key is supplied in this document.

APP_NAME="Application Test"
APP_ENV=local
APP_DEBUG=false
APP_URL=https://project.example.test
APP_KEY=
APP_CIPHER=AES-256-CBC
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=REPLACE_WITH_ISOLATED_DATABASE
DB_USERNAME=REPLACE_WITH_ISOLATED_USER
DB_PASSWORD=SET_PRIVATELY
SESSION_DRIVER=file
CACHE_STORE=file
QUEUE_CONNECTION=sync
MAIL_MAILER=log

The file session/cache and sync queue values are temporary bootstrap choices, not the final worker configuration. The seven installers switch their final session, cache and queue backends to database unless explicitly configured otherwise. Keep workers stopped until fixtures and outbound destinations are controlled. Never regenerate APP_KEY on an existing installation.

Dependency installation is separate from the browser wizard

The Git snapshots exclude installed root vendor dependencies. Inspect Composer scripts and allowed plugins before running dependency installation. A complete customer release may already contain its matching vendor tree; the source snapshots do not. Review package scripts before any Node dependency install.

# Run only inside the isolated checkout after reviewing scripts/plugins.
composer install --no-dev --prefer-dist --no-interaction
composer check-platform-reqs --no-dev

# Fresh isolated installation only, once dependency bootstrapping works.
php artisan key:generate
php artisan config:clear

If post-autoload package discovery cannot boot because configuration or database-backed options are missing, retain the error. A reviewer may install with --no-scripts for diagnosis, but deferred package-discovery/scripts must be reviewed and completed after the missing configuration is supplied. Do not present --no-scripts as a finished deployment.

1. Set up a synthetic business profile/location, plans, timezone and SMTP; do not use a live business listing for initial testing.
2. Review CRM, loyalty/referral, Google Business, webhook, WhatsApp notification and email automation add-ons separately.
3. Google Business provider ownership, permissions and listing eligibility require separate account evidence. Source code alone does not establish approval.
4. Custom domains require a separately configured DNS/HTTPS route; validate the base application domain first. Keep outbound notifications and webhook targets under reviewer control.

• modules/AdminMarketplace/Providers/AdminMarketplaceServiceProvider.php
• modules/AdminFaker/Support/AdminFakerService.php
• modules/AdminFaker/Providers/AdminFakerServiceProvider.php
• modules/AppPayments/Providers/AppPaymentsServiceProvider.php

Run these procedures only after the isolated installation and outbound configuration have been reviewed. Use the application service account and the same PHP runtime/configuration as the web process. The commands below are operating examples to adapt, not commands executed during documentation preparation.

Schedule discovery before activation

php artisan schedule:list
php artisan queue:failed
php artisan migrate:status

These commands boot the application and require working configuration. schedule:list shows registered schedules but not every external cron or a complete deployment inventory. Record results before enabling continuous processing.

Scheduler

On a Linux test host, configure one cron entry per application. Replace both absolute paths with the confirmed test runtime and checkout. Preserve restricted test logs; rotate them.

* * * * * cd /srv/dd/PROJECT_ROOT && /usr/bin/php artisan schedule:run >> /srv/dd/logs/PROJECT-scheduler.log 2>&1

On Windows/WAMP, create a Task Scheduler job repeating every minute: Program = the selected php.exe; Arguments = artisan schedule:run; Start in = the isolated repository root. Use an account with the required file/database permissions. Do not point the task at the seller’s v12 working installation.

Queue workers

php artisan queue:work database --queue=default --tries=3 --timeout=60

This example applies when the intended connection is database and the queue name is default. Use the actual connection, named queues and worker limits from each project/module. Keep timeout below retry_after to reduce duplicate processing; check timeout requirements for media/AI work. StackPosts automation needs its separate lane described in its project guide. Supervisor/systemd or an equivalent process manager must restart long-running workers; cron is not a worker manager.

Record queue tables/backend, queue names, retry policy, failed-job handling, concurrency and restart behavior. Do not run queue:retry all blindly: failed jobs may send messages, charge providers or repeat external changes. Review the target and idempotency before a controlled retry.

Mail and optional services

• MAIL_MAILER=log records messages locally and does not prove SMTP delivery. Use a controlled SMTP inbox for authorized notification tests; protect/redact logs containing test personal data.
• Redis, object storage, websocket/realtime services, media binaries and social/AI gateways are feature-specific. Determine need from enabled modules and configuration rather than provisioning every possible dependency.
• A provider console, approval, billing method and valid token are separate dependencies. A successful local install does not establish API approval or delivery.
• Use actual callback/redirect URLs produced by the configured application. This guide intentionally does not invent a generic webhook URL for every provider.

Before an update

1. Record the current source commit, dependencies, active modules/themes, schema revision, configuration inventory and artifact hashes. Verify the target release and its change notes.
2. Take an encrypted database backup, uploaded-file/product-artifact backup and a separately protected copy of application configuration/APP_KEY. Do not place these backups inside source repositories or this documentation folder.
3. Perform a restore rehearsal into a separate disposable environment. A backup file that has never restored successfully is not acceptance evidence.
4. Obtain the product-specific upgrade instructions and rehearse on a clone. Waziper’s referenced UPGRADE.md is missing from its snapshot; do not invent an upgrade path.
5. Define the maintenance window, queue drain/stop procedure and rollback thresholds. Separate application rollback from schema/data rollback.

During an approved change

Use the seller-approved release/update mechanism and reviewed migration steps. Preserve the existing APP_KEY and customer data. Do not rerun the fresh installer on an existing installation. Rebuild only the assets belonging to the selected release, clear/rebuild applicable caches and restart workers so they load the new code.

# Operational examples after an approved isolated update; adapt to the release.
php artisan optimize:clear
php artisan queue:restart

Re-enabling workers can produce external effects. Confirm the test destinations first. Do not treat copying the previous application code back as a complete rollback if schema or customer data changed.

Post-update checks

• Check login, authorization, active themes/static assets, uploads/downloads, cron, queued work and one product-specific user flow.
• For Store/license changes, validate synthetic old-install activation/update behavior and download entitlement before any cutover.
• For provider integrations, retain separate webhook/publish/delivery evidence and redact tokens and customer identifiers.
• Record backups, restore outcome, downtime, errors, rollback decision and remaining gaps. Remove disposable test data according to your retention policy.

These are source module descriptor locations, not proof that each module is active, configured, sold separately, licensed or provider-approved.

Derived from the prepared .env.example. This is not a complete settings inventory and contains no secret values. Empty names must not be treated as a working .env.

• Confirm the exact application version and its required runtime.
• Complete installation in a disposable environment before using production data.
• Check scheduled jobs, queues, mail and backup/restore behavior.
• Configure provider credentials and test each enabled external feature.
• Keep actual test results separate from instructions and source inspection notes.