schematichq 1.4.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 4a37f9b78f97beda5bfbe730f7f2379af6ebc839d78effba80bb721937c4c543
+  data.tar.gz: 5023b82060064243de4b6e1819d4f8b3d7c28d5a04c120d76d1625208ce2767b
+SHA512:
+  metadata.gz: f794285eeef51f342e46facd95319bb2a9dac39d862f062889076f11bab49fa2dc10626363135e12058c2380db85ab6bf3b6b60a77c6387961596d7e59f1f580
+  data.tar.gz: a2f5fe984d629ac16dc9886c7419bb65790707f263936e0674d506dda69b57df1bae5c472a9e2823dfd5dd0a6c8e850beff8d3e529ca93d91063a7c36adc7910

data/.claude/settings.json

@@ -0,0 +1,16 @@
+{
+  "hooks": {
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bundle exec rubocop --force-exclusion 2>&1 || true",
+            "timeout": 30,
+            "statusMessage": "Running rubocop..."
+          }
+        ]
+      }
+    ]
+  }
+}

data/.claude/skills/pr-review/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: pr-review
+description: Review code changes on the current branch for quality, bugs, performance, and security
+disable-model-invocation: true
+argument-hint: "[optional: LINEAR-TICKET-ID]"
+allowed-tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*), Bash(git show:*), Bash(git branch:*), Bash(gh pr:*), Bash(gh api:*), Bash(~/.claude/scripts/fetch-github-pr.sh:*), Bash(~/.claude/scripts/fetch-sentry-data.sh:*), Bash(~/.claude/scripts/fetch-slack-thread.sh:*)
+---
+
+# Code Review
+
+You are reviewing code changes on the current branch. Your review must be based on the **current state of the code right now**, not on anything you've seen earlier in this conversation.
+
+## CRITICAL: Always Use Fresh Data
+
+**IGNORE any file contents, diffs, or line numbers you may have seen earlier in this conversation.** They may be stale. You MUST re-fetch everything from scratch using the commands below.
+
+## Step 1: Get the Current Diff and PR Context
+
+Run ALL of these commands to get a fresh view:
+
+```bash
+# The authoritative diff -- only review what's in HERE
+git diff main...HEAD
+
+# Recent commits on this branch
+git log --oneline main..HEAD
+
+# PR description and comments
+gh pr view --json number,title,body,comments,reviews,reviewRequests
+```
+
+Also fetch PR review comments (inline code comments):
+
+```bash
+# Get the PR number
+PR_NUMBER=$(gh pr view --json number -q '.number')
+
+# Fetch all review comments (inline comments on specific lines)
+gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/comments --jq '.[] | {path: .path, line: .line, body: .body, user: .user.login, created_at: .created_at}'
+
+# Fetch review-level comments (general review comments)
+gh api repos/{owner}/{repo}/pulls/$PR_NUMBER/reviews --jq '.[] | {state: .state, body: .body, user: .user.login}'
+```
+
+## Step 2: Understand Context from PR Comments
+
+Before reviewing, read through the PR comments and review comments. Note **who** said what (by username).
+
+- **Already-addressed feedback**: If a reviewer pointed out an issue and the author has already fixed it (the fix is visible in the current diff), do NOT re-raise it.
+- **Ongoing discussions**: Note any unresolved threads -- your review should take these into account.
+- **Previous approvals/requests for changes**: Understand what reviewers have already looked at.
+
+**IMPORTANT**: Your review is YOUR independent review. Do not take credit for or reference other reviewers' findings as if they were yours. If another reviewer already flagged something, you can note "as [reviewer] pointed out" but do not present their feedback as your own prior review. Your verdict should be based solely on your own analysis of the current code.
+
+## Step 3: Get Requirements Context
+
+Check if a Linear ticket ID was provided as an argument ($ARGUMENTS). If not, try to extract it from the branch name (pattern: `{username}/{linear-ticket}-{title}`).
+
+If a Linear ticket is found:
+- Use Linear MCP tools (`get_issue`) to get the issue details and comments
+- **Check for a parent ticket**: If the issue has a parent issue, fetch the parent too. Our pattern is to have a parent ticket with project-wide requirements and sub-tickets for specific tasks (often one per repo/PR). The parent ticket will contain the full scope of the project, while the sub-ticket scopes what this specific PR should cover. Use both to assess completeness — the PR should fulfill the sub-ticket's scope, and that scope should be a reasonable subset of the parent's backend-related requirements.
+- Look for Sentry links in the description/comments; if found, use Sentry MCP tools to get error details
+- Assess whether the changes fulfill the ticket requirements
+
+If no ticket is found, check the PR description for context on what the changes are meant to accomplish.
+
+## Step 4: Review the Code
+
+Review ONLY the changed lines (from `git diff main...HEAD`). Do not comment on unchanged code.
+
+**When referencing code, always use the file path and quote the actual code snippet** rather than citing line numbers, since line numbers shift as the branch evolves.
+
+### Code Quality
+- Is the code well-structured and maintainable?
+- Does it follow CLAUDE.md conventions? (import grouping, error handling with lib/errors, naming, alphabetization, etc.)
+- Any AI-generated slop? (excessive comments, unnecessary abstractions, over-engineering)
+
+### Performance
+- N+1 queries, inefficient loops, missing indexes for new queries
+- Unbuffered writes in hot paths (especially ClickHouse)
+- Missing LIMIT clauses on potentially large result sets
+
+### Bugs
+- Nil pointer risks (especially on struct pointer params and optional relations)
+- Functions returning `nil, nil` (violates convention)
+- Missing error handling
+- Race conditions in concurrent code paths
+
+### Security
+- Hardcoded secrets or sensitive data exposure
+- Missing input validation on service request structs
+
+### Tests
+- Are there tests for the new/changed code?
+- Do the tests cover edge cases and error paths?
+- Are test assertions specific (not just "no error")?
+
+## Step 5: Present the Review
+
+Structure your review as:
+
+```
+## Summary
+[1-2 sentences: what this PR does and overall assessment]
+
+## Requirements Check
+[Does the PR fulfill the Linear ticket / PR description requirements? Any gaps?]
+
+## Issues
+### Critical (must fix before merge)
+- [blocking issues]
+
+### Suggestions (nice to have)
+- [non-blocking improvements]
+
+## Prior Review Activity
+[Summarize what other reviewers have flagged, attributed by name. Note which of their concerns have been addressed in the current code and which remain open.]
+
+## Verdict
+[LGTM / Needs changes / Needs discussion -- based on YOUR analysis, not other reviewers' findings]
+```
+
+## Guidelines
+
+- Be concise. Don't pad with praise or filler.
+- Only raise issues that matter. Don't nitpick formatting (that's what linters are for).
+- Quote code snippets rather than referencing line numbers.
+- If PR comments show a discussion was already resolved, don't reopen it.
+- If you're unsure about something, flag it as a question rather than a definitive issue.

