1.Executive Overview

PLOCAL is a nationwide local business evaluation platform. It is built around one core model, repeated across every U.S. state, city, and category:

PLOCAL helps customers find local businesses they can trust, and helps business owners understand how professional, credible, visible, and customer-ready their business appears online. Unlike a simple listing directory, PLOCAL does not just confirm that a business exists — it evaluates it against a structured, transparent standard, then presents the outcome publicly.

Who PLOCAL Serves

Main System Areas

High-Level Flow

2.System Architecture

PLOCAL is a single Laravel application. It is primarily server-rendered: pages are built on the server using Blade templates and returned as complete HTML, rather than relying on a separate single-page-application frontend framework. This keeps the system simple to operate, deploy, and reason about.

Layer Responsibilities

3.Repository Structure

The Laravel application lives entirely inside the backend/ directory of the repository. The directories below are the ones an owner or developer will interact with most.

4.Backend Architecture

Every request follows the same predictable path through the backend:

Routing

Routes are grouped into three clearly separated areas:

• Public routes — no authentication, open to any visitor.
• Business routes — prefixed /business, require a Business Portal login.
• Internal routes — prefixed /internal, require staff login and role permission.

Validation & Authorization

Every state-changing request is validated before any Application Service runs. Internal routes are additionally protected by role-based permission checks (see Chapter 16 and Chapter 23), so a Reviewer account, for example, cannot perform an Administrator-only action even if it knows the correct URL.

Background Jobs

Notification delivery (invitation emails, activation confirmations, support-case acknowledgements) is queued rather than sent inline, so a slow mail provider never blocks a visitor-facing request. See Chapter 26 for the current queue configuration.

External Integrations

5.Frontend Architecture

PLOCAL's frontend is server-rendered. Laravel's Blade templating engine builds each page on the server and returns finished HTML — there is no separate JavaScript framework driving page navigation, and no client-side routing to keep in sync with the backend.

Template Organization

The public site's header and footer are each a single shared partial included on every public page, so a navigation change made once is reflected everywhere automatically.

Assets

CSS and JavaScript are organized by page and by shared concern under the repository's assets/ directory (bootstrap and vendor libraries, a shared custom stylesheet, and page-specific stylesheets/scripts). Pages are responsive down to common mobile widths.

Forms & Server Communication

Public forms (Submit Your Business, Contact, Support) post directly to a Laravel route. Where a form submits without a full page reload, it uses a plain JavaScript fetch request against the same route and displays the JSON result inline — there is no separate API layer or token-based authentication for these public forms.

6.Public Website Navigation

The table below covers the primary pages a visitor encounters. Internal action-only endpoints are intentionally omitted — see Chapter 47 for a short reference of the most useful routes.

7.Nationwide Directory & Find Businesses

PLOCAL supports all 50 U.S. states using canonical two-letter USPS state codes (for example, CA, TX, NY). A Submission is only accepted with a valid code from this canonical list — full state names or invalid codes are rejected at submission time. Cities are created automatically the first time a legitimately paid, activated Business reports that city — there is no need to pre-populate every city in the country in advance.

Find Businesses — nationwide search by category, state, city, and ZIP. Captured from the local development environment.

Search Filters

• Category — Construction & Home Services, Beauty & Personal Care, Restaurants & Food Businesses.
• State — any of the 50 canonical U.S. states.
• City — free-text, matched against provisioned locations.
• ZIP — five-digit ZIP code.

Result Ordering

Results are shown in a neutral order. Placement is not determined by payment, votes, Awards, or Evaluation score — every eligible Business receives equal presentation weight in the result list.

Visitor Journey

1. Open Find Businesses.
2. Select any combination of Category, State, City, or ZIP.
3. Review the neutral-order result list.
4. Open a Business Profile for full detail.
5. Return to the exact same search results using the page's Previous/Next or Back-to-Results controls (see Chapter 8).

8.Business Profiles & Contextual Navigation

Every evaluated Business has a public profile at /pro/{businessSlug}.

A live Business Profile, showing category, location, website screenshot, and Digital / Service / Trust result. Captured from the local development environment.

Profile Contents

