Implemented support for loading configuration from nested subdirectories
This commit is contained in:
@@ -63,7 +63,9 @@ Validation behavior:
|
||||
|
||||
## Prompt Definition Files
|
||||
|
||||
Prompt definitions are YAML files in `prompt_dir`.
|
||||
Prompt definitions are YAML files anywhere under `prompt_dir`, including nested subdirectories.
|
||||
|
||||
Subdirectories are organizational only. Callers still select prompts by the YAML `id`, not by file path. For example, `prompts/dnd/recap.yaml` may still declare `id: dnd.recap`, and callers use `--prompt dnd.recap`.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -122,7 +124,9 @@ Message rules:
|
||||
|
||||
- Repeated roles are allowed.
|
||||
- `content_file` is resolved relative to the prompt YAML file location.
|
||||
- Nested prompt files keep the same relative `content_file` behavior; `./recap.user.md` next to `dnd/recap.yaml` resolves from `dnd/`.
|
||||
- Prompt decoding is strict; unknown YAML fields are rejected.
|
||||
- Duplicate prompt IDs are invalid. If multiple files declare the requested prompt ID, Scriptorium fails instead of choosing one.
|
||||
|
||||
`output` fields:
|
||||
|
||||
@@ -138,7 +142,9 @@ Repair behavior boundary:
|
||||
|
||||
## Profile Definition Files
|
||||
|
||||
Execution profiles are YAML files in `profile_dir`.
|
||||
Execution profiles are YAML files anywhere under `profile_dir`, including nested subdirectories.
|
||||
|
||||
Subdirectories are organizational only. Callers still select profiles by the YAML `id`, not by file path. For example, `profiles/local/local-quality.yaml` may still declare `id: local-quality`, and callers use `--profile local-quality`.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -171,6 +177,7 @@ Profile rules:
|
||||
- Profile decoding is strict; unknown YAML fields are rejected.
|
||||
- Raw `api_key` is rejected; use `api_key_env`.
|
||||
- If `api_key_env` is set, that environment variable must be set when preparing/running.
|
||||
- Duplicate profile IDs are invalid. If multiple files declare the requested profile ID, Scriptorium fails instead of choosing one.
|
||||
|
||||
Current outbound request behavior:
|
||||
|
||||
@@ -184,8 +191,9 @@ Schemas are JSON files, typically in `schema_dir`.
|
||||
Rules:
|
||||
|
||||
- `output.validation_mode: json_schema` requires `output.schema_path`.
|
||||
- Relative `schema_path` values resolve from `schema_dir`.
|
||||
- Relative `schema_path` values resolve from `schema_dir`, including explicit nested paths such as `dnd/structured_events.schema.json`.
|
||||
- Absolute `schema_path` values are used directly.
|
||||
- Scriptorium does not recursively search schemas by basename; nested schemas must be referenced by their relative path.
|
||||
- Missing or invalid schema documents cause runtime validation errors.
|
||||
- Invalid generated JSON causes validation status `failed` (not a runtime error).
|
||||
|
||||
@@ -207,6 +215,14 @@ Supported artifact reference types for request inputs are `file` and `inline`.
|
||||
- Render example script: `examples/render-markdown-summary.sh`
|
||||
- HTTP request example: `examples/http-run.json`
|
||||
|
||||
Example organizational layout:
|
||||
|
||||
```text
|
||||
examples/prompts/dnd/recap.yaml
|
||||
examples/profiles/local/local-quality.yaml
|
||||
examples/schemas/dnd/structured_events.schema.json
|
||||
```
|
||||
|
||||
## Integration References
|
||||
|
||||
- [Inbound HTTP contract](integrations/http-api.md)
|
||||
|
||||
Reference in New Issue
Block a user