Several of your dimensions belong in different buckets, and that re-bucketing changes how work composes around them.
Code quality (I think): complexity, purity, changeability, single source of truth, size, readability. That’s a coherent bucket.
Architecture is its own bucket: architectural ratio and separation, architectural suitability. Code can be beautifully crafted inside a bad architecture, or vice versa. Not the same axis.
Testing is its own bucket: tests are a different layer from the code under test. Not a code-quality property.
Documentation is its own bucket: LLMs do specific weird things here (doc gaps + comment overproduction) that need their own tools.
Hot spots and performance traps belong in performance, which folds into correctness when SLOs cross thresholds. Dead code is code quality.
Where this matters: if the community converges on per-bucket work, each bucket becomes tractable. Right now most of the substantial tooling here (Archdo, Ragex, gtcode’s substrate, the elixir-vibe org) is trying to cover multiple buckets at once. If we instead converged on, say, a standard architectural-linting Credo pack for Phoenix bounded contexts, the problem space would collapse.
Selfishly: I’m partly making this case because I’m a customer of this work, not a builder of it. My lane is contract-form and code generation, not quality measurement. I’d love a standardized architectural Credo pack for Phoenix that I can plug into my harness without rebuilding it. Same for code-quality lint, security lint, doc lint. The buckets give us the convergence targets.
Architectural separation is the most interesting of your list. If we take your approach (separating architecture from implementation), it opens up a more easily measurable axis.