• Business identity — name, category, city and state.
• Website and submitted website screenshot.
• Evaluation result, shown in the current Digital / Service / Trust format once finalized.
• Current Recognition status, if the Business currently holds or has held an Award.
• Public Voting, where the Evaluation Window is still open for voting.
• Contextual Previous/Next navigation (below).

Contextual Previous/Next Navigation

Profile pages remember how the visitor arrived, so browsing forward and backward stays inside the same context instead of jumping to an unrelated Business:

9.Business Submission

Submit Your Business — the public Submission form. Captured from the local development environment.

Information Collected

• Business name, category, city, state, and ZIP.
• Website URL, main services, and a business description.
• Contact details for the submitter.
• A website screenshot, used as evaluation evidence.

Website Screenshot Requirement

Verified directly against the current Submission validation rules.

What Happens After Submission

A successful Submission creates a durable record and immediately proceeds to Evaluation Checkout (Chapter 10). The Submission itself does not create a public Business Profile — publication only happens after payment is confirmed and the Business is activated (Chapter 11).

10.Payments & Stripe

PLOCAL charges a fixed Evaluation service fee of $250 USD plus applicable taxes, collected through Stripe's hosted Checkout page.

What Payment Does and Does Not Buy

Other Payment Behavior

• Automatic tax — applicable tax is calculated and added on top of the base fee where configured.
• Duplicate charges / refunds — handled through Internal Payment Operations (Chapter 18), never through direct database edits.
• Activation retry — if activation did not complete automatically after a confirmed payment, an Administrator can retry it from Internal Payment Operations.

Stripe: Test vs. Production

# .env — never commit real values
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=

Local Development

# Terminal 1
php artisan serve

# Terminal 2 — forwards Stripe test events to your local app
stripe listen --forward-to http://localhost:8000/webhooks/stripe

11.Paid Activation

Once Stripe's signed webhook confirms payment, PLOCAL provisions everything the Business needs in a single, idempotent sequence:

Idempotency: replaying the same confirmed payment event does not create a duplicate Business or a duplicate Evaluation Window — activation is safe to retry.

If activation did not fully complete (for example, a transient failure between steps), an Administrator can trigger a safe retry from Internal Payment Operations rather than needing any direct database intervention (Chapter 18).

12.Evaluation — Digital / Service / Trust

Every activated Business is assessed across three dimensions, each scored from 0 to 10:

PLOCAL Score

Evaluation Window

Each Evaluation runs on a fixed window of 96 elapsed hours from the moment the Business is activated. This is wall-clock elapsed time, not 96 business hours.

Roles Involved

13.Public Voting

While a Nominee's Evaluation Window is open, the public can cast a Vote across the same three dimensions: Digital, Service, and Trust.

Voting Rules

• One pseudonymous device identity may cast one Ballot per Nominee, per Evaluation Window.
• Each dimension requires a target of 5 valid, distinct-device votes to reach qualification.
• A staff Administrator can invalidate a Ballot found to be invalid, which recomputes qualification.

14.Recognition

Recognition — Business of the Day, Month, and Year. Captured from the local development environment.

Recognition Hierarchy

Lifecycle

A qualifying Nominee that reaches the Evaluation and voting thresholds becomes a Candidate. An Administrator's Final Decision determines the outcome — confirmed as a Nominee, granted Honors, awarded Business of the Day, or declined. Honors and Day/Month/Year Awards are drawn from qualifying Candidates on a chronological basis.

Historical Record

Past Recognition remains publicly viewable. If an Award is later revoked or replaced, that history is preserved for transparency rather than silently deleted — a revoked or inactive Award is not shown as currently valid, but the record of it having occurred is retained internally.

15.Business Portal

Business Portal sign-in at /business/login. Captured from the local development environment.

Onboarding Flow

What a Business Account Can See

The dashboard is a read-only status view scoped strictly to the account's own Business:

• Business identity, category, city/state, and public Profile status and link.
• Evaluation status, and once finalized, its Digital / Service / Trust and PLOCAL Score result.
• Payment history, payment status, and refund status.
• Award and Recognition history for its own Business.

A Business account cannot view or influence another Business's data, and cannot access the Internal Portal under any circumstance — the two systems use entirely separate authentication guards.

16.Internal Portal & RBAC

Internal Portal staff sign-in at /internal/login. Captured from the local development environment.

Roles

Dashboard Areas

