Cnuas Product Roadmap & Project Plan¶

Scope: Cnuas Virtual AI HPC Infrastructure and all components · Version: `5c3d075-dirty` · Updated: 2026-08-22

This page is the single source of truth for what is available today versus what is planned. It is organised as Epics (major workstreams) broken into Tasks, mirroring the GitHub Projects board used for day-to-day tracking.

Status legend¶

Symbol	Meaning
✅ Available	Implemented, tested, and shipped in the current tree
🚧 In Progress	Actively being worked on
📋 Planned	Scheduled; not yet started
⛔ Blocked	Waiting on a dependency

An entry may be marked available only when the Validation Matrix names a test for it and records that the test passes.

Roadmap at a glance¶

timeline title Cnuas Delivery Horizons section Now - Available CnuasNIC RoCEv2 + Native IB : RC/UD/SMI/GSI, atomics, SRQ, multicast, ICRC CnuasSwitch fabric : 10-port RoCE/IB, DCB, in-switch Subnet Manager CnuasGPU runtime : SIMT, libcnuasrt, AVX2/AVX-512 SGEMM CnuasGPU Soft-GPU : host device backend, vectorised activations, ggml backend Cnuas peer memory : GPU DMA-BUF export, RNIC registration, userspace library CnuasLink fabric : frame protocol, FDB, discovery Platform : VM lifecycle CLI, packaging, submodule split, datasheets section Next - In Progress CnuasNIC IB SM : SA path-record, PMA/perfquery, opensm compat Docs : ASCII to mermaid, roadmap, RoCE/IB HowTo rewrite section Later - Planned CnuasGPU devices : device-backend refactor, tile primitive, host char device FPGA IP : tile blocks in RTL, PolarFire SoC Icicle Kit Interconnect : UALink alongside PCIe Collectives : UCCL P2P + AllReduce/AllGather Runtimes : quantised paths, vLLM integration Upstreaming : PCI IDs, QEMU and OpenBMC submissions

Epics and tasks¶

Epic 1, CnuasNIC, RDMA NIC (RoCEv2 + native InfiniBand)¶

Repo: PacketFive/CnuasNIC (v0.1.0-27-gc7e8629)

Status	Task	Milestone
✅ Available	RoCEv2 TX path	H1
✅ Available	RoCEv2 RX path	H2
✅ Available	RC reliability + RDMA READ	,
✅ Available	RC atomics (CMP_SWP, FETCH_ADD)	,
✅ Available	Multi-packet WRITE/READ honouring path MTU	,
✅ Available	Real ICRC compute + validate on RX	,
✅ Available	Shared Receive Queue (SRQ)	,
✅ Available	UD QPs + IB multicast (attach_mcast)	,
✅ Available	Per-port IB link layer + dual port_immutable	I1
✅ Available	LRH + IB opcodes; parallel IB skb builder	I2, I3
✅ Available	Wire IB skb through QEMU vNIC + switch pipeline	I4
✅ Available	QP0 MAD plumbing; SMA GET/SET; directed-route SMPs	I5a, I5c
✅ Available	SM wire-format + kernel SMI groundwork	I5f
✅ Available	LRH-aware RX dispatcher	I6
✅ Available	End-to-end test gate (pingpong + perftest + ibstat)	I7
✅ Available	NCCL / UCX build+link gates	,
🚧 In Progress	DMA-BUF memory-region import and I/O-safe CnuasGPU BAR access; implementation builds, guest transfer validation remains gated	PM2
📋 Planned	Userspace verbs fast path, an mmap'd ring for `post_send` and `poll_cq`	H5
📋 Planned	Native IB LRH-only TX path for RC QPs with IB-typed AHs	H1.5
📋 Planned	SA path-record responder on QP1	I5f-SA
📋 Planned	PMA + perfquery support	I5g
📋 Planned	opensm-in-VM compatibility lab	I5h
📋 Planned	RoCE/IB HowTo rewrite (RoCEv2 + Native IB)	I8
📋 Planned	Debug ib_umad `/dev/infiniband/umadN` creation	,
⛔ Blocked	UCCL-P2P RDMA transfer engine smoke	,
⛔ Blocked	UCCL collective (AllReduce) host-mem smoke	,

Epic 2, CnuasGPU, Virtual GPU + Runtime¶

Repo: PacketFive/CnuasGPU (v0.2.0-29-gf3e5f47-dirty)