data/.fern/metadata.json

@@ -0,0 +1,18 @@
+{
+  "cliVersion": "4.43.1",
+  "generatorName": "fernapi/fern-ruby-sdk",
+  "generatorVersion": "1.1.11",
+  "generatorConfig": {
+    "module": "SchematicHQ",
+    "rubocopVariableNumberStyle": "disabled",
+    "extraDependencies": {
+      "wasmtime": ">= 19.0",
+      "websocket": ">= 1.2"
+    },
+    "extraDevDependencies": {
+      "webrick": ">= 1.0"
+    }
+  },
+  "originGitCommit": "42e108eda47d554722530a9d404ee80ba2da1b28",
+  "sdkVersion": "1.4.0"
+}

data/.fernignore

@@ -0,0 +1,21 @@
+.claude/
+.github/
+.gitignore
+CLAUDE.md
+LICENSE
+README.md
+WASM_VERSION
+custom.gemspec.rb
+lib/schematic/cache.rb
+lib/schematic/datastream/
+lib/schematic/event_buffer.rb
+lib/schematic/logger.rb
+lib/schematic/redis_cache.rb
+lib/schematic/rules_engine.rb
+lib/schematic/schematic_client.rb
+lib/schematic/wasm/
+lib/schematic/webhook_verification.rb
+lib/schematichq.rb
+scripts/
+test/custom.test.rb
+testapp/

