polyrun 2.2.3 → 2.2.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 65f2008623ad5bcf9289da8ffb3db95cf07d8261d349978b96ca463b0ff37ea3
-  data.tar.gz: a1fabab4fe6cc0f571b09d8f8a73559866730d6a76a0bc09b48f4a0e0631a724
+  metadata.gz: de79eaae07044fa991b839a44011f7648df5ba16d0586a1ea2708c1d7160cf5e
+  data.tar.gz: f3cbab3bf642164ffa507aa75be1acaaf7a232057b1b1c5f3fcdb0f804c2a0a7
 SHA512:
-  metadata.gz: eb24b21418a3804b868f62f72f1d8462b15f4b7ab0a9901e82789fdb0c7eb04a73ece7bd437ae10acc8c4edbffd53e64ae9e648e09376e6d9d7df2789b42be78
-  data.tar.gz: f0dd0a2b341c81ce8ea3f10358e06f205a0f7329d5695eb82e49a97e067133fe5b665b444c1b57236740a0e354b9945658f2e1351e54730a358583cc411641fb
+  metadata.gz: f62f0cbc1760e3fc42a4711b7e55eace3b8b5bb038836abcae91eba876cfabf9b72832e2f04a284744fdf09247288bff6b60c7a3b1a38d00ee140d37634702df
+  data.tar.gz: 4f9b6d94992745419d35a5bbb40041094569f725470904f546566bfdba7a3e7eeca899f5b80844d9908ca36e744870fef3f8ecef6e20d589fa090d0363859147

data/CHANGELOG.md

@@ -1,5 +1,12 @@
 # CHANGELOG
 
+## Unreleased
+
+## 2.2.4 (2026-09-04)
+
+- Fix `DEBUG_SQL` / `POLYRUN_DEBUG_SQL` raising `NoMethodError` for `loggable_sql?` when the SQL subscriber runs on an RSpec example group.
+- Add `rfcs/` starter pack: process (RFC 0001), positioning (RFC 0002), and Standards Track design RFCs 0003–0006 for shard layouts, coverage merge, hooks, and partition config.
+
 ## 2.2.3 (2026-08-16)
 
 - Fix `merge-failures` `Encoding::CompatibilityError` when JSONL or RSpec JSON contains UTF-8 and the process locale is US-ASCII; read fragments as UTF-8

data/CODE_OF_CONDUCT.md

@@ -1,31 +1,26 @@
 # Code of Conduct
 
-## Our Pledge
+## Pledge
 
-We pledge to make participation in our community a harassment-free experience for everyone. We operate on principles of mutual respect, privacy, and authentic engagement. We value substantive contributions and clarity on intentions.
+Participation is a harassment-free experience. Treat each other with respect. Keep private context private.
 
-## Our Standards
+## Expected behavior
 
-Examples of behavior that contributes to a positive environment include:
+- Engage with genuine curiosity. Admit uncertainty.
+- Own every line you submit, including generated code.
+- Correct errors politely.
+- Use language that welcomes people and respects identity and privacy.
 
-- Authenticity: Engaging with genuine curiosity and admitting uncertainty rather than feigning knowledge.
-- Responsible Innovation: Taking full responsibility for any content or code contributed, whether manually written or generated by automation tools.
-- Gentle Correction: Responding politely to errors. We view mistakes as opportunities for learning, provided they are addressed with humility.
-- Inclusive Language: Using language that welcomes diverse perspectives and respects the privacy and identity of all participants.
+## Unacceptable behavior
 
-Examples of unacceptable behavior include:
+- Harassment, trolling, or insulting comments, public or private.
+- Using jargon or volume, including automated spam, to silence others.
+- Sharing others' data or personal context without permission.
 
-- Harassment: Public or private harassment, trolling, or insulting comments.
-- Weaponized Complexity: Using jargon or overwhelming volume (including automated spam) to silence others.
-- Publishing Private Information: Sharing others' data or personal context without explicit permission.
+## Automation
 
-## Artificial Intelligence and Automation
-
-In accordance with our commitment to collective awareness:
-
-- Contributors are responsible for the accuracy and security of any AI-generated artifacts they submit.
-- "The AI wrote it" is not a valid excuse for introducing bugs, security vulnerabilities, or bias.
+You remain responsible for bugs, security holes, and bias in generated artifacts you submit.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at contact@kiskolabs.com. All complaints will be reviewed and investigated promptly and fairly.
+Report abusive or harassing behavior to contact@kiskolabs.com. Reports are reviewed and investigated.

data/CONTRIBUTING.md

@@ -1,29 +1,23 @@
 # Contributing Guidelines
 
-Thank you for your interest in contributing. We value learning over perfection but require rigor and responsibility.
+## Automation authorship
 
-## The Golden Rule of Automation
+You may use AI and automation tools. You remain the author of every line you submit: review, debug, and understand the change.
 