Status	Task	Milestone
✅ Available	GPU driver scaffold + `/dev/cnuasgpuN` char device	Phase 2
✅ Available	ioctl set (INFO/ALLOC/FREE/MEMCPY/LINK_*)	,
✅ Available	`libcnuasdev` low-level driver shim	,
✅ Available	`libcnuasrt` CUDA-style runtime	,
✅ Available	Vector add compute primitive	5b
✅ Available	Tile-based SGEMM (AVX2/FMA)	,
✅ Available	AVX-512 SGEMM	6.3
✅ Available	Multi-GPU verification	,
✅ Available	`cnuassmi` / `cnuas-smi` CLI	,
✅ Available	Compute-backend refactor (scalar/AVX2/AVX-512 + dispatch loader, per-backend `.so` artefacts)	6.1
✅ Available	Split backends into `.so` + dlopen loader	6.1c
✅ Available	Host device backend (`cnuasdev_host.c`), standalone Soft-GPU operation with no guest	,
✅ Available	Vectorised activations (relu, gelu, silu, sigmoid, tanh, softmax) for AVX2 and AVX-512	,
✅ Available	ggml backend `libggml-cnuas.so` for llama.cpp and Ollama	,
✅ Available	Page-aligned allocation and subrange export as a lifetime-safe DMA-BUF	PM1
✅ Available	`libcnuaspeermem` export and standard `ibv_reg_dmabuf_mr` registration API	PM3
📋 Planned	Device-backend refactor	6.2
✅ Available	CnuasIR object format, frozen header and reference parser	6.4a
✅ Available	CnuasIR packer, disassembler and validator tools	6.4b
✅ Available	CnuasIR interpreter backend and the kernel launch API	6.4c
✅ Available	TVP (Tile Vector Processor) lanes, the elementwise and reduction surface	,
✅ Available	CCP (Cluster Control Processor), the command processor behind the BAR2 doorbell pages	,
✅ Available	LSU (Load Store Unit), operand movement inside the compute primitives	,
📋 Planned	Tile/accumulate compute primitive, exposing the TTU rather than leaving it implicit inside `sgemm`	,
📋 Planned	TCP (Tile Control Processor) as an addressable block, with per-tile address generation and loop control rather than ISA facilities only	,
📋 Planned	SFU (Special Function Unit) as an addressable block, rather than transcendentals running on the TVP lanes	,
📋 Planned	TF32 matrix multiply, FP32 caller buffers narrowed inside the TTU with FP32 accumulation	,
📋 Planned	BF16 matrix multiply entry point and conversion, with FP32 accumulation	,
📋 Planned	2:4 structured sparsity, the index metadata layout and a sparse weight entry point	,
📋 Planned	Quantised dequantise-to-SGEMM compute paths	,
✅ Available	Host character device (`cnuasgpu_host.ko`, `/dev/cnuasgpu_hostN`) with no QEMU or PCI function	HDEV1
✅ Available	Configurable zero-copy mappings, pinned allocations and DMA-BUF sharing	HDEV2
✅ Available	Ordered batched asynchronous queue, pollable completions and barriers	HDEV3
✅ Available	Loaded-module feature/configuration matrix under QEMU, KASAN and lock debugging	HDEV4
📋 Planned	vLLM integration, after quantised paths and attention kernels exist	,
📋 Planned	UALink accelerator to accelerator interconnect, alongside PCIe	,
📋 Planned	Documentation pass	6.6

Epic 2b, Cnuas Peer Memory¶

cnuas-peermem joins the CnuasGPU and CnuasNIC kernel interfaces with the upstream Linux DMA-BUF RDMA ABI. It is distinct from framed GPU-to-GPU copies over CnuasLink and from the obsolete out-of-tree peer-memory client API.

Status	Task	Milestone
✅ Available	CnuasGPU allocation and subrange DMA-BUF export with export-safe allocation and device lifetime	PM1
🚧 In Progress	CnuasNIC DMA-BUF MR registration across SEND, RECV, RDMA READ/WRITE and atomics; module build passes, guest transfer test remains gated	PM2
✅ Available	`libcnuaspeermem` shared/static library, smoke utility, ABI and ownership tests	PM3
🚧 In Progress	Two-device guest transfer validation and lifetime/failure matrix	PM4

Epic 2a, CnuasGPU FPGA IP, PolarFire SoC Icicle Kit¶

The tile blocks as synthesisable RTL on real fabric, with a RISC-V host. The emulated device is the reference model the RTL is checked against. Phases follow the CnuasGPU FPGA design note.

