I was thinking about architectural-separation point. I’ve been doing this in my harness from two directions.
The architecture-design step writes an architectural proposal first. It’s a structured document mapping user stories to contexts, context modules, and surfaces (typically liveviews, controllers, mcp tools). The proposal gets validated against a document spec, then projected into stub spec files that scaffold each contexts expected structure. Implementation only happens against those stubs.
So the architecture (what should exist, where, with which dependencies) is captured and validated as a standalone artifact before any implementation runs. The proposal is the architectural intent. The stub specs are the architectural constraints. Implementation fills them in.
In the existing codebase, each bounded context module is aspirationally only defdelegate calls to its components. When there are fatter functions, they’re coordinating (PubSub broadcasts, boundary checks), not implementing business logic:
defmodule CodeMySpec.Components do
defdelegate list_components(scope), to: ComponentRepository
defdelegate get_component!(scope, id), to: ComponentRepository
defdelegate list_contexts(scope), to: ComponentRepository
defdelegate upsert_component(scope, attrs), to: ComponentRepository
defdelegate list_dependencies(scope), to: DependencyRepository
defdelegate validate_dependency_graph(scope), to: DependencyRepository
# ...
def create_component(%Scope{} = scope, attrs) do
with {:ok, component} <- ComponentRepository.create_component(scope, attrs) do
broadcast(scope, {:created, component})
{:ok, component}
end
end
end
Combined with the boundary library, the bounded contexts also enforce what’s allowed to call what.
The result is that architecture (what calls what, where things live, what’s coordinated) ends up largely separable from implementation (how each thing is done). The bounded context surfaces are short enough that an LLM can read them as the architectural intent and stay within them.
So I think you’re onto something real with the separation as a measurement unlock. The bucketing argument gets cleaner if architecture really can be evaluated independently of code quality. Once you have it as a separable artifact, it becomes “more measurable”.
