perkovsky

I like the “claim-driven” framing.

For stateful systems, tests named after setup details often get weakened over time. Tests named after the claim they are trying to falsify are harder to water down.

The part I’d be most interested in is how well this works for business invariants like idempotent posting, no lost acknowledgements and recovery after partial failure.

Agree. Postinstall scripts should be explicit opt-in, not ambient capability.

Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review.

The default should probably be: install files, don’t run code.

I agree with this. Moving the git repo is easy, moving the whole project surface is the hard part.

Issues, releases, CI, docs, security advisories, search and discoverability all tend to get coupled to GitHub over time.

For open-source projects, I like the idea of self-hosted as the source of truth, but still keeping a read-only GitHub mirror so people can actually find it.

Yes. I’d add: design the module boundaries before splitting deployment.

A modular monolith still forces you to name ownership, data boundaries and invariants, but without making every mistake a networking/ops problem.