Merge pull request #7 from Valourite/feature/code-updates

Feature/code updates

Author: Dayne-Valourite

.aider.chat.history.md

@@ -0,0 +1,57 @@
+
+# 2025-07-29 10:16:14.389830
++N
+
+# 2025-07-29 10:20:25.071517
++Please review the files, and let me know where I can make changes to improve the performance of this package. The repeater, from the EditRecord is very slow when I try and save a model that has been specified inside the config. 
+
+# 2025-07-29 10:35:07.201489
++Update the Form Resource so that only the fields that need to be reactive are reactive. It a filed does not need to be reactive, then don't set it as reactive or live
+
+# 2025-07-29 10:38:15.242235
++Edit the section repeater and the filed repeater to make them optimised, also remove the live and reactive where it is not needed. 
+
+# 2025-07-29 10:44:13.865938
++Based on the code provided, and what the README says about how data is stored on a modal. What would be a better way of storing data on a model, keep in mind that the data that is being stores is is modal instance specific, meaning that the instance of the model could have different data and even a different form stored on it 
+
+# 2025-07-29 10:44:33.049655
++Y
+
+# 2025-07-29 10:44:43.810567
++/run php artisan make:migration create_form_responses_table
+
+# 2025-07-29 10:44:43.810656
++/run php artisan make:migration create_form_responses_table
+
+# 2025-07-29 10:44:48.627309
++Y
+
+# 2025-07-29 10:44:51.193558
++/run php artisan make:model FormResponse
+
+# 2025-07-29 10:44:51.193664
++/run php artisan make:model FormResponse
+
+# 2025-07-29 10:44:52.988306
++Y
+
+# 2025-07-29 10:59:25.631519
++I need the response to be able to store the schema of the form, so that if the form is updated and the schema changed, if we view the response on a model, we can see what version of the form was used and what schema was used so that the correct schema for that response gets used. Whats the best way of doing that, would it be to copy the form across into the form response or would it be better that when the form gets updated, we create a new record always, ensuring that the form_id that links a form reponse will always include the correct schema as we can never change the schema on a form record. 
+
+# 2025-07-29 11:00:44.839789
++Y
+
+# 2025-07-29 11:04:40.505128
++Okay, you didnt listen to what I asked of you. I want to set it so that every form that gets created will create a record with timestamps, however when that form is updated, we create a new record only if the form schema is updated. This will allow the form response to always link to the form_id without having to copy the form schema, version and such into the form response record. Please update the files to handle this, also update the config to remove any refernces to being able to change how a form is version controlled. Also implement a version control on the form so that we can see the different forms over time. Essentially when a form schema gets updated, we need to make a new record. We do not then need to store the form shcema and the form version inside the form response, just the form_id
+
+# 2025-07-30 13:57:28.685710
++Y
+
+# 2025-07-30 13:57:38.378752
++N
+
+# 2025-07-30 13:58:08.680169
++Y
+
+# 2025-07-30 14:00:03.206428
++Based on all the files provided, please update the README.md file to reflect how a user should install and work with this package

.aider.input.history

