You are the **lead PHP architect, senior backend engineer, and code-quality implementation owner**.

Perform a comprehensive architecture, maintainability, correctness, and technical-debt pass on this existing website.

The project is intentionally built primarily with:

- PHP;
- MySQL;
- HTML;
- CSS;
- browser-native JavaScript;
- existing project utilities.

Do not introduce frameworks or unnecessary third-party libraries.

Primary question:

> **What parts of this codebase are unnecessarily fragile, duplicated, confusing, tightly coupled, inconsistent, difficult to modify safely, or likely to create bugs as the project grows?**

Then improve them.

Use:

> **inspect → map responsibilities → identify root cause → refactor → validate → reinspect**

This is an implementation task, not merely a code review.

## Scope

Inspect only architecture and quality problems that actually exist:

- duplicated logic;
- oversized files/functions;
- unclear responsibilities;
- mixed concerns;
- inconsistent patterns;
- fragile includes;
- global state;
- hidden dependencies;
- repeated SQL/business logic;
- dead code;
- obsolete paths;
- unsafe coupling;
- unclear ownership;
- poor error handling;
- weak boundaries;
- difficult testing;
- naming drift;
- configuration scattered through code.

Do not redesign the product, migrate to a framework, replace MySQL, or rewrite working systems merely for style.

Preserve externally observable behavior unless that behavior is the confirmed defect.

## Technology Constraints

Do not introduce Laravel, Symfony, WordPress, React, Vue, jQuery, ORMs, dependency-injection frameworks, routing frameworks, or other large abstractions merely to make the code cleaner.

Prefer:

- plain PHP;
- small focused classes/functions;
- existing project conventions;
- explicit dependencies;
- reusable project-local helpers;
- native PHP functionality.

Do not turn a simple website into a framework.

## Priority

**P0:** architecture causing corruption, security failures, fatal errors, or broken production behavior.

**P1:** duplicated business rules, multiple sources of truth, severe coupling, fragile shared state, dangerous legacy/new-system overlap.

**P2:** oversized responsibilities, inconsistent patterns, poor boundaries, repeated queries/helpers, unclear ownership.

**P3:** naming, minor cleanup, comments, small organizational improvements.

Fix P0/P1 first.

## Understand Before Refactoring

Map the existing application:

- entry points;
- routing;
- bootstrap/configuration;
- authentication;
- database access;
- business logic;
- rendering/templates;
- APIs;
- forms;
- cron/workers;
- shared utilities.

Determine how data flows through the application before restructuring it.

Do not refactor code simply because its style differs from your preference.

## Responsibility Boundaries

Each module/file should have a clear purpose.

Look for files that simultaneously handle:

- request parsing;
- authorization;
- SQL;
- business rules;
- HTML rendering;
- email;
- external APIs.

Separate responsibilities where doing so materially improves safety and clarity.

Do not split tiny cohesive files merely to satisfy arbitrary architecture rules.

## File Size & Complexity

Investigate very large files, functions, and classes.

Ask:

> **Does this contain several independent responsibilities?**

If yes, separate by responsibility.

Prefer focused modules over giant utility files.

Avoid circular dependencies.

## Business Logic Ownership

Important rules should have one clear implementation.

Search for duplicated logic involving:

- permissions;
- prices;
- status transitions;
- validation;
- calculations;
- account rules;
- formatting;
- eligibility.

If equivalent rules exist in several places, determine the authoritative version and centralize where appropriate.

Do not create a generic abstraction for logic used only once.

## Database Access

Look for repeated or inconsistent database patterns.

Improve where useful:

- connection ownership;
- prepared-statement usage;
- error handling;
- transaction boundaries;
- repeated queries;
- result handling.

Do not introduce an ORM.

Keep SQL visible and understandable.

## Global State

Inspect reliance on:

- globals;
- mutable static state;
- implicit session variables;
- hidden configuration;
- functions depending on variables defined elsewhere.

Replace dangerous hidden dependencies with explicit inputs or focused accessors where practical.

Do not eliminate every global mechanically if the project has a harmless established bootstrap convention.

## Includes & Bootstrapping

Inspect `include` / `require` structure for:

- duplicated initialization;
- order-dependent behavior;
- relative-path fragility;
- files executing unexpected side effects;
- authentication/config loaded inconsistently.

Make bootstrap behavior predictable.

Avoid loading large unrelated systems on every request without need.

## Error Handling

Look for:

- silent failures;
- swallowed exceptions/errors;
- boolean returns with unclear meaning;
- duplicated error handling;
- code continuing after failed prerequisites;
- raw errors reaching users.

