I have a statecharts system that is currently bolting datafy/nav support onto every statechart I use. I realized that it might be a good fit for upstreaming, so all statecharts would support datafy/nav. I have Opus exploring a design for a fork and it looks ilke about 120 lines of code in a new namespace to have statecharts support datafy and nav protocols. Is that something you'd be interested in having upstreamed @tony.kay
it’s interesting…how are you leveraging it?
I have pathom resolvers created automatically using datafy/nav, so the statecharts are fully introspectable with an EQL query on the pathom graph by the AI. I am consolidating to having the AI use only EQL queries on the pathom graph for everything. Tools become one tool app_query and the tool description gives it a few example EQL queries for the operations i want that tool to perform. It's working very well for both the dev agent to query all state to figure out what is going on, and an easy way to create new tools with the exact same interface. AI models are very good at making EQL queries.
I got the idea from core.async.flow which i am using in a few spots for network I/O, it has datafy/nav and creating those pathom resolvers automatically was so simple I had Opus bolt the support onto all my statecharts, so the pathom resolvers are automatically generated.
but what are you resolving? The structure of the chart???
Yes, and the working memory too. I don't have to create a schema, with datafy/nav the pathom resolvers are automatic, and the malli schema generation is also automatic.
The whole chart can be introspected by the AI with EQL queries to pathom.
why is that better than just pointing it at the chart’s definition?
It can look at the definition, and it can look at the current state in the runtime while it's running.
Just as an example I have an agent queue it kept getting stuck. It used the EQL queries to inspect the running state, and then looked at the chart definition, and found where the transitions were not correct. It's a troubleshooting helper, and you can send events through pathom. You can create mutations in pathom that send events to the statecharts, which means with the one tool the AI can inspect everything, and it can use the mutations to manipulate state.
It's really working well for me, and I'm going to do this fork, I just wondered if you were interested in the upstream.
I'm actually using fulcro headless, and I inject the fulcro env with the pathom env into the simple statecharts env, so statecharts can do fulcro things, and pathom things, and statechart things all from it's own env.
I don't know that I'm doing it right but it's working so well I don't even believe I designed this thing. I'm a few weeks away from releasing it.
sure, as long as it doesn’t need to add deps, I’m open to including it…additional section in the book might also be nice (not necessarily tied to your use-case, but an examples section might be nice with ideas as well).