Prepare Notarius v0.8.1 source release

This commit is contained in:
2026-09-28 03:04:04 +00:00
parent 122f36bc68
commit 9790579b51
5 changed files with 31 additions and 7 deletions

23
docs/releases/v0.8.1.md Normal file
View File

@@ -0,0 +1,23 @@
# Notarius v0.8.1
This patch release refreshes ConfigKit and PromptKit and makes the project's
licensing, policy provenance, and upstream attribution easier to find.
## Changes
- Update ConfigKit to v0.4.2 and PromptKit to v0.11.2. These upstream patches
update release tooling and policy or licensing documentation without changing
the Notarius integration APIs or configured profile settings.
- Refresh the PromptKit built-in profile-source checkpoint identity for the
selected dependency version. Existing checkpoints with the previous identity
are not reused; source-keyed chunk plans and published output are unaffected.
- Align the repository policies with their pinned upstream source, add canonical
third-party attribution, and distinguish the GPL-3.0-or-later application grant
from the CC-BY-SA-4.0 terms for copied or adapted policy material. The root
GPL license text has been brought into the house-standard form without
changing the application grant.
Notarius's CLI, configuration schema, subprocess receipt, and durable artifact
formats have no intentional changes in this release.
[COPYRIGHT](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/COPYRIGHT) | [LICENSE](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/LICENSE) | [ATTRIBUTION](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/oss/attribution.md)

View File

@@ -24,7 +24,8 @@ The original finding below is retained as review context.
## Review Scope
Reviewed implementation commits `31b48d2` through `7ac9d94` against
[the feature roadmap](upgrade-kit.md) and [the implementation plan](implementation.md).
[the feature roadmap](upgrade-kit.md) and the completed upgrade work recorded
in those commits.
The review covered configuration selection/defaults, production client wiring,
error translation, execution observation, scheduler/debug propagation, current
documentation, and tests. No production model calls were made.

View File

@@ -12,9 +12,9 @@ Adopt ConfigKit v0.4.0 and PromptKit v0.11.0 in one coordinated work set:
Preserve application/framework boundaries and keep the two upgrades as distinct
implementation workstreams. Neither requires a redesign of pipeline execution.
This feature roadmap owns the target state and scope. The ordered work and
stage-specific verification belong to the [implementation plan](implementation.md).
Neither document authorizes release publication.
This feature roadmap records the target state and scope. Its original
implementation plan was completed and later replaced by a new work plan.
Neither document authorized release publication.
## Current Baseline
@@ -249,7 +249,7 @@ new durable telemetry artifact, or add complete cost accounting.
### Documentation
Update current documentation with the implementation, keeping canonical
ownership under [Documentation Policy](../policy/documentation.md):
ownership under [Documentation Policy](../../policy/documentation.md):
- `docs/cli.md`: new flag on every affected command and matching help behavior.
- `docs/config.md`: overlay terminology, directory layout, precedence, and the
@@ -296,7 +296,7 @@ retries and zero-value opt-out, and the dependency license change. PromptKit's
catalogs are unchanged from v0.10.0; this upgrade adds no further profile-name
migration or change to the D&D model defaults. Release preparation,
tagging, and publication remain a separately requested task under
[Source Releases](../release.md).
[Source Releases](../../release.md).
## Acceptance And Verification
@@ -333,5 +333,5 @@ tagging, and publication remain a separately requested task under
and the complete configuration with `--config-overlay development`.
Use existing behavioral tests where possible, following
[Testing Policy](../policy/testing.md). No live model calls or production API
[Testing Policy](../../policy/testing.md). No live model calls or production API
credentials are needed to validate this migration.