Compare commits
13 Commits
856d0852e7
...
v0.15.0
| Author | SHA1 | Date | |
|---|---|---|---|
| 9849c6bda2 | |||
| 777b727602 | |||
| 81e1ef59e6 | |||
| df762c3735 | |||
| 417522f08c | |||
| b3bb36fc86 | |||
| ba0d99f107 | |||
| 538bc27472 | |||
| 1bad076d48 | |||
| 8452b54809 | |||
| d6aecf5c50 | |||
| 83856b4de8 | |||
| 39d3508705 |
@@ -1,4 +1,6 @@
|
||||
Please review `docs/development.md` for initial orientation in this repository and follow its task-specific reading guide.
|
||||
Start with `docs/development.md` for orientation and use its policy reading guide
|
||||
to select the policies applicable to the task. Do not read the entire suite by
|
||||
default.
|
||||
|
||||
Review and follow `docs/policy/agents.md` before recommending, planning, or
|
||||
implementing changes to this repository.
|
||||
Read and follow `docs/policy/agents.md` before recommending, planning, or
|
||||
implementing repository changes.
|
||||
|
||||
10
COPYRIGHT
10
COPYRIGHT
@@ -5,7 +5,7 @@ Copyright (C) 2026 Eric Rakestraw
|
||||
SPDX-License-Identifier: GPL-3.0-or-later
|
||||
|
||||
Scriptorium is free software: you can redistribute it and/or modify it
|
||||
under the terms of the GNU Lesser General Public License as published by
|
||||
under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
@@ -14,6 +14,10 @@ The GNU General Public License version 3 is provided in LICENSE.
|
||||
Scriptorium is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU Lesser General Public License for more details.
|
||||
GNU General Public License for more details.
|
||||
|
||||
Third-party code and assets are subject to their respective license terms.
|
||||
Third-party code and assets are subject to their respective license terms.
|
||||
|
||||
Policy documents adapted from Standard Repository Policies remain licensed
|
||||
under CC-BY-SA-4.0. See docs/oss/attribution.md for the affected material,
|
||||
upstream credit, and license links.
|
||||
|
||||
@@ -6,7 +6,7 @@ OpenAI-compatible model endpoints, and returns generated output with validation
|
||||
metadata.
|
||||
|
||||
The application uses
|
||||
[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/)
|
||||
[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/)
|
||||
for prompt, profile, schema, preparation, generation, and validation behavior.
|
||||
Scriptorium owns executable configuration, CLI and HTTP mapping, process
|
||||
behavior, output presentation, and HTTP artifact-containment policy.
|
||||
@@ -39,8 +39,8 @@ a model. For complete invocation and output behavior, see the
|
||||
- [Migration from the former Go package](docs/consumers/migrating-to-promptkit.md)
|
||||
- [Subprocess integration](docs/integrations/subprocess.md)
|
||||
- [Architecture policy](docs/policy/architecture.md)
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
|
||||
- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
|
||||
- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
|
||||
|
||||
## Examples
|
||||
|
||||
@@ -52,6 +52,6 @@ a model. For complete invocation and output behavior, see the
|
||||
- [Render script](examples/render-markdown-summary.sh)
|
||||
- [HTTP request](examples/http-run.json)
|
||||
|
||||
Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
|
||||
Scriptorium is licensed under the [GPL v3.0 or later](COPYRIGHT).
|
||||
|
||||
[Open Source attribution notices](docs/oss/attribution.md) are available.
|
||||
|
||||
@@ -68,11 +68,11 @@ The optional `model` object accepts `endpoint`, `model`, `temperature`,
|
||||
`max_tokens`, `top_p`, `timeout_seconds`, `service_tier`,
|
||||
`reasoning_effort`, `api_key_env`, and `extra_params`. Numeric ranges and
|
||||
framework credential semantics are defined by the
|
||||
[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
|
||||
[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
|
||||
Explicit zero values for the numeric fields are overrides; zero
|
||||
`timeout_seconds` disables the per-attempt generation deadline only, retaining the
|
||||
request context and configured transport cap. The timeout layers are defined in
|
||||
the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
|
||||
the [Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
|
||||
Each built-in transient retry gets a fresh generation timeout; the caller's
|
||||
request context remains the outer cancellation boundary.
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ only; the caller context and configured transport cap remain active. CLI
|
||||
durations are converted to whole seconds by truncation toward zero, so any
|
||||
duration whose absolute value is below one second becomes an explicit
|
||||
zero-second override. The timeout layers are defined in the
|
||||
[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
|
||||
[Promptkit outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md#timeout-and-cancellation).
|
||||
With the built-in client, each transient retry gets a fresh generation timeout;
|
||||
this flag does not limit the complete run.
|
||||
`--run-timeout` keeps subsecond precision and starts immediately before engine
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
This is the canonical reference for Scriptorium application settings. Prompt,
|
||||
profile, schema, execution-setting, built-in profile, and framework credential
|
||||
semantics are defined by the
|
||||
[Promptkit v0.11.0 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
|
||||
[Promptkit v0.11.2 format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
|
||||
For command syntax, see the [CLI reference](cli.md); for HTTP request shapes and
|
||||
outcomes, see the [HTTP API reference](api.md).
|
||||
|
||||
@@ -26,7 +26,7 @@ The maintained [minimal configuration](../examples/config.yml),
|
||||
|
||||
## Application Configuration File
|
||||
|
||||
Configuration is decoded by ConfigKit v0.4.0 as strict YAML. Unknown fields,
|
||||
Configuration is decoded by ConfigKit v0.4.2 as strict YAML. Unknown fields,
|
||||
empty files, multiple YAML documents, and YAML aliases/anchors are rejected.
|
||||
An explicit empty string is a value: it clears a file-provided optional path
|
||||
or, for required `prompt_dir`, fails the command's prerequisite. A scalar
|
||||
@@ -152,7 +152,7 @@ parse those framework file formats.
|
||||
contracts.
|
||||
|
||||
See the
|
||||
[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
|
||||
[tagged Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
|
||||
for all of those definitions. The files under
|
||||
[`examples/prompts`](../examples/prompts/),
|
||||
[`examples/profiles`](../examples/profiles/), and
|
||||
@@ -195,7 +195,7 @@ client retains its own retry behavior. The tagged integration contract owns
|
||||
eligibility and timing.
|
||||
|
||||
Promptkit's
|
||||
[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
|
||||
[OpenAI-compatible integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
|
||||
defines outbound authentication, provider request mapping, transport limits,
|
||||
and timeout layering.
|
||||
|
||||
@@ -204,4 +204,4 @@ and timeout layering.
|
||||
- [CLI reference](cli.md)
|
||||
- [HTTP API reference](api.md)
|
||||
- [Operations guide](operations.md)
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
|
||||
|
||||
@@ -14,7 +14,7 @@ and the HTTP service according to the boundary your application needs.
|
||||
|
||||
Go applications that need an in-process prompt framework should import
|
||||
Promptkit directly. The tagged
|
||||
[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
|
||||
[Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
|
||||
owns that interface; Scriptorium does not provide a Go library package.
|
||||
Consumers arriving from the former Scriptorium Go API should follow the
|
||||
[migration guide](migrating-to-promptkit.md).
|
||||
@@ -35,4 +35,4 @@ Scriptorium does not persist run state. A retry can produce different output
|
||||
and can incur another provider request. CLI exits belong to the
|
||||
[CLI reference](../cli.md), HTTP status behavior belongs to the
|
||||
[HTTP API reference](../api.md), and framework semantics belong to
|
||||
[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
|
||||
[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Scriptorium `v0.11.1` at
|
||||
`gitea.maximumdirect.net/eric/scriptorium` is the final release that provides
|
||||
the former in-process Go framework. Promptkit `v0.11.0` at
|
||||
the former in-process Go framework. Promptkit `v0.11.1` at
|
||||
`gitea.maximumdirect.net/eric/promptkit` is the destination for that framework
|
||||
API. Scriptorium `v0.12.0` and later provide the CLI and HTTP application only.
|
||||
|
||||
@@ -19,7 +19,7 @@ Start from a clean consumer checkout and review the pending diff before
|
||||
committing it. Add the published Promptkit module:
|
||||
|
||||
```sh
|
||||
go get gitea.maximumdirect.net/eric/promptkit@v0.11.0
|
||||
go get gitea.maximumdirect.net/eric/promptkit@v0.11.1
|
||||
```
|
||||
|
||||
For an ordinary consumer that imports the former root package under its
|
||||
@@ -51,14 +51,14 @@ go mod tidy
|
||||
go test ./...
|
||||
```
|
||||
|
||||
Confirm that `go.mod` selects Promptkit `v0.11.0` and that no Go file imports
|
||||
Confirm that `go.mod` selects Promptkit `v0.11.1` and that no Go file imports
|
||||
the former Scriptorium package:
|
||||
|
||||
```sh
|
||||
test "$(
|
||||
go list -m -f '{{.Path}}@{{.Version}}' \
|
||||
gitea.maximumdirect.net/eric/promptkit
|
||||
)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.0'
|
||||
)" = 'gitea.maximumdirect.net/eric/promptkit@v0.11.1'
|
||||
if git grep -n \
|
||||
'gitea.maximumdirect.net/eric/scriptorium' \
|
||||
-- '*.go'
|
||||
@@ -73,20 +73,20 @@ fi
|
||||
Promptkit preserves the established engine, request, result, profile,
|
||||
source-option, model-client, artifact, validation-value, and public-error
|
||||
shapes where practical. Exact declarations and current behavior belong to the
|
||||
tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
|
||||
tagged [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md)
|
||||
and Go source.
|
||||
|
||||
Promptkit also includes migration-relevant public contracts that were not in
|
||||
Scriptorium `v0.11.1`:
|
||||
|
||||
- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L169-L174)
|
||||
- [`WithArtifactReader`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L169-L174)
|
||||
and the
|
||||
[`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/types.go#L315)
|
||||
[`ArtifactReader` declaration](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/types.go#L315)
|
||||
provide the artifact-reading extension described by the tagged
|
||||
[extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#extension-interfaces).
|
||||
- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/engine.go#L33-L48)
|
||||
[extension-interface guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#extension-interfaces).
|
||||
- [`ErrProfileRequired` and `ErrAPIKeyEnvMissing`](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/engine.go#L33-L48)
|
||||
provide the specific identities described by the tagged
|
||||
[error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md#handle-errors).
|
||||
[error guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.1/docs/consumers/pkg-promptkit.md#handle-errors).
|
||||
|
||||
Use those tagged owners for exact signatures, wrapping guarantees, and
|
||||
extension behavior.
|
||||
|
||||
@@ -2,23 +2,39 @@
|
||||
|
||||
This is the contributor entry point for Scriptorium. Scriptorium is an
|
||||
application that consumes the public
|
||||
[Promptkit v0.11.0 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md);
|
||||
[Promptkit v0.11.2 package](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md);
|
||||
framework implementation work belongs in Promptkit. Application configuration
|
||||
uses ConfigKit v0.4.0; keep Scriptorium's schema and source selection local.
|
||||
uses ConfigKit v0.4.2; keep Scriptorium's schema and source selection local.
|
||||
|
||||
## Initial Orientation
|
||||
|
||||
Before recommending, planning, or implementing work:
|
||||
|
||||
1. read the [agent policy](policy/agents.md);
|
||||
2. inspect the working tree and preserve unrelated changes;
|
||||
3. read the [architecture policy](policy/architecture.md);
|
||||
4. follow the task-specific contracts and internal documents below; and
|
||||
5. inspect the relevant implementation and tests before changing them.
|
||||
1. inspect the working tree and preserve unrelated changes;
|
||||
2. use the policy and task-specific reading guides below; and
|
||||
3. inspect the relevant implementation and tests before changing them.
|
||||
|
||||
Also read the [documentation policy](policy/documentation.md) before changing
|
||||
documentation and the [testing policy](policy/testing.md) before changing
|
||||
tests.
|
||||
## Policy Reading Guide
|
||||
|
||||
| Policy | Read before… |
|
||||
| --- | --- |
|
||||
| [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
|
||||
| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
|
||||
| [Architecture](policy/architecture.md) | Planning or changing application code or its structure. |
|
||||
| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
|
||||
| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
|
||||
| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
|
||||
| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
|
||||
|
||||
- Read applicable policies before making decisions they govern; multiple policies
|
||||
may apply.
|
||||
- Select policies using the task triggers above. Follow cross-references to
|
||||
relevant sections when needed to resolve a concrete question.
|
||||
- Reuse policies already available in context; reread when changed or no longer
|
||||
available.
|
||||
- Expand reading when the task's scope expands.
|
||||
- When revising a policy itself, read that policy and any provisions elsewhere
|
||||
affected by the revision.
|
||||
|
||||
## Task-Specific Reading Guide
|
||||
|
||||
@@ -29,13 +45,13 @@ tests.
|
||||
| HTTP routes, DTOs, limits, status mapping, or artifact policy | [HTTP API contract](api.md), [adapter internals](internal/adapters.md), and [source internals](internal/sources.md) |
|
||||
| Application configuration or precedence | [Configuration contract](config.md), [adapter internals](internal/adapters.md), [source internals](internal/sources.md), and `internal/config` definition/load tests |
|
||||
| Prepared-run presentation | [CLI contract](cli.md), [adapter internals](internal/adapters.md), and `internal/format` |
|
||||
| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md) |
|
||||
| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md) |
|
||||
| Prompt, profile, schema, generation, or validation semantics | [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md) and the [Promptkit consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md) |
|
||||
| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md) |
|
||||
| Subprocess behavior | [Subprocess integration](integrations/subprocess.md) and [CLI contract](cli.md) |
|
||||
| Runtime operation or recovery | [Operations](operations.md) |
|
||||
| Dependencies, copied assets, or attribution | The [OSS policy](policy/oss.md), [component attributions](oss/attribution.md), and [architecture policy](policy/architecture.md) |
|
||||
| Release documentation, packaging, or publication | The [release policy](policy/release.md), [OSS policy](policy/oss.md), [release procedure](release.md), [hosted release workflow](../.woodpecker/release.yml), and [architecture policy](policy/architecture.md) |
|
||||
| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md), and the related files under `examples/` |
|
||||
| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md), and the related files under `examples/` |
|
||||
| Architecture decisions or future work | The [documentation policy](policy/documentation.md), relevant accepted ADRs, and relevant roadmap documents |
|
||||
|
||||
Cross-project changes land and release in Promptkit before Scriptorium adopts
|
||||
|
||||
@@ -9,7 +9,7 @@ own IO and presentation mechanics, not framework decisions.
|
||||
External contracts are canonical in the [CLI reference](../cli.md) and
|
||||
[HTTP API reference](../api.md). Promptkit's public engine contract is
|
||||
described by its tagged
|
||||
[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md).
|
||||
[Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md).
|
||||
|
||||
## Components And Collaborators
|
||||
|
||||
|
||||
@@ -15,5 +15,5 @@ public behavior belongs in the linked contracts.
|
||||
| `internal/report` | Projects one terminal Promptkit observation into Scriptorium-owned execution metadata. | [adapter internals](adapters.md) |
|
||||
|
||||
Framework implementation packages are provided by
|
||||
[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
|
||||
[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
|
||||
and are not part of this repository.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
This document covers Scriptorium-owned source locations and the restricted HTTP
|
||||
artifact reader. Prompt, profile, schema, and ordinary artifact semantics are
|
||||
owned by the tagged
|
||||
[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md).
|
||||
[Promptkit format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md).
|
||||
|
||||
## Application Source Locations
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ fields, or HTTP wire behavior.
|
||||
- [CLI reference](cli.md): commands, output destinations, and exit codes.
|
||||
- [Configuration reference](config.md): application settings, source
|
||||
locations, defaults, and credential mapping.
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md):
|
||||
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md):
|
||||
prompt, profile, schema, execution-setting, and framework credential
|
||||
contracts.
|
||||
- [HTTP API reference](api.md): route, request/response schema, status codes,
|
||||
@@ -150,7 +150,7 @@ setting and then Promptkit's default, while explicit zero disables additional
|
||||
attempts. Existing generation timeouts apply
|
||||
per attempt, while the caller context covers the complete operation. Provider
|
||||
`Retry-After` timing can exceed Promptkit's ordinary backoff cap; consult the
|
||||
[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
|
||||
[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
|
||||
for details.
|
||||
|
||||
CLI `run` can set a [whole-run deadline](cli.md) when total execution time must
|
||||
|
||||
@@ -1,91 +1,110 @@
|
||||
# Open-Source Attribution
|
||||
# Open Source Attribution Notices
|
||||
|
||||
Scriptorium's own terms are in the repository [LICENSE](../../LICENSE).
|
||||
The [OSS policy](../policy/oss.md) governs these entries. Dependency versions
|
||||
are recorded in [go.mod](../../go.mod) and [go.sum](../../go.sum); source and
|
||||
notice links below identify the exact commits for the selected versions.
|
||||
## Standard Repository Policies
|
||||
|
||||
Material: `docs/policy/oss.md`, `docs/policy/meta.md`,
|
||||
`docs/policy/agents.md`, `docs/policy/documentation.md`,
|
||||
`docs/policy/architecture.md`, `docs/policy/testing.md`,
|
||||
`docs/policy/release.md`, `AGENTS.md`, and the
|
||||
Policy Reading Guide section of `docs/development.md`, adapted for this
|
||||
repository.
|
||||
|
||||
Copyright (C) 2026 Eric Rakestraw
|
||||
|
||||
SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
|
||||
License and notices: [CC BY-SA 4.0](licenses/CC-BY-SA-4.0.txt) |
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/COPYRIGHT) |
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/LICENSE).
|
||||
|
||||
[Source](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843).
|
||||
|
||||
## Promptkit
|
||||
|
||||
Selected module: `gitea.maximumdirect.net/eric/promptkit` at `v0.11.2`.
|
||||
|
||||
Copyright (C) 2026 Eric Rakestraw
|
||||
|
||||
SPDX-License-Identifier: LGPL-3.0-or-later
|
||||
|
||||
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
|
||||
[GPL v3 companion](licenses/GPL-3.0.txt) |
|
||||
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d/LICENSE)
|
||||
License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
|
||||
[GPL 3.0](licenses/GPL-3.0.txt) |
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/COPYRIGHT) |
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2/LICENSE).
|
||||
|
||||
Source: [Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d)
|
||||
[Source](https://gitea.maximumdirect.net/eric/promptkit/src/commit/12d6d80024e80c552d122a076c22429bf6f2f6c2).
|
||||
|
||||
## ConfigKit
|
||||
|
||||
Upstream copyright statement: no project-specific statement is present in the
|
||||
selected module; the FSF copyright in its license text belongs to that license
|
||||
document and is not substituted for a project notice.
|
||||
Selected module: `gitea.maximumdirect.net/eric/ConfigKit` at `v0.4.2`.
|
||||
|
||||
SPDX-License-Identifier: LGPL-3.0-only
|
||||
Copyright (C) 2026 Eric Rakestraw
|
||||
|
||||
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
|
||||
[GPL v3 companion](licenses/GPL-3.0.txt) |
|
||||
[upstream LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258/LICENSE)
|
||||
SPDX-License-Identifier: LGPL-3.0-or-later
|
||||
|
||||
Source: [ConfigKit v0.4.0](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/e6ced0d3d1194b58e0b3dc8970089471ba175258)
|
||||
License and notices: [LGPL 3.0](licenses/LGPL-3.0.txt) |
|
||||
[GPL 3.0](licenses/GPL-3.0.txt) |
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/COPYRIGHT) |
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f/LICENSE).
|
||||
|
||||
[Source](https://gitea.maximumdirect.net/eric/ConfigKit/src/commit/67c03690181c5af8dde6be325abac241dae6732f).
|
||||
|
||||
## Promptkit OpenRouter Catalog
|
||||
|
||||
Upstream copyright statement: no project-specific statement is present in the
|
||||
selected module. The linked upstream README records the profile assets'
|
||||
Promptkit origin and the copyright holder's deliberate relicensing.
|
||||
Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2` at `v2.20260926.0`.
|
||||
|
||||
SPDX-License-Identifier: LGPL-3.0-only
|
||||
Copyright (C) 2026 Eric Rakestraw
|
||||
|
||||
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
|
||||
[GPL v3 companion](licenses/GPL-3.0.txt) |
|
||||
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/LICENSE) |
|
||||
[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/README.md)
|
||||
SPDX-License-Identifier: MIT
|
||||
|
||||
Source: [OpenRouter catalog v2.20260922.1](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab)
|
||||
License and notices: [MIT](licenses/MIT.txt) |
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/COPYRIGHT) |
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3/LICENSE).
|
||||
|
||||
[Source](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/4f731d217e0bc39151c010f50fb5912706e7b6b3).
|
||||
|
||||
## Promptkit Rakestrawhome Catalog
|
||||
|
||||
Upstream copyright statement: no project-specific statement is present in the
|
||||
selected module. The linked upstream README records the profile asset's
|
||||
Promptkit origin and the copyright holder's deliberate relicensing.
|
||||
Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2` at `v2.20260926.0`.
|
||||
|
||||
SPDX-License-Identifier: LGPL-3.0-only
|
||||
Copyright (C) 2026 Eric Rakestraw
|
||||
|
||||
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
|
||||
[GPL v3 companion](licenses/GPL-3.0.txt) |
|
||||
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/LICENSE) |
|
||||
[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/README.md)
|
||||
SPDX-License-Identifier: MIT
|
||||
|
||||
Source: [Rakestrawhome catalog v2.20260922.0](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226)
|
||||
License and notices: [MIT](licenses/MIT.txt) |
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/COPYRIGHT) |
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596/LICENSE).
|
||||
|
||||
[Source](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/48918a3ad39fd99843cda94a86133b1b3881d596).
|
||||
|
||||
## jsonschema/v6
|
||||
|
||||
Upstream copyright statement: no project-specific statement is present in the
|
||||
selected module; no substitute statement is inferred here.
|
||||
Selected module: `github.com/santhosh-tekuri/jsonschema/v6` at `v6.0.2`.
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
|
||||
License and notices: [Apache 2.0](licenses/Apache-2.0.txt) |
|
||||
[upstream LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE)
|
||||
[LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE).
|
||||
|
||||
Source: [jsonschema/v6 v6.0.2](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71)
|
||||
[Source](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71).
|
||||
|
||||
## golang.org/x/text
|
||||
|
||||
Selected module: `golang.org/x/text` at `v0.14.0`.
|
||||
|
||||
Copyright (c) 2009 The Go Authors. All rights reserved.
|
||||
|
||||
SPDX-License-Identifier: BSD-3-Clause
|
||||
|
||||
License and notices: [BSD 3-Clause](licenses/BSD-3-Clause.txt) |
|
||||
[upstream LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE)
|
||||
[LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE).
|
||||
|
||||
Source: [golang.org/x/text v0.14.0](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353)
|
||||
[Source](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353).
|
||||
|
||||
## gopkg.in/yaml.v3
|
||||
|
||||
Selected module: `gopkg.in/yaml.v3` at `v3.0.1`.
|
||||
|
||||
Copyright (c) 2006-2010 Kirill Simonov
|
||||
|
||||
Copyright (c) 2006-2011 Kirill Simonov
|
||||
@@ -96,18 +115,17 @@ Copyright 2011-2016 Canonical Ltd.
|
||||
|
||||
SPDX-License-Identifier: MIT AND Apache-2.0
|
||||
|
||||
The upstream LICENSE assigns MIT to files ported from libyaml and Apache 2.0
|
||||
to the remaining files; these are file-specific terms, not alternatives.
|
||||
|
||||
License and notices: [MIT](licenses/MIT.txt) |
|
||||
[Apache 2.0](licenses/Apache-2.0.txt) |
|
||||
[upstream LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
|
||||
[upstream NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE)
|
||||
[LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
|
||||
[NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE).
|
||||
|
||||
Source: [gopkg.in/yaml.v3 v3.0.1](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51)
|
||||
[Source](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51).
|
||||
|
||||
## go.yaml.in/yaml/v4
|
||||
|
||||
Selected module: `go.yaml.in/yaml/v4` at `v4.0.0-rc.6`.
|
||||
|
||||
Copyright 2006-2010 Kirill Simonov
|
||||
|
||||
Copyright 2011-2019 Canonical Ltd
|
||||
@@ -116,12 +134,9 @@ Copyright 2025 The go-yaml Project Contributors
|
||||
|
||||
SPDX-License-Identifier: MIT AND Apache-2.0
|
||||
|
||||
The upstream NOTICE assigns MIT to files ported from libyaml and Apache 2.0
|
||||
to the remaining files; these are file-specific terms, not alternatives.
|
||||
|
||||
License and notices: [MIT](licenses/MIT.txt) |
|
||||
[Apache 2.0](licenses/Apache-2.0.txt) |
|
||||
[upstream LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
|
||||
[upstream NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE)
|
||||
[LICENSE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/LICENSE) |
|
||||
[NOTICE](https://github.com/yaml/go-yaml/blob/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125/NOTICE).
|
||||
|
||||
Source: [go.yaml.in/yaml/v4 v4.0.0-rc.6](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125)
|
||||
[Source](https://github.com/yaml/go-yaml/tree/1c17b9cee72bf81ae73a8be50fbd7dd3a9985125).
|
||||
|
||||
170
docs/oss/licenses/CC-BY-SA-4.0.txt
Normal file
170
docs/oss/licenses/CC-BY-SA-4.0.txt
Normal file
@@ -0,0 +1,170 @@
|
||||
Creative Commons Attribution-ShareAlike 4.0 International
|
||||
|
||||
Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
|
||||
|
||||
Using Creative Commons Public Licenses
|
||||
|
||||
Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
|
||||
|
||||
Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
|
||||
|
||||
Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described.
|
||||
|
||||
Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
|
||||
|
||||
Creative Commons Attribution-ShareAlike 4.0 International Public License
|
||||
|
||||
By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
|
||||
|
||||
Section 1 – Definitions.
|
||||
|
||||
a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
|
||||
|
||||
b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
|
||||
|
||||
c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.
|
||||
|
||||
d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
|
||||
|
||||
e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
|
||||
|
||||
f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
|
||||
|
||||
g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
|
||||
|
||||
h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
|
||||
|
||||
i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
|
||||
|
||||
j. Licensor means the individual(s) or entity(ies) granting rights under this Public License.
|
||||
|
||||
k. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
|
||||
|
||||
l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
|
||||
|
||||
m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
|
||||
|
||||
Section 2 – Scope.
|
||||
|
||||
a. License grant.
|
||||
|
||||
1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
|
||||
|
||||
A. reproduce and Share the Licensed Material, in whole or in part; and
|
||||
|
||||
B. produce, reproduce, and Share Adapted Material.
|
||||
|
||||
2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
|
||||
|
||||
3. Term. The term of this Public License is specified in Section 6(a).
|
||||
|
||||
4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
|
||||
|
||||
5. Downstream recipients.
|
||||
|
||||
A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
|
||||
|
||||
B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
|
||||
|
||||
C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
|
||||
|
||||
6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
|
||||
|
||||
b. Other rights.
|
||||
|
||||
1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
|
||||
|
||||
2. Patent and trademark rights are not licensed under this Public License.
|
||||
|
||||
3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
|
||||
|
||||
Section 3 – License Conditions.
|
||||
|
||||
Your exercise of the Licensed Rights is expressly made subject to the following conditions.
|
||||
|
||||
a. Attribution.
|
||||
|
||||
1. If You Share the Licensed Material (including in modified form), You must:
|
||||
|
||||
A. retain the following if it is supplied by the Licensor with the Licensed Material:
|
||||
|
||||
i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
|
||||
|
||||
ii. a copyright notice;
|
||||
|
||||
iii. a notice that refers to this Public License;
|
||||
|
||||
iv. a notice that refers to the disclaimer of warranties;
|
||||
|
||||
v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
|
||||
|
||||
B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
|
||||
|
||||
C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
|
||||
|
||||
2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
|
||||
|
||||
3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
|
||||
|
||||
b. ShareAlike.In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
|
||||
|
||||
1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
|
||||
|
||||
2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
|
||||
|
||||
3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
|
||||
|
||||
Section 4 – Sui Generis Database Rights.
|
||||
|
||||
Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
|
||||
|
||||
a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
|
||||
|
||||
b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
|
||||
|
||||
c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
|
||||
For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
|
||||
|
||||
Section 5 – Disclaimer of Warranties and Limitation of Liability.
|
||||
|
||||
a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
|
||||
|
||||
b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
|
||||
|
||||
c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
|
||||
|
||||
Section 6 – Term and Termination.
|
||||
|
||||
a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
|
||||
|
||||
b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
|
||||
|
||||
1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
|
||||
|
||||
2. upon express reinstatement by the Licensor.
|
||||
|
||||
c. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
|
||||
|
||||
d. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
|
||||
|
||||
e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
|
||||
|
||||
Section 7 – Other Terms and Conditions.
|
||||
|
||||
a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
|
||||
|
||||
b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
|
||||
|
||||
Section 8 – Interpretation.
|
||||
|
||||
a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
|
||||
|
||||
b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
|
||||
|
||||
c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
|
||||
|
||||
d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
|
||||
|
||||
Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
|
||||
|
||||
Creative Commons may be contacted at creativecommons.org.
|
||||
@@ -1,12 +1,14 @@
|
||||
# Agent Policy
|
||||
|
||||
**Base Policy Version:** 1.1
|
||||
**Base Policy Version:** 1.3
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md
|
||||
|
||||
## Purpose
|
||||
|
||||
Agents working in this repository must read and adhere to the following house rules.
|
||||
Agents must read and follow these rules.
|
||||
|
||||
## Implementation Discipline
|
||||
|
||||
@@ -43,15 +45,15 @@ unless that behavior was expressly selected as part of the contract.
|
||||
|
||||
## Git Commit Policy
|
||||
|
||||
By default, create a commit after completing each coherent unit of work, using a
|
||||
By default, commit each completed, nonempty unit of work using a
|
||||
concise, plain-English message describing what changed. This policy is standing
|
||||
authorization to create those local commits; a separate user request is not
|
||||
required. An explicit user instruction to leave work uncommitted takes precedence.
|
||||
|
||||
A unit of work is a focused, reviewable outcome, including its relevant tests and
|
||||
documentation. Do not commit after every intermediate edit or create empty commits.
|
||||
documentation.
|
||||
Complete the appropriate validation before committing. If work is incomplete or
|
||||
validation is blocked, report that state rather than presenting it as completed.
|
||||
validation is blocked, report that state accurately.
|
||||
|
||||
Before committing:
|
||||
|
||||
@@ -59,10 +61,10 @@ Before committing:
|
||||
changes. Identify changes that predate the current unit of work.
|
||||
2. Exclude secrets, local environment files, generated junk, and unrelated changes.
|
||||
3. Stage only the files or hunks belonging to the completed unit. Use `git add .`
|
||||
only when every included change belongs to that unit. Do not disturb unrelated
|
||||
staged or unstaged work.
|
||||
4. Review `git diff --staged` and run appropriate checks for the change. Do not
|
||||
repeat checks already passed for unchanged content merely to create a commit.
|
||||
only when every included change belongs to that unit. Preserve unrelated
|
||||
staged and unstaged work.
|
||||
4. Review `git diff --staged` and run appropriate checks for the change. Reuse
|
||||
successful checks for unchanged content.
|
||||
5. Review `git log --oneline -n 10` and use
|
||||
`git commit -m "<concise plain-English commit message>"`.
|
||||
6. Report the commit identifier and any remaining uncommitted work.
|
||||
|
||||
@@ -1,147 +1,110 @@
|
||||
# Architecture Policy
|
||||
|
||||
**Base Policy Version:** 1.1
|
||||
**Base Policy Version:** 1.3
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md
|
||||
|
||||
## Purpose And Ownership
|
||||
|
||||
This policy defines Scriptorium's purpose, responsibility and dependency
|
||||
boundaries, established invariants, and non-goals. Concrete component inventory
|
||||
and implementation mechanics belong in [internal documentation](../internal/overview.md);
|
||||
public behavior belongs in its canonical contracts.
|
||||
The adopted policy defines the application's purpose and the architectural
|
||||
constraints contributors must follow. It owns system boundaries, responsibility
|
||||
and dependency rules, established invariants, and explicit non-goals.
|
||||
|
||||
Adopted constraints govern future development without implying that every
|
||||
capability they could govern exists or is planned. Keep proposed structure and
|
||||
implementation status in roadmaps, and decision rationale in ADRs. Acceptance
|
||||
of a decision is not proof of implementation. Do not turn incidental choices
|
||||
into architectural invariants.
|
||||
Describe the concrete package inventory and implementation mechanics in internal
|
||||
documentation. Link to canonical public contracts for their exact behavior and
|
||||
to ADRs for decision rationale.
|
||||
|
||||
## System Shape
|
||||
## Architectural Approach
|
||||
|
||||
Scriptorium is an executable application with four command entry paths: CLI
|
||||
`run`, CLI `render`, CLI `inspect`, and the HTTP service started by `serve`.
|
||||
The `inspect` command has prompt and profile modes. Scriptorium does not expose
|
||||
a reusable root Go package.
|
||||
Hexagonal architecture is strongly recommended, including encapsulating external
|
||||
integrations and APIs within internal adapters. Keep domain and application
|
||||
logic independent of external integration details, and make dependency direction
|
||||
clear in the adopted policy.
|
||||
|
||||
The application consumes
|
||||
[Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
|
||||
through its supported root package. Promptkit owns prompt execution,
|
||||
preparation, source formats, built-in profiles, model-client behavior, and
|
||||
validation. Scriptorium owns application configuration, executable adapters,
|
||||
prepared-run and definition-inspection presentation, process behavior, and HTTP
|
||||
deployment policy.
|
||||
Implement that separation with proportionate, idiomatic code. Choose interfaces
|
||||
and package layout to serve the application's actual boundaries. Use adapters
|
||||
for collaborators with external integration responsibilities.
|
||||
|
||||
Scriptorium also consumes ConfigKit v0.4.0 for application configuration
|
||||
decoding, resolution, and validation flow. Scriptorium owns its application
|
||||
schema, defaults, normalization, validation rules, source selection, and CLI
|
||||
flag mapping; ConfigKit does not own Promptkit framework sources or HTTP
|
||||
artifact containment.
|
||||
## Adopted Constraints And Implemented Structure
|
||||
|
||||
The concrete package inventory is maintained in the
|
||||
[internal overview](../internal/overview.md).
|
||||
Architectural constraints govern current and future development. Record
|
||||
implemented structure accurately, proposals and implementation status in the
|
||||
roadmap, and significant decisions and rationale in ADRs. Describe a target
|
||||
structure as implemented when its changes land.
|
||||
|
||||
As established by [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium
|
||||
aims to support the complete set of features in valid Promptkit prompt and
|
||||
profile definitions for its selected upstream version. Promptkit remains the
|
||||
canonical parser and validator. Library-only features are considered
|
||||
individually against the simple predefined-prompt execution model.
|
||||
Constraints must reflect deliberately selected requirements and decisions.
|
||||
Do not promote incidental implementation choices into architectural invariants.
|
||||
|
||||
Maintain adapter boundaries with proportionate, idiomatic code. This approach
|
||||
does not require an interface for every type, additional wrappers, or a fixed
|
||||
directory tree for integrations that do not exist.
|
||||
## Scriptorium's Purpose And System Shape
|
||||
|
||||
## Dependency Direction
|
||||
Scriptorium is an executable application with CLI `run`, `render`,
|
||||
`inspect`, and `config` command families and an HTTP service started by
|
||||
`serve`. It offers simple, request-independent execution of predefined
|
||||
prompts, not a reusable Scriptorium root Go API or a workflow framework.
|
||||
The [internal overview](../internal/overview.md) owns the concrete package
|
||||
inventory; [adapter internals](../internal/adapters.md) and
|
||||
[source internals](../internal/sources.md) own implementation mechanics.
|
||||
|
||||
```text
|
||||
cmd/scriptorium
|
||||
|
|
||||
v
|
||||
CLI and HTTP adapters, configuration, defaults, and formatting
|
||||
|
|
||||
v
|
||||
Promptkit (execution) and ConfigKit (application configuration)
|
||||
```
|
||||
## Framework And Application Boundaries
|
||||
|
||||
- Retained application packages may import Promptkit's root package.
|
||||
- They must not import Promptkit `internal` packages.
|
||||
- They must not import Promptkit catalog modules directly.
|
||||
- They must not import the removed Scriptorium root facade or recreate former
|
||||
framework package families.
|
||||
- Adapter-owned interfaces use Promptkit public values when a consumer-side
|
||||
substitution boundary is needed.
|
||||
- Scriptorium passes omitted framework settings as zero values so Promptkit
|
||||
applies its own defaults.
|
||||
Scriptorium consumes
|
||||
[Promptkit v0.11.2](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/consumers/pkg-promptkit.md)
|
||||
through its supported public root package. Promptkit owns prompt execution,
|
||||
preparation, prompt and profile formats, built-in profiles, model-client
|
||||
behavior, validation, and framework defaults. Scriptorium owns application
|
||||
configuration, executable CLI and HTTP adapters, prepared-run and
|
||||
definition-inspection presentation, process behavior, and HTTP deployment
|
||||
policy. The [format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/formats.md)
|
||||
and [outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.2/docs/integrations/openai-compatible-chat.md)
|
||||
remain Promptkit's contracts.
|
||||
|
||||
The repository architecture guard enforces these import and removal
|
||||
invariants.
|
||||
Scriptorium uses ConfigKit v0.4.2 for strict application YAML decoding,
|
||||
resolution, and validation flow. Scriptorium retains its application schema,
|
||||
defaults, normalization, validation rules, source selection, and CLI override
|
||||
mapping. ConfigKit does not own Promptkit framework sources or HTTP artifact
|
||||
containment. The [configuration contract](../config.md) owns externally
|
||||
observable configuration behavior.
|
||||
|
||||
Cross-project changes land and release in Promptkit before Scriptorium adopts
|
||||
the tagged dependency. Do not commit Go workspaces, local replacements,
|
||||
vendored Promptkit implementation, or unpublished dependency assumptions.
|
||||
Application code may import Promptkit's public root package, but not its
|
||||
`internal` packages or catalog modules. It must not recreate the removed
|
||||
Scriptorium framework facade or former framework package families.
|
||||
Adapter-owned interfaces use Promptkit public values when a consumer-side
|
||||
substitution boundary is needed. Omitted framework settings pass as zero
|
||||
values so Promptkit applies its own defaults. Cross-project changes land and
|
||||
release in Promptkit before
|
||||
Scriptorium adopts its tagged dependency; do not commit Go workspaces, local
|
||||
replacements, vendored Promptkit source, or unpublished dependency assumptions.
|
||||
The repository's architecture guard protects these import and removal
|
||||
boundaries. Adapter separation does not require an interface for every type,
|
||||
extra wrappers, or a fixed directory tree.
|
||||
|
||||
## Retained Boundaries
|
||||
## Definition Support And Request State
|
||||
|
||||
- `internal/adapter/cli` owns commands, flags, configuration precedence,
|
||||
process streams, output files, summaries, and exit codes.
|
||||
- `internal/adapter/http` owns routes, strict JSON DTOs, size limits, response
|
||||
mapping, status mapping, and the restricted artifact reader.
|
||||
- `internal/config` owns discovery and Scriptorium's application definition;
|
||||
ConfigKit owns strict YAML decoding and the load/override pipeline.
|
||||
- `internal/defaults` owns Scriptorium application and HTTP defaults only.
|
||||
- `internal/format` owns deterministic prepared-run and definition-inspection
|
||||
text and JSON presentation.
|
||||
- Promptkit owns framework orchestration and contracts. Its
|
||||
[format reference](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
|
||||
and
|
||||
[outbound integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md)
|
||||
are canonical.
|
||||
As decided in [ADR 0004](../adr/0004-definition-boundary.md), Scriptorium aims
|
||||
to support the complete set of features in valid Promptkit prompt and profile
|
||||
definitions for its selected upstream version. Promptkit remains the canonical
|
||||
parser and validator. Library-only features are considered individually
|
||||
against Scriptorium's simple predefined-prompt execution model.
|
||||
|
||||
## HTTP Artifact Security Boundary
|
||||
|
||||
Ordinary CLI file loading is provided by Promptkit. Scriptorium's HTTP adapter
|
||||
injects a restricted `promptkit.ArtifactReader` for inbound HTTP requests.
|
||||
That reader denies file references without an artifact root, enforces the
|
||||
configured byte limit, and applies Scriptorium's lexical root-containment rule.
|
||||
The operating system still follows symlinks after the lexical check.
|
||||
|
||||
This boundary handles untrusted request references under the documented
|
||||
deployment model; it is not a filesystem sandbox. Defending against a
|
||||
privileged actor concurrently modifying the host filesystem is outside the
|
||||
adopted scope, not a claim that such activity cannot occur. Do not infer
|
||||
additional defenses or guarantees from hypothetical threats; raise unsettled
|
||||
scope decisions under the [agent policy](agents.md).
|
||||
|
||||
The [HTTP API](../api.md) owns observable request outcomes, and
|
||||
[operations](../operations.md) owns deployment permissions and root selection.
|
||||
|
||||
## State, Errors, And Secrets
|
||||
|
||||
Scriptorium has no durable run-state store, checkpoint, cache, or resume
|
||||
mechanism. Recovery is a new request after correcting inputs, configuration, or
|
||||
environment.
|
||||
|
||||
Each request is self-contained from the caller's perspective, without
|
||||
conversation or workflow state retained from completed requests. This does
|
||||
not mean the process is internally stateless. Shared engines, backend capacity
|
||||
and queue accounting, in-flight coordination, cancellation, and server
|
||||
lifecycle resources are permitted and must be shared where necessary to
|
||||
enforce configured backend limits across concurrent requests. Such state must
|
||||
be concurrency-safe and does not create a durable user-workflow contract.
|
||||
|
||||
Adapters map Promptkit public error identities into CLI exits or HTTP statuses
|
||||
without classifying by message text. Raw API keys are not accepted in
|
||||
Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
|
||||
External YAML and JSON decoding remains strict. Adapters map external values
|
||||
through Promptkit public requests and results without taking over framework
|
||||
orchestration. Explicit numeric request overrides preserve presence, including
|
||||
zero. Adapters map Promptkit public error identities to CLI exits or HTTP
|
||||
statuses without classifying by message text. Raw API keys are not accepted
|
||||
in Scriptorium configuration, CLI arguments, or HTTP payloads, and resolved
|
||||
secrets must not be emitted.
|
||||
|
||||
## Architectural Invariants
|
||||
|
||||
- External YAML and JSON decoding remains strict.
|
||||
- CLI and HTTP behavior remains presentation and transport logic rather than
|
||||
framework orchestration.
|
||||
- Explicit numeric request overrides preserve presence, including zero.
|
||||
- HTTP artifact containment and byte limits remain Scriptorium policy.
|
||||
- No application package depends on Promptkit implementation packages.
|
||||
Each execution request is self-contained from the caller's perspective; no
|
||||
conversation or workflow state is retained from completed requests. This
|
||||
does not preclude process-scoped operational state. A server shares its
|
||||
Promptkit engine, backend registry, capacity admission and queue accounting
|
||||
across relevant concurrent requests so configured backend limits cannot be
|
||||
bypassed by per-request construction. In-flight coordination, cancellation,
|
||||
and server lifecycle state must be concurrency-safe. None of this creates a
|
||||
durable workflow, checkpoint, cache, or resume contract; recovery is a new
|
||||
request after correcting inputs, configuration, or environment.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
@@ -153,5 +116,19 @@ secrets must not be emitted.
|
||||
- Do not add durable workflow, archive, or resume behavior.
|
||||
- Do not add application-managed prompt modification, follow-up message flows,
|
||||
conversation management, or multi-step workflow orchestration.
|
||||
## Trust Boundaries And Threat Scope
|
||||
|
||||
Work that is not implemented belongs in `docs/roadmap/`.
|
||||
Ordinary CLI file loading belongs to Promptkit. For untrusted inbound HTTP
|
||||
artifact references, Scriptorium injects a restricted
|
||||
`promptkit.ArtifactReader`. It denies file references without an artifact
|
||||
root, applies the configured byte limit, and enforces lexical root containment.
|
||||
The operating system follows symlinks after that lexical check. This is not a
|
||||
filesystem sandbox or a defense against a privileged actor concurrently
|
||||
modifying the host filesystem; that threat is outside the adopted scope.
|
||||
Do not infer stronger defenses from hypothetical threats. Raise unsettled
|
||||
scope decisions under the [agent policy](agents.md).
|
||||
|
||||
The [HTTP API](../api.md) owns observable request outcomes, the
|
||||
[configuration contract](../config.md) owns credential supply, and
|
||||
[operations](../operations.md) owns deployment permissions and root selection.
|
||||
The [source internals](../internal/sources.md) describe reader mechanics.
|
||||
|
||||
@@ -1,15 +1,16 @@
|
||||
# Documentation Policy
|
||||
|
||||
**Base Policy Version:** 1.4
|
||||
**Base Policy Version:** 1.11
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md
|
||||
|
||||
## Purpose
|
||||
|
||||
This policy assigns each documentation topic to one canonical owner. Its goal is
|
||||
to keep this repository's documentation accurate, concise, discoverable, and
|
||||
resistant to drift for users, operators, developers, integrators, and LLM
|
||||
coding agents.
|
||||
to keep this application's documentation accurate, concise, discoverable, and resistant
|
||||
to drift for users, operators, developers, integrators, and LLM coding agents.
|
||||
|
||||
## Core Rules
|
||||
|
||||
@@ -17,45 +18,38 @@ coding agents.
|
||||
|
||||
Each authoritative fact belongs in one document. A non-owning document may give
|
||||
a short, stable summary for orientation, but it must link to the canonical owner
|
||||
instead of repeating volatile details.
|
||||
for volatile details.
|
||||
|
||||
Volatile details include commands, flags, configuration fields and defaults,
|
||||
module keys, schemas, file names, paths, status codes, retry behavior, and
|
||||
runtime guarantees. If readers could reasonably treat a statement as a
|
||||
contract, maintain it only in the owning document.
|
||||
|
||||
Minimal tested usage examples are allowed outside the owning contract when this
|
||||
policy assigns them an orientation or instructional purpose. They must link to
|
||||
the canonical contract and must not redefine complete syntax, defaults, or
|
||||
semantics.
|
||||
|
||||
### Current And Future Behavior
|
||||
|
||||
Outside `docs/roadmap/`, documentation describes implemented behavior only.
|
||||
Partial features may be described only to their implemented boundary.
|
||||
|
||||
Architectural constraints may govern future changes without implying that the
|
||||
components or capabilities they would govern already exist. This does not
|
||||
permit describing a proposed system structure as implemented.
|
||||
Architectural constraints may govern future changes. Describe current structure
|
||||
from implemented behavior.
|
||||
|
||||
ADRs may record an accepted architectural decision before implementation, but
|
||||
acceptance must not be presented as proof that the behavior exists. The roadmap
|
||||
owns implementation status and sequencing until the decision is implemented.
|
||||
Current architecture, user, operator,
|
||||
integration, and internal documentation are updated when the behavior lands.
|
||||
ADRs may record an accepted architectural decision before implementation. The
|
||||
roadmap owns implementation status and sequencing until the decision is
|
||||
implemented. Current architecture, user, operator, integration, and internal
|
||||
documentation are updated when the behavior lands.
|
||||
|
||||
### Audience And Detail
|
||||
|
||||
Write for the document's stated audience and include only the detail needed for
|
||||
its owned topic. User and operator docs should not expose implementation detail.
|
||||
Developer docs should link to user-facing and external contracts rather than
|
||||
restate them.
|
||||
its owned topic. Keep user and operator docs focused on using and operating the
|
||||
application. Developer docs should link to user-facing and external contracts
|
||||
for their definitions.
|
||||
|
||||
### Examples
|
||||
|
||||
Complete copyable files belong in `examples/`. Documentation may use the
|
||||
smallest illustrative snippet needed to explain its owned topic, but should link
|
||||
to maintained examples instead of embedding a second complete copy.
|
||||
to maintained examples for complete copyable files.
|
||||
|
||||
Examples must be valid, secret-free, and tested where practical. Commands and
|
||||
configuration used in documentation should match the application.
|
||||
@@ -71,43 +65,42 @@ secret values.
|
||||
|
||||
| Topic | Canonical owner | Owned content | Content owned elsewhere |
|
||||
| --- | --- | --- | --- |
|
||||
| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
|
||||
| Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, and detailed change recipes, which belong in the relevant internal component document. |
|
||||
| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
|
||||
| Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit rules, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
|
||||
| Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
|
||||
| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
|
||||
| Product orientation and minimal end-to-end quickstart | `README.md` | Purpose, value, shortest successful invocation, and navigation, including licensing and attribution. | Complete command reference, configuration reference, operational procedures, implementation detail. |
|
||||
| Contributor entry point | `docs/development.md` | Task-oriented reading guide, contributor orientation, baseline validation commands, and canonical links. | Package inventory, architecture rules, subsystem behavior, detailed change recipes. |
|
||||
| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
|
||||
| Policy-set provenance and upstream navigation | `docs/policy/meta.md` | Policy-set origin, local authority, adoption baselines, and upstream adoption and update links. | Task-specific reading triggers, detailed adoption procedures, and formal attribution notices. |
|
||||
| Agent policy | `docs/policy/agents.md` | Proportionate, idiomatic implementation; rules against inventing requirements, restrictions, guarantees, or policy. | Application contracts, architecture, testing policy, and contributor procedures. |
|
||||
| Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
|
||||
| Testing policy | `docs/policy/testing.md` | Test philosophy, risk sufficiency, boundaries, doubles, coverage, regressions, and test maintenance. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
|
||||
| Release policy | `docs/policy/release.md` | Versioning, compatibility, release integrity and immutability, release documentation, proportionate gates, publication controls, completion, and required versus optional checks. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
|
||||
| Open source licensing and attribution policy | `docs/policy/oss.md` | License defaults and author choices, COPYRIGHT and attribution formats, license/notice links, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
|
||||
| Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and upstream component attribution. |
|
||||
| Project license texts | `LICENSE` | Complete project and incorporated companion license texts, with required project-specific fields. | General licensing policy and upstream component attribution. |
|
||||
| Upstream component attribution | `docs/oss/attribution.md` | House Format component entries: identity, material scope and modifications where applicable, copyright, license, required notices, and license, notice, and source links. | General attribution policy, exception reasoning, research narratives, compliance commentary, and complete standard license texts. |
|
||||
| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by applicable entries. | Project-specific upstream notices, attribution prose, and policy interpretation. |
|
||||
| Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, validation and publication commands and automated guards, asynchronous deliverables, delivery status, optional consumer verification, and recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
|
||||
| CLI contract | `docs/cli.md` | Commands, arguments, flags, invocation semantics, and exit codes. | End-to-end operating procedures, configuration field definitions, runtime filesystem layout, module implementation details. |
|
||||
| Configuration contract | `docs/config.md` | Application discovery and precedence, source locations, server fields, render default, HTTP limits, and credential mapping. | Promptkit framework formats and defaults, complete example files, CLI syntax, runtime lifecycle, and implementation detail. |
|
||||
| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache, and debug handling, resume, cleanup, permissions, recovery, and operational limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
|
||||
| Release policy | `docs/policy/release.md` | Versioning and compatibility, release integrity and immutability, documentation requirements, proportionate gates, publication controls, source completion, and optional verification boundaries. | Repository-specific commands, installation guidance, historical summaries, and CI implementation details. |
|
||||
| Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, publication command and guards, asynchronous delivery, optional diagnostics, and failure recovery. | General release requirements, runtime operations, historical announcements, and current application contracts. |
|
||||
| Version-specific release notes | `docs/releases/` | Immutable release summaries, compatibility notices, and migration announcements for one published version. | Complete CLI, HTTP, configuration, operations, or dependency contracts. |
|
||||
| Open source licensing and attribution policy | `docs/policy/oss.md` | House attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
|
||||
| Project license | `LICENSE` | The project's own license terms. | Upstream component attribution and dependency license texts. |
|
||||
| Upstream component attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General attribution policy and complete standard license texts. |
|
||||
| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
|
||||
| Configuration contract | `docs/config.md` | Application configuration discovery, precedence, schema, fields, defaults, environment overrides, validation, and selectable module and validator keys. | PromptKit framework formats and defaults, complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
|
||||
| Operations | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache and debug handling, resume, cleanup, permissions, recovery, and limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
|
||||
| Public HTTP contract | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
|
||||
| Consumer guidance | `docs/consumers/` | Choosing between Scriptorium's executable interfaces and understanding consumer responsibilities. | HTTP wire semantics, CLI syntax, Promptkit's Go package, and internal implementation detail. |
|
||||
| External and durable integration contracts | `docs/integrations/` | Scriptorium-owned process and executable integration contracts. | Promptkit framework formats and outbound provider protocols, physical runtime placement, internal transformations, CLI syntax, and configuration defaults. |
|
||||
| Implemented component inventory | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
|
||||
| Internal component behavior | Other files under `docs/internal/` | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
|
||||
| Architectural decision history | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
|
||||
| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status; sequencing; and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
|
||||
| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other files intended to be copied or run. | Field-by-field reference, command reference, prose explanation. |
|
||||
| Consumer guidance for executable use and migration | `docs/consumers/` | Task-oriented executable use, migration to PromptKit, minimal examples, and consumer responsibilities. | HTTP wire semantics, CLI syntax, PromptKit's public Go API, external protocol contracts, internal implementation detail. |
|
||||
| Scriptorium-owned integration contracts | `docs/integrations/` | Scriptorium-owned executable and process contracts, logical output paths and schemas, media types, and compatibility. | PromptKit framework formats and outbound provider protocols, physical runtime placement and lifecycle, internal transformations, CLI syntax, configuration defaults. |
|
||||
| Inventory of implemented internal packages | `docs/internal/overview.md` | Implemented packages and components, responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
|
||||
| Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, collaborators, state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
|
||||
| Architectural decision records | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
|
||||
| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
|
||||
| Release-note history | `docs/releases/` | One checked-in summary per source release under the procedure; the note at its immutable tag is the release record. | Current commands, behavior, contracts, and compatibility definitions. |
|
||||
| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
|
||||
|
||||
Documents that do not exist are required only when the corresponding interface
|
||||
or responsibility exists. Do not create placeholder API, consumer, integration,
|
||||
or operations documents for behavior the application does not have.
|
||||
Create supporting documents for existing interfaces and responsibilities when
|
||||
substantive content is available.
|
||||
|
||||
## Boundary Rules
|
||||
|
||||
### Orientation
|
||||
|
||||
The README owns product orientation. The developer guide routes contributors.
|
||||
Architecture owns normative structure. Internal overview owns the current
|
||||
concrete component map. These documents may link to one another but should not
|
||||
maintain parallel package or behavior descriptions.
|
||||
Link among orientation, architecture, and internal documents; maintain each
|
||||
package or behavior description in its canonical owner.
|
||||
|
||||
### Commands, Configuration, And Operations
|
||||
|
||||
@@ -119,26 +112,25 @@ other contracts.
|
||||
|
||||
### Releases
|
||||
|
||||
The release policy owns release requirements; the release procedure supplies
|
||||
the commands that satisfy them. Release notes are historical summaries, not
|
||||
current-state contract owners. The checked-in note at an immutable tag records
|
||||
that release; current documentation changes with the behavior it describes.
|
||||
Neither a procedure nor a note may weaken policy or defer required updates to
|
||||
canonical contracts.
|
||||
The release policy defines requirements and invariants that every release must
|
||||
satisfy. The repository-specific release procedure defines the commands and
|
||||
workflow maintainers use to satisfy that policy. Release notes record history
|
||||
at immutable tags. Maintain current behavior in its canonical documentation,
|
||||
update it with the corresponding behavior changes, and keep release procedures
|
||||
consistent with adopted policy.
|
||||
|
||||
### Open Source Attribution
|
||||
### Project Licensing And Upstream Attribution
|
||||
|
||||
The [OSS policy](oss.md) defines the House Format and README and release-link
|
||||
conventions. Attribution entries own component-specific information. README
|
||||
and release documents provide navigation to those canonical materials; the
|
||||
release procedure owns URL construction and publication mechanics.
|
||||
README and release documents link to the canonical licensing and attribution
|
||||
materials under the [OSS policy](oss.md). The release procedure owns URL
|
||||
construction and publication mechanics.
|
||||
|
||||
### Contracts And Implementation
|
||||
|
||||
Integration and API documents define externally observable shapes and
|
||||
semantics. Internal documents explain how this project implements or consumes
|
||||
those contracts. Internal docs may name a field, file, or protocol to identify
|
||||
a dependency, but must link to its canonical contract for the definition.
|
||||
semantics. Internal documents explain how this application implements or consumes those
|
||||
contracts. Internal docs may name a field, file, or protocol to identify a
|
||||
dependency, but must link to its canonical contract for the definition.
|
||||
|
||||
### Security Topics
|
||||
|
||||
@@ -160,31 +152,13 @@ Use sequentially numbered ADR filenames such as
|
||||
6. alternatives considered;
|
||||
7. consequences.
|
||||
|
||||
Use one of these statuses:
|
||||
|
||||
- **Proposed:** the decision is under consideration and may change;
|
||||
- **Accepted:** the decision is approved, whether or not implementation is
|
||||
complete;
|
||||
- **Rejected:** the proposed decision was considered and not adopted;
|
||||
- **Superseded:** a later ADR replaces the accepted decision.
|
||||
|
||||
A proposed ADR transitions to accepted or rejected. An accepted ADR transitions
|
||||
to superseded only when a later accepted ADR replaces it. An ADR may be created
|
||||
as accepted when the decision has already been made.
|
||||
|
||||
Treat the decision content of an accepted ADR as immutable. Its status and
|
||||
supersession metadata may be updated, but a changed decision requires a new ADR.
|
||||
A superseded ADR must link to its replacement, and the replacement must link
|
||||
back to the superseded ADR. Rejected architectural alternatives belong in the
|
||||
ADR; rejected product ideas belong in the roadmap.
|
||||
Treat the decision content of an accepted ADR as immutable. When a decision
|
||||
changes, create a new ADR and update the earlier ADR's status to superseded.
|
||||
Rejected architectural alternatives belong in the ADR; rejected product ideas
|
||||
belong in the roadmap.
|
||||
|
||||
## Maintenance
|
||||
|
||||
Every policy document records its underlying template version and local
|
||||
last-updated date immediately below the title. Update the date when revising
|
||||
local policy; change the base version only when adopting a newer template.
|
||||
Do not retain template adoption instructions in the local policy.
|
||||
|
||||
When behavior changes, update its canonical owner in the same change. If
|
||||
ownership moves, remove the old definition and replace it with a link where
|
||||
navigation remains useful.
|
||||
|
||||
27
docs/policy/meta.md
Normal file
27
docs/policy/meta.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Policy Set Provenance
|
||||
|
||||
**Base Policy Version:** 1.0
|
||||
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md
|
||||
|
||||
## Origin And Local Authority
|
||||
|
||||
This repository's policy set is adapted from
|
||||
[Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
|
||||
The adopted local policies govern work in this repository. Upstream revisions
|
||||
become local policy through deliberate adoption, preserving local decisions.
|
||||
Each policy's `Upstream Source` identifies its adopted baseline.
|
||||
|
||||
## Adoption And Updates
|
||||
|
||||
For policy adoption, upstream revision reviews, and updates, consult the
|
||||
[upstream adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
|
||||
That guide and the reference example collection are maintained upstream and
|
||||
accessed through links. Keep discovery links pointed at the current upstream
|
||||
project and guide; keep adopted-source and example links pinned to commits.
|
||||
|
||||
The local [developer guide](../development.md) routes tasks to applicable
|
||||
policies. Formal credit and licensing notices for the copied policy material
|
||||
belong in the local [attribution document](../oss/attribution.md).
|
||||
@@ -1,81 +1,150 @@
|
||||
# Open Source Licensing And Attribution Policy
|
||||
|
||||
**Base Policy Version:** 1.1
|
||||
**Base Policy Version:** 1.8
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md
|
||||
|
||||
## Purpose And Scope
|
||||
|
||||
This policy establishes a repeatable House Format for open source attribution
|
||||
and license notices. It covers upstream components incorporated into or
|
||||
distributed with the project, including relevant transitive dependencies and
|
||||
copied code or assets. Treatment follows the component's terms and actual use,
|
||||
rather than its classification as a direct dependency.
|
||||
This policy defines project licensing conventions and a repeatable House Format
|
||||
for upstream attribution and license notices. It covers the project's own code
|
||||
and upstream components incorporated into or distributed with the application
|
||||
or library, including relevant transitive dependencies and copied code,
|
||||
documentation, or assets.
|
||||
Determine treatment from the component's terms and actual use.
|
||||
|
||||
Consulting development guidance or using tooling alone does not require an
|
||||
attribution entry. Copying or adapting documentation for inclusion in the
|
||||
repository is different: preserve its applicable attribution and license terms.
|
||||
A material's role as development guidance does not exempt copied documents.
|
||||
Apply any express permissions for attribution-free reuse of example formatting.
|
||||
|
||||
The baseline is a publicly available source repository with releases published
|
||||
alongside it. The format is independent of language, forge, and build system.
|
||||
It does not require attribution for every development tool, establish license
|
||||
compatibility, or resolve obligations beyond attribution and notice handling.
|
||||
compatibility, or resolve every obligation arising from use or distribution.
|
||||
|
||||
## Canonical Locations
|
||||
|
||||
The [documentation policy](documentation.md) assigns ownership:
|
||||
|
||||
- `LICENSE` contains the project's own license. Dependency attribution does
|
||||
not relicense the project.
|
||||
- `docs/oss/attribution.md` contains the canonical component entries.
|
||||
- `docs/oss/licenses/` contains complete, verbatim standard license texts,
|
||||
including companion texts where applicable.
|
||||
- `COPYRIGHT`: project name, copyright statements, SPDX expression, grant,
|
||||
warranty disclaimer, and third-party statement.
|
||||
- `LICENSE` contains the complete, unmodified project license text, including
|
||||
incorporated companion text. Dependency attribution does not relicense the project.
|
||||
- `docs/oss/attribution.md`: canonical component entries.
|
||||
- `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
|
||||
|
||||
Use recognizable license filenames, such as `Apache-2.0.txt` or `LGPL-3.0.txt`.
|
||||
A shared standard text may serve multiple entries. Keep explanations outside
|
||||
license texts and preserve distinct versions and exceptions.
|
||||
|
||||
## House Format
|
||||
## Upstream Reference Examples
|
||||
|
||||
Each component entry has five fields:
|
||||
Use the commit-pinned upstream examples to create actual project notices.
|
||||
Retain their links and keep the example collection upstream; keep applicable
|
||||
license texts locally as specified above.
|
||||
|
||||
1. **Project name**, normally as the entry heading.
|
||||
## Project Licensing
|
||||
|
||||
Unless the author specifies otherwise, use **GPL version 3 or later**
|
||||
(`GPL-3.0-or-later`) for applications and **LGPL version 3 or later**
|
||||
(`LGPL-3.0-or-later`) for libraries. An author's explicit choice takes precedence:
|
||||
for example, a one-off script may use MIT. Such a choice requires no exception
|
||||
rationale, additional approval, or compensating controls under this policy.
|
||||
|
||||
These defaults guide new license selection. Adopting this policy does not
|
||||
relicense existing code or override third-party terms. Preserve an existing
|
||||
license unless the author deliberately changes it. For mixed-purpose projects,
|
||||
follow the author's selected scope rather than inferring different licenses for
|
||||
individual packages.
|
||||
|
||||
Use the upstream [application COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/application/COPYRIGHT)
|
||||
or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/library/COPYRIGHT)
|
||||
to create the project’s root `COPYRIGHT` file.
|
||||
Use verified project names, contribution years, and copyright holders.
|
||||
For another selected license, adapt the grant, SPDX expression, disclaimer, and
|
||||
text references together to reflect the author's selected grant.
|
||||
|
||||
For GPLv3 projects, copy the complete GPLv3 text into `LICENSE`. For LGPLv3
|
||||
projects, place the complete LGPLv3 text followed by the complete GPLv3 text in
|
||||
`LICENSE`; the LGPL incorporates the GPL terms. Keep the texts unmodified and
|
||||
place project-specific statements in `COPYRIGHT`. For the default grants, the
|
||||
grant and SPDX expression in `COPYRIGHT` must expressly identify `or-later`;
|
||||
follow the author’s choice if a different grant is selected.
|
||||
|
||||
For other licenses, provide their complete text and any required project-specific
|
||||
fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
|
||||
`LICENSE`, SPDX expressions, and README descriptions consistent with the actual
|
||||
grant. This convention introduces no blanket requirement for per-file headers;
|
||||
preserve notices or add them where the applicable terms require them.
|
||||
|
||||
Identify separately licensed documentation or assets in the project grant, with
|
||||
links to their attribution and license information. An application's default
|
||||
code license does not override the terms of incorporated documentation.
|
||||
|
||||
## Upstream Attribution House Format
|
||||
|
||||
Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
|
||||
followed directly by component entries. These comprise the complete document.
|
||||
|
||||
Each entry presents these five fields in order, with blank lines between them:
|
||||
|
||||
1. **Project name** as a level-two heading. An optional identification paragraph
|
||||
may follow, such as `Selected module: MODULE at VERSION.` with the module and
|
||||
version in backticks. For copied documentation, a concise `Material:` sentence
|
||||
may identify the affected files and whether they were adapted or copied
|
||||
without modification. A factual qualifier such as `(transitive dependency)`
|
||||
is permitted. Limit optional identification prose to factual component and
|
||||
material scope.
|
||||
2. **Upstream copyright statement or statements**, preserving their wording.
|
||||
3. **SPDX license identifier or expression**, when applicable.
|
||||
4. **License and notice links**, covering the applicable standard texts and
|
||||
upstream project-specific material.
|
||||
5. **Source repository link**, identifying the source corresponding to the
|
||||
imported version.
|
||||
Put multiple statements in separate paragraphs. Include this field when the
|
||||
selected upstream source supplies an applicable statement; otherwise, omit it.
|
||||
3. **SPDX license identifier or expression**, when applicable, using
|
||||
`SPDX-License-Identifier: EXPRESSION`.
|
||||
4. **License and notice links**, beginning `License and notices:`, separated
|
||||
by ` | `, and ending with a period. Label local standard texts by license
|
||||
name, such as `MIT` or `Apache 2.0`. Label upstream files by their actual
|
||||
filenames, such as `COPYRIGHT`, `LICENSE`, `NOTICE`, or `PATENTS`.
|
||||
5. **Source repository link**, rendered exactly as `[Source](COMMIT_URL).`.
|
||||
|
||||
Illustrative Markdown, with placeholders for the actual upstream information:
|
||||
Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/attribution.md)
|
||||
to create the project’s `docs/oss/attribution.md`.
|
||||
The example illustrates omitted fields and multiple copyrights and licenses.
|
||||
Replace the uppercase placeholders and illustrative URLs with actual component
|
||||
information. Local license links are relative to the destination
|
||||
`docs/oss/attribution.md`; copy the applicable texts into its `licenses/`
|
||||
directory. Do not copy example entries for components the project does not use.
|
||||
|
||||
```markdown
|
||||
## Example Library
|
||||
These are five fields, not a line limit. Omit the SPDX field when no applicable
|
||||
identifier exists; identify nonstandard terms through the linked text. Preserve
|
||||
licensing alternatives and exceptions, and record a selected option when
|
||||
relevant through the factual license identification. Do not invent an identifier
|
||||
or silently resolve an unsettled licensing choice.
|
||||
|
||||
Copyright <upstream copyright statement>
|
||||
|
||||
SPDX-License-Identifier: Apache-2.0
|
||||
|
||||
License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)
|
||||
|
||||
Source: [Example Library](<upstream repository URL at the imported commit>)
|
||||
```
|
||||
|
||||
These are five fields, not a line limit. Include multiple statements and links
|
||||
where needed. Omit the SPDX field when no applicable identifier exists; identify
|
||||
nonstandard terms accurately through the linked text. Preserve licensing
|
||||
alternatives and exceptions, and record a selected option when relevant. Do not
|
||||
invent an identifier or silently resolve an unsettled licensing choice.
|
||||
Keep entries factual. Do not add agent-authored explanations of license
|
||||
expressions, file-level license scope, research performed, retained source
|
||||
notices, or compliance conclusions. Avoid filler such as "none is invented
|
||||
here" and embellished link labels such as "upstream LICENSE", "additional
|
||||
patent grant", or "at the imported commit". Preserve actual required upstream
|
||||
content; this rule excludes editorial additions, not required notices. Policy
|
||||
interpretation and exception reasoning belong in the adopted OSS policy or an
|
||||
appropriate decision record, not the attribution document.
|
||||
|
||||
## License Texts And Upstream Links
|
||||
|
||||
Link standard license texts to their local copies. Link project-specific
|
||||
notices to the upstream copies instead of storing them locally. Every upstream
|
||||
repository or notice link must identify the exact commit corresponding to the
|
||||
notices to their upstream copies. Every upstream repository or notice link must
|
||||
identify the exact commit corresponding to the
|
||||
imported version, including the selected source revision for copied material.
|
||||
Do not use moving branches or version tags as substitutes for that commit.
|
||||
|
||||
Classify material by its contents, not its filename. An upstream `LICENSE`,
|
||||
Classify material according to its contents. An upstream `LICENSE`,
|
||||
`COPYING`, or similar file may contain project-specific notices or exceptions
|
||||
in addition to standard wording. Link both the local standard text and the
|
||||
commit-specific upstream file when needed. Make companion license texts directly
|
||||
reachable from the entry rather than leaving readers to infer their location.
|
||||
reachable from the entry.
|
||||
|
||||
For project-specific license and attribution material, this policy accepts
|
||||
direct links to the applicable upstream texts as satisfying reproduction,
|
||||
@@ -91,17 +160,18 @@ source files; the central attribution entry does not authorize stripping them.
|
||||
## Discoverability
|
||||
|
||||
End the project's README with two friendly statements linking to its actual
|
||||
license and the attribution document. For Scriptorium:
|
||||
grant in `COPYRIGHT` and the attribution document. For example, for a project
|
||||
with the stated license:
|
||||
|
||||
```markdown
|
||||
Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
|
||||
Scriptorium is licensed under the [GPL v3.0 or later](COPYRIGHT).
|
||||
|
||||
[Open Source attribution notices](docs/oss/attribution.md) are available.
|
||||
```
|
||||
|
||||
Each new checked-in release document and its hosted download page must end
|
||||
with links whose visible text is `LICENSE | ATTRIBUTION`. Use absolute URLs to
|
||||
those files at the release's immutable tag or corresponding immutable source
|
||||
with links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`. Use absolute
|
||||
URLs to those files at the release's immutable tag or corresponding immutable source
|
||||
revision so the links work in both locations. This release navigation is distinct
|
||||
from upstream component links, which must use the imported commit.
|
||||
|
||||
@@ -113,8 +183,9 @@ assets, source bundles, or a different binary package format.
|
||||
|
||||
## Maintenance And Exceptions
|
||||
|
||||
Update notices in the change that adds, removes, upgrades, copies, or changes
|
||||
the distribution of a relevant component. Check the selected source's license
|
||||
Update project licensing statements together when the author changes the grant
|
||||
or its scope. Update upstream notices in the change that adds, removes, upgrades,
|
||||
copies, or changes the distribution of a relevant component. Check the selected source's license
|
||||
and notices rather than assuming they are unchanged. Update affected entries,
|
||||
commit links, and texts; retain historical versions through Git.
|
||||
|
||||
@@ -128,8 +199,10 @@ to implement this policy.
|
||||
Use the House Format routinely. Raise an exception only for a concrete obligation
|
||||
or unresolved rights question it does not address, including any arising from a
|
||||
particular distribution channel. Record the issue and selected treatment in the
|
||||
adopted policy or affected attribution entry as appropriate. Resolve the issue
|
||||
before the affected use or distribution without reopening settled choices.
|
||||
adopted OSS policy or an appropriate decision record. Attribution entries
|
||||
contain the resulting factual identification and required material, without
|
||||
repeating that reasoning. Resolve the issue before the affected use or
|
||||
distribution without reopening settled choices.
|
||||
Common ownership of projects is neither required nor a blanket exception.
|
||||
|
||||
Apply the formatting convention prospectively. Do not rewrite published tags,
|
||||
|
||||
@@ -1,8 +1,10 @@
|
||||
# Release Policy
|
||||
|
||||
**Base Policy Version:** 1.2
|
||||
**Base Policy Version:** 1.4
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -18,14 +20,13 @@ policy and link to it rather than introduce additional release requirements.
|
||||
|
||||
A source release identifies one exact committed source revision through an
|
||||
immutable version tag and a version-matched, checked-in release note. The
|
||||
primary release branch is `main`; the authoritative publication remote is
|
||||
`origin`.
|
||||
primary release branch is `main` unless the adopted policy specifies otherwise.
|
||||
The procedure must name the authoritative publication remote.
|
||||
|
||||
A successful push of the intended tag, with its source commit available on the
|
||||
authoritative primary branch, completes the release. Publish `main` before
|
||||
invoking the publication command; the command requires
|
||||
that the remote branch exactly identifies the validated candidate and pushes
|
||||
only the selected annotated tag.
|
||||
authoritative primary branch, completes the release. The source commit may be
|
||||
pushed before the tag or published together with it through an atomic push.
|
||||
The procedure must choose and document the supported approach.
|
||||
|
||||
Release commands must finish at successful publication. They must not wait for
|
||||
or poll CI, require successful CI status, inspect downloadable artifacts, or
|
||||
@@ -34,19 +35,20 @@ A failed or ambiguous push requires resolving the authoritative remote state
|
||||
before declaring success or retrying; successful pushes do not require a
|
||||
separate remote read-back gate.
|
||||
|
||||
Scriptorium publishes Linux binaries and checksums asynchronously from the
|
||||
tagged source. The procedure must identify those deliverables and the
|
||||
Repositories may publish source only. Additional binaries, images, packages,
|
||||
checksums, or other declared deliverables may be published asynchronously from
|
||||
the tagged source. The procedure must identify those deliverables and the
|
||||
responsibility of their automation. Published deliverables must be traceable
|
||||
to that source and identify the same version.
|
||||
|
||||
Artifact delivery is a separate status. A successful tag push is not evidence
|
||||
that artifacts are available. Delivery failures do not reverse source-release
|
||||
success, and optional investigation must not delay release completion.
|
||||
Track source-release completion and artifact delivery separately. Report delivery
|
||||
failures and optional investigations under artifact-delivery status.
|
||||
|
||||
## Versioning And Compatibility
|
||||
|
||||
Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with
|
||||
no leading zeroes. Prereleases are not part of the adopted release channel.
|
||||
no leading zeroes. Prereleases require an explicit adopted policy defining
|
||||
their format and use.
|
||||
|
||||
The selected version must be unused locally and on the authoritative remote.
|
||||
Do not require queries to every configured remote or publication service.
|
||||
@@ -76,9 +78,13 @@ source tree. Use the complete version tag as the filename and begin with a
|
||||
title containing the product name and that exact version.
|
||||
|
||||
Include a short summary and any relevant compatibility impact or upgrade
|
||||
instructions. Keep the note proportionate to the change. Fixed sections and
|
||||
explicit no-action boilerplate are not required. Existing historical notes
|
||||
need not be rewritten to adopt this format.
|
||||
instructions. Choose sections suited to the release and keep the note
|
||||
proportionate to the change.
|
||||
|
||||
Keep exact current contracts in their canonical documents and update affected
|
||||
documentation with the behavior change. Link to those documents from the note
|
||||
where useful. If annotated tags are used, derive their summary from the
|
||||
checked-in note.
|
||||
|
||||
Include the release footer defined by the [OSS policy](oss.md#discoverability)
|
||||
in each new release document and preserve it on the hosted download page. The
|
||||
@@ -86,18 +92,11 @@ release procedure defines the concrete URLs and publication mechanics. Prepare
|
||||
these links with the release note; they do not add a network check or approval
|
||||
gate.
|
||||
|
||||
Keep exact current contracts in their canonical documents and update affected
|
||||
documentation with the behavior change. Link to those documents from the note
|
||||
where useful. A release note must not substitute for current documentation.
|
||||
Use annotated tags with their message derived from the checked-in note rather
|
||||
than requiring a separately authored account of the same release.
|
||||
|
||||
Version selection, release-note content, and retirement of completed roadmaps
|
||||
are preparation responsibilities, not separate human approval gates. Preserve
|
||||
planned and deferred work and repair affected links when retiring roadmaps.
|
||||
Ordinary change review covers unintended files, credentials, and private data;
|
||||
do not repeat it as a release-specific sign-off. Ignored local files are not
|
||||
prohibited merely because they exist: they are not included in the tagged source.
|
||||
Handle version selection, release-note content, and retirement of completed
|
||||
roadmaps during preparation. Preserve planned and deferred work and repair
|
||||
affected links when retiring roadmaps. Reuse ordinary change review for
|
||||
unintended files, credentials, and private data. Scope release-content review
|
||||
to the tagged source.
|
||||
|
||||
## Candidate Validation
|
||||
|
||||
@@ -107,24 +106,10 @@ mode or command may be provided for diagnosis, but must not be a required step
|
||||
before publication repeats the same checks.
|
||||
|
||||
Run the complete deterministic, offline default test suite once for the final
|
||||
candidate, following the [testing policy](testing.md), and verify the required
|
||||
build targets. Select those targets for the application's actual support
|
||||
commitments; native testing on each platform and access to particular hardware
|
||||
are not default release prerequisites.
|
||||
|
||||
The selected test invocation includes the race detector because the HTTP
|
||||
service shares engines and backend capacity state across concurrent requests.
|
||||
This single invocation covers both ordinary assertions and race detection.
|
||||
Build both declared Linux architectures with the hosted release flags to catch
|
||||
cross-compilation and packaging failures; native test hardware for each target
|
||||
is not required. Existing architecture tests enforce dependency boundaries.
|
||||
|
||||
Retain narrow source guards against committed workspaces, vendor trees, and
|
||||
module replacements: these can otherwise make a passing local build depend on
|
||||
unpublished or substituted framework code. Disable workspace discovery and
|
||||
vendor mode during validation. These guards preserve the established
|
||||
cross-project boundary; they do not require exact dependency-version audits or
|
||||
module-metadata rewrites at release time.
|
||||
candidate, following the [testing policy](testing.md). For repositories that
|
||||
publish builds, verify the required build targets. Select those targets for
|
||||
the application's actual support commitments; native testing on each platform
|
||||
and access to particular hardware are not default release prerequisites.
|
||||
|
||||
Additional gates must address a concrete risk that the existing checks do not
|
||||
adequately cover. Do not automatically require linting, race testing, module
|
||||
@@ -134,8 +119,8 @@ checks when their distinct protection justifies their cost. A one-time migration
|
||||
check must not silently become a permanent release requirement.
|
||||
|
||||
Release tests must not require real credentials, mutable application services,
|
||||
paid APIs, provider probes, or inference calls. The procedure describes
|
||||
dependency preparation separately from offline validation.
|
||||
paid APIs, provider probes, or inference calls. The procedure may describe dependency
|
||||
preparation separately from offline validation.
|
||||
|
||||
Avoid duplicate validation across release phases. Successful checks for the
|
||||
same final candidate need not be repeated solely to satisfy another phase;
|
||||
@@ -158,7 +143,9 @@ Automate the checks needed to publish the intended source under a fresh version:
|
||||
- the worktree and index are clean on the primary release branch;
|
||||
- the source being published is the exact candidate that passed validation,
|
||||
including its matching release note;
|
||||
- the remote primary branch already identifies that exact candidate; and
|
||||
- the remote primary branch already identifies that candidate, or an atomic
|
||||
source/tag push will advance it to that candidate without discarding remote
|
||||
history; and
|
||||
- the tag identifies the validated candidate and only the intended refs are
|
||||
published.
|
||||
|
||||
@@ -211,3 +198,27 @@ Use copyable commands where practical. Keep optional diagnostics and consumer
|
||||
verification clearly optional. The procedure must not turn preparation work,
|
||||
ordinary change review, or post-publication investigation into additional
|
||||
release gates.
|
||||
|
||||
## Scriptorium Release Selections
|
||||
|
||||
Scriptorium publishes stable releases from `main` through the authoritative
|
||||
`origin` push endpoint. The validated candidate is published to the remote
|
||||
branch before the annotated version tag; the publication command requires
|
||||
exact agreement between the remote branch and candidate before pushing only
|
||||
that tag. Atomic branch-and-tag publication and source-only delivery remain
|
||||
general alternatives in this policy, not Scriptorium-supported workflows.
|
||||
The tag message derives from the checked-in note. A successful tag push
|
||||
completes the source release; binary delivery is asynchronous and does not
|
||||
gate it.
|
||||
|
||||
The tagged source produces Linux amd64 and arm64 binaries and checksums through
|
||||
the hosted workflow. Candidate validation runs the complete offline Go suite
|
||||
once with the race detector because concurrent HTTP requests share engine and
|
||||
backend capacity state. It builds both declared Linux targets. Narrow guards
|
||||
reject committed workspaces, vendor trees, and module replacements so local
|
||||
substitutions cannot mask unpublished framework code. These selected checks
|
||||
address distinct application and release risks; no CI polling, artifact
|
||||
availability, consumer installation, or new approval gate is required.
|
||||
|
||||
The [release procedure](../release.md) owns exact commands, targets, guards,
|
||||
delivery reporting, and recovery steps.
|
||||
|
||||
@@ -1,14 +1,16 @@
|
||||
# Testing Policy
|
||||
|
||||
**Base Policy Version:** 1.1
|
||||
**Base Policy Version:** 1.3
|
||||
|
||||
**Last Updated:** 2026-09-26
|
||||
**Last Updated**: 2026-09-28
|
||||
|
||||
**Upstream Source:** https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md
|
||||
|
||||
## Purpose
|
||||
|
||||
Our tests exist to make **incorrect changes expensive and correct changes cheap**.
|
||||
|
||||
We do not optimize for test count, line coverage, exhaustive isolation, or the fewest possible tests. We optimize for sufficient confidence in important behavior while imposing as little unnecessary friction as possible on future development.
|
||||
We optimize for sufficient confidence in important behavior while minimizing friction on future development.
|
||||
|
||||
## Every test has a cost
|
||||
|
||||
@@ -22,9 +24,9 @@ Evaluate that tradeoff at two levels:
|
||||
1. **Per test:** What realistic defect does this test detect, how consequential would that defect be, and is that protection worth the test's lifetime cost?
|
||||
2. **Across the suite:** Does this collection provide materially more confidence than a smaller, simpler suite would?
|
||||
|
||||
Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. They should not make ordinary internal changes needlessly expensive.
|
||||
Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. Keep ordinary internal changes inexpensive.
|
||||
|
||||
The cost of a test is not a reason to omit testing by default. Do not cite maintenance cost abstractly. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
|
||||
Evaluate maintenance cost against the specific failure being protected. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
|
||||
|
||||
## Default testing style
|
||||
|
||||
@@ -56,7 +58,7 @@ To the extent the following features are present in the application, prioritize
|
||||
6. Previously observed or plausible regressions.
|
||||
7. Representative integration and end-to-end workflows.
|
||||
|
||||
A package-level contract is behavior relied upon by another package or major collaborator, not every observable detail of a package implementation.
|
||||
A package-level contract comprises behavior relied upon by another package or major collaborator.
|
||||
|
||||
Choose tests for requested behavior and established contracts. Tests must not
|
||||
introduce new restrictions, guarantees, or threat scenarios merely because they
|
||||
@@ -75,14 +77,8 @@ Do not add tests merely because a function, branch, or line exists. Do not add a
|
||||
|
||||
## Choose the right test boundary
|
||||
|
||||
Test through the narrowest stable boundary that expresses the behavior clearly.
|
||||
|
||||
For application configuration, ConfigKit owns exhaustive YAML grammar,
|
||||
source traversal, import/overlay composition, provenance, and inspection
|
||||
renderer tests. Scriptorium tests its selected definition, source discovery,
|
||||
CLI override presence, command prerequisites, runtime conversion, credential
|
||||
boundary, and representative execution/inspection workflows with the tagged
|
||||
library. Do not copy the upstream parser test matrix into this repository.
|
||||
Choose the narrowest stable boundary that expresses the behavior clearly and
|
||||
provides durable confidence with minimal incidental coupling.
|
||||
|
||||
This is often the package API, but it may instead be:
|
||||
|
||||
@@ -90,22 +86,15 @@ This is often the package API, but it may instead be:
|
||||
- a package-level operation when several internal collaborators jointly produce the behavior; or
|
||||
- a larger integration boundary when correctness emerges from interaction with a real dependency.
|
||||
|
||||
Do not force all behavior through oversized end-to-end tests. Do not test every private helper merely because it exists. Choose the boundary that gives durable confidence with the least incidental coupling.
|
||||
|
||||
## Test behavior, not implementation
|
||||
|
||||
A test should protect a decision, contract, or invariant. A test must not memorialize the current implementation.
|
||||
A test should protect a selected decision, contract, or invariant.
|
||||
|
||||
A test is suspect when its main purpose is to detect that someone:
|
||||
A test is suspect when it primarily detects changes to private constants or
|
||||
helpers, equivalent operation ordering, incidental formatting, equivalent
|
||||
algorithms, or internal structure that preserves behavior.
|
||||
|
||||
- changed an internal constant;
|
||||
- renamed or split a private helper;
|
||||
- reordered equivalent internal operations;
|
||||
- changed incidental formatting;
|
||||
- replaced one correct algorithm with another; or
|
||||
- refactored internal object structure without changing behavior.
|
||||
|
||||
Refactoring should normally require no test edits unless the refactored structure is itself part of the contract.
|
||||
Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
|
||||
|
||||
## Expected effects of different changes
|
||||
|
||||
@@ -122,7 +111,7 @@ A test failing is not the same as a test needing to be edited. Many tests may co
|
||||
|
||||
## Separate mechanism from policy
|
||||
|
||||
Configurable thresholds and defaults must not be duplicated throughout the test suite.
|
||||
Derive expectations from test-controlled configuration and relationships.
|
||||
|
||||
For this example, assume the selected contract rejects a request to start more
|
||||
processes than a configured limit. Do not encode its production default indirectly:
|
||||
@@ -158,33 +147,52 @@ limit solely to reproduce this example.
|
||||
|
||||
The production default should be tested exactly only when its literal value is itself a public, operational, safety, protocol, or compatibility requirement.
|
||||
|
||||
Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior, not duplicated literals.
|
||||
Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior.
|
||||
|
||||
For established concurrency limits, distinguish these behaviors where the contract requires them:
|
||||
|
||||
1. **Configuration handling:** values are accepted or rejected according to the selected contract.
|
||||
2. **Runtime enforcement:** observed peak concurrency never exceeds the configured limit.
|
||||
|
||||
Use a test-controlled limit and measure the behavior relative to that limit. Do not merely assert today's default value.
|
||||
Use a test-controlled limit and measure the behavior relative to that limit.
|
||||
|
||||
## Avoid semantic duplication across layers
|
||||
## Assign each behavior a test owner
|
||||
|
||||
Each behavior should have a clear test owner.
|
||||
Where these layers exist, assign ownership as follows:
|
||||
|
||||
- Configuration tests own application YAML, strict decoding, discovery,
|
||||
precedence, and application defaults.
|
||||
- CLI tests own argument mapping, streams, summaries, exit behavior, and
|
||||
representative command workflows.
|
||||
- HTTP tests own DTOs, strict decoding, limits, status mapping, and restricted
|
||||
artifact policy.
|
||||
- Formatter tests own prepared-run and definition-inspection text and JSON
|
||||
presentation.
|
||||
- Architecture tests own dependency direction and removal invariants.
|
||||
- Parser tests own parsing cases.
|
||||
- Validator tests own validation rules.
|
||||
- Domain tests own transformations and invariants.
|
||||
- Adapter tests own external integration behavior.
|
||||
- Orchestrator tests own coordination and failure propagation.
|
||||
- CLI tests own argument and configuration mapping.
|
||||
- End-to-end tests prove that representative assembled workflows work.
|
||||
|
||||
Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
|
||||
|
||||
## Scriptorium Test Ownership
|
||||
|
||||
- Application configuration tests own Scriptorium's definition, strict
|
||||
decoding at its boundary, source discovery and selection, explicit CLI
|
||||
override presence, application defaults, runtime conversion, and safe
|
||||
diagnostics. ConfigKit owns exhaustive YAML grammar, source traversal,
|
||||
import and overlay composition, provenance, and inspection renderers.
|
||||
- CLI tests own argument mapping, streams, output, exit behavior, and
|
||||
representative run, render, inspect, serve, and config workflows.
|
||||
- HTTP tests own DTO decoding, transport limits, status and error mapping,
|
||||
restricted artifact reading, and representative server workflows.
|
||||
- Formatting tests own prepared-run and definition-inspection text and JSON
|
||||
presentation. Architecture guards own dependency direction and removed
|
||||
framework-package boundaries.
|
||||
- Promptkit owns framework parsing, orchestration, validation, profiles, and
|
||||
model-client behavior. Scriptorium's definition compatibility fixtures protect
|
||||
its adapter plumbing without duplicating the upstream format contract.
|
||||
model-client behavior. Scriptorium's definition and execution fixtures
|
||||
protect adoption through its public adapter boundary without duplicating
|
||||
Promptkit's exhaustive format matrix.
|
||||
|
||||
Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
|
||||
HTTP lexical containment, size limits, and shared engine and backend capacity
|
||||
across concurrent requests merit focused adapter coverage because violations
|
||||
cross a security or concurrency boundary. Choose cases by realistic risk
|
||||
rather than a coverage quota or a duplicated upstream matrix.
|
||||
|
||||
## Use test doubles deliberately
|
||||
|
||||
@@ -205,12 +213,9 @@ Mocks are appropriate when the contract includes facts such as:
|
||||
- an expensive API is called no more than once; or
|
||||
- a security audit event is emitted.
|
||||
|
||||
Do not use mocks merely to isolate every object or reproduce the implementation's call graph.
|
||||
|
||||
## Go-specific guidance
|
||||
|
||||
Select techniques according to the behavior and risk being tested. The following
|
||||
are options, not a checklist that every package or application must satisfy:
|
||||
Select techniques by behavior and risk:
|
||||
|
||||
- table-driven tests for meaningful behavioral categories and boundaries;
|
||||
- `t.TempDir()` for real filesystem behavior;
|
||||
@@ -220,55 +225,48 @@ are options, not a checklist that every package or application must satisfy:
|
||||
- integration tests where correctness depends on component interaction; and
|
||||
- a small number of representative end-to-end tests when assembled workflows expose meaningful risks not adequately covered at narrower boundaries.
|
||||
|
||||
Avoid exact error-string assertions unless the wording is itself contractual. Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields.
|
||||
Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields. Use exact error-wording assertions only when the wording is contractual.
|
||||
|
||||
At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Do not snapshot complete diagnostic wording unless it is contractual.
|
||||
At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Use complete diagnostic snapshots only when the wording is contractual.
|
||||
|
||||
Golden-file updates must require an explicit local flag. CI must not update golden files automatically, and reviewers must inspect the semantic diff before accepting an update.
|
||||
|
||||
Keep tests readable and direct. Test helpers and fixture frameworks must earn their own maintenance cost; do not build elaborate test infrastructure for small or isolated needs.
|
||||
Keep tests readable and direct. Size test helpers and fixture frameworks to the maintenance benefit they provide.
|
||||
|
||||
## Coverage
|
||||
|
||||
Coverage is a diagnostic, not a target.
|
||||
Use coverage to locate untested critical branches and unexpectedly weak packages. Evaluate test quality through meaningful behavioral protection and choose coverage according to risk.
|
||||
|
||||
Use it to find untested critical branches and unexpectedly weak packages. Do not write low-value tests solely to increase a percentage, and do not infer test quality from coverage alone.
|
||||
|
||||
Security-sensitive HTTP containment and external mappings may warrant denser
|
||||
coverage than straightforward process wiring. Uneven coverage is acceptable
|
||||
when it reflects risk.
|
||||
Pure domain logic will often warrant higher coverage than CLI wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
|
||||
|
||||
## Regression tests
|
||||
|
||||
A bug fix should normally include a regression test that fails before the fix and passes afterward.
|
||||
|
||||
Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant; do not preserve accidental implementation details from the original bug.
|
||||
Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant.
|
||||
|
||||
Not every historical bug requires a permanent test. If the underlying design has made recurrence impossible, the test has become redundant, or a stronger invariant test now subsumes it, remove or consolidate it.
|
||||
Remove or consolidate a test when the underlying design has made recurrence impossible, its protection is redundant, or a stronger invariant test subsumes it.
|
||||
|
||||
## Deleting or rewriting tests
|
||||
|
||||
Tests are maintained code, not permanent historical artifacts.
|
||||
|
||||
Delete or rewrite a test when its maintenance cost exceeds the confidence it provides.
|
||||
Delete or rewrite tests when maintenance cost exceeds their continuing
|
||||
protective value.
|
||||
|
||||
Strong candidates include tests that:
|
||||
|
||||
- require updates after harmless internal changes;
|
||||
- directly assert private constants without protecting a real contract;
|
||||
- duplicate the same policy across several layers;
|
||||
- assert incidental private constants or snapshot large amounts of incidental output;
|
||||
- verify mock choreography rather than outcomes;
|
||||
- snapshot large amounts of incidental output;
|
||||
- test trivial private helpers already exercised through stable package behavior;
|
||||
- protect risks already covered more effectively elsewhere;
|
||||
- duplicate policy across layers, retest trivial helpers covered by package
|
||||
behavior, or protect risks covered more effectively elsewhere;
|
||||
- are flaky, misleading, obsolete, or disproportionately expensive to diagnose; or
|
||||
- no longer correspond to a plausible failure mode.
|
||||
|
||||
Several brittle tests may encode one genuine requirement. Replace them with one durable behavior-level or invariant test rather than preserving all of them.
|
||||
Several brittle tests may encode one genuine requirement. Consolidate them into one durable behavior-level or invariant test.
|
||||
|
||||
## Reviewing a proposed test
|
||||
|
||||
Use the following questions when the value, boundary, or durability of a proposed test is not self-evident. Significant test additions should be reviewable against them, but written answers are not required for every routine test.
|
||||
Use the following questions when a proposed test needs closer evaluation. Significant test additions should be reviewable against them; written answers are optional for routine tests.
|
||||
|
||||
1. Which requested behavior or established contract does it protect, and what realistic defect would violate it?
|
||||
2. How likely and consequential is that defect, and is it already protected elsewhere?
|
||||
@@ -282,10 +280,9 @@ A test suite is sufficient when:
|
||||
|
||||
- important requested behavior and established contracts are protected against realistic, consequential failures;
|
||||
- boundaries and component interactions have coverage where they introduce meaningful risks not protected elsewhere;
|
||||
- failures provide useful signal rather than redundant noise;
|
||||
- legitimate internal changes usually do not require test edits; and
|
||||
- failures provide useful, distinct signals;
|
||||
- tests usually remain stable through legitimate internal changes; and
|
||||
- additional tests would mostly repeat existing protection or preserve inconsequential implementation details.
|
||||
|
||||
Sufficiency is a risk judgment, not a coverage percentage, test count, or required
|
||||
mix of testing techniques. Reassess it as the application, its users, and the
|
||||
consequences of failure evolve.
|
||||
Reassess sufficiency as the application, its users, and the consequences of
|
||||
failure evolve.
|
||||
|
||||
@@ -23,20 +23,19 @@ Choose an unused stable version under the release policy. Commit its note as
|
||||
`docs/releases/<version>.md`, beginning with a title such as
|
||||
`# Scriptorium v0.14.0` (an example, not an instruction to select that version).
|
||||
Include a concise summary and relevant compatibility impact or upgrade action.
|
||||
End the note with the following footer, replacing `<version>` in both absolute
|
||||
End the note with the following footer, replacing `<version>` in all three absolute
|
||||
URLs with the selected version tag (for example, `v0.14.0`):
|
||||
|
||||
```markdown
|
||||
[LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/<version>/docs/oss/attribution.md)
|
||||
```
|
||||
|
||||
Check that both URLs name files in the candidate tree at that tag. The tag may
|
||||
Check that all three URLs name files in the candidate tree at that tag. The tag may
|
||||
not resolve online until publication. The checked-in note is copied unchanged
|
||||
into the hosted release body by the existing workflow, so do not maintain a
|
||||
second footer there.
|
||||
Update affected canonical documentation with the change, and retire completed
|
||||
roadmap material when appropriate while preserving deferred work and links.
|
||||
No extra release-specific review signoff is required.
|
||||
|
||||
Finish and commit the intended candidate on `main`, then publish that branch:
|
||||
|
||||
@@ -63,9 +62,8 @@ remote version, exact agreement with authoritative remote `main`, and a
|
||||
checked-in note whose first-level title contains Scriptorium and the exact
|
||||
version. Ignored local files do not make the candidate dirty.
|
||||
|
||||
The existing source-boundary guards reject committed workspaces, vendor trees,
|
||||
and module replacements. No migration-specific exact Promptkit version audit
|
||||
is required.
|
||||
The source-boundary guards reject committed workspaces, vendor trees, and
|
||||
module replacements.
|
||||
|
||||
It then runs the complete suite once with the race detector and builds Linux
|
||||
amd64 and arm64 binaries using `CGO_ENABLED=0`, `-trimpath`, and
|
||||
|
||||
26
docs/releases/v0.15.0.md
Normal file
26
docs/releases/v0.15.0.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Scriptorium v0.15.0
|
||||
|
||||
This minor release changes Scriptorium's application grant to GPL version 3 or
|
||||
later, aligns its repository policies and attribution notices, and updates the
|
||||
selected Promptkit and ConfigKit patch releases.
|
||||
|
||||
## Licensing and upgrade impact
|
||||
|
||||
Scriptorium's application source and binaries are now distributed under
|
||||
GPL-3.0-or-later. Review [COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT)
|
||||
and [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE)
|
||||
before redistributing or incorporating this version. Material adapted from
|
||||
Standard Repository Policies remains separately licensed under CC-BY-SA-4.0;
|
||||
the [attribution notices](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)
|
||||
identify its scope and license text. Existing dependency grants are unchanged,
|
||||
and earlier tagged releases retain their own published terms.
|
||||
|
||||
## Dependency updates
|
||||
|
||||
Scriptorium now selects Promptkit v0.11.2 and ConfigKit v0.4.2. The current
|
||||
[CLI](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/cli.md),
|
||||
[HTTP API](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/api.md),
|
||||
and [configuration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/config.md)
|
||||
references describe the executable contracts.
|
||||
|
||||
[COPYRIGHT](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/oss/attribution.md)
|
||||
@@ -3,9 +3,10 @@
|
||||
## Status And Intent
|
||||
|
||||
Implemented feature direction, drafted on 2026-09-26 and delivered through the
|
||||
[implementation plan](implementation.md). This roadmap records the target
|
||||
behavior and changes from the reviewed baseline; the implementation plan owns
|
||||
sequencing, concrete interfaces, and verification evidence.
|
||||
historical plan at
|
||||
`git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
|
||||
This roadmap records the target behavior and changes from the reviewed baseline;
|
||||
that Git record owns sequencing, concrete interfaces, and verification evidence.
|
||||
|
||||
The user is adopting ConfigKit across an application suite to standardize
|
||||
configuration semantics. Scriptorium will make a clean cutover to ConfigKit's
|
||||
|
||||
@@ -1,536 +1,303 @@
|
||||
# ConfigKit Adoption Implementation Plan
|
||||
# Policy Alignment Implementation Plan
|
||||
|
||||
## Status, Authority, And Historical Plans
|
||||
## Status, Scope, And Authority
|
||||
|
||||
Planned on 2026-09-26 against Scriptorium commit
|
||||
`43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c`. This document records the
|
||||
ordered implementation and its completion evidence. The maintainer resolved
|
||||
the inspection-policy question:
|
||||
`extra_params` remain visible; only API-key values require secret protection.
|
||||
Planned on 2026-09-28 against Scriptorium
|
||||
`8452b54809b99425a97940da485daaa48c77aeb8`. All five stages are complete.
|
||||
The ordered stages below retain the implementation instructions and completion
|
||||
evidence for this delivered work set.
|
||||
|
||||
The [feature roadmap](configkit.md) owns scope, target behavior, and user intent.
|
||||
This plan owns implementation steps and the interface choices needed to execute
|
||||
them. Read [development](../development.md) and every policy before work:
|
||||
[agents](../policy/agents.md), [architecture](../policy/architecture.md),
|
||||
[documentation](../policy/documentation.md), [testing](../policy/testing.md),
|
||||
[release](../policy/release.md), and [OSS](../policy/oss.md).
|
||||
[ADR 0004](../adr/0004-definition-boundary.md) continues to govern Promptkit's
|
||||
definition boundary. Do not rewrite accepted ADR decisions.
|
||||
The [feature roadmap](policy.md) owns the agreed end state, scope, and reasons
|
||||
for local exceptions. This plan owns execution steps and acceptance checks.
|
||||
This is documentation work, not application, dependency, or release-tool work.
|
||||
|
||||
This filename previously contained completed Promptkit plans. Older roadmap
|
||||
links to this file refer to these historical records, not the ConfigKit stages:
|
||||
The selected public upstream revision is
|
||||
`d84a38ebab26f048cafbe59a2246700c35d29843`.
|
||||
Start with its
|
||||
[adoption guide](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md).
|
||||
Retrieve source files at this revision, not whatever main contains when a
|
||||
stage runs. A verified checkout of this exact revision is acceptable; no
|
||||
sibling checkout is a prerequisite. If source retrieval fails, report that
|
||||
blocker rather than inventing source content or provenance.
|
||||
|
||||
- Completed v0.11 implementation and release handoff:
|
||||
`git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`.
|
||||
- Completed v0.9 implementation:
|
||||
`git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`.
|
||||
Read the current local agent policy and developer orientation before work,
|
||||
then policies governing the stage. Once Stage 2 lands, use the new selective
|
||||
reading guide. Reuse unchanged policy text already available in context.
|
||||
|
||||
Those deliveries must not be repeated or lost from upcoming release preparation.
|
||||
These Git records are available locally without publishing the recent commits.
|
||||
## Historical Implementation Records
|
||||
|
||||
## Working Rules And Selected Design
|
||||
This filename previously held completed application plans. Preserve their
|
||||
records through Git rather than carrying their implementation steps forward:
|
||||
|
||||
The dependency target is `gitea.maximumdirect.net/eric/ConfigKit v0.4.0`,
|
||||
commit `e6ced0d3d1194b58e0b3dc8970089471ba175258`. Use its public root package,
|
||||
imported as `configkit`. The roadmap links the exact upstream contracts.
|
||||
Do not opportunistically upgrade Promptkit or other dependencies, commit a
|
||||
workspace/replacement, or depend on sibling source at runtime.
|
||||
- ConfigKit adoption and release handoff:
|
||||
`git show 8452b54809b99425a97940da485daaa48c77aeb8:docs/roadmap/implementation.md`.
|
||||
- Earlier PromptKit plans are referenced within that historical document.
|
||||
|
||||
This is a clean configuration cutover, not a compatibility project. Native
|
||||
ConfigKit syntax, presence, nullability, resource limits, and precedence apply.
|
||||
Do not add a pre-parser, YAML serialization round trip, alternate merge engine,
|
||||
legacy mode, generic provider abstraction, or a new CLI framework.
|
||||
Those stages must not be rerun. Existing release notes, including
|
||||
[the v0.14.0 note](../releases/v0.14.0.md), record prior delivered features.
|
||||
Do not infer a new release obligation from an old prospective handoff.
|
||||
The new policy and licensing changes still need a concise summary in the next
|
||||
release, including the already-selected GPL-3.0-or-later application grant and
|
||||
the separately licensed policy material. Version selection and publication
|
||||
are not part of this plan.
|
||||
|
||||
Keep application source discovery and domain rules in `internal/config`;
|
||||
CLI parsing/output stays in `internal/adapter/cli`. Promptkit remains responsible
|
||||
for prompt/profile/schema parsing, backend semantics, credentials, and engine
|
||||
behavior. Keep one shared server engine and existing HTTP artifact policy.
|
||||
No HTTP schema, execution-report, request-timeout, or retry-orchestration change
|
||||
is part of this plan.
|
||||
## Common Execution Rules
|
||||
|
||||
For every stage:
|
||||
1. Inspect status and relevant diffs before each stage. Preserve unrelated
|
||||
changes; do not silently include them in the stage commit.
|
||||
2. Read the selected upstream files completely before adopting them. Compare
|
||||
directly with local files; do not reconstruct historical adoption baselines.
|
||||
3. Start from upstream text, remove the complete Base Policy Template section,
|
||||
and apply only the customizations selected below. Preserve shared language
|
||||
verbatim, including its meaning and strength. Do not retain old paraphrases
|
||||
merely because they are familiar or add prohibitions for hypothetical risks.
|
||||
4. For each policy adopted in that stage, set the target Base Policy Version,
|
||||
the actual adoption date, and an Upstream Source link:
|
||||
`https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/FILE.md`.
|
||||
Substitute the actual filename. Do not stamp a source on a policy before
|
||||
incorporating it. Intermediate commits may legitimately have mixed versions.
|
||||
5. Update the single policy-attribution entry as its copied/adapted scope grows.
|
||||
Do not claim later-stage material has already been adopted.
|
||||
6. Validate affected text, links, notices, and diff; record concise completion
|
||||
evidence under the completed stage here. Commit each coherent stage with a
|
||||
short plain-English message under the agent policy. Do not push or publish.
|
||||
|
||||
1. Inspect the working tree and relevant code/tests through the repository's
|
||||
code-discovery guidance. Preserve unrelated changes.
|
||||
2. Implement the listed outcome and only supporting refactoring it needs.
|
||||
Internal names below are selected implementation guidance, not public APIs
|
||||
or immutable package-layout contracts.
|
||||
3. Update canonical current-state docs when behavior lands. Until Stage 3 the
|
||||
new loader is internal preparation, not an advertised executable feature.
|
||||
Never claim later stages are implemented.
|
||||
4. Run focused tests and the development guide's baseline validation for code
|
||||
changes. Tests stay offline, deterministic, and free of real credentials.
|
||||
Reuse existing coverage rather than cloning ConfigKit's parser test matrix.
|
||||
5. Format changed Go files, inspect the diff, validate affected docs/examples,
|
||||
record stage status/evidence here, and commit the coherent unit. Do not push,
|
||||
tag, publish, or add new release gates.
|
||||
Do not change Go code, module pins, tests, release scripts, CI, accepted ADR
|
||||
decisions, or published release notes. Do not introduce recurring sync checks,
|
||||
license approval rounds, release gates, or blanket source headers. Preserve
|
||||
the application grant and dependency terms. Standard license text must remain
|
||||
verbatim even if a generic whitespace check dislikes publisher formatting.
|
||||
|
||||
### Application Configuration Definition
|
||||
## Stage 1: Adopt OSS Rules And Establish Licensing Notices
|
||||
|
||||
Use a new `Document` type in `internal/config` for the native configuration
|
||||
shape. It replaces the old on-disk `Config` after CLI cutover. Keep the familiar
|
||||
YAML field names:
|
||||
**Status: Complete.** OSS language was compared with the pinned source after
|
||||
the approved metadata and example changes. The CC-BY-SA text matches its pinned
|
||||
source byte-for-byte; attribution and navigation were checked against the
|
||||
specified format and local paths.
|
||||
|
||||
| YAML path | Go shape | Default and selected meaning |
|
||||
| --- | --- | --- |
|
||||
| `prompt_dir`, `profile_dir` | `string` | Empty; no source configured. |
|
||||
| `schema_dir` | `string` | Existing schema-directory default. Empty remains empty at the application boundary; Promptkit owns any subsequent framework default. |
|
||||
| `transient_retries` | `*int` | Nil; omitted/null delegates, zero disables additional attempts. |
|
||||
| `server` | Non-pointer struct | Its children receive typed defaults; null is invalid. |
|
||||
| `server.addr` | `string` | Existing listen-address default when absent; explicit empty is passed unchanged to the standard HTTP server, not replaced with the Scriptorium default. |
|
||||
| `server.artifact_root` | `string` | Empty; HTTP file input remains disabled. |
|
||||
| Three `server.max_*_bytes` fields | `int64` | Existing defaults; explicit zero disables the respective limit; null is invalid. |
|
||||
| `defaults` | Non-pointer struct | Contains `render_format`; null is invalid. |
|
||||
| `defaults.render_format` | `string` | Existing text default; resolved value must be text or json. Explicit empty is invalid, not defaulted. |
|
||||
| `backends` | `map[string]BackendDocument` | Nil; null is permitted, an empty mapping follows ConfigKit semantics. |
|
||||
Files: `docs/policy/oss.md`, `docs/oss/attribution.md`,
|
||||
`docs/oss/licenses/CC-BY-SA-4.0.txt`, `COPYRIGHT`, `README.md`,
|
||||
and the footer portion of `docs/release.md`.
|
||||
|
||||
`BackendDocument` keeps `endpoint string`, `api_key_env string`,
|
||||
`extra_params map[string]any`, `concurrency_limit int`, and
|
||||
`queue_capacity *int`. Scalar nulls are invalid; nullable maps/pointers retain
|
||||
native semantics. No catalog IDs or Promptkit fields are added.
|
||||
1. Read upstream OSS v1.8, COPYRIGHT, the canonical
|
||||
`examples/licensing/policy-attribution.md`, and referenced licensing
|
||||
examples at their pinned URLs. Adopt OSS v1.8 with metadata as above.
|
||||
Remove template-only content; retain upstream common wording and its
|
||||
existing commit-pinned example links. Customize the README example to
|
||||
Scriptorium and GPL v3 or later. No other OSS exception is selected.
|
||||
2. Copy the complete CC-BY-SA-4.0 reference text from the selected revision
|
||||
into the named local license file and compare it byte-for-byte with that
|
||||
source. Do not copy the rest of the reference collection or add CC0 merely
|
||||
because example formatting is used.
|
||||
3. Reformat the attribution document to the exact v1.8 House Format. Use
|
||||
`# Open Source Attribution Notices`, immediately followed by entries.
|
||||
Place Standard Repository Policies first, using the canonical entry,
|
||||
with its COPYRIGHT, LICENSE, and Source URLs pinned to the selected full
|
||||
commit. In this stage identify `docs/policy/oss.md` as the newly adapted
|
||||
material. Do not research or make claims about prior adoption provenance.
|
||||
4. Preserve the eight existing dependency entries and their imported commits,
|
||||
copyright wording, SPDX expressions, and required notices. Optional module
|
||||
identification paragraphs may retain versions currently in source labels.
|
||||
Remove the introductory prose, missing-copyright filler, and editorial
|
||||
YAML license explanations. Preserve the factual MIT AND Apache-2.0
|
||||
expressions. Use actual upstream filename labels, local license names,
|
||||
terminal periods, and the exact `[Source](COMMIT_URL).` source form.
|
||||
Do not upgrade dependencies or relabel their grants.
|
||||
5. Add a scoped paragraph to COPYRIGHT stating that material adapted from
|
||||
Standard Repository Policies remains CC-BY-SA-4.0, with
|
||||
`docs/oss/attribution.md` identifying affected material and links. This
|
||||
covers the scoped material as stages add it; it does not relicense unrelated
|
||||
application code or documentation. Keep the existing GPL grant and LICENSE.
|
||||
6. Correct the README ending to link GPL v3 or later to COPYRIGHT and keep
|
||||
the attribution link. Change the release-procedure footer to absolute
|
||||
immutable-tag COPYRIGHT, LICENSE, and ATTRIBUTION links, updating the
|
||||
references to the number of URLs. Change no publication commands.
|
||||
Do not retrofit published notes or create a release note/version now.
|
||||
|
||||
The fresh defaults factory reads existing `internal/defaults` and format
|
||||
constants, not a duplicated set of literals. Normalization trims surrounding
|
||||
whitespace from application directory strings, artifact root, and server
|
||||
address; cleans only nonempty application paths; and lowercases/trims
|
||||
`defaults.render_format`. Empty paths remain empty: never let
|
||||
`filepath.Clean("")` turn disabled/unset into `.`. Record actual changes with
|
||||
`configkit.Normalize`, using value-free reasons. Do not normalize backend
|
||||
fields or parameter values on Promptkit's behalf.
|
||||
Acceptance: OSS text matches the pinned source except the approved project
|
||||
example and metadata; attribution follows the prescribed format; the added
|
||||
license text is faithful; project and dependency grants remain unchanged.
|
||||
Check affected local paths and upstream notice/example destinations. Missing
|
||||
copyright fields are omitted, not explained with agent-authored commentary.
|
||||
|
||||
The read-only validator reports negative application size limits, negative
|
||||
nonnull application retries, and invalid render format through
|
||||
`Validation.Error` at their field paths. It does not print rejected values.
|
||||
Do not call the existing format parser's empty-as-default branch for this field.
|
||||
Do not add endpoint, backend ID, credential-presence, directory-existence,
|
||||
address-format, or positive-only-capacity checks. Existing Promptkit and
|
||||
command-specific validation retains those responsibilities where applicable.
|
||||
## Stage 2: Adopt Provenance, Agent Guidance, And Documentation Ownership
|
||||
|
||||
## Stage 1: Add The Dependency And Native Application Definition
|
||||
**Status: Complete.** The three policies carry the selected versions, source
|
||||
links, and local adoption date; shared text and the orientation template were
|
||||
compared with the pinned source. The seven-link reading guide and local links
|
||||
were checked, and attribution names only the incorporated material.
|
||||
|
||||
**Status: Complete.** The pinned dependency, native definition, focused
|
||||
presence/normalization/validation tests, and commit-specific attribution are in
|
||||
place. The existing executable loader remains active pending the command cutover.
|
||||
Files: new `docs/policy/meta.md`, `docs/policy/agents.md`,
|
||||
`docs/policy/documentation.md`, root `AGENTS.md`,
|
||||
`docs/development.md`, and the policy attribution entry.
|
||||
|
||||
Primary files: `go.mod`, `go.sum`, new focused files under `internal/config`,
|
||||
and `docs/oss/attribution.md`.
|
||||
1. Adopt meta v1.0 and agents v1.3 verbatim after template-section removal
|
||||
and metadata substitution. Keep meta's live project and main-branch
|
||||
adoption-guide discovery URLs; its own Upstream Source is commit-pinned.
|
||||
Retain local relative links to developer guidance and attribution.
|
||||
2. Adopt documentation v1.11. Customize only applicable topic-map rows:
|
||||
configuration remains application configuration, framework formats belong
|
||||
to PromptKit, consumers cover executable use and migration rather than a
|
||||
Scriptorium public Go API, and integrations cover Scriptorium-owned
|
||||
executable/process contracts. Keep upstream rows for meta, COPYRIGHT,
|
||||
LICENSE, and attribution. Remove instructional “if applicable” qualifiers
|
||||
from selected rows. Preserve the rest of the shared language.
|
||||
3. Use the upstream ADR lifecycle and examples guidance without retaining
|
||||
generic local expansions. This does not edit accepted ADRs or change their
|
||||
decisions. Metadata maintenance follows the adoption guide through meta,
|
||||
rather than a duplicate custom rule set.
|
||||
4. Adapt upstream `agents/AGENTS.md` into root AGENTS.md. Preserve any actual
|
||||
repository-specific code-discovery instructions; do not copy environment-
|
||||
injected instructions into the file just because they appeared in a session.
|
||||
Do not copy upstream's own root AGENTS.md.
|
||||
5. Add the adoption guide's Policy Reading Guide table and selection bullets
|
||||
verbatim to the developer guide with the seven local links. Replace its
|
||||
unconditional architecture-reading instruction and duplicated policy-reading
|
||||
prose with this selective guide. Retain project orientation, task-specific
|
||||
contract rows, dependency boundaries, and baseline validation commands.
|
||||
Avoid maintaining competing policy trigger rules in multiple places.
|
||||
6. Expand the policy entry's Material sentence to identify the adopted OSS,
|
||||
meta, agents, and documentation policies plus adapted root AGENTS.md and
|
||||
the copied Policy Reading Guide section of docs/development.md. Mark them
|
||||
adapted for this repository; do not imply the whole developer guide or
|
||||
unrelated tooling instructions have changed license.
|
||||
|
||||
1. Add ConfigKit at the selected release. Retain Promptkit v0.11.0 and its
|
||||
selected catalogs. Provision dependencies outside offline test execution.
|
||||
ConfigKit's yaml/v4 release-candidate dependency is the reviewed upstream
|
||||
choice, not an instruction to upgrade its parser independently.
|
||||
2. Implement `Document`, `BackendDocument`, the fresh defaults factory,
|
||||
recorded resolver, and read-only validator described above. Keep the old
|
||||
loader operational until Stage 3 so this stage remains independently
|
||||
buildable; this temporary development state is not a shipped compatibility
|
||||
mode or a second user-selectable configuration path.
|
||||
3. Test the new definition using real `configkit.Load[Document]` with
|
||||
`Bytes` and `NoSource`. Cover explicit zero/empty/null distinctions,
|
||||
retry/queue nil-versus-zero, safe application validation, and a normalized
|
||||
path whose effective output agrees with the returned value. Include nested
|
||||
unknown fields and a representative dynamic numeric parameter.
|
||||
4. Add ConfigKit and yaml/v4 attribution from their selected source material.
|
||||
Resolve the imported yaml/v4 commit from release/module metadata. Preserve
|
||||
actual copyright statements; do not infer a project statement from the
|
||||
FSF license-document copyright. Use applicable SPDX expressions, local
|
||||
standard texts, and commit-pinned upstream license/notice links. Reuse GPL,
|
||||
LGPL, MIT, and Apache texts where applicable, including companion links.
|
||||
Retain yaml.v3 attribution because Promptkit still incorporates it.
|
||||
5. Document the internal definition as preparation in the relevant internal
|
||||
guide without claiming the CLI has switched. No current configuration
|
||||
contract changes yet.
|
||||
Acceptance: all stage policies have their own correct source link and version;
|
||||
orientation selects policies by task, including meta for adoption work; local
|
||||
links resolve; no upstream handbook or example collection was copied.
|
||||
Generic language differences from upstream are eliminated, not rephrased.
|
||||
|
||||
Acceptance: the dependency and definition compile, focused tests demonstrate
|
||||
native semantics and audited normalization, and attribution follows the OSS
|
||||
policy. Existing executable behavior still passes its tests.
|
||||
## Stage 3: Adopt Architecture And Testing With Narrow Local Decisions
|
||||
|
||||
## Stage 2: Build Discovery And The Shared Loading Boundary
|
||||
**Status: Complete.** The three shared architecture sections and the common
|
||||
testing text match the pinned source. Local architecture decisions were checked
|
||||
against the accepted ADRs and internal guides; focused test ownership and the
|
||||
expanded attribution scope were reviewed without changing application code.
|
||||
|
||||
**Status: Complete.** Ordered source discovery, one ConfigKit load, typed
|
||||
diagnostics, and settings conversion are covered by focused file/default and
|
||||
override tests. Existing commands still use the old entry point until cutover.
|
||||
Files: `docs/policy/architecture.md`, `docs/policy/testing.md`,
|
||||
policy attribution entry, and focused internal docs only if moving existing
|
||||
implementation detail requires it.
|
||||
|
||||
Primary files: `internal/config` and its tests; `docs/internal/sources.md`.
|
||||
1. Read the existing architecture, relevant accepted ADRs, source/adapter
|
||||
internal guides, and the pinned architecture v1.3 template. Retain upstream
|
||||
Purpose And Ownership, Architectural Approach, and Adopted Constraints And
|
||||
Implemented Structure text verbatim. Replace the Application-Specific
|
||||
Topics placeholder with Scriptorium's existing substantive decisions.
|
||||
2. Preserve public PromptKit/ConfigKit responsibility boundaries, definition
|
||||
support, strict decoding, presence handling, HTTP artifact containment,
|
||||
request independence and concurrency-safe shared capacity, credential/error
|
||||
boundaries, dependency restrictions, and explicit workflow non-goals.
|
||||
Retain the existing lexical containment and privileged-host threat scope,
|
||||
not a stronger filesystem-sandbox promise. Customize the trust discussion
|
||||
to those decisions rather than retaining instructional example prose.
|
||||
3. Correct system shape to include run, render, serve, inspect, and config.
|
||||
Link to internal documentation for concrete package inventory/mechanics.
|
||||
Where material moves, preserve it in its canonical internal owner without
|
||||
duplicating it. Do not introduce new wrappers, ports, orchestration, or
|
||||
package constraints merely to “implement” the architectural recommendation.
|
||||
4. Adopt testing v1.3 common text verbatim. Add one clearly identified local
|
||||
test-ownership section for configuration, CLI, HTTP, formatting, architecture
|
||||
guards, and PromptKit/ConfigKit boundaries. Preserve the existing distinction
|
||||
between adoption/integration fixtures and upstream exhaustive tests.
|
||||
Retain a short application-specific note explaining HTTP containment and
|
||||
shared-state risks where useful; do not replace upstream risk-based coverage
|
||||
guidance or create percentage targets, quotas, or new test requirements.
|
||||
5. Add accurate source/version/date metadata and extend the policy attribution
|
||||
scope to architecture and testing. Record any moved adapted prose in the
|
||||
Material scope if it is placed outside the already identified files.
|
||||
|
||||
1. Add `LoadOptions` with `Path string`, `Explicit bool`, `Overlay string`,
|
||||
and `Overrides []configkit.Override`, plus
|
||||
`Load(LoadOptions) (*configkit.Result[Document], error)`.
|
||||
Discovery chooses a source; the one ConfigKit call owns actual file reading
|
||||
and decoding. Return the result so consumers retain the frozen inspection
|
||||
snapshot as well as the typed configuration.
|
||||
2. With `Explicit=true`, pass the selected path to `configkit.File`;
|
||||
an explicitly empty path is invalid, not implicit discovery or a fallback
|
||||
to the old system filename. Do not silently trim a source filename into a
|
||||
different filename. ConfigKit validates and resolves file sources.
|
||||
3. With `Explicit=false`, ignore the option's path value and examine the
|
||||
existing ordered implicit search locations. Only nonexistence permits
|
||||
examining the next candidate. Other stat failures are errors. Select the
|
||||
first existing candidate and let ConfigKit load it. A selected file's later
|
||||
disappearance/read/parse failure does not restart discovery.
|
||||
4. If neither implicit candidate exists, use `NoSource`. Initially leave
|
||||
imports disabled and the overlay empty; Stage 4 enables composition.
|
||||
Defaults-only loads still accept explicit application overrides. Never
|
||||
reinterpret an empty file as `NoSource`.
|
||||
5. Pass overrides into the ConfigKit call before decoding/validation; do not
|
||||
validate a separately merged lower configuration first. Native parsing and
|
||||
composition failures still follow the upstream lifecycle and are not
|
||||
bypassed by CLI overrides.
|
||||
6. Add a small `Settings(Document) AppSettings` conversion for existing
|
||||
executable wiring. It copies resolved fields, maps the already-validated
|
||||
format, and converts the backend map into ID-sorted backend settings.
|
||||
It performs no file IO, normalization, credential lookup, semantic backend
|
||||
checks, or additional defaults. Dynamic values retain their decoded shapes.
|
||||
7. Preserve ConfigKit's typed `*LoadError` through wrapping so the CLI can
|
||||
render safe structured diagnostics. Discovery-only errors are concise and
|
||||
quote paths safely; no new public error taxonomy is needed.
|
||||
8. Test ordered discovery with temporary paths rather than host system files,
|
||||
explicit missing/empty paths, empty-file rejection versus `{}`,
|
||||
defaults-only loading, source records, override-before-validation behavior,
|
||||
sorted backend conversion, and preservation of zero/nullable values.
|
||||
Remove no existing entry point until all its CLI callers migrate in Stage 3.
|
||||
Acceptance: direct comparison isolates only the roadmap's justified local
|
||||
decisions; shared text matches upstream. Architecture describes existing
|
||||
behavior accurately without implementation work. Testing preserves ownership
|
||||
without duplicating upstream matrices or imposing new coverage gates.
|
||||
|
||||
Acceptance: real files and defaults-only inputs produce one reusable result,
|
||||
runtime conversion agrees with it, and tests do not depend on machine-wide
|
||||
configuration or secrets. The old and new internals are temporarily buildable,
|
||||
with no new user-visible mode.
|
||||
## Stage 4: Adopt Release Policy Without Changing Publication Behavior
|
||||
|
||||
## Stage 3: Cut Existing Commands Over And Remove The Legacy Loader
|
||||
**Status: Complete.** The shared release language matches the pinned source;
|
||||
the local selections match the existing script, hosted workflow, and runbook.
|
||||
Commands, build targets, recovery behavior, and the three-link footer remain
|
||||
unchanged. Attribution now names all seven adopted policies.
|
||||
|
||||
**Status: Complete.** All five command modes use the shared ConfigKit loader;
|
||||
the legacy decoder and merge path are removed. CLI and configuration contracts
|
||||
now describe native YAML and override behavior. Full test, race, vet, build,
|
||||
and diff checks passed.
|
||||
Files: `docs/policy/release.md`, `docs/release.md`, attribution entry.
|
||||
|
||||
Primary files: `internal/adapter/cli/run.go`, `inspect.go`,
|
||||
`internal/config/config.go`, and associated tests.
|
||||
1. Read the current release policy, procedure, script, and hosted workflow;
|
||||
inspect them read-only. Adopt upstream release v1.4 common wording.
|
||||
2. Add a compact Scriptorium-specific section preserving the established
|
||||
selections: main/origin, branch-before-tag publication with exact remote
|
||||
candidate agreement, annotated tags derived from the checked-in note,
|
||||
stable releases only, asynchronous Linux binaries/checksums, one race-enabled
|
||||
offline test invocation, and source-boundary guards. Keep rationale for
|
||||
selected gates in policy and command/target details in the procedure.
|
||||
3. Retain upstream's general alternatives verbatim but state which existing
|
||||
approach Scriptorium selects. Atomic push and source-only release remain
|
||||
template-supported alternatives, not newly supported Scriptorium workflows.
|
||||
Preserve successful tag publication as completion; no CI polling, artifact
|
||||
availability, or consumer installation gate is added.
|
||||
4. Align the procedure with this allocation without changing its commands,
|
||||
required checks, supported platforms, or failure-recovery behavior. Confirm
|
||||
the Stage 1 three-link footer survives hosted-body reuse. Do not run the
|
||||
publication command or mutate remote state to validate documentation.
|
||||
5. Add metadata and expand the policy attribution scope to all seven policies.
|
||||
The final Material description also identifies adapted AGENTS.md and the
|
||||
developer-guide reading section, plus any actually moved adapted text.
|
||||
|
||||
1. Route run, render, serve, inspect prompt, and inspect profile through the
|
||||
shared `Load` and `Settings` boundary. Preserve the explicit presence of
|
||||
`--config` in every parser. Centralize the small application-flag mapping
|
||||
rather than reproduce it in each command.
|
||||
2. Use `flag.FlagSet.Visit` (or the existing explicit-set helper) to create
|
||||
one `configkit.Override` per explicitly supplied application flag. Use
|
||||
`configkit.Keys`, built-in scalar values, and a safe `Flag` label containing
|
||||
only the flag name. Standard flag parsing's last occurrence supplies the
|
||||
single override; do not emit duplicate records or parser defaults.
|
||||
Acceptance: the existing release workflow still satisfies the resulting policy
|
||||
with no script/CI changes. Source completion, delivery status, immutability,
|
||||
tag type, and validation obligations are unchanged. All seven source links
|
||||
identify their own file at the selected full commit.
|
||||
|
||||
| Flag | Application path | Existing command scope after cutover |
|
||||
| --- | --- | --- |
|
||||
| `--prompt-dir` | `prompt_dir` | run, render, serve, inspect prompt |
|
||||
| `--profile-dir` | `profile_dir` | run, render, serve, inspect profile |
|
||||
| `--schema-dir` | `schema_dir` | run, render, serve |
|
||||
| `--addr` | `server.addr` | serve |
|
||||
| `--artifact-root` | `server.artifact_root` | serve |
|
||||
| `--max-request-bytes` | `server.max_request_bytes` | serve |
|
||||
| `--max-artifact-bytes` | `server.max_artifact_bytes` | serve |
|
||||
| `--max-response-bytes` | `server.max_response_bytes` | serve |
|
||||
## Stage 5: Verify Language Parity And Complete The Documentation Handoff
|
||||
|
||||
Register the schema-directory flag on render as well as run/serve so the
|
||||
advertised application path override is consistently usable. This is not a
|
||||
general expansion of runtime/provider flags to other commands.
|
||||
3. Keep `--format`, `--out`, request `--transient-retries`, prompt/profile
|
||||
selection, model overrides, timeouts, inputs, variables, and reporting
|
||||
options outside the application configuration tree. In particular,
|
||||
`render --format` overrides that invocation's output format without
|
||||
rewriting `defaults.render_format`; omitted format inherits its resolved
|
||||
application value. Existing invocation-only parsing remains unchanged.
|
||||
4. Remove post-load directory trimming/cleaning/defaulting from argument
|
||||
finalizers, including unconditional schema-path cleaning. Keep only
|
||||
invocation-owned transformations such as output-file paths. Explicit
|
||||
empty profile/artifact-root overrides must clear file-provided values;
|
||||
explicit empty prompt directory must reach the existing execution
|
||||
prerequisite rather than revive the lower value.
|
||||
5. Keep existing command prerequisites: run/render/serve and prompt inspection
|
||||
need their effective prompt directory as currently required; profile
|
||||
inspection does not acquire a prompt-directory requirement. All commands
|
||||
still perform the common application schema validation. Do not introduce
|
||||
eager filesystem or credential validation for inspection.
|
||||
6. Add one CLI diagnostic path using `errors.As` and
|
||||
`configkit.WriteDiagnostics` for load errors. Carry successful load warnings
|
||||
to the command boundary and render them once on stderr before execution or
|
||||
output. Handle diagnostic writer errors as command failures. Do not flatten
|
||||
structured failures into raw parser text or print rejected values.
|
||||
Preserve existing process exit classifications; application/parse/load
|
||||
failures are exit 1, not generated-output validation exit 2.
|
||||
7. Remove the old YAML decoder, `strictInteger.UnmarshalYAML`, old on-disk
|
||||
types, `applyConfig`, `ApplyCLIOverrides`, and unused compatibility
|
||||
sentinels/helpers after migrating all callers/tests. Keep only one defaults
|
||||
factory. Remove the direct yaml.v3 import; module tidy may retain yaml.v3
|
||||
as an indirect Promptkit dependency.
|
||||
8. Update tests to the deliberate breaking semantics, not the legacy behavior.
|
||||
Protect explicit empty path clearing, scalar-null rejection, unknown fields,
|
||||
rejected empty/multi-document input, one representative YAML policy change,
|
||||
unchanged request-versus-engine retry precedence, absent optional
|
||||
credentials, and command-specific inspection prerequisites.
|
||||
9. Update configuration and CLI contracts, source/adapter internals, architecture
|
||||
ownership, and the contributor reading guide for the delivered cutover.
|
||||
Preserve existing application defaults, Promptkit definition support,
|
||||
HTTP containment, shared capacity, and report behavior. Adjust the current
|
||||
CLI claim that every command requires a prompt directory to match actual
|
||||
command-specific requirements.
|
||||
**Status: Complete.** All seven policies were compared directly with the pinned
|
||||
upstream files; differences are limited to metadata, removed template text,
|
||||
the selected project example and topic rows, and the identified local sections.
|
||||
The copied license matches byte-for-byte. A Markdown-aware check resolved 86
|
||||
local links; historical plan references resolve to Git objects. Attribution,
|
||||
notice scope, release navigation, and the final documentation-only diff were
|
||||
reviewed without changing application or publication artifacts.
|
||||
|
||||
Acceptance: all existing commands use ConfigKit, no legacy parser or second
|
||||
application merge remains, relevant tests pass, and diagnostics and docs describe
|
||||
the native breaking behavior. Imports/overlays and new inspection commands are
|
||||
not yet advertised.
|
||||
Files: this plan, the feature roadmap, and only affected documentation needing
|
||||
correction within the preceding stages' scope.
|
||||
|
||||
## Stage 4: Enable Explicit Imports And Selected Configuration Overlays
|
||||
1. Compare all seven adopted documents directly with their selected upstream
|
||||
counterparts. Account for metadata, removed template sections, approved
|
||||
substitutions, and the narrow local sections. Correct every remaining
|
||||
non-substantive wording difference. Do not turn this comparison into a
|
||||
permanent script, CI requirement, or release gate.
|
||||
2. Check there are no adoption placeholders, copied template-only instructions,
|
||||
absent local example links, stale BSD descriptions of Scriptorium itself,
|
||||
or contradictory selective-reading directions. Legitimate BSD dependency
|
||||
attribution remains. Validate links using Markdown-aware handling so
|
||||
illustrative syntax in inline code is not treated as a broken real link.
|
||||
3. Confirm per-document source metadata, the policy entry's exact scope,
|
||||
COPYRIGHT's scoped license treatment, existing dependency grants/notices,
|
||||
and the byte-for-byte new license text. Keep example/source links pinned
|
||||
and public discovery links current. Check footer paths in the candidate;
|
||||
unpublished release tags need not resolve online.
|
||||
4. Review affected roadmap references to implementation.md. Where a link
|
||||
specifically means an old completed plan, replace it with a clear historical
|
||||
Git reference from this plan, not this new policy sequence. Preserve
|
||||
deferred application features and historical completion evidence.
|
||||
Current release directions link to the canonical procedure, not an old
|
||||
two-link footer. Do not rewrite published release notes.
|
||||
5. Mark only actually delivered stages complete with concise evidence here.
|
||||
Update the feature roadmap's status to delivered and keep its end-state
|
||||
focus. Record the next-release summary described above without choosing a
|
||||
version, creating a tag, or claiming publication.
|
||||
6. Run diff/whitespace and affected-document/link checks. Do not reformat
|
||||
verbatim license text to satisfy a style check. No Go test/build rerun is
|
||||
necessary for this documentation-only work; no executable example or
|
||||
publication command needs changing. Inspect status and staged diff, commit,
|
||||
and report the commit and remaining work under the agent policy.
|
||||
|
||||
**Status: Complete.** File-backed loads support explicit imports and one
|
||||
selected overlay under the selected file's canonical directory. All five
|
||||
existing command modes accept `--config-overlay`; real-file composition and a
|
||||
render workflow are tested. The composed example and contracts are updated;
|
||||
full test, race, vet, build, and diff checks passed.
|
||||
|
||||
Primary files: shared loader, CLI source-selection wiring, configuration and
|
||||
CLI tests, maintained configuration examples.
|
||||
|
||||
1. Enable `Options.Imports` for file-backed loads. Leave it false for
|
||||
`NoSource`, which rejects imports. Use ConfigKit's default canonical
|
||||
selected-file directory as the root; do not supply a wider filesystem root
|
||||
or add application traversal code.
|
||||
2. Wire `LoadOptions.Overlay` into `Options.Overlay`. Register
|
||||
`--config-overlay` on all five existing configuration-loading command
|
||||
modes. Treat the value exactly as an upstream overlay name: no trimming,
|
||||
case folding, extension fallback, path expansion, or local inheritance.
|
||||
Empty and exact lowercase default mean no active overlay under v0.4.0.
|
||||
A requested active overlay without a selected base source fails through
|
||||
ConfigKit; do not manufacture an empty base file or root.
|
||||
3. Use native `configkit.imports` directives for explicit paths/globs. The
|
||||
application enables the feature without requiring a second CLI opt-in;
|
||||
absent directives cause no discovery. Retain conflict-based base
|
||||
composition and native overlay replacement/null semantics.
|
||||
4. Preserve working-directory-relative application path values even when
|
||||
authored in fragments or overlays. Configuration-source containment is
|
||||
not the HTTP artifact policy and is not applied to prompt/schema paths.
|
||||
5. Add focused real-file tests for disjoint backend fragments, an import
|
||||
conflict, overlay replacement, explicit CLI precedence, missing selected
|
||||
overlay, and no-base overlay failure. Verify `--profile` still selects a
|
||||
Promptkit execution profile independently of `--config-overlay`.
|
||||
One real command workflow proves wiring; upstream owns exhaustive glob,
|
||||
symlink, cycle, and parser-limit tests.
|
||||
6. Add a small synthetic import/overlay example under `examples/`; preserve
|
||||
a simple single-file quickstart. Update config/CLI contracts and operations
|
||||
guidance for the new features, root selection, and relative-value policy.
|
||||
|
||||
Acceptance: supported commands load the same native composition pipeline;
|
||||
imports are explicit, overlays remain distinct from execution profiles, and no
|
||||
new scanning, remote acquisition, or path policy is introduced.
|
||||
|
||||
## Stage 5: Add Application Validation, Effective Output, And Source Inspection
|
||||
|
||||
**Status: Complete.** Application-only validation, effective YAML, and ordered
|
||||
JSON source inspection use one shared ConfigKit result without an engine. Tests
|
||||
cover source composition, CLI provenance, stream failures, and the credential
|
||||
reference boundary. Public and internal contracts are updated; full test,
|
||||
race, vet, build, and diff checks passed.
|
||||
|
||||
Primary files: a focused `internal/adapter/cli/config.go`, shared config
|
||||
definition, CLI dispatch/help/tests, and canonical CLI/config documentation.
|
||||
|
||||
1. Apply the maintainer's selected inspection policy: no redaction for
|
||||
`extra_params`, including historical values. API-key values are the only
|
||||
relevant secrets, but this schema stores only `api_key_env` reference names.
|
||||
Keep those names visible and never resolve them in the ConfigKit load.
|
||||
Do not add secret tags to the reference name or parameter container, a
|
||||
catch-all secret predicate, sensitive-key guessing, or a selective masking
|
||||
interface. Actual credentials remain with Promptkit; raw API-key fields
|
||||
remain rejected. Use upstream inspection renderers without adding a second
|
||||
value-rendering path or a synthetic credential field.
|
||||
2. Add a top-level `config` command family using the existing standard-library
|
||||
flag style. The selected interfaces are:
|
||||
|
||||
| Command | Success stdout |
|
||||
| --- | --- |
|
||||
| `scriptorium config validate [flags]` | Empty; exit status communicates application validation success. |
|
||||
| `scriptorium config show [flags]` | `Result.WriteEffective` redacted YAML. |
|
||||
| `scriptorium config sources [flags]` | One newline-terminated JSON array of source records. |
|
||||
| `scriptorium config explain --path <pointer> [flags]` | Added in Stage 6. |
|
||||
|
||||
These are prospective interface specifications, not commands to execute
|
||||
before their stages are implemented.
|
||||
3. All configuration subcommands accept `--config`, `--config-overlay`,
|
||||
and the eight application override flags in Stage 3's table, regardless
|
||||
of which execution command normally uses them. They do not accept request,
|
||||
credential, backend-editing, output-format, or output-file flags. Shell
|
||||
redirection is sufficient for these inspection outputs. No positional
|
||||
arguments are accepted.
|
||||
4. Load exactly once through the common loader. Do not construct a Promptkit
|
||||
engine, restricted artifact reader, listener, or client. Missing prompt
|
||||
directories, unselected/absent credentials, and framework backend validity
|
||||
are not additional application-inspection gates. Invalid application
|
||||
types/ranges/format still fail. Validation describes application load
|
||||
validity, not end-to-end executability.
|
||||
5. For sources, map `Result.Sources()` to a small local DTO with JSON keys
|
||||
`id`, `label`, `layer` (always present), and `path` (omit when empty).
|
||||
Preserve upstream source order; emit `[]\n` for defaults-only input without
|
||||
overrides. Include synthetic CLI sources where present. Do not marshal
|
||||
opaque ConfigKit implementation objects. The standard JSON encoder escapes
|
||||
control characters; no custom terminal rendering is necessary.
|
||||
6. Diagnostics/warnings go only to stderr through the shared diagnostic helper.
|
||||
Successful operations exit 0; parse/load/output/diagnostic-write failures
|
||||
exit 1. No exit 2 meaning is introduced for configuration validation.
|
||||
Ordinary writer failures may leave partial output; do not promise atomic
|
||||
streams or buffering of an entire configuration.
|
||||
7. Test defaults-only show/sources, a composed load with CLI provenance,
|
||||
explicit empty clearing, normalized effective values, failed loads producing
|
||||
no successful stdout, and writer failure. Set a synthetic API-key environment
|
||||
variable: effective output must show its reference name, not its value.
|
||||
Repeat with the variable absent to establish that inspection does not require
|
||||
credentials. Assert that ordinary synthetic parameter values remain visible
|
||||
and runtime ExtraParams stay intact; no real environment or provider is used.
|
||||
8. Update CLI/config contracts, README navigation, subprocess integration,
|
||||
operations, and internal inventory to describe only these delivered modes.
|
||||
Retain the README's license/attribution ending.
|
||||
|
||||
Acceptance: validation, effective output, and source inspection use the same
|
||||
resolved configuration as execution, preserve stream separation, and honor the
|
||||
selected API-key boundary without masking or changing backend parameter data.
|
||||
|
||||
## Stage 6: Add Per-Path Explanation And Verify Credential Boundaries
|
||||
|
||||
**Status: Complete.** `config explain` uses required JSON Pointer paths and
|
||||
ConfigKit's snapshot renderer, including historical and normalized values.
|
||||
Tests cover root, escaped/numeric keys, unknown paths, writer failures, and
|
||||
synthetic credential-reference boundaries. Full test, race, vet, build, and
|
||||
diff checks passed.
|
||||
|
||||
Primary files: configuration command implementation/tests and CLI/config docs.
|
||||
|
||||
1. Implement `config explain` with the same selectors and override flags as
|
||||
Stage 5 plus a required, explicitly supplied `--path`. Parse using
|
||||
`configkit.ParsePath`; syntax is JSON Pointer, not dotted notation, a file
|
||||
path, or a URL fragment. Explicit `--path ""` selects the root; an omitted
|
||||
flag is an error. Preserve escaped and numeric mapping-key semantics.
|
||||
2. Use the successful shared result's `WriteExplanation`. Explain known
|
||||
effective and historical paths, including removed values. An unknown or
|
||||
malformed path exits 1 with no successful explanation output. Quote
|
||||
user-supplied paths safely if included in application diagnostics.
|
||||
Do not rebuild history, look up environment values, or reload sources.
|
||||
3. Keep the upstream human-readable renderer and its redaction semantics rather
|
||||
than inventing a JSON explanation schema or freezing the entire rendered
|
||||
prose as an application guarantee. Writer failures exit 1 and can leave
|
||||
partial output, as with effective output.
|
||||
4. Test a value's default/base/overlay/CLI history, recorded normalization,
|
||||
explicit equal-value writes, an escaped backend key, root selection, and
|
||||
an unknown path. Cover a displaced historical backend parameter value:
|
||||
it remains visible, including in a container/root explanation. Use distinct
|
||||
synthetic environment names and key values to verify reference names remain
|
||||
explainable but resolved API-key bytes are absent from all history/output.
|
||||
5. Update CLI/config docs and operations guidance with path syntax,
|
||||
historical-value meaning, representation differences, and sensitive
|
||||
identifiers/paths. Do not claim that redaction detects arbitrary secrets
|
||||
outside classified paths.
|
||||
|
||||
Acceptance: explain uses the existing snapshot and upstream semantics; its
|
||||
history matches the selected inputs and normalization, parameters remain
|
||||
visible, and explanation neither resolves nor discloses API-key values.
|
||||
|
||||
## Stage 7: Verify Integration, Finish Documentation, And Record Release Handoff
|
||||
|
||||
**Status: Complete.** The feature roadmap, command paths, dependency boundary,
|
||||
documentation, and attribution were audited. Maintained single-file and
|
||||
composed examples passed configuration inspection and no-provider rendering;
|
||||
the optional-credential/integer-parameter backend path passed with a local
|
||||
provider. The full test, race, vet, build, formatting, link, and diff checks
|
||||
passed. Release preparation is recorded below; no tag or publication occurred.
|
||||
|
||||
1. Review the feature roadmap against actual code. Confirm all five original
|
||||
command modes and all four new configuration subcommands use one definition
|
||||
and load pipeline. Remove any transitional loader, duplicated defaults,
|
||||
unused compatibility helpers, or post-snapshot configuration mutation.
|
||||
Do not add architecture machinery merely to assert a particular file layout.
|
||||
2. Exercise maintained single-file and import/overlay examples through the
|
||||
implemented configuration commands and a no-provider render workflow.
|
||||
Use focused backend integration evidence that dynamic integer parameters
|
||||
reach Promptkit correctly and missing optional credentials retain their
|
||||
established meaning. Use a local HTTP server only where provider serialization
|
||||
must be checked; never a real service or credential.
|
||||
3. Retain existing HTTP concurrency, containment, error mapping, retry,
|
||||
timeout, and report tests. Add a representative configuration-to-server
|
||||
wiring test only if existing coverage misses changed settings propagation;
|
||||
do not reproduce all upstream scheduling or HTTP cases.
|
||||
4. Run the development baseline on final code: `go test ./...`,
|
||||
`go test -race ./...`, `go vet ./...`, and
|
||||
`go build ./cmd/scriptorium`. Check formatting, affected examples/links,
|
||||
and `git diff --check`. Do not stage the built binary or scratch files.
|
||||
Compare any new standard license text byte-for-byte; preserve upstream
|
||||
whitespace rather than editing license wording to satisfy a style check.
|
||||
5. Ensure current configuration, CLI, subprocess, operations, internal docs,
|
||||
contributor routing, and architecture ownership agree. Testing policy
|
||||
should identify ConfigKit as the owner of exhaustive upstream loading tests,
|
||||
while Scriptorium owns application adoption tests. Change policy dates when
|
||||
revising policies, not base versions unless adopting new templates.
|
||||
Keep accepted ADR text and published release notes immutable.
|
||||
6. Record the release handoff below and mark only delivered stages complete.
|
||||
Update the feature roadmap's status, including the resolved inspection
|
||||
decision. Preserve deferred work. The next breaking release follows the
|
||||
release policy; version selection, candidate publication validation, release
|
||||
notes at that version, tag creation, and publishing are not this sprint.
|
||||
7. Commit the final coherent handoff and report validation evidence, remaining
|
||||
limitations, and any outstanding work without claiming source/binary
|
||||
publication or complete legal compliance.
|
||||
|
||||
Acceptance: the ConfigKit-native target is delivered with proportionate
|
||||
regression evidence and accurate documentation, and the workspace contains no
|
||||
temporary dependency substitutions or uncommitted implementation artifacts.
|
||||
|
||||
### Release Handoff To Retain
|
||||
|
||||
The upcoming release needs migration guidance for empty files versus `{}`,
|
||||
explicit empty values, nullable versus scalar fields, strict YAML/scalars,
|
||||
reserved keys and upstream size limits, and the invalid explicit-empty config
|
||||
path. Include imports/overlays, application path interpretation, CLI presence,
|
||||
inspection command scope, and the selected API-key-only secret policy. Explicit
|
||||
empty server address reaches standard HTTP server behavior instead of restoring
|
||||
Scriptorium's default; operators should supply their intended listen address.
|
||||
|
||||
Keep request retry overrides and Promptkit credential semantics distinct from
|
||||
application settings. Explain that configuration validation is not a provider
|
||||
probe or complete Promptkit definition validator, and that inspection output
|
||||
is not guaranteed reloadable. Include dependency/attribution changes and the
|
||||
existing LICENSE | ATTRIBUTION footer. Preserve the still-relevant Promptkit
|
||||
v0.11 release handoff identified above when preparing a combined next release.
|
||||
|
||||
### Implementation And Release Preparation Record
|
||||
|
||||
The ConfigKit v0.4.0 adoption is implemented in committed source. The next
|
||||
breaking release still needs version selection, version-matched release notes,
|
||||
candidate validation, tagging, and publication under the release policy; none
|
||||
has occurred as part of this work. Keep the earlier Promptkit v0.11 handoff
|
||||
linked above when preparing a combined release.
|
||||
|
||||
The release note should summarize the deliberate configuration migration:
|
||||
empty files now fail and `{}` means an empty mapping; explicitly empty strings
|
||||
and zero values override lower values; `null` follows declared nullable types;
|
||||
strict YAML rejects additional documents, anchors/aliases, unsupported scalar
|
||||
forms, and unknown fields; `configkit` is reserved and ConfigKit's source and
|
||||
resource limits apply. Explicit `--config ''` is invalid. Imports are opt-in
|
||||
per file directive, while `--config-overlay` selects one named overlay under
|
||||
the selected file's canonical directory; application path *values* remain
|
||||
process-working-directory-relative. Only explicitly supplied application CLI
|
||||
flags override configuration. An explicit empty server address is passed to
|
||||
the standard HTTP server and does not restore Scriptorium's default.
|
||||
|
||||
Document the four application-inspection modes and the selected policy:
|
||||
`extra_params`, including history, and `api_key_env` reference names remain
|
||||
visible, but actual API-key bytes are never resolved by ConfigKit. Inspection
|
||||
output can be sensitive and is not guaranteed reloadable. Application
|
||||
validation neither probes a provider nor completely validates Promptkit
|
||||
definitions. Keep request retry overrides and Promptkit's credential rules
|
||||
separate from application settings. Include the new dependency and attribution
|
||||
notices, and retain the existing LICENSE | ATTRIBUTION footer. Deferred
|
||||
secrets bootstrap, schema versioning, reload, and remote acquisition remain
|
||||
deferred; do not imply source or binary publication has happened.
|
||||
Acceptance: policy language is standardized with only justified local
|
||||
customization; notice/provenance arrangements describe reality; no runtime,
|
||||
dependency, publication, or historical-release change slipped into the diff.
|
||||
|
||||
## Open Questions
|
||||
|
||||
None remain for this scope. On 2026-09-26 the maintainer selected no redaction
|
||||
for `extra_params` and specified that the API key is the only secret requiring
|
||||
ConfigKit redaction. Stages 5–6 implement that decision through visible parameter
|
||||
values/reference names and the existing separation of actual credentials from
|
||||
application configuration. Do not reopen it or substitute blanket masking.
|
||||
|
||||
This does not claim automatic detection of credentials embedded in arbitrary
|
||||
strings or provider parameters. The application schema still rejects raw API-key
|
||||
fields, and Promptkit remains responsible for resolving named credential sources.
|
||||
None. The maintainer approved the public discovery URLs, the standard
|
||||
CC-BY-SA arrangement for copied policy material, the selected upstream revision,
|
||||
and the justified local variations. The existing application grant, dependency
|
||||
grants, and release approach remain unchanged; do not reopen them merely to
|
||||
perform this adoption.
|
||||
|
||||
@@ -1,63 +1,223 @@
|
||||
# OSS Policy Adoption
|
||||
# Standard Repository Policy Alignment
|
||||
|
||||
## Status
|
||||
## Status And Intent
|
||||
|
||||
Completed on 2026-09-26. The upstream template work proposed here is now
|
||||
available and adopted locally. This document records the adoption; the
|
||||
[OSS policy](../policy/oss.md) is the canonical owner of the ongoing rules.
|
||||
Agreed and delivered on 2026-09-28. This roadmap replaces the
|
||||
earlier licensing-only proposal with alignment of the complete applicable
|
||||
policy set and its supporting documentation. It defines the targeted end state
|
||||
and required changes; the [implementation plan](implementation.md) owns ordered
|
||||
stages and their verification.
|
||||
|
||||
The adopted baseline is the standard policy repository at commit
|
||||
`eea8bcd21a964b395e31971077d7fddb445f2c28`:
|
||||
The next release summary should mention the policy and licensing alignment,
|
||||
the already-selected GPL-3.0-or-later application grant, and the separate
|
||||
CC-BY-SA-4.0 treatment of adapted policy material. Version selection and
|
||||
publication remain release preparation, not part of this delivery.
|
||||
|
||||
- OSS policy base version 1.1;
|
||||
- documentation policy base version 1.4; and
|
||||
- release policy base version 1.2.
|
||||
The goal is identical policy language across adopting projects except where a
|
||||
substantive, locally significant requirement or decision warrants customization.
|
||||
Adopt upstream wording verbatim for non-substantive differences. Existing local
|
||||
phrasing is not, by itself, a reason to retain a variation.
|
||||
|
||||
Each affected policy records its base version and local update date. Template
|
||||
adoption instructions were removed. Unchanged agent, architecture, and testing
|
||||
policies retain their existing versions.
|
||||
## Review Revision And Current Baseline
|
||||
|
||||
## Adoption Outcome
|
||||
The fixed upstream review revision is
|
||||
`d84a38ebab26f048cafbe59a2246700c35d29843`.
|
||||
Use the [adoption and update guide at that revision](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md)
|
||||
for this adoption. The review compared current local documents directly with
|
||||
that revision; reconstruction or assessment of historical adoption baselines
|
||||
is not required.
|
||||
|
||||
- [Documentation ownership](../policy/documentation.md) distinguishes the
|
||||
project license, component entries, standard texts, and OSS policy.
|
||||
- The [contributor guide](../development.md) routes dependency, copied-asset,
|
||||
attribution, and release-document work to the OSS policy.
|
||||
- [Component entries](../oss/attribution.md) cover the six selected direct and
|
||||
transitive Go modules. Source and project-specific notice links identify the
|
||||
imported commits. LGPL entries link directly to both LGPL v3 and GPL v3.
|
||||
- Project-specific notices are linked upstream under the adopted house
|
||||
interpretation. YAML's former local LICENSE and NOTICE copies were removed;
|
||||
their history remains in Git. Missing upstream copyright statements are
|
||||
identified in the affected entries rather than fabricated.
|
||||
- The five applicable standard texts in `docs/oss/licenses/` match the upstream
|
||||
reference collection byte-for-byte: GPL v3, LGPL v3, Apache 2.0, BSD 3-Clause,
|
||||
and MIT. The reference collection documents their publisher/SPDX provenance.
|
||||
Adoption removed a stray LGPL prefix, restored the complete Apache text,
|
||||
separated the standard BSD text from the Go-specific notice, and added MIT.
|
||||
- The [README](../../README.md) ends with friendly project-license and
|
||||
attribution links. The [release policy](../policy/release.md) delegates footer
|
||||
conventions to the OSS policy; the [release procedure](../release.md) retains
|
||||
Scriptorium's immutable-tag URLs and existing hosted-body reuse.
|
||||
The reviewed Scriptorium revision is
|
||||
`d6aecf5c50269b7d130dbf19f416a67454cd9778`. It has six adopted policies,
|
||||
without per-document Upstream Source metadata, and no `docs/policy/meta.md`.
|
||||
The policy targets below supersede the earlier roadmap's narrower version
|
||||
targets.
|
||||
|
||||
## Preserved Scope
|
||||
| Policy and proposed Upstream Source | Current base | Target base | Target treatment |
|
||||
| --- | --- | --- | --- |
|
||||
| [agents.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md) | 1.1 | 1.3 | Adopt shared rules verbatim, including commit discipline. |
|
||||
| [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md) | 1.1 | 1.3 | Adopt common principles and customize for Scriptorium's established boundaries. |
|
||||
| [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md) | 1.4 | 1.11 | Adopt shared language and tailor the canonical topic map. |
|
||||
| [testing.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md) | 1.1 | 1.3 | Adopt shared guidance with focused local test ownership. |
|
||||
| [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md) | 1.2 | 1.4 | Adopt common rules and retain justified release choices. |
|
||||
| [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md) | 1.1 | 1.8 | Adopt licensing, attribution, and reference-example conventions. |
|
||||
| [meta.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md) | Not adopted | 1.0 | Add provenance, local authority, and upstream discovery. |
|
||||
|
||||
This adoption changes documentation and attribution, not Scriptorium's license,
|
||||
dependencies, application architecture, or release machinery. Published notes,
|
||||
tags, and assets remain unchanged. Existing source-release completion and
|
||||
asynchronous binary-delivery behavior remain intact.
|
||||
Every existing policy needs language and provenance updates. No adopted policy
|
||||
is entirely update-free, but established application decisions, dependency
|
||||
licenses, and release mechanics need no substantive change.
|
||||
|
||||
There is no new publication-time network check, approval gate, scanner, source
|
||||
bundle, downloadable license asset, or modified-dependency rebuild exercise.
|
||||
Concrete exceptions continue to receive the treatment specified by the adopted
|
||||
OSS policy; the house format is not a universal legal-sufficiency guarantee.
|
||||
Current supporting-document gaps include the README's obsolete BSD project
|
||||
license statement, the release procedure's two-link footer, an attribution
|
||||
document that does not follow the new exact House Format, and orientation
|
||||
guidance that requires architecture reading even for unrelated work.
|
||||
The architecture policy's command inventory also omits the implemented
|
||||
`config` command family.
|
||||
|
||||
## Validation
|
||||
## Target Policy Language And Local Customizations
|
||||
|
||||
The standard texts were compared against the upstream reference collection.
|
||||
The BSD reference intentionally retains its publisher's trailing space in the
|
||||
copyright placeholder; it is not reformatted to satisfy a whitespace check.
|
||||
Dependency commit references were resolved from Go module origin metadata or
|
||||
the selected upstream tag, and affected local links and upstream attribution
|
||||
destinations were checked. No runtime code, commands, or executable examples
|
||||
changed.
|
||||
Remove every `Base Policy Template` section and its adoption instructions.
|
||||
Replace instructional application-specific placeholders with actual decisions;
|
||||
do not leave template examples describing nonexistent components.
|
||||
|
||||
Use upstream common language verbatim. Keep necessary local requirements
|
||||
clearly identifiable rather than paraphrasing entire shared sections.
|
||||
The following customizations are justified:
|
||||
|
||||
- **Architecture:** preserve PromptKit and ConfigKit ownership, full support
|
||||
for valid PromptKit definitions, public dependency boundaries, HTTP artifact
|
||||
containment, and simple predefined-prompt execution. Preserve caller-visible
|
||||
request independence alongside shared engine and backend capacity state.
|
||||
These are deliberate product and safety decisions, not generic template
|
||||
choices. Adopt upstream architectural principles proportionately; they do
|
||||
not require a wrapper or interface for every library. Correct the command
|
||||
inventory and keep concrete package mechanics in internal documentation.
|
||||
- **Documentation ownership:** tailor the topic map to the executable CLI and
|
||||
HTTP application. Scriptorium does not offer a reusable public Go API;
|
||||
consumer guidance covers executable use and migration to PromptKit.
|
||||
PromptKit remains the owner of framework formats. Use upstream wording for
|
||||
generic ownership, example, and ADR guidance instead of retaining redundant
|
||||
local paraphrases. Preserve accepted ADR decisions and their history.
|
||||
- **Testing:** retain a short project-specific ownership section distinguishing
|
||||
Scriptorium's integration and adapter tests from upstream framework/parser
|
||||
tests. This prevents duplication of PromptKit and ConfigKit test matrices.
|
||||
HTTP containment and shared-capacity behavior justify focused adapter
|
||||
coverage. Upstream observations about domain coverage are not quotas or a
|
||||
hierarchy that displaces risk-based testing.
|
||||
- **Release:** preserve branch-before-tag publication, annotated tags,
|
||||
Linux amd64/arm64 binaries and checksums, and asynchronous artifact delivery.
|
||||
Retain race testing because the server shares concurrent engine state and
|
||||
source guards because local replacements, workspaces, or vendoring can hide
|
||||
unpublished dependency substitutions. Keep gate rationale in policy and
|
||||
concrete commands, targets, and publication choices in the release procedure.
|
||||
Upstream's optional atomic-push approach does not require a new feature.
|
||||
- **OSS:** use Scriptorium's actual GPL-3.0-or-later grant in the project
|
||||
example. Preserve dependency grants and the settled House Format
|
||||
interpretation for upstream notice links. The code grant does not extend
|
||||
to separately licensed copied policy material.
|
||||
|
||||
No agent-policy exception is needed: upstream already preserves the local
|
||||
commit authorization and safety boundaries. Stylistic preferences, alternate
|
||||
wording, and generic elaboration do not justify additional exceptions.
|
||||
|
||||
## Provenance And Public Discovery
|
||||
|
||||
When adoption lands, each of the seven policies records its target
|
||||
`Base Policy Version`, actual local adoption date in `Last Updated`, and
|
||||
`Upstream Source` pointing to the exact corresponding file linked in the
|
||||
table above. Do not substitute a repository homepage, moving branch, another
|
||||
policy's URL, or a historical source revision for that per-document link.
|
||||
Retain accurate provenance in later local edits.
|
||||
|
||||
The new local `docs/policy/meta.md` follows upstream language after removing
|
||||
its template section. It establishes that adopted local policies govern the
|
||||
repository and that upstream changes require deliberate adoption. Its public
|
||||
discovery links remain current:
|
||||
|
||||
- [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
|
||||
- [Current adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
|
||||
|
||||
Adopted-source and example links remain commit-pinned. Preserve the valid
|
||||
commit-pinned example links supplied in the selected OSS policy; their asset
|
||||
revision need not be rewritten merely to match the policy review revision.
|
||||
Public discovery and attribution in this agreed adoption supersede the earlier
|
||||
instruction not to reference the policy repository.
|
||||
|
||||
## Orientation And Selective Reading
|
||||
|
||||
Adapt [the upstream agent orientation](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/agents/AGENTS.md)
|
||||
into [root AGENTS.md](../../AGENTS.md), preserving applicable existing
|
||||
code-discovery instructions. It points to the local contributor guide and
|
||||
requires the agent policy before recommendations, planning, or implementation;
|
||||
it does not require reading the entire suite by default.
|
||||
|
||||
The [contributor guide](../development.md) gains the upstream Policy Reading
|
||||
Guide table and associated selection rules, including the new meta policy.
|
||||
Retain Scriptorium's task-specific contract guide alongside it. Architecture
|
||||
reading becomes task-triggered rather than unconditional. Relevant policies
|
||||
are read before governed decisions, multiple policies may apply, material
|
||||
already available in context may be reused, and expanded scope triggers
|
||||
expanded reading. Policy-reading triggers live here, not in the documentation
|
||||
topic map.
|
||||
|
||||
## Licensing And Attribution
|
||||
|
||||
Follow the [canonical copied-policy attribution entry](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/examples/licensing/policy-attribution.md).
|
||||
Insert it directly beneath the prescribed attribution title and replace all
|
||||
three placeholder URLs with the full review commit. Identify the actual
|
||||
copied/adapted scope, including agent-orientation material and copied reading
|
||||
guidance where used, rather than describing only policy files if additional
|
||||
material is incorporated. Preserve creator, copyright, license, disclaimer,
|
||||
and modification information through the supplied notices and links.
|
||||
|
||||
Required supporting changes:
|
||||
|
||||
- Add the complete, unmodified `docs/oss/licenses/CC-BY-SA-4.0.txt` from the
|
||||
selected revision.
|
||||
- Extend [COPYRIGHT](../../COPYRIGHT) to identify the adapted policy material
|
||||
as CC-BY-SA-4.0 and point to attribution for exact scope. Preserve
|
||||
Scriptorium's GPL-3.0-or-later code grant and existing [LICENSE](../../LICENSE).
|
||||
Unrelated application documentation is not automatically relicensed.
|
||||
- Reformat [attribution](../oss/attribution.md) to the v1.8 House Format:
|
||||
`# Open Source Attribution Notices`, followed directly by component entries;
|
||||
factual optional identification; supplied copyrights; SPDX expressions;
|
||||
license/notice links with actual filename labels and terminal periods;
|
||||
and `[Source](COMMIT_URL).`.
|
||||
- Remove its introductory policy prose, missing-copyright filler, and
|
||||
agent-authored license-scope explanations. Omit an unavailable copyright
|
||||
field instead of explaining that none was invented. Preserve actual
|
||||
required upstream notices, applicable license expressions, and imported
|
||||
dependency revisions.
|
||||
- Correct [README](../../README.md) to link its GPL v3 or later statement to
|
||||
`COPYRIGHT`, followed by the attribution link.
|
||||
- Update [the release procedure](../release.md) to use the prospective
|
||||
`COPYRIGHT | LICENSE | ATTRIBUTION` footer, with absolute immutable-release
|
||||
URLs for all three destinations. The existing hosted workflow continues
|
||||
copying the checked-in release note unchanged.
|
||||
|
||||
The documented CC-BY-SA arrangement is agreed for this adoption. Original
|
||||
licensing-example formatting has upstream's CC0 permission; using it alone
|
||||
does not require a separate attribution entry. Reproduced license texts and
|
||||
third-party notices retain their own terms.
|
||||
|
||||
## Local Materials And Upstream References
|
||||
|
||||
Keep applicable adopted policies, Scriptorium's adapted root orientation and
|
||||
developer guide, actual project notices, attribution entries, and required
|
||||
license texts locally.
|
||||
|
||||
Keep the upstream adoption guide, README, root AGENTS.md, developer guide, and
|
||||
example collection upstream. Link to them as appropriate rather than copying
|
||||
them into a parallel local handbook. The upstream `agents/AGENTS.md` is the
|
||||
downstream orientation template, distinct from upstream's own root AGENTS.md.
|
||||
Copy only needed standard license texts, not the entire reference collection.
|
||||
|
||||
## Scope And Completion Criteria
|
||||
|
||||
This work updates policy and supporting documentation. It does not change
|
||||
application code, dependency versions or grants, release scripts, publication
|
||||
mechanics, or accepted ADR decisions. No new scanner, recurring synchronization
|
||||
check, license approval, publication-time network probe, or release gate is
|
||||
introduced. Published releases, tags, notes, and assets remain unchanged.
|
||||
|
||||
Completion means:
|
||||
|
||||
- All seven policy files use the selected versions, accurate source links,
|
||||
adoption dates, and upstream common wording, with template-only content
|
||||
removed and local variations limited to the justified decisions above.
|
||||
- Orientation and selective reading agree, and local links resolve without
|
||||
depending on a sibling checkout.
|
||||
- Policy attribution and document-license scope match the material actually
|
||||
incorporated; required standard texts are complete and unmodified.
|
||||
- README, attribution, release navigation, and still-operative roadmap
|
||||
handoffs agree with the new conventions. Historical implementation evidence
|
||||
remains available through the Git references in the implementation plan,
|
||||
without making old footer directions current policy. The earlier
|
||||
author-selected license change remains in the next release's preparation
|
||||
context; publication remains separate work.
|
||||
- Review checks the resulting rules, source/example URLs, notice facts, local
|
||||
links, license-text fidelity, and final diff. Runtime tests are unnecessary
|
||||
for documentation-only changes. A Git adoption record is sufficient; no
|
||||
additional provenance database or recurring audit is required.
|
||||
|
||||
There are no unresolved policy choices for this scope.
|
||||
|
||||
@@ -3,8 +3,9 @@
|
||||
## Status
|
||||
|
||||
Complete. This document records the delivered feature scope and targeted end
|
||||
state. The completed delivery plan is maintained in
|
||||
[implementation.md](implementation.md); current behavior remains defined by
|
||||
state. The completed delivery plan is preserved at
|
||||
`git show e4405966c87c8a7843b340146e90cc1e515bef42:docs/roadmap/implementation.md`;
|
||||
current behavior remains defined by
|
||||
the canonical application contracts linked below.
|
||||
|
||||
The durable product and integration boundary for this work is established by
|
||||
|
||||
@@ -8,7 +8,8 @@ and publication remain separate release preparation. The baseline descriptions
|
||||
below record the state when this roadmap was written, not current behavior.
|
||||
Upgrade directly from Promptkit v0.9.0 to v0.11.0, including the intervening
|
||||
v0.10.0 catalog transition. This document defines the desired end state and
|
||||
the changes from the current baseline. The [implementation plan](implementation.md)
|
||||
the changes from the current baseline. The historical plan at
|
||||
`git show 43eea5c7c41d2a8134b3dece60f3af5c98b8fd1c:docs/roadmap/implementation.md`
|
||||
owns sequencing, concrete interface choices, verification steps, and unresolved
|
||||
implementation decisions.
|
||||
|
||||
@@ -268,6 +269,6 @@ boundaries.
|
||||
the version-matched note remain release preparation.
|
||||
|
||||
Concrete interface decisions and the selected distribution approach are recorded
|
||||
in the completed [implementation plan](implementation.md). They do not expand
|
||||
in that completed historical plan. They do not expand
|
||||
the product into conversations, follow-up messages, application-owned semantic
|
||||
retry loops, prepared-handle coordination, or multi-step workflows.
|
||||
|
||||
8
go.mod
8
go.mod
@@ -3,13 +3,13 @@ module gitea.maximumdirect.net/eric/scriptorium
|
||||
go 1.25.5
|
||||
|
||||
require (
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.0
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.0
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.2
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.2
|
||||
)
|
||||
|
||||
require (
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 // indirect
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 // indirect
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 // indirect
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 // indirect
|
||||
github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect
|
||||
go.yaml.in/yaml/v4 v4.0.0-rc.6 // indirect
|
||||
golang.org/x/text v0.14.0 // indirect
|
||||
|
||||
16
go.sum
16
go.sum
@@ -1,11 +1,11 @@
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.0 h1:fo+vKff3zTGeWqJIA38NtT84b6OUP//9ZmBH3lFuKgk=
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.0/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.0 h1:x7JguOUiInPVXK0GEitjyoRFqqvcuSTjYUvqJ+whtik=
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.0/go.mod h1:0zEBVlJJC+ldDdXazAgybYBXNSe74vwFx5dyOuSos/w=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1 h1:S2/Q/JDE+m8Ca3pDhAjVbfYrdlEhs9blj0STgNopHo0=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260922.1/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0 h1:Y0EXc3eh12eKW2NrOviVqdk3oBo6UUjopt1YAa1B3Oc=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260922.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.2 h1:ZMxmv8pOnLtAx2hFTf8Z+pHKUbR89xErkBhwjr4yK24=
|
||||
gitea.maximumdirect.net/eric/ConfigKit v0.4.2/go.mod h1:tYWpsrbLyu05r8+1MapWp5fN6ZrX9I8hU2xEPedYmYk=
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.2 h1:2RqI+KtflvSh7vLQaTAQCmMaFQscEA7EPwPazyvXRoY=
|
||||
gitea.maximumdirect.net/eric/promptkit v0.11.2/go.mod h1:onm/FBPUKQ8/NSPwTEk26Ut+dVX2iXcq8vEseB+g/0E=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0 h1:wdab+R+lgMZxzYwhbAuCrW7zdSQ1cW9ovBR6UzLmZR4=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2 v2.20260926.0/go.mod h1:a3VBbh9oaGXD6ruxhtwHj+AWW6DY/SSyby1QtMmYSUo=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0 h1:baCCIB6Ee5t0S4Zc++NTBIPcJEv5UPS6DlSrpZfykwg=
|
||||
gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/v2 v2.20260926.0/go.mod h1:mtgD1E0SGm0e/I8Ffhz+AYX7GN7RKUWJXehNFIKHs4Y=
|
||||
github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI=
|
||||
github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8=
|
||||
github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ=
|
||||
|
||||
Reference in New Issue
Block a user