dry-validation-rust 0.1.0.pre6-x64-mingw-ucrt

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 2b453a01f2bae38a733f8b3145c9f015599549d1e177eb834fc079d7443bda91
+  data.tar.gz: 22651b06ba22ffab3cd5fd6a9bad0b03d1d7d98cf74a69e9593ed24e5c8faa7f
+SHA512:
+  metadata.gz: 3ce997c6fb6de7d2ac0ec6d38dc8aec68fc105129f19b88f1a05373f886aa1116e53ac4b8ad3a7c77b081ade90d1e8baaf0f55122e8f3096c8c6cabb5d0c9d2c
+  data.tar.gz: 7eddeba3a78a99a9361558beffb250cd8ba105b49a6c40a5c7a74686337d6b5d5ab5ba383b3b74a986897b79d9ad50eb7cf4b08bff60b4775a715629946629f5

data/.gitignore

@@ -0,0 +1,13 @@
+/.bundle/
+/pkg/
+/coverage/
+/ext/dry_validation_rust/Makefile
+/ext/dry_validation_rust/mkmf.log
+/ext/dry_validation_rust/native.*
+/lib/dry/validation/rust/native.so
+/ext/dry_validation_rust/target/
+/ext/dry_validation_rust/fuzz/target/
+/tmp/
+/build-week-2026/
+/.vscode/
+/target/

data/.markdownlint.yml

@@ -0,0 +1,9 @@
+MD013:
+  line_length: 120
+  code_blocks: false
+  tables: false
+MD024:
+  siblings_only: true
+MD033: false
+MD041: false
+MD060: false

data/.rubocop.yml

@@ -0,0 +1,124 @@
+plugins:
+  - rubocop-performance
+  - rubocop-minitest
+
+AllCops:
+  TargetRubyVersion: 3.3
+  NewCops: enable
+
+# Keep complexity limits meaningful for the library while excluding declarative
+# test cases and command orchestration from limits that do not aid readability.
+Metrics/AbcSize:
+  Max: 40
+  Exclude:
+    - 'Rakefile'
+    - 'benchmark/**/*'
+    - 'script/**/*'
+    - 'test/**/*'
+
+Metrics/BlockLength:
+  Max: 30
+
+Metrics/ClassLength:
+  Max: 200
+  Exclude:
+    - 'script/**/*'
+    - 'test/**/*'
+
+Metrics/CyclomaticComplexity:
+  Max: 16
+  Exclude:
+    - 'Rakefile'
+    - 'benchmark/**/*'
+    - 'script/**/*'
+    - 'test/**/*'
+
+Metrics/MethodLength:
+  Max: 30
+  Exclude:
+    - 'Rakefile'
+    - 'benchmark/**/*'
+    - 'script/**/*'
+    - 'test/**/*'
+
+Metrics/ParameterLists:
+  Max: 7
+
+Metrics/PerceivedComplexity:
+  Max: 16
+  Exclude:
+    - 'Rakefile'
+    - 'benchmark/**/*'
+    - 'script/**/*'
+    - 'test/**/*'
+
+Layout/LineLength:
+  Exclude:
+    - 'Rakefile'
+    - 'benchmark/**/*'
+    - 'script/**/*'
+    - 'test/**/*'
+
+Style/Documentation:
+  Enabled: false
+
+Gemspec/DevelopmentDependencies:
+  Enabled: false
+
+Naming/FileName:
+  Exclude:
+    - 'lib/dry-schema.rb'
+    - 'lib/dry-validation.rb'
+
+Naming/MethodName:
+  Exclude:
+    - 'lib/dry/validation.rb'
+    - 'lib/dry/validation/rust.rb'
+    - 'lib/dry/validation/rust/schema.rb'
+
+# The suite uses several assertions to describe each public behavioral scenario.
+# Enforcing assertion style or count would make tests less readable without
+# improving coverage or failure diagnostics.
+Minitest/AssertInDelta:
+  Enabled: false
+
+Minitest/AssertPathExists:
+  Enabled: false
+
+Minitest/AssertPredicate:
+  Enabled: false
+
+Minitest/AssertTruthy:
+  Enabled: false
+
+Minitest/AssertWithExpectedArgument:
+  Enabled: false
+
+Minitest/EmptyLineBeforeAssertionMethods:
+  Enabled: false
+
+Minitest/MultipleAssertions:
+  Enabled: false
+
+Minitest/RefuteFalse:
+  Enabled: false
+
+Minitest/RefutePathExists:
+  Enabled: false
+
+Minitest/RefutePredicate:
+  Enabled: false
+
+# These allocation-oriented rewrites are not applied wholesale without measured
+# benchmarks; the performance suite remains the source of such evidence.
+Performance/CollectionLiteralInLoop:
+  Enabled: false
+
+Performance/DoubleStartEndWith:
+  Enabled: false
+
+Performance/MapCompact:
+  Enabled: false
+
+Performance/TimesMap:
+  Enabled: false

