Interesting,thanks for clarifying.

I’d say most of the properties you mention are highly undesirable, especially monorepo and single executable. But regardless, I think monolith has to be defined at the behavioral level: does one system perform multiple completely independent behaviors? Must you change the same singleton codebase/artifact to effect two totally separate concerns? And indeed this is basically why all types of “mono” workflows (monorepo/monoapp, whatever) are intrinsically bad designs. That you can solve problems in spite of this through intense extra scaffolding bolted into the mono stuff is not any type of endorsement that it’s a good way.