FPGA IP is active research work. The roadmap distinguishes RTL simulation, generated bitstreams and board validation so that completing one phase is not reported as completing the others.

Status	Task	Milestone
📋 Planned	Board preparation, Linux on the U54 cores, no fabric work	6.5.0
📋 Planned	Minimum PCIe bitstream, the endpoint enumerates and BAR0 reads back	6.5.1
📋 Planned	Firmware daemon on the U54 cores, serving as the CCP and the TCP	6.5.2
📋 Planned	Vector add on fabric, the first TVP lane in RTL	6.5.3
📋 Planned	SAXPY, scale, dot and SGEMM on fabric, TVP lanes on the MACC blocks	6.5.4
📋 Planned	CnuasIR execution on the U54 cores	6.5.5
📋 Planned	CnuasIR in fabric	6.5.6
📋 Planned	TTU in fabric, on the MACC array, once the tile primitive has a caller-visible interface	,
📋 Planned	FPGA IP implementation and legal release review	6.5
📋 Planned	Bitstream distribution as tagged releases rather than in the git tree	,

Epic 3, CnuasSwitch, Virtual TOR Switch¶

Repo: PacketFive/CnuasSwitch (v0.1.0-8-gd630c1f)

Status	Task	Milestone
✅ Available	10-port switch daemon (`cnuas-vswitchd`)	,
✅ Available	RoCEv2 + native IB forwarding	,
✅ Available	DCB: PFC / ETS / ECN	,
✅ Available	Ethernet FDB + IB LFT	,
✅ Available	Switch-side SMA	I5d
✅ Available	In-switch Subnet Manager	I5e
✅ Available	SM SMP wire-format fix for kernel CA acceptance	I5f
✅ Available	OpenTelemetry telemetry export	,
✅ Available	JSON management API (18+ commands)	,
📋 Planned	Switch-side SA/PMA alignment	I5g

Epic 4, CnuasLink, GPU Fabric Interconnect¶

Repo: PacketFive/CnuasLink (v0.1.0-3-g812f464)

Status	Task	Milestone
✅ Available	GPU fabric switch daemon (`cnuasgpu-link-switchd`)	P1
✅ Available	8-port frame-based protocol	,
✅ Available	FDB learning + discovery + keepalive	,
✅ Available	CnuasGPU ↔ switch wiring	P2
✅ Available	Link state in sysfs + `cnuassmi`	P2.1
✅ Available	`cnuaslink-cli` management CLI	P4
📋 Planned	Collective offload (AllReduce / AllGather) end-to-end	,
📋 Planned	Bandwidth / latency modelling	,

Epic 5, Platform, Tooling & VM Lifecycle¶

Superproject: PacketFive/cnuas (5c3d075-dirty)

Status	Task	Milestone
✅ Available	VM lifecycle CLI (`vm up/down/ssh/console/lab`)	6.2e
✅ Available	Package + image build subcommands	6.2c, 6.2d
✅ Available	Kernel port to v6.19 + binary `.ko`/`.deb` packaging	6.2f
✅ Available	Deployment tooling	,
📋 Planned	Self-hosted apt repository with signing key, and `deploy install --from-dir`	,
✅ Available	Repo split into per-component submodules	,
✅ Available	QEMU fork tagged for consumers	,
✅ Available	CI strategy (Azure DevOps)	6.0e
✅ Available	Build system (Bazel + Make)	,
📋 Planned	PCI vendor/device ID allocation request to the QEMU project	,
📋 Planned	Upstreaming tracks 1 to 5 (QEMU aspeed-gpio and CMIS, OpenBMC RFC, QEMU Cnuas devices, Linux drivers)	,

Epic 6, Documentation¶

Status	Task	Milestone
✅ Available	Design docs (topology, switch, CnuasLink, CnuasGPU, driver, control plane)	6.0
✅ Available	Component + platform datasheets	,
✅ Available	Live version wiring from git tags	,
✅ Available	Version pinning reference	,
✅ Available	Convert ASCII diagrams to mermaid across docs	,
🚧 In Progress	This roadmap	,
📋 Planned	Vector redraw of the finished logo mark for poster scale	,

Epic 7, CnuasBMC, OCP Rack Management (BMC + OOB)¶

Superproject: PacketFive/cnuas (5c3d075-dirty), layer for OpenBMC contribution