data/.ruby-version

@@ -0,0 +1 @@
+3.3.7

data/.tool-versions

@@ -0,0 +1 @@
+ruby 3.3.7

data/.yardopts

@@ -0,0 +1,4 @@
+--markup markdown
+--protected
+--no-private
+lib/**/*.rb

data/AGENTS.md

@@ -0,0 +1,376 @@
+# AGENTS.md — Lean feature delivery
+
+These instructions apply to coding agents working in this repository.
+
+## Mission
+
+Ship correct, reviewable user value with the least process needed to keep the codebase understandable and safe for a team.
+
+Optimize for this order:
+
+1. user-visible behavior;
+2. correctness and safety;
+3. focused verification;
+4. maintainable code;
+5. minimal affected documentation;
+6. repository polish.
+
+Do not optimize for the number of documents, tests, abstractions, or process artifacts produced.
+
+## Project state and progress
+
+Do not maintain a per-task or per-commit progress log.
+
+Code, tests, differential fixtures, benchmarks, pull requests, and Git history
+are the primary evidence that implementation work happened.
+
+Use these authoritative locations instead:
+
+- `docs/ROADMAP.md` — intended milestone outcomes, dependency order, and exit goals;
+- `compat/status.yml` — small machine-readable current milestone/task state;
+- `docs/COMPATIBILITY.md` — detailed supported and unsupported behavior;
+- `docs/SUPPORT_MATRIX.md` — version, runtime, and platform support;
+- benchmark sources/baselines and README benchmark sections — performance evidence;
+- ADRs — durable cross-cutting decisions;
+- issues/PRs/Git history — work history and temporary implementation context.
+
+Update `compat/status.yml` only when a tracked durable state actually changes,
+for example:
+
+- a milestone moves between `not_started`, `active`, `blocked`, and `complete`;
+- a named milestone task changes state;
+- an external blocker is added or resolved;
+- the declared release phase changes.
+
+Do not update project-state files merely because:
+
+- an ordinary bug fix or refactoring was completed;
+- tests, fixtures, source files, or documentation counts changed;
+- a commit was created;
+- an investigation produced temporary notes;
+- a benchmark experiment failed without changing a published claim;
+- a follow-up idea was discovered.
+
+When a compatibility, support, benchmark, or architecture truth changes, update
+its authoritative location rather than duplicating the same fact in
+`compat/status.yml`.
+
+For milestone-driven work:
+
+1. satisfy the milestone file's acceptance criteria;
+2. run the required verification;
+3. update `compat/status.yml` only if a tracked milestone/task state changed;
+4. update user/developer documentation only where its durable truth changed;
+5. keep completion details and follow-ups in the task/PR context;
+6. do not create a separate completion-report document.
+
+Documentation describes current durable truth; it is not an activity log.
+
+## Default working mode
+
+Work on one coherent capability, defect, or risk at a time.
+
+Before editing:
+
+1. read the relevant implementation and tests;
+2. identify the smallest independently useful slice;
+3. state the intended behavior, explicit non-goals, likely files, and verification plan;
+4. reuse existing patterns before introducing new abstractions.
+
+During implementation:
+
+- keep unrelated code unchanged;
+- prefer a direct implementation over speculative infrastructure;
+- add focused behavioral tests;
+- preserve explicit failures at unsupported or invalid boundaries;
+- record follow-up ideas without implementing them;
+- update only documentation whose truth changed.
+
+At completion, report only:
+
+1. behavior changed;
+2. important files changed;
+3. checks run and results;
+4. remaining limitations or risks;
+5. follow-up ideas intentionally not implemented.
+
+## Scope guardrails
+
+For an ordinary task, default limits are:
+
+- one public capability or one defect class;
+- at most 1,000 added lines, excluding generated code or fixtures that are the direct product requirement;
+- at most 5 new source files;
+- at most 3 new test files;
+- at most 2 new abstractions;
+- no new documentation file;
+- updates to at most 2 existing documentation files;
+- at most 150 added documentation lines.
+
+If the likely change exceeds a limit, reduce it to the smallest useful vertical slice before coding.
+Do not silently continue with a large implementation.
+
+These are agent guardrails, not rigid team policy. Exceed them only when the task explicitly requires it
+and the reason is stated before implementation.
+
+## Tests
+
+Tests should protect observable behavior, important regressions, safety boundaries, integration
+contracts, and packaging where relevant.
+
+Before reporting a code-changing task as complete, run `bundle exec rubocop`
+when Ruby source, tests, tooling, or CI configuration changed. Treat any
+RuboCop failure as unfinished work: fix the offenses or report the remaining
+baseline explicitly instead of claiming completion.
+
+Prefer:
+
+- focused unit tests for local behavior;
+- integration tests for public flows;
+- contract or differential tests for compatibility claims;
+- regression tests for fixed defects;
+- property, fuzz, or stress tests only for identified risk surfaces.
+
+Do not add tests whose main purpose is checking:
+
+- Markdown wording or headings;
+- roadmap structure;
+- documentation file presence or count;
+- issue or pull-request template structure;
+- stage completion;
+- repository maturity claims;
+- private implementation details already covered through public behavior.
+
+Do not weaken or delete a failing test merely to make checks green.
+
+## Documentation
+
+Documentation exists to help users and maintainers make correct decisions.
+
+Update documentation when a change affects:
+
+- public behavior or API;
+- configuration;
+- installation or operation;
+- compatibility or support boundaries;
+- architecture ownership or data flow;
+- a decision that would otherwise be repeatedly reopened.
+
+Do not create a document for:
+
+- an ordinary implementation plan;
+- a completed task report;
+- a temporary investigation;
+- information already expressed clearly elsewhere;
+- speculative future architecture.
+
+Use comments for local reasoning, tests for executable behavior, `compat/status.yml`
+for small machine-readable current milestone/task state, `docs/ROADMAP.md` for
+intended outcomes, issues for planned work, pull requests for change context,
+ADRs for durable cross-cutting decisions, and user documentation for supported
+usage. Link between authoritative locations instead of copying the same state
+into several documents.
+
+## Abstractions
+
+Do not add a framework, registry, adapter layer, plugin system, generic configuration mechanism, or
+extension point for one anticipated use case.
+
+Generalize only when:
+
+- at least two implemented cases need the same behavior;
+- current duplication is concrete and meaningful;
+- the abstraction reduces total conceptual surface;
+- its ownership and failure behavior are clear.
+
+Prefer duplication that is easy to remove over an abstraction that is difficult to understand.
+
+## Failure behavior
+
+Invalid, unsupported, or unsafe behavior must fail explicitly and predictably.
+
+Never:
+
+- silently ignore unsupported input;
+- accept unsupported syntax as a no-op;
+- approximate semantics without an explicit opt-in;
+- hide an unexpected exception as a normal result;
+- substitute a fallback that changes behavior without documentation;
+- claim support because input parses successfully.
+
+## Compatibility and performance claims
+
+Compatibility claims require executable evidence against a pinned reference or a clearly documented contract.
+
+Performance claims require reproducible before-and-after measurements on representative workloads.
+Report neutral and negative results as well as improvements. Never broaden a synthetic result into a
+general claim.
+
+## Team decisions
+
+Use an ADR only when a decision is durable, cross-cutting, costly to reverse, or likely to be reopened by multiple contributors.
+
+An ADR should normally fit on one page and contain:
+
+- context;
+- decision;
+- consequences;
+- alternatives considered.
+
+Do not write an ADR for routine implementation choices.
+
+## Skill selection
+
+Use the smallest set of skills needed for the active task.
+
+Choose one primary skill for implementation or delivery. Preflight and review skills may be used before
+or after it, but they should not expand the task.
+
+### Primary implementation skills
+
+Use exactly one of these for ordinary implementation work:
+
+- `.agents/skills/feature-delivery/SKILL.md` — implement one independently useful user-visible capability;
+- `.agents/skills/bug-fix/SKILL.md` — reproduce and fix one defect class with regression coverage;
+- `.agents/skills/compatibility/SKILL.md` — implement one verified compatibility slice against a pinned reference;
+- `.agents/skills/migration/SKILL.md` — enable one realistic migration path with minimal user changes;
+- `.agents/skills/performance/SKILL.md` — improve one measured bottleneck while preserving behavior;
+- `.agents/skills/refactoring/SKILL.md` — improve internal structure without observable behavior changes;
+- `.agents/skills/documentation/SKILL.md` — update documentation when documentation is the primary deliverable;
+- `.agents/skills/release-readiness/SKILL.md` — verify an actual release candidate.
+
+Do not combine several primary implementation skills in one ordinary task.
+
+If a task appears to require two primary skills, select the dominant outcome and split the remaining
+work into a separate task unless the work is genuinely inseparable.
+
+Examples:
+
+- a feature that requires a small local refactoring remains a feature-delivery task;
+- a bug fix that includes a benchmark to confirm no regression remains a bug-fix task;
+- a compatibility feature required for a real migration may use migration as the primary skill and
+  compatibility evidence as part of its workflow;
+- release preparation must not include unrelated feature development.
+
+### Preflight and decision skills
+
+Use these before implementation when needed:
+
+- `.agents/skills/scope-guard/SKILL.md` — define the smallest coherent slice and explicit non-goals before coding;
+- `.agents/skills/investigation/SKILL.md` — inspect, reproduce, or evaluate without modifying implementation files;
+- `.agents/skills/architecture-decision/SKILL.md` — evaluate a durable cross-cutting decision and
+  create an ADR only when the ADR threshold is met.
+
+These skills normally do not modify production code.
+
+Use `scope-guard` when the request is broad, ambiguous, milestone-sized, or likely to exceed the scope guardrails.
+
+Use `investigation` when the root cause, compatibility behavior, feasibility, or architecture boundary is not yet known.
+
+Use `architecture-decision` only when implementation cannot proceed safely without resolving a durable cross-team decision.
+
+After a preflight or decision task, start a separate implementation run with the selected primary skill
+and the approved scope.
+
+### Review skills
+
+Use these after implementation or for an existing diff:
+
+- `.agents/skills/code-review/SKILL.md` — review correctness, compatibility, maintainability, and unnecessary complexity;
+- `.agents/skills/safety-review/SKILL.md` — review panic safety, memory/resource ownership,
+  concurrency, failure behavior, and other identified safety risks.
+
+A review skill must not turn the review into unrelated implementation work.
+
+Use `safety-review` only when the code touches a meaningful safety surface, such as:
+
+- native or FFI boundaries;
+- unsafe code;
+- concurrency or synchronization;
+- resource lifetime or cleanup;
+- persistence or data-loss risk;
+- authentication, authorization, or secrets;
+- untrusted parsing or deserialization;
+- panic or exception containment.
+
+For ordinary changes, `code-review` alone is sufficient.
+
+### Allowed skill sequences
+
+Valid sequences include:
+
+```text
+scope-guard -> feature-delivery -> code-review
+investigation -> bug-fix -> code-review
+investigation -> performance -> code-review
+architecture-decision -> feature-delivery -> code-review
+scope-guard -> migration -> code-review
+feature-delivery -> safety-review
+release-readiness
+```
+
+The arrows represent separate phases or runs. They do not authorize all skills to broaden one implementation session.
+
+### Skill routing rules
+
+- Load only the skill needed for the current phase.
+- Do not load every available skill by default.
+- Do not let feature work automatically trigger release, documentation, architecture, or repository-cleanup work.
+- Do not let review skills add unrelated requirements.
+- Do not let `scope-guard` create permanent planning artifacts.
+- Do not let `investigation` modify code unless the user explicitly starts a separate implementation phase.
+- Do not let `documentation` rewrite unrelated documents.
+- Do not let `refactoring` introduce behavior changes.
+- Do not let `performance` optimize without a measured baseline.
+- Do not let `compatibility` claim parity beyond executable evidence.
+- Do not let `migration` become a complete reimplementation of the source system.
+- Do not let `release-readiness` publish, tag, or release without explicit authorization.
+
+## Working with scope guard
+
+For a broad or ambiguous task, use this sequence:
+
+1. apply `.agents/skills/scope-guard/SKILL.md` without modifying files;
+2. identify one approved vertical slice;
+3. select the matching primary implementation skill;
+4. implement only the approved slice;
+5. review the resulting diff with the smallest appropriate review skill.
+
+The approved scope should state:
+
+- outcome;
+- included behavior;
+- explicit non-goals;
+- likely affected areas;
+- verification plan;
+- stop conditions.
+
+Do not reopen or expand the approved scope during implementation unless a required blocker is discovered.
+
+## Follow-up work
+
+When work reveals additional ideas, classify them as:
+
+- required blocker — include only the smallest necessary fix;
+- related follow-up — report but do not implement;
+- independent defect — recommend a separate bug-fix task;
+- architectural uncertainty — stop and use investigation or architecture-decision;
+- unrelated cleanup — leave unchanged.
+
+Do not implement a follow-up merely because it is nearby or easy.
+
+## Prohibited unless explicitly requested
+
+Do not:
+
+- publish artifacts or releases;
+- create or push tags;
+- make remote repository changes;
+- change branch protection, visibility, or secrets;
+- add credentials;
+- create a new planning hierarchy;
+- generate long compliance reports;
+- reorganize documentation during unrelated feature work;
+- implement backlog ideas discovered during the task;
+- load every skill for every task;
+- convert preflight or review work into an unapproved implementation task.

