diff --git a/GiftedDialog-Logic-Flow.md b/GiftedDialog-Logic-Flow.md
new file mode 100644
index 00000000..377a7f05
--- /dev/null
+++ b/GiftedDialog-Logic-Flow.md
@@ -0,0 +1,3957 @@
+# GiftedDialog UI Logic Flow
+
+**Author:** Matthew Raymer
+**Date:** December 2025
+**Component:** `src/components/GiftedDialog.vue`
+
+## Overview
+
+The `GiftedDialog` component is a multi-step modal dialog that facilitates recording gifts/contributions between people and projects in the Time Safari application. It supports various gift scenarios including person-to-person, person-to-project, and project-to-person transactions.
+
+This component serves as the primary interface for users to acknowledge and record contributions they have received or given. When a user wants to document a gift, favor, or contribution, they interact with this dialog which guides them through a structured process to ensure all necessary information is captured accurately. The dialog intelligently adapts its interface based on the context from which it was opened, whether from the home screen, a project page, or another part of the application.
+
+## Architecture
+
+### Component Structure
+- **Framework:** Vue 3 with TypeScript using `vue-facing-decorator`
+- **Dependencies:**
+ - Database layer (`db/index.ts`, `databaseUtil.ts`)
+ - Endorser server integration (`libs/endorserServer.ts`)
+ - Platform services (`PlatformServiceFactory`)
+ - Child components: `EntityIcon`, `ProjectIcon`
+
+The component is built using Vue 3's Composition API with TypeScript decorators for a class-based approach. This architectural choice provides strong typing and clear separation of concerns. The component heavily relies on the application's database layer for storing and retrieving contact information, while the endorser server integration handles the cryptographic signing and publishing of gift records to the distributed network.
+
+### Key Properties
+```typescript
+@Prop() fromProjectId: string // Project ID when project is the giver
+@Prop() toProjectId: string // Project ID when project is the recipient
+@Prop() showProjects: boolean // Whether to show projects in selection
+@Prop() isFromProjectView: boolean // Whether opened from project view
+```
+
+These properties control the dialog's behavior and determine what type of entities (people or projects) should be displayed in the selection interface. The `fromProjectId` and `toProjectId` properties are mutually exclusive and indicate whether a specific project is involved in the transaction. When `showProjects` is true, the dialog prioritizes showing available projects rather than people. The `isFromProjectView` flag helps the component understand the navigation context and adjust its interface accordingly.
+
+## Logic Flow
+
+### 1. Initialization Phase
+
+#### Entry Point: `open()` Method
+```typescript
+async open(
+ giver?: GiverReceiverInputInfo,
+ receiver?: GiverReceiverInputInfo,
+ offerId?: string,
+ customTitle?: string,
+ prompt?: string,
+ callbackOnSuccess: (amount: number) => void = () => {}
+)
+```
+
+The dialog's lifecycle begins when the `open()` method is called from a parent component. This method accepts several optional parameters that pre-populate the dialog with context-specific information. If a giver or receiver is already known (such as when recording a gift from a specific project), these can be passed in to skip the selection step. The method also accepts custom prompts and titles to provide contextual guidance to the user.
+
+**Initialization Steps:**
+1. **Entity Type Determination** (`updateEntityTypes()`)
+ - Analyzes props to determine if giver/recipient should be person or project
+ - Sets `giverEntityType` and `recipientEntityType` accordingly
+
+The first step in initialization involves analyzing the component's properties to determine what types of entities should be involved in this gift transaction. This analysis considers the context from which the dialog was opened and sets internal flags that control the subsequent user interface presentation.
+
+2. **Database Setup**
+ - Retrieves active account settings
+ - Loads contacts from database
+ - Fetches user's DIDs for identification
+
+Next, the component establishes its data foundation by connecting to the local database and retrieving the user's contacts, account settings, and decentralized identifiers (DIDs). This information is essential for populating the selection interface and ensuring the user can choose from their known contacts and projects.
+
+3. **Project Loading** (if needed)
+ - Calls `loadProjects()` if either entity type is "project"
+ - Fetches available projects from API server
+
+If the dialog needs to display projects (either as potential givers or recipients), it makes an API call to the endorser server to retrieve the current list of available projects. This ensures users see the most up-to-date project information when making their selections.
+
+4. **Step Determination**
+ - If giver is pre-selected: starts at Step 2 (Gift Details)
+ - Otherwise: starts at Step 1 (Entity Selection)
+
+Finally, the component determines which step to display first. If enough context was provided during opening (such as a pre-selected giver), the dialog can skip directly to the gift details step. Otherwise, it starts with the entity selection step to gather the necessary information from the user.
+
+### 2. Entity Type Logic
+
+#### Entity Type Matrix
+| Context | Giver Type | Recipient Type | Description |
+|---------|------------|----------------|-------------|
+| `showProjects=true` | project | person | HomeView "Project" button |
+| `fromProjectId` set | project | person | Project giving to person |
+| `toProjectId` set | person | project | Person giving to project |
+| Default | person | person | Person-to-person gift |
+
+The entity type determination follows a clear hierarchy of rules based on the dialog's opening context. When users click the "Project" button from the home view, they're indicating they want to record receiving something from a project, so the dialog configures itself for project-to-person gifts. Conversely, when opened from a project page with a "give to this project" context, it sets up for person-to-project transactions.
+
+#### Dynamic Entity Resolution
+```typescript
+updateEntityTypes() {
+ // Reset defaults
+ this.giverEntityType = "person";
+ this.recipientEntityType = "person";
+
+ // Apply context-specific logic
+ if (this.showProjects) {
+ this.giverEntityType = "project";
+ } else if (this.fromProjectId) {
+ this.giverEntityType = "project";
+ } else if (this.toProjectId) {
+ this.recipientEntityType = "project";
+ }
+}
+```
+
+The `updateEntityTypes()` method implements this logic by first resetting both entity types to "person" (the most common case), then applying specific rules based on the component's properties. This approach ensures a predictable fallback while allowing for context-specific customization. The method is called whenever relevant properties change, ensuring the interface stays synchronized with the current context.
+
+### 3. Step 1: Entity Selection
+
+#### Display Logic
+The UI dynamically shows different entity grids based on `shouldShowProjects`:
+
+```typescript
+get shouldShowProjects() {
+ return (this.stepType === "giver" && this.giverEntityType === "project") ||
+ (this.stepType === "recipient" && this.recipientEntityType === "project");
+}
+```
+
+The first step presents users with a grid of selectable entities, but the content of this grid changes dramatically based on whether projects or people should be displayed. The `shouldShowProjects` computed property determines this by checking if the current selection step (giver or recipient) corresponds to an entity type of "project". This ensures users only see relevant options for their current selection task.
+
+#### Project Selection Grid
+- **Layout:** 3-4 columns on mobile/desktop
+- **Content:** First 7 projects with icons, names, and issuer info
+- **Actions:**
+ - Click project → `selectProject()` or `selectRecipientProject()`
+ - "Show All" link → Navigate to discover page
+
+When displaying projects, the interface uses a wider grid layout to accommodate project icons and additional information like the project creator's identity. The grid shows only the first seven projects to avoid overwhelming the user, with a "Show All" option that navigates to the main discovery page for browsing the complete project catalog. Each project is displayed with its custom icon (if available), name, and information about who created or manages the project.
+
+#### Person Selection Grid
+- **Layout:** 4-6 columns responsive
+- **Content:**
+ - "You" option (with conflict detection)
+ - "Unnamed" option
+ - First 10 contacts with avatars and names
+- **Conflict Prevention:**
+ - Grays out options that would create giver=recipient conflicts
+ - Uses `wouldCreateConflict()` method for validation
+
+The person selection grid uses a more compact layout since person entries require less information. It always includes a "You" option (allowing users to select themselves) and an "Unnamed" option for cases where the other party isn't in their contact list. The grid then displays up to 10 of the user's contacts, each with their avatar and name. Importantly, the interface includes conflict prevention logic that visually disables options that would result in the same person being selected as both giver and recipient.
+
+#### Conflict Detection Algorithm
+```typescript
+wouldCreateConflict(contactDid: string) {
+ // Only applies to person-to-person gifts
+ if (this.giverEntityType !== "person" || this.recipientEntityType !== "person") {
+ return false;
+ }
+
+ if (this.stepType === "giver") {
+ return this.receiver?.did === contactDid;
+ } else if (this.stepType === "recipient") {
+ return this.giver?.did === contactDid;
+ }
+
+ return false;
+}
+```
+
+The conflict detection algorithm prevents users from accidentally selecting the same person for both roles in a gift transaction. It only applies to person-to-person gifts, since project-to-person or person-to-project gifts cannot have this type of conflict. The method checks whether selecting a particular contact would create a duplicate selection by comparing their DID (decentralized identifier) with the already-selected entity for the opposite role.
+
+### 4. Step 2: Gift Details
+
+#### Entity Display
+- **Editable Entities:** Show edit button, allow clicking to return to Step 1
+- **Locked Entities:** Show lock icon, prevent editing (e.g., when project is pre-selected)
+- **Visual Representation:** Appropriate icons (EntityIcon for people, ProjectIcon for projects)
+
+The second step displays the selected entities prominently at the top of the form, providing visual confirmation of the user's choices. The interface distinguishes between editable and locked entities - editable entities show a pencil icon and can be clicked to return to the selection step, while locked entities (such as when the dialog was opened with a specific project context) show a lock icon and cannot be changed. This prevents users from accidentally modifying critical context information.
+
+#### Form Controls
+1. **Description Input**
+ - Text field with dynamic placeholder
+ - Uses custom prompt if provided
+
+The description field allows users to provide context about what was given or received. The placeholder text adapts based on any custom prompt provided when opening the dialog, helping guide users toward appropriate descriptions for their specific context.
+
+2. **Amount Controls**
+ - Increment/decrement buttons
+ - Direct numeric input
+ - Unit selector (Hours, USD, BTC, BX, ETH)
+
+The amount section provides multiple ways for users to specify the quantity of their gift. Increment and decrement buttons make it easy to adjust whole number amounts, while the direct input field allows for precise decimal values. The unit selector supports various types of contributions, from time (hours) to different currencies, acknowledging that gifts in the Time Safari ecosystem can take many forms.
+
+3. **Advanced Options**
+ - "Photo & more options" link to `GiftedDetailsView`
+ - Passes comprehensive query parameters for state preservation
+
+For users who want to add additional details like photos or more complex descriptions, a link navigates to an expanded details view. The component carefully preserves all current form state by encoding it in query parameters, ensuring users don't lose their progress when exploring these advanced options.
+
+#### Validation Logic
+```typescript
+async confirm() {
+ // Check for active DID
+ if (!this.activeDid) {
+ this.$notify({ type: "danger", text: "You must select an identifier..." });
+ return;
+ }
+
+ // Validate amount
+ if (parseFloat(this.amountInput) < 0) {
+ this.$notify({ type: "danger", text: "You may not send a negative number." });
+ return;
+ }
+
+ // Require description or amount
+ if (!this.description && !parseFloat(this.amountInput)) {
+ this.$notify({ type: "danger", text: "You must enter a description or amount." });
+ return;
+ }
+
+ // Check for person conflict
+ if (this.hasPersonConflict) {
+ this.$notify({ type: "danger", text: "Cannot select same person as giver and recipient." });
+ return;
+ }
+}
+```
+
+The validation logic implements several business rules before allowing gift submission. Users must have an active decentralized identifier selected, cannot submit negative amounts, and must provide either a description or a numeric amount. The system also prevents the logical error of selecting the same person as both giver and recipient in person-to-person transactions.
+
+## Gift Recording Logic
+
+### API Parameter Mapping
+The component translates UI selections into endorser server API parameters:
+
+```typescript
+// Person-to-Person Gift
+{
+ fromDid: giver.did,
+ toDid: receiver.did,
+ description: description,
+ amount: parseFloat(amountInput),
+ unit: unitCode
+}
+
+// Person-to-Project Gift
+{
+ fromDid: giver.did,
+ fulfillsProjectHandleId: toProjectId,
+ description: description,
+ amount: parseFloat(amountInput),
+ unit: unitCode
+}
+
+// Project-to-Person Gift
+{
+ providerPlanHandleId: fromProjectId,
+ toDid: receiver.did,
+ description: description,
+ amount: parseFloat(amountInput),
+ unit: unitCode
+}
+```
+
+The final step in the gift recording process involves translating the user's selections into the specific parameter format expected by the endorser server API. This mapping is complex because the API uses different fields depending on whether entities are people or projects. For project-to-person gifts, the project is identified by its handle ID in the `providerPlanHandleId` field, while the person is identified in the `toDid` field. Person-to-project gifts reverse this pattern, using `fromDid` for the person and `fulfillsProjectHandleId` for the project. Person-to-person gifts use the simpler `fromDid` and `toDid` pattern.
+
+## State Management
+
+### Core State Variables
+```typescript
+// UI State
+visible: boolean = false; // Dialog visibility
+currentStep: number = 1; // Current step (1 or 2)
+stepType: string = "giver"; // Current selection type
+
+// Entity State
+giver?: GiverReceiverInputInfo; // Selected giver
+receiver?: GiverReceiverInputInfo; // Selected recipient
+giverEntityType: "person" | "project";
+recipientEntityType: "person" | "project";
+
+// Form State
+description: string = ""; // Gift description
+amountInput: string = "0"; // Gift amount
+unitCode: string = "HUR"; // Unit of measurement
+
+// Data State
+allContacts: Contact[] = []; // Available contacts
+projects: PlanData[] = []; // Available projects
+activeDid: string = ""; // Current user's DID
+```
+
+The component maintains several categories of state to track the user's progress through the gift recording process. UI state controls the dialog's visibility and current step, while entity state tracks the selected giver and recipient along with their types. Form state holds the user's input for the gift details, and data state contains the available options loaded from the database and API. This separation makes the component's behavior predictable and easier to debug.
+
+### Navigation State Transitions
+```mermaid
+graph TD
+ A[Dialog Closed] --> B[open() called]
+ B --> C{Giver pre-selected?}
+ C -->|Yes| D[Step 2: Gift Details]
+ C -->|No| E[Step 1: Entity Selection]
+ E --> F{Entity selected}
+ F --> D
+ D --> G{User action}
+ G -->|Edit Entity| E
+ G -->|Confirm| H[Submit Gift]
+ G -->|Cancel| A
+ H --> I{Success?}
+ I -->|Yes| A
+ I -->|No| D
+```
+
+The state transition diagram illustrates the possible paths users can take through the dialog. The flow begins when the dialog is opened and branches based on whether sufficient context was provided to skip entity selection. Users can move back and forth between steps, edit their selections, or cancel at any time. After submitting a gift, the flow either returns to the closed state (on success) or back to the details step (on error) to allow for corrections.
+
+## Error Handling
+
+### Validation Layers
+1. **UI Prevention:** Disable/gray out invalid options
+2. **Form Validation:** Check required fields and business rules
+3. **API Validation:** Handle server-side errors gracefully
+4. **User Feedback:** Clear error messages with specific guidance
+
+The component implements a multi-layered approach to error prevention and handling. The first layer prevents errors by disabling invalid options in the user interface, such as graying out contacts that would create conflicts. The second layer validates form inputs before submission, checking for required fields and business rule violations. The third layer handles errors returned by the server API, while the fourth layer ensures users receive clear, actionable feedback about any issues that occur.
+
+### Common Error Scenarios
+- **Missing Identifier:** User hasn't selected an active DID
+- **Negative Amount:** Prevent negative gift values
+- **Empty Gift:** Require either description or amount
+- **Person Conflict:** Same person selected as giver and recipient
+- **Network Errors:** API server unreachable or returns errors
+- **Database Errors:** Local storage issues
+
+Each error scenario is handled with specific validation logic and user-friendly error messages. The component provides clear guidance on how to resolve issues, such as directing users to select an identifier or adjust their amount input. Network and database errors are caught and presented with appropriate fallback options.
+
+## Security Considerations
+
+### Data Privacy
+- **DID Protection:** User identifiers only shared with explicit consent
+- **Local Storage:** Sensitive data encrypted in local database
+- **Network Transport:** All API calls use HTTPS encryption
+
+The component maintains strict privacy controls over user data, particularly decentralized identifiers which serve as the core of user identity in the system. DIDs are only transmitted to the server when users explicitly choose to record a gift, and all local storage uses encryption to protect sensitive information.
+
+### Input Validation
+- **SQL Injection Prevention:** Parameterized database queries
+- **XSS Protection:** Input sanitization and Vue's built-in escaping
+- **Amount Validation:** Numeric input validation and range checking
+
+All user inputs are validated both on the client side for immediate feedback and on the server side for security. The component uses parameterized queries to prevent SQL injection attacks and relies on Vue's built-in template escaping to prevent cross-site scripting vulnerabilities.
+
+## Performance Optimization
+
+### Lazy Loading
+- **Projects:** Only loaded when needed for project-related gifts
+- **Contacts:** Cached after initial load to avoid repeated queries
+- **Database:** Optimized queries with proper indexing
+
+The component optimizes performance by loading data only when needed. Projects are fetched from the API only when the dialog needs to display them, reducing unnecessary network requests. Contact information is cached after the initial load to avoid repeated database queries. Database operations are optimized through proper indexing and efficient query patterns.
+
+### Reactive Updates
+- **Watchers:** Automatically update entity types when props change
+- **Computed Properties:** Efficient conflict detection and UI state
+- **Minimal Re-renders:** Strategic use of v-show vs v-if
+
+Vue's reactivity system is leveraged to ensure the interface stays synchronized with changing data while minimizing unnecessary re-renders. Watchers automatically update internal state when component properties change, computed properties efficiently calculate derived state like conflict detection, and the template uses v-show instead of v-if where appropriate to avoid expensive DOM manipulations.
+
+## Integration Points
+
+### External Dependencies
+- **Endorser Server:** Gift submission and verification
+- **Database Layer:** Contact and settings management
+- **Platform Services:** Cross-platform database access
+- **Router:** Navigation to related views
+
+The component integrates with several external systems to provide its functionality. The endorser server handles the cryptographic signing and publishing of gift records to the distributed network. The database layer manages local storage of contacts and user settings. Platform services provide an abstraction layer for database access across different deployment targets (web, mobile, desktop). The Vue router enables navigation to related views while preserving state.
+
+### Child Components
+- **EntityIcon:** Person avatar rendering with fallbacks
+- **ProjectIcon:** Project icon rendering with custom images
+- **Notification System:** User feedback and error reporting
+
+The dialog relies on several child components to provide specialized functionality. EntityIcon handles the complex logic of rendering person avatars with appropriate fallbacks when images aren't available. ProjectIcon performs similar duties for project representations. The notification system provides consistent user feedback across the application for both success and error conditions.
+
+## Future Considerations
+
+### Extensibility
+- **New Entity Types:** Architecture supports additional entity types
+- **Custom Units:** Easy to add new currency/unit types
+- **Workflow Steps:** Framework supports additional steps if needed
+
+The component's architecture is designed to accommodate future enhancements without major restructuring. The entity type system could be extended to support new types beyond people and projects. The unit selection system can easily accommodate new currencies or measurement types. The step-based workflow could be expanded to include additional steps for more complex gift recording scenarios.
+
+### Accessibility
+- **Keyboard Navigation:** All interactive elements accessible
+- **Screen Readers:** Semantic HTML and ARIA labels
+- **Color Contrast:** Visual indicators don't rely solely on color
+
+Accessibility considerations ensure the component is usable by people with disabilities. All interactive elements can be navigated using only the keyboard, semantic HTML and ARIA labels provide context for screen readers, and visual indicators use more than just color to convey information. These features make the gift recording process inclusive for all users.
+
+### Testing Strategy
+- **Unit Tests:** Individual method testing
+- **Integration Tests:** Full workflow testing
+- **E2E Tests:** User journey validation
+- **Error Scenarios:** Comprehensive error path testing
+
+A comprehensive testing strategy ensures the component works reliably across different scenarios and platforms. Unit tests validate individual methods and computed properties, integration tests verify the complete workflow from opening to submission, end-to-end tests simulate real user journeys, and error scenario tests ensure graceful handling of failure conditions.
+
+## Component Usage and Integration Context
+
+### Primary Views and Usage Patterns
+
+The `GiftedDialog` component is referenced and used throughout the Time Safari application in various contexts, each with specific requirements and configurations. Understanding where and how this component is integrated provides insight into its versatility and the different user workflows it supports.
+
+#### 1. HomeView - Main Entry Point
+**File:** `src/views/HomeView.vue`
+**Context:** Primary application dashboard and activity feed
+
+The HomeView serves as the main entry point for gift recording, providing users with multiple pathways to create gift records. The dialog is integrated here with a `showProjectsDialog` property that controls whether project options are displayed in the entity selection interface.
+
+```vue
+
+```
+
+**Usage Patterns:**
+- **Gift Prompts Integration:** Connected with `GiftedPrompts` component to provide suggested gift ideas
+- **"Unnamed" Giver Support:** Special handling for recording gifts from unknown or unnamed individuals
+- **Context-Aware Opening:** Different title and prompt text based on whether recording from a person or project
+
+The HomeView implementation includes sophisticated logic for handling "Unnamed" givers, where the dialog is opened with specific pre-selections and immediately advances to Step 2 after calling `selectGiver()`. This streamlines the user experience when users want to record gifts from people not in their contact list.
+
+#### 2. ProjectViewView - Project-Specific Context
+**File:** `src/views/ProjectViewView.vue`
+**Context:** Individual project pages with bidirectional gift recording
+
+ProjectViewView contains two separate instances of GiftedDialog to handle different gift directions:
+
+```vue
+
+
+
+
+
+```
+
+**Specialized Features:**
+- **Bidirectional Gift Recording:** Supports both giving to and receiving from projects
+- **Project Context Locking:** The project entity is pre-selected and cannot be changed
+- **Offer Integration:** Can be opened with pre-populated offer information
+- **Project-Specific Prompts:** Custom titles and descriptions based on project context
+
+The ProjectViewView demonstrates the component's flexibility in handling complex scenarios where one entity (the project) is fixed while the other (person) needs to be selected. The `isFromProjectView` property helps the dialog understand this constrained context.
+
+#### 3. ContactsView - Contact-Specific Gift Recording
+**File:** `src/views/ContactsView.vue`
+**Context:** Contact management with direct gift recording capabilities
+
+ContactsView integrates the dialog for recording gifts between the current user and specific contacts, with sophisticated confirmation flows to ensure users understand the direction of the gift:
+
+```vue
+
+```
+
+**Key Features:**
+- **Bidirectional Confirmation:** Users confirm whether they're recording giving or receiving
+- **Contact Pre-selection:** The contact is already known, simplifying entity selection
+- **Direction Clarity:** Clear messaging about gift direction to prevent confusion
+
+The ContactsView implementation includes a two-step confirmation process (`confirmShowGiftedDialog` and `showGiftedDialog`) that ensures users clearly understand whether they're recording giving something to a contact or receiving something from them.
+
+#### 4. ContactGiftingView - Specialized Gift Recording Interface
+**File:** `src/views/ContactGiftingView.vue`
+**Context:** Dedicated interface for complex gift recording scenarios
+
+This view provides a specialized interface for gift recording with advanced entity type handling and step management:
+
+```vue
+
+```
+
+**Advanced Features:**
+- **Dynamic Entity Type Resolution:** Supports complex scenarios with projects and people
+- **Step Type Management:** Handles both giver and recipient selection workflows
+- **Context Preservation:** Maintains complex state across navigation
+
+ContactGiftingView demonstrates the most sophisticated usage of GiftedDialog, with comprehensive support for all entity type combinations and step management scenarios.
+
+#### 5. ClaimView - Offer Fulfillment Context
+**File:** `src/views/ClaimView.vue`
+**Context:** Converting offers into actual gift records
+
+ClaimView uses GiftedDialog to record gifts that fulfill existing offers, creating a connection between the offer system and gift recording:
+
+```vue
+
+```
+
+**Offer Integration Features:**
+- **Offer Pre-population:** Gift details can be pre-filled from offer information
+- **Fulfillment Tracking:** Links gifts to specific offers for tracking purposes
+- **Context-Aware Prompts:** Custom messaging for offer fulfillment scenarios
+
+#### 6. Supporting Views - Additional Integration Points
+
+**RecentOffersToUserView & RecentOffersToUserProjectsView:**
+- Provide quick access to gift recording from offer listings
+- Support both personal and project-related offer contexts
+
+**NewActivityView:**
+- Integrates gift recording into activity creation workflows
+- Supports creating gifts as part of broader activity documentation
+
+### Integration Patterns and Best Practices
+
+#### Common Integration Pattern
+Most views follow a consistent pattern for integrating GiftedDialog:
+
+1. **Template Declaration:** Include the component with appropriate props
+2. **Reference Setup:** Use `ref` attribute for programmatic access
+3. **Method Integration:** Implement `openDialog` or similar methods
+4. **Context Configuration:** Set appropriate props based on view context
+5. **State Management:** Handle dialog results and state updates
+
+#### Props Configuration Strategy
+The component's props are designed to work together to create specific behaviors:
+
+- **Mutual Exclusivity:** `fromProjectId` and `toProjectId` are mutually exclusive
+- **Context Indicators:** `isFromProjectView` provides navigation context
+- **Display Control:** `showProjects` overrides default entity type logic
+- **Behavioral Modification:** Props combination determines available workflows
+
+#### Error Handling and User Experience
+Each integration point implements appropriate error handling and user experience considerations:
+
+- **Validation Feedback:** Clear error messages for invalid selections
+- **Context Preservation:** State maintained across navigation
+- **Graceful Degradation:** Fallback options when data is unavailable
+- **Accessibility Support:** Keyboard navigation and screen reader compatibility
+
+### Development and Maintenance Considerations
+
+#### Component Coupling
+The widespread usage of GiftedDialog creates important coupling considerations:
+
+- **Interface Stability:** Changes to the component's API affect multiple views
+- **Testing Requirements:** Each integration context requires specific test coverage
+- **Performance Impact:** Component optimization benefits multiple user workflows
+- **Documentation Needs:** Clear usage patterns help maintain consistency
+
+#### Future Evolution
+The component's integration patterns suggest several areas for future development:
+
+- **Workflow Standardization:** Common patterns could be extracted into mixins
+- **State Management:** Complex state could benefit from centralized management
+- **Type Safety:** Better TypeScript integration for props and methods
+- **Accessibility Enhancement:** Consistent accessibility patterns across integrations
+
+This comprehensive integration context demonstrates how GiftedDialog serves as a central component in the Time Safari application's gift recording ecosystem, supporting diverse user workflows while maintaining consistency and usability across different contexts.
+
+## Detailed Implementation Roadmap for Future Enhancements
+
+### 1. New Entity Types Implementation
+
+The current architecture supports people and projects, but could be extended to support additional entity types such as organizations, events, or resources. Here's precisely what these changes would look like:
+
+#### Current Entity Type System
+```typescript
+// Current implementation in GiftedDialog.vue
+giverEntityType: "person" | "project" = "person";
+recipientEntityType: "person" | "project" = "person";
+
+updateEntityTypes() {
+ this.giverEntityType = "person";
+ this.recipientEntityType = "person";
+
+ if (this.showProjects) {
+ this.giverEntityType = "project";
+ } else if (this.fromProjectId) {
+ this.giverEntityType = "project";
+ } else if (this.toProjectId) {
+ this.recipientEntityType = "project";
+ }
+}
+```
+
+#### Extended Entity Type System
+```typescript
+// Enhanced implementation with new entity types
+type EntityType = "person" | "project" | "organization" | "event" | "resource";
+
+// New props to support additional entity types
+@Prop() fromOrganizationId = "";
+@Prop() toOrganizationId = "";
+@Prop() fromEventId = "";
+@Prop() toEventId = "";
+@Prop() fromResourceId = "";
+@Prop() toResourceId = "";
+@Prop() showOrganizations = false;
+@Prop() showEvents = false;
+@Prop() showResources = false;
+
+giverEntityType: EntityType = "person";
+recipientEntityType: EntityType = "person";
+
+updateEntityTypes() {
+ // Reset to default
+ this.giverEntityType = "person";
+ this.recipientEntityType = "person";
+
+ // Apply context-specific logic with priority order
+ if (this.showOrganizations) {
+ this.giverEntityType = "organization";
+ } else if (this.showEvents) {
+ this.giverEntityType = "event";
+ } else if (this.showResources) {
+ this.giverEntityType = "resource";
+ } else if (this.showProjects) {
+ this.giverEntityType = "project";
+ } else if (this.fromOrganizationId) {
+ this.giverEntityType = "organization";
+ } else if (this.fromEventId) {
+ this.giverEntityType = "event";
+ } else if (this.fromResourceId) {
+ this.giverEntityType = "resource";
+ } else if (this.fromProjectId) {
+ this.giverEntityType = "project";
+ } else if (this.toOrganizationId) {
+ this.recipientEntityType = "organization";
+ } else if (this.toEventId) {
+ this.recipientEntityType = "event";
+ } else if (this.toResourceId) {
+ this.recipientEntityType = "resource";
+ } else if (this.toProjectId) {
+ this.recipientEntityType = "project";
+ }
+}
+```
+
+#### New Component Integration Required
+```vue
+
+
+
+
+
+
+```
+
+#### API Parameter Mapping Extensions
+```typescript
+// Extended gift recording logic
+async recordGive() {
+ let apiParams: any = {
+ description: this.description,
+ amount: parseFloat(this.amountInput),
+ unit: this.unitCode
+ };
+
+ // Entity-specific parameter mapping
+ switch (`${this.giverEntityType}-${this.recipientEntityType}`) {
+ case "person-person":
+ apiParams.fromDid = this.giver?.did;
+ apiParams.toDid = this.receiver?.did;
+ break;
+ case "person-project":
+ apiParams.fromDid = this.giver?.did;
+ apiParams.fulfillsProjectHandleId = this.toProjectId;
+ break;
+ case "project-person":
+ apiParams.providerPlanHandleId = this.fromProjectId;
+ apiParams.toDid = this.receiver?.did;
+ break;
+ case "person-organization":
+ apiParams.fromDid = this.giver?.did;
+ apiParams.fulfillsOrganizationHandleId = this.toOrganizationId;
+ break;
+ case "organization-person":
+ apiParams.providerOrganizationHandleId = this.fromOrganizationId;
+ apiParams.toDid = this.receiver?.did;
+ break;
+ case "person-event":
+ apiParams.fromDid = this.giver?.did;
+ apiParams.fulfillsEventHandleId = this.toEventId;
+ break;
+ case "event-person":
+ apiParams.providerEventHandleId = this.fromEventId;
+ apiParams.toDid = this.receiver?.did;
+ break;
+ case "person-resource":
+ apiParams.fromDid = this.giver?.did;
+ apiParams.fulfillsResourceHandleId = this.toResourceId;
+ break;
+ case "resource-person":
+ apiParams.providerResourceHandleId = this.fromResourceId;
+ apiParams.toDid = this.receiver?.did;
+ break;
+ default:
+ throw new Error(`Unsupported entity combination: ${this.giverEntityType}-${this.recipientEntityType}`);
+ }
+
+ // Submit to endorser server
+ const result = await createAndSubmitGive(apiParams);
+}
+```
+
+### 2. Custom Units Implementation
+
+The current unit system supports Hours, USD, BTC, BX, and ETH. Here's how to add new currency/unit types:
+
+#### Current Unit System
+```typescript
+// Current implementation in GiftedDialog.vue
+unitCode = "HUR";
+
+// In template
+
+```
+
+#### Enhanced Unit System
+```typescript
+// New unit configuration system
+interface UnitDefinition {
+ code: string;
+ name: string;
+ symbol: string;
+ category: "time" | "currency" | "token" | "custom";
+ decimals: number;
+ conversionRate?: number; // Optional conversion to base unit
+}
+
+// Configurable unit registry
+const UNIT_REGISTRY: UnitDefinition[] = [
+ // Time units
+ { code: "HUR", name: "Hours", symbol: "hr", category: "time", decimals: 2 },
+ { code: "MIN", name: "Minutes", symbol: "min", category: "time", decimals: 0 },
+ { code: "DAY", name: "Days", symbol: "day", category: "time", decimals: 1 },
+
+ // Traditional currencies
+ { code: "USD", name: "US Dollar", symbol: "$", category: "currency", decimals: 2 },
+ { code: "EUR", name: "Euro", symbol: "€", category: "currency", decimals: 2 },
+ { code: "GBP", name: "British Pound", symbol: "£", category: "currency", decimals: 2 },
+
+ // Cryptocurrencies
+ { code: "BTC", name: "Bitcoin", symbol: "₿", category: "token", decimals: 8 },
+ { code: "ETH", name: "Ethereum", symbol: "Ξ", category: "token", decimals: 18 },
+ { code: "BX", name: "BX Token", symbol: "BX", category: "token", decimals: 4 },
+
+ // Custom units
+ { code: "KARMA", name: "Karma Points", symbol: "♦", category: "custom", decimals: 0 },
+ { code: "SKILL", name: "Skill Points", symbol: "⚡", category: "custom", decimals: 1 },
+ { code: "REP", name: "Reputation", symbol: "★", category: "custom", decimals: 0 }
+];
+
+// Enhanced component implementation
+export default class GiftedDialog extends Vue {
+ unitCode = "HUR";
+ availableUnits: UnitDefinition[] = [];
+
+ async mounted() {
+ // Load available units based on user preferences or context
+ this.availableUnits = await this.loadAvailableUnits();
+ }
+
+ async loadAvailableUnits(): Promise {
+ // Load from user settings or default configuration
+ const userSettings = await this.getUserSettings();
+ if (userSettings.customUnits && userSettings.customUnits.length > 0) {
+ return [...UNIT_REGISTRY, ...userSettings.customUnits];
+ }
+ return UNIT_REGISTRY;
+ }
+
+ get unitsByCategory() {
+ return this.availableUnits.reduce((acc, unit) => {
+ if (!acc[unit.category]) acc[unit.category] = [];
+ acc[unit.category].push(unit);
+ return acc;
+ }, {} as Record);
+ }
+
+ get selectedUnit(): UnitDefinition | undefined {
+ return this.availableUnits.find(unit => unit.code === this.unitCode);
+ }
+
+ formatAmount(amount: number): string {
+ const unit = this.selectedUnit;
+ if (!unit) return amount.toString();
+
+ const formattedAmount = amount.toFixed(unit.decimals);
+ return `${unit.symbol}${formattedAmount}`;
+ }
+}
+```
+
+#### Enhanced Template with Categorized Units
+```vue
+
+
+
+
+
+
+
+```
+
+### Implementation Priority
+
+#### High Priority (Immediate User Impact)
+1. **Navigation Flow Fix**: Implement success callbacks and proper navigation
+2. **Step Indicators**: Add visual progress indication
+3. **Parameter Cleanup**: Remove legacy `projectId` confusion
+
+#### Medium Priority (User Experience)
+1. **Enhanced Labels**: Add color-coded context and emoji visual cues
+2. **Error Handling**: Improve error messages and validation feedback
+
+#### Low Priority (Code Quality)
+1. **Method Naming**: Standardize method names for consistency
+2. **Type Safety**: Enhance TypeScript definitions
+3. **Documentation**: Update inline documentation
+
+### Integration with Pinia Refactoring
+
+These quick fixes can be implemented in two ways:
+
+1. **Standalone Implementation**: Apply these fixes to the current component before the Pinia refactoring
+2. **Integrated Implementation**: Include these improvements as part of the Pinia store refactoring plan
+
+**Recommendation**: Implement the navigation flow fixes immediately as they address critical usability issues, then include the UX enhancements as part of the Pinia refactoring for better consistency.
+
+### Testing Requirements
+
+#### Manual Testing Checklist
+- [ ] ContactGiftingView navigation flow works correctly
+- [ ] Users can complete gift recording without getting stuck
+- [ ] Success callbacks navigate to appropriate views
+- [ ] Step indicators show correct progress
+- [ ] Error states are handled gracefully
+
+#### Automated Testing
+- [ ] Update Playwright tests to verify navigation flows
+- [ ] Add tests for success callback functionality
+- [ ] Verify parameter cleanup doesn't break existing functionality
+
+### Risk Assessment
+
+#### Low Risk Changes
+- Adding step indicators (purely visual enhancement)
+- Improving label text and adding emoji
+- Parameter cleanup (removing unused parameters)
+
+#### Medium Risk Changes
+- Navigation flow changes (affects user journey)
+- Success callback implementation (new functionality)
+
+#### Mitigation Strategies
+- Implement changes incrementally
+- Test thoroughly in development environment
+- Have rollback plan ready
+- Monitor user feedback after deployment
+
+**Status**: These improvements are documented as proposed changes and ready for implementation when development resources are available.
+
+---
+
+## TEMPLATE IMPROVEMENTS DURING PINIA REFACTORING
+
+### Overview
+The Pinia refactoring provides an excellent opportunity to modernize and significantly improve the GiftedDialog template. The current template has grown organically and contains several areas that can benefit from modern Vue 3 patterns, better accessibility, improved component composition, and cleaner state management integration.
+
+### Current Template Analysis
+
+#### Strengths
+- ✅ Responsive grid layouts for different screen sizes
+- ✅ Clear visual hierarchy with icons and typography
+- ✅ Conflict detection and prevention UI
+- ✅ Comprehensive entity selection interface
+
+#### Areas for Improvement
+- 🔄 **Complex conditional logic** in template makes it hard to maintain
+- 🔄 **Repetitive code** for entity display and selection
+- 🔄 **Accessibility gaps** in keyboard navigation and screen readers
+- 🔄 **Mixed concerns** - UI logic mixed with business logic
+- 🔄 **Inconsistent styling** patterns across similar elements
+- 🔄 **No step indicators** for user guidance
+- 🔄 **Limited error feedback** for validation states
+
+### Proposed Template Improvements
+
+#### 1. Component Composition and Extraction
+
+**Current Issue**: The template is monolithic with ~400 lines of mixed logic.
+
+**Proposed Solution**: Extract reusable sub-components for better maintainability.
+
+**New Component Structure:**
+```vue
+
+
+