# 3D - QA Apps: Working Agreement

## Project context

- This is an existing internal Laravel application. Do not create a new Laravel project.
- Stack: Laravel 13, PHP 8.3+, MySQL/MariaDB, Blade, Vite, and Node.js 22.
- The planned UI stack is Bootstrap 5, jQuery, AJAX, DataTables, Select2, SweetAlert2, and SortableJS.
- UI labels are in Bahasa Indonesia; class, method, variable, database table, and column names are in English.

## Architecture

- Keep controllers thin.
- Place business logic in service classes.
- Use Form Requests for validation.
- Use Eloquent relationships and Laravel conventions; avoid raw SQL when Eloquent or the query builder is sufficient.
- Use database transactions for multi-table operations.
- Use policies and Spatie permissions where authorization is needed.
- All database changes must use Laravel migrations. Seed master/default data with seeders.

## Domain rules

- Keep `apps`, `menus`, and `app_versions` as separate entities.
- Menus must support parent-child relationships through `parent_id`.
- Keep test cases separate from test results because one test case can be tested and retested multiple times.
- QA flow: BELUM TEST -> NOK -> SEDANG DIPERBAIKI -> SIAP RETEST -> OK.
- A failed retest returns to NOK, then follows the repair/retest flow again.
- Every QA status change must create immutable audit/history data.
- Consider soft deletes for master or transactional records whose history must be retained.

## Data and safety

- Use foreign keys and appropriate indexes.
- Do not manually create or alter database tables.
- Never run `migrate:fresh`, `migrate:reset`, `db:wipe`, `DROP TABLE`, or another destructive database operation without explicit user approval.
- Do not change `.env` automatically and never expose or commit credentials, tokens, API keys, or passwords.
- Do not remove files or dependencies without a clear reason and explicit scope.

## Change process

- Audit the existing code before making substantial changes.
- Do not install packages, run migrations, or introduce modules beyond the scope explicitly requested by the user.
- Prefer maintainability and readability over unnecessary complexity.
- Verify changes proportionally with focused tests or checks, and report material risks before proceeding.