VACATION SYSTEM V2 - COMPLETE IMPLEMENTATION PROMPT PACK ======================================================== Project: /Users/yahyaashawish/Herd/burijeEapps Master plan: /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt How to use this file -------------------- 1. Use one new working chat for each prompt. 2. Attach the master V2 plan to every chat. 3. Complete prompts in the order shown below. 4. Do not start the next prompt until the previous phase has been reviewed. 5. Phases 8 and 9 must be treated as one production release boundary because they replace the current incorrect request/balance behavior. 6. Phase 12 data reconciliation must finish before Phase 13 removes legacy fields. 7. Do not run migrations unless explicitly requested in that working chat. Current completed work from the old plan ---------------------------------------- - Week Days CRUD is implemented. - Official Holidays CRUD from old Phase 3B is implemented. - Vacation Request Days administrative views from old Phase 3C are implemented. - Their routes, permissions, and vacation submenu entries exist. - Vacation requests, vacation balances, vacation years, printing, and basic request actions exist. The new phases must extend and refactor that implementation. They must not recreate it from scratch. PROMPT 0 - BUSINESS POLICY CONFIRMATION AND CODE AUDIT ====================================================== Perform Phase 0 of the Vacation System V2 plan as an analysis-only task. Project path: /Users/yahyaashawish/Herd/burijeEapps Attached master plan: /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read completely: 1. The attached V2 plan. 2. /Users/yahyaashawish/Herd/burijeEapps/AGENTS.md 3. Current vacation migrations, models, CRUD pages, employee forms, settings, routes, menu, request printing, request actions, and balances logic. Do not modify any file in this phase. Confirm whether the current code and database support these approved baseline rules: 1. Every employee will have one work-week type. 2. Each work-week type has exactly seven weekday configurations. 3. Connected weekly days off are appended only after request.end_date. 4. The connected sequence stops at the first configured working day. 5. No weekly days off are automatically prepended before request.start_date. 6. Official holidays retain a per-holiday balance-deduction flag. 7. A new official holiday defaults to no balance deduction. 8. When a date is both an official holiday and a weekly day off, the official-holiday deduction flag takes precedence. 9. Vacation types with affects_balance=false deduct nothing. 10. Employee schedule and connected-policy values are snapshotted on request creation. 11. Approved historical requests are not automatically regenerated. 12. Submission does not affect balances. 13. Approval increases reserved_days only. 14. Daily processing moves each finished date from reserved_days to used_days. 15. Approved cancellation releases only unprocessed reserved dates. 16. Vacation request status archived becomes completed, displayed as منتهي. 17. Vacation-year archived status remains unchanged. 18. Cross-year calculated date sets are blocked in the first implementation unless management approves another allocation policy. Report: - Current files and methods that conflict with the new rules. - Existing migrations that have already run and must never be edited. - Any policy ambiguity still requiring management approval. - Any schema or naming differences from the plan. - A go/no-go recommendation for Phase 1. Do not create tests, migrations, documentation, or code. PROMPT 1 - ADDITIVE DATABASE FOUNDATION ======================================= Implement Phase 1 of the revised Vacation System plan: Additive Database Foundation. Project path: /Users/yahyaashawish/Herd/burijeEapps Attached master plan: /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Current status: - Week Days CRUD is implemented. - Official Holidays CRUD old Phase 3B is implemented. - Vacation Request Days views old Phase 3C are implemented. - Their original migrations have already run on MySQL. Before editing: 1. Read the V2 plan and AGENTS.md completely. 2. Inspect migrate:status, current Git status, related migrations, entities, permissions, and database conventions. 3. Preserve unrelated changes. Strict scope: Create additive migrations only. Do not implement models, CRUD pages, employee forms, generation, workflow, scheduler, reconciliation, or navigation. Never edit already-run migrations. Create `work_week_types` with: - id - name - working_days_count unsigned tiny integer default 0 - off_days_count unsigned tiny integer default 0 - is_default boolean default false - status enum enabled/disabled, default enabled - notes nullable text - created_by and updated_by nullable user foreign keys with nullOnDelete - timestamps and soft deletes - useful status/default indexes Create `work_week_type_days` with: - id - work_week_type_id foreign key - week_day_id unsigned tiny integer foreign key to week_days.id - is_working_day boolean default true - timestamps - unique work_week_type_id plus week_day_id - restrict deletion of referenced weekdays Do not seed or create a default work week yet. Add nullable indexed `work_week_type_id` to employees with a foreign key to work_week_types and restrictOnDelete. Do not backfill or make it non-nullable yet. Add to hr_settings: - count_connected_weekly_off_days boolean default false Do not create another settings row. Add to vacation_requests: - nullable indexed work_week_type_id with restrictOnDelete - count_connected_weekly_off_days boolean default false - requested_calendar_days unsigned small integer default 0 - deductible_days decimal(6,2) default 0 - completed_at nullable timestamp Do not update existing request data. Add to vacation_request_days: - source enum requested/connected_weekly_off default requested - is_weekly_off boolean default false - is_scheduled_working_day boolean default true - nullable indexed work_week_type_id with restrictOnDelete - calculation_reason nullable string with a sensible length Do not remove or rename is_weekend, is_holiday, day_value, deducts_balance, or lifecycle timestamps yet. Change only the database default of official_holidays.affects_vacation_calculation to false through a new migration. Preserve every existing row value and all original column attributes. Expand vacation_requests.status to include completed while temporarily retaining archived. Preserve the current default and index. In down(), safely convert completed to archived before removing completed. Add permissions using the existing Spatie pattern: - work_week_types.view - work_week_types.create - work_week_types.edit - work_week_types.delete - work_week_types.activate - vacation_settings.view - vacation_settings.edit Use guard web, avoid duplicates, and clear permission cache. Migration safety: - Use safe dependency ordering and reversible down() methods. - Do not change balances, requests, employees, or existing holiday values. - Avoid raw SQL except for the MySQL enum when necessary. - Do not run migrations unless explicitly requested. Do not create or run tests. Verification: - Run vendor/bin/pint --dirty --format agent. - Run php -l on changed PHP files. - Run php artisan migrate:status --no-interaction. - Review migration order, up/down methods, and Git diff. - Confirm no existing migration or unrelated file was modified. Report files, schema additions, keys, indexes, enum changes, permissions, untouched data, verification results, and deferred work. PROMPT 2 - MODELS, RELATIONSHIPS, CASTS, AND DOMAIN CONSTANTS ============================================================ Implement Phase 2 of the Vacation System V2 plan. Project path: /Users/yahyaashawish/Herd/burijeEapps Attached master plan: /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Assume Phase 1 migrations exist. Inspect their exact schema before editing. Read AGENTS.md, the V2 plan, applicable Laravel conventions, and sibling HR entities completely. Strict scope: Implement models, relationships, casts, scopes, constants, and state helpers only. Do not implement CRUD pages, backfills, employee forms, generator, balances, workflow, scheduler, or reconciliation. Create WorkWeekType entity following Modules/Hr/Entities conventions: - guarded/fillable convention matching siblings - SoftDeletes - casts for counts and booleans - status labels in Arabic if entity constants currently hold UI labels - enabled and default scopes - ordered scope - hasMany day configurations - hasMany employees - hasMany vacation requests - hasMany request-day snapshots if schema supports it - safe helper methods for assigned/referenced state Create WorkWeekTypeDay entity: - casts for IDs and is_working_day - belongsTo work-week type - belongsTo weekday - working-day and off-day scopes Update WeekDay: - hasMany work-week type days - keep legacy is_weekend casts/scopes temporarily, clearly isolated from new employee-specific logic Update Employee: - belongsTo work-week type - retain existing vacation relationships Update HrSetting: - boolean cast for count_connected_weekly_off_days Update VacationRequest: - belongsTo snapshotted work-week type - casts for connected flag, requested_calendar_days, deductible_days, and completed_at - central status labels/constants including completed => منتهي - keep archived temporarily for legacy compatibility - helpers/scopes for editable, approvable, approved, completed, and terminal states Update VacationRequestDay: - belongsTo work-week type if added - casts for source and new booleans - source and calculation-reason constants - scopes for requested, connected, scheduled working, weekly off, deductible, reserved, unprocessed, processed, released, and unreleased - keep existing safe-edit/delete state helpers Update OfficialHoliday: - make the semantics explicit: affects_vacation_calculation=true means the date deducts from vacation balance - add a clearly named scope/helper such as deductsVacationBalance without breaking the existing field - preserve attendance logic separately Use explicit return and parameter types, casts() methods, curly braces, and descriptive names. Do not create or run tests. Do not run migrations unless explicitly requested. Verification: - Pint dirty PHP files. - php -l every changed/created PHP file. - Review relationships against real foreign keys. - Review Git diff for unrelated changes. Report files, relationships, casts, constants, helpers, compatibility fields retained, and deferred work. PROMPT 3 - WORK-WEEK TYPES CRUD =============================== Implement Phase 3 of the Vacation System V2 plan: Work-Week Types CRUD. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and the applicable Livewire and Tailwind skills. Inspect the completed Week Days and Official Holidays CRUD pages before editing. Strict scope: Implement only Work-Week Types routes, permissions usage, full-page Livewire CRUD, and vacation submenu entry. Do not assign employees, backfill data, generate request days, or change request balances. Arabic page/submenu title: أنواع أسابيع الدوام Match the exact existing Week Days CRUD style, cards, spacing, three-column form conventions where appropriate, shared inputs/select/textarea, table, badges, buttons, confirmation dialog, toast, pagination, RTL behavior, loading states, and validation display. Index: - Search by name. - Filter by enabled/disabled status. - Display name, working count, off count, default badge, status badge, and actions. - Add create, edit, activate/deactivate, and safe-delete actions according to permissions. Create/update: - name - status - is_default - notes using the general textarea component - seven weekday configurations ordered using week_days.sort_order - each weekday selects working day or weekly day off - live display of derived working/off counts Save atomically: - exactly seven unique weekdays - at least one working day - counts derived from child rows, never trusted from submitted count inputs - counts sum to seven - one active default type - selecting a new default clears the previous default in the same transaction Restrictions: - Cannot disable the default until another enabled default is selected. - Cannot delete a type assigned to employees or referenced by requests/request days. - Cannot delete the default without replacement. - Enforce rules server-side, not only through hidden buttons. Add named routes using current HR conventions and add the submenu item under الإجازات with active-route and permission checks. Do not create tests or run migrations unless requested. Run Pint, php -l, filtered route:list, and diff review. Report files, routes, permissions, validation, transaction behavior, restrictions, submenu work, and deferred phases. PROMPT 4 - DEFAULT WORK WEEK AND EMPLOYEE ASSIGNMENT ==================================================== Implement Phase 4 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and inspect the current EmployeeController, employee create/update/index views, work-week entities, Week Days data, and Work-Week Types CRUD. Strict scope: Implement the default work-week backfill mechanism and employee work-week assignment. Do not change vacation request calculation or balances. Create an idempotent data migration or appropriately scoped command, following project conventions, that: 1. Creates one default work-week type from the current week_days.is_weekend values if no default exists. 2. Creates exactly seven child day rows. 3. Calculates working/off counts. 4. Assigns that default type to employees where work_week_type_id is null. 5. Never overwrites an existing employee assignment. 6. Can be rerun safely without duplicate types or child rows. Use an Arabic default name such as "الدوام الإداري الافتراضي", unless an existing naming convention indicates otherwise. Update employee create and update pages: - Add required general select field titled "نوع أسبوع الدوام". - Load enabled work-week types. - While editing, continue displaying the current selected type even if it has since been disabled. - Preserve old input and show Arabic validation errors. - Match existing employee form layout and shared components. Update EmployeeController create/update validation and payloads: - required integer exists in non-deleted work_week_types - require enabled selection for new assignment - allow retaining a currently assigned disabled type during unrelated editing, but do not allow switching to another disabled type Add the work-week type to employee index/details only if it fits the existing layout cleanly. Do not make the employee foreign key non-nullable yet unless the migration strategy in Phase 1 explicitly prepared and verifies all rows. Leave the final contract change for Phase 13. Do not create tests. Do not run migrations or backfill commands unless explicitly requested. Run Pint, php -l, route/view validation checks, and diff review. Report the backfill behavior, employee UI/controller changes, safeguards, and remaining nullability work. PROMPT 5 - VACATION LOGIC SETTINGS PAGE ======================================= Implement Phase 5 of the Vacation System V2 plan: Vacation Settings. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and applicable Livewire/Tailwind skills. Inspect Week Days CRUD, Vacation Years settings modal, HR settings entity, routes, permissions, and vacation submenu. Strict scope: Create only the dedicated vacation settings page for the existing singleton hr_settings row. Do not implement connected-date generation yet. Arabic title and submenu item: إعدادات الإجازات First setting: احتساب أيام العطلة الأسبوعية المتصلة Values: - نعم - لا Requirements: - Full-page Livewire view matching existing HR CRUD layout and card styles. - Use the general select/switch component. - Edit only hr_settings row ID 1 or the established singleton accessor. - Never insert a second row. - Default false when the value is missing. - Server-side boolean validation and vacation_settings.edit permission. - Existing notification and validation-error components. - Explain in Arabic that changes affect new requests and do not automatically recalculate approved historical requests. - Add named route with vacation_settings.view permission. - Add submenu item under الإجازات with active state and permission. Do not modify vacation-year start/end logic except to ensure the same singleton row is safely shared. Do not create tests or run migrations unless requested. Run Pint, php -l, filtered route:list, and diff review. Report files, route, permission checks, singleton safety, submenu, and deferred generator behavior. PROMPT 6 - OFFICIAL HOLIDAY BALANCE POLICY UPDATE ================================================= Implement Phase 6 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and applicable Livewire/Tailwind skills. Inspect the already implemented Official Holidays CRUD and Phase 1 migration before editing. Strict scope: Clarify and update the Official Holidays CRUD balance-policy behavior only. Do not generate or regenerate vacation request days. Authoritative meaning: - affects_vacation_calculation=true: the holiday date deducts from vacation balance. - affects_vacation_calculation=false: the holiday date does not deduct. - New holidays default to false. - Existing holiday values must remain unchanged when editing. Update create/update/index/filter UI: - Replace ambiguous wording with "تخصم العطلة من رصيد الإجازة". - Create form defaults to "لا". - Edit form loads the stored value. - Index shows clear Arabic badges: "تخصم من الرصيد" / "لا تخصم من الرصيد". - Filter uses the same meaning. - Keep attendance-calculation settings separate. - Preserve the existing old CRUD visual style and shared components. Add validation to prevent ambiguous boolean submission and show Arabic field errors. Review overlapping enabled official-holiday date ranges. If the V2 policy decision requires preventing overlaps, add safe validation now; otherwise report the unresolved precedence without inventing it. Do not bulk-update existing holidays. Do not update request days or balances. Do not create tests or run migrations unless requested. Run Pint, php -l, route inspection if changed, and diff review. Report semantics, UI defaults, validation, existing-data preservation, and deferred calculation integration. PROMPT 7 - REQUEST-DAY POLICY ENGINE AND GENERATOR ================================================== Implement Phase 7 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md, the entire V2 policy precedence, current entities, work-week configuration, holiday scopes, request-day schema, and current request CRUD. Strict scope: Implement domain calculation classes only. Do not yet replace request creation/approval UI, mutate balances, add scheduler logic, or reconcile existing data. Create focused classes following project structure, such as: - WorkWeekResolver - VacationDayCalculationPolicy - VacationRequestDayGenerator Required generator behavior: 1. Require request employee, vacation type, vacation year, work-week snapshot, and seven configured schedule days. 2. Load schedule and applicable enabled official holidays in bounded queries before date iteration. 3. Generate one source=requested row for every explicit start_date through end_date date. 4. Classify weekday, scheduled working/off state, holiday relation, calculation reason, day_value, and deducts_balance. 5. If connected snapshot is enabled, start at end_date+1 and append consecutive configured weekly-off dates only. 6. Stop at the first scheduled working day. 7. Never prepend dates before start_date. 8. Limit connected iteration to at most six dates as a safety guard. 9. Official holiday deduction setting takes precedence when a generated date is a holiday. 10. Vacation types with affects_balance=false make every row non-deductible. 11. New official holidays default to non-deductible, but use each stored value. 12. Persist rows uniquely by request/date. 13. Calculate requested_calendar_days, working_days, and deductible_days from persisted rows. Regeneration: - Allowed only for draft/submitted/under_review/returned. - Block if any row is reserved, processed, or released. - Run atomically. - Never mutate balances. - Preserve historical approved/terminal rows. Cross-year rule: - Apply the policy confirmed in Phase 0. - If no different policy was explicitly approved, reject any explicit or connected deductible date outside the selected vacation year. Performance: - Avoid per-day queries. - Use CarbonPeriod safely. - Use decimal-safe totals. - Make repeated generation idempotent for editable requests. Do not create tests per project instruction. Do not wire the classes into production request actions yet. Run Pint, php -l, static code review, and diff inspection. Report created classes, exact precedence, queries, transaction behavior, safeguards, and integration deferred to Phase 8. PROMPT 8 - REQUEST FORM, GENERATED TOTALS, REQUEST-DAY UI, AND PDF ================================================================ Implement Phase 8 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and applicable Livewire, Tailwind, and PDF skills. Inspect the existing request create/update page, request-day pages, print controller/view, and Phase 7 generator. Strict scope: Integrate generated request days and totals into request creation/editing and display. Do not implement approval reservation, daily consumption, or scheduler yet. Critical old-logic replacement: - Remove the editable working_days input. - Stop trusting working_days from the browser. - Remove the current request-creation code that increases vacation_balances.reserved_days. - Submission must have no balance effect. Create request atomically: 1. Validate employee, type, current year, and dates. 2. Require employee work-week assignment. 3. Snapshot work_week_type_id and count_connected_weekly_off_days. 4. Create the submitted request. 5. Generate request-day rows. 6. Persist generated totals. 7. Roll back the request when generation fails. Edit: - Allow only editable statuses. - Regenerate after employee, type, start date, or end date changes. - Block regeneration when lifecycle timestamps exist. - Do not mutate balances. Form display: - requested calendar days - scheduled working days - deductible days titled "الأيام المحتسبة من الرصيد" - connected weekly-off days - holidays that deduct - holidays that do not deduct - employee work-week type summary Update Vacation Request Days index/details to show source, scheduled work/off state, holiday deduction policy, calculation reason, and final deduction result using Arabic badges and the existing old CRUD style. Update request index and PDF to display deductible_days as the balance-impact total. Preserve the supplied Arabic PDF layout and visually verify rendering if PDF files change. Do not enable this phase in production independently from Phase 9. The old approval logic is incompatible after submission stops reserving. Treat Phases 8 and 9 as one release boundary. Do not create tests or run migrations unless requested. Run Pint, php -l, route inspection, PDF render/visual verification when changed, and diff review. Report removed old logic, generator integration, UI totals, PDF changes, and Phase 9 dependency. PROMPT 9 - WORKFLOW AND BALANCE SERVICES ======================================== Implement Phase 9 of the Vacation System V2 plan immediately after Phase 8. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md, Phase 7 generator, Phase 8 request integration, current request index actions, print controller, and vacation balance formula. Strict scope: Replace direct lifecycle/balance mutations with services. Do not add the daily command yet. Create VacationBalanceService with explicit methods such as: - reserve(VacationRequest $request): void - consumeDay(VacationRequestDay $day): void, implemented for Phase 10 use but not scheduled yet - release(VacationRequest $request): void Create VacationRequestWorkflowService with methods such as: - submit - markUnderReview - approve - reject - cancel - complete Approval transaction: 1. Lock request. 2. Lock deductible request-day rows. 3. Lock matching employee/type/year balance. 4. Sum persisted eligible day_value. 5. Calculate available_days = remaining_days - reserved_days. 6. Block insufficient available balance. 7. Block overlap with another approved request on any deductible generated date, including connected dates. 8. Increase reserved_days only. 9. Set reserved_at on exact deductible rows. 10. Set request/approval status approved and approved_at. 11. Do not increase used_days or change remaining_days. Reject/cancel before approval: - No balance effect. - Set correct statuses and timestamps. Approved cancellation: - Release only rows reserved and not processed/released. - Decrease reserved_days by their exact total. - Keep processed used days unchanged. Refactor Livewire actions and print controller to call workflow services. Printing/starting formal review changes status through markUnderReview and never directly updates the model. Remove the old logic that subtracts reserved and immediately adds used during approval. All balance operations must be transactional, lockForUpdate, decimal-safe, non-negative, and preserve other requests' reservations. Never reset aggregate reserved_days to zero. Phases 8 and 9 together must leave no active path using the old lifecycle. Do not create tests. Do not add scheduler yet. Run Pint, php -l, route review, search the codebase for old direct balance/status mutations, and review diff. Report services, replaced actions, locking order, overlap rule, formulas, and scheduler work deferred. PROMPT 10 - DAILY PROCESSOR AND COMPLETED STATUS ================================================ Implement Phase 10 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md, workflow/balance services, request-day lifecycle fields, routes/console.php, provider conventions, request views, badges, filters, and PDF. Strict scope: Implement daily request-day processing, automatic completion, and completed-status presentation. Create Artisan command: hr:process-vacation-days Select rows where: - parent request is approved - date is before today - deducts_balance=true - reserved_at is set - processed_at is null - released_at is null Process in chunks. For each row call the balance service transactionally: - reserved_days -= day_value - used_days += day_value - remaining_days = opening_balance - (used_days + adjusted_days) - processed_at = now Ensure idempotency, consistent lock ordering, non-negative reservation safeguards, useful logging, and no duplicate processing when rerun. After processing, complete an approved request only when every deductible row is processed or released and the latest deductible generated date is before today. Use generated dates, not request.end_date, because connected days may extend it. Update: - status=completed - completed_at=now Replace vacation-request Arabic label "مؤرشف" with "منتهي" for completed in request index filters, badges, details, PDF, and notifications. Keep vacation-year archived wording unchanged. Schedule in routes/console.php at 00:10 with withoutOverlapping and onOneServer when the configured cache supports it. Follow Laravel 12 scheduling conventions. Do not create tests. Do not execute the command against production data unless explicitly requested. Run Pint, php -l, artisan command discovery, schedule:list if safe/read-only, route/view searches for archived request labels, and diff review. Report command, criteria, idempotency, schedule, completion logic, and UI updates. PROMPT 11 - LIFECYCLE EDITING, CANCELLATION, AND DELETION HARDENING ================================================================== Implement Phase 11 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and audit every request, request-day, holiday, weekday, work-week, employee, controller, Livewire action, route, and menu entry that can mutate lifecycle data. Strict scope: Harden authorization and state restrictions. Do not perform legacy reconciliation or remove columns. Enforce server-side: - Draft/submitted/under-review/returned requests may be edited only according to approved policy. - Editing employee/type/dates regenerates days safely. - Approved requests cannot be normally edited. - Rejected/cancelled/completed requests are historical and read-only. - Processed request days cannot be edited/deleted. - Reserved/released days cannot be manually changed to affect balances. - Requests with balance/day history cannot be hard deleted. - Approved cancellation uses workflow service and confirmation. - Official holidays referenced by request days cannot be hard deleted. - Work-week types referenced by employees/requests cannot be hard deleted. - Weekday dictionary entries referenced by schedule/request days cannot be deleted. - Disabled work-week types cannot be newly assigned. - Permissions are checked inside actions, not only Blade. Review and harden direct URLs and crafted Livewire requests. Use Arabic blocked-operation messages and existing confirmation/toast components. Search for all direct writes to status, reserved_days, used_days, remaining_days, and request-day lifecycle timestamps outside authorized services. Refactor any remaining unsafe path. Do not create tests or run migrations unless requested. Run Pint, php -l, filtered route inspection, mutation search, and diff review. Report every restriction and any policy decision still unresolved. PROMPT 12 - EXISTING DATA RECONCILIATION ======================================== Implement Phase 12 of the Vacation System V2 plan: Existing Data Reconciliation. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md, current database counts, all new services/generator, and old lifecycle code history. Recheck counts because the earlier audit of 90 employees, 1 request, 0 request days, and 1 holiday may now be outdated. Strict scope: Create a safe, idempotent reconciliation command with dry-run as the default and an explicit apply option. Do not remove legacy columns. The command must: 1. Report employees without work-week types. 2. Assign the approved default type only in apply mode and only where null. 3. Report official holidays and their stored balance-deduction values for administrative review. 4. Report requests missing snapshots or request-day rows. 5. Generate legacy request days only using an explicitly approved snapshot policy. 6. Recalculate requested_calendar_days, working_days, and deductible_days. 7. Calculate expected balance reservations and usage from request/day states. 8. Compare expected and current balances per employee/type/year. 9. Output precise deltas; never blindly reset reserved_days or used_days. 10. Require explicit apply confirmation/options before any data mutation. 11. Lock affected records and apply each balance correction transactionally. 12. Record conflicts instead of guessing when manual old working_days differs from generated totals. Status policy: - submitted/under_review: no reservation under new logic - approved future dates: reserved - approved past dates: processed according to approved cutoff policy - rejected/cancelled: no unprocessed reservations - archived legacy requests: validate history before converting to completed Do not run apply mode unless explicitly requested. Dry-run may be run only if it is guaranteed read-only and the user has authorized execution. Do not create tests. Run Pint, php -l, command discovery, help output, and diff review. Report command options, dry-run output design, idempotency, conflict handling, transaction boundaries, and steps required before apply. PROMPT 13 - LEGACY FIELD CONTRACT CLEANUP ========================================= Implement Phase 13 of the Vacation System V2 plan only after Phase 12 reconciliation has completed and been approved. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md. Inspect migration status, reconciliation results, all code references, command code, PDFs, views, filters, and database constraints. Strict scope: Create contract-cleanup migrations and remove obsolete application references only when replacement data is complete. Candidate cleanup: - Remove week_days.is_weekend after all logic uses work-week type days. - Remove or safely rename vacation_request_days.is_weekend after is_weekly_off is fully populated and used. - Remove archived from vacation_requests.status after all request rows and code use completed. - Make employees.work_week_type_id non-nullable after confirming no nulls. - Make vacation_requests.work_week_type_id required where safe, with an explicit legacy-row strategy. Before each destructive change: 1. Search the entire codebase for references. 2. Add migration precondition checks or fail clearly when data is incomplete. 3. Preserve all current attributes when changing columns. 4. Provide a realistic down() migration where data restoration is possible. 5. Do not remove vacation-year archived behavior. 6. Do not drop official-holiday balance policy. Do not run destructive migrations unless explicitly requested. Do not create tests. Run Pint, php -l, migrate:status, full reference searches, and diff review. Report every removed field/reference, precondition, rollback limitation, and any cleanup intentionally deferred. PROMPT 14 - MANUAL VERIFICATION AND CONTROLLED ROLLOUT REVIEW ============================================================= Perform Phase 14 of the Vacation System V2 plan. Project path and plan: /Users/yahyaashawish/Herd/burijeEapps /Users/yahyaashawish/Herd/burijeEapps/output/txt/vacation-system-implementation-plan-v2.txt Read AGENTS.md and inspect all completed V2 phases. This project explicitly prohibits creating test code. Do not add unit, feature, Pest, PHPUnit, Livewire, browser-test, or temporary verification scripts. Perform non-destructive verification and prepare a rollout report. Code verification: - Run vendor/bin/pint --dirty --format agent. - Run php -l on changed PHP files. - Inspect route:list for all new routes. - Inspect schedule:list and command discovery. - Inspect migrate:status. - Search for old direct request/balance mutation logic. - Search for request archived labels and legacy weekend logic. - Review Git diff and unrelated dirty files. Browser/manual scenarios using an authorized local session: 1. Employee A: Friday/Saturday off. 2. Employee B: Friday only off. 3. Thursday request with connected setting disabled. 4. Thursday request with connected setting enabled. 5. Sunday-through-Thursday request adds only following weekly-off block. 6. Holiday configured not to deduct produces zero balance effect. 7. Holiday configured to deduct produces a deductible day. 8. Non-balance vacation type deducts nothing. 9. Submission changes no balance. 10. Approval increases reserved only. 11. Insufficient available balance blocks approval. 12. Overlapping deductible dates block approval. 13. Daily processing moves equal value from reserved to used. 14. Re-running processing does not duplicate consumption. 15. Approved cancellation releases only unprocessed reservations. 16. Completion occurs after the latest deductible generated date and displays منتهي. 17. Employee schedule/settings changes do not rewrite approved request snapshots. 18. Permissions and direct URLs enforce all restrictions. 19. Arabic validation, toast, confirmation, badges, responsive forms, tables, and submenu active states render correctly. 20. Vacation request PDF renders correctly with generated deductible totals. Do not mutate real production data. If a scenario requires data mutation and no safe local/staging data is available, document it as pending rather than creating records without authorization. Final rollout report: - Completed phases and files. - Pending migrations and their order. - Required seed/backfill/reconciliation commands. - Required settings and work-week assignments. - Data conflicts. - Manual scenario results. - Rollback risks. - Monitoring requirements for reserved/used balances and processing logs. - Clear go/no-go recommendation. END OF PROMPT PACK ==================