Status	Task	Milestone
✅ Available	PCIe Link Capabilities on CnuasNIC + CnuasGPU (Gen5 x16, configurable)	,
✅ Available	Management plane design (fidelity tiers, topology, protocol surface)	,
🚧 In Progress	`meta-cnuas` OpenBMC layer (cnuas-sled/tor/rmc machines)	,
🚧 In Progress	Renode satellite skeletons (BMS, PSU, fan, optics, sequencer, front panel)	,
✅ Available	UART front-panel satellite firmware + protocol	,
✅ Available	Isolated management bridge + real OpenBMC on QEMU ast2600	,
✅ Available	Redfish power wired to VM lifecycle + Serial over LAN	,
🚧 In Progress	`cnuas bmc/power/rack` command groups + Redfish aggregation	,
✅ Available	Cnuas machine device trees + branded firmware image	,
✅ Available	BMS + PSU over RS-485 with real firmware in Renode	,
📋 Planned	Thermal Simulation model for fans and airflow (research)	,
📋 Planned	DC-SCM root of trust + SPDM attestation bench (optional)	,

Epic 8, Accelerator Software Stack¶

Repo: PacketFive/CnuasGPU (v0.2.0-29-gf3e5f47-dirty)

The compiler, instruction set, collectives, one sided messaging and numerical libraries. Every component here has a preview datasheet recording the specified design.

Two of these do not wait for the compiler. CnuasBLAS v0.1 wraps the SGEMM and vector kernels that libcnuasrt ships and is complete; a first CnuasCCL moves buffers over CnuasLink and reduces them with those same kernels, and needs no compiler either. CnuasCCL does require a userspace CnuasLink transport and a chosen bootstrap protocol, which is why it is split into 8.2a to 8.2c. The transport ships as part of CnuasDev in 8.2a and the bootstrap protocol is fixed in 8.2b, so CnuasCCL v0.1 is implemented. It carries collective payloads over the caller's bootstrap channel rather than the fabric, because the receive path has no demultiplexing, ordering or delivery guarantee; section 3 of the design document sets out what an in band version has to add first.

Everything that runs a user written kernel still waits on the CnuasIR chain in Epic 2 milestone 6.4.

Status	Task	Milestone
✅ Available	CnuasBLAS v0.1 over the shipped SGEMM and vector kernels	8.1
✅ Available	Userspace CnuasLink transport wrapper in CnuasDev	8.2a
✅ Available	CnuasCCL rank bootstrap protocol, decisions recorded	8.2b
✅ Available	CnuasCCL v0.1, broadcast, AllReduce and AllGather	8.2c
✅ Available	CnuasIR scalar subset completion, the target a compiler needs	8.3a
✅ Available	`cnuascc` front end, device C subset parser and type checker	8.3b
✅ Available	`cnuascc` code generator emitting CnuasIR objects, scalar subset	8.3c
✅ Available	Activation set in the compute backend ABI 0.2, the TVP layer	8.3d
✅ Available	Host device backend, so the runtime, numerical library and activations run with no kernel module, no character device and no guest	8.3e
✅ Available	All six activations vectorised for AVX2 and AVX-512, verified over all 2^32 binary32 inputs per function against a double precision oracle on hardware of both kinds	8.3f
✅ Available	ggml backend, so an unpatched llama.cpp or Ollama can run a model on CnuasGPU. 648 of 648 differential matrix multiply cases, and byte identical greedy decoding against the CPU backend	8.3g
✅ Available	Transposed matrix multiply through the whole stack, compute ABI 0.3 `sgemm_nt`, `cnuasSgemmNT`, and `CNUASBLAS_OP_T`, so the ggml backend needs no scratch transpose	8.3h
⛔ Blocked	CnuasSHMEM one sided put, get and atomics	8.4
⛔ Blocked	CnuasBLAS v0.2, kernels generated through `cnuascc`	8.5
⛔ Blocked	CnuasDNN, CnuasFFT, CnuasSPARSE, CnuasSOLVER	8.6
⛔ Blocked	`cnuas-prof` profiler and `cnuas-dcgmi` telemetry	8.7
📋 Planned	CnuasML, an NVML-style C management library for the whole Cnuas system	8.8
📋 Planned	Cnuasdebug, a low-level device inspection tool in the shape of `nvdebug`	8.8
📋 Planned	`cnuas_gpu_tools.py`, a Python device inspection script in the shape of `nvidia_gpu_tools.py`	8.8

Order of work, and why:

