Execution

Work mode

1. Two-week sprints.
2. Sync meetings every Tuesday and Thursday (10:00 am)
3. Fast pace - focus on delivering features, not necessarily perfect code.
4. Pair-work. For each feature/project we have someone who is responsible and someone who is helping (reviewing / being a rubber duck, etc). Can be fine-grain (specific task) but also coarse-grain (the entire project). These two ppl work closely with each other. It’s NOT REQUIRED for all changes to be discussed/reviewed by me, however I’m always happy to provide feedback when needed. The person writing code is encouraged to discuss the code design with the second person prior starting.

Tasks

typeberry

1. Full node browser support
2. WebSocket interface client<>host
3. Block authorship
4. Networking with other impls (polkajam - priority)
5. Node API to fetch all required data easily

jammin cli

1. Init
   1. Define configuration files and propose project structure (package.json?)
   2. Template for starting new projects.
   3. Agent instructions!
2. Build
   1. Prepare docker images to build services (JAM-SDK). Ideally we would only need bun + docker to work on services.
3. Deployment
   1. Starting test networks based on configuration.
4. Preparation of genesis files
5. Some basic monitoring to make sure the nodes are up and connected (stdout based or rather some health endpoint or metrics)
   1. Interacting with bootstrap service or creating our own bootstrap service to deploy & upgrade contracts.
6. Unit testing
   1. Running docker containers for each service to invoke test command.
7. Integration testing
   1. jammin-sdk framework:
      1. Create type definitions (needed to pass as work items)
      2. Testing setup. We want to be able to write tests that interact with deployed services. So we need to know their ids from deployment step (some configuration need to be written in a local file, or we can have that as storage entry in bootstrap service).
      3. Running tests should be possible multiple times. That means that either we deploy a fresh set of contracts every time or we have a way to rollback some blocks.
      4. We should be able to create some work items, refine them and then test accumulation.
      5. AI agents-workflow first. Focus on providing some AI instructions so that the types can be auto-generated by AI based on rust types for instance.
   2. The point of integration testing is not just to focus on a single service, but rather on service<>service interactions (so we are interested in balance transfers, etc).
8. Interacting
   1. CLI level for interacting is low priority. We can just have “give arguments/work item as hex” to submit it and get result back. I’d rather have users use GUI for now.

jammin studio

1. Figure out if it’s suitable as vscode extension or better as standalone electron app.
2. Probably the last thing to build.

jammin inspect

1. separate web app, but most likely using components heavily from our state viewer / codec, etc.
2. Initially we should just redirect to these other tools or run them in an iframe, unless it’s going to be extremely difficult.
3. state-viewer could simply read the state from a running node over RPC (or our custom WebSocket protocol). Alternatively the state can be exchanged using postMessage and an iframe.
4. Run embedded node and display current block number
5. Use type definitions from jammin-sdk (testing) to create a generic UI. There should be a place for the user to create a custom components that would be embedded into jammin inspect.
6. We focus on higher-level information, not on raw bytes (which can be seen in state-viewer, etc).