@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/huggingface-ml/references/inference-optimization.md

@@ -1,264 +0,0 @@
-# Inference Optimization
-
-Load this when optimizing model inference latency, memory usage, or throughput for production deployment.
-
-## Device and Memory Management
-
-### Automatic Device Mapping
-
-```python
-from transformers import AutoModelForCausalLM
-
-# Automatically distribute across available GPUs and CPU
-model = AutoModelForCausalLM.from_pretrained(
-    "meta-llama/Meta-Llama-3-8B-Instruct",
-    device_map="auto",
-    torch_dtype=torch.float16,
-)
-```
-
-- `device_map="auto"` splits the model across available GPUs. If GPU memory is insufficient, it offloads layers to CPU.
-- `torch_dtype=torch.float16` halves memory usage with minimal quality impact for inference.
-- Use `device_map="balanced"` to distribute evenly across GPUs.
-- Use `max_memory={"cuda:0": "10GB", "cpu": "30GB"}` to set per-device limits.
-
-### Explicit Device Placement
-
-```python
-import torch
-
-device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
-model = AutoModel.from_pretrained("bert-base-uncased").to(device)
-tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased")
-
-inputs = tokenizer("Hello world", return_tensors="pt").to(device)
-with torch.no_grad():
-    outputs = model(**inputs)
-```
-
-## Quantization
-
-### BitsAndBytes (Dynamic Quantization)
-
-```python
-from transformers import BitsAndBytesConfig
-
-# 4-bit quantization
-config_4bit = BitsAndBytesConfig(
-    load_in_4bit=True,
-    bnb_4bit_quant_type="nf4",           # Normal Float 4-bit
-    bnb_4bit_compute_dtype=torch.float16, # Compute in fp16
-    bnb_4bit_use_double_quant=True,       # Quantize the quantization constants
-)
-
-# 8-bit quantization (less aggressive, higher quality)
-config_8bit = BitsAndBytesConfig(load_in_8bit=True)
-
-model = AutoModelForCausalLM.from_pretrained(
-    model_id,
-    quantization_config=config_4bit,
-    device_map="auto",
-)
-```
-
-### GPTQ (Static Quantization)
-
-Pre-quantized models are available on the Hub with `-GPTQ` suffix.
-
-```python
-from transformers import AutoModelForCausalLM
-
-model = AutoModelForCausalLM.from_pretrained(
-    "TheBloke/Llama-2-7B-Chat-GPTQ",
-    device_map="auto",
-)
-```
-
-- GPTQ is faster than BitsAndBytes at inference because quantization is done offline.
-- Requires a calibration dataset during quantization. Pre-quantized models skip this step.
-
-### AWQ (Activation-Aware Weight Quantization)
-
-```python
-model = AutoModelForCausalLM.from_pretrained(
-    "TheBloke/Llama-2-7B-Chat-AWQ",
-    device_map="auto",
-)
-```
-
-- AWQ preserves important weights at higher precision, providing better quality than uniform quantization.
-- Generally faster than GPTQ with comparable quality.
-
-## Batching Strategies
-
-### Static Batching
-
-```python
-# Pad all sequences to the same length
-inputs = tokenizer(
-    texts,
-    padding=True,
-    truncation=True,
-    max_length=512,
-    return_tensors="pt",
-).to(device)
-
-with torch.no_grad():
-    outputs = model(**inputs)
-```
-
-- Simple but wasteful: short sequences are padded to the longest sequence length.
-- Good for uniform-length inputs (fixed-length classification).
-
-### Dynamic Batching by Length
-
-```python
-from itertools import groupby
-
-def batch_by_length(texts: list[str], bucket_size: int = 64) -> list[list[str]]:
-    """Group texts into buckets of similar length to minimize padding."""
-    sorted_texts = sorted(texts, key=lambda t: len(t.split()))
-    return [
-        list(group)
-        for _, group in groupby(
-            sorted_texts,
-            key=lambda t: len(t.split()) // bucket_size
-        )
-    ]
-```
-
-- Groups texts by approximate length, reducing padding waste by 30-50%.
-- Essential for variable-length inputs like documents and queries.
-
-## Pipeline Optimization
-
-### Pipeline with GPU and Batching
-
-```python
-from transformers import pipeline
-
-classifier = pipeline(
-    "text-classification",
-    model=model_id,
-    device=0,           # GPU index
-    batch_size=32,       # Process 32 texts at a time
-    torch_dtype=torch.float16,
-)
-
-results = classifier(texts, truncation=True, max_length=512)
-```
-
-### Pipeline with Multiple GPUs
-
-```python
-classifier = pipeline(
-    "text-classification",
-    model=model_id,
-    device_map="auto",
-)
-```
-
-## Caching and Warm-Up
-
-### Model Caching
-
-```python
-import os
-
-# Set cache directory (default: ~/.cache/huggingface)
-os.environ["HF_HOME"] = "/data/hf_cache"
-os.environ["TRANSFORMERS_CACHE"] = "/data/hf_cache/transformers"
-
-# Models are cached on first download and loaded from cache on subsequent calls
-model = AutoModel.from_pretrained(model_id)  # downloads once, cached after
-```
-
-### KV-Cache for Generation
-
-```python
-# KV-cache is enabled by default for generation
-outputs = model.generate(
-    input_ids,
-    max_new_tokens=256,
-    use_cache=True,  # default; reuses key-value pairs from previous tokens
-)
-```
-
-- KV-cache avoids recomputing attention for already-generated tokens.
-- Memory usage grows linearly with sequence length. For very long sequences, consider sliding window attention models.
-
-## ONNX Runtime Acceleration
-
-```python
-from optimum.onnxruntime import ORTModelForSequenceClassification
-
-# Export and load model in ONNX format
-model = ORTModelForSequenceClassification.from_pretrained(
-    model_id,
-    export=True,  # converts to ONNX on first load
-)
-
-# Use the same pipeline API
-classifier = pipeline("text-classification", model=model, tokenizer=tokenizer)
-```
-
-- ONNX Runtime provides 1.5-3x speedup over PyTorch for encoder models.
-- Best gains on CPU inference. GPU gains are model-dependent.
-- Use `optimum` library for seamless integration with Transformers.
-
-## Inference API (Serverless)
-
-```python
-from huggingface_hub import InferenceClient
-
-client = InferenceClient(
-    model="meta-llama/Meta-Llama-3-8B-Instruct",
-    token="hf_YOUR_TOKEN",
-    timeout=30,
-)
-
-# Text generation
-response = client.text_generation(
-    "Explain quantum computing in simple terms.",
-    max_new_tokens=200,
-    temperature=0.7,
-)
-
-# Embeddings
-embeddings = client.feature_extraction("Hello, world!")
-```
-
-- Serverless: no GPU provisioning, scales to zero.
-- Rate-limited: use Inference Endpoints for production throughput.
-- Set `timeout` and implement retry logic for cold starts.
-
-## Benchmarking
-
-```python
-import time
-import torch
-
-def benchmark_inference(model, tokenizer, text, n_runs=100):
-    inputs = tokenizer(text, return_tensors="pt").to(model.device)
-
-    # Warm up
-    for _ in range(10):
-        with torch.no_grad():
-            model(**inputs)
-
-    # Benchmark
-    torch.cuda.synchronize()
-    start = time.perf_counter()
-    for _ in range(n_runs):
-        with torch.no_grad():
-            model(**inputs)
-    torch.cuda.synchronize()
-    elapsed = time.perf_counter() - start
-
-    print(f"Average: {elapsed / n_runs * 1000:.1f}ms per inference")
-    print(f"Throughput: {n_runs / elapsed:.0f} inferences/second")
-```
-
-- Always warm up the model before benchmarking to exclude initialization costs.
-- Use `torch.cuda.synchronize()` to ensure GPU operations complete before timing.
-- Benchmark with representative input lengths, not just short strings.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/huggingface-ml/references/model-selection.md