• Overview / Nominees & Evaluations
• Business Submissions
• Payment Operations
• Support Cases
• Business Duplicates
• Business of the Month / Business of the Year
• Award Corrections
• Blog
• Advertisers
• Internal Users Administrator-only

Every area is gated by role permission — a Reviewer or Evaluator account attempting an Administrator-only action (such as managing Internal Users) is denied regardless of the URL used.

17.Internal Evaluation Workflow

1. Staff logs in to the Internal Portal.
2. Opens Nominees / Evaluations.
3. Opens the assigned, current Nominee.
4. Reviews the Business and submitted evidence (website, screenshot).
5. Scores the Digital dimension.
6. Scores the Service dimension.
7. Scores the Trust dimension.
8. Saves and submits the Evaluation for review.
9. Candidate eligibility is evaluated once qualification thresholds are met.
10. An Administrator makes the Final Decision.
11. The Recognition outcome, if any, appears publicly on the Business Profile and Recognition page.

18.Payment Operations

Internal Payment Operations gives Administrators visibility and safe recovery tools over every payment:

• Authoritative payment status and history per Business.
• Refund status, including duplicate-charge handling.
• Activation recovery/retry for a payment that was confirmed but did not fully activate.
• Relevant Stripe identifiers, where displayed for reference.

19.Support Cases

Current official contact channels:

Public Contact and Support forms submit into the same internal Support Case system. Every submission is durably recorded and reviewable by Administrators from Internal Support Cases, with a status workflow (for example, received → in review → resolved).

The Business Profile's "Report a concern" link routes a visitor to the official Contact page, which submits into this same Support Case system — there is a single, consistent path for any public concern or fraud report, rather than a separate parallel system.

20.Blog CMS

Public Blog index at /blog. Captured from the local development environment.

Internal Management Capabilities

• Create and edit a draft article, including featured image and alt text.
• Publish and unpublish an article.
• Feature an article for prominent homepage/blog placement.
• Delete (archive) an article.

Public Visibility

Only published articles are ever publicly reachable at /blog or /blog/{slug}. A draft or unpublished article is never exposed on the public site.

21.Advertiser Management

What an Administrator Configures

• Company name and logo
• Website URL
• Active / inactive status
• Display order
• Optional visibility start/end dates

Active advertisers appear in the homepage sponsor carousel, linking only to their own website_url.

22.Database Architecture

PLOCAL uses MySQL as its single source of truth. The conceptual relationships below matter more for day-to-day operation than the full column-level schema.

Other Core Tables

Migrations under backend/database/migrations are the authoritative schema history; they should be applied in order and never edited after being run against a live database.

23.Authentication & Security Model

Three Separate Authentication Systems

Keeping Business and Internal authentication completely separate ensures a compromised or misused Business account can never reach staff-only tooling, and vice versa.

Current Security Controls

• CSRF protection on session-based forms, with a documented, narrow exception for unauthenticated public endpoints (Submission, Support, payment webhooks) that are instead protected by same-origin checks and per-route rate limiting.
• Signed URLs for the payment checkout flow.
• Stripe webhook signature verification as the sole payment authority.
• Role-based authorization (RBAC) throughout the Internal Portal.
• Rate limiting on Submission, Voting, Support Case, and payment-checkout endpoints.
• Private evidence storage, never served directly from the web root.
• Standard password hashing for Business and Internal accounts.
• Business accounts are strictly scoped to their own Business's data.

24.File Storage

25.Email

The current production design sends transactional email through Google Workspace SMTP, from info@plocal.com, using Laravel's standard Mailer.

# Production .env placeholders
MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=info@plocal.com
MAIL_PASSWORD=<GOOGLE_WORKSPACE_SMTP_CREDENTIAL>
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=info@plocal.com
MAIL_FROM_NAME=PLOCAL

Never place real credentials in source control. See Chapter 33 for the Google Workspace setup procedure.

26.Queues & Background Jobs

Local development may run with QUEUE_CONNECTION=sync, meaning queued work executes immediately, inline, with no separate worker process. This is convenient for development but has no retry/backoff behavior.

Production should use a persistent queue driver (the database driver is supported out of the box) together with a supervised worker process:

php artisan queue:work \
  --queue=default \
  --tries=3 \
  --backoff=60,300 \
  --max-time=3600

