De perfectionist in mij werd een beetje lastig van Claude die maar zijn ding doet nadat hij maar half begrepen heeft wat ik van hem wil, en hey check it out, ik ben in de tijd gelijk aangenomen als analist op mijn werk, dus ik dacht: waarom zou ik Claude geen analyse geven van wat ik wil in plaats van gewoon te zeggen “euh ik wil iets in deze zin”?
En dus schrijf ik een beknopt document en vraag ik of alles duidelijk is, en hoe verder we in het document gaan, hoe meer er van de computer staat en hoe minder van mij en hopla dan kan hij eraan beginnen en ben ik iets minder onzeker dat het a priori nonsens zal zijn:
Overview
The diary system allows players to move memories into a specialized diary resource, creating a permanent record of experiences. Here is the in-game logic for diaries:
A Diary can hold up to four of your vampire’s Memories. Unlike Memories themselves, Diaries are physical objects that are added to your Resource List. You may freely create a Diary whenever you need to move a Memory into it. Like any other Resource, a Diary can be lost. When this happens strike out the Memories it held. Your vampire can have one Diary at a time, and it must contain at least one Memory.
A Memory placed in the Diary is no longer in the vampire’s head it exists only in the Diary and the vampire accepts whatever is written as truth. Once a Memory has been transferred to a Diary, you may not add any further Experiences to that Memory.
Core Requirements
1. Diary as Resource
- Diary is a specialized resource that appears in the resources list
- Properties: title, description, portable/stationary flag, can be lost
- Visual Identifier:
bi-journal-richtext
icon appears to the left of diary name in resources list
- At most one diary at a time per character
- Diaries cannot be created from the resource list – only by transferring a memory
- Characters may start with a diary or create one by moving a memory
2. Diary Creation Rules
- Only by moving a memory to diary (not via resource creation UI)
- Replacement: If diary is lost, a new one can be created by moving a memory
- Diary must contain at least one memory (enforced by creation method)
- Diary can hold maximum 4 memories
3. Memory-to-Diary Transfer
- Action: Click
bi-journal-plus
icon (positioned left of delete memory icon)
- Visibility: Icon only shows when diary exists and memory not already in diary
- Transfer blocked if diary already has 4 memories (full)
- Effect: Memory is removed from memories list and stored in diary
- Pending State: Transfer is a pending change during the turn (can be undone)
- Permanence: After turn completion, memory transfer becomes permanent
- State Change: Memory gains
in_diary: true
property
- Memories in diary cannot have new experiences added
4. Diary Display Section
- Visibility: Shows only when non-lost diary exists in resources
- Position: Between memories and lost memories sections
- Behavior: Expandable/collapsible section with diary name as header
- Content: Shows memories that have been moved to diary (read-only)
- Ordering: Memories ordered by transfer date (most recent first)
- Capacity Display: Shows current count (e.g., “Diary (2/4)”)
- Lost Diary: When diary is lost, section still shows but memories are unreadable
5. Memory Count and Limits
- 5-memory limit applies only to active memories (not in diary)
- Diary memories do not count toward the 5-memory limit
- Continue Button disabled only when more than 5 active (non-diary) memories exist
- Lost memories also don’t count toward active limit
Technical Integration Points
Current System Analysis
Memory Structure
interface Memory {
id: number
title: string
in_diary: Boolean // Already exists!
is_lost?: Boolean
created_at: string
experiences: Experience[]
experience_count: number
can_add_experience: boolean
}
Character Properties
interface Character {
// ...
diary_memory_count: number // Already exists!
has_diary: Boolean // Already exists!
// ...
}
Required Frontend Changes
1. Resource Display Enhancement
- Add diary detection logic in resources list
- Add
bi-journal-richtext
icon for diary resources
- Prevent diary creation via standard resource creation UI
- Enforce one-diary-per-character rule
2. Memory Actions Enhancement
- Add
bi-journal-plus
icon to memory action buttons
- Position between edit and delete icons
- Show only when diary exists, memory not in diary, and diary not full (< 4 memories)
- Implement move-to-diary functionality as pending change
- Disable experience addition for memories in diary
3. New Diary Section Component
- Create expandable section between memories and lost memories
- Show diary memories in read-only format with transfer date ordering
- Display diary name and capacity in section header (e.g., “My Diary (2/4)”)
- Handle lost diary state (show section but mark memories as unreadable)
- Hide section completely when no diary exists
4. Business Logic Updates
- Memory filtering: exclude
in_diary: true
memories from main list and active count
- Memory counting: diary memories don’t count toward 5-memory limit
- Diary detection: identify diary resources and check capacity
- Move operation: implement as pending change with undo capability
- Continue button: disable only when more than 5 active (non-diary) memories
Clarified Rules and Behaviors
1. Diary Creation Process
- Method: Only by transferring a memory (not via resource creation)
- Trigger: Moving first memory creates diary if none exists
- Replacement: If diary is lost, moving a memory creates new diary
- Content: New diary immediately contains the transferred memory
2. Memory Transfer Rules
- Capacity: Maximum 4 memories per diary
- Pending State: Transfer is undoable until “Continue” is clicked
- Permanence: After turn completion, memories become permanently bound to diary
- Restrictions: Diary memories cannot gain new experiences
3. Memory Counting Logic
- Active Memories: Count excludes diary memories and lost memories
- Continue Button: Disabled when active memory count > 5
- Display: Diary section shows “Diary (current/4)” format
4. Visual Hierarchy
Memories (active, countable toward limit)
├── Regular Memory 1 [Edit] [Move to Diary] [Delete]
├── Regular Memory 2 [Edit] [Move to Diary] [Delete]
└── ...
Diary: My Personal Journal (2/4) [Expandable]
├── Diary Memory 1 (read-only, shows experiences)
├── Diary Memory 2 (read-only, shows experiences)
└── ...
Lost Memories [Expandable]
├── Lost Memory 1
└── ...
5. Lost Diary Behaviour
- Memory Access: Memories in lost diary become unreadable but not truly lost
- Section Display: Diary section remains visible but indicates inaccessibility
- Recovery: If diary is recovered, memories become readable again
- Replacement: New diary can be created even with lost diary containing memories
Implementation Requirements (Confirmed)
Backend API Endpoints Needed
Based on the clarified rules, these endpoints are required:
POST /api/characters/{id}/move-memory-to-diary/
– Create pending memory transfer
DELETE /api/characters/{id}/pending-memory-moves/{memory_id}/
– Undo pending transfer
- Resource creation must be blocked for diary type in standard UI
- Memory experience addition must be blocked for diary memories
Frontend State Management
- Track pending memory-to-diary transfers in game store
- Update diary capacity tracking in real-time
- Exclude diary memories from active memory count
- Handle diary detection from resources list
Implementation Strategy (Revised)
Phase 1: Backend API Verification
- Confirm existing API endpoints for diary functionality
- Test memory transfer and pending change capabilities
- Verify diary capacity and creation restrictions
Phase 2: Resource Enhancement
- Add diary icon rendering in resources list
- Add diary detection and capacity tracking
- Block diary creation via standard resource UI
Phase 3: Memory Transfer System
- Add transfer icon to memory actions with visibility rules
- Implement pending move-to-diary functionality
- Update memory filtering to exclude diary memories from counts
- Disable experience addition for diary memories
Phase 4: Diary Section Component
- Create DiarySection component with expandable behaviour
- Add capacity display in header (e.g., “My Diary (2/4)”)
- Show diary memories in read-only format with proper ordering
- Handle lost diary state (unreadable memories)
Phase 5: Integration and Edge Cases
- Test diary creation by memory transfer
- Test capacity limits and full diary handling
- Test lost diary recovery and replacement scenarios
- Verify memory counting excludes diary memories from 5-memory limit
Technical Specifications
Diary Detection Logic
const diaryResource = resources.find(r => r.type === 'diary' && !r.is_lost)
const hasDiary = !!diaryResource
const diaryCapacity = diaryResource?.diary_memory_count || 0
const diaryFull = diaryCapacity >= 4
Memory Action Visibility
const showMoveToDialry = hasDiary && !memory.in_diary && !diaryFull && !memory.is_lost
Active Memory Count
const activeMemoryCount = memories.filter(m => !m.in_diary && !m.is_lost).length
const canContinue = activeMemoryCount <= 5
Risk Assessment (Updated)
Low Risk
- Backend properties suggest partial implementation exists
- Frontend follows established pending change patterns
- UI components follow existing design system
Medium Risk
- Integration between resource and memory systems
- Proper state synchronization for diary capacity
- Pending change management for memory transfers
Resolved Questions
All major questions have been clarified through user discussion:
- ✅ Diary creation: Only via memory transfer
- ✅ Transfer mechanics: Pending change, undoable until Continue
- ✅ Memory limits: Diary memories excluded from 5-memory limit
- ✅ Capacity: Maximum 4 memories per diary
- ✅ Lost diary: Memories become unreadable but not lost
- ✅ Ordering: Transfer date (most recent first)
Conclusion
The diary functionality has been thoroughly analyzed with all requirements clarified. Key findings:
Confirmed Requirements
- One diary per character: Created only by memory transfer, not via resource UI
- Capacity limits: Maximum 4 memories per diary, minimum 1 (enforced by creation method)
- Pending changes: Memory transfers are undoable until turn completion
- Memory exclusion: Diary memories don’t count toward 5-memory active limit
- Lost diary handling: Memories become unreadable but retained
Implementation Readiness
- Backend properties (
in_diary
, has_diary
, diary_memory_count
) suggest partial implementation
- Frontend follows established patterns for pending changes and entity management
- Clear technical specifications for all components
Next Steps
- Phase 1: Verify backend API capabilities and endpoints
- Phase 2: Implement diary detection and resource list enhancements
- Phase 3: Add memory transfer functionality with pending change support
- Phase 4: Create diary section component with proper capacity and state handling
- Phase 5: Integration testing and edge case verification
Status: Ready for implementation with comprehensive requirements and technical specifications defined.