Questions

Overview

This document captures questions that arise during Phase 1 brainstorming that need clarification.

Instructions

• Questions will be added here automatically as ambiguities arise during brainstorming
• Questions may be resolved naturally by subsequent prompts (and will be removed)
• Periodic Q&A sessions will address remaining questions directly
• Answers will be incorporated back into the appropriate Phase 1 documents

Open Questions

Authentication

1. Should users be able to link multiple OAuth providers to a single account?
2. What happens if a user tries to sign in with a different provider using the same email address?
3. Do we need email verification in addition to OAuth authentication?
4. Should there be a "guest mode" or is authentication required to use the app?
5. What user data should we store locally vs. remotely?
6. How long should sessions remain active before requiring re-authentication?

Content Prioritization & Documentation Structure

Context: The Active Notes brainstorming dump reveals a complex dual-mode application (Journal + Ideas-Generation) with rich philosophical underpinnings.

Question: How should we structure the documentation to handle this dual functionality?

Considerations:

• The app has two distinct user journeys: (1) Logging/journaling past events with photos, and (2) Proactive activity suggestions to fill skill gaps
• These modes share common elements (child profiles, skills database, AI analysis) but have different UX flows
• Should we document these as separate "modules" in the User Experience doc, or treat them as integrated features?
• How do we ensure the Controller Scripts don't become unwieldy when we have both reactive (journal) and proactive (suggestions) processing pipelines?
• Should the Frontend Components be organized by screen/view, or by functional mode?

Impact: This affects how we organize all 5 Phase 1 documents and may influence the ultimate app architecture.

Data Progression & Age Mapping

Context: Skills and behaviours data has been supplied with partial progression information.

Resolved:

• ✅ Format: CSV files provided
• ✅ Structure: Hierarchical for Skills (Category → Sub-category → Skill), Flat for Behaviours
• ✅ Activity templates: Extensive activity data provided with progression levels (1-3 scale)
• ✅ Knowledge areas: Real-world contexts provided (Household, Society, Well-being, Travel, etc.)

Remaining Questions:

• How should age-appropriateness be mapped to the existing progression levels (1-3)?
  • Should Level 1 = ages 4-7, Level 2 = ages 8-12, Level 3 = ages 13+?
  • Or should age ranges be customizable per knowledge area/activity type?
• How do we track skill progression beyond "demonstrated vs. not demonstrated"?
  • Should we use stages like "emerging → developing → proficient → mastery"?
  • How does this map to the existing Level 1-3 scale in activity data?
• Will the skills/behaviours taxonomy be static or user-extensible?
  • Can parents add custom skills beyond the 64 core skills?
  • Can parents add custom behaviours beyond the 22 core character traits?

Data Import Strategy

Context: CSV files provided contain comprehensive skills, behaviours, knowledge areas, and activity data.

Questions:

• Should all CSV data be imported during initial database seeding (one-time import)?
• Or should this be an ongoing/updatable dataset that can be refreshed?
• How do we handle the "Skills used" column in activity CSVs, which contains comma-separated skill references?
  • Need matching/linking strategy between activity data and skills taxonomy
  • Some skill names in activities may not exactly match skill names in Skills-Skills.csv
• Should the Tech category (currently minimal data) be populated with placeholder activities, or left empty until data is supplied?
• How do we preserve the hierarchical relationships in CSVs during import?
  • Some CSVs have merged cells (implied hierarchy) that need to be explicitly modeled in the database

Dual-Mode Functionality: Structural Implications

Context: The app serves two primary purposes:

1. Reactive/Journal Mode: Parent takes photo → AI suggests templates → Log skills/behaviors demonstrated
2. Proactive/Ideas Mode: System identifies gaps → Suggests personalized activities → Parent explores options

Key Questions:

User Experience:

• Are these modes accessed via separate navigation tabs, or is the Ideas mode contextually triggered from the journal view?
• Can users create journal entries directly from suggested activities (creating a feedback loop)?
• Should the "Live CV" output be generated from journal entries only, or also track "planned/intended" activities from Ideas mode?

Database Model:

• Do suggested activities become database entities before they're acted upon, or only after a parent accepts/logs one?
• How do we track which suggestions were shown, dismissed, or accepted (for improving AI recommendations)?
• Is there a relationship between "gaps identified" and "activities suggested" that needs explicit modeling?

Frontend Components:

• Does Ideas mode need its own photo capture, or is it purely suggestion-browsing with optional bookmarking?
• How are "dead zones" (skill gaps) visualized to the user?
• Should activity suggestions be filterable by time investment, location (indoor/outdoor), materials needed, etc.?

Controller Scripts:

• Should gap identification run continuously/periodically, or only when user explicitly enters Ideas mode?
• How often should AI recommendations refresh based on new journal entries?
• Is there a "recommendation engine" that needs to be architected separately from the journal processing pipeline?

Architectural Considerations:

• This dual-mode structure suggests we may need clear separation of concerns in our controller layer
• The AI analysis engine serves both modes but with different goals (identifying past behaviors vs. predicting beneficial future activities)
• May benefit from documenting these as distinct "feature domains" while noting their shared infrastructure

Resolved Questions

Archive of questions that have been answered, for reference.