Skip to content

Define transactional type-pack contract evolution - #44

Merged
callumalpass merged 1 commit into
mainfrom
agent/contract-evolution
Aug 3, 2026
Merged

Define transactional type-pack contract evolution#44
callumalpass merged 1 commit into
mainfrom
agent/contract-evolution

Conversation

@callumalpass

Copy link
Copy Markdown
Collaborator

What changed

  • Defines managed and seed type-pack resources.
  • Adds immutable JCS pack digests and portable mdbase.lock.yaml provenance.
  • Specifies structured install, upgrade, downgrade, reconfigure, conflict, and no-op assessments.
  • Defines transactional application with stale-assessment rechecks and explicit resource actions.
  • Adds schemas, normative examples, and executable conformance cases.

Why

Collections previously had no durable, portable account of which exact pack produced their managed resources. When contracts evolved, consumers could discover only that a collection stopped matching, not whether it was safe to upgrade or what would change.

This makes contract evolution an explicit local-first protocol: assessment is read-only and explainable; application is exact, transactional, and conflict-preserving.

Impact

This is intentionally breaking prerelease work. Implementations should replace the old install-only API with assess/apply semantics and treat the lockfile as collection provenance.

Validation

  • python scripts/check_test_levels.py
  • python scripts/check_v03_tests.py (64 executable cases / 99 adapter targets)
  • migration fixture validation
  • runtime pack generation
  • schema/conformance suites in the coordinated Rust and TypeScript PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant