fxbixn12/axislab

1. Overall shape

- This is a Laravel application built on the Laravel + Livewire starter kit.

- The app is a small e-commerce / ordering system with customer browsing, cart/checkout, payment integration, and an admin back office.

- The frontend is Blade-driven with Livewire/Volt for reactive interaction, not a separate SPA.

2. Request entry and application bootstrap

- HTTP requests enter through public/index.php, then Laravel bootstraps via bootstrap/app.php.

- Routing is split between routes/web.php for the main site and routes/auth.php for authentication flows.

- Standard Laravel config lives under config/, with environment setup driven by .env.example.

3. Presentation layer

- User-facing pages are rendered from resources/views/, including catalog, product detail, cart, checkout, success, contact, and landing pages.

- Admin screens have their own Blade views such as admin.blade.php, admin-crear.blade.php, and district management views.

- Shared UI structure is centralized in resources/views/components/ and resources/views/layouts/, with Flux UI components under resources/views/flux/.

4. Frontend reactivity

- Livewire is used for interactive UI behavior without a full frontend framework.

- The starter kit includes Livewire auth views under resources/views/livewire/auth/ and settings views under resources/views/livewire/settings/.

- A small Livewire action exists for logout in app/Livewire/Actions/Logout.php.

5. Authentication and user management

- Authentication is handled by the standard Laravel auth stack plus custom controllers in app/Http/Controllers/AuthController.php and app/Http/Controllers/Auth/VerifyEmailController.php.

- User data is extended beyond the default starter kit with apellido and id_rol, indicating role-based access control.

- Email verification, password reset, and registration tests are present, matching the starter kit’s auth subsystem.

6. Catalog and customer browsing

- CatalogoController likely serves product listing and product detail flows.

- The domain is organized around Producto and Categoria, with a producto-detalle view for item detail pages.

- This is the customer discovery layer before cart and checkout.

7. Cart, checkout, and order lifecycle

- CheckoutController coordinates the purchase flow.

- The database includes carrito and detalle_carrito tables for temporary cart state, plus pedidos and detalle_pedido for finalized orders.

- Additional tables for pagos and envios show that checkout persists both payment and shipping information as separate order-related records.

8. Payment integration

- MercadoPagoController is the dedicated integration point with Mercado Pago.

- Architecturally, this sits between checkout/order creation and payment confirmation, handling the external payment provider boundary.

- The success view suggests a post-payment return or confirmation page.

9. Admin/back-office subsystem

- AdminController manages admin CRUD for catalog or user-related entities, while AdminDistritoController manages districts.

- Admin views cover create/edit/list flows for both products/users and districts.

- Distrito appears to support shipping or checkout constraints, and the migrations include distritos plus add_datos_envio_to_pedidos_table, suggesting admin-maintained shipping metadata affects orders.

10. Domain model and persistence

- The core domain models are User, Role, Categoria, Producto, Pedido, DetallePedido, and Distrito.

- Database migrations define the schema evolution for roles, products, cart, orders, payments, shipping, and district data.

- DatabaseSeeder and RoleSeeder establish initial application data, especially role records for authorization.

11. System boundaries and data flow

- Main flow: anonymous user browses catalog → authenticates if needed → adds products to cart → checkout creates order records → payment is sent through Mercado Pago → success/confirmation view closes the loop.

- Admin flow: privileged user logs in → manages products/categories/districts and related operational data.

- The key boundary is between internal order state in the database and the external payment provider.

12. Tooling and operational structure

- Dependencies are managed with Composer and npm/Vite (composer.json, package.json, vite.config.js), reflecting a Laravel + modern asset pipeline setup.

- GitHub Actions in .github/workflows/ run linting and tests, so the repo includes CI validation even though the test coverage is still mostly starter-kit auth tests.

- Standard Laravel storage, cache, and queue directories are present, but the visible architecture is primarily synchronous web request handling.