initial: bootstrap from BukidBountyApp base

docs/completed/chklist-20260402171000.md

@@ -0,0 +1,59 @@
+# Checklist: Systematic Permission Verification (103 Actions)
+
+## Phase 1: Test Environment Setup (Using Tinker)
+- [ ] Create test accounts for all roles if they do not exist:
+    - **ULTIMATE**: `777` (already exists).
+    - **SUPER_OPERATOR**: `test_super_op`
+    - **OPERATOR**: `test_op`
+    - **COORDINATOR**: `test_coord`
+    - **RIDER**: `test_rider`
+    - **POS_TERMINAL**: `test_pos`
+    - **USER**: `test_user`
+- [ ] Ensure all test accounts use the password: `123123`.
+
+## Phase 2: Role-Based Verification (ULTIMATE - 777)
+- [ ] **Auth**: Login to `777` with `123123`. Confirm success.
+- [ ] **User Mgmt**: Navigate to `/user-list`. Verify full list of users is visible.
+- [ ] **Action Group: Create User Checks**
+    - [ ] Navigate to `/create-user`.
+    - [ ] Verify dropdown includes `ULTIMATE`, `SUPER_OPERATOR`, `OPERATOR`, `RIDER`, etc.
+    - [ ] Check if `CreateUserPOSTerminal` action is functional.
+- [ ] **Action Group: Ultimate Tools Checks**
+    - [ ] Navigate to `/ultimate-console`. Confirm it loads with full stats and maintenance toggles.
+
+## Phase 3: Role-Based Verification (SUPER_OPERATOR)
+- [ ] **Auth**: Login to `test_super_op`.
+- [ ] **Blocking Check**: Access `/ultimate-console`. Confirm it redirects to `/`.
+- [ ] **Action Group: Create User Checks**
+    - [ ] Navigate to `/create-user`.
+    - [ ] Verify `ULTIMATE` choice is NOT in the role dropdown.
+    - [ ] Verify `SUPER_OPERATOR` and others are visible.
+- [ ] **Logistics**: Access `/shipment-list`. Verify if they can see shipments.
+
+## Phase 4: Role-Based Verification (OPERATOR)
+- [ ] **Auth**: Login to `test_op`.
+- [ ] **Action Group: Create User Checks**
+    - [ ] Navigate to `/create-user`.
+    - [ ] Verify only `COORDINATOR`, `SUPPLIER`, `STORE_OWNER`, `RIDER`, `POS_TERMINAL` are present (as per `UserTypeService`).
+- [ ] **Action Group: Reports Checks**
+    - [ ] Navigate to `/pos-history`. Verify access per store context.
+
+## Phase 5: Role-Based Verification (RIDER)
+- [ ] **Auth**: Login to `test_rider`.
+- [ ] **Action: ViewShipments**: Navigate to `/shipment-list`.
+    - [ ] Verify view status (per `UserPermissions.php` roles array).
+    - [ ] Document result: Allowed or Restricted?
+
+## Phase 6: Role-Based Verification (POS_TERMINAL)
+- [ ] **Auth**: Login to `test_pos`.
+- [ ] **UI Focus Check**: Verify if "Pos Main" is the default or prioritized interface.
+- [ ] **Blocking Check**: Attempt access to `/user-list`. Verify if they are blocked.
+
+## Phase 7: Final Matrix Audit (All 103 Actions)
+- [ ] Match each action in `UserActions.php` with actual behavior in the UI.
+- [ ] Document all observed permission gaps (e.g. `UpdateShipmentStatus` not assigned to `RIDER`).
+- [ ] Verify for `PUBLIC` access (unauthenticated) that only marketplace and pos-start are reachable.
+
+## Phase 8: Dictionary Sync
+- [ ] Update `ai-docs/dictionary.md` with any findings or new established RBAC patterns.
+- [ ] Commit and push the dictionary update.

docs/completed/chklist-20260402230000.md