@@ -0,0 +1,93 @@
+# Programming Rules & Guidelines
+
+**Aider, read and internalize these rules. You MUST adhere to them strictly.**
+
+## General Directives
+
+1. **Surgical Precision:** Make only the exact changes explicitly requested. Do not add, remove, or modify any code that
+   is not directly pertinent to the current task.
+2. **No Extraneous Changes:** Do not auto-format, re-indent, reorder, or refactor code unless specifically instructed.
+   Preserve the existing code style, formatting, and structure.
+3. **No Unsolicited Refactoring:** Do not introduce new classes, methods, or architectural patterns unless explicitly
+   outlined in the task. If a suggestion for refactoring is implicit, ask for explicit approval first.
+4. **Prioritize Clarity over Brevity:** Code must be clear, readable, and maintainable. Do not optimize for line count
+   at the expense of understanding.
+
+## Filament v4 Specific Directives (CRITICAL)
+
+1. **Exact Method Signatures:** When modifying or implementing Filament resource methods (`form()`, `table()`,
+   `getColumns()`, `getActions()`, `getPages()`, `getHeaderActions()`, etc.), you **MUST** preserve their exact Filament
+   v4 method signatures, including type hints and return types (e.g., `public static function form(Form $form): Form`,
+   `public static function table(Table $table): Table`, `public static function makeHeaderActions(Page $page): array`).
+2. **Filament `Action` Syntax:** Use the correct Filament v4 `Action` syntax (`Action::make(...)`) with its fluent
+   methods (`->label()`, `->icon()`, `->action()`, `->modal()`, `->requiresConfirmation()`, and dynamic properties using
+   `fn (Model $record): type => ...`).
+3. **Resource `getPages()`:** When modifying `getPages()`, ensure it only lists the specified page routes. **Do NOT**
+   automatically add `Create` or `Edit` pages unless explicitly instructed for that specific resource.
+4. **No Raw `created_at` or `updated_at` in Tables/Infolists:** Avoid directly displaying
+   `TextColumn::make('created_at')` or `TextEntry::make('created_at')`. Use dedicated timestamp columns or accessors if
+   temporal data is needed.
+
+## Database & Model Strictness
+
+1. **No `timestamps()` or `softDeletes()` in Migrations (Unless Specified):** Unless explicitly told otherwise for a
+   specific table, new migrations and modifications to existing migrations **MUST NOT** include `->timestamps()` or
+   `->softDeletes()`.
+2. **No `$fillable` Array in Models:** Models **MUST NOT** use the `$fillable` property. Rely on specific factory
+   methods, service methods, or guarded properties if absolutely necessary.
+3. **No `timestamps` or `softDeletes` Properties/Traits in Models:** Unless explicitly told otherwise for a specific
+   model, models **MUST NOT** use the `$timestamps = false;` property or the `SoftDeletes` trait.
+4. **Type Hinting & Casts:** Use native PHP type hints for properties and method arguments/return types. Utilize
+   `$casts` for Enum fields and JSON columns.
+
+## SOLID Principles & Dynamic Programming
+
+1. **Single Responsibility Principle (SRP):** Each class and method should have only one reason to change. Break down
+   complex logic into smaller, focused units.
+2. **Open/Closed Principle (OCP):** Software entities should be open for extension, but closed for modification. Favor
+   composition and interfaces over inheritance where appropriate.
+3. **Liskov Substitution Principle (LSP):** Objects in a program should be replaceable with instances of their subtypes
+   without altering the correctness of that program. Ensure proper use of polymorphism.
+4. **Interface Segregation Principle (ISP):** Clients should not be forced to depend on interfaces they do not use.
+   Create small, role-specific interfaces.
+5. **Dependency Inversion Principle (DIP):**
+    * Use interfaces where appropriate to define contracts for services and clients.
+6. **Dynamic & Flexible Code:**
+    * **Enums for Fixed Options:** Use PHP Enums for fixed sets of options (e.g., `TranscriptStatus`, `AIProvider`).
+    * **Factories for Implementations:** Use factory classes/methods to retrieve specific implementations of
+      interfaces (e.g., `AIClientFactory`).
+
+## API Clients
+
+1. **All API Calls Through Clients:** Any interaction with external APIs (e.g., OpenAI, AWS, Salesforce) **MUST** go
+   through a dedicated API client class (e.g., `OpenAIApiClient`, `AwsS3Client`, `SalesforceTaskApiClient`). These
+   clients should wrap the HTTP calls and handle API-specific details.
+
+## Testing
+
+1. **Test Coverage:** For any new feature or significant refactoring, consider how unit and integration tests would be
+   written. The design should facilitate easy testing through proper dependency injection.
+
+## Error Handling & Resilience
+
+1. **Explicit Error Handling:** Implement robust `try-catch` blocks for external API calls and critical operations. Log
+   errors clearly.
+2. **Asynchronous Operations for External Systems:** For operations involving external APIs (especially write operations
+   like Salesforce sync), favor asynchronous processing via jobs to prevent UI blocking and allow for retries.
+
+## Configuration
+
+1. **Use Configuration Files/Environment Variables:** All API keys, endpoint URLs, and changeable settings must be
+   defined in `.env` and accessed via `config()` helpers, not hardcoded.
+
+---
+
+## Api client -Specific Rules
+
+1. DTOs **must NOT have constructors** — all population happens in Transformers.
+2. Transformers use `toDto()` and `toSpotify()`.
+3. All mass data Clients use:
+
+```php
+public function getMassData(): Collection;
+public function saveMassData(object $dto): mixed;

.aider.tags.cache.v4/cache.db

@@ -0,0 +1,35 @@
+## 📝 Pull Request Summary
+
+Please provide a clear and concise description of the changes made in this PR.
+
+- What does this PR fix or add?
+- Why is this change needed?
+
+---
+
+## 📌 Type of Change
+
+Please check all that apply:
+
+- [ ] 🐛 Bugfix
+- [ ] ✨ New feature
+- [ ] ♻️ Refactor (non-breaking changes)
+- [ ] 🧪 Tests
+- [ ] 📝 Documentation
+- [ ] 🧹 Code cleanup or formatting
+- [ ] 🚀 Build or deployment changes
+
+---
+
+## ✅ Checklist
+
+- [ ] I have tested my code
+- [ ] I have updated the documentation (if necessary)
+- [ ] This PR follows the team’s code style guidelines
+- [ ] I have added necessary tests or explained why not
+
+---
+
+## 🔗 Related Issues
+
+Closes #[issue_number] (if applicable)

.aider/CONVENTIONS.md

@@ -0,0 +1,5 @@
+.aider*
+.aider.*
+.aider.conf.yml
+.aider.input.history
+.aider.chat.history.md