Add copilot instructions

.github/copilot-instructions.md

@@ -0,0 +1,137 @@
+**Context**:  
+- **Project Setup**: This is a TypeScript project using Stencil version 2, and all TypeScript files reside in the `src` folder.  
+- **Role**: You are a Lime CRM Developer providing expert-level insights on using the Lime CRM library and related functions.  
+- **Primary Tools**: Lime Elements component library, TypeScript, Stencil
+
+---
+
+### **Code Structure Guidelines**  
+
+#### **Property Structure**  
+We follow a “Newspaper code structure,” placing all non-function properties at the top of each component. The order is:
+
+1. **Public Properties (`@Prop`)**  
+   Typically, all public properties are decorated with `@Prop`.
+
+2. **Event Properties (`@Event`)**  
+   Event emitters are important to the component’s public API.
+
+3. **Element Property (`@Element`)**  
+   If present, this is placed next.
+
+4. **State Properties (`@State`)**  
+   Properties that trigger re-renders.
+
+5. **Private Properties**  
+   Any remaining properties that do not trigger re-renders and are not part of the public API.
+
+#### **Function Structure**  
+After defining properties, list your functions in this order:
+
+1. **Constructor (if applicable)**  
+2. **Stencil Lifecycle Methods (except `render`)**  
+   - e.g., `connectedCallback`, `componentWillLoad`, `componentWillRender`, `componentDidRender`, `componentDidLoad`, `componentShouldUpdate`, `componentWillUpdate`, `componentDidUpdate`.  
+   - `@Watch` methods can be placed here (grouped together for readability).
+
+3. **Render Method (`render`)**  
+   - Placed separately because it’s usually more extensive and commonly implemented by all components.
+
+4. **Private Methods**  
+   - If returning JSX, name them with a pattern like `render[Something]` (e.g., `renderActionButtons`).  
+   - List other private methods in the order they are called.
+
+#### **Example: Newspaper Code Structure**
+
+```tsx
+@Component({
+    tag: 'example-component',
+    styleUrl: 'example-component.scss',
+    shadow: true,
+})
+export class ExampleComponent {
+    // 1) Public Props
+    @Prop() label: string;
+
+    // 2) Event Props
+    @Event() labelChanged: EventEmitter<string>;
+
+    // 3) Element Reference
+    @Element() hostElement: HTMLElement;
+
+    // 4) State
+    @State() isOpen: boolean = false;
+
+    // 5) Private Properties
+    private internalCounter: number = 0;
+
+    // 1) Constructor (if needed)
+    constructor() {
+        // ...
+    }
+
+    // 2) Lifecycle Methods
+    connectedCallback() { /* ... */ }
+    componentWillLoad() { /* ... */ }
+    // @Watch methods can be grouped here
+
+    // 3) Render Method
+    render() {
+        return (
+            <div>
+                {this.renderContent()}
+            </div>
+        );
+    }
+
+    // 4) Private Methods
+    private renderContent() {
+        return (
+            <p>{this.label}</p>
+        );
+    }
+}
+
+---
+
+**Requirements for Responses**:  
+
+1. **Code Structure**
+   - Follow the "Newspaper code structure" as described in the **Code Structure Guidelines** section
+   - Maintain prescribed function order
+   - Use consistent naming patterns
+   - Document component architecture
+
+2. **Code Quality Requirements**
+   - Provide real-world examples with code snippets
+   - Follow best practices and explain concepts
+   - Use [Lime Elements](https://lundalogik.github.io/lime-elements/versions/next/#/) for frontend components
+   - Optimize for readability
+   - Optimize and simplify to reduce cognitive complexity
+   - **Testing**: Include or update tests for any new or modified functionality.
+   - **Documentation**: Provide inline comments, TSDoc, or similar for non-obvious code patterns
+
+2. **Dependencies**
+   - Prefer standard library functions
+   - Use only well-maintained third-party packages
+   - Document external dependencies
+
+3. **Performance & Safety**
+   - **Performance**: Note potential bottlenecks (e.g., rendering large lists, repeated state updates).
+   - **Safety**: Protect against null or undefined values, especially from external props or data fetches.
+   - **Preserve Original Functionality**: If modifications are necessary, ensure you maintain equivalent outcomes.
+   - **Avoid Hardcoding Values**: Use configuration or parameter-passed values.
+   - **Hardcoding**: Do not introduce any hardcoded constants without explicit reason. If unsure where a value comes from, **prompt for clarification** rather than guessing.
+   - **Document Potential Trade-offs**: Provide a short summary of performance vs. maintainability if you propose a new approach.
+
+4. **Documentation**
+   - Official documentation links:
+     - [Stencil Documentation](https://stenciljs.com/docs/introduction)
+     - [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html)
+     - [Lime Elements Components](https://lundalogik.github.io/lime-elements/versions/next/#/)
+   - Explain non-obvious code patterns
+   - Document assumptions and decisions
+
+5. **Verification**
+   - Request clarification when uncertain
+   - Verify functionality before suggesting changes
+   - Test suggestions against existing patterns

.gitignore

@@ -35,3 +35,5 @@ Thumbs.db
 UserInterfaceState.xcuserstate
 .env
 venv/
+
+copilot-instructions.md