Problem
dotnet pack writes exclude="Build,Analyzers" on nuspec dependencies by default, so the FirstClassErrors.RequestBinder package's dependency on the core does not flow the bundled FCE analyzers to a consumer who installs only the binder. The repository itself knows a plain reference does not carry analyzers (it wires them explicitly for its own dogfood — csproj comment referencing issue #153), but RequestBinder.en.md's install section presents the binder as a standalone dotnet add package with no companion-reference note.
Impact
The consumer most likely to be documenting a boundary error surface — the binder's whole pitch is "coded, documented PrimaryPortError trees" — is the one silently missing the rules that enforce the discipline.
Direction
- Preferred: reuse the core's
_AddAnalyzerToPackage target in FirstClassErrors.RequestBinder.csproj so the FCE analyzers also ship at analyzers/dotnet/cs of the binder package (Roslyn deduplicates by assembly identity; the lockstep train guarantees version match).
- Cheaper alternative: one documented sentence in
RequestBinder.en.md + .fr.md stating the analyzers flow only from a direct FirstClassErrors reference.
Acceptance criteria
- A project referencing only
FirstClassErrors.RequestBinder gets FCE diagnostics (or, at minimum, the docs state explicitly that it will not and what to add).
- If bundled: the floor-check/packaging guards cover the binder package's analyzer payload.
Context
Surfaced by the 2026-07-20 architecture, design & ecosystem audit (doc/handwritten/for-maintainers/audit/2026-07-20-firstclasserrors-architecture-and-design-audit.md, §10.3/§14-HV13; branch claude/firstclasserrors-audit-83gap7).
Problem
dotnet packwritesexclude="Build,Analyzers"on nuspec dependencies by default, so theFirstClassErrors.RequestBinderpackage's dependency on the core does not flow the bundled FCE analyzers to a consumer who installs only the binder. The repository itself knows a plain reference does not carry analyzers (it wires them explicitly for its own dogfood — csproj comment referencing issue #153), butRequestBinder.en.md's install section presents the binder as a standalonedotnet add packagewith no companion-reference note.Impact
The consumer most likely to be documenting a boundary error surface — the binder's whole pitch is "coded, documented PrimaryPortError trees" — is the one silently missing the rules that enforce the discipline.
Direction
_AddAnalyzerToPackagetarget inFirstClassErrors.RequestBinder.csprojso the FCE analyzers also ship atanalyzers/dotnet/csof the binder package (Roslyn deduplicates by assembly identity; the lockstep train guarantees version match).RequestBinder.en.md+.fr.mdstating the analyzers flow only from a directFirstClassErrorsreference.Acceptance criteria
FirstClassErrors.RequestBindergets FCE diagnostics (or, at minimum, the docs state explicitly that it will not and what to add).Context
Surfaced by the 2026-07-20 architecture, design & ecosystem audit (
doc/handwritten/for-maintainers/audit/2026-07-20-firstclasserrors-architecture-and-design-audit.md, §10.3/§14-HV13; branchclaude/firstclasserrors-audit-83gap7).