Coordinating a Windows development team

What Windows changes, and what it doesn't

The database side is unaffected. Postgres runs natively on Windows. There is no translation layer, no container required, no reason a Windows-based team's task board should live anywhere but the same server everyone already points their tools at. If your build machines, your CI runners, or a shared server are already Windows boxes with Postgres installed, that part of the setup is exactly as described in the README.

The part that changes is the CLI. lac, ctask, csend and the rest are bash scripts. They need `bash 4+` and `psql` on the machine that runs them, which is not the default shape of a Windows developer's box. cmd.exe and PowerShell cannot run them as-is.

The two paths that work

WSL2 is the more literal match to the environment Lacunari is built and tested in: a real bash, a real psql, the same file locking and process semantics as macOS and Linux. Point LAC_DSN at a Postgres running on the Windows host itself, or at a shared server, and the two sides talk over the network like any other client.

Git Bash gets closer to a native feel. No second filesystem, no VM boundary between your editor and your terminal. But it is a smaller, MSYS-based bash rather than a full Linux userspace, and it has not been run through the test suite the way WSL2 and native Linux/macOS have.

Say this plainly: it is proven-by-use, not proven-by-suite

Lacunari's own status notes are specific about this, and the honest version belongs here rather than in fine print: the project has been run on Windows on a live project, but Windows is not one of the platforms in continuous integration. CI runs on Postgres 14, 16 and 17, and on macOS, Ubuntu and Linux Mint. Windows is exercised by real use, which is a real signal, but a different one from a green check on every commit.

If your team is evaluating this for a Windows-only shop, the honest plan is: run it under WSL2 first, keep the database on whatever server you'd use anyway, and treat the Git Bash path as something to try rather than something to depend on for a first rollout.

Where the value holds regardless of shell

Once lac is running somewhere, whether that's WSL2, a Linux build agent, or a Mac a lead engineer keeps around, the coordination problem it solves does not care what OS wrote the code it is indexing. A native Windows codebase has the same undocumented modules, the same symbols nothing calls, and the same two engineers who might silently pick up the same file, as a codebase written anywhere else.

The indexer reads source files by extension and content, not by which shell built them, so a mixed solution (a C++ core, a C# service layer, build scripts, whatever a Windows-based codebase actually contains) maps the same way any other multi-language repository does. A locked file is a locked file whether the worker that claimed it is a Claude Code session on a laptop or a build agent running unattended overnight.

A realistic first setup

• Database on a server, not a laptop. Point every developer's WSL2 instance and every build agent at one shared Postgres, so the board reflects the whole team rather than one machine's view of it.
• Start with two or three engineers, not the whole team. Confirm claiming and file locking behave the way you expect on your actual machines before putting a dozen people's work through it.
• Keep an eye on the WSL2/Windows filesystem boundary. Indexing a repository that lives on the Windows side (/mnt/c/…) from inside WSL works, but is slower than a repo cloned into the WSL filesystem itself. Worth knowing before you assume a slow first index means something is wrong.