Document the PromptKit integration

docs/internal/cli.md

@@ -39,8 +39,10 @@ in [Configuration Internals](configuration.md).
 Configuration validation without a selected pipeline checks structural
 configuration only. Validation with a selected pipeline also builds the
 effective catalog, resolves the pipeline, and verifies explicitly selected
-Scriptorium profiles. Pipeline listing validates configuration before returning
-normalized, sorted identifiers.
+PromptKit profiles. Each explicit binding or validator profile is prepared
+against the configured PromptKit source without performing generation, so an
+unknown profile fails before pipeline preparation. Pipeline listing validates
+configuration before returning normalized, sorted identifiers.
 
 ## Production Composition
 
@@ -51,12 +53,13 @@ catalog used for resolution and the concrete constructors used for preparation.
 Tests may provide a catalog or registries instead; production code must not
 silently merge an injected partial catalog with production registrations.
 
-The production LLM factory builds the PromptKit-backed client from resolved
-configuration, creates one scheduler from the effective global LLM limit, and
-wraps the client before it reaches modules. Registration and LLM construction
-errors are returned before a pipeline is prepared. Concrete module keys and
-validator chains are public configuration choices and remain documented in
-[Configuration](../config.md).
+The production LLM factory builds one PromptKit-backed client from the resolved
+**promptkit.profile_dir** or **promptkit.profile_file** source, attaches the
+profile-provenance recorder, creates one scheduler from the effective global
+LLM limit, and wraps the client before it reaches modules. Registration and LLM
+construction errors are returned before a pipeline is prepared. Configuration
+field definitions remain in [Configuration](../config.md#promptkit-profiles);
+the adapter mechanics remain in [LLM Runtime](llm.md).
 
 ## Run Orchestration
 
@@ -68,7 +71,7 @@ handoff:
 2. create and validate a safe run identity, then allocate a debug bundle only
    when requested;
 3. build the effective catalog, resolve requested reference changes, resolve
-   the effective pipeline, and verify explicit Scriptorium profiles;
+   the effective pipeline, and verify explicit PromptKit profiles;
 4. materialize external or generated references and record redacted invocation
    and resolution provenance when debug capture is enabled;
 5. construct registries, the scheduled LLM client, prepared modules, and the

docs/internal/llm.md

@@ -6,7 +6,7 @@ provider calls, assembles registered prompt and schema assets, records selected
 profiles, and redacts provider errors. The architectural boundary is defined in
 [Architecture](../policy/architecture.md#llm-boundary); profile sources,
 credentials, and concurrency settings belong in
-[Configuration](../config.md#scriptorium-profiles) and
+[Configuration](../config.md#promptkit-profiles) and
 [Configuration](../config.md#concurrency-output-cache-and-debug).
 
 ## Structured Completion Boundary
@@ -26,16 +26,20 @@ durable schemas. Those responsibilities remain with the module and its
 
 `PromptKitClient` validates the request target and prompt identity, maps each
 named material to a PromptKit inline artifact while preserving its origin URI,
-forwards session and profile selection, then prepares and runs the prompt. It
-returns PromptKit’s validated raw bytes rather than re-encoding the decoded
-target. An empty optional material is represented as one space so its named
-input is retained by PromptKit.
+maps the request session to the existing `session_id` prompt variable, forwards
+profile selection, then prepares and runs the prompt. PromptKit v0.1.0 has no
+direct request-level session field. The adapter returns PromptKit’s validated
+raw bytes rather than re-encoding the decoded target. An empty optional
+material is represented as one space so its named input is retained by
+PromptKit.
 
 An empty request profile lets the prompt select its configured default. The CLI
 prepares every explicitly selected binding profile before a run begins, so a
 missing explicit profile fails before stage execution. Calls record the profile
 actually selected by PromptKit; the recorder deduplicates non-secret profile
-identity, provider, and model values for manifest use.
+identity, provider, and model values for manifest use. Successful completion
+responses and recorded profile manifests identify the adapter provider as
+`promptkit`.
 
 ## Shared Provider-Call Limit
 
@@ -111,6 +115,22 @@ attempt lifecycle, validation chains, and retry diagnostics; see
 [Pipeline Internals](pipeline.md#validation-retries-and-output) and the
 [binding reference](../config.md#module-bindings-and-validators).
 
+## Timeout Ownership
+
+The caller context remains the outer cancellation authority. PromptKit applies
+a positive effective generation timeout as an inner request deadline; an
+explicit zero disables only that generation deadline. The HTTP client timeout
+is a separate transport-wide cap. Notarius forwards the caller context and
+does not install another timeout wrapper around PromptKit.
+
+The selected PromptKit profile owns generation settings. Notarius binding
+retries remain outside the adapter and repeat the complete module operation
+and validation chain. PromptKit v0.1.0 does not add a provider retry loop.
+Operator-facing behavior is summarized in
+[Operations](../operations.md#operational-limits), and the pinned upstream
+contract is identified in
+[PromptKit Integration](../integrations/pkg-promptkit.md).
+
 ## Observability And Redaction
 
 When debug recording is enabled, the pipeline decorates the shared client. The