@@ -1,152 +0,0 @@
-# Model Selection
-
-Load this when searching for pre-trained models, choosing between architectures, or evaluating model suitability for a task.
-
-## Hub Search Strategy
-
-### By Task
-
-The Hub organizes models by task type. Start here when you know what you want to do but not which model to use.
-
-| Task | Top Models | Notes |
-|------|-----------|-------|
-| Text Classification | `distilbert-base-uncased`, `roberta-base` | Fine-tune on your labels |
-| Token Classification (NER) | `bert-base-NER`, `roberta-large-ner` | Pre-trained on CoNLL-2003 |
-| Question Answering | `deepset/roberta-base-squad2` | Extractive QA from context |
-| Summarization | `facebook/bart-large-cnn`, `google/pegasus-xsum` | Abstractive summarization |
-| Translation | `Helsinki-NLP/opus-mt-*` | Language-pair specific |
-| Text Generation | `meta-llama/Meta-Llama-3-8B-Instruct` | Chat and instruction following |
-| Sentence Embeddings | `sentence-transformers/all-MiniLM-L6-v2` | Fast, good quality for search |
-| Image Classification | `google/vit-base-patch16-224` | Vision Transformer |
-| Object Detection | `facebook/detr-resnet-50` | End-to-end detection |
-| Speech-to-Text | `openai/whisper-large-v3` | Multilingual ASR |
-
-### Filtering on the Hub
-
-```python
-from huggingface_hub import HfApi
-
-api = HfApi()
-
-# Search by task and sort by downloads
-models = api.list_models(
-    task="text-classification",
-    sort="downloads",
-    direction=-1,
-    limit=10,
-)
-
-for model in models:
-    print(f"{model.modelId}: {model.downloads:,} downloads")
-```
-
-### Evaluation Criteria
-
-When comparing models for the same task:
-
-1. **Task alignment** -- Does the model's training task match yours? A sentiment model will not classify support tickets without fine-tuning.
-2. **Size vs latency** -- Smaller models (DistilBERT, MiniLM) are 2-5x faster with 5-15% quality loss vs their full-size counterparts.
-3. **Downloads and community adoption** -- High download counts indicate community validation and easier debugging.
-4. **License** -- Apache 2.0 and MIT are permissive. Models with custom licenses (Llama, Mistral) may have commercial use restrictions.
-5. **Model card quality** -- A thorough model card with evaluation results, training data, and limitations indicates a well-maintained model.
-
-## Architecture Selection Guide
-
-### Encoder Models (BERT family)
-
-Best for understanding and classification tasks.
-
-```python
-from transformers import AutoModel
-
-# Good for: classification, NER, embeddings, QA
-model = AutoModel.from_pretrained("bert-base-uncased")
-```
-
-- **BERT**: Foundation encoder. Good baseline for fine-tuning.
-- **RoBERTa**: Better pre-training. Usually outperforms BERT.
-- **DistilBERT**: 40% smaller, 60% faster, 97% of BERT quality.
-- **DeBERTa**: State-of-the-art on many benchmarks. Larger and slower.
-
-### Decoder Models (GPT family)
-
-Best for text generation and instruction following.
-
-```python
-from transformers import AutoModelForCausalLM
-
-# Good for: chat, code generation, creative writing, reasoning
-model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")
-```
-
-- **Llama 3**: Strong open model. 8B and 70B sizes.
-- **Mistral**: Efficient architecture with sliding window attention.
-- **Phi-3**: Small but capable (3.8B). Good for resource-constrained deployment.
-- **Gemma**: Google's open model. Good for fine-tuning.
-
-### Encoder-Decoder Models (T5 family)
-
-Best for sequence-to-sequence tasks.
-
-```python
-from transformers import AutoModelForSeq2SeqLM
-
-# Good for: summarization, translation, data-to-text
-model = AutoModelForSeq2SeqLM.from_pretrained("google/flan-t5-base")
-```
-
-- **T5/Flan-T5**: Versatile. Frame any task as text-to-text.
-- **BART**: Strong for summarization and denoising.
-- **mBART**: Multilingual translation and generation.
-
-## Size and Resource Planning
-
-| Model Size | GPU Memory | Inference Latency | Use Case |
-|-----------|------------|-------------------|----------|
-| < 500M params | 2-4 GB | < 50ms | Real-time APIs, edge deployment |
-| 1-3B params | 4-8 GB | 50-200ms | Balanced quality and speed |
-| 7-8B params | 16-24 GB | 200-500ms | High quality, dedicated GPU |
-| 13-70B params | 40-140 GB | 500ms-5s | Maximum quality, multi-GPU |
-
-### Quantization for Smaller Footprint
-
-```python
-from transformers import AutoModelForCausalLM, BitsAndBytesConfig
-
-# 4-bit quantization: ~4x memory reduction
-bnb_config = BitsAndBytesConfig(
-    load_in_4bit=True,
-    bnb_4bit_quant_type="nf4",
-    bnb_4bit_compute_dtype=torch.float16,
-)
-
-model = AutoModelForCausalLM.from_pretrained(
-    "meta-llama/Meta-Llama-3-8B-Instruct",
-    quantization_config=bnb_config,
-    device_map="auto",
-)
-```
-
-- 4-bit quantization reduces a 7B model from ~14 GB to ~4 GB with minimal quality loss.
-- 8-bit quantization is a safer choice with less quality degradation.
-- GPTQ and AWQ are alternative quantization methods with pre-quantized models available on the Hub.
-
-## Version Pinning
-
-```python
-# Pin to a specific revision (commit hash)
-model = AutoModel.from_pretrained(
-    "bert-base-uncased",
-    revision="a265f773a47193eed794233aa2a0f0bb6d3eaa63",
-)
-
-# Pin to a specific branch or tag
-model = AutoModel.from_pretrained(
-    "bert-base-uncased",
-    revision="v1.0",
-)
-```
-
-- Always pin model revisions in production. Hub models can be updated by their authors.
-- Use commit hashes for immutable references. Branch names and tags can be moved.
-- Store the exact revision in your deployment configuration for reproducibility.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/integration-testing/evals/assertions.md

