Harden backend contracts and documentation

This commit is contained in:
2026-07-29 17:22:55 +00:00
parent ae210b3c26
commit 359b7313f4
16 changed files with 315 additions and 113 deletions

View File

@@ -47,17 +47,19 @@ 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 the internal repositories, renderer, validator,
outbound client, and use-case runner while translating public values and
errors at the library boundary. 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.
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 current implementation follows this dependency direction:
@@ -74,11 +76,11 @@ downstream consumers, including Scriptorium
narrow injected abstractions
```
The backend registry depends on the domain model, and the model client reuses
its OpenAI-compatible reserved request-field rule. 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.
The backend registry depends on the domain model, has no mutation API after
construction, and shares its OpenAI-compatible reserved request-field rule
with the model client. 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