Publish the Promptkit engine facade

docs/policy/architecture.md

@@ -13,8 +13,8 @@ Promptkit is an importable Go library. It does not provide a runnable command,
 an HTTP service, or another application process.
 
 The module root contains package `promptkit`, which is the public facade. It
-declares the module's public package boundary but does not yet provide a usable
-exported framework API.
+provides the supported engine, configuration and source options, requests,
+results, public values, extension interfaces, profiles, and error sentinels.
 
 The implemented internal components consist of:
 
@@ -40,17 +40,19 @@ The implemented internal components consist of:
 - `internal/usecase`, which coordinates preparation and execution across the
   internal framework components.
 
-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 public
-engine has not yet been extracted.
+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.
 
-Future framework extraction must follow this dependency direction:
+The current implementation follows this dependency direction:
 
 ```text
 downstream consumers, including Scriptorium
@@ -65,16 +67,13 @@ downstream consumers, including Scriptorium
         narrow injected abstractions
 ```
 
-The facade may coordinate internal components once the public engine is
-extracted. Internal components must depend on narrow abstractions for behavior
-supplied from outside the library; they must not depend on consumers or on
-Scriptorium. This diagram is the target dependency direction for later
-extraction and does not assert that the public facade already assembles the
-implemented foundation.
+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
 
-Scriptorium is a downstream application that will consume Promptkit through
+Scriptorium is a downstream application that consumes Promptkit through
 the supported public facade. It is not a Promptkit package and must not become
 an internal dependency.
 
@@ -147,7 +146,6 @@ state.
 
 ## Current-State Maintenance
 
-This policy distinguishes present implementation from constraints on future
-framework extraction. Do not list planned packages as implemented components.
-When extraction introduces a package, update the internal inventory and the
-owning contract or subsystem document in the same change.
+Do not list planned packages as implemented components. When implementation
+introduces a package, update the internal inventory and the owning contract or
+subsystem document in the same change.