@@ -1,42 +0,0 @@
-# Integration Testing -- Eval Assertions
-
-## Eval 001: API Contract Verification Between Services
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `contract` | The response must recommend consumer-driven contract testing as the primary approach to prevent field-rename breakages between services. |
-| 2 | contains | `consumer` | The response must identify the frontend as the consumer that defines the expected response shape, since the consumer knows what fields it needs. |
-| 3 | contains | `provider` | The response must describe provider-side verification where the backend validates its responses against the consumer contract. |
-| 4 | contains | `CI` | The response must integrate contract verification into the CI/CD pipeline so breaking changes are caught before deployment. |
-| 5 | contains | `schema` | The response must define a contract schema specifying expected field names and types, directly preventing the `role` to `userRole` rename issue. |
-
-### What a Passing Response Looks Like
-
-A passing response designs a contract testing strategy that:
-- Uses a consumer-driven approach (e.g., Pact, Spring Cloud Contract) where the frontend defines expected fields.
-- Includes a contract file that specifies `id`, `name`, `email`, and `role` as required fields with types.
-- Describes how the provider (user-service) runs verification against the contract on every build.
-- Integrates into CI so a rename like `role` -> `userRole` fails the provider build before merge.
-- Explains the workflow: consumer publishes contract, provider verifies, both run in CI.
-
----
-
-## Eval 002: Database Integration Test Setup with Containers
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `container` | The response must recommend Testcontainers or equivalent ephemeral container approach for CI-compatible database provisioning. |
-| 2 | contains | `migrat` | The response must include running database migrations in the test setup to ensure schema matches production. |
-| 3 | contains | `rollback` | The response must use transaction rollback or equivalent mechanism for per-test data isolation. |
-| 4 | contains | `seed` | The response must describe a fixture seeding strategy for populating test data in a controlled manner. |
-| 5 | contains | `cleanup` | The response must include a teardown or cleanup phase that removes test artifacts and stops containers. |
-
-### What a Passing Response Looks Like
-
-A passing response designs a database integration test environment that:
-- Spins up a PostgreSQL container using Testcontainers in the beforeAll/setup phase.
-- Runs schema migrations against the ephemeral database.
-- Seeds known test data (fixtures) for predictable assertions.
-- Wraps each test in a transaction that rolls back, ensuring isolation.
-- Tears down the container after all tests complete.
-- Shows the complete lifecycle: container start -> migrate -> seed -> test (in transaction) -> rollback -> container stop.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/integration-testing/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "integration-testing-eval-001",
-    "name": "API contract verification between services",
-    "description": "Evaluate the skill's ability to design consumer-driven contract tests between a frontend application and a backend user service API, ensuring contracts are verified independently.",
-    "prompt": "Our frontend app consumes a GET /api/users/:id endpoint from the user-service. The response includes id, name, email, and role fields. Recently, the backend team renamed 'role' to 'userRole' and broke the frontend. Design an integration testing strategy using contract tests to prevent this from happening again. Include the contract definition, provider verification, and CI integration.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "contract",
-        "description": "Should recommend consumer-driven contract testing as the primary solution"
-      },
-      {
-        "type": "contains",
-        "value": "consumer",
-        "description": "Should identify the frontend as the consumer that defines expected response shape"
-      },
-      {
-        "type": "contains",
-        "value": "provider",
-        "description": "Should describe provider-side verification that runs against the contract"
-      },
-      {
-        "type": "contains",
-        "value": "CI",
-        "description": "Should integrate contract verification into CI/CD pipeline to catch breaks before deploy"
-      },
-      {
-        "type": "contains",
-        "value": "schema",
-        "description": "Should define a contract schema that specifies expected field names and types"
-      }
-    ]
-  },
-  {
-    "id": "integration-testing-eval-002",
-    "name": "Database integration test setup with containers",
-    "description": "Evaluate the skill's ability to set up a database integration test environment using test containers, including migration, fixture seeding, isolation, and teardown.",
-    "prompt": "I need to write integration tests for a UserRepository that performs CRUD operations against PostgreSQL. The tests should run in CI without requiring a shared database. Design the complete test setup including database provisioning, schema migration, test data seeding, per-test isolation, and cleanup. Show the test lifecycle.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "container",
-        "description": "Should recommend Testcontainers or ephemeral container-based PostgreSQL for CI isolation"
-      },
-      {
-        "type": "contains",
-        "value": "migrat",
-        "description": "Should include running database migrations as part of the test setup phase"
-      },
-      {
-        "type": "contains",
-        "value": "rollback",
-        "description": "Should use transaction rollback or equivalent for per-test data isolation"
-      },
-      {
-        "type": "contains",
-        "value": "seed",
-        "description": "Should describe a fixture seeding strategy for test data"
-      },
-      {
-        "type": "contains",
-        "value": "cleanup",
-        "description": "Should include a teardown or cleanup phase to remove test artifacts"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/java-best-practices/evals/assertions.md

@@ -1,33 +0,0 @@
-# Java Best Practices - Eval Assertions
-
-## Eval 1: Virtual Threads Migration
-
-This eval tests the skill's ability to guide a migration from platform thread pools to virtual threads with structured concurrency.
-
-### Assertions
-
-1. **Uses virtual thread executor** -- The migration must replace the fixed `ThreadPoolTaskExecutor` with `Executors.newVirtualThreadPerTaskExecutor()` or Spring Boot 3.2+'s `spring.threads.virtual.enabled=true`. Virtual threads eliminate the thread-per-request bottleneck by allowing millions of concurrent tasks on a small number of carrier threads.
-
-2. **Replaces synchronized with ReentrantLock** -- `synchronized` blocks pin virtual threads to their carrier thread, negating the scalability benefit. The code must identify all `synchronized` usage in the request path and convert to `ReentrantLock.lock()`/`unlock()` in try-finally blocks. This is the most critical correctness issue in virtual thread adoption.
-
-3. **Uses StructuredTaskScope for parallel calls** -- The 3 downstream HTTP calls should be forked within a `StructuredTaskScope.ShutdownOnFailure` so that if any call fails, the others are cancelled automatically. The scope must be used in a try-with-resources block with `scope.join()` and `scope.throwIfFailed()`.
-
-4. **Warns about CPU-bound work** -- Virtual threads should not be used for computation-heavy tasks (JSON parsing of large payloads, encryption, image processing) because they share carrier threads. The response must explain this limitation and recommend keeping CPU-bound work on platform thread pools or `ForkJoinPool`.
-
-5. **Includes monitoring guidance** -- Virtual thread debugging differs from platform threads. The response should mention JDK Flight Recorder (JFR) events for virtual threads, `jcmd Thread.dump_to_file` for structured thread dumps, or testing strategies to verify the migration works under load.
-
-## Eval 2: Domain Modeling with Sealed Classes
-
-This eval tests the skill's ability to model a complex state machine using sealed classes, records, and pattern matching.
-
-### Assertions
-
-1. **Sealed interface with permits** -- The Payment type must be a `sealed interface` or `sealed class` with a `permits` clause explicitly listing all allowed subtypes (Pending, Authorized, Captured, Refunded, Declined, Cancelled). This makes the type hierarchy closed and enables exhaustive pattern matching.
-
-2. **Records for state variants** -- Each payment state should be a `record` carrying only the data relevant to that state. For example, `Authorized` carries an auth code, `Captured` carries a capture timestamp. Records provide immutability and structural equality, which are ideal for state representations.
-
-3. **Pattern matching switch for transitions** -- State transition logic should use Java 21's switch expression with pattern matching rather than instanceof chains or the visitor pattern. The compiler verifies exhaustiveness against the sealed hierarchy, catching missing cases at compile time.
-
-4. **Guarded patterns for transition validation** -- Valid state transitions should be enforced using guarded patterns (`case Authorized a when isWithinAuthWindow(a)`) or explicit validation in the transition method. Invalid transitions (e.g., Refunded -> Authorized) should throw a descriptive exception.
-
-5. **Serialization strategy for sealed hierarchy** -- Persisting and transmitting the payment hierarchy requires a discriminator-based serialization strategy. Jackson's `@JsonTypeInfo` with `@JsonSubTypes` is the standard approach. The response should show how to configure this for the sealed hierarchy so that deserialization produces the correct record subtype.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/java-best-practices/evals/evals.json

@@ -1,32 +0,0 @@
-{
-  "skill_name": "java-best-practices",
-  "platform": "claude-code",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I have a Spring Boot service that makes 3 blocking HTTP calls to downstream services for each incoming request, using a ThreadPoolTaskExecutor with 200 platform threads. At peak load we're running out of threads and requests queue up. Migrate this to virtual threads and structured concurrency so it can handle thousands of concurrent requests without thread pool exhaustion.",
-      "expected_output": "A migration showing virtual thread executor configuration, replacement of synchronized blocks with ReentrantLock, structured concurrency with StructuredTaskScope for the 3 parallel downstream calls, and guidance on monitoring the migration.",
-      "files": [],
-      "assertions": [
-        "Uses Executors.newVirtualThreadPerTaskExecutor() or Spring Boot's virtual thread auto-configuration instead of the fixed thread pool",
-        "Replaces synchronized blocks with ReentrantLock to avoid carrier thread pinning",
-        "Uses StructuredTaskScope (ShutdownOnFailure or ShutdownOnSuccess) for the 3 parallel downstream calls with proper join and error handling",
-        "Warns against using virtual threads for CPU-bound work and explains carrier thread starvation",
-        "Includes guidance on monitoring virtual threads (JFR events, thread dumps) or testing the migration"
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "I'm modeling a payment processing domain. Payments can be in states: Pending, Authorized, Captured, Refunded, Declined, and Cancelled. Each state carries different data (Authorized has an auth code, Captured has a capture timestamp, Refunded has a refund amount and reason). Design this domain model using sealed classes, records, and pattern matching. Show how to write a state transition function and how to serialize/deserialize the hierarchy.",
-      "expected_output": "A sealed interface Payment hierarchy with record subtypes for each state, a state transition method using pattern matching switch, and serialization strategy with Jackson discriminator configuration.",
-      "files": [],
-      "assertions": [
-        "Defines a sealed interface or sealed class for Payment with permits clause listing all state variants",
-        "Uses records for each payment state variant carrying state-specific data (auth code, capture timestamp, refund amount/reason)",
-        "Implements state transition logic using switch expression with pattern matching and exhaustiveness checking",
-        "Uses guarded patterns (case ... when) or validation in transition methods to enforce valid state transitions",
-        "Includes Jackson @JsonTypeInfo/@JsonSubTypes configuration or equivalent for polymorphic serialization of the sealed hierarchy"
-      ]
-    }
-  ]
-}