Before pre-betting table: Name in parenthesis means, proposed by this person.

After pre-betting table: Name in parenthesis means taking the lead in shaping. Please involve the right people or distribute the work.

## Blue line

- Measure performance, extend Liskov / CMake to support selecting the mode for performance (Christoph, Till)
- Continue combined stencils (Christoph, Nikki)
- Risk: these stencils contain boundary conditions which can still be a problem for compile times (while better than before). We should check this in advance.
- Performance benchmarking and correctness checking for running Python diffusion from ICON. (Sam, Abishek).

## Green line (Magdalena)
- Integrate JW test case infrastructure (initial conditions, ...)
- It would be nice to finally have all components of the JW test case in icon4py main. That would provide a starting ground for a first architecture refactoring round in up coming cycles.
- metrics fields (from last cycle)
- IO prototype - cleanup and finish (from last cycle)
- initialize vertical grid coords:
- The EXCLAIM experiments use the `SLEVE` vertical coordinate for the height levels. It can be read from a file (MCH experiment) or computed.
- (maybe shaping/research) refactor IconGrid : domain start end, refin_ctl values.
- the domain boundaries can be retrieved from the ICON grid, the implementation that we have is very faithful to the Fortran original and very confusing and should be refactored.

## GT4Py

- Containers (pytree) (Enrique)
- ITIR improvements: (Till, Hannes)
- closure to `apply_stencil` / `map` + `if`
- index builtin
- if-stmts in ITIR (dependency on Type inference or requires adoption of existing type inference)
- cleanup scalars
- Experiment with lowering to `map`-itir for temporary placement (Till, Hannes)
- Type inference on improved ITIR ~~(good task for Sara)~~, review Peter's work (Till)
- Conceptual cleanups? (Enrique, Hannes)
- shaping combined IR?
- Strided ICON execution 2: uniform domain and GPU (Ioannis, Hannes)
- jax.jit/xarray enabler

## DaCe

- orchestration / progress on halo exchange library node (Christos, Fabian?)
- [Edoardo] I am fine with the name "orchestration" as long as it is clear what this task is about. It is about generating a single CUDA/C++ program for an entire granule instead of doing it stencil by stencil. More advanced "orchestration" features require a GT4Py DaCe-backend.
- [Hannes] Orchestration for me means getting more than a single GT4Py program into an SDFG, by DaCe parsing of driver code around the GT4Py programs.
- [Christos] Work with Fabian to figure out how DaCe could do the halo exchange tuning, i.e. size of halos, patterns, etc.
- JAX2DaCe from prototype to stable (Philip, Edoardo)
- [Edoardo] As we discussed during the QPM, the focus for next 1-2 cycles should be on a JAX2DaCe backend for JAX programs. Likely, we will get some experience useful for the design of combined-IR. Also, another possible mid-term future outcome is the integration of JAX2DaCe in GT4Py programs using JAX-embedded backend.