6.4c, the interpreter and the launch API. execute_cnuasir occupies a slot in the compute backend vtable and CNUAS_CCAP_CNUASIR_EXEC is allocated, so this fills a hole rather than reshaping the ABI. The runtime provides cnuasModuleLoad, cnuasModuleUnload and cnuasLaunchKernel, without which a program cannot reach a backend. 8.3 depends on it.
8.3, the compiler. A compiler needs a target to emit for and a reference to be checked against, both of which require a hand written kernel that the interpreter accepts. 8.3a precedes it because the instruction subset must be able to express ordinary code: a subtraction between floats needs fsub.s, and a bitmask or a predicate needs logical and compare instructions. 8.3b bounds the language to what that subset expresses, so that a rejection lands on a token with a note saying what to write instead, rather than on accepting C and refusing half of it during code generation.
8.4 onward. One sided messaging and the numerical libraries are ordinary consumers of the launch API.

8.1 and 8.2 run in parallel with all of the above, since they depend only on what is already shipped.

Epic 9, Facility Digital Twin¶

Superproject: PacketFive/cnuas (5c3d075-dirty), facility/

Status	Task	Milestone
✅ Available	Campus, buildings and room programme generator	,
✅ Available	Detailed data hall with the emulated racks	,
✅ Available	Plant yards sized from the load	,
✅ Available	Power roll-up to a grid connection	,
✅ Available	OpenUSD emission, Z-up metres, `cnuas:` attributes	,
✅ Available	Custom JSON campus specification, spatial validation and beginner-to-Isaac workflow	F1
✅ Available	Live rack power from the ORV3 shelf	,
✅ Available	Runtime load input to the PSU model	,
✅ Available	Workload profiles driving the shelf	,
📋 Planned	Cooling plant that responds to measured heat	,
📋 Planned	Workloads on emulated blades driving the draw	,
📋 Planned	Grid frequency and generator start sequencing	,

Epic 10, Cnuas Calibrated Virtual-time and Performance Model¶

Superproject: PacketFive/cnuas (5c3d075-dirty), timing/

Status	Task	Milestone
✅ Available	Deterministic integer-picosecond virtual clock and event scheduler	VT1
✅ Available	Versioned cross-component profiles for NIC, switch, GPU, link, BMC, PCIe and facility	VT2
✅ Available	Target-specific calibration fitting and held-out error reporting	VT3
✅ Available	QEMU `icount` deterministic TCG experiment mode	VT4
📋 Planned	Physical hardware calibration datasets and validated target profiles	VT5
📋 Planned	Runtime telemetry adapters and automatic trace ingestion	VT6
✅ Available	Dedicated calibrated virtual-time research paper	VT7

The supplied profile is deliberately analytic and uncalibrated. Its output is a deterministic virtual-time estimate, not a prediction of physical hardware. A target profile can be called calibrated only after fitting named hardware measurements and reporting error on held-out workloads. See the timing model design.

Epic 11, Deferred design decisions¶

Decisions that are recorded but not yet settled. Each names the component it belongs to and the current working default, so a reader knows what the tree does today and what is still open.