@@ -0,0 +1,41 @@
+# Checklist: Cooperative Member & User Info Expansion
+
+## 1. Database Expansion
+- [x] **Migration**: Create `2026_04_02_000001_expand_user_infos_table.php`:
+    - Add `firstname`, `middlename`, `lastname`, `suffix`, `gender`, `dob` (date).
+    - Add social accounts: `messenger_id`, `viber_number`, `tiktok_username`.
+    - Add address components: `region`, `province`, `city`, `barangay`.
+    - Add family: `civil_status`, `children_count` (int), `education_level`, `course`, `school`, `year_last_attended`.
+    - Add livelihood: `livelihood_source`, `last_company`, `last_position`, `last_employment_year`.
+    - Add government: `tin`, `philhealth_id`, `gov_id`.
+    - Add emergency contact info: `emergency_contact_name`, `emergency_contact_address`, `emergency_contact_phone`, `emergency_contact_relation`, `emergency_contact_user_id` (nullable foreign key).
+- [x] **Migration**: Create `2026_04_02_000002_expand_cooperative_members_table.php`:
+    - Add `membership_type`, `membership_level`, `officer_position`, `officer_level`, `concurrent_position`, `concurrent_level`, `cooperative_name_alt`, `cooperative_position`, `year_beginning`.
+
+## 2. Model Updates
+- [x] **App/Models/Market/UserInfo.php**:
+    - Update `$fillable` array with new fields.
+    - Add `emergencyContactUser()` relation (BelongsTo User).
+- [x] **App/Models/Market/CooperativeMember.php**:
+    - Update `$fillable` with new membership fields.
+
+## 3. Controller Logic
+- [x] **App/Http/Controllers/Market/UserInfoController.php**:
+    - Update `updateUserInfo` to handle newly added fields.
+    - Implement logic in `updateUserInfo` to automatically populate `emergency_contact_user_id` if the `emergency_contact_phone` matches a registered user's `mobile_number`.
+- [x] **App/Http/Controllers/Market/CooperativeController.php**:
+    - Ensure membership field updates are supported in `joinCooperative` and `addMember` endpoints.
+
+## 4. UI Redesign (Vue 3)
+- [x] **Resources/js/Pages/UserInfoEdit.vue**:
+    - Group fields into expandable sections or card groups (Personal, Social, Family/Education, Livelihood, etc.).
+    - Implement the "Emergency Contact" section with a visual cue if linked to a system user.
+
+## 5. Seeders
+- [x] **Database/Seeders/UpdateUserInfoSeeder.php**:
+    - Ensure sample data from `README.md` (Rex Moran Loba) can be seeded into a test user profile.
+
+## 6. Execution & Build
+- [ ] Run migrations: `docker compose exec bukidbountyapp php artisan migrate`
+- [ ] Run build: `npm run build`
+- [ ] Restart: `docker restart bukidbountyapp`

docs/completed/chklist-20260403-032827.md

@@ -0,0 +1,71 @@
+# Checklist: UI Component Standardization & Premium Elevation
+
+## 🧩 1. Core Component Enhancements (Phase 1)
+Upgrade components in `resources/js/Components/Core/Forms/` with premium logic and props.
+
+- [x] **`InputGroup.vue`**:
+    - [x] Add `error` (String) prop for displaying validation messages.
+    - [x] Add `hint` (String) prop for supporting text under the input.
+    - [x] Add `isPremium` (Boolean, default true) for enabling premium glassmorphism styles.
+    - [x] Add `variant` (String, 'default' | 'glass' | 'soft') prop.
+    - [x] Standardize the label to include a red asterisk if `required` is true.
+    - [x] Refactor styles to pull from global theme variables (`--bg-secondary`, `--text-primary`).
+
+- [x] **`InputGroupSelect.vue`**:
+    - [x] Add `error` and `hint` props.
+    - [x] Add `isPremium` and `variant` props.
+    - [x] Support flexible `options` format (Array of Strings or Array of Objects `{ value, text }`).
+    - [x] Update dropdown arrow styling for premium look.
+
+- [x] **`InputGroupButton.vue`**:
+    - [x] Add `variant` (String, 'primary' | 'secondary' | 'outline' | 'danger' | 'glass' | 'text').
+    - [x] Add `loading` (Boolean) to show integrated `LoadingSpinner`.
+    - [x] Add `size` (String, 'sm' | 'md' | 'lg').
+    - [x] Add `disabled` prop handling (visual and functional).
+    - [x] Add default slot support for complex button content (icons + text).
+    - [x] Remove hardcoded `text` prop requirement if slot is present.
+
+- [x] **`InputGroupTextarea.vue`**:
+    - [x] Add `rows` (Number, default 3) prop.
+    - [x] Add `error` and `hint` props.
+    - [x] Add `isPremium` and `variant` props.
+    - [x] Ensure styling matches `InputGroup.vue`.
+
+- [x] **`InputGroupCheckbox.vue`**:
+    - [x] Add `label` (String) prop.
+    - [x] Add `error` prop.
+    - [x] Add `isSwitch` (Boolean) prop for toggle-style checkbox.
+    - [x] Replace native checkbox with a premium, theme-aware custom design.
+
+- [x] **`CardSimple.vue`**:
+    - [x] Add `isPremium` / `glass` (Boolean) prop for background glassmorphism.
+    - [x] Add `noPadding` (Boolean) for custom body content.
+    - [x] Add `shadow` (String, 'none' | 'sm' | 'md' | 'lg') prop.
+
+## 🔍 2. Scanning & Replacement (Phase 2)
+Identify and replace raw HTML elements in all pages.
+
+### High-Priority Pages (Standardize first)
+- [x] **`EditStoreUltimate.vue`**:
+    - [x] Replace `input` with `InputGroup`.
+    - [x] Replace `select` with `InputGroupSelect`.
+    - [x] Replace `textarea` with `InputGroupTextarea`.
+    - [x] Replace `button` with `InputGroupButton`.
+    - [x] Remove excessive `<style>` blocks once standardized components are used.
+- [x] **`UserInfoEdit.vue`**:
+    - [x] Replace extensive set of ~40+ raw `input` and `select` with `InputGroup` components.
+- [x] **`ShipmentDetail.vue`**:
+    - [x] Standardize action buttons with `InputGroupButton` variants.
+- [x] **`AccountSettings.vue`**:
+    - [x] Replace user info inputs and buttons.
+
+### Page Audit & Cleanup
+- [x] **`resources/js/Pages/`**: Scan all remaining files for raw `<button>`, `<input>`, `<select>`, `<textarea>`.
+- [x] **Consistency Check**: Verify that all replaced components correctly bind `v-model` and handle events like `@click` or `@change`.
+- [x] **Dead Code Removal**: Search for and remove local CSS like `.premium-input`, `.premium-select`, `.btn-premium-launch` from component `<style>` blocks after they are integrated into the core components.
+
+## 🏗️ 3. Build & Verification (Phase 3)
+- [x] **NPM Build**: Run `npm run build` to ensure all changes are compiled.
+- [x] **Visual Audit**: Verify the "WOW" factor across different pages and screen sizes.
+- [x] **Docker Restart**: `docker restart bukidbountyapp`.
+- [x] **Baseline Check**: Run tests again to ensure no regressions in functional logic.