-We welcome the use of AI and automation tools to reduce toil, but you must strictly adhere to the following:
+Keep pull requests small enough to review. Annotate non-obvious logic.
 
-1. You are the Author: You act as the responsible agent for any code you submit. You must review, debug, and understand every line.
-2. Manage Cognitive Load: Do not submit massive, unreviewed automated dumps. Respect the reviewers' time by annotating complex logic.
-3. Security: Never feed project secrets or private context into public AI models.
+Never send project secrets or private context to public models.
 
-## How to Contribute
+## How to contribute
 
-### 1. Reporting Issues
+### Reporting issues
 
-- Verify Accuracy: Before posting, verify your information. Avoid generalizations.
-- Use Structured Inputs: Use issue templates to provide clear goals, constraints, and reproduction steps. This helps us understand the context immediately.
+Verify the facts before filing. Use issue templates for goals, constraints, and reproduction steps.
 
-### 2. Pull Request Process
+### Pull requests
 
-- Scope: Keep PRs focused on a single goal.
-- Context: Explain why the change is necessary. Transparency builds trust.
-- Testing: Run all smoke tests and regression checks locally. We prioritize safety first.
+Keep one pull request to one goal. Explain why the change is needed. Run smoke tests and regression checks locally before opening the request.
 
-### 3. Review Process
+### Review
 
-- We encourage productive friction. Expect questions about your approach.
-- If a reviewer suggests a change, view it as mutual aid, not criticism.
+Reviewers will ask about approach and trade-offs. Treat suggested changes as part of the work.

data/README.md

@@ -2,6 +2,8 @@
 
 Ruby gem for parallel test runs, merged coverage (SimpleCov-compatible JSON to JSON, LCOV, Cobertura, or console output), CI reporting (JUnit, timing), and parallel-test hygiene (fixtures, snapshots, per-shard databases, asset preparation). Ship it as one development dependency: no runtime gem dependencies beyond the standard library and vendored code.
 
+Design changes go through `rfcs/` (RFC 0001).
+
 ## Why?
 
 Running tests in parallel across processes still requires a single merged coverage report, stable shard assignment, isolated databases per worker so rows are not shared, and reliable timing data for cost-based splits—without wiring together many small tools and shell scripts.

data/SECURITY.md

@@ -2,26 +2,24 @@
 
 ## Reporting a Vulnerability
 
-Do not open a public issue for security vulnerabilities.
-
 Email security details to: security@kiskolabs.com
 
-Include: description, steps to reproduce, potential impact, and suggested fix (if available).
+Send the report only to that address. Include description, steps to reproduce, potential impact, and a suggested fix when you have one.
 
 ### Response Timeline
 
-- We will acknowledge receipt of your report
-- We will provide an initial assessment
-- We will keep you informed of our progress and resolution timeline
+- We will acknowledge receipt of your report.
+- We will provide an initial assessment.
+- We will keep you informed of our progress and resolution timeline.
 
 ### Disclosure Policy
 
-- We will work with you to understand and resolve the issue
-- We will credit you for the discovery (unless you prefer to remain anonymous)
-- We will publish a security advisory after the vulnerability is patched
-- We will coordinate public disclosure with you
+- We will work with you to understand and resolve the issue.
+- We will credit you for the discovery unless you prefer to remain anonymous.
+- We will publish a security advisory after the vulnerability is patched.
+- We will coordinate public disclosure with you.
 
 ## Automation Security
 
-- Context Isolation: It is strictly forbidden to include production credentials, API keys, or Personally Identifiable Information (PII) in prompts sent to third-party LLMs or automation services.
-- Supply Chain: All automated dependencies must be verified.
+- Keep production credentials, API keys, and personal data out of prompts sent to third-party models or automation services.
+- Verify automated dependencies.

data/lib/polyrun/rspec/example_debug_instrumentation.rb

@@ -11,9 +11,9 @@ module Polyrun
         rspec_config.around do |example|
           subscriber = ActiveSupport::Notifications.subscribe("sql.active_record") do |event|
             payload = event.payload[:sql]
-            next unless loggable_sql?(payload)
+            next unless ExampleDebug.loggable_sql?(payload)
 
-            line = sql_with_interpolated_binds(payload, event.payload[:type_casted_binds])
+            line = ExampleDebug.sql_with_interpolated_binds(payload, event.payload[:type_casted_binds])
             io.puts "+ #{line}"
           end
 

data/lib/polyrun/version.rb

@@ -1,3 +1,3 @@
 module Polyrun
-  VERSION = "2.2.3"
+  VERSION = "2.2.4"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: polyrun
 version: !ruby/object:Gem::Version
-  version: 2.2.3
+  version: 2.2.4
 platform: ruby
 authors:
 - Andrei Makarov