Problem
A FirstClassErrors package can ship its own emittable, documented error codes. FirstClassErrors.RequestBinder is the first to do so (REQUEST_ARGUMENT_REQUIRED, REQUEST_ARGUMENT_INVALID); the core library defines none.
fce generate --solution documents opted-in projects — the GenerateErrorDocumentation marker, discovered via dotnet sln list. It never scans referenced packages. So a consumer that uses such a package emits those codes to its clients at runtime, yet its generated catalogue omits them — the exact "undocumented code in production" gap the library exists to close.
Current workaround
fce generate --assemblies <package>.dll documents any named binary (the reader already reads internal/private factories). But --assemblies and --solution are mutually exclusive, so it produces a separate catalogue to merge by hand, and nothing tells the consumer to do it.
Proposed direction
An assembly-level opt-in attribute — e.g. [assembly: ProvidesErrorDocumentation], mirroring the existing [assembly: DocumentationContractVersion] that fce already reads. A package self-declares that it carries a documented catalogue; fce generate --solution gains a discovery step that also includes direct referenced assemblies bearing the attribute, via a cheap metadata-only pre-check (only attribute-bearing assemblies get the full extraction). Error codes stay library-owned; zero consumer boilerplate.
Open questions
- Filter by the attribute, not by assembly name, so third-party FirstClassErrors-based packages benefit too.
- Scope to direct references of opted-in projects (a transitive dependency was not chosen by the consumer; "referenced" does not always mean "emitted on the public surface").
- Code collisions between packages.
- Doc-contract version mismatch of a referenced package (the existing contract-version attribute helps detect it).
- Executing example factories from third-party assemblies at generation time (isolation via the existing worker model).
Scope
Deliberately decoupled from the request-binder feature (#126), which surfaced this. Likely warrants an ADR once a direction is chosen.
Problem
A FirstClassErrors package can ship its own emittable, documented error codes.
FirstClassErrors.RequestBinderis the first to do so (REQUEST_ARGUMENT_REQUIRED,REQUEST_ARGUMENT_INVALID); the core library defines none.fce generate --solutiondocuments opted-in projects — theGenerateErrorDocumentationmarker, discovered viadotnet sln list. It never scans referenced packages. So a consumer that uses such a package emits those codes to its clients at runtime, yet its generated catalogue omits them — the exact "undocumented code in production" gap the library exists to close.Current workaround
fce generate --assemblies <package>.dlldocuments any named binary (the reader already readsinternal/privatefactories). But--assembliesand--solutionare mutually exclusive, so it produces a separate catalogue to merge by hand, and nothing tells the consumer to do it.Proposed direction
An assembly-level opt-in attribute — e.g.
[assembly: ProvidesErrorDocumentation], mirroring the existing[assembly: DocumentationContractVersion]thatfcealready reads. A package self-declares that it carries a documented catalogue;fce generate --solutiongains a discovery step that also includes direct referenced assemblies bearing the attribute, via a cheap metadata-only pre-check (only attribute-bearing assemblies get the full extraction). Error codes stay library-owned; zero consumer boilerplate.Open questions
Scope
Deliberately decoupled from the request-binder feature (#126), which surfaced this. Likely warrants an ADR once a direction is chosen.