This first digs into the types which are used as binding to the native environments. Then we build on top of this the foundational data types, which gets us to the point of at least defining the forms and tasks related to the basic data types.
Next, we focus on the note tree parser so we can parse the DSLs we have defined for the foundational data types and the native binding types. Here we build 2 parsers that both take grammars. One parser is for arbitrary text, and the other is for note trees. We use this to parse LeafText into an AST.
Next, we focus on the test runner, as the simplest thing to get the code working after we can parse things into an AST. In an ideal world, the test runner uses a virtual DOM-like rendering technique, so we also need to at some point focus on the implementation of the virtual DOM for generating at least pretty text output.
By this point, we are able to run some tests using hacky ways of invoking the code from the CLI. Well actually, we need to compile the code to an output platform like Node.js or the browser. So we work on figuring out the mapping of the AST nodes into the target platforms, focusing on JavaScript output at first.
Then at this point, we can run tests, get decent output, and compile the code so-to-speak. No typechecking or type inference is in place yet, but we can get that working later. Linting and code prettifying can come later as well.
After tests can be run and inspected, we can focus on the implementation of AST resolving to the object graph, without typechecking necessarily at this point. This will allow us to get the code working or running in a primitive way.
At some point in this process we will also need primitive package management so we can wire up packages and make things modular, importing tasks and forms and such from other modules/cards. So we dive into the implementation of the package manager. The package manager does symlinking and generally works like pnpm.
After testing is basically working, and we can parse and compile basic functions and types to JavaScript, and we can modularize these into decks/packages, we should be able to start extending the system and building out the type checker, as well as the other other output targets and API wrappers.
At this stage we can focus on the implementation of a basic web server, leveraging the Node.js built-ins internally at first, perhaps later switching to Rust and then to native.