[ ] finalize Q-initial greeting &/or test via url param dyn
[ ] enforce usage of main chat window (now that stories movable - keep at minimum size?); remove from memoryLane)
[ ] allow avatar to go "public" - demonstrate externally, whether it be on-demand actor or actual instructionset
[ ] dynamic event dialog: use mRunFunction instead of direct chain
[ ] consider Asset Assistant as core singleton in avatar once needed (instantiate on-demand)
[ ] HELP knowledge incorporated into Q help sub-bots
[ ] event-driven streaming refactor
[ ] frontend architecture to receive functional commands from backend - example: { "function": "createInput", "type": "textarea", "parameter": { etc. for placeholder text, length, anything ultimately} } JSON concept that would communicate between front and back, therefore diminishing even the need for defined frontend only API receipt; originally written as: avatar HTML input mechanics: within scripts, potentially chat, should server just send in its own HTML input mechanisms? That would be pretty damn cool, twisting the old mechanic on its head which moved away from that... but now, with intelligence,
[ ] vectorstore creation, include basic re-usable MyLife document, providing more context to any agent with file-search
[ ] create timer for select mechanic -> both frontend and backend... essentially, data snapchats after 120s (tbd)
[ ] bot sleep-mode (revert to avatar or if avatar logout? play random experience?)
Fixes
[ ] reverse order of messages from server (at least from registration)
[ ] wait for one message to be displayed before running the next
[ ] if any error occurs inside event dialog (or elsewhere?) it recovers by making endless calls to openai!
[ ] refactor globals to include chat elements working across guest/member.mjs
[ ] emails submitted to registration could be reviewed for internal consistency (IRL ex. @gmail.cmo)
Enhancements
dynmRunFunctioninstead of direct chain{ "function": "createInput", "type": "textarea", "parameter": { etc. for placeholder text, length, anything ultimately} }JSON concept that would communicate between front and back, therefore diminishing even the need for defined frontend only API receipt; originally written as: avatar HTML input mechanics: within scripts, potentially chat, should server just send in its own HTML input mechanisms? That would be pretty damn cool, twisting the old mechanic on its head which moved away from that... but now, with intelligence,Fixes
guest/member.mjs@gmail.cmo)Cosmetic
Test
Placeholders