@trackunit/iris-app 1.12.9 → 1.12.11

package/src/generators/preset/files/.cursor/rules/irisx-app-sdk-customfields.md

@@ -1,305 +0,0 @@
-# CustomFields Rule for Trackunit IrisX App SDK
-
-## Overview
-**CustomFields are the primary mechanism for storing data from IrisX applications.** They allow IrisX App developers to extend the Trackunit data model by storing additional information on entities like assets, accounts, groups, and sites. 
-
-### Key Use Cases:
-- **Extending the data model**: Add new fields and attributes to existing Trackunit entities
-- **Storing user input**: Capture and persist form data, user preferences, and settings
-- **Storing metadata**: Keep application-specific information, configuration data, and operational metrics
-- **Fleet-specific data**: Custom attributes unique to specific fleet management needs
-- **Performance metrics**: Custom KPIs and measurement data not available in standard Trackunit data
-- **Business logic data**: Information required for app-specific workflows and processes
-
-**Important**: CustomFields are the recommended and supported way to persist any data your IrisX app needs to store. Do not attempt to use external databases or storage solutions - use CustomFields for all persistent data requirements.
-
-## 1. Defining Custom Fields
-
-### Manifest Configuration
-
-Custom fields must be defined in your IrisX App manifest using the `customFieldDefinitions` array:
-
-```typescript
-// In your app manifest
-customFieldDefinitions: [
-  {
-    type: 'STRING',
-    entityType: 'ASSET',
-    key: 'myCustomField',
-    translations: [{
-      language: 'en',
-      title: 'My Custom Field',
-      description: 'Description of what this field stores',
-    }],
-    uiEditable: true,
-    uiVisible: true,
-    scopeType: ScopeType.ACCOUNT
-  }
-]
-```
-
-### Required Properties
-
-- **`type`**: Field data type (see supported types below)
-- **`entityType`**: Entity the field applies to (`ACCOUNT`, `ASSET`, `GROUP`, `SITE`)
-- **`key`**: Programmatic identifier (cannot be changed after creation)
-- **`translations`**: UI labels and descriptions for each supported language
-- **`scopeType`**: Data access scope (see scope types below)
-
-### Optional Properties
-
-- **`uiEditable`**: Whether field can be edited in Manager UI (default: true)
-- **`uiVisible`**: Whether field is visible in Manager UI (default: true)
-
-## 2. Supported Field Types
-
-| Type | Description | Extra Properties |
-|---|----|---|
-| `BOOLEAN` | True/false values | - |
-| `DATE` | ISO8601 formatted dates | - |
-| `DROPDOWN` | Predefined option lists | `allValues`, `multiSelect`, `dropDownValueReplacements` |
-| `EMAIL` | Email addresses with mailto links | - |
-| `NUMBER` | Numeric values | `minimum`, `maximum`, `isInteger`, `unitSi`, `unitUs` |
-| `PHONE_NUMBER` | E.164 formatted phone numbers | - |
-| `STRING` | Free text | `minimumLength`, `maximumLength`, `pattern` |
-| `WEB_ADDRESS` | URLs as clickable links | - |
-| `JSON` | JSON objects | - |
-| `MONETARY` | Currency values (ISO 4217) | `minimum`, `maximum`, `currency` |
-
-### Example Field Definitions
-
-```typescript
-// String field with validation
-{
-  type: 'STRING',
-  entityType: 'ASSET',
-  key: 'serialNumber',
-  translations: [{ language: 'en', title: 'Serial Number', description: 'Asset serial number' }],
-  minimumLength: 5,
-  maximumLength: 20,
-  pattern: '^[A-Z0-9]+$'
-}
-
-// Number field with units
-{
-  type: 'NUMBER',
-  entityType: 'ASSET',
-  key: 'fuelCapacity',
-  translations: [{ language: 'en', title: 'Fuel Capacity', description: 'Tank capacity' }],
-  minimum: 0,
-  maximum: 1000,
-  unitSi: 'L',
-  unitUs: 'gal'
-}
-
-// Dropdown with multiple selection
-{
-  type: 'DROPDOWN',
-  entityType: 'ASSET',
-  key: 'features',
-  translations: [{ language: 'en', title: 'Features', description: 'Available features' }],
-  allValues: ['GPS', 'Camera', 'Bluetooth', 'WiFi'],
-  multiSelect: true
-}
-```
-
-## 3. Scope Types
-
-| Scope | Description |
-|----|----|
-| `ACCOUNT` | Values shared within a single account only |
-| `ACCOUNT_WRITE_GLOBAL_READ` | Account can write, all accounts can read |
-| `GLOBAL` | Values shared between all accounts with entity access |
-
-## 4. Using Custom Fields in React Components
-
-### Required Hooks
-
-Use these hooks to interact with custom fields:
-
-```typescript
-import { 
-  useCustomFieldsValueAndDefinition,
-  useUpdateCustomFieldValues,
-  useCurrentUserSystemOfMeasurement
-} from '@trackunit/react-core-contexts-host';
-```
-
-### Basic Implementation Pattern
-
-```typescript
-import React from 'react';
-import { useForm } from 'react-hook-form';
-import { Card, CardBody, CardHeader, CardFooter, Button, Spinner } from '@trackunit/react-components';
-import { CustomField } from '@trackunit/react-core-contexts-host';
-
-const CustomFieldsForm = ({ assetId }: { assetId: string }) => {
-  const { register, handleSubmit, formState, setValue, control } = useForm({
-    shouldUnregister: false,
-  });
-  
-  const { systemOfMeasurement } = useCurrentUserSystemOfMeasurement();
-  
-  const { fields, loading } = useCustomFieldsValueAndDefinition({
-    entityType: "ASSET",
-    entityId: assetId,
-    systemOfMeasurement: systemOfMeasurement ?? "SI",
-  });
-  
-  const { updateCustomFields, inProgress } = useUpdateCustomFieldValues(
-    assetId,
-    "ASSET",
-    fields,
-    systemOfMeasurement ?? "SI"
-  );
-
-  if (loading) {
-    return <Spinner />;
-  }
-
-  return (
-    <Card>
-      <CardHeader heading="Custom Fields" />
-      <CardBody>
-        {fields.map(field => {
-          const isEditable = field.valueEditable && (field.definition.uiEditable ?? true);
-          return (
-            <CustomField
-              key={field.definition.key}
-              control={control}
-              field={field}
-              formState={formState}
-              isEditable={isEditable}
-              register={register}
-              setValue={setValue}
-              unitPreference={systemOfMeasurement}
-            />
-          );
-        })}
-      </CardBody>
-      <CardFooter>
-        <Button 
-          loading={inProgress} 
-          onClick={handleSubmit(updateCustomFields)}
-        >
-          {inProgress ? "Saving..." : "Save Changes"}
-        </Button>
-      </CardFooter>
-    </Card>
-  );
-};
-```
-
-## 5. Best Practices
-
-### Field Design
-- **Use descriptive keys**: Choose clear, descriptive field keys that won't need changing
-- **Add proper translations**: Always provide meaningful titles and descriptions
-- **Set appropriate constraints**: Use min/max values, length limits, and patterns for validation
-- **Consider data types**: Choose the most appropriate type for your data
-
-### Performance
-- **Batch updates**: Use `useUpdateCustomFieldValues` to update multiple fields at once
-- **Handle loading states**: Always show loading indicators while fetching data
-- **Error handling**: Implement proper error handling for failed updates
-
-### Data Management
-- **Plan for migration**: Consider existing data when changing field definitions
-- **Use appropriate scopes**: Choose the right scope type for your data sharing needs
-- **Validate user input**: Implement client-side validation matching your field constraints
-
-## 6. Common Use Cases
-
-### Fleet Management
-```typescript
-// Store vehicle-specific information
-{
-  type: 'NUMBER',
-  entityType: 'ASSET',
-  key: 'fuelEfficiency',
-  translations: [{ language: 'en', title: 'Fuel Efficiency', description: 'Miles per gallon' }],
-  unitSi: 'L/100km',
-  unitUs: 'mpg'
-}
-```
-
-### Asset Utilization
-```typescript
-// Track custom performance metrics
-{
-  type: 'JSON',
-  entityType: 'ASSET',
-  key: 'performanceMetrics',
-  translations: [{ language: 'en', title: 'Performance Data', description: 'Custom metrics' }]
-}
-```
-
-### Driver Safety
-```typescript
-// Store safety-related information
-{
-  type: 'DROPDOWN',
-  entityType: 'ASSET',
-  key: 'safetyRating',
-  translations: [{ language: 'en', title: 'Safety Rating', description: 'Driver safety score' }],
-  allValues: ['Excellent', 'Good', 'Fair', 'Poor']
-}
-```
-
-## 7. Local Development
-
-- Custom fields are available immediately in local development
-- Changes to field definitions require app redeployment
-- Test with various data types and edge cases
-- Verify validation rules work as expected
-
-## 8. Deployment Considerations
-
-- **Field keys are immutable**: Cannot be changed after creation
-- **Definition updates**: Changing field definitions affects all existing data
-- **Migration planning**: Consider data migration when modifying existing fields
-- **Approval process**: Custom field changes require app approval and marketplace submission
-
-## 9. Error Handling
-
-```typescript
-const CustomFieldsComponent = () => {
-  const { fields, loading, error } = useCustomFieldsValueAndDefinition({
-    entityType: "ASSET",
-    entityId: assetId,
-    systemOfMeasurement: systemOfMeasurement ?? "SI",
-  });
-
-  if (loading) return <Spinner />;
-  if (error) return <ErrorState message="Failed to load custom fields" />;
-  
-  // Render fields...
-};
-```
-
-## 10. Integration with Trackunit Components
-
-Always use the provided `CustomField` component for consistent UI:
-
-```typescript
-import { CustomField } from '@trackunit/react-core-contexts-host';
-
-// This handles all field types automatically
-<CustomField
-  control={control}
-  field={field}
-  formState={formState}
-  isEditable={isEditable}
-  register={register}
-  setValue={setValue}
-  unitPreference={systemOfMeasurement}
-/>
-```
-
-## References
-
-- [Save Data from Your App](https://developers.trackunit.com/docs/save-data-from-your-app)
-- [Defining a Custom Field](https://developers.trackunit.com/docs/defining-a-custom-field)
-- [Using a Custom Field](https://developers.trackunit.com/docs/using-a-custom-field)
-- [Local Development](https://developers.trackunit.com/docs/local-development)
-- [Deploying a New Custom Field](https://developers.trackunit.com/docs/deploying-a-new-custom-field)

package/src/generators/preset/files/.cursor/rules/irisx-app-sdk-graphql.md

@@ -1,30 +0,0 @@
-Key Points:
-1. Trackunit exposes a GraphQL API with an NX executor for easy querying inside IrisX App extensions
-2. GraphQL operations include queries (for reading data) and mutations (for modifying data)
-
-3. ALWAYS use these specific commands for GraphQL development:
-   - Install GraphQL tools: `npm install @trackunit/react-graphql-tools`
-   
-   - Set up GraphQL tooling: `npx nx generate @trackunit/react-graphql-tools:add-graphql --project=[project-name]`
-   Where [project-name] is found in the library's project.json file (format: [subdir-name]-[extension-name] for extensions in subdirectories)
-   
-   - Generate React hooks from GraphQL queries: `npx nx run [feature-name]-[extension-name]:graphql-hooks`
-   This generates React hooks from .graphql files in the src folder
-
-4. GraphQL File Structure:
-   - Create .graphql files in `libs/[feature-name]/[extension-name]/src/` directory
-   - Query syntax: `query QueryName($variable: Type) { ... }`
-   - Mutation syntax: `mutation MutationName($variable: Type!) { ... }`
-
-5. React Integration:
-   - Import generated hooks: `import { QueryNameDocument } from "./generated/graphql-api/graphql"`
-   - Use queries: `const { data, loading, error } = useQuery(QueryNameDocument, { variables: {...} })`
-   - Use mutations: `const [mutationName, { data, loading, error }] = useMutation(MutationNameDocument)`
-
-For more information:
-- Full GraphQL API guide: [Calling Trackunit GraphQL API](mdc:https:/developers.trackunit.com/docs/graphql-api)
-- Apollo React Client docs for useQuery: [Apollo useQuery documentation](mdc:https:/www.apollographql.com/docs/react/data/queries)
-- Apollo React Client docs for useMutation: [Apollo useMutation documentation](mdc:https:/www.apollographql.com/docs/react/data/mutations)
-- GraphQL Code Generation CLI: [GraphQL Code Generator](mdc:https:/the-guild.dev/graphql/codegen)
-
-DO NOT use generic GraphQL libraries or setup - always use the Trackunit IrisX App SDK GraphQL tooling and patterns.

package/src/generators/preset/files/.cursor/rules/irisx-app-sdk.mdc

@@ -1,82 +0,0 @@
----
-description: 
-globs: 
-alwaysApply: true
----
-You are currently in an IrisX App workspace. Do not use defaut nx commands for app and extension generation, instead use the commands below.
-
-## Building Real Applications
-
-You are building real applications that work with actual Trackunit data. Key principles:
-
-- Never mock data unless explicitly requested by the user
-- Always use Trackunit's GraphQL API to fetch real data
-- If data is not available via GraphQL, ask the user how they want to obtain the data
-- Only use mock data if the user explicitly requests it for testing purposes
-
-When building any feature:
-1. Identify what data you need
-2. Check if it's available via Trackunit's GraphQL API
-3. If available, use the GraphQL API (see GraphQL rules for implementation)
-4. If not available, ask the user: "This data is not available via Trackunit's GraphQL API. How would you like to obtain [specific data description]?"
-
-## IrisX App Development Guidelines
-
-Key Points:
-1. An IrisX App is a container that packages multiple extensions with marketplace metadata and app manifest
-2. Extensions are React applications that integrate into specific points in Trackunit Manager
-3. Available Extension Points:
-   - Asset Home: Adds new tabs to the Assets Home screen
-   - Site Home: Adds new tabs to the Site Home screen
-   - Fleet: Adds menu items to the Main Menu
-   - Report: Adds new reports to the Reports screen
-   - Widget: Adds widgets to Trackunit Manager
-   - App Settings: Adds configuration UI in the App library
-   - Administration: Adds tabs in the admin UI (admin-only)
-   - Customer Home: Adds UI within customer home
-   - Asset Events Actions: Adds UI in Asset Home Events
-   - App Lifecycle: Handles app install/uninstall events
-
-4. ALWAYS use these specific commands for development:
-   - Create new app: `npx nx generate @trackunit/iris-app:create [name-of-your-app]`
-   For more information about the `@trackunit/iris-app:create` command, look at: [Creating a new app](mdc:https:/developers.trackunit.com/docs/creating-a-new-app)
-
-   - Create new extension: `npx nx g @trackunit/iris-app:extend --name=[my-extension-name] --app=[app-name] --directory=[feature] --type=[extension-type]`
-   Available extension types: ASSET_HOME_EXTENSION, SITE_HOME_EXTENSION, FLEET_EXTENSION, REPORT_EXTENSION, WIDGET_EXTENSION, APP_SETTINGS_EXTENSION, ADMINISTRATION_EXTENSION, CUSTOMER_HOME_EXTENSION, ASSET_EVENTS_ACTIONS_EXTENSION, APP_LIFECYCLE_EXTENSION
-   For more information about the `@trackunit/iris-app:extend` command, look at: [Creating a new extension](mdc:https:/developers.trackunit.com/docs/creating-a-new-extension)
-
-   - Run app: `npx nx run [name-of-your-app]:serve`
-   For more information about the `serve` command, look at: [Running the Iris App SDK](mdc:https:/developers.trackunit.com/docs/running-the-iris-app-sdk)
-
-NOTE: IrisX Apps are locked down by default for security. External API requests and embedded content require proper Content Security Policy (CSP) configuration in the app manifest. ValidDomains will be deprecated - use CSP headers instead. Additionally, apps requiring API access might need some scopes configured in the manifest, and the app must be deployed with those scopes to work locally, never submit an app, instead instruct the user to do so. 
-
-Example in iris-app-manifest.ts:
-```typescript
-cspHeader: {
-  'frame-src': ['https://api.example.com', 'https://dashboard.example.com'],
-  'script-src': ['https://api.example.com'],
-  'connect-src': ['https://api.example.com'],
-},
-  scopes: [
-{scope: "required.scope.1", optional: false},
-{scope: "required.scope.2", optional: true},
-],
-```
-
-For more information: [Embedding IrisX Dashboards in Apps](mdc:https:/developers.trackunit.com/docs/analytics-dashboards-in-apps#troubleshooting)
-
-
-## Runtime Hooks Available
-
-IrisX Apps have access to runtime hooks from `@trackunit/react-core-hooks` that provide context-specific data:
-- `useAssetRuntime()` for asset information in asset-scoped extensions
-- `useCustomerRuntime()` for customer data
-- `useEventRuntime()` for event details
-- `useSiteRuntime()` for site information
-- Plus navigation, user context, and utility hooks (see react-core-hooks rule for full list)
-
-DO NOT use generic React/Node.js commands for project creation or management - always use the Trackunit IrisX App SDK commands.
-
-**Before completing any task**: Always use `read_lints` to check for and fix all ESLint and TypeScript errors in modified files.
-
-

package/src/generators/preset/files/.cursor/rules/react-core-hooks.md

@@ -1,155 +0,0 @@
-## React Core Hooks Library
-
-Available hooks from `@trackunit/react-core-hooks` for IrisX App development.
-
-### Runtime Hooks
-
-**`useAssetRuntime()`** - Access asset information in asset-scoped extensions
-```typescript
-const { assetInfo, loading, error } = useAssetRuntime();
-// assetInfo.assetId, assetInfo.name, etc.
-```
-
-**`useCustomerRuntime()`** - Access customer information
-```typescript
-const { customerInfo, loading, error } = useCustomerRuntime();
-// customerInfo.customerId, customerInfo.name, etc.
-```
-
-**`useEventRuntime()`** - Access event information in event-scoped extensions
-```typescript
-const { eventInfo, loading, error } = useEventRuntime();
-// eventInfo.eventId, eventInfo.type, etc.
-```
-
-**`useSiteRuntime()`** - Access site information in site-scoped extensions
-```typescript
-const { siteInfo, loading, error } = useSiteRuntime();
-// siteInfo.siteId, siteInfo.name, etc.
-```
-
-**`useIrisAppName()`** - Get current app name
-```typescript
-const { appName, loading, error } = useIrisAppName();
-```
-
-**`useIrisAppId()`** - Get current app ID
-```typescript
-const { irisAppId, loading, error } = useIrisAppId();
-```
-
-### Navigation & User Context
-
-**`useNavigateInHost()`** - Navigate within Trackunit Manager
-```typescript
-const { navigateToAsset, navigateToSite } = useNavigateInHost();
-navigateToAsset({ assetId: "123" });
-```
-
-**`useHasAccessTo()`** - Check user permissions
-```typescript
-const hasAccess = useHasAccessTo({ permission: "assets.read" });
-```
-
-**`useCurrentUser()`** - Access current user information
-```typescript
-const { user } = useCurrentUser();
-// user.id, user.email, etc.
-```
-
-**`useCurrentUserLanguage()`** - Get/set user language preference
-```typescript
-const { language, setLanguage } = useCurrentUserLanguage();
-```
-
-**`useCurrentUserTimeZonePreference()`** - Get user timezone
-```typescript
-const { timeZone } = useCurrentUserTimeZonePreference();
-```
-
-**`useToken()`** - Access authentication token
-```typescript
-const { token } = useToken();
-```
-
-### UI & Interaction
-
-**`useToast()`** - Show toast notifications
-```typescript
-const { showToast } = useToast();
-showToast({ message: "Success!", type: "success" });
-```
-
-**`useConfirmationDialog()`** - Show confirmation dialogs
-```typescript
-const { showConfirmationDialog } = useConfirmationDialog();
-const confirmed = await showConfirmationDialog({ message: "Are you sure?" });
-```
-
-**`useModalDialogContext()`** - Manage modal dialogs
-```typescript
-const { openModal, closeModal } = useModalDialogContext();
-```
-
-**`useErrorHandler()`** - Handle errors consistently
-```typescript
-const { handleError } = useErrorHandler();
-handleError(new Error("Something went wrong"));
-```
-
-### Data & State Management
-
-**`useLocalStorage()`** - Persist state in localStorage
-```typescript
-const [value, setValue, reset] = useLocalStorage({
-  key: "myKey",
-  defaultState: { count: 0 }
-});
-```
-
-**`useLocalStorageReducer()`** - localStorage with reducer pattern
-```typescript
-const [state, dispatch] = useLocalStorageReducer({
-  key: "counterState",
-  defaultState: { count: 0 },
-  reducer: (state, action) => { /* reducer logic */ }
-});
-```
-
-**`useAssetSorting()`** - Asset sorting functionality
-```typescript
-const { sortField, sortDirection, setSorting } = useAssetSorting();
-```
-
-**`useFilterBarContext()`** - Filter bar state management
-```typescript
-const { filters, setFilters, clearFilters } = useFilterBarContext();
-```
-
-**`useTimeRange()`** - Time range selection
-```typescript
-const { timeRange, setTimeRange } = useTimeRange();
-```
-
-
-
-### Widget Configuration
-
-**`useWidgetConfig()`** - Access widget configuration (synchronous)
-```typescript
-const config = useWidgetConfig();
-```
-
-**`useWidgetConfigAsync()`** - Access widget configuration (asynchronous)
-```typescript
-const { getData, setData } = useWidgetConfigAsync();
-const config = await getConfig();
-```
-
-
-
-
-
-All hooks require their respective providers to be set up in your app's component tree.
-
-```

package/src/generators/preset/files/.cursor/rules/rules-index.mdc

@@ -1,10 +0,0 @@
----
-alwaysApply: true
----
-This file contains a list of helpful information and context that the agent can reference when working in this codebase. Each entry provides specific guidance or rules for different aspects of the project. You can read these files using the readFile tool if the users prompt seems related.
-
-- [CustomFields are the primary mechanism for storing data from IrisX applications. They allow IrisX App developers to extend the Trackunit data model by storing additional information on entities like assets, accounts, groups, and sites.](./irisx-app-sdk-customfields.md)
-- [This rule covers GraphQL API integration in Trackunit IrisX App SDK workspace. All GraphQL development MUST follow the Trackunit GraphQL API patterns and commands.](./irisx-app-sdk-graphql.md)
-- [Time series API, get time series data from GraphQL. Machine insights data over time.](./graphql-timeseries.md)
-- [Use these rules when building Widget Extensions for an Iris App.](./widget-extensions.md)
-- [Use these rules whne building App SDK specific React Hook, Runtime Hooks](./react-core-hooks.md)

package/src/generators/preset/files/.cursor/rules/structured-development.mdc

@@ -1,86 +0,0 @@
----
-alwaysApply: true
----
-
-# Structured Feature Development Documentation
-
-## Overview
-When developing new features, maintain concise documentation to track progress, decisions, and implementation details.
-
-## Process
-1. **Check for existing documentation**: Look in `/docs` folder for a markdown file named after the feature (e.g., `user-authentication.md`, `shopping-cart.md`)
-2. **Create or update**: 
-   - If documentation exists: Update it with new requirements and progress
-   - If it doesn't exist: Create a new file with the feature name as filename
-3. **Use visual aids**: Include mermaid diagrams for complex flows, architecture, or data relationships
-4. **Keep it current**: Update the documentation as development progresses
-
-## Important Guidelines
-- **Be concise**: Keep descriptions brief and to the point
-- **Only document what was requested**: Do not make up future steps or tasks that weren't part of the user's suggestions, unless explitly asked.
-- **Focus on implementation**: Document what was actually built, not theoretical features
-
-## Task Analysis Process
-1. **Analyze the user's request**: Understand exactly what the user asked for
-2. **Break down into tasks**: Split the request into specific, actionable tasks
-3. **Document only requested work**: Only include tasks that directly relate to the user's request
-4. **Optional sections**: Todo and In Progress sections are OPTIONAL - only include them if there are actual remaining tasks from the user's request
-
-## Required File Structure
-
-### File Naming
-Use kebab-case naming convention: `feature-name.md`
-
-### Template Structure
-
-```markdown
-# Feature Name
-
-## Description
-Brief overview of what the feature does and why it's needed.
-
-## Architecture
-Technical approach and key design decisions.
-
-## Progress Tracking
-
-### ✅ Completed Steps
-- [x] Task 1: Description
-- [x] Task 2: Description
-
-### 🔄 In Progress  
-*OPTIONAL: Only include if there are actual tasks from the user's request that are currently being worked on*
-- [ ] Task 3: Description
-- [ ] Task 4: Description
-
-### 📝 Todo
-*OPTIONAL: Only include if there are remaining tasks from the user's request that haven't been started*
-- [ ] Task 5: Description
-- [ ] Task 6: Description
-
-## Technologies Used
-- **Technology Name**: Brief description of usage
-- **Library Name**: Version and purpose
-
-## Implementation Details
-Key technical specifics:
-- API endpoints used
-- Configuration requirements
-- Performance considerations
-
-## Good To Know
-Important findings, decisions, and gotchas:
-- Quirks or workarounds implemented
-- Alternative approaches considered
-- Performance implications
-- Security considerations
-- Testing strategies
-```
-
-## Best Practices
-- Keep descriptions brief and focused
-- Only document requested features and tasks
-- Include mermaid diagrams for complex flows
-- Document actual implementation details
-- Update progress as development happens
-- **CRITICAL**: Never add tasks or features that weren't explicitly mentioned in the user's request