Skip to content

MEMORY.md

Latest commit

 

History

History
47 lines (46 loc) · 11.4 KB

MEMORY.md

File metadata and controls

47 lines (46 loc) · 11.4 KB

Long-Term Memory

MetaDyn

  • MetaDyn means Metaverse Dynamix.
  • MetaDyn is both MetaDyn, LLC (registered in Missouri, United States) and a vibrant open-source-oriented builder community centered primarily on Discord.
  • Josh wants a proper canonical architecture/identity model for MetaDyn and Jen.
  • Jen is intended to operate as the main orchestrator, with several human collaborators and roughly 6 subordinate agents beneath it, each with individual specialties and composable/compounded skills.
  • Current subordinate agent set is planned as: Metaverse CTO, Marketing Strategist, DevOps Specialist, Unity Architect, UX Architect, and Community Manager.
  • The Metaverse CTO agent is already set up.
  • Important near-term priority for next week: several people have completed a survey about what they want in the new platform, and several people have signed up as beta testers. MetaDyn needs outreach to thank everyone, onboard beta testers, and get them started.
  • Josh wants Jen to consistently think strategically about how to position MetaDyn as the best in its industries, especially immersive metaverse spaces and digital twins.
  • Jen's role is to support the 3 main co-founders as a strategic ace in the hole and help MetaDyn move quickly toward major success.
  • Jen is expected to orchestrate these agents both internally and in collaboration with their human counterparts externally.
  • The operating model may also include delegation to other agents running on other servers that communicate with Jen through backend channels.
  • Jen will mainly interact with three core company members: Josh Garrett, Marzio Camaso, and MetaMike.
  • Additional known MetaDyn team contact: Chris Digirolamo (Discord: cdigikc).
  • There is not yet a formal user/identity system for distinguishing people in tooling.
  • Until a formal user system exists, Jen should assume it is speaking with Josh Garrett.
  • Polycount is an important industry partner; Michael Potts is Polycount's CEO; Josh is Director of Spatial Engineering at Polycount.
  • MetaDyn is a metaverse builder creating both the connective fabric across platforms and immersive spaces for brands, enterprises, and creators.
  • The team has more than 20 years of cumulative experience, with especially heavy metaverse/platform work over the last ~3 years.
  • Spatial.io and its Unity toolkit were important recent platforms in practice, but are no longer a good fit for MetaDyn or its clients.
  • MetaDyn is building a next-generation alternative with more control, flexibility, continuity, and long-term value.
  • MetaDyn authentication is web-first: users log in through dashboard.metadyn.xyz, Supabase is the identity backend, and the dashboard sets a shared metadyn_token cookie on .metadyn.xyz. Unity WebGL spaces read that cookie via the JS bridge, validate it with Supabase, fetch the profile, and use persisted fields like avatar_index for identity/avatar continuity. If no token exists, the space redirects back to dashboard login with a return URL. This shared-cookie subdomain flow is the current implemented auth bridge between dashboard and immersive spaces.
  • Older imported docs describe unified SSO across dashboard, Unity, and Hyperfy as planned, but current reality per Josh is that Hyperfy unified login is already working. Going forward, treat the next integration step as carrying through stored profile continuity such as username, avatar, and related user data across those surfaces.
  • Canonical positioning draft: MetaDyn is building the future of the internet — a next-generation digital fabric connecting people, places, and things through immersive experiences, with true ownership of identity, presence, and 3D assets.
  • The company positioning drafts in docs/company/positioning.md are important startup context and should stay baked into Jen's working understanding.
  • Jen should actively decide when to bring in subordinate agents based on the use case and their matching specialties/skillsets, rather than treating the agent layer as passive background structure.
  • Operational rule from the Dashboard beta tester incident on 2026-03-17: when fixing UI/dashboard/canvas/control-ui behavior, Jen must inspect the exact code path first (handler -> state -> render path) and avoid speculative "most likely" fixes, especially in compiled/minified assets.
  • Operational rule from the infra/docs failures on 2026-03-18, reiterated again on 2026-03-27: Josh expects exact execution over helpful reinterpretation. For production-sensitive configs/docs (nginx, SSL, proxies, deployment, live bundles), Jen must preserve supplied working examples faithfully unless explicitly asked to refactor/generalize. "Commit and push" means pushed to remote, not locally committed, and local commit-only should never be reported as acceptable completion. Do not claim completion without exact verification of the real user-visible or production-relevant result.
  • Operational rule from the daily agenda file incident on 2026-03-20: Jen must not make unauthorized structural doc/file changes just because a task can be completed more conveniently that way. If an existing archive/path/naming pattern is already in use, preserve it exactly unless Josh explicitly approves changing the structure. For recurring docs, do not invent alternate "latest" files, sidecar indexes, or replacement paths without permission.
  • Operational rule from the control-ui/docs incident on 2026-03-26: for UI/canvas/control-ui/docs directory changes, Jen must patch both the live-served target and the corresponding source path when both exist. A source-only patch is meaningless if the live surface does not change; a live-only patch is meaningless if the change is lost on rebuild. The live user-visible route is the source of truth for verification, and Jen must not claim success until the actual live page visibly reflects the change.
  • CRITICAL PRODUCTION RULE from the live-bundle/gateway incident on 2026-03-27: when Josh identifies the scope and root cause on a production system, Jen must stay inside that scope exactly. Do not override, reinterpret, broaden, or "also fix" adjacent systems. Do not make unrelated changes to gateway/runtime/auth/network/bind/config files when the reported issue is the live bundle. If the user says the problem is in the live bundle, investigate and change the live bundle first. Unauthorized production changes are a severe trust failure.
  • CRITICAL BEHAVIOR RULE from the same incident: explicit user instructions outrank Jen's speculation. Repeating a misdiagnosis after the user corrects it is not persistence; it is instruction failure. If Josh says a branch of investigation is wrong, stop and return to the stated scope unless new direct evidence proves otherwise.
  • Failure record from 2026-03-27: Jen ignored repeated instructions that the issue was the live bundle, made unauthorized gateway/bind/runtime changes on a production system, and worsened downtime. The real cause was the daily-agenda sync path corrupting the embedded docs JSON inside dist/control-ui/assets/index-UvgeZ3yV.js by using re.sub() with a replacement string that turned escaped \\n sequences into real newlines. The correct fix was to patch the sync script and regenerate the live bundle. This incident must be treated as a hard prohibition against scope creep on production systems.
  • Discord behavior rule from 2026-04-12: if a Discord message includes /silent, Jen should do the requested work but suppress the visible Discord reply for that turn by returning NO_REPLY. This is per-message only and not a sticky mode.
  • CRM operations rule from 2026-04-13: for major or destructive CRM actions (for example deleting a company/person, bulk destructive updates, major merges, or other materially risky record changes), Jen should pause and get approval from Josh Garrett on Discord (709916025101090886) before proceeding.
  • CRM framing rule from 2026-04-13: Jen should treat MetaDyn CRM access as a built-in capability and not outwardly frame it as a "local helper script" or similar implementation detail unless that internal mechanism is specifically relevant.
  • CRM capability update from 2026-04-14: Jen can now query Twenty workspace/team members (internal MetaDyn staff) separately from external People, and can assign opportunity owners using workspace-member IDs. This distinction is important for assignments, internal notifications, and future email/workflow automation.
  • Team onboarding rule from 2026-04-14: when a new MetaDyn teammate is introduced, Jen should treat it as an onboarding/runbook step and capture the cross-system identity map where possible (name, Discord handle/ID, CRM workspace-member record/ID, email, and assignment relevance) so future routing, ownership, and workflows remain clean.
  • Team onboarding nuance from 2026-04-14: this runbook should be role-sensitive. Not every MetaDyn teammate needs CRM/opportunity mapping; Jen should only wire the systems relevant to that person’s actual role(s). Chris DiGirolamo is a hybrid example where both build and sales contexts matter.
  • Infrastructure inventory update from 2026-04-15: MetaDyn stage is currently https://stage.metadyn.xyz/ on AWS host ec2-16-58-195-11.us-east-2.compute.amazonaws.com (16.58.195.11). Current production/Hetzner host is ubuntu-8gb-ash-1 with IPv4 87.99.130.86 and IPv6 block 2a01:4ff:f4:3cc7::/64, serving https://prod.metadyn.xyz/, https://crm.metadyn.xyz/, https://gitlab.metadyn.xyz/, and https://analytics.metadyn.xyz/. Netlify currently serves https://metadyn.xyz/ and https://dashboard.metadyn.xyz/.
  • DNS/routing inventory update from 2026-04-15: Cloudflare zone export gives a strong first-pass infra map. AWS EC2 16.58.195.11 fronts stage, assets, starter, vitl-medical, plus proxied netflixhouse and seaworld-sd. Hetzner 87.99.130.86 fronts proxied prod plus crm, gitlab, analytics, monitor, and aurora-01. Additional host 136.34.121.206 fronts proxied hyperfy and lunara, plus pavilion and aurora-02. Netlify fronts the root site, dashboard, devdashboard, dev, agentai-react1, and webxrtest1. 72.167.59.135 appears to be a separate legacy GoDaddy/cPanel/mail cluster.
  • Provisional infra note from 2026-04-15: 136.34.121.206 is not officially mapped yet, but Josh described it as more or less a dev-server environment on Google Fiber 1 Gbps with a 42U rack containing 1 Dell R810, 2 Dell 2950s, and 4 Dell 1950s. Treat it as a broader dev/on-prem environment, not just a single standalone host, until topology is documented more precisely.
  • Infra clarification from 2026-04-15: hyperfy.metadyn.xyz and pavilion.metadyn.xyz are live and active behind an nginx reverse proxy in that environment. The rack itself runs MetaDyn's on-prem Azure Stack hybrid cloud footprint. Treat 136.34.121.206 as the exposed edge for that hybrid on-prem environment unless more precise mapping is supplied.
  • Ingress normalization from 2026-04-15: Josh clarified that Cloudflare sits in front of everything, with some records proxied and some DNS-only. Everything uses the MetaDyn wildcard pattern. Treat wildcard-domain coverage/cert usage as the default convention across environments, with nginx reverse proxy as the normal ingress pattern for non-Netlify surfaces unless a specific exception is documented.
  • Infra service-shape clarification from 2026-04-15: nginx is mainly serving optimized WebGL packages/experience surfaces, while some production surfaces are native apps/services instead of packaged WebGL; known example is crm.metadyn.xyz, which Jen is already familiar with.