Architecture and Dependency Iron Rules for the Product Mainline and the Two Embeddable SDKs

Context

The repository carries both a directly deployable authorization-server product and a reusable protocol engine. Without constraining dependency direction, Domain code would be permeated by framework types and SDK consumers would be forced to pull in Drogon.

Decision

Deliver with the product as the mainline while distilling fulla::oauth2 and fulla::identity into two embeddable SDKs. The three Domain packages (common/oauth2/identity) are forbidden from including Drogon (jsoncpp is allowed); oauth2 and identity have no compile-time dependency on each other; all cross-package ports sink into common; apps/server is the sole assembly point responsible for dependency injection; tools/arch-guard enforces all of the above in CI.

Consequences and Current State

The 7 library directories under libs/ (8 CMake packages, including common/testing) and include/fulla/*/ports/ are all implemented accordingly; arch-guard (tools/arch-guard) is a CI gate. Consumers can use just the engine plus any single storage backend.