docs/completed/chklist-20260403024500.md

@@ -0,0 +1,51 @@
+# Checklist: POS Access Control & Login Hardening
+
+## 1. **User Type Check & Parent Role Configuration**
+- [x] **app/Http/Controllers/Helpers/Permissions/UserPermissions.php**: Ensure `POS_TERMINAL` role has:
+  - `ViewPosReports`
+  - `ViewCustomers`
+  - `ViewUserInfo` (For customer lookup)
+  - `ManageUserInfo` (For customer lookup)
+  - `ViewShipments` (Optional? User didn't specify, but often needed).
+- [x] **app/Http/Controllers/Helpers/Permissions/UserPermissions.php**: Verify that `STORE_MANAGER` is the only parent role for `POS_TERMINAL`.
+- [x] **app/Http/Controllers/Helpers/Permissions/UserTypeService.php**: Ensure `STORE_MANAGER` (and above) can create `POS_TERMINAL` users.
+
+## 2. **Store-Level Authorization Helper**
+- [x] Create a helper to verify if a user is allowed to access a specific store's POS/Reports.
+- [x] Implementation:
+  ```php
+  public static function isUserAllowedAccessToStore($user, $storeId): bool
+  {
+      if ($user->acct_type === UserTypes::ULTIMATE) return true;
+      
+      $store = Store::find($storeId);
+      if (!$store) return false;
+
+      // Check if user owns or manages the store
+      if ($user->id === $store->owner_id || $user->id === $store->manager_id) return true;
+
+      // Check if user's parent is the owner/manager (for POS_TERMINAL/RIDER)
+      if ($user->parentuid === $store->owner_id || $user->parentuid === $store->manager_id) return true;
+
+      // check if user is an ancestor of the owner/manager
+      if (self::isAncestorOf($user, $store->owner) || self::isAncestorOf($user, $store->manager)) return true;
+
+      return false;
+  }
+  ```
+
+## 3. **Controller Hardening**
+- [x] **app/Http/Controllers/Market/PosController.php**: Apply `isUserAllowedAccessToStore` in `startSession` using `store_hash`.
+- [x] **app/Http/Controllers/Market/PosController.php**: Apply `isUserAllowedAccessToStore` in `getSession` when looking up a store session.
+- [x] **app/Http/Controllers/Market/PosController.php**: Apply `isUserAllowedAccessToStore` in `getTodayStats`.
+- [x] **app/Http/Controllers/Market/PosController.php**: Apply `isUserAllowedAccessToStore` in `getPosSessions`.
+- [x] **app/Http/Controllers/Market/PosController.php**: Apply `isUserAllowedAccessToStore` in `getCustomers`.
+
+## 4. **Testing & Validation**
+- [x] Create **tests/Feature/PosAccessTest.php**:
+  - Test `POS_TERMINAL` login.
+  - Test access to authorized store (Success).
+  - Test access to unauthorized store (Fail - 401/403).
+  - Test access to manager-only pages (Fail - 302).
+- [x] Run the tests and ensure 100% success.
+- [x] Perform a final sanity check on the UI (`PosMain.vue`) to ensure no broken links.

docs/completed/chklist-20260403030000.md

@@ -0,0 +1,29 @@
+# Checklist: Store and Product Management (Big 3 & Multiple Managers)
+
+## 📦 Database & Models
+- [x] **Migration**: Create `store_managers` table with standard fields (`hashkey`, `created_by`, `updated_by`, `is_active`).
+- [x] **Model**: Create `app/Models/Market/StoreManager.php`.
+- [x] **Model**: Add `managers()` relationship to `app/Models/Market/Store.php`.
+- [x] **Dictionary**: Update `ai-docs/dictionary.md` with "Big 3" definition.
+
+## 🔐 Permissions & Hierarchy
+- [x] **UserPermissions**: Ensure `ULTIMATE`, `SUPER_OPERATOR`, `OPERATOR` are identified as "Big 3".
+- [x] **ProductPermissions**: Add `UserActions::ModifyAllProducts` to `OPERATOR` role in `ProductPermissionsDefinition`.
+- [x] **ProductPermissions**: Extend `isActionAllowed` to check if current user is a parent of any of the store's managers (not just the owner).
+- [x] **Permissions Helper**: Add `isParentOfTargetUser` recursive check for Store Owner and all Store Managers.
+
+## 🏪 Store Management
+- [x] **StoreController**: Refactor `listStores_Admin` to filter by "Big 3" OR "Parent of Owner" OR "Parent of any Manager".
+- [x] **StoreController**: Ensure `update` and `deleteStore_Admin` enforce the same hierarchy checks.
+- [x] **StoreController**: Update `canUserAccessPos` to include a check against the `store_managers` table.
+- [x] **StoreController**: Support saving multiple managers in `store` and `update` methods (input should be an array of user hashkeys).
+
+## 🍎 Product Management
+- [x] **ProductController**: Refactor `editProductAdmin` - Only "Big 3" can perform global edits (updating `prd_items` table fields). Non-Big 3 can only update their own store's pivot data if they are a manager/owner.
+- [x] **ProductController**: Ensure `createNew_Admin` requires Big 3 or ownership/parentship of the target store.
+- [x] **ProductController**: Update `AssignProductToOwnStore` to support the new `store_managers` lookup.
+
+## 🖥️ Frontend Changes
+- [x] **CreateStore.vue / EditStore.vue**: Implement a multi-select for managers.
+- [x] **ManageProductAdmin.vue**: Only show global edit fields to Big 3 users.
+- [x] **StoreDetail.vue**: Ensure correct action buttons (Edit, POS) are visible only based on the new permission logic.

docs/completed/chklist-20260403142500.md

@@ -0,0 +1,34 @@
+# Checklist: Responsive UI Transition (800px constraint removal)
+
+## 📋 Pre-Implementation
+- [x] Identify hardcoded 800px constraints in JS/Vue files.
+- [x] Verify baseline stability (`composer test`).
+
+## 🛠️ Implementation
+
+### 1. **Global Configuration in `resources/js/app.js`**
+- [x] Locate the inline `<style>` template (Lines 251-260).
+- [x] Modify `body` `max-width` from `800px` to `var(--layout-max-width, 100%)`.
+- [x] Add `:root` variable `--layout-max-width: 1440px;` (or preferred max desktop width).
+- [x] Standardize centering: `margin: 0 auto; width: 100%;`.
+
+### 2. **Header Layout Adjustment (`TopHeader.vue`)**
+- [x] Update `.header` `max-width: 800px` to `var(--layout-max-width, 100%)`.
+- [x] Ensure `.tf-container` inside the header provides reasonable content padding/centering.
+
+### 3. **Bottom Navigation Adjustment (`BottomNav.vue`)**
+- [x] Update `.bottom-navigation-bar` `max-width: 800px` to `var(--layout-max-width, 100%)`.
+- [x] Ensure the navigation bar stays centered at the bottom of the visible area.
+
+### 4. **UI Store / Settings Sync**
+- [x] Check if `uiStore.isFullWidth` correctly overrides these new variables (likely handled by the existing classes).
+
+### 5. **Documentation**
+- [x] Update `ai-docs/dictionary.md` with the new Layout Architecture details.
+
+## ✅ Verification
+- [ ] Build assets: `npm run build`.
+- [ ] Restart container: `docker restart bukidbountyapp`.
+- [ ] Verify landscape display on simulated devices (e.g., tablet landscape).
+- [ ] Verify portrait display remains centered and mobile-friendly.
+- [ ] Verify POS page still works in "Full Width" mode.

docs/completed/prt-20260402171000.md

@@ -0,0 +1,50 @@
+# Plan: User Creation, Login, and Access Testing
+
+## 🎯 Objective
+Verify that the RBAC system correctly restricts user creation based on account types and ensures that new users can successfully log in and access their respective dashboards.
+
+## 🏗️ Technical Approach
+The testing will be conducted using the browser tool to simulate real user interactions. We will iterate through each user type, perform creation attempts (both valid and invalid), and verify the results.
+
+### 1. Test Data Setup
+We need a set of "Parent" users for each type. I will verify if these exist or create them via the database if needed.
+- `ULTIMATE`: `admin` (assuming exists)
+- `SUPER_OPERATOR`: `test_super_op`
+- `OPERATOR`: `test_op`
+- `COORDINATOR`: `test_coord`
+- `STORE_OWNER`: `test_store_owner`
+- `USER`: `test_user`
+
+### 2. Creation Permission Matrix (Target vs Actor)
+| Actor \ Target | ULTIMATE | SUPER_OP | OPERATOR | COORD | SUPPLIER_O | WHOLESALE | SUPPLIER | STORE_OWNER | STORE_MGR | USER | RIDER | POS_T |
+| :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| **ULTIMATE** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| **SUPER_OP** | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+| **OPERATOR** | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ |
+| **COORD** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ | ✅ | ❌ |
+| **STORE_OWNER** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ✅ |
+| **USER** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
+
+### 3. Verification Steps
+1.  **Login** as the Actor user.
+2.  **Navigate** to the "Create User" page.
+3.  **Check** the "User Type" dropdown for allowed options.
+4.  **Attempt** to create an allowed user type:
+    - Fill form with valid data.
+    - Submit.
+    - Verify "Success" message.
+5.  **Attempt** to create a restricted user type (if UI allows selection or via direct API manipulation if possible, but primarily UI-based check).
+6.  **Login** as the newly created user to verify account activation.
+7.  **Logout** and repeat for next role.
+
+## 🛠️ Tools & Commands
+- **Browser**: Interaction and visual verification.
+- **Tinker**: Quick user creation for testing setup if needed.
+- **Docker**: Build and restart after any potential fixes (though this task is primarily testing).
+
+## 📅 Timeline
+- Phase 1: Environment Readiness (Verify/Create Actor Users)
+- Phase 2: Browser Testing - ULTIMATE & SUPER_OPERATOR
+- Phase 3: Browser Testing - OPERATOR & COORDINATOR
+- Phase 4: Browser Testing - STORE_OWNER & USER (Restriction check)
+- Phase 5: Final Report and Cleanup

docs/completed/prt-20260402230000.md

@@ -0,0 +1,27 @@
+# Plan: Cooperative Member and User Information Enhancement
+
+## 🎯 Objective
+Expand the user information and cooperative membership system to include all fields defined in the `README.md` specification. Ensure a premium UI is maintained for managing these fields. Add logic to automatically link emergency contact info to existing system users.
+
+## 🏗️ Architecture & Requirements
+1. **Database Expansion**:
+    - **Table `user_infos`**: Add fields for personal info, social accounts, address fragments, family/education, employment/livelihood, and government info.
+    - **Table `cooperative_members`**: Add membership-specific details (level, officer status, concurrent positions, etc.).
+    - **Foreign Keys**: Ensure `emergency_contact_user_id` is added to `user_infos` to link emergency contacts to existing users.
+2. **Model Updates**:
+    - `UserInfo.php`: Add new fillables and an `emergencyContactUser` relation.
+    - `CooperativeMember.php`: Add fillables for membership details.
+3. **Logic Enhancements**:
+    - `UserInfoController.php`: Add logic to search for a user by name or phone during emergency contact updates to link them.
+4. **UI Updates**:
+    - `UserInfoEdit.vue`: Redesign to handle the expanded field set with a cleaner, grouped layout (Personal, Social, Family/Education, etc.).
+    - Add a toggle/search for linking emergency contacts to existing users.
+
+## 🛠️ Proposed Tech Stack
+- **Backend**: Laravel-style Hypervel (PHP 8.2+).
+- **Frontend**: Vue 3 with Composition API.
+- **Styling**: Bootstrap 5 with premium glassmorphism and `.rounded-pill`.
+
+## 🔄 Dependencies
+- Existing `user_infos` and `cooperative_members` tables.
+- `UserPermissions` and `UserActions` for access control.

docs/completed/prt-20260403-032827.md

@@ -0,0 +1,54 @@
+# Plan: Standardize Vue Element Components & Design System Elevation
+
+## 🎯 Goal
+Standardize all UI elements across the application by replacing raw HTML elements (`button`, `input`, `select`, `textarea`, `label`, `checkbox`) with a centralized set of highly customizable, premium-designed Vue components. This will ensure visual consistency, reduce code duplication in `<style>` blocks, and provide a state-of-the-art "WOW" factor for the user.
+
+## 🏗️ Technical Approach
+
+### 1. Component Enhancements (`resources/js/Components/Core/Forms/`)
+We will upgrade the existing "InputGroup" components to support premium aesthetics (glassmorphism, subtle gradients, and micro-animations) and deep customizability through props.
+
+#### Shared Features across all Form Components:
+- **Premium Styling**: Default to a high-end look (rounded corners, soft shadows, theme-aware glass effects).
+- **Error Handling**: Standardized `error` prop and error message display.
+- **Labels & Hints**: Consistent handling of labels (with optional required asterisks) and hint text.
+- **Size Variants**: `sm`, `md` (default), `lg`.
+- **States**: `disabled`, `readonly`, `loading`.
+
+#### Specific Component Upgrades:
+- **`InputGroup.vue`**: 
+    - Support for different text-based input types (text, email, password, date, etc.).
+    - Built-in clear button option.
+- **`InputGroupSelect.vue`**:
+    - Consistent icon positioning and custom dropdown styling.
+- **`InputGroupTextarea.vue`**:
+    - Support for `rows`, `autoResize`.
+- **`InputGroupButton.vue`**:
+    - New `variant` prop: `primary`, `secondary`, `outline`, `glass`, `danger`, `text`.
+    - Integrated `LoadingSpinner` when `loading` prop is true.
+    - Hover animations and scale effects.
+- **`InputGroupCheckbox.vue`**:
+    - Premium custom checkbox design (replacing browser defaults).
+    - Support for toggle/switch style.
+
+### 2. New Core Components
+- **`BaseCard.vue` / `PremiumCard.vue`**: To replace repeated card structures like those in `EditStoreUltimate.vue`, supporting glassmorphism and header/footer slots.
+
+### 3. Scanning and Replacement Phase
+A systematic approach to scan `resources/js/Pages/` and replace raw elements:
+1.  **Batch 1: Core Pages** (Dashboard, Home, User Profiles).
+2.  **Batch 2: Market Pages** (Store Management, Add/Edit Store, POS).
+3.  **Batch 3: Configuration & Settings**.
+
+## 🎨 Design Tokens (Global Update)
+Ensure `app.js` or a new `theme.css` contains the necessary variables for these premium components to pull from, respecting the `dark-mode` state.
+
+## 🚀 Implementation Workflow
+1.  **Refine Core Components**: Update the `Core/Forms` components with new props and premium logic.
+2.  **Component Proofing**: Test the new components in a dedicated playground page or by updating a single high-visibility page (e.g., `EditStoreUltimate.vue`).
+3.  **Broad Replacement**: Iterate through all identified pages, replacing raw HTML with standardized components and removing redundant `<style>` code.
+4.  **Audit**: Final check for any missed raw elements or styling inconsistencies.
+
+## ⚠️ Stability & Compatibility
+- Maintain existing `modelValue` / `v-model` compatibility to avoid breaking functional logic.
+- Ensure props are optional or have sensible defaults to minimize immediate breakage during the transition.

docs/completed/prt-20260403024500.md

@@ -0,0 +1,46 @@
+# Task: POS Login & Access Control Hardening
+
+## Background
+The user wants to ensure that `POS_TERMINAL` accounts, which are children of a `STORE_MANAGER`, can:
+1. Access the POS for the store managed/owned by their parent.
+2. NOT access the POS or data of other stores outside their parent's hierarchy.
+3. NOT access features "above" their role (already partially handled by RBAC, but needs verification).
+
+## Requirements
+- [ ] **RBAC Verification**: Verify that `POS_TERMINAL` role contains the necessary permissions but doesn't overreach into `STORE_MANAGER` or `STORE_OWNER` territory.
+- [ ] **Cross-Store Access Control**: Ensure `PosController` methods (`startSession`, `getTodayStats`, `getCustomers`, `getPosSessions`, `listHistory`) explicitly check if the authenticated user (especially `POS_TERMINAL`) is authorized for the requested `store_hash`.
+- [ ] **Hierarchy Boundary**: Ensure `POS_TERMINAL` cannot access administrative pages or data that their parent (`STORE_MANAGER`) is restricted from (already base logic, but needs testing).
+- [ ] **Testing Suite**: Create a comprehensive feature test to simulate the hierarchy and verify access attempts across multiple stores.
+
+## Technical Approach
+1. **Store Access Logic**:
+   - Create a static method in `UserPermissions` or a trait to check `isUserAllowedToAccessStore(User $user, Store $store)`.
+   - Logic:
+     - IF Ultimate user -> Allow.
+     - IF $user->id is $store->owner_id or $store->manager_id -> Allow.
+     - IF $user is an ancestor of $store->owner or $store->manager -> Allow.
+     - IF $user is a child of the store manager/owner AND role is `POS_TERMINAL` or `RIDER` -> Allow.
+2. **Controller Hardening**:
+   - Update `app/Http/Controllers/Market/PosController.php` to use this check in all methods receiving a `store_hash`.
+3. **Test Case**:
+   - `tests/Feature/PosAccessTest.php` will be created to automate these checks.
+
+## Impact Analysis
+- Refines security for multi-store environments.
+- Ensures data isolation among different franchises or store locations.
+## Verified Findings (as of 2026-04-03)
+Based on the audit report in @[docs/tasks/pos-access-control-test-report.md], the following findings have been verified and need to be addressed:
+
+- [x] **RBAC Status**: `POS_TERMINAL` has the necessary base permissions (`ViewPosReports`, `ViewCustomers`, `ViewUserInfo`, `ManageUserInfo`).
+- [x] **Permission Gap**: `STORE_MANAGER` is missing the `CreateUserPOSTerminal` action permission in `UserPermissions::roles()`.
+- [x] **Missing Helper**: `isUserAllowedAccessToStore` is not implemented in `UserPermissions.php`.
+- [x] **Controller Security Gaps**:
+    - `PosController@startSession`: No store-level check or authentication for non-terminal logins.
+    - `PosController@getSession`: No store-level check.
+    - `PosController@getPosSessions`: Missing ALL permission/store-level checks.
+    - `PosController@getTodayStats`: Missing store-level check.
+    - `PosController@getCustomers`: Missing store-level check.
+- [x] **Missing Infrastructure**: `isAncestorOf` helper is missing (needed for hierarchical store access).
+- [x] **Missing Tests**: `tests/Feature/PosAccessTest.php` does not exist.
+- [x] **UI Security**: `PosMain.vue` is functional but lacks any store-level authorization checks or error handling for unauthorized access.
+- [x] **Performance Optimization**: `PosController` already uses `CacheHelper` and raw DB queries in some areas, but these need to be maintained during hardening.

docs/completed/prt-20260403030000.md

@@ -0,0 +1,56 @@
+# Plan: Store and Product Management Refactoring (RBAC Hardening)
+
+This plan outlines the implementation of stricter role-based access control (RBAC) for Store and Product management, following the "Big 3" hierarchy and supporting multiple store managers.
+
+## 🏗️ Technical Approach
+
+### 1. Data Architecture: Multiple Store Managers
+- **New Table**: `store_managers`
+    - `id` (INT)
+    - `hashkey` (VARCHAR 300, unique)
+    - `store_id` (INT, foreign key to `str`)
+    - `user_id` (INT, foreign key to `users`)
+    - `created_by` (INT)
+    - `updated_by` (INT)
+    - `is_active` (BOOLEAN, default true)
+    - `created_at`, `updated_at`
+- **Model**: `App\Models\Market\StoreManager`
+- **Relationship**: `Store` hasMany `StoreManager` (and `belongsToMany` via `users`).
+
+### 2. RBAC: The "Big 3"
+- **Definition**: `ULTIMATE`, `SUPER_OPERATOR`, `OPERATOR`.
+- **Global Access**: The Big 3 can list, view, and manage ANY store.
+- **Hierarchy Access**: Other roles (e.g., Coordinator, Supplier Overseer) can only list or manage stores where they are a direct or indirect parent of the Store Owner OR any of the Store Managers.
+- **Global Product Editing**: Restrict `ModifyAllProducts` action to only the Big 3.
+
+### 3. Controller Refactoring
+- **StoreController**:
+    - `listStores_Admin`: Implement strict hierarchy-based filtering for non-Big 3 users.
+    - `update`: Enforce hierarchy-based check to prevent unauthorized modifications.
+    - `viewStoreDetails`: Ensure correct "can_edit" flag based on hierarchy.
+- **ProductController**:
+    - `editProductAdmin`: Change global edit logic - allow ONLY Big 3 to edit global product fields. Remove the "creator can edit globally" for non-Big 3 if they don't have the permission.
+    - `AssignProductToOwnStore`: Update to include check for multiple managers.
+
+## 🛠️ Components to Update
+
+### Backend
+- `app/Http/Controllers/Market/StoreController.php`
+- `app/Http/Controllers/Market/ProductController.php`
+- `app/Http/Controllers/Helpers/Permissions/ProductPermissions.php`
+- `app/Http/Controllers/Helpers/Permissions/UserPermissions.php`
+- `app/Models/Market/Store.php`
+- `app/Models/Market/StoreManager.php` (New)
+
+### Frontend
+- `resources/js/Pages/CreateStore.vue`: Add multi-manager selection.
+- `resources/js/Pages/EditStore.vue`: Update management UI.
+- `resources/js/Pages/ManageProductAdmin.vue`: Enforce global edit restrictions in the UI.
+
+## 📅 Phases
+
+1. **Phase 1: Database and Models** (Migration and StoreManager model).
+2. **Phase 2: RBAC Logic Hardening** (Update Permissions helpers).
+3. **Phase 3: Store Management Refactoring** (Hierarchy-based filtering).
+4. **Phase 4: Product Management Refactoring** (Global edit restrictions).
+5. **Phase 5: UI Integration** (Multi-manager picker and permission guards).

docs/completed/prt-20260403142500.md

@@ -0,0 +1,37 @@
+# High-Level Plan: Responsive UI Transition
+
+## Objective
+Analyze and resolve the "portrait-only" feel of the UI by removing hardcoded maximum width constraints (800px) and implementing a responsive, centered layout that supports landscape and ultra-wide displays.
+
+## Background
+The application currently injects a global style into the `<head>` via `resources/js/app.js` that limits the `body` to `max-width: 800px`. This design choice, while good for mobile-first "superapps", prevents the UI from utilizing desktop or landscape screen real estate, causing it to appear as a narrow column.
+
+## Technical Approach
+
+### 1. Centralized Layout Configuration
+- Introduce CSS variables in `:root` or `body` to define `---layout-max-width`.
+- Default the max-width to a more modern value (e.g., `1440px`) or set it to `none` for full responsiveness with internal containers.
+
+### 2. Update Global Styles (app.js)
+- Modify the `body` style injection in `resources/js/app.js`.
+- Change `max-width: 800px` to a responsive variable or remove it.
+- Ensure `margin: 0 auto` is maintained to keep the content centered on large screens.
+
+### 3. Component Updates
+- **TopHeader.vue**: Update `.header` to use the new layout width.
+- **BottomNav.vue**: Update `.bottom-navigation-bar` to use the new layout width.
+- **Containers**: Ensure `.tf-container` classes throughout the app are configured to limit content width to a readable measure (e.g., 1200px) while allowing the background/header to span wider.
+
+### 4. Responsiveness
+- Ensure that on mobile, the UI still behaves as expected (100% width).
+- On landscape/desktop, the UI should expand or stay centered without being artificially "pinched" to 800px.
+
+## Affected Files
+- `resources/js/app.js`
+- `resources/js/Pages/Core/Fragments/TopHeader.vue`
+- `resources/js/Pages/Core/Fragments/BottomNav.vue`
+- `ai-docs/dictionary.md` (Update layout definitions)
+
+## Verification
+- Visual inspection on different screen sizes (Mobile, Tablet, Desktop, Landscape).
+- Verify `is-full-width` mode (used for POS) still works correctly.

docs/completed/readme.md

@@ -0,0 +1,4 @@
+Completed tasks (prompt-*.md && prd-*.md) files go here.
+the new names are 
+prompt-*.md = prt-{datetimenumber}.md
+prd-*.md = chklist-{datetimenumber}.md