This worker command should run continuously under a process manager — systemd, Supervisor, or an equivalent tool already standard on the chosen server — so it is automatically restarted if it stops. The specific supervisor is an infrastructure choice for the owner/hosting administrator; this guide does not mandate one.

27.Production Environment Reference

The table below lists the environment variables PLOCAL reads, verified against the current configuration. No secret values are shown — use the placeholders when configuring production.

# Application
APP_NAME=PLOCAL
APP_ENV=production
APP_KEY=<GENERATED_BY_ARTISAN_KEY_GENERATE>
APP_DEBUG=false
APP_URL=https://www.plocal.com

# Logging
LOG_CHANNEL=stack
LOG_STACK=single
LOG_LEVEL=error

# Database
DB_CONNECTION=mysql
DB_HOST=<PRODUCTION_DB_HOST>
DB_PORT=3306
DB_DATABASE=<PRODUCTION_DB_NAME>
DB_USERNAME=<PRODUCTION_DB_USERNAME>
DB_PASSWORD=<PRODUCTION_DB_PASSWORD>

# Session & Cache
SESSION_DRIVER=database
SESSION_LIFETIME=120
SESSION_ENCRYPT=true
CACHE_STORE=database

# Queue
QUEUE_CONNECTION=database

# Mail
MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=info@plocal.com
MAIL_PASSWORD=<GOOGLE_WORKSPACE_SMTP_CREDENTIAL>
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=info@plocal.com
MAIL_FROM_NAME=PLOCAL

# Stripe
STRIPE_SECRET_KEY=<STRIPE_LIVE_SECRET_KEY>
STRIPE_WEBHOOK_SECRET=<STRIPE_LIVE_WEBHOOK_SECRET>

28.Production Deployment

The steps below describe a conceptual deployment to a Linux VPS. No specific hosting provider is assumed.

1. Provision a Linux server.
2. Install a compatible PHP version (PHP 8.3 or newer, per composer.json).
3. Install the required PHP extensions (standard Laravel/MySQL extension set).
4. Install Composer.
5. Install and configure MySQL.
6. Upload or clone the repository onto the server.
7. Configure the web server to point at backend/public as the document root.
8. Create and populate the production .env file (Chapter 27).
9. Generate the application key safely: php artisan key:generate.
10. Install production dependencies: composer install --no-dev --optimize-autoloader.
11. Set correct filesystem permissions on storage and bootstrap/cache.
12. Run migrations: php artisan migrate --force.
13. Run the PLOCAL production bootstrap: php artisan plocal:bootstrap-production.
14. Configure and start the queue worker (Chapter 26).
15. Configure SMTP (Chapter 33).
16. Configure Stripe LIVE keys and webhook (Chapter 32).
17. Configure HTTPS (Chapter 35).
18. Configure DNS (Chapter 35).
19. Confirm persistent storage for uploads (Chapter 24).
20. Confirm a backup plan is active (Chapter 36).
21. Run the production readiness check (Chapter 29).
22. Smoke-test the public flows described in Chapter 43.

29.Production Commands Reference

# Install production dependencies
composer install --no-dev --optimize-autoloader

# Apply the database schema
php artisan migrate --force

# Seed the production-safe reference data (RBAC, Evaluation policy, categories, 50 states)
php artisan plocal:bootstrap-production

# Cache configuration, routes, and views for performance
php artisan config:cache
php artisan route:cache
php artisan view:cache

# Read-only check of production configuration health
php artisan plocal:verify-production-readiness

# Start the queue worker (run under a process supervisor)
php artisan queue:work --queue=default --tries=3 --backoff=60,300 --max-time=3600

30.Commands Never to Run in Production

This list reflects the current Artisan command registry at the time of writing. Command names should be re-verified against php artisan list before each deployment, since the registry can change over time.

31.Database Bootstrap

php artisan plocal:bootstrap-production is the single production-safe seeding entry point. It is idempotent — running it again on an already-initialized database changes nothing.

What It Creates

• Roles and permissions (RBAC)
• The active Digital / Service / Trust Evaluation policy
• The current category taxonomy
• All 50 U.S. states, active and published

What It Deliberately Never Creates

• Fake Businesses
• Fake Awards
• Fake payments
• Demo Internal Users
• Demo Evaluations

32.Stripe Production Setup

