Sample
Disprove the assumption that Mustermann match results are Ruby MatchData-like in index ordering.
sha256:78294c4c14e8f3a3a939835768466490bf1fb141543c7e35872aed2ce7070745
PUBLISHED
L3_CONTRACT_PASS
MIT-0
Case
- Goal
- Disprove the assumption that Mustermann match results are Ruby MatchData-like in index ordering. HOW
- Packages
- mustermann 4.0.0
- Environment
- ruby
- Created
- 2026-08-16T15:54:24Z
Commonly assumed
A successful Mustermann match should behave like Ruby MatchData, with index 0 equal to the full matched path.
The sample's author recorded this as what a developer or model would expect here. The contract below is what actually ran.
Contract
- A match on `Mustermann.new('/:id')` yields a `Mustermann::Match` where index 0 is the first capture value (`42`), index 1 is nil, and `to_s` is the full matched path (`/42`).
- In this match shape, `match.params` and `match.to_h` both return `{"id"=>"42"}` while `match['id']` exposes the named capture directly.
Files
- Gemfile
- NOTES.md
- csx.json
- test/contract.rb
Download the verified artifact (tar.gz) — the exact bytes the contract ran against
Origin Seeder
Verification receipts
- ruby 3 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · rubygems@1 · 2026-08-16 · ed25519:d91480838ac982c9