evo-agent upgrade v1.1

[Mookse]

Evo-Agent (evolution-assistant) should operate in distinct phases: create, init, develop, mature, maintain, retire

For this ticket, focus on incorporating capture functionality (which is working, but gpt-assistant.metadata was not an effective route to pursue, as they deprecated immediately...) into the new model where file would be dynamically created from core (no longer limited to 512 char) and attached to member's bound avatar on openAI - need only happen once per permutation, but should be tracked as such.

Phase 0: create

• simple constructor facility
• no state change emission, as communication unreceivable

Phase 1: init

Architectural

• decision-making around return of category mode from GPT
  • "Category Mode: [xxx]." remove text and make session adjustments

node.js backend

• await init() routine
• emitters/listeners
• manage phases
• contribution_questions database container
  • build out cosmos container
  • populate base questions per category
• class-extenders.mjs::this.#getQuestions()
  • convert to modular function
  • retrieve from dataservices
  • fix problem with the fact that mbr_id partition is a failure -- container is initialized under mbr_id - should have had a fake partition key for this one, rather than rely on MyLife mbr id
• routes.js
  • /members/:mid/contributions/:cid
  • /members base chat: adhere to new JSON object
  • _memberRouter.post('/category', category)
• functions.mjs
  • create contributions()
  • update contributions() (or create new) with ability to process incoming answers
  • create category() [passes action to avatar, ergo class-extenders.mjs]
• class-extenders.mjs avatar
  • create category()
    • not async, will alter what's immediately necessary and store at "leisure"
  • setContribution()
  • store Contribution objects between communication with other services inside of avatar protected this.# scope

JSON objects

• messages.json
  • message_member_chat
    • properties: ["agent", "category", "contributions", "id", "message", "response_time", "purpose", "type"]
    • required: ["agent", "category", "contributions", "id", "message", "type"]

EJS frontend

• members.html
  • convert chat() parameter to message_member_chat object structure (not a class currently)
• _widget-contributions.html

Assistants

• update avatar 'base' instructions to include category mode information

Outstanding Optionals

• convert 'Category Mode` to openAI function/Action
• return and test functionality for question creation
  • include 512 metadata limit in logic
• todo: need to think more about how to "end" category discussion. My presumption is that it follows this sort of trajectory

1. submit user content along with category flag

• re-route from secondary endpoint to same chat endpoint with additional variables, although still protected behind session.locked

2. category flag will add message/metadata or primer text to thread that links to function agent call, or whatever similar

• determine and implement best or first functional mechanic

3. function trigger would continue to add,
4. add history to avatar's context directly or as summary

Phase 2: develop

optional, convert to new issue? Alpha will be fine up to phase 1

• identify initial logical criteria for improving content in avatar context
  • MyLife core avatar good place to start

Phase notes

• Create: The initial phase where the Evo-Agent is conceptualized and its basic structure and functionality are established.
• Initiate: Following creation, this phase involves setting up the agent, configuring its initial parameters, and preparing it for operation.
• Develop: In this phase, the Evo-Agent is further refined with added functionalities, enhancements, and integrations.
• Mature: The Evo-Agent reaches a state of maturity where it performs its intended functions effectively and efficiently.
• Maintain: Ongoing maintenance to ensure continued optimal performance and to address any emerging issues or bugs.
• Retire: When the Evo-Agent is no longer needed or has become obsolete, it enters the retirement phase where it is decommissioned.

[Mookse]

To implement the "Answer Questions" feature with the flow you've described, you can design the interface and server interaction as follows:

Frontend Interface Design

1. Sidebar Option: Include an "Answer Questions" option in the sidebar for logged-in members. This creates an intuitive pathway for members to engage with the feature.

2. Listing Contribution Topics: When a member selects "Answer Questions," display a list of ongoing Contribution topics. This list can be dynamically loaded from the server, showing titles or brief descriptions of each topic.

3. Topic Selection and Interaction:

   • When a member clicks on a specific topic, it sends a request to the server.
   • The server then responds with a chat object related to that topic, containing either randomized content or AI-generated content based on Contributions[x].questions.

4. Displaying Questions: Present the questions to the member in a conversational format, possibly within a chat interface. This can make the experience more engaging and personal.

5. Member Response: Allow members to type their responses, which are then sent back to the server for processing or storage.

Backend Server Logic

1. Endpoint for Questions: Create a dedicated endpoint on the server to handle requests for Contribution topics and their associated questions.

2. Fetching Contribution Topics: When a request is made to this endpoint, fetch the relevant Contribution topics and their details from your database or storage solution.

3. Generating Chat Objects:

   • Upon a topic selection, generate a chat object that includes questions from Contributions[x].questions.
   • Decide whether to use pre-seeded/randomized content or to generate content using AI, based on your resource constraints and desired user experience.

4. Sending Response: Send the chat object back to the frontend where it can be displayed to the member.

5. Handling Responses: When a member submits their answers, handle this submission appropriately – storing responses, updating member profiles, or triggering any subsequent actions.

This approach ensures a smooth user experience and effective backend handling, balancing member engagement with resource management.