Document application config support

architecture.md

@@ -28,6 +28,7 @@ Scriptorium uses a ports-and-adapters architecture to decouple the core executio
 - `cmd/scriptorium`: Binary entrypoint for CLI and HTTP server.
 - `internal/domain`: Core domain contracts, including `PromptDefinition`, `ExecutionProfile`, `PreparedRun`, `RunResult`, and related metadata.
 - `internal/usecase`: `Runner` use case logic, including prompt preparation, profile selection, runtime override resolution, full run execution, validation, and bounded repair.
+- `internal/config`: Application-level config model/loader for adapter settings (for example prompt/profile/schema directories, server address, and render format default).
 - `internal/promptdef`: Repository for loading and validating Prompt Definitions from the filesystem.
 - `internal/profile`: Repository for loading Execution Profiles from the filesystem.
 - `internal/artifact`: Input artifact resolution (`inline`, `file`).
@@ -40,6 +41,28 @@ Scriptorium uses a ports-and-adapters architecture to decouple the core executio
 
 Exact package names may evolve, but the architectural boundaries should remain stable.
 
+### Application Configuration
+
+`config.yml` is adapter/application setup, not domain logic.
+
+Application config is intended for application-level settings such as:
+- `prompt_dir`
+- `profile_dir`
+- `schema_dir`
+- `server.addr`
+- `defaults.render_format`
+
+Application config precedence is:
+1. CLI flags
+2. `config.yml`
+3. Built-in application defaults
+
+Runtime model settings are intentionally separate:
+- Execution profiles and runtime overrides continue to own endpoint/model/runtime behavior.
+- `config.yml` does not replace execution profiles.
+
+The core use case (`Runner.Prepare`/`Runner.Run`) does not need to know whether adapter-level settings came from CLI flags or `config.yml`; it receives resolved dependencies and requests from adapters.
+
 ## 3. Core Execution Model
 
 Scriptorium has two closely related execution paths:
@@ -457,4 +480,4 @@ Future work should remain grounded in the current architecture:
 - **Profiles**: Support more granular profile versioning and environment-specific profiles.
 - **HTTP**: Add an HTTP prepare/render endpoint if Narratio or another caller needs it.
 
-Future render formats should plug into the formatter layer and should not require changes to the usecase layer.
+Future render formats should plug into the formatter layer and should not require changes to the usecase layer.