Continuous delivery model: IPublishTarget, channels, environments (ADR-0009)

.editorconfig

@@ -6,7 +6,7 @@ root = true
 ####################################################################
 
 [*]
-end_of_line = crlf
+end_of_line = lf
 insert_final_newline = true
 trim_trailing_whitespace = true
 

CONTRIBUTING.md

@@ -51,7 +51,7 @@ Fallout welcomes contributions. As a community, we want to help each other, prov
 
 - **Write functional commit and PR titles** — describe what the change accomplishes, not how it's categorised. Do not use conventional-commit prefixes (`feat:`, `fix:`, `chore:`, `refactor:`, etc.). Good examples: "Add retry logic to the HTTP tool wrapper", "Fix null-reference in target dependency resolution". The `!` suffix (e.g. `fix(security)!: …`) is recognised only as a breaking-change detection signal, not a general style requirement.
 - Aim for qualitative, readable code that matches the surrounding style.
-- There's no committed `.editorconfig` or ReSharper/`*.DotSettings` file — they were removed during the takeover. Rely on `dotnet format` defaults and review; don't reintroduce them without a maintainer-level decision.
+- Style is codified in a committed `.editorconfig` (plus `fallout.slnx.DotSettings` for Rider/ReSharper). Match it and keep `dotnet format` green; don't delete or bypass it — change a rule deliberately if needed.
 - Add tests when meaningful — every `Foo` project has a sibling `Foo.Tests`.
 - Don't commit code generated by `./build.ps1 GenerateTools` — generated `.cs` files are regenerated manually once per release.
 - **Label the PR `target/vCurrent`** for the current release line (use `target/vNext` for work held to next year's major). Legacy `support/v10` maintenance work uses `target/v10`. **Breaking changes are batched to the yearly major cut**: they land on `main` gated behind `[Experimental("FALLOUT0xx")]` (or, when they can't be gated, on a short-lived topic branch off `main`) — never on a `release/YYYY` production train — are held for next year's `YYYY+1.0.0`, and additionally get a `breaking-change` label, a `⚠️ Breaking change` callout, and a `CHANGELOG.md` entry under the next-major `[Unreleased]` heading. Surface that isn't ready to commit to can ship behind `[Experimental("FALLOUT0xx")]` instead of being held back. See the [PR-creation flow](docs/agents/release-and-versioning.md#pr-creation-flow) for the full procedure.