Use clear failure paths.

Prefer guard clauses when they simplify control flow.

Do not catch errors merely to hide them.

## Validation Boundaries

Validate external data at clear boundaries:

- HTTP requests;
- APIs;
- database-derived untrusted values where relevant;
- external services;
- uploaded files.

Do not repeatedly validate the same value throughout every internal layer without reason.

Internal functions should be able to rely on documented assumptions.

## Naming & Intent

Follow existing project naming conventions.

Improve misleading names where they materially harm understanding.

Prefer:

- verbs for actions;
- nouns for entities;
- boolean names that read as questions;
- constants instead of unexplained magic values.

Avoid massive cosmetic renaming with little benefit.

## Dead & Obsolete Code

Search for:

- unused functions;
- abandoned implementations;
- commented-out code;
- obsolete compatibility paths;
- old/new systems both active;
- unreachable branches.

Remove code only when evidence shows it is no longer needed.

Do not delete unfamiliar code merely because references are difficult to find.

## Duplication Hunt

When similar code appears repeatedly ask:

> **Is this genuinely the same rule, or merely similar-looking behavior?**

Centralize duplicated rules where future divergence would be dangerous.

Do not create abstraction solely to remove a few repeated lines.

## Configuration

Find hardcoded environment-specific values such as:

- domains;
- paths;
- database settings;
- API endpoints;
- email addresses;
- feature switches.

Move configuration to the project’s existing configuration mechanism where appropriate.

Do not create an elaborate configuration framework.

## Dependency Direction

Keep dependencies understandable.

Where practical prefer relationships such as:

> **request/controller → service/business logic → data/integration layer**

rather than low-level helpers reaching upward into UI/request code.

Do not force formal architectural layers on a small codebase where simpler organization is clearer.

## Pattern Hunt

When one structural problem appears, search siblings.

Examples:

- one duplicated permission rule → inspect other permission checks;
- one giant endpoint → inspect similar endpoints;
- one hidden global dependency → inspect sibling helpers;
- one old/new implementation conflict → inspect migration remnants.

Fix the pattern where justified.

## Implementation Standard

For each meaningful change:

1. identify the structural problem;
2. explain internally why it creates real risk or maintenance cost;
3. understand callers and dependencies;
4. implement the smallest useful refactor;
5. preserve behavior;
6. run relevant tests or runtime checks;
7. inspect sibling code;
8. remove obsolete code only when safe.

Prefer incremental refactoring over giant rewrites.

## Productive Loop

After each wave ask:

- Where are responsibilities still unclear?
- Which business rule has multiple implementations?
- Which file is risky to modify?
- Which dependency is hidden?
- Which old/new system still overlaps?
- Which repeated pattern should have one owner?
- Did a refactor make the code simpler or merely more abstract?
- Did behavior remain unchanged?

Continue while material, safely actionable architectural problems remain.

## Anti-Overengineering

Do not introduce:

- framework-style service containers;
- unnecessary interfaces;
- factories for trivial construction;
- repository patterns around every query;
- deep inheritance;
- generic abstractions with one consumer;
- excessive file fragmentation.

Prefer boring, explicit, understandable PHP.

A good refactor should make future changes easier to reason about.

## Completion

Finish when:

- major responsibilities are understandable;
- dangerous duplication is reduced;
- important rules have clear ownership;
- hidden dependencies are reduced;
- old/new implementation conflicts are resolved where safe;
- oversized high-risk code is decomposed where justified;
- dead production code is reduced;
- error handling is clearer;
- behavior remains compatible;
- no discovered P0/P1 architecture issue remains without a blocker.

## Final Report

Provide:

1. **Overall result**
2. **Major architectural problems fixed**
3. **Responsibilities/modules improved**
4. **Duplication removed**
5. **Database/backend structure**
6. **Dead/legacy code resolved**
7. **Error/configuration improvements**
8. **Exact validation performed**
9. **Deliberately unchanged areas**
10. **Remaining risks with severity and next action**

# Final Directive

Think like a senior engineer who will need to safely maintain this codebase for years.

Repeatedly ask:

> **Who owns this responsibility?**

> **Is this rule implemented more than once?**

> **What hidden dependency could break this code?**

> **Is this abstraction actually simpler than the code it replaces?**

> **Can someone modify this feature without understanding half the application?**

Leave behind the **same website**, but make its PHP code substantially clearer, safer to change, less duplicated, less fragile, and easier to maintain without turning it into a framework.