[C] #514 slice 17: assembly split — conditional on Track A/B evidence

[mforce]

Amended 2026-10-04: scope changed by the owner. Step 1 replaces module-ledger.json, tenant-bypass-allowlist.json and filter-free-set-sites.tsv with typed C# registries, with no assembly split. The entry-condition evidence and the options comparison are in this comment. The original body is kept below for history.

Important

Track C is unscheduled. These slices move production code, and the 2026-08 design's own status
line still governs: "proposed architecture; no production refactor is authorized by this
document." Filed so the analysis is tracked work rather than a comment, not as a commitment to
run it.

The 2026-09-14 re-plan
recommends gating Track C on evidence from Tracks A and B: if the #842 ratchet fires repeatedly in
real pull requests, these become worth their cost; if it stays quiet, they do not. Track C is
57–95 focused engineering days and produces no user-visible change.

Read the re-plan before picking any of these up. Several assumptions in the 2026-08 plan are
corrected there.

Split the modules into separate assemblies so the compiler enforces what the ledger has been
watching. Conditional — see the bar below.

This slice has an entry condition, and it is not "the others finished"

Run it only if Tracks A and B produced evidence that a boundary was actually crossed by accident.
If the ratchet (#842) and the adapter guard (#846) sat quiet through the whole of Track C, then a
source walk was sufficient, nobody was reaching where they should not, and this buys a compiler error
for a problem that did not occur.

That is not a formality. This is the single most expensive slice in the epic and the one most likely
not to earn its cost.

What it buys that nothing before it does

Peer implementations become genuinely invisible — not "we notice", but "it does not compile".
Everything in Tracks A and B is detection. This is prevention.

What it costs, priced honestly

Per new project: a packages.lock.json under Central Package Management (#684), a COPY line in the
Dockerfile restore layer, and for a test project a CI matrix leg (#775), a
SolutionTestProjectSplitTests reconcile and a tools/coverage/collect.sh entry. Multiply by the
number of assemblies.

Plus a namespace rename across the tenancy registry's symbol-keyed rows and the filter-free-set TSV —
which is precisely the re-pinning churn #632 keyed those by symbol to avoid. Do it once, deliberately,
in a single reviewable commit, or not at all.

The cross-owner foreign-key mechanism, already solved

A cross-owner FK is never expressed through EF's generic fluent API — that type parameter is what
forces a Platform.Persistence ↔ Module.Implementation cycle. Use the fully string-based
non-generic form from the owner's own configuration, e.g.

builder.HasOne("Cluckwork.Domain.Flocks.Flock").WithMany().HasForeignKey("FlockId")
       .HasConstraintName("FK_Expenses_Flocks_FlockId").OnDelete(DeleteBehavior.Restrict);

The fully-qualified name and the Restrict delete behaviour are both load-bearing — a typo'd
namespace or a dropped OnDelete each independently fail the model-equivalence check. This
reproduces exactly what InitialCreate already created, so it needs no new migration; emitting
AddForeignKey for an existing constraint name fails on every already-migrated database.

Done when

The six architecture mutations from the 2026-08 design §8 go red at assembly level rather than at
source level. EF model digest identical. Full solution, frontend and simulation verification green.

• Change map in the PR (owner, 2026-10-01). The PR carries a before/after diagram of who calls whom, in the shape of the refactor(finance): put Finance behind an IFinanceModule contract #1010 and refactor(insights): read reports, exports and audit provenance through an Insights facade #1012 change maps: the adapters and module types before and after, any ledger edges added or removed, and the end state of any file another open slice also changes. Put it in the PR body or a PR comment as a fenced text block.

[mforce]

Blocked on its own entry condition, measured 2026-09-26

This slice says to run it only if Tracks A and B produced evidence that a boundary was actually crossed by accident. That evidence has now been gathered, and it says no.

Measured over main from the day the ledger landed (8f9e672) to e47288c, 62 merges:

Signal	Count
Feature pull requests that had to touch the ledger	3 of 62
New module-to-module cells lit up	0
Existing module cells that gained a symbol	1
Adapter reach counts that rose	2
Accidental crossings caught	0

The three firings were #912, #918 and #950. The one module-cell change is Egg Operations to Farm going from one symbol to two, when EggGradeFloorPolicy read a role enum. The other two were endpoints reaching more owners, which Platform is explicitly permitted to do as the free hub. In all three the crossing was deliberate, and the author declared it correctly on the first attempt. Nobody reached where they should not have.

So the entry condition is unmet, and this is the most expensive slice in the epic. It stays open and stays unscheduled, but it is now explicitly blocked rather than merely unprioritised, so nobody picks it up expecting it to be ready.

Re-check trigger. Revisit when either of these becomes true, and record the evidence here:

1. The ledger, table-owner or adapter ratchet catches a crossing the author did not intend, in a real pull request, at least twice.
2. A second deployable is actually planned, at which point the guarantee is needed for a reason other than hygiene.

Until then, detection through the committed ledger is doing the job that this slice would spend the most to improve.

[mforce]

Evidence from Track C, 2026-10-02

The 2026-09-26 measurement still holds for the trigger as written: no merge in Track C so far crossed a module boundary by accident. Every crossing in #1010, #1012, #1013, #1015 and #1021 was declared deliberately. Track C's review rounds produced a different kind of evidence, recorded here so the next decision on this slice can weigh it.

Static guards have a ceiling that internal does not. Every contract-guard gap that reviewers found and that could not be fixed cheaply was runtime substitution behind a declared type:

• refactor(flocks): put flock lifecycle behind an IFlockModule contract #1021 round 2: a constructed Result<Flock> returned through a contract method declared Task<Result>. A guard that reads declared types cannot see it, so it is now documented as review-only in docs/decisions/852-flock-contract.md and 849-module-contract.md.
• refactor(flocks): put flock lifecycle behind an IFlockModule contract #1021 round 2: a Result subclass carrying a Flock, built in Infrastructure and handed back through DI. Fixed by widening the scanned assemblies, but the fix only covers assemblies the test project references.
• test(arch): register and date every module compatibility exception #1013 rounds 1–2: interface laundering, a generic type sharing a trusted type's name, and an expression-bodied DbSet getter that runs a query. All were fixed, but each fix added scanner complexity.

If each module's entities and repositories lived in their own assembly as internal, the compiler would reject every one of these outright, with no scanner involved.

A cheaper first step than the full split. Modular-monolith practice commonly gives each module a small Cluckwork.Modules.<X>.Contracts project holding the module interface and its records. Peers reference only that project. On its own, a contracts project buys dependency-direction clarity and makes the later split mechanical. Compile-time enforcement only arrives once the implementation also moves out and becomes internal, because peers sharing the Cluckwork.Application assembly can still reach implementation types. Contracts that exist today, all inside Cluckwork.Application:

• IFinanceModule ([C] #514 slice 7: Finance pilot — first module behind a contract #849)
• IInsightsModule ([C] #514 slice 14: Insights read facade for reports, exports and audit reads #856)
• IFarmModule ([C] #514 slice 9: Farm contract, with tenant identity staying in Platform #851)
• IFlockModule, IFlockLookup and IMortalityLedger ([C] #514 slice 10: Flock Management contract, eligibility and mortality ports #852)
• IInventoryModule ([C] #514 slice 13: General Inventory contract and the flock-eligibility read #855, in progress)

Unchanged: the single AppDbContext is still the expensive part of a real split. This note does not schedule the slice; the owner decides.

[mforce]

What #858 (Track C Platform composition) leaves for the assembly split

#858 finishes in PR #1066. Track C's ledger end state is recorded in docs/decisions/858-platform-composition.md; once #1066 merges, the file lives on main. This comment lists what that state hands to this slice, measured at #1066's head 06a24053. It is not a recommendation to start it.

Still detection, not prevention: what the split would turn into compiler errors

• compatibilityExceptions holds one row, and it is this issue's: UserRoleAssignmentRepository.ListByNameByUserAsync left-joins the filtered Flocks set in one statement, so the flock-scope filter decides which names a caller sees (Add discovery guard for flock-scoped EF query filters #613). Replacing it with IFlockLookup.GetDisplayNamesAsync adds a round trip. A split must keep the single-statement projection or accept that cost.
• Fixture ports (I<Module>Fixture, Access's IAccessSeedLookup/IAccessFixture) are contract types. Any adapter can inject them, and only the !IsProduction() registration gate keeps them out of Production request code. An assembly split does not change that: the seeders live in Platform Infrastructure.Persistence and need the ports to stay public. Keep FixturePortRegistrationTests.
• Loosenable is empty but reported, not enforced ([B] #514 slice 4: adapter-privilege ratchet over endpoints, CLI, jobs and seeders #846).

The map a split would follow

• Module implementations still share Cluckwork.Infrastructure.Repositories, fixture implementations included. Each owner's ledger implementations list names only those that sit outside the owner's namespaces. Implementations inside them carry the own-module allowance and must not be listed: listing Access's AccessFixture fails CompatibilityExceptionRealTreeTests. A move inventory is therefore the implementations list plus every implementation already in an owner's namespaces, such as Access's Cluckwork.Infrastructure.Identity classes (AccessFixture, AccessSeedLookup, AccessLookup, IdentityProvider and the rest).
• Registration is already one file per owner under Cluckwork.Api/Hosting/Modules/, listed by AddCluckworkModules; Access registers in AddCluckworkIdentity. A per-module assembly could own its registration extension as is.
• Farm's seam (IAccountRepository, Account, UserRoleAssignment) is used directly by peers. It must stay public across a split.
• Platform stays the free hub (Cluckwork.Api.*, Infrastructure.* except Identity): migrate, healthcheck, the SimulationSeedStates anchor, the idempotency purge and DurableJobWorker reach no module. persistenceForbiddenNamespaces is still only Cluckwork.Api.Endpoints.
• One AppDbContext maps every module's entities. The string-based FK mechanism above remains the way to avoid a Platform↔module cycle.

Entry-condition evidence from #858 (eight PRs: #1040, #1042, #1043, #1062, #1063, #1064, #1065, #1066)

Every ledger-guard failure across those PRs came from a planned move or a deliberate mutation. None was an accidental boundary crossing found in normal work. Two examples:

• adding an Access → Farm/Access → FlockManagement symbol for AccessFixture in refactor(seed): read and write simulation fixtures through module ports #1063;
• a missing Ensure* discovery path that Astra found in review of refactor(api): register each module from its own file #1065, which was a gap in the guard's own discovery, not a crossing.

So #858 adds no evidence that the ratchet fired on a real accidental crossing. Tracks A/B evidence from other PRs is outside what I measured.

Edited 2026-10-04 after Astra's review of #1066: corrected which implementations the ledger lists, and the move inventory.

[mforce]

Scope change, approved by the owner on 2026-10-04: typed C# registries replace the rule files. No assembly split.

Evidence that the split's entry condition is unmet. All 64 failed PR runs since #842 still have their logs. Exactly one failed on a boundary guard, because of an unsupported handler shape (#874), not an accidental crossing. Review comments and commit messages since 2026-09-14 show deliberate edge declarations, row bookkeeping and one ownership-guard bug. They show zero accidental crossings. #858's own PRs found the same; see the amendment above.

Options compared. Option A: attributes plus one Roslyn analyzer, keeping today's projects. Option B: split into assemblies, 9 → 27 projects. An independent design review recommended against B on this evidence. B has gaps in its migration plan and its compile-time guarantees: endpoints could still reach EF through transitive packages, a module could return an internal entity through Result, and several registrations cannot move as written. Neither option removes the declarations themselves, because tenant-bypass approvals and module-pair rules are decisions, not compiler facts. The owner accepted typed C# declarations.

Step 1 (now in scope). Delete Architecture/Data/module-ledger.json, TenantBypass/Data/tenant-bypass-allowlist.json and TenantBypass/Data/filter-free-set-sites.tsv. Their rows become typed C# registries in tests/Cluckwork.Application.Tests: six RealModuleLedger.*.cs partial files, plus BypassAllowList.cs and FilterFreeSetSites.cs, each kept separate from the code it excuses. The scanners keep their logic and take the same objects instead of a file path. Behaviour stays identical: the same rules, the same #632 identities and token hashes, the same reasons, and the runtime needs-review trim. There is no new project, no analyzer and no src/ change beyond comments. Converting the current data to C# and back is byte-identical: all 9 ledger sections, 40 allowlist rows and 36 filter-free identities.

Delivered as three PRs, about 5.5–8.5 days in total:

1. A loader seam: scanners take objects, and semantic validation is separated from parsing.
2. All nine ledger sections in one PR. It deletes module-ledger.json, its parser and 12 JSON-syntax fixtures.
3. Both tenant registries.

Each PR first proves in CI that the C# copy equals the file it replaces. It then switches the reader and deletes the file. CI parity is renewed whenever a rebase changes the source rows.

Still owed by this issue after step 1. The one remaining compatibility exception, the filtered Flocks LEFT JOIN, moves byte-identical with deleteWhen: "#859". Removing it is still this issue's job.

Out of scope for step 1, as separate follow-ups:

• three ledger corrections: FarmModule → Commerce DiscountCeiling, Access → Commerce through IIdentityProvider, and seven false import-scope edge rows;
• policy tightenings: token hashes on the 40 allow-listed bypasses, unused adapter reach as an error, and deriving tables;
• a Roslyn analyzer, considered rule by rule only where a working prototype shows simpler maintenance.