Document backend capacity management

docs/policy/architecture.md

@@ -23,6 +23,8 @@ The implemented internal components consist of:
   components;
 - `internal/backend`, which owns validated immutable OpenAI-compatible backend
   definitions and the built-in OpenRouter definition;
+- `internal/capacity`, which owns engine-local bounded run admission and
+  model-generation scheduling for limited backends;
 - `internal/defaults`, which owns application-neutral framework defaults and
   constructs the default execution target;
 - `internal/filecatalog`, which discovers YAML files and provides source-path
@@ -49,19 +51,21 @@ The `examples/go-library/prepare` and `examples/go-library/run` packages are
 maintained downstream consumers of the root facade. They do not expose library
 packages or participate in internal assembly.
 
-The root facade assembles one immutable backend registry, the internal
-repositories, renderer, validator, outbound client, and use-case runner while
-translating public values and errors at the library boundary. The registry
-contains built-ins plus validated engine-scoped consumer additions. The
-defaults and renderer depend on the domain model. Prompt-definition and
-profile repositories use the domain model, file catalog, and YAML decoder. The
-built-in profile repository supplies an embedded `fs.FS` to the profile
-package. Artifact reading uses the domain model and application-neutral
-defaults. Validation uses the domain model, file catalog, and JSON Schema
-implementation. The model client uses the domain model, application-neutral
-defaults, and an injected or standard-library HTTP client. The use-case runner
-depends on the narrow interfaces owned by each internal component, including
-backend lookup.
+The root facade assembles one immutable backend registry, one capacity manager,
+the internal repositories, renderer, validator, outbound client, and use-case
+runner while translating public values and errors at the library boundary. The
+registry contains built-ins plus validated engine-scoped consumer additions.
+The facade constructs the capacity manager from the registry's immutable
+policy snapshot, wraps the selected built-in or injected model client, and
+supplies bounded admission to the runner. The defaults and renderer depend on
+the domain model. Prompt-definition and profile repositories use the domain
+model, file catalog, and YAML decoder. The built-in profile repository supplies
+an embedded `fs.FS` to the profile package. Artifact reading uses the domain
+model and application-neutral defaults. Validation uses the domain model, file
+catalog, and JSON Schema implementation. The model client uses the domain
+model, application-neutral defaults, and an injected or standard-library HTTP
+client. The use-case runner depends on the narrow interfaces owned by each
+internal component, including backend lookup and run admission.
 
 The current implementation follows this dependency direction:
 
@@ -81,10 +85,12 @@ downstream consumers, including Scriptorium
 The backend registry depends on the domain model and shared JSON-value
 validation, has no mutation API after construction, and consumes the
 OpenAI-compatible reserved request-field rule owned by the model client. The
-model client does not depend on registry configuration. The facade coordinates
-internal components and adapts
-the supported public extension interfaces to narrow internal abstractions.
-Internal components must not depend on consumers or on Scriptorium.
+capacity component depends on the domain model and the narrow internal
+model-client boundary, not on provider transport implementation. The model
+client does not depend on registry or capacity configuration. The facade
+coordinates internal components and adapts the supported public extension
+interfaces to narrow internal abstractions. Internal components must not depend
+on consumers or on Scriptorium.
 
 ## Repository And Consumer Boundary