refactor(arch)!: Kernel ring + structural realignment close-out (onion 5a–5c + project renames/splits + Fallout meta)#351
Closed
ChrisonSimtian wants to merge 23 commits into
Closed
Conversation
ChrisonSimtian
added
breaking-change
ChrisonSimtian
changed the title
…on step 5a) Establishes Fallout.Kernel, the innermost shared ring (ADR-0006). The shared utility/IO layer moves from Fallout.Common.Utilities* / Fallout.Common.IO to Fallout.Kernel / .Collections / .IO / .Net: pure helpers (collections, string/ text, reflection, crypto, JSON/YAML, guards), the AbsolutePath/RelativePath value types AND their fluent filesystem operations, plus HTTP/compression helpers. Filesystem is treated as a kernel-level capability (like the BCL File/Directory): the fluent AbsolutePath API (.ReadAllText/.GlobFiles/.CreateDirectory/…) is used pervasively across the Application ring, so routing it through ports would be impractical and anti-ergonomic — it lives in Kernel, not Infrastructure. Pushing the genuinely-external adapters (HTTP/FTP, compression) further out to Infrastructure is deferred for the same reason (same ports decision as the filesystem API). The Application⊥Infrastructure fitness gate still passes. Native consumers rewrite `using Fallout.Common.Utilities;` → `using Fallout.Kernel;` (and .Collections/.Net) and `using Fallout.Common.IO;` → `using Fallout.Kernel.IO;`. Assembly/project files unchanged; only namespaces moved (the Fallout.Utilities → Fallout.Kernel project rename rides the deferred project-rename step). A few root-Fallout.Common guards (Assert/NotNull/EnvironmentInfo) stay in the dissolving catch-all for now and fold into Kernel later. Tooling: OnionRewriter rules retargeted for 5a. A handful of files the workspace didn't fully analyse were mopped up by hand (skipping package consumers and the Migrate rebrand fixtures, re-adding lost-ancestor usings) — see lesson #12. Full suite green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ts (onion step 5b) Move the concrete CI host providers (AppVeyor, AzurePipelines, TeamCity, GitHubActions, GitLab, TravisCI, Jenkins, Bitrise, Bitbucket, Bamboo, SpaceAutomation) and their config generators from Fallout.Common.CI.* to Fallout.Infrastructure.CI.*. The Application ring uses provider-SPECIFIC capabilities (PublishTestResults, PushArtifact, SetBuildNumber, UpdateBuildNumber, Token, …), so a generic host abstraction can't capture them. Instead, per-provider ports in Fallout.Application.CI — IAppVeyor/IAzurePipelines/ITeamCity/IGitHubActions — plus a CiHost accessor that casts the detected Host.Instance to the port (null when not running on that host). No registration needed: Host.Instance is the existing detection seam, and the providers (subclasses of Host) implement the ports. Components (ITest/IReportCoverage/ISignPackages/ICreateGitHubRelease) and version/coverage attributes now call CiHost.X instead of X.Instance, so the Application ring keeps no dependency on Fallout.Infrastructure.* — the fitness gate still passes. The two enums the ports expose move to Fallout.Application.CI as vocabulary. Nuke.Common CI host shims repointed to the new namespace. (The generic CI host abstraction — ADR-0005 IBuildHost/IBuildReporter, #341 — stays a separate additive effort.) Tooling: OnionRewriter rules retargeted for 5b (CI → Infrastructure.CI, enums overridden to Application.CI). Lesson #13: alias-qualified `global::Ns.Type` refs aren't rewritten (Left includes `global::`) — hit in the shims, mopped up. Full suite green; Application-ring fitness gate green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…amespace move Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Extends the 5a "filesystem is kernel-level" ruling to the rest of the fluent external-IO vocabulary. Investigation found every external-IO category the original plan earmarked for Infrastructure (HTTP fluent client, compression .ZipTo()/.UnZipTo(), HttpTasks/FtpTasks, glob) is consumed by gated Application-ring code, so none can move cleanly and all would otherwise need 5c-style ports. They're thin BCL-ergonomic layers, not genuine adapters — kept in Kernel; gate stays green. - spike 0003: mark 5d resolved-by-decision; correct the step-5 summary - ADR-0006: add Amendment reversing the "IO/Net/compression are genuinely infrastructure" default for the fluent vocabulary Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… tree) Reshape the Solution/Project/SolutionFolder/SolutionItem model from live wrappers over the vendored SolutionModel into a populated POCO tree with parent links + an opaque object Handle (carries the serializer model for Save without the inner ring naming vendored types). Public surface preserved. Translation walker lives in ReadSolution for now (still in the model project, still vendored-coupled — extracted to the Infrastructure adapter in phase B). The strongly-typed solution generator is coupled to the model ctor (it emits Solution subclasses), so update its template in lockstep: drop the vendored `using`, emit `(AbsolutePath, object handle)` ctor, ctor-less folder subclass. Namespaces unchanged (Fallout.Solutions) — no ring move yet. Build + Solution/ProjectModel/generator tests + dogfood build green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…or ports Invert the impure solution/project I/O behind Application-ring ports (ADR-0006), mirroring the 4b ToolingServices pattern: - ISolutionSerializer + IProjectEditor + SolutionServices locator added to the model project. The serializer adapter (vendored .sln/.slnx + the vendored→Fallout translation walker + opaque-handle save) is co-hosted with the model and self-registers via a [ModuleInitializer] (+ ns2.0 polyfill) — co-hosted like ToolingServices so registration is guaranteed on assembly load. - Model.cs + SolutionModelExtensions now route through the port and no longer reference any vendored type — the inner model is pure. - ProjectEditorAdapter (Microsoft.Build) in Fallout.ProjectModel implements IProjectEditor (GetProperty/SetProperty/HasPackageReference) + module-init. HasPackageReference moves from the Infra ProjectExtensions to a port-backed Application extension (its only framework-ring caller is Components/ITest); the rest of the MSBuild ProjectExtensions stay Infra (consumers/tests reference them directly). - Telemetry.CheckAwareness (dead code, telemetry disabled) rewired through IProjectEditor, dropping Fallout.Build's Microsoft.Build coupling. - Drop now-dead Fallout.Build/Fallout.Common → Fallout.ProjectModel refs; add explicit ProjectModel refs to the Cli composition root + the dogfood build (consumer of the MSBuild GetTargetFrameworks extension). Namespaces unchanged (Fallout.Solutions) — ring move is phase C. Full build + Solution/ProjectModel/generator/gate tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…namespace move)
Move the Fallout.Solutions namespace (declared across Fallout.Solution,
Fallout.ProjectModel, Fallout.Common) onto the onion rings via OnionRewriter,
splitting it three ways:
• model + ports + [Solution] vocabulary → Fallout.Application.Solutions
(the abstract concept, inner ring)
• vendored .sln/.slnx serializer adapter → Fallout.Infrastructure.Solutions
• Microsoft.Build evaluator (ProjectModelTasks/ProjectExtensions) →
Fallout.Infrastructure.ProjectModel
Realised with per-type overrides + a multi-assembly rule (18 moved types,
~47 files). After phase B the model already routes I/O through the ports,
so the move adds no Infrastructure dependency to the Application ring.
Companion edits the semantic rewriter can't make (string literals):
• generator template + attribute-detection string → Application.Solutions
• ShimMarker: mirror both new namespaces → Nuke.Common.ProjectModel
• cake ClassRewriter using-list + project template + generator test
snippets → Application.Solutions
• re-accepted 8 namespace-churned Verify snapshots (generator + cake)
Fitness gate now loads Fallout.Application.Solutions and stays green
(Application ⊥ Infrastructure). The strongly-typed-solution generator's
compile-time ReadSolution works unchanged — the serializer adapter is
co-hosted in the model assembly the generator already bundles, so its
[ModuleInitializer] fires. Full suite (14 projects) + dogfood ./build.sh
Compile green (runtime [Solution] injection through the port verified).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…realization Mark 5c complete in spike 0003: Fallout-owned POCO model + opaque handle, ISolutionSerializer/IProjectEditor ports, co-hosted adapters, the vendored-entanglement + false-positive findings, and the pre-existing ClassRewriter/template stale-namespace debt found but left out of scope. All substantive ring moves are now landed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…template
The cake migration's hard-coded using list (ClassRewriter.NamespaceImports)
and the `dotnet fallout :setup` Build.cs template still emitted pre-onion
Fallout.Common.* namespaces removed in steps 4a/4b/5b/5c — so migrated and
freshly-scaffolded builds referenced dead namespaces (CS0246).
- ClassRewriter: map dead Fallout.Common.{Execution,Tooling,Tools.GitVersion}
→ Fallout.Application.*; drop entries already contributed by the static
imports (Fallout.Common, Kernel.IO, Tools.DotNet, Tools.SignTool); add
.Distinct() so the emitted using list has no duplicates (the static-import
namespaces previously double-added Kernel.IO).
- Template Build.cs: map dead Fallout.Common.{CI,Tooling,Tools.*} +
Fallout.Solutions → their Fallout.Application.* homes. Kept the namespaces
that genuinely still live under Fallout.Common (root, .Execution, .Git
attribute, .ChangeLog, EnvironmentInfo) — Git/ChangeLog were only partially
migrated by earlier steps.
- Re-accepted the 7 cake-migration Verify snapshots.
Out of scope (pre-existing, noted): the template still references the removed
[CheckBuildProjectConfigurations] attribute, and the GitRepository class vs
[GitRepository] attribute are split across Application.Git/Common.Git from an
incomplete earlier move — separate follow-ups, not namespace staleness.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Stragglers from the earlier rings: GitRepositoryAttribute was still in Fallout.Common.Git while the GitRepository model already lived in Fallout.Application.Git, and the changelog helpers were still in Fallout.Common.ChangeLog. Move both into the Application ring via OnionRewriter (pass 1): • Fallout.Common.Git → Fallout.Application.Git (attribute joins the model) • Fallout.Common.ChangeLog → Fallout.Application.ChangeLog Update the dotnet-fallout template's two Git/ChangeLog usings to match. No shim-marker changes — the Application ring's Nuke.* shim story is the deferred redesign, so this just brings Git/ChangeLog in line with it. Full suite green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…/etc → Fallout.Kernel Four pure-utility types in the Fallout.Utilities (Kernel) project were left in the Fallout.Common namespace when step 5a moved everything else to Fallout.Kernel (the lesson-#12 workspace-load gap): EnvironmentInfo (5 files), Assert, AsyncHelper, ArgumentParser. Move them to Fallout.Kernel via OnionRewriter (pass 2, source assembly = Fallout.Utilities only so the surviving-namespace scan still sees Fallout.Common alive in the Fallout.Common project and keeps live `using Fallout.Common;` directives). ~180 files of reference churn (Assert/.NotNull() is pervasive). Two rewriter blind-spots fixed by hand: - Fallout.ProjectModel files carried `using Fallout.Common;` that only ever resolved because Fallout.Utilities declared those Common-namespace types; ProjectModel doesn't reference the Fallout.Common assembly, so the using dangled (CS0234) once they moved. The rewriter can't see assembly-ref graphs — replaced/dropped the stale usings (Kernel was already imported). - CITest.cs gained `using Fallout.Kernel;` (for .NotNull()), colliding Fallout.Kernel.Assert with Xunit.Assert — aliased the bare name to Xunit's. Companion edits: template + cake ClassRewriter EnvironmentInfo import → Fallout.Kernel; re-accepted 7 cake snapshots. Full suite + dogfood ./build.sh Compile green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ale cref Record the finished partial onion moves in spike 0003, and fix a stale doc-comment cref (Fallout.Common.Git.GitRepository → Fallout.Application.Git.GitRepository — the class had already moved). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… the exposed Infra dep) Last of the partial onion stragglers: - Fallout.Common.Execution (CheckPathEnvironmentVariable + HandleSingleFileExecution build-extension attributes) → join Fallout.Application.Execution. - Fallout.Common.Gitter (GitterTasks) → Fallout.Application.Tools.Gitter, alongside its sibling notification tools (Slack/Discord/Teams/Mastodon). Moving the two attributes into the Application ring made the fitness gate catch a real Application→Infrastructure dependency that was previously invisible only because the attributes sat in Fallout.Common.Execution (the spike flagged this: they "still reach Infrastructure"). Both called ProcessTasks (Fallout.Infrastructure.Tooling) directly — rerouted through the IProcessExecutor port (ToolingServices.Process), the same 4b inversion the rest of the Application ring uses. Gate green again. Template: Fallout.Common.Execution using → Fallout.Application.Execution (now fully evacuated). Full suite + dogfood ./build.sh Compile green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… ring names First phase of aligning project files with the (already onion-aligned) namespaces. Pure renames of the ring-pure projects (folders + .csproj + assembly + package IDs); no namespace edits, no file moves between projects: Fallout.Build → Fallout.Application Fallout.Components → Fallout.Application.Components Fallout.ProjectModel → Fallout.Infrastructure.ProjectModel Fallout.Utilities → Fallout.Kernel Fallout.Utilities.IO.Compression → Fallout.Kernel.IO.Compression Fallout.Utilities.IO.Globbing → Fallout.Kernel.IO.Globbing Fallout.Utilities.Net → Fallout.Kernel.Net Fallout.Utilities.Text.Json → Fallout.Kernel.Text.Json Fallout.Utilities.Text.Yaml → Fallout.Kernel.Text.Yaml Rewired ~71 files: all ProjectReferences, fallout.slnx, the SourceGenerators DLL-bundling paths (Fallout.Utilities.dll → Fallout.Kernel.dll), the shared AssemblyInfo.cs InternalsVisibleTo grants (Fallout.Build→Fallout.Application, Fallout.Utilities.IO.Globbing→Fallout.Kernel.IO.Globbing), and a hard-coded project-name lookup + the renamed-project accessors in the generator snapshot. Package IDs change (breaking) — rides the 2026 major. Mixed projects (Common/Tooling/Solution) split in later phases. Full suite + dogfood green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… assemblies
Split the mixed Fallout.Tooling project into:
Fallout.Application.Tooling — tool vocabulary + ports (ToolingServices,
ToolTasks, ToolOptions, ToolResolver, IProcess*)
netstandard2.0;net10.0 (consumed by the
Fallout.Tooling.Generator Roslyn generator)
Fallout.Infrastructure.Tooling — executors + resolvers (ProcessTasks,
ToolExecutor, *Resolver, the module-init
registration) — net10.0
Rewired all consumers (App ring → Application.Tooling; CI/MSBuildTasks/Cli →
Infrastructure.Tooling), the slnx, the AssemblyInfo IVT grants, removed 6
stale `using Fallout.Infrastructure.Tooling;` directives from Application-ring
files (no real Infra dependency — confirmed by the gate), and dropped net472
from MSBuildTasks (it now references the net10.0-only Infra.Tooling).
CRITICAL FIX (BuildManager.Initialize): the assembly force-loader used
Assembly.Load, which loads metadata but does NOT run a [ModuleInitializer]
(that fires lazily on first type use). Pre-split this was masked — build code
uses ToolingServices, co-hosted with its registration. Post-split the
registration moved to Fallout.Infrastructure.Tooling, whose types nothing
references directly, so it never ran → ToolingServices.* stayed null →
swallowed NRE at build-finish (CI-config drift check). Now the force-loader
calls RuntimeHelpers.RunModuleConstructor on each Fallout.* assembly, making
split-adapter registration deterministic (also covers the Solution/ProjectModel
splits to come). Caught via dogfood ./build.sh + a stash A/B against phase 1.
Full suite + gate + dogfood (zero NREs) green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…e assemblies
Split src/Persistence/Fallout.Solution into:
Fallout.Application.Solutions — Solution/Project model + ports
(SolutionServices, ReadSolution) — ns2.0;net10.0
Fallout.Infrastructure.Solutions — the .sln/.slnx serializer adapter +
registration — ns2.0;net10.0
Both at src/ top level; the vendored Fallout.Persistence.Solution stays.
Source generator: reads solutions at compile time, but a Roslyn host can't
run the adapter's module initializer to populate the SolutionServices
locator. Added Fallout.Infrastructure.Solutions.SolutionReader (a public
direct entry into the adapter) and pointed the generator at it — bypassing
the runtime locator (the generator is build-time tooling, not a ring).
Wiring: rewired all consumers (model → Application.Solutions); Cli + _build
(composition roots) reference Infrastructure.Solutions so its registration is
force-loaded for runtime [Solution] injection; moved the vendored
InternalsVisibleTo + the shared AssemblyInfo IVT grants to the split names;
updated the SourceGenerators DLL-bundling. Test hosts (Solution.Tests,
ProjectModel.Tests) get a [ModuleInitializer] that RunModuleConstructor's the
adapter assembly (same reason as the generator — no BuildManager force-load
in a test host).
Full suite + gate + dogfood (zero NREs, [Solution] injection works) green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…re assemblies + Fallout meta
The 249-file Fallout.Common catch-all is gone. Its files fan out by ring:
Tools/* + Gitter/ → Fallout.Application.Tools (new; tool wrappers)
CI/* (providers) → Fallout.Infrastructure.CI (new; Host-detected adapters)
CI/CiHostPorts + 2 enums → Fallout.Application (Application.CI)
ChangeLog, Git/Execution/Solution/Tooling attrs, HttpTasks, FtpTasks,
TemplateUtility, globbing attrs → Fallout.Application
GitHub-coupled bits (LatestGitHubRelease, ChangeLogTasks) → Fallout.Application.Tools
TextTasks, XmlTasks → Fallout.Kernel (genuinely pure)
New consumer-facing meta-package **Fallout** (no code): references every ring
+ carries the MSBuild integration (Fallout.props/.targets, renamed from
Fallout.Common.*), the MSBuildTasks publish output, and the source-generator
analyzer — the packaging-anchor role Fallout.Common held. Cli, the Nuke.Common
shim, and consumers now reference Fallout; ring-internal consumers reference
the specific ring projects.
Placement was dependency-driven, not namespace-driven: injection/extension
attributes (SolutionAttribute, [Latest*], [GitRepository], globbing attrs) and
ControlFlow/Configure/Serilog-coupled IO (FtpTasks, HttpTasks, TemplateUtility)
must live in Fallout.Application despite their Kernel.IO/Application.Tooling/etc.
namespaces, because their base classes live there and the leaf ring projects
are referenced BY Fallout.Application (placing them in the leaves would cycle).
Residual noted: a handful of Kernel.IO-namespace files sit in the Application
assembly (FtpTasks/HttpTasks/globbing attrs) — a namespace-vs-assembly cleanup
for later, ring-safe (no Infra dependency, gate green).
Wired all refs + slnx (+Fallout +Application.Tools +Infrastructure.CI),
AssemblyInfo IVT grants, _build props/targets import → Fallout.props/.targets,
and _build's direct refs. Full suite + gate + dogfood (zero NREs) green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…lout meta - Fallout.Domain: netstandard2.1;net10.0 → net10.0 (both consumers are net10.0; nothing constrains it). - Fallout.Infrastructure.ProjectModel: KEEP net8.0;net9.0;net10.0 — the multi-targeting is load-bearing (Directory.Packages.props pins a matching Microsoft.Build per TFM: net10→18.0.2, net9→17.14, net8→17.11; the standard MSBuildLocator SDK-matching pattern). The plan's "nothing constrains it" premise was wrong; reverted that part. - Consumer wiring for the dissolved Fallout.Common package: the dotnet-fallout template now adds the `Fallout` meta-package; Constants.FalloutCommonPackageId → FalloutPackageId = "Fallout"; `:setup` version lookup/prompts and `:update`'s package-bump now target the meta. (The Fallout.Common NAMESPACE survives in Fallout.Build.Shared — Constants/LegacyEnvironment — so the using directives stay valid.) - Fallout.Build.Shared: kept as the shared-primitives leaf (its residual Fallout.Common-root namespace is a separate namespace cleanup, not a project rename). Fitness gate green (now operating on ring-pure assemblies). Full suite + gate + dogfood green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ADR-0006) The structural realignment is complete — ring = project = namespace = assembly = package. Document the project-file renames/splits, the Fallout meta-package as the consumer anchor, the TFM decisions, and the Assembly.Load-vs-ModuleInitializer fix (RunModuleConstructor) as the general pattern for ring splits. Only the Nuke.* shim/Migrate redesign remains. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… → Fallout.Application.IO Namespace-vs-assembly tidy-up from the project-rename phase. FtpTasks, HttpTasks, and the globbing injection attributes (FileSystemGlobbingAttributeBase + FileGlobbingAttribute, GlobbingOptionsAttribute) carried a Fallout.Kernel.IO namespace but physically live in the Fallout.Application assembly (they depend on the Application ring — ControlFlow/Configure — so they can't be Kernel). Retargeted their namespace to Fallout.Application.IO so namespace matches assembly/ring. Source assembly = Fallout.Application only; the 20 genuine Kernel.IO types in Fallout.Kernel are untouched (Fallout.Kernel.IO survives, so live `using Fallout.Kernel.IO;` directives are preserved). Consumers gain `using Fallout.Application.IO;` where they used these 4 types. Full suite + gate + dogfood green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…pace → Fallout.Build.Shared The final Fallout.Common namespace (Constants + LegacyEnvironment, physically in the Fallout.Build.Shared assembly) is relabelled to Fallout.Build.Shared so namespace matches assembly — the dissolved Fallout.Common catch-all is now gone from the entire shipped codebase. Pure namespace relabel + using rewrites across ~87 files (no assembly-graph change; Constants stays in Build.Shared). Deleted a vestigial empty Fallout.Common.FalloutBuild stub in SourceGenerators first, so the namespace was fully evacuated and 75 dead `using Fallout.Common;` directives dropped cleanly. Also removed the now-dead `using Fallout.Common;` from the dotnet-fallout starter template (embedded resource the semantic rewriter can't reach — would have been CS0246 in a freshly-scaffolded build). (Migrate test fixtures still contain "Fallout.Common"/"Nuke.Common" as Nuke→Fallout migration test DATA — intentionally unchanged.) Full suite (14 projects) + gate + dogfood green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…y gone Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ChrisonSimtian
force-pushed
the
spike/onion-infrastructure
branch
from
2934d9f to
c15499d
Compare
ChrisonSimtian
force-pushed
the
spike/onion-kernel
branch
from
4c3c86d to
36fc88e
Compare
Collaborator
Author
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.
What
Closes out the structural half of the onion realignment (ADR-0006) on top of the Domain (#343) + Application (#349) + Infrastructure (#350) rings. Started as steps 5a/5b; now carries the realignment through to its structural end —
ring = project = namespace = assembly = package.Fallout.*consumers migrate per the CHANGELOG; theNuke.*shim/Migrate redesign is the one remaining deferred piece.Rings (namespaces)
Fallout.Kernel: shared utility/IO/path-value ring (filesystem kept kernel-level).Fallout.Infrastructure.CIviaFallout.Application.CIports +CiHost.SolutionPOCO model +[Solution]injection behindISolutionSerializer/IProjectEditorports (Fallout.Application.Solutions);.sln/.slnxserializer adapter →Fallout.Infrastructure.Solutions; MSBuild evaluator →Fallout.Infrastructure.ProjectModel.Fallout.Application.*;Assert/EnvironmentInfo/AsyncHelper/ArgumentParser→Fallout.Kernel; Execution + Gitter → Application.Project files / assemblies / packages (the mechanical close-out)
Fallout.Build→Fallout.Application,Fallout.Components→Fallout.Application.Components,Fallout.ProjectModel→Fallout.Infrastructure.ProjectModel,Fallout.Utilities*→Fallout.Kernel*.Fallout.Tooling→Application.Tooling+Infrastructure.Tooling;Fallout.Solution→Application.Solutions+Infrastructure.Solutions;Fallout.Common(249 files) dissolved →Application.Tools+Infrastructure.CI+Application+Kernel.Falloutmeta-package = the consumer anchor (references every ring + carriesFallout.props/.targets, MSBuildTasks output, the source-generator analyzer).dotnet fallout :setup/:updatetarget it. MigrateFallout.Common→Fallout.net472dropped (dotnet build-only);Fallout.Domain→net10.0; ns2.0 kept only on the Roslyn generators + the ring halves they consume;Fallout.Infrastructure.ProjectModelkeepsnet8/9/10(per-TFM Microsoft.Build SDK matching).Why it's safe
Fallout.Architecture.Tests) enforcesFallout.Application.* ⊥ Fallout.Infrastructure.*, now across ring-pure assemblies — green.Assembly.Loaddoesn't run[ModuleInitializer]s, so splitting ports from adapters silently broke registration (null services, swallowed NRE — passed unit tests, caught by the dogfood build).BuildManager.InitializenowRunModuleConstructors eachFallout.*assembly; the generator uses aSolutionReaderdirect-read; test hosts force-run the adapter ctors../build.sh Testgreen throughout; each phase committed build-green.Known residuals (follow-up, not blocking; gate green)
Kernel.IO-namespace files (FtpTasks/HttpTasks/globbing attrs) physically sit in theFallout.Applicationassembly (they depend onControlFlow/Configure) — namespace-vs-assembly tidy-up.Fallout.Build.Sharedstill hosts theFallout.Common-root namespace (Constants/LegacyEnvironment).Nuke.*shim /Fallout.Migrateredesign (deferred by ADR-0006).🤖 Generated with Claude Code