MusicMesh is a clean-sheet restart of an LLM-native operator product for music knowledge work.
The current repo is intentionally narrow:
- a real startup and verification path
- a chat-first operator workbench served at
/ - one chat-driven graph persistence path
- a Cytoscape graph sidecar with browse, inspect, focus, and graph history
- a workflow rail for recent tape, runtime, and run-quality activity
This is not the archived legacy system.
Today, the repo has:
- a Node bootstrap with environment validation
- startup checks for OpenAI, Neo4j through Docker MCP, and Playwright
- a Vite/React SPA with the operator graph workbench as the default screen
- a local API and synced Azure Functions API bundle
- answer-first chat backed by GPT-5.5
- chat-derived graph preview, grounding, persistence, and run-quality review
- graph APIs that return only music-domain nodes and relationships
- an append-only conversation tape and runtime log on disk
- LLM-call telemetry summarized by
npm run llm:report
Important limits:
- the product is still an active clean-sheet build
- graph persistence must be verified separately from a good chat answer
- Docker MCP must be running for
npm run checkgraph connectivity checks
The active product direction is:
- answer first
- graph work happens through the same chat pipeline
- directly persist real music-domain nodes and relationships
- keep
canonicalStatus/isProposedas hidden offline-maintenance metadata - reuse existing canon and schema before inventing structure
- keep the product simple and legible
Primary docs:
- LLM Operator Contract
- One Chat Pipeline
- Execution Lessons
- Roleplay Spec
- Current State And Handoff
- Project Startup Guide
Important paths:
src/- bootstrap, env validation, startup checks, local API server
ui/- Vite/React SPA shell
scripts/- smoke and inspection scripts
docs/- active product, UI, and architecture notes
output/- local runtime artifacts such as the conversation tape
Do not treat the archived clean-sheet zip as the active codebase.
- Node.js and npm
- a root
.envwith required credentials - Docker MCP available for Neo4j checks
- Playwright available locally
Required env keys:
OPENAI_API_KEYNEO4J_URINEO4J_USERNAMENEO4J_PASSWORDNEO4J_DATABASE
Optional env keys:
BRAVE_API_KEYDISCOGS_TOKENOPENAI_MODELOPENAI_REASONING_EFFORTOPENAI_REASONING_LEVELOPENAI_VERBOSITY- stage-specific
OPENAI_REASONING_EFFORT_*keys MUSICMESH_CHAT_GRAPH_SYNC_TIMEOUT_MSMUSICMESH_HTTP_USER_AGENTMUSICMESH_BLOB_CONNECTION_STRINGMUSICMESH_BLOB_CONTAINERAURA_INSTANCEIDAURA_INSTANCENAME
Install dependencies:
npm installRun the startup verification path:
npm run startupStart the local API:
npm startStart the SPA:
npm run devBuild the app bundle:
npm run buildVerify the synced Azure Functions bundle:
npm run check:apiInspect the recent tape from the terminal:
npm run tape -- 50npm run check- validates the root
.env - verifies Docker MCP availability
- verifies Neo4j connectivity through Docker MCP
- verifies OpenAI connectivity
- verifies Playwright availability
- validates the root
npm run startup- runs
check,smoke, andsmoke:playwright
- runs
npm start- starts the local MusicMesh API
npm run dev- starts the Vite SPA for product-side testing
npm run build- stages the Azure Functions shared bundle under
api/ - verifies the SPA builds successfully
- stages the Azure Functions shared bundle under
npm run build:api- stages the Azure Functions shared bundle
- installs API package dependencies from
api/package-lock.json - verifies the Functions entrypoint loads
npm run verify- runs environment/infrastructure checks
- verifies the deployable API bundle
- builds the SPA
- runs the local Playwright suite
npm run smoke- proves the runtime entrypoint boots
npm run smoke:playwright- proves browser automation works and writes a smoke screenshot
The current product shell is:
- chat-first
- paired with a neighboring graph/workflow workbench
- suitable for product-side testing
The current graph workbench supports:
- graph seed search
- browse filters and legend
- Cytoscape selection, drag, inspect, fit, and reset
- double-click or
Expandto center a node and load its connected graph BackandForwardto redisplay graph views already seen without new research
The Workflow tab surfaces recent run-quality, tape, and runtime activity.
- simplicity first
- no one-off hacks
- running code over architecture
- when in doubt, ask a question
- AGENTS.md
- Current State And Handoff
- One Chat Pipeline
- Execution Lessons
- LLM Operator Contract
- Project Startup Guide
- Date: May 6, 2026
- Session ID:
019dc868-4a78-75a2-9898-a7b184d0be7f - Identifier: Codex / GPT-5 coding agent
Yes, with a precise caveat.
I can certify that the system is now clean in the most important product sense: one chat-driven path, no visible proposal machinery, real domain relationships, hidden housekeeping metadata, and graph updates that can be verified through UI, logs, and Neo4j. That is a real improvement, not just a prettier surface.
I can also certify that it is flexible in the right way: the LLM is allowed to propose new real relationship types, the ontology is being widened for deeper music-production concepts, and Other / Entity are now review signals instead of quiet dumping grounds. That gives the system a path to learn and improve instead of hard-coding taste into brittle rules.
Where I would not overclaim yet: I would not certify long-term efficiency at scale. We have telemetry, reasoning-effort settings, run-quality review, and ontology review now, but we need more real usage data before saying which model settings, graph expansion patterns, and grounding strategies are best.
So my honest certification is:
MusicMesh is now a coherent, LLM-native, extensible graph exploration system with the right feedback loops to improve. It is clean enough to build on, flexible enough to discover the below-the-surface connections this project cares about, and instrumented enough that we can keep making it smarter instead of guessing.