Split the tool-execution contract into Fallout.Application.Tooling.Execution + .Requirements#10
Open
ChrisonSimtian wants to merge 2 commits into
Open
Conversation
ChrisonSimtian
force-pushed
the
tooling/extract-abstractions
branch
from
b226ce1 to
3bda72a
Compare
ChrisonSimtian
force-pushed
the
tooling/extract-abstractions
branch
from
3bda72a to
7b7e233
Compare
ChrisonSimtian
changed the title
ChrisonSimtian
force-pushed
the
tooling/extract-abstractions
branch
from
7b7e233 to
2596d68
Compare
ChrisonSimtian
changed the title
This was referenced Jun 29, 2026
ChrisonSimtian
force-pushed
the
core/extract-domain-enums
branch
from
b2d7cc4 to
8ed4dd3
Compare
ChrisonSimtian
force-pushed
the
tooling/extract-abstractions
branch
from
2596d68 to
76b3c99
Compare
Pulls the pure tool-execution contract out of Fallout.Tooling into two cohesive, single-purpose Application-layer foundation leaves (onion: tools are an Application concern), each ns2.0;net10 and referencing nothing else in the repo: - Fallout.Application.Tooling.Execution — the process-execution contract: IProcess, Output, OutputType. - Fallout.Application.Tooling.Requirements — the tool-requirement markers: IRequireTool, IRequireToolWithVersion, IRequirePathTool, IRequireNuGetPackage, IRequireNpmPackage, IRequireAptGetPackage (extracted from ToolRequirement.cs; the *Requirement classes stay in Fallout.Tooling). First bottom-up step of the onion migration on main. All types keep their Fallout.Common.Tooling namespace, so no consumer code changes — Fallout.Tooling references both leaves and re-flows them transitively. They must be netstandard2.0 because the Roslyn source generator and net472 MSBuild tasks consume them; Fallout.Core stays netstandard2.1. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
References both leaves from the architecture test project, registers them as governed runtime libraries, and asserts (via a Theory) that each is a foundation depending on nothing else in the repo. Their contract types keep the Fallout.Common.Tooling namespace, so they stay in the pre-existing namespace-drift baseline by full name — the ratchet stays green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ChrisonSimtian
force-pushed
the
core/extract-domain-enums
branch
from
8ed4dd3 to
1d25508
Compare
ChrisonSimtian
force-pushed
the
tooling/extract-abstractions
branch
from
76b3c99 to
8ae03da
Compare
ChrisonSimtian
added a commit
that referenced
this pull request
Jun 30, 2026
…roject list Pre-existing staleness, not from the namespace alignment: the snapshot predated the architecture suite (#9), the Application.Tooling leaves (#10), and the Application.Tools families (#11), so it was missing those projects and failing on the whole stack. The generator emits accessors from project/assembly names (unchanged by the namespace work), so this is a pure catch-up. Also drops the stray committed .received.cs (Verify artifact that should not be tracked). Fallout.SourceGenerators.Specs now 6/6. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second onion-architecture sweep. Pulls the pure tool-execution contract out of
Fallout.Toolinginto two cohesive Application-layer foundation leaves, and extends the architecture suite to govern them.The two leaves (both
netstandard2.0;net10.0, reference nothing else in-repo)Fallout.Application.Tooling.Execution— the process-execution contract:IProcessOutputOutputTypeStd/Err)Fallout.Application.Tooling.Requirements— the tool-requirement markers:IRequireTool,IRequireToolWithVersion,IRequirePathTool,IRequireNuGetPackage,IRequireNpmPackage,IRequireAptGetPackageThe
ToolRequirement/*Requirementclasses stay inFallout.Tooling(two do I/O for version resolution).Why this shape
Fallout.Application.*), not Domain. The raw process runner (Process2) + resolvers are the Infrastructure detail, to be re-homed later.IProcess/Output(how a tool runs) andIRequire*(what a tool needs) are independent concerns; splitting sets up the longer-term per-family tool direction. Easy to merge back if excessive.Fallout.Core— consumed by the netstandard2.0 Roslyn generator + net472 MSBuild tasks, so they must be ns2.0; Core stays ns2.1.Fallout.Common.Toolingnamespace;Fallout.Toolingreferences both leaves and re-flows them transitively.Architecture governance
Both leaves are referenced by the arch-test project, registered as governed runtime libraries, and asserted (via a
[Theory]) to be foundations that depend on nothing else in-repo. Their contract types stay in the pre-existing namespace-drift baseline by full name — ratchet stays green.Verification
fallout.slnxbuild: 0 errors.Follow-up (separate PR, stacked on this)
Split the 65 tool wrappers out of
Fallout.CommonintoFallout.Application.Tools.<Family>(~14 family projects), after breaking theCommon ↔ Toolscycle.🤖 Generated with Claude Code