1. Sign in to the Stripe account and switch to LIVE mode.
2. Retrieve the LIVE secret API key and store it only in the production .env.
3. Create a webhook endpoint pointed at the final production domain, for example https://www.plocal.com/webhooks/stripe (confirm the exact current route before finalizing).
4. Retrieve the webhook's signing secret and store it as STRIPE_WEBHOOK_SECRET.
5. If automatic tax is used, confirm the relevant tax registrations are configured in Stripe.
6. Send a real test transaction and confirm the webhook is received and activation completes.

The Stripe CLI listener (stripe listen) is never used in production — see Chapter 10.

33.Google Workspace SMTP Setup

1. Sign in to the Google Workspace account that owns info@plocal.com.
2. Generate an app-specific password (or configure Workspace SMTP relay/OAuth, depending on the account's current security policy).
3. Set the Laravel MAIL_* variables from Chapter 25 in the production .env.
4. Send a real test email from the application and confirm delivery.
5. At the DNS level, confirm SPF, DKIM, and DMARC records are configured for the sending domain — this materially improves deliverability and reduces the chance of mail landing in spam.

Exact Google Workspace account settings are specific to the owner's account and are not reproduced here.

34.Web Server Configuration

The web server's document root must point at backend/public — never at the repository root, and never directly at backend/ itself. Only the contents of public should ever be reachable directly over the web.

Conceptual Nginx Notes

• Root: /path/to/project/backend/public
• Pass PHP requests to PHP-FPM.
• Route all non-file requests through index.php (Laravel's standard front controller pattern).

35.DNS & HTTPS

• Point the production domain's DNS at the server.
• Decide the canonical form (www or non-www) and redirect the other consistently.
• Install a valid HTTPS certificate and force an HTTP → HTTPS redirect.
• Set APP_URL to the exact canonical HTTPS domain.
• Confirm secure, HTTPS-only cookies in production.
• Confirm the Stripe webhook endpoint uses this same HTTPS domain — Stripe requires HTTPS for production webhook delivery.

This guide uses https://www.plocal.com as the expected canonical domain; confirm and adjust if the final configured domain differs.

36.Backups

Recommended Practice

• Scheduled MySQL database backups, stored off-server.
• Backups of private Submission evidence storage.
• Backups of public Blog and Advertiser media.
• A defined retention period appropriate to the business's needs.
• Periodic restore testing — a backup that has never been restored is unverified.

37.Logs & Troubleshooting

Payment Troubleshooting

Walk this chain top to bottom in Internal Payment Operations. If the webhook never arrived, fix delivery/HTTPS/firewall first — retrying activation cannot help until the webhook is actually received. If the webhook arrived and payment is confirmed but activation did not complete, use Retry Activation.

Directory Troubleshooting

Symptom: a Business was submitted and paid for, but does not appear in Find Businesses.

Check, in order:

1. Payment was actually confirmed.
2. Activation completed.
3. Business lifecycle and publication status are active/published.
4. The Business Profile itself is published.
5. The submitted state/city was correctly recognized.
6. Discovery eligibility was reached.

If a Business is stuck ineligible purely due to a geography reference-data gap, the safe reconciliation command is:

php artisan plocal:reconcile-discovery-eligibility --dry-run

Review the dry-run output first, then re-run without --dry-run only once the proposed change looks correct.

38.Maintenance

• Keep Laravel and PHP dependencies current, reviewing release notes before upgrading.
• Apply database migrations as they are introduced.
• Monitor the queue worker and the failed_jobs table.
• Monitor disk usage, particularly private evidence and media storage.
• Review logs periodically, not only when something visibly breaks.
• Periodically verify that backups completed successfully.
• Monitor Stripe webhook health from the Stripe dashboard.
• Monitor SMTP delivery for bounces or authentication failures.
• Apply security patches promptly.

39.Testing

PLOCAL includes an automated Laravel test suite covering the majority of product behavior, run against a fully isolated test database.

# Run the full suite
php artisan test

# Run a focused subset
php artisan test --filter="SomeTestName"

40.Local Development Environment

cd backend
composer install
# configure .env for local development
# create the local database
php artisan migrate
php artisan plocal:bootstrap-production
php artisan serve

For local Stripe testing:

stripe listen --forward-to http://localhost:8000/webhooks/stripe

If queued work needs to be processed locally:

php artisan queue:work

Never place real production credentials in a local .env file.

41.Owner Quick Start

A short answer to: "PLOCAL is already deployed — how do I actually use it?"

Administrator

• Log in to the Internal Portal.
• Review new Submissions and Payment Operations.
• Manage Evaluations and Recognition.
• Manage the Blog and Advertisers.
• Handle Support Cases and manage Internal Users.

42.Administrator Daily Workflow

Morning

• Review new Support Cases.
• Review new Business Submissions.
• Check for payment or activation exceptions.
• Review active Evaluations in progress.
• Review current Recognition workload.

Content

• Blog — draft, review, or publish articles.
• Advertisers — review active/inactive status and display order.

Administration

• Manage Internal Users.
• Review Business Duplicates.
• Process any needed Award Corrections.

43.Production Launch Checklist

• VPS ready
• Production MySQL ready
• Production .env configured
• APP_DEBUG=false
• APP_URL correct and HTTPS
• HTTPS certificate valid
• DNS correctly pointed
• Migrations complete
• plocal:bootstrap-production complete
• 50 states verified
• Digital / Service / Trust policy verified active
• Stripe LIVE keys configured
• Stripe LIVE webhook configured and verified
• A real production payment tested safely
• Stripe Tax reviewed, if used
• SMTP verified with a real test email
• Queue worker running under a supervisor
• Persistent storage verified for uploads
• Backup system verified
• File permissions correct
• Home page works
• Find Businesses works
• A Business Profile works
• Submission works end-to-end
• Business login works
• Internal login works
• Blog works
• Advertisers display correctly
• robots/canonical metadata correct for production
• Logs reviewed after first deploy
• No demo/seed commands were run against production

44.Post-Launch Checklist

Items above are operational recommendations, not application behavior claims.

45.Recommended Follow-Up Improvements

PLOCAL is prepared for handoff. The items below are genuinely non-blocking follow-ups identified during the most recent technical review — none of them prevent a production launch.

• Add a sitemap for search-engine discovery of the full directory hierarchy.
• Minor responsive polish on one directory listing layout at narrow tablet widths.
• A small number of legacy static redirects still need cleanup.
• A product decision is still pending on two informational pages referenced from older content (a badge-verification lookup page and a standalone privacy-policy page).
• Establish version control (source history) for the repository going forward, if not already in place at handoff.

46.Glossary

Business Submission

The initial form a business owner completes to request a PLOCAL Evaluation.

Business

The canonical record for an activated business on PLOCAL.

Business Profile

The public-facing page for a Business at /pro/{slug}.

Nominee

A Business under active Evaluation and eligible for Recognition consideration.

Evaluation Window

The fixed 96-elapsed-hour period during which a Nominee is assessed and voted on.

Digital / Service / Trust

The three 0–10 dimensions that make up the current Evaluation model.

PLOCAL Score

(Digital + Service + Trust) ÷ 3, rounded once.

Voting Ballot

One pseudonymous-device vote cast for a Nominee within its Evaluation Window.

Candidate

A Nominee that has met the qualification thresholds required for Recognition consideration.

Honors

A Recognition outcome granted by Administrator Final Decision, short of a Day/Month/Year Award.

Business of the Day / Month / Year

The three tiers of official PLOCAL Recognition.

Paid Activation

The provisioning sequence triggered once payment is confirmed.

Discovery Eligibility

Whether a Business currently qualifies to appear in Find Businesses.

Support Case

A durable record created from any public Contact, Support, or concern submission.

Internal User

A PLOCAL staff account (Administrator, Reviewer, or Evaluator).

Business User

An invited account scoped to a single activated Business.

47.Quick Route Reference

Action-only (POST) endpoints are intentionally omitted from this reference.

48.Owner Production Responsibilities

The following are infrastructure and configuration responsibilities for the owner or hosting administrator — they are not missing application features.

49.Final System Status

This guide reflects the PLOCAL codebase as verified at the time of writing: routes, Artisan commands, environment variables, the Digital / Service / Trust Evaluation model, the 50-state directory architecture, the Stripe payment flow, the Business Portal, the Internal Portal, the Blog, Advertisers, and the production bootstrap command were each checked directly against the current source.