List view
Audit (2026-06-02) of hand-rolled code that duplicates well-maintained NuGet packages, several of which are *already referenced* in Directory.Packages.props. Goal: cut maintenance surface and fragility on the 2026 line. Tiers: - **Tier 1 (replace):** fragile hand-rolled code with a clear, mature replacement. - **Tier 2 (consolidate):** thin helpers that overlap packages already in deps (MoreLINQ candidate, Humanizer) + dead shims. - **Tier 3 (keep):** hand-rolled code that is justified — document the rationale so it is not re-litigated. Per ADR-0004: public-API-breaking swaps carry the `breaking-change` label and land on `experimental` (batched to the yearly major), even though the effort is grouped here. Non-breaking tasks should wrap replacements behind existing public signatures. --- **Evaluated & rejected — Pathy (dennisdoomen/pathy), 2026-06-02.** Considered as a replacement for `AbsolutePath` + the IO globbing wrapper. Rejected: (1) type-model mismatch — Pathy is a single `ChainablePath`, while our `AbsolutePath` is a foundational public type (527 uses / 92 files) with a relative-path hierarchy, `IFormattable` quote formats driving tool-arg rendering, and `TypeConverter` parameter injection that Pathy lacks; (2) globbing semantics differ — Pathy.Globbing uses Microsoft.Extensions.FileSystemGlobbing (file-oriented, no clean `GlobDirectories` equivalent, different `**`/case-sensitivity behavior) vs our GlobExpressions wrapper, across 38 call sites. Reinforces the keep decision in #358.
No due date•0/7 issues closedTrim CI waste and realign the pipeline to the 3-tier branch ladder (experimental -alpha / main -preview / release+support production). Public repo = Actions free, so this targets feedback latency, hygiene, and future-proofing (if anything goes private the savings become real money). Quick wins (triggers/concurrency/paths) + structural (split build/test/pack, gate cross-platform to release intent, caching). Couples to the in-flight branch-model restructure.
No due date•7/9 issues closedSub-area of the Continuous Delivery Vision (#8): CD for Proxmox, which extends to deploying onto VMs and regular on-prem/bare-metal machines, as well as LXC and containers. Self-hostable target (Proxmox VE nests in a VM), so cheap to exercise without cloud spend. Distinct target class from the public clouds (Azure #14, AWS, GCP). Chris is actively prototyping this. Long-horizon, shape TBD. Parent: #8.
No due date•0/1 issues closedSub-area of the Continuous Delivery Vision (#8): GCP-specific deployment/release orchestration, developed and tested against Google's local service **emulators** (gcloud emulators for Pub/Sub, Firestore, Datastore, Bigtable, Spanner; fake-gcs-server for storage). Coverage is patchier than LocalStack/Topaz — to assess during scoping. Sibling to Azure (#14) and AWS tracks. Long-horizon, shape TBD. Parent: #8.
No due date•0/1 issues closedSub-area of the Continuous Delivery Vision (#8): AWS-specific deployment/release orchestration, developed and tested cheaply against **LocalStack** (the de-facto AWS cloud emulator) — no real AWS spend. Sibling to the Azure (#14) track. Long-horizon, shape TBD. Parent: #8.
No due date•0/1 issues closedSub-area of the Continuous Delivery Vision (#8): Azure-specific deployment/release orchestration, developed and tested cheaply against **Topaz**, the open-source Azure cloud emulator — no real Azure spend. Directly motivated by real workplace need, which makes it a low-cost proving ground for Fallout's CD primitives. Long-horizon, shape TBD; collects Azure CD scoping + work. Parent: #8.
No due date•0/1 issues closedShift the project from "every merge to main = release" to a release-branch model with tag-triggered, multi-channel CD. **Driven by RFC [#267](https://github.com/ChrisonSimtian/Fallout/issues/267)** — design discussion, open questions, work breakdown. ## What changes - **`main` becomes the integration trunk** — what's in `main` is what's currently stable for the active major. Merging to `main` no longer publishes. - **`release/vN` branches are the release channels** — `release/v11` cut from `main` at the v11.0.0 ship point. Eventually `release/vN.M` for minor lines. - **Tag-triggered publish** — pushing `v11.0.4` (or similar) to `release/v11` fires the publish workflow. Merging to a release branch only stages commits. - **Hotfix flow via cherry-pick** — fixes land on `main` first, then cherry-pick to `release/vN` and tag. - **Multi-channel CD via GitHub Environments** — three environments keyed by channel (`nuget-org`, `github-packages`, `github-releases`), one publish workflow producing three deployment records. nuget-org gets an approval gate (irreversible). - **Documentation in `CONTRIBUTING.md` and `docs/`** — contributors and AI agents both need to understand the new flow. ## Why a separate milestone This work cuts across all major versions — it's process/infrastructure, not feature work. Related to but distinct from: - [#4 CI roadmap](https://github.com/ChrisonSimtian/Fallout/milestone/4) — broader CI restructuring. - [#8 Continuous Delivery Vision](https://github.com/ChrisonSimtian/Fallout/milestone/8) — v13 long-horizon CD/release thinking. - [#263 CHANGELOG vs GitHub releases](https://github.com/ChrisonSimtian/Fallout/issues/263) — auto-generated release notes question intersects here. This milestone is the concrete first step toward a stable CD shape, scoped tightly to the branching + publish-trigger restructure.
No due date•20/23 issues closedCross-cutting milestone for making the repo work well with multiple AI coding tools (Claude Code, GitHub Copilot, Aider, Cursor, Continue, Codex, future ones). Tool-agnostic by design. Loose milestone, no target date — items here graduate to active work when a maintainer picks them up.
No due date•1/6 issues closedStand up a dedicated organization/account that owns every identity asset for the Fallout brand — domain, GitHub repositories, and nuget.org handle — so the project is not personally bound. Loose milestone, no target date.
No due date•1/6 issues closedCommunity channels, comms, announcement — sequenced by Chris, not tied to a version.
No due date•0/2 issues closedIssues to investigate or scope before targeting a specific release. Things that aren't blocking but need someone to look at before being assigned to a milestone.
No due dateLong-horizon: extend Fallout beyond CI into release management & deployment orchestration (think Octopus Deploy / TeamCity release pipelines, C#-native and code-first). Shape is TBD — this milestone collects RFCs and scoping work. No commitment to a release date. **Sub-areas:** Azure Cloud (Topaz emulator) → milestone #14 (https://github.com/ChrisonSimtian/Fallout/milestone/14), seeded by #281.
No due date•0/34 issues closedPublishes Fallout.Plugin.Sdk 1.0 — the stable, additive-only abstractions package contributors compile their plugins against. Migrates first-party CI host adapters onto the SDK as dogfood proof. Ships a canonical sample plugin and the plugin author's guide. Locks and versions the JSON tool-wrapper schema. Shape driven by the RFC discussions opened in 11.0.
No due date•0/24 issues closedTwo coordinated workstreams. (A) Finish the Nuke→Fallout rebrand (shim packages, migration tool, codefix, announcement, docs). (B) Internal foundation for the plugin architecture: extract Fallout.Core domain, introduce DI, split FalloutBuild god class, internal IBuildMiddleware pipeline. No public plugin SDK in this release — that is v12. See docs/roadmap.md; design RFCs driving v12 are in milestone #7. Issues labelled `v11-slip-ok` may push to 11.1 if v11 timeline pressures; unlabelled issues are required for the 11.0 cut.
No due date•9/32 issues closedCoordinated rebrand from NUKE to Fallout — repo, code, packages, bridge, docs, community. Each issue is a discrete step; respect the phase prefix in the title for ordering.
No due date•17/17 issues closedDemand-driven CI hardening and provider revival. Items here are not committed to a release — they get pulled into a numbered milestone once we have signal.
No due date•0/7 issues closedDesign discussions, unlabeled long-tail, items without a release target yet.
No due date•3/14 issues closed.NET 10 follow-up bugs, slnx polish, Microsoft.Testing.Platform support. Targets ~6 weeks.
No due date•21/21 issues closedSecurity patches, stale-PR triage pass, low-hanging fixes. Targets ~2 weeks.
No due date•11/11 issues closed