specguard-rspec 0.2.3 → 0.2.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 9ab32ecca2ef5d4af0b93b22c0e9691a9b0f5302f939cc8fc6a8809eae7074e9
-  data.tar.gz: 5baf222c850624d56c5fccd4c4647c68bac3ee765e0a5afe6e6dcb1bba69f027
+  metadata.gz: 02bea41599b8c1f8697024cf8a51edf7c440f123df6fa2b13a98057b87f9b9c6
+  data.tar.gz: c31039b38eb67f65fd51a3811c2eaf2ff7923dfe44c6df4c6fe5df94f4c71c3f
 SHA512:
-  metadata.gz: 8cef9f595cb3ab96d24b249bb5dd758d87d20b9fdfc26f14b56290dab4210707227037e3691228ce6e16fa83de8c502a533aa597cc2ccad36d6ffa56599ea4b1
-  data.tar.gz: b34a783f590850c73237116f7044aae7c0c58deb9b99e30c8e48ac31213073ccf6dfacac6cfefe516ccdf236dea329655bae2fafc1b306fa33c817b33ceab928
+  metadata.gz: a378b77c653e52cc4ddab51ee850d6eee2ff070b74dbfcf04a723c857b8d0e5ff9f9447446123f75a6409cbd4e016303e02c117b72bff22cf8f414c00f8feb7a
+  data.tar.gz: ad50a392d982957340b9fe47972df7942e636c67dd143e2449986f3439f07b976f4a1780e111428938073df1441c39caf48ecf1f80b322bea1d6268dfad5aa0f

data/lib/specguard/rspec/version.rb

@@ -2,6 +2,6 @@
 
 module SpecGuard
   module RSpec
-    VERSION = "0.2.3"
+    VERSION = "0.2.4"
   end
 end

data/lib/specguard/rspec/violation_renderer.rb

@@ -339,9 +339,58 @@ module SpecGuard
 
       # The ecosystem's shared vocabulary for interpolating a VALUE into a
       # violation message. `validate-intent` renders the same values the same
-      # way (its `RenderValue`), and message_parity_spec.rb pins the two
-      # against each other — getting this wrong is not cosmetic, because
-      # `value 'e2e' is not one of [...]` is a line CI logs get diffed on.
+      # way (its `RenderValue`) BY CONVENTION — neither program is generated
+      # from the other — but EDITING THIS METHOD IS PINNED, so expect red.
+      # validator_backend_spec.rb asserts this path's rendered stdout, byte for
+      # byte, against reports RECORDED from the binary and committed as
+      # spec/fixtures/validator/source-corpus.json, which carries the binary's
+      # own text; message_parity_spec.rb asserts four payloads through
+      # `Schema#violations` against strings hand-copied from the binary (its
+      # header refuses to be read as a proof about two programs, and is right —
+      # four hand-copied strings are not a second process). Change the String
+      # arm and BOTH SNAPSHOTS fail, quoting the binary's spelling back at you:
+      # message_parity_spec.rb, and validator_backend_spec.rb on both stdout
+      # and `--json`. (This gem's own unit and regression specs go red as well,
+      # but those are the gem checking itself, not the binary.) That is the
+      # coupling working, not unrelated breakage.
+      #
+      # The pin runs ONE WAY. Both are snapshots taken from the binary, and no
+      # SPEC in this gem executes it — validator_backend_spec.rb replays the
+      # recorded stdout through a shell stub it writes to a tmpdir. The gem
+      # itself does execute the binary, but only on the `ValidatorBackend` arm
+      # that `SPECGUARD_VALIDATE_INTENT` selects INSTEAD of this renderer: `CLI`
+      # loads the `Schema` only when that backend is absent, and returns the
+      # backend's results before it would ever build a `Linter`, so a LINT run
+      # on that arm does not reach this method. That arm reports the binary's
+      # own rendered strings, so it substitutes Go's spelling for this method's
+      # rather than checking one against the other. Note the env var takes this
+      # method out of the LINTER only, not out of service: `AnnotationLookup`
+      # reaches it through the same `Schema#violations` on the formatter's
+      # annotation path, which does not consult the backend at all.
+      #
+      # So a change on THIS side is caught immediately, while a change on the Go
+      # side is caught only once someone re-records the corpus. Getting it wrong
+      # is not cosmetic either way, because `value 'e2e' is not one of [...]` is
+      # a line CI logs get diffed on.
+      #
+      # Only the String and Array arms are reachable from `Schema#violations`:
+      # the schema types every property `string` or array-of-`string`, carries
+      # no numeric bounds (`minimum`/`maximum`/`multipleOf` are all absent;
+      # `minLength` is present, but its message reports a character count, not
+      # the value), and sets `additionalProperties: false`, so a non-string
+      # value produces a type-mismatch line and the one message that would
+      # interpolate the instance value (`enum_entry`) is dropped by
+      # `drop_shadowed_by_type_mismatch`. Neither snapshot above can reach the
+      # remaining arms, so nothing pins THOSE against the binary — but they are
+      # not all unheld. violation_renderer_spec.rb drives some of them from this
+      # side, with expectations phrased the validator's way: a bare `enum`
+      # property with no `type` (so there is no type-mismatch line to shadow the
+      # enum message) asserts `None` and `True`, and a hypothetical grown schema
+      # carrying `minimum`/`maximum` asserts `value 3 is below minimum 5`. Edit
+      # the nil, `true` or Integer arm and that file goes red — this gem holding
+      # itself to Go's spelling, with the binary not consulted at all. The
+      # `false` arm and the `inspect` fallback have no such example: blanking
+      # both leaves the suite green.
       def render_value(value)
         case value
         when String then render_quoted(value)

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: specguard-rspec
 version: !ruby/object:Gem::Version
-  version: 0.2.3
+  version: 0.2.4
 platform: ruby
 authors:
 - specguard Agent
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-08-18 00:00:00.000000000 Z
+date: 2026-08-20 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: json_schemer