data/.rubocop.yml

@@ -0,0 +1,69 @@
+plugins:
+  - rubocop-minitest
+
+AllCops:
+  TargetRubyVersion: 3.3
+  NewCops: enable
+
+Style/StringLiterals:
+  EnforcedStyle: double_quotes
+
+Style/StringLiteralsInInterpolation:
+  EnforcedStyle: double_quotes
+
+Style/AccessModifierDeclarations:
+  Enabled: false
+
+Lint/ConstantDefinitionInBlock:
+  Enabled: false
+
+Metrics/AbcSize:
+  Enabled: false
+
+Metrics/BlockLength:
+  Enabled: false
+
+Metrics/ClassLength:
+  Enabled: false
+
+Metrics/MethodLength:
+  Enabled: false
+
+Metrics/ParameterLists:
+  Enabled: false
+
+Metrics/PerceivedComplexity:
+  Enabled: false
+
+Metrics/CyclomaticComplexity:
+  Enabled: false
+
+Metrics/ModuleLength:
+  Enabled: false
+
+Layout/LineLength:
+  Enabled: false
+
+Naming/VariableNumber:
+  Enabled: false
+
+Style/Documentation:
+  Enabled: false
+
+Style/Lambda:
+  EnforcedStyle: literal
+
+Minitest/MultipleAssertions:
+  Enabled: false
+
+Minitest/UselessAssertion:
+  Enabled: false
+
+# Dynamic snippets are code samples for documentation, not standalone Ruby files.
+Style/FrozenStringLiteralComment:
+  Exclude:
+    - "dynamic-snippets/**/*"
+
+Layout/FirstHashElementIndentation:
+  Exclude:
+    - "dynamic-snippets/**/*"

data/CLAUDE.md

@@ -0,0 +1,45 @@
+# Schematic Ruby SDK
+
+## Architecture
+
+Two-layer SDK:
+1. **Fern-generated layer** (`lib/schematic/`) - Auto-generated API client bindings. Do NOT modify directly.
+2. **Custom layer** (protected via `.fernignore`) - Hand-written wrapper providing higher-level functionality.
+
+## Key Commands
+
+```bash
+# Run all tests (requires Ruby 3.3+)
+/opt/homebrew/opt/ruby/bin/ruby -I lib -I test test/custom.test.rb
+
+# Run linter
+/opt/homebrew/opt/ruby/bin/bundle exec rubocop
+
+# Run test app
+ruby testapp/app.rb
+
+# Download/update WASM binary
+./scripts/download-wasm.sh
+
+# Start webhook test server
+ruby scripts/webhook_test_server.rb <webhook_secret>
+```
+
+## Fern Code Generation
+
+The Fern-generated layer is configured in `schematic-fern-config/fern/generators.yml` (sibling repo). The Ruby SDK uses the `fernapi/fern-ruby-sdk` generator.
+
+Some changes should be configured in the generator config rather than directly as custom code. The  most common example of this is dependencies. Refer to the Fern Ruby SDK generator documentation: https://buildwithfern.com/learn/sdks/generators/ruby/configuration
+
+### Custom Files
+
+All custom files MUST be listed in `.fernignore` to survive Fern regeneration.
+
+## WASM Rules Engine
+
+- Binary: `lib/schematic/wasm/rulesengine.wasm` (gitignored; downloaded at build time)
+- Runtime: `wasmtime` gem (required dependency)
+- Version pin: `WASM_VERSION` file at repo root
+- Download: `./scripts/download-wasm.sh` fetches from internal WASM binary registry
+- C ABI exports: `alloc`, `dealloc`, `checkFlagCombined`, `getResultJson`, `getResultJsonLength`, `get_version_key_wasm`
+- Input: JSON envelope `{"flag": {...}, "company": {...}, "user": {...}}`

data/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023-2026 Schematic, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.