data/CHANGELOG.md

@@ -0,0 +1,145 @@
+# Changelog
+
+## Unreleased
+
+## 0.1.0.pre6 — 2026-09-02
+
+- Added Rails, Hanami, Roda, and Grape integration guides for the side-by-side
+  contract API.
+- Added a GitHub Discussions link for usage questions in the README.
+- Added a pull-request checklist and path-based labels for changed areas.
+- Added guided bug, feature, and performance-regression issue forms for contributors.
+- Made the CI support matrix and its published platform table YAML-backed and
+  checked for synchronization in CI.
+- Made the documented compatibility matrix YAML-backed and checked for sync in CI.
+- Added hosted Rust API reference documentation to the GitHub Pages site.
+- Added a getting-started guide for installation, first contracts, macros,
+  web integration, and native-build troubleshooting.
+- Added an mdBook documentation site with sidebar navigation, native search,
+  and GitHub Pages deployment from `main`.
+- Added a searchable YARD Ruby API reference to the GitHub Pages site.
+- Added opt-in MemoryProfiler allocation and retained-memory totals to the
+  schema-throughput JSON benchmark matrix for both engines.
+- Added a documented `script/benchmark` entrypoint for reproducible local
+  schema-throughput comparisons and JSON measurements.
+- Improved unsupported schema DSL errors with migration guidance for boolean
+  predicate composition, UUID predicates, and filtering.
+- Added a five-minute pinned-upstream differential fuzz CI job covering 1,000
+  generated schema/input pairs per run.
+- Added a blocking pull-request CI job for the pinned upstream differential
+  compatibility suite, with uploaded test logs.
+- Made publication benchmark duration and live progress visible, so long
+  full-matrix runs can be distinguished from stalled executions.
+- Added a repeatable publication benchmark runner with calibrated measurements,
+  checkpoints, environment metadata, and documented evidence guidance.
+- Added CI checks for Markdown style violations and broken documentation links.
+- Added local Ruby and Rust CPU-flamegraph scripts for diagnosing validation
+  hot paths.
+- Added a schema-throughput pull-request regression gate with a 5% p95-latency
+  threshold and a GitHub Pages benchmark dashboard refreshed from trusted runs.
+- Added Ruby line-coverage reporting and a Codecov quality gate to CI.
+- Added native Rust line-coverage reporting and a Codecov quality gate to CI.
+- Added beta Rust CI coverage and a weekly nightly Miri check for the native extension.
+- Added an allowed-to-fail Windows CI job that compiles the native extension
+  and runs the Ruby test suite with RubyInstaller's UCRT toolchain.
+- Fixed deeply nested Ruby type processing to avoid exhausting Windows' Ruby
+  VM stack during validation.
+- Added Gitleaks secret scanning to the Security workflow for pull requests,
+  protected-branch pushes, scheduled runs, and manual runs.
+- Added local release automation for version and Cargo-lockfile updates, dated
+  changelog sections, and release tags, plus pull-request changelog enforcement.
+- Added representative throughput, allocation, and native Criterion benchmark
+  coverage with regression gates where main-branch baselines are available.
+- Improved source and native-gem build reliability across supported targets,
+  including MinGW source builds and cross-compilation packaging.
+- Added release-publishing preflight, signed native-gem artifacts, and trusted
+  RubyGems publishing support.
+
+## 0.1.0.pre5 — 2026-08-18
+
+- Added pluggable schema message backends through custom `MessageBackend`
+  subclasses.
+- Changed the native engine boundary to return a typed `SchemaResult` with
+  `#output` and `#errors` accessors.
+- Fixed native predicate evaluation to propagate exceptions raised by Ruby
+  predicate methods instead of returning validation failures.
+- Added generated predicate ownership declarations and explicit rule-context
+  visibility for the supported contract API.
+- Improved native schema, coercion, predicate, and rule-dependency execution
+  while preserving the documented compatibility subset.
+- Added Rust 1.75 MSRV verification, source-gem package auditing, and public
+  API documentation checks.
+
+## 0.1.0.pre4 — 2026-08-12
+
+- Improved native coercion and declared-key validation performance.
+- Fixed predicate-block arity validation and range-predicate message
+  interpolation.
+- Improved native structured error reporting and stability coverage for hostile
+  Ruby inputs.
+- Refined the public schema, contract, result, values, and message data types
+  without broadening the documented compatibility surface.
+
+## 0.1.0.pre3 — 2026-08-09
+
+- Added `config.validate_keys = true` for `params` and `json` schemas to
+  report undeclared keys, including in nested hashes.
+- Added supported predicate-composition blocks to schema value declarations.
+- Added `:value_coercer` schema processor hooks that run before and after
+  native schema evaluation.
+- Added direct-field support for custom `dry-types` objects and constructors.
+- Added configurable YAML message templates and an optional I18n message
+  backend for schema errors.
+- Added source-gem package auditing with an isolated installation smoke test.
+- Documented the coordinated vulnerability-disclosure process, including a
+  90-day post-fix-release embargo and the weekly dependency-audit schedule.
+
+## 0.1.0.pre2 — 2026-08-03
+
+- Added typed native predicate arguments; invalid null and object arguments are
+  rejected when compiling a schema plan.
+- Added explicit depth limits for native schema plans and nested schema
+  traversal.
+- Changed `MessageSet#messages` to return a read-only view; use `#add` to add
+  messages to a mutable message set.
+- Relaxed the native extension's Magnus dependency to compatible `0.8.x`
+  patch releases.
+- Added coercion boundary and concurrent contract-call coverage.
+- Added Rust package-manifest verification to CI.
+- Added product-scope documentation, including the support matrix and pinned
+  upstream compatibility references.
+- Added canonical verification and benchmark-smoke scripts.
+- Added fixture-backed baseline behavior tests and verification documentation.
+- Excluded local Cargo target output from source gem file selection.
+- Added public RubyGems metadata and a package audit task for source-gem
+  contents, artifact rejection, isolated install, and safe-entrypoint smoke
+  verification.
+- Added GitHub Actions workflows for Ruby/Rust CI, compatibility preflight,
+  security audit, package audit, and scheduled fuzz preflight.
+- Added Dependabot configuration, dependency audit policy, and dependency
+  version capture in canonical verification logs.
+- Added contribution, conduct, security, support, and governance policies plus
+  structured issue forms and a pull request template.
+- Added project-management policy, roadmap-to-milestone mapping, issue-quality
+  form, canonical labels, work-in-progress limits, and an idempotent GitHub API
+  synchronizer with dry-run defaults.
+- Replaced the extensive stage catalog with a compact outcome-oriented roadmap
+  and aligned project synchronization, issue milestones, and workflow references.
+- Removed prose-only documentation/community/project-policy tests and made
+  remaining configuration tests protect executable, package, or security
+  behavior without freezing exact roadmap counts.
+
+## 0.1.0.pre1 — 2026-07-12
+
+- Added a Magnus/rb-sys native extension with immutable compiled schema plans.
+- Added `params`, `json`, and non-coercing `schema` modes.
+- Added required, optional, filled, maybe, hash, array, primitive member,
+  nested member, coercion, type check, and common predicate support.
+- Added ordered Ruby contract rules, multi-key rules, nested paths,
+  `rule.each`, key/base failures, context, options, and macros.
+- Added result, values, message, message-set, pattern-matching, inheritance,
+  external schema reuse, and safe/exact entrypoints.
+- Added compatibility, architecture, feasibility, testing, and benchmark
+  documentation.
+
+This is an experiment, not a production-compatible release.