Facade
Keep the public surface narrow
External projects should call stable facade interfaces. A facade coordinates logic and repositories, but callers never need to know whether the result came from a file, package fixture, database, or cache.
Protocol5 wiki
C# code standards for Protocol5 implementation work
These standards apply to Protocol5 UAI-1 for .NET implementation work. They are intentionally practical: readable types, stable interfaces, testable logic, repository abstraction, and public evidence for behavior.
Required rules
Baseline C# standards
- Explicit types
- Use explicit interface or concrete types in implementation code that needs reviewable public behavior.
- Interfaces first
- Consumers depend on facade, service, repository, and adapter interfaces rather than concrete storage or AI providers.
- POCO DTOs
- Request and response objects stay simple, serializable, and free of repository, SQL, HTTP, or UI dependencies.
- Automated tests
- Every behavior slice gets unit or contract tests before it is treated as an implementation rule.
Logic
Business rules stay out of repositories
Normalization, Unicode scalar handling, grapheme grouping, approximate weighting, score thresholds, and private-use rejection belong in logic services that can be tested without a database.
Repository
Storage is behind contracts
ADO.NET repositories implement interfaces with SQL Server vector commands, but application logic uses repository contracts and POCO values. Storage mechanics do not leak up the stack.
Quality
Tests define the contract
Contract tests should cover facade behavior, package fixtures, schema expectations, route contracts, and source-style rules.
Current enforcement
Rules already under test
| Rule | Current enforcement | Why it matters |
|---|---|---|
| Explicit types | Focused source scans can verify type readability rules. | Types remain visible in code review and in plain text tools. |
| Package fixtures | Contract tests verify embedded examples and downloadable artifacts. | Consumers can reproduce behavior without relying on a live service. |
| Schema validation | Schema tests verify supported documents and registry shapes. | Implementation behavior stays aligned with the public UAI-1 contract. |
| Route contract | Site tests verify published routes, downloads, and machine assets. | Developer links stay stable and inspectable. |
| Authority boundary | Content tests keep Protocol5 implementation guidance distinct from UAIX standard authority. | Protocol5 remains an implementation hub, not the standards source. |