Status	Decision	Component
📋 Planned	Math mode selection, a global fast-math versus strict-IEEE flag, a per-call flag, or always-fast. Working default is a `cnuasSetMathMode` global.	CnuasGPU compute backends
📋 Planned	Whether a host matrix engine (Intel AMX, ARMv9 SME) is surfaced as a new compute backend (`x86_amx`, `arm_sme`) or a capability bit on an existing one.	CnuasGPU compute backends
📋 Planned	Mixed-precision GEMM, `cnuasSgemmEx` with explicit input and output dtypes.	CnuasGPU compute backends
📋 Planned	NUMA-aware backend selection, pinning OpenMP threads via `numa_available()`.	CnuasGPU compute backends
📋 Planned	CnuasIR JIT emitting AVX2, AVX-512, SVE and RVV machine code from bytecode, removing per-arch hand-coded kernels.	CnuasGPU compute backends
📋 Planned	Asynchronous compute queues, `cnuasStream_t` and `cnuasSgemmAsync`. The present API is synchronous.	CnuasGPU compute backends
📋 Planned	Whether the `host` arena becomes growable. The present behaviour is fail-fast, sized by `CNUAS_HOST_ARENA_MB`.	CnuasGPU device backends
📋 Planned	Shared device memory IPC across processes. Allocation namespaces are per-process today.	CnuasGPU device backends
📋 Planned	Whether `pcie_fpga` remains a distinct backend or collapses into `chardev` plus a `CNUAS_DCAP_FPGA_FABRIC` capability bit.	CnuasGPU device backends
📋 Planned	Heterogeneous multi-device, opening device 0 as `chardev` and device 1 as `host`.	CnuasGPU device backends
📋 Planned	Whether fabric compute is required for the first FPGA target, or a U54 Linux CnuasIR build suffices. Working position is that fabric VADD is the minimum.	CnuasGPU FPGA
📋 Planned	Bitstream distribution, as tagged repository releases rather than in the git tree.	CnuasGPU FPGA
📋 Planned	Whether to add the PolarFire SoC Discovery Kit (MPFS095T) as a second, smaller target, which caps lanes at 4-wide.	CnuasGPU FPGA
📋 Planned	Whether to offer Zephyr or bare metal on the U54 instead of the Buildroot Linux reference image.	CnuasGPU FPGA
📋 Planned	Container CI jobs versus raw VM agents. Containers lose `/dev/kvm` unless privileged, so raw VM agents are used.	CI
📋 Planned	Outbound allow-list for agents if the lab is firewalled.	CI
📋 Planned	Parallel job capacity beyond the free tier.	CI
📋 Planned	Cross-architecture CI for ARM64 and RISC-V64, which needs agents on those architectures.	CI
📋 Planned	DKMS support for kernels other than the Cnuas-pinned kernel.	VM lifecycle
📋 Planned	Multi-machine image distribution. Images are cached locally at `~/.local/share/cnuas/images/`.	VM lifecycle
📋 Planned	Image signing, a detached signature alongside the `.sha256`.	VM lifecycle
📋 Planned	A `--prefix` flag to namespace libvirt domain names so two labs can share a host.	VM lifecycle
📋 Planned	`libvirt-python` bindings in place of the present subprocess calls.	VM lifecycle

Project management¶

Day-to-day tracking lives on the public board at https://github.com/orgs/PacketFive/projects/7, rendered as a scrollable and zoomable graphic on the Project Plan page, because the component repos already live under the PacketFive GitHub organisation, so Epics and Tasks link directly to issues, pull requests, and commits.

Epics map to the workstreams above (label epic).
Tasks map to individual table rows (label task), linked to their Epic and to the owning component repo.
Status on the board is Todo, In Progress or Done. The legend above maps onto it: Available is Done, Planned and Blocked are Todo.

The board is seeded and kept in sync from a machine-readable source of truth:

scripts/roadmap/roadmap.csv, every Epic and Task with status, milestone, and repo.
scripts/roadmap/seed_github_project.sh, creates the Project, labels, and issues via the gh CLI.

Seeding the board¶

# One-time auth with project scope
gh auth login
gh auth refresh -s project,read:project

# Preview what would be created
scripts/roadmap/seed_github_project.sh --owner PacketFive --dry-run

# Create the board + issues
scripts/roadmap/seed_github_project.sh --owner PacketFive --title "Cnuas Roadmap"

Keeping this roadmap current¶

Update scripts/roadmap/roadmap.csv when a task changes status. The epic tables on this page and the rows in the CSV are one to one: a task added to a table needs a matching CSV row, or it never reaches the board. Task titles carry no commas and no quotation marks, because the seeder parses the file with IFS=, and has no quoting support; a title written through a CSV library will be quoted the moment it contains a comma and will break that parse.
Re-run scripts/roadmap/seed_github_project.sh --owner PacketFive --sync to reflect changes on the board. --sync reconciles as well as creates: it moves the status:* label and the board Status field of an issue that already exists onto whatever the CSV now records, so a status change in the CSV reaches the board without hand editing. Issues are matched by exact title against one listing per repository, so a re-run is safe immediately after a previous one.
The seeder writes only where the board and the CSV disagree, and it stops with an error if a repository listing fails rather than treating the failure as an empty repository. A board this size can otherwise exhaust the hourly GraphQL quota, and a throttled listing reads as "no issues exist", which would duplicate every task. If the quota is exhausted, wait for the reset reported by gh api rate_limit and re-run.
Re-run python scripts/roadmap/export_project_plan.py --owner PacketFive to redraw the graphic on the Project Plan page and the PDF beside it. The timestamp it writes is the moment the data was exported, so the step belongs with a status change rather than with a site build.
Component versions on this page and in the datasheets update automatically from git tags at documentation build time (no manual edit needed).