Avatar-Experience

[Mookse]

With the clarification that the Avatar class will manage consent and the portrayal of experiences, and the Session is responsible for making the "hard-coded" requests based on variables stored within the Avatar itself (such as tutorial completion status), here's a revised approach tailored to these specific roles:

Development Steps

Step 1: Update the Avatar Class

• Objective: Enhance the Avatar class in core.mjs to handle consent for and portrayal of experiences. This includes managing state variables like tutorial completion status. Avatar is creating experience-lived as it generates the actual live experience from the experience database blueprint.
• Key Components:
  • Methods for managing consent for different experiences.
  • State management for tracking the member's progress through experiences (e.g., a boolean flag for tutorial completion).
  • Mechanisms for portraying experiences to the member, including serving the content and handling interactions.

Step 2: Implement Experience Invocation in Session

• Objective: Implement logic within the Session class to check the Avatar's state (e.g., whether they have completed the tutorial) and invoke experiences accordingly.
• Key Components:
  • Session checks for specific variables within the Avatar object to determine if an experience should be initiated.
  • Logic to initiate experiences based on the member's state, with hardcoded triggers for now (e.g., starting the tutorial on the member's first login).

Step 3: Define the Experience JSON Structure

• Objective: Create a JSON schema for defining experiences. This structure must be compatible with the Avatar class's capabilities for managing and portraying experiences.
• Key Components:
  • A clear and flexible schema that includes elements for text/chat content, decision points, outcomes, and consent requirements.
  • The schema should be designed with future extensibility in mind, allowing for more complex interactions and GPT integration down the line.

Step 4: Experience Processing and Portrayal

• Objective: Develop mechanisms within the Avatar class for parsing the JSON-defined experiences and managing the flow and portrayal of these experiences to the member.
• Key Components:
  • A parser and controller within the Avatar class to interpret the JSON structure and manage the experience flow.
  • Interface methods in the Avatar class for displaying experience content and capturing member interactions/responses.

Considerations for Alpha Phase One

• Focus on Core Experience: Initially, focus on a simple core experience, such as a tutorial, to test the mechanics of consent, invocation, and portrayal within the Avatar and Session classes.
• Documentation and Testing: Ensure thorough documentation of the new Avatar capabilities and the JSON experience structure. Implement testing to validate the flow of experiences and the integration between Avatar and Session.
• Privacy and Consent: Even in the alpha phase, implement clear consent mechanisms within the Avatar class, ensuring members are informed and agree to participate in experiences.

Next Steps

1. Implement Avatar Enhancements: Start by adding the new methods and state management capabilities to the Avatar class.
2. Develop the Session Invocation Logic: Implement the logic in the Session class to trigger experiences based on Avatar state variables.
3. Design and Test the JSON Experience Structure: Create a prototype JSON structure for experiences and test its compatibility with the enhanced Avatar class.

This approach focuses on leveraging the Avatar class as the primary entity for experience management, with the Session acting as the trigger based on predefined conditions. It sets the foundation for a flexible and member-centric experience management system within MyLife.

[Mookse]

Outlined for brevity:

• [x] Update Avatar Class
  • [x] Remove avatar.json (external agents CANNOT make avatars, they are NOT generic)
  • [x] Convert functionality from *-extenders and modules to core (or peer-equivalent)
  • [x] review getAssistant and assistant-related code... is this API version? first version of it?
  • [x] introduce modes: interface modes: enum: ['experience','standard']
  • [x] getter/setter for mode [ set relies on mValidateMode modular to perform logic]
  • [x] startExperience(): Initiates an avatar experience. This function would set the current experience mode, lock out non-experience requests, and send initial data to the frontend to start the experience.
    • logic
    • inputs
    • outputs
    • errors
• [x] Factory proficiency
  • [x] sanitize schemas for variable names and "sub"-classes
• [x] Session Experience Request pipeline
  • [x] Query MyLife for Experience objects
  • [x] Pass to Avatar? Available for Avatar review?
  • [x] Avatar session storage capacity for lived experiences
  • [x] MyLife pipeline for required or auto-experiences; currently only system-derived, but could be permissioned to allow member->member or perhaps externality->member for a fee (to external agent)
• [x] Define Experience.JSON
  • [x] experience: core object from which to develop experience
  • [x] experience-cast-member
  • [x] experience-scene
  • [x] experience-event
  • [x] experience-lived
• [x] Front-End Capacity
• [x] API pipeline for mode (note: must send cancel mode in order to defuse on server-side)

[Mookse]

I was unable to keep track of changes and tasks as I got deeper in and they commingled, however, artifacts are almost done, providing current punchlist here for completion:

• [x] scene-end remove freaky re-animations and hide click request
• [x] create interface version
  • .stage will hold backdrop value for scene
  • transition backdrops
  • includes:
  • character icon display
  • auto-dialog feed, swapping visible bot
  • create synced layouts when switching between 'bots' either in experience or out
• [x] endExperience fix: check FE first, then backend may be the one holding on to data
  • autoplay session does not trigger, so on reload, post-finish, requires a kickstart when [] is returned from server
• [x] scene skip/implementation?
• [x] navigation bar
• [x] character bar
• [x] experiences bar, incl start experience

[Mookse]

Final Sprint

• [x] member-input spinner/button logic
  • spinner for "writing dialog"
• [x] livedExperience implementation, save/recall
• [x] event dialog capture confirmation - I believe main conversation thread is not stored correctly
• [x] unhide maincontent on unloggedin pages
• [x] sidebar inclusion interface
• [x] clear chat after experience
• [x] HTML unparsed in bubble class
• [x] revive full version of experience