@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/microservices-design/references/saga-pattern.md

@@ -1,225 +0,0 @@
-# Saga Pattern
-
-## Overview
-
-A saga is a sequence of local transactions in different services where each step has a compensating action that undoes its effect if a later step fails. Sagas replace distributed transactions (2PC) which are impractical in microservices.
-
-## Saga Types
-
-### Orchestration
-
-A central **saga orchestrator** controls the flow:
-
-```
-                    ┌──────────────┐
-                    │    Saga      │
-                    │ Orchestrator │
-                    └──────┬───────┘
-                           │
-         ┌─────────┬───────┼───────┬──────────┐
-         │         │       │       │          │
-         ▼         ▼       ▼       ▼          ▼
-      ┌─────┐  ┌─────┐ ┌─────┐ ┌─────┐  ┌─────┐
-      │Order│  │Pay  │ │Inv  │ │Ship │  │Notif│
-      │Svc  │  │Svc  │ │Svc  │ │Svc  │  │Svc  │
-      └─────┘  └─────┘ └─────┘ └─────┘  └─────┘
-```
-
-The orchestrator:
-1. Knows the sequence of steps
-2. Calls each service in order
-3. Receives success/failure responses
-4. Triggers compensating actions on failure
-5. Maintains the saga state machine
-
-| Pro | Con |
-|-----|-----|
-| Easy to understand the flow | Single point of coordination (but not failure — it is stateless) |
-| Easy to add new steps | Orchestrator can become a "god service" if not careful |
-| Easy to implement timeouts | Slightly higher coupling (orchestrator knows all services) |
-| Easy to test end-to-end | More code to maintain |
-
-### Choreography
-
-Each service listens for events and reacts independently:
-
-```
-OrderSvc ──OrderPlaced──► PaymentSvc ──PaymentCharged──► InventorySvc
-                                                              │
-                                                     InventoryReserved
-                                                              │
-                                                              ▼
-                                                         ShippingSvc
-                                                              │
-                                                     ShipmentScheduled
-                                                              │
-                                                              ▼
-                                                       NotificationSvc
-```
-
-| Pro | Con |
-|-----|-----|
-| No central coordinator | Hard to see the full flow |
-| Loose coupling between services | Hard to implement timeouts |
-| Each service is autonomous | Compensation logic is scattered |
-| Natural fit for event-driven systems | Debugging requires tracing across services |
-
-### When to Choose
-
-| Criteria | Orchestration | Choreography |
-|----------|-------------|--------------|
-| Number of steps | 4+ steps | 2-3 steps |
-| Compensating actions | Complex, order-dependent | Simple, independent |
-| Timeout requirements | Per-step timeouts needed | Global timeout sufficient |
-| Team structure | One team owns the workflow | Different teams own each step |
-| Debugging needs | Must trace exact step failures | Event tracing is acceptable |
-
-## Designing Compensating Actions
-
-### Properties
-
-Every compensating action must be:
-
-1. **Semantically reversing:** Undoes the business effect of the forward action (refund reverses charge).
-2. **Idempotent:** Can be called multiple times safely (retry of a refund does not double-refund).
-3. **Commutative with retries:** The order of compensating actions should not matter (if possible).
-
-### Compensation Table
-
-| Forward Action | Compensating Action | Notes |
-|---------------|-------------------|-------|
-| Create Order | Cancel Order | Set status to cancelled, soft delete |
-| Charge Payment | Refund Payment | Full refund via payment gateway |
-| Reserve Inventory | Release Inventory | Restore stock count |
-| Schedule Shipment | Cancel Shipment | Cancel with carrier API |
-| Send Notification | No compensation | Notifications are informational; send a correction if needed |
-| Create Account | Deactivate Account | Soft delete, do not hard delete (audit trail) |
-| Publish Event | Publish Compensation Event | e.g., OrderCancelled reverses OrderPlaced |
-
-### Actions Without Compensation
-
-Some actions cannot be undone:
-- Emails sent cannot be unsent (but a correction email can be sent)
-- External API calls may not support reversal
-- Physical actions (warehouse picking) may be irreversible
-
-For these, place them last in the saga sequence so that they execute only after all reversible steps have succeeded.
-
-## State Machine
-
-The saga orchestrator is a state machine:
-
-```
-States:
-  STARTED           → Initial state
-  ORDER_CREATED     → After CreateOrder succeeds
-  PAYMENT_CHARGED   → After ChargePayment succeeds
-  INVENTORY_RESERVED→ After ReserveInventory succeeds
-  SHIPMENT_SCHEDULED→ After ScheduleShipment succeeds
-  COMPLETED         → After all steps succeed
-  COMPENSATING      → A step failed, running compensations
-  FAILED            → All compensations complete (or exhausted retries)
-
-Transitions:
-  STARTED → ORDER_CREATED           (on CreateOrder success)
-  ORDER_CREATED → PAYMENT_CHARGED   (on ChargePayment success)
-  PAYMENT_CHARGED → INVENTORY_RESERVED (on ReserveInventory success)
-  INVENTORY_RESERVED → SHIPMENT_SCHEDULED (on ScheduleShipment success)
-  SHIPMENT_SCHEDULED → COMPLETED    (on SendNotification success)
-
-  Any state → COMPENSATING          (on step failure or timeout)
-  COMPENSATING → FAILED             (all compensations done)
-```
-
-## Persistence
-
-The saga state must be persisted so that recovery is possible after an orchestrator crash:
-
-```sql
-CREATE TABLE saga_instances (
-  saga_id         UUID PRIMARY KEY,
-  saga_type       TEXT NOT NULL,          -- e.g., 'order-fulfillment'
-  current_state   TEXT NOT NULL,          -- e.g., 'PAYMENT_CHARGED'
-  payload         JSONB NOT NULL,         -- saga data (order_id, amounts, etc.)
-  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
-  updated_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
-  completed_at    TIMESTAMPTZ,
-  version         INT NOT NULL DEFAULT 1  -- optimistic locking
-);
-
-CREATE TABLE saga_step_log (
-  id              SERIAL PRIMARY KEY,
-  saga_id         UUID REFERENCES saga_instances(saga_id),
-  step_name       TEXT NOT NULL,
-  step_type       TEXT NOT NULL,          -- 'forward' or 'compensate'
-  status          TEXT NOT NULL,          -- 'pending', 'completed', 'failed'
-  idempotency_key UUID NOT NULL UNIQUE,
-  request_payload JSONB,
-  response_payload JSONB,
-  error_message   TEXT,
-  started_at      TIMESTAMPTZ,
-  completed_at    TIMESTAMPTZ
-);
-```
-
-### Recovery After Crash
-
-When the orchestrator starts up:
-1. Query `saga_instances` for sagas in non-terminal states (not COMPLETED, not FAILED).
-2. For each, read the `saga_step_log` to determine the last completed step.
-3. Resume from the next step (forward or compensating, depending on state).
-4. Because all steps are idempotent, re-executing a completed step is safe.
-
-## Timeout Handling
-
-Each step has a timeout. When exceeded:
-
-```
-Step timeout configuration:
-  CreateOrder:       5s  (local DB operation)
-  ChargePayment:    30s  (external payment gateway)
-  ReserveInventory: 10s  (internal service)
-  ScheduleShipment: 30s  (external carrier API)
-  SendNotification: 10s  (internal service, fire-and-forget)
-```
-
-On timeout:
-1. Mark the step as `failed` with reason `TIMEOUT`.
-2. Transition saga to `COMPENSATING`.
-3. Run compensating actions for all completed steps in reverse order.
-4. If a compensating action also times out, retry with exponential backoff (up to 5 retries).
-5. If compensation exhausts retries, mark saga as `FAILED` and alert for manual intervention.
-
-## Testing Sagas
-
-### Unit Tests
-
-Test the state machine transitions:
-- Happy path: all steps succeed → COMPLETED
-- Failure at each step: verify correct compensations run
-- Timeout at each step: verify timeout triggers compensation
-- Idempotency: call each step twice, verify no duplicate effects
-
-### Integration Tests
-
-- Deploy all services and run the full saga end-to-end
-- Inject failures (kill a service, add latency) and verify compensation
-- Verify saga recovery after orchestrator restart
-
-### Contract Tests
-
-- Each service's forward action and compensating action must be contract-tested
-- Verify that the orchestrator's expected request/response matches the service's actual API
-
-## Observability
-
-| Metric | What to monitor |
-|--------|----------------|
-| Saga completion rate | Percentage of sagas reaching COMPLETED state |
-| Saga failure rate | Percentage of sagas reaching FAILED state |
-| Average saga duration | Time from STARTED to COMPLETED |
-| Step failure distribution | Which steps fail most often |
-| Compensation success rate | Percentage of compensations that succeed |
-| Stuck sagas | Sagas in non-terminal state for > 5 minutes |
-
-Dashboard: Show saga throughput, failure rate by step, and average duration over time. Alert on failure rate > 1% or stuck sagas.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/nestjs/evals/assertions.md

@@ -1,21 +0,0 @@
-# NestJS Skill Assertions
-
-## Eval 1: Modular API with Guards
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Uses @Module() decorator | contains | `@Module(` | NestJS applications must define feature modules with explicit imports, providers, controllers, and exports arrays for dependency injection scoping. |
-| 2 | Implements CanActivate | contains | `CanActivate` | Authentication and authorization guards must implement the CanActivate interface to integrate with the NestJS guard lifecycle. |
-| 3 | Applies @UseGuards() | contains | `@UseGuards(` | Guards must be attached to controllers or handlers via @UseGuards() to execute before the route handler in the request pipeline. |
-| 4 | Uses ValidationPipe | contains | `ValidationPipe` | The global ValidationPipe activates class-validator decorators on DTOs, providing runtime type safety that TypeScript alone cannot enforce. |
-| 5 | Marks with @Injectable() | contains | `@Injectable()` | All providers (services, guards, interceptors) must be decorated with @Injectable() to participate in the dependency injection container. |
-
-## Eval 2: Microservice Communication
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Uses ClientsModule | contains | `ClientsModule` | Microservice clients must be registered via ClientsModule to configure transport, connection options, and serialization for inter-service communication. |
-| 2 | Uses @MessagePattern() | contains | `@MessagePattern(` | Request-response microservice handlers must use @MessagePattern() so the transport layer knows to wait for and forward the response. |
-| 3 | Uses @EventPattern() | contains | `@EventPattern(` | Event-driven handlers must use @EventPattern() to signal fire-and-forget semantics; mixing with @MessagePattern() causes acknowledgment mismatches. |
-| 4 | Specifies Transport enum | contains | `Transport.` | The transport layer (TCP, Redis, NATS, Kafka) must be explicitly specified to configure connection parameters and serialization strategy. |
-| 5 | Calls connectMicroservice() | contains | `connectMicroservice` | Hybrid applications serving both HTTP and microservice traffic must call connectMicroservice() to bind the transport listener alongside the HTTP server. |

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/nestjs/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "modular-api-with-guards",
-    "description": "Validate that the skill produces a modular NestJS API with proper module structure, guards for authentication, DTOs with validation, and correct dependency injection patterns.",
-    "prompt": "Create a NestJS 11 REST API for a task management system. The API has a TasksModule with a TasksController and TasksService. Tasks belong to a Project and are assigned to a User. Implement a JWT AuthGuard that protects all task endpoints, a RolesGuard for admin-only delete, DTOs with class-validator decorators for create and update, and register everything in the TasksModule with proper imports and exports.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "@Module(",
-        "description": "Must use @Module() decorator to define the feature module with explicit imports, providers, controllers, and exports arrays."
-      },
-      {
-        "type": "contains",
-        "value": "CanActivate",
-        "description": "Must implement the CanActivate interface for the JWT authentication guard to integrate with the NestJS guard lifecycle."
-      },
-      {
-        "type": "contains",
-        "value": "@UseGuards(",
-        "description": "Must apply guards with @UseGuards() decorator on controllers or individual route handlers for authentication and authorization."
-      },
-      {
-        "type": "contains",
-        "value": "ValidationPipe",
-        "description": "Must use ValidationPipe to activate class-validator decorators on incoming DTOs for runtime type safety."
-      },
-      {
-        "type": "contains",
-        "value": "@Injectable()",
-        "description": "Must mark services and guards with @Injectable() to register them in the NestJS dependency injection container."
-      }
-    ]
-  },
-  {
-    "name": "microservice-communication",
-    "description": "Validate that the skill produces correct NestJS microservice patterns with transport configuration, message patterns, hybrid application setup, and proper serialization.",
-    "prompt": "Build a NestJS microservices setup with two services: an API Gateway (HTTP) and an OrderService (TCP transport). The gateway receives HTTP requests and forwards them to OrderService using ClientProxy. OrderService handles a 'create_order' message pattern and emits an 'order_created' event. Show the hybrid application bootstrap, ClientsModule registration, message and event pattern handlers, and DTOs shared between services.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "ClientsModule",
-        "description": "Must use ClientsModule.register() or registerAsync() to configure the microservice client with transport and connection options."
-      },
-      {
-        "type": "contains",
-        "value": "@MessagePattern(",
-        "description": "Must use @MessagePattern() decorator for request-response communication between microservices."
-      },
-      {
-        "type": "contains",
-        "value": "@EventPattern(",
-        "description": "Must use @EventPattern() decorator for event-driven fire-and-forget communication between services."
-      },
-      {
-        "type": "contains",
-        "value": "Transport.",
-        "description": "Must specify the transport layer enum (Transport.TCP, Transport.REDIS, etc.) for microservice connection configuration."
-      },
-      {
-        "type": "contains",
-        "value": "connectMicroservice",
-        "description": "Must call connectMicroservice() on the application instance to create a hybrid HTTP + microservice application."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/nextjs/evals/assertions.md

@@ -1,51 +0,0 @@
-# Next.js 15+ App Router -- Eval Assertions
-
-## Eval 01: Server Component data fetching with caching
-
-This eval validates correct usage of Next.js 15 async Server Components for data fetching with appropriate caching and streaming configuration.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `async` | Verifies the skill uses async Server Component functions for data fetching. In Next.js 15 App Router, pages and layouts can be async functions that fetch data directly without client-side hooks. |
-| 2 | pattern | `revalidate\|next:\s*\{` | Verifies the skill configures caching or revalidation. Next.js 15 no longer caches fetch requests by default, so explicit `revalidate` or `next` options are required to avoid unnecessary refetches. |
-| 3 | contains | `generateMetadata` | Verifies the skill exports `generateMetadata` for dynamic SEO. Each page should generate metadata from its data to provide accurate titles, descriptions, and Open Graph tags. |
-| 4 | contains | `loading.tsx` | Verifies the skill creates or references `loading.tsx` for streaming. This file automatically wraps the page in a Suspense boundary, enabling progressive content delivery. |
-| 5 | excludes | `useEffect` | Verifies the skill does NOT use `useEffect` for data fetching. Server Components fetch data on the server; using `useEffect` would require a Client Component and cause unnecessary waterfalls. |
-
-### What a passing response looks like
-
-A passing response creates:
-- An `app/blog/[slug]/page.tsx` as an async Server Component that fetches post data directly
-- A `revalidate = 60` segment config export or `next: { revalidate: 60 }` fetch option
-- A `generateMetadata` async function that reads the post title/description for SEO
-- A `loading.tsx` file with a skeleton UI for streaming
-- An `error.tsx` Client Component with error boundary UI
-- No `useEffect`, `useState`, or `'use client'` in the page component
-
----
-
-## Eval 02: Server Action form with validation and revalidation
-
-This eval validates correct implementation of a Server Action with Zod validation, structured error returns, and cache revalidation after mutation.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `'use server'` | Verifies the skill marks the action function with the `'use server'` directive. Server Actions must be explicitly marked to create the RPC boundary between client and server. |
-| 2 | contains | `useActionState` | Verifies the skill uses `useActionState` for form state. This React 19 hook manages pending state, previous results, and error display in a single call. |
-| 3 | pattern | `z\.(string\|object)\|zod` | Verifies the skill validates inputs with Zod. Server Actions are publicly accessible endpoints, so all inputs must be validated server-side. |
-| 4 | contains | `revalidatePath` | Verifies the skill revalidates cached data after mutation. Without revalidation, users see stale data after form submission. |
-| 5 | contains | `'use client'` | Verifies the skill marks the form component as a Client Component. Components using hooks like `useActionState` must be Client Components. |
-
-### What a passing response looks like
-
-A passing response provides:
-- An `actions.ts` file with `'use server'` directive containing the form action
-- Zod schema validation for name (min 2, max 100) and email (valid format)
-- Structured error return with field-level messages on validation failure
-- A call to `revalidatePath('/messages')` after successful submission
-- A Client Component form using `useActionState` with pending state indicator
-- Progressive enhancement: the form works as a standard POST without JavaScript

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/nextjs/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "nextjs-eval-01",
-    "name": "Server Component data fetching with caching",
-    "description": "Validate that the skill correctly guides creation of a Next.js 15 page using async Server Components for data fetching with appropriate caching configuration.",
-    "prompt": "Create a Next.js 15 App Router blog post page at app/blog/[slug]/page.tsx that fetches post data from an API using a Server Component. Configure time-based revalidation of 60 seconds, implement loading.tsx for streaming, error.tsx for error handling, and generateMetadata for dynamic SEO metadata based on the post title and description.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "async",
-        "description": "Must use an async Server Component function for server-side data fetching without useEffect"
-      },
-      {
-        "type": "pattern",
-        "value": "revalidate|next:\\s*\\{",
-        "description": "Must configure caching/revalidation using segment config or fetch options since Next.js 15 does not cache by default"
-      },
-      {
-        "type": "contains",
-        "value": "generateMetadata",
-        "description": "Must export generateMetadata for dynamic SEO metadata based on fetched post data"
-      },
-      {
-        "type": "contains",
-        "value": "loading.tsx",
-        "description": "Must reference or create loading.tsx for Suspense-based streaming of the route segment"
-      },
-      {
-        "type": "excludes",
-        "value": "useEffect",
-        "description": "Must NOT use useEffect for data fetching since Server Components fetch data directly on the server"
-      }
-    ]
-  },
-  {
-    "id": "nextjs-eval-02",
-    "name": "Server Action form with validation and revalidation",
-    "description": "Validate that the skill correctly implements a Server Action for form mutation with Zod validation, error handling, and cache revalidation.",
-    "prompt": "Implement a Next.js 15 contact form using Server Actions. Create a Server Action in a separate actions.ts file with 'use server' directive that validates name (required, 2-100 chars) and email (required, valid format) with Zod. Return structured errors on failure. Build the form in a Client Component using useActionState for pending/error states. After successful submission, revalidate the /messages path.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "'use server'",
-        "description": "Must include the 'use server' directive to mark the function as a Server Action"
-      },
-      {
-        "type": "contains",
-        "value": "useActionState",
-        "description": "Must use useActionState hook for managing form submission state and displaying results"
-      },
-      {
-        "type": "pattern",
-        "value": "z\\.(string|object)|zod",
-        "description": "Must use Zod for server-side input validation since Server Actions are public HTTP endpoints"
-      },
-      {
-        "type": "contains",
-        "value": "revalidatePath",
-        "description": "Must call revalidatePath or revalidateTag after successful mutation to invalidate stale cached data"
-      },
-      {
-        "type": "contains",
-        "value": "'use client'",
-        "description": "Must mark the form component with 'use client' since it uses hooks for interactive state management"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/observability/evals/assertions.md

@@ -1,50 +0,0 @@
-# Observability Eval Assertions
-
-## Eval 1: OpenTelemetry Instrumentation
-
-This eval tests the core instrumentation skill: configuring OpenTelemetry auto-instrumentation, adding custom spans, setting up trace propagation, and designing a collector pipeline with tail-based sampling.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `FastAPIInstrumentor` — Auto-instrumentation    | Auto-instrumentation provides baseline HTTP span visibility without manual code changes. Missing it means every endpoint requires hand-written span creation. |
-| 2 | contains | `set_attribute` — Custom span attributes        | Business-relevant attributes (payment amount, status) on custom spans enable filtering and grouping traces by domain-specific dimensions during incident investigation. |
-| 3 | contains | `tail_sampling` — Tail-based sampling processor | Tail-based sampling in the collector retains 100% of error traces while sampling successful traces. Head-based sampling randomly discards the error traces you need most. |
-| 4 | contains | `service.name` — Resource attribute             | `service.name` is the primary resource attribute for filtering telemetry in multi-service environments. Without it, traces from different services are indistinguishable. |
-| 5 | contains | `OTLPSpanExporter` — OTLP export protocol       | The OTLP exporter sends traces to the OpenTelemetry Collector using the standard protocol, maintaining vendor neutrality and enabling backend switching without code changes. |
-
-### What a passing response looks like
-
-- Python SDK setup with `TracerProvider`, `OTLPSpanExporter`, and `BatchSpanProcessor`.
-- Resource attributes: `service.name=payment-service`, `service.version=1.2.0`, `deployment.environment=production`.
-- `FastAPIInstrumentor().instrument()` for auto-instrumentation of all HTTP endpoints.
-- A custom `process_payment` function wrapped with `tracer.start_as_current_span("process_payment")` and `span.set_attribute("payment.amount", amount)`.
-- W3C Trace Context propagation configured via `set_global_textmap(TraceContextTextMapPropagator())`.
-- OpenTelemetry Collector config with OTLP receiver, `tail_sampling` processor (sampling 100% of error traces, 10% of success), and exporters to Jaeger and Prometheus.
-
----
-
-## Eval 2: SLO-Based Alerting
-
-This eval tests the SLO design skill: defining SLIs in PromQL, calculating error budgets, configuring multi-window burn-rate alerts, and creating runbooks.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `burn_rate` — Burn-rate alert calculation        | Multi-window burn-rate alerts detect both fast burns (outage) and slow burns (gradual degradation) with appropriate urgency, unlike static threshold alerts that have a single sensitivity. |
-| 2 | contains | `error_budget` — Error budget calculation        | Explicit error budget math (e.g., 0.1% = 43.2 minutes/month for 99.9% SLO) makes the cost of unreliability concrete and drives prioritization decisions between features and reliability work. |
-| 3 | contains | `histogram_quantile` — PromQL percentile query   | Latency SLIs must use `histogram_quantile` to compute percentiles from histogram buckets. Using `rate()` on a counter gives average latency, which hides the tail that users actually experience. |
-| 4 | contains | `runbook` — Runbook reference in alerts          | Every alert annotation must include a runbook URL. Without runbooks, on-call engineers waste incident time reverse-engineering what the alert means and what to investigate first. |
-| 5 | contains | `30d` — Rolling window specification             | A 30-day rolling window provides a stable baseline for error budget calculations. Shorter windows create noisy budgets; longer windows delay detection of sustained degradation. |
-
-### What a passing response looks like
-
-- Availability SLI: `sum(rate(http_requests_total{service="checkout",code!~"5.."}[30d])) / sum(rate(http_requests_total{service="checkout"}[30d]))`.
-- Latency SLI: `histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="checkout"}[30d])) by (le))`.
-- Error budget: 99.9% availability = 0.1% budget = 43.2 minutes of total downtime per 30 days.
-- Fast-burn alert: burn rate > 14.4x over 5m AND > 14.4x over 1h (pages immediately).
-- Slow-burn alert: burn rate > 6x over 30m AND > 6x over 6h (creates ticket).
-- Alert annotations with `runbook_url`, `summary`, and `description` fields.
-- Runbook template with sections: Symptoms, Impact Assessment, Investigation Steps, Remediation, Escalation Path.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/observability/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "opentelemetry-instrumentation",
-    "description": "Validate that the skill produces correct OpenTelemetry instrumentation with auto-instrumentation, manual spans, trace propagation, and collector configuration for a Python FastAPI service.",
-    "input": "Instrument a Python FastAPI microservice with OpenTelemetry. Configure auto-instrumentation for HTTP and database spans. Add a custom span for a business-critical payment processing function that records the payment amount and status as span attributes. Set up W3C Trace Context propagation. Configure an OpenTelemetry Collector pipeline that receives OTLP traces, applies tail-based sampling (keep all error traces and 10% of successful traces), and exports to both Jaeger and Prometheus. Include resource attributes for service.name, service.version, and deployment.environment.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "FastAPIInstrumentor",
-        "description": "The instrumentation must use FastAPIInstrumentor for automatic HTTP span creation on every request, providing baseline visibility without manual code changes."
-      },
-      {
-        "type": "contains",
-        "value": "set_attribute",
-        "description": "Custom spans must record business-relevant attributes (payment amount, status) using set_attribute for rich trace context during incident investigation."
-      },
-      {
-        "type": "contains",
-        "value": "tail_sampling",
-        "description": "The collector configuration must use a tail-based sampling processor to retain error traces while sampling routine successful traces."
-      },
-      {
-        "type": "contains",
-        "value": "service.name",
-        "description": "Resource attributes must include service.name to enable filtering telemetry by service in multi-service environments."
-      },
-      {
-        "type": "contains",
-        "value": "OTLPSpanExporter",
-        "description": "The SDK must export spans using the OTLP exporter protocol to the OpenTelemetry Collector, maintaining vendor neutrality."
-      }
-    ]
-  },
-  {
-    "name": "slo-based-alerting",
-    "description": "Validate that the skill produces correct SLO definitions with SLI specifications, error budgets, multi-window burn-rate alerts, and linked runbooks.",
-    "input": "Define SLOs for an e-commerce checkout API. Create two SLOs: (1) Availability SLO: 99.9% of checkout requests return a non-5xx response over a 30-day rolling window; (2) Latency SLO: 99% of checkout requests complete within 500ms over a 30-day rolling window. For each SLO, write the SLI query in PromQL, calculate the error budget, configure multi-window burn-rate alerts (5m/1h fast burn, 30m/6h slow burn), define severity levels, and create a runbook template with investigation steps.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "burn_rate",
-        "description": "Alert rules must use burn-rate calculations rather than static thresholds to adapt alert sensitivity to the speed of error budget consumption."
-      },
-      {
-        "type": "contains",
-        "value": "error_budget",
-        "description": "The SLO definition must include explicit error budget calculations (1 - SLO target) to quantify the allowable failure margin."
-      },
-      {
-        "type": "contains",
-        "value": "histogram_quantile",
-        "description": "The latency SLI must use histogram_quantile in PromQL to calculate percentile latency from histogram buckets rather than averages."
-      },
-      {
-        "type": "contains",
-        "value": "runbook",
-        "description": "Every alert must link to a runbook that describes symptoms, investigation steps, and remediation actions for on-call engineers."
-      },
-      {
-        "type": "contains",
-        "value": "30d",
-        "description": "SLO measurement windows must use a 30-day rolling window as specified, providing a meaningful time horizon for error budget calculations."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/owasp-security-review/evals/assertions.md

@@ -1,25 +0,0 @@
-# Eval Assertions — OWASP Security Review
-
-## Eval 1: Injection Vulnerability Detection
-
-**ID:** `owasp-injection-detection`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_contains | "SQL injection" | The code concatenates `req.query.name` directly into a SQL string. The skill must identify this as SQL injection. |
-| 2 | content_contains | "XSS" | The code reflects `req.query.name` and `err.message` directly into HTML. The skill must identify reflected XSS. |
-| 3 | content_matches_regex | `A0[3]\|Injection\|injection` | The finding must reference OWASP A03:2025 (Injection) to demonstrate proper categorization. |
-| 4 | content_contains | "parameterized" | Remediation must recommend parameterized queries (prepared statements) as the primary fix for SQL injection. |
-| 5 | content_matches_regex | `encod\|escap\|sanitiz\|DOMPurify` | Remediation must recommend output encoding, escaping, or sanitization for XSS prevention. |
-
-## Eval 2: Threat Model Generation
-
-**ID:** `owasp-threat-model-generation`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `STRIDE\|spoofing\|tampering\|repudiation\|information disclosure\|denial of service\|elevation of privilege` | The threat model must use a recognized framework (STRIDE) or enumerate its threat categories. |
-| 2 | content_matches_regex | `trust boundar\|boundary\|ingress\|external\|internal` | Must identify trust boundaries between the public internet, Kubernetes ingress, and internal services. |
-| 3 | content_matches_regex | `JWT\|token\|session` | Must analyze JWT security concerns including signing algorithm, token expiry, and storage. |
-| 4 | content_matches_regex | `password reset\|reset.password\|account takeover` | Must identify the password reset flow as a high-value attack vector for account takeover. |
-| 5 | content_matches_regex | `Critical\|High\|Medium\|Low\|severity\|risk.*(rating\|level)` | Must assign severity or risk ratings to each identified threat to enable prioritization. |

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/owasp-security-review/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "owasp-injection-detection",
-    "title": "Detect injection vulnerabilities in code sample",
-    "description": "Given a code sample with SQL injection and XSS vulnerabilities, the skill should identify both, classify them under the correct OWASP categories, and provide remediation.",
-    "prompt": "Review the following Express.js route handler for OWASP Top 10 vulnerabilities:\n\n```javascript\napp.get('/users', (req, res) => {\n  const query = `SELECT * FROM users WHERE name = '${req.query.name}'`;\n  db.query(query, (err, results) => {\n    if (err) {\n      res.status(500).send(`<h1>Error: ${err.message}</h1>`);\n    }\n    res.send(`<h1>Results for ${req.query.name}</h1><pre>${JSON.stringify(results)}</pre>`);\n  });\n});\n```",
-    "assertions": [
-      {
-        "type": "content_contains",
-        "value": "SQL injection",
-        "description": "Must identify SQL injection from string concatenation in query"
-      },
-      {
-        "type": "content_contains",
-        "value": "XSS",
-        "description": "Must identify reflected XSS from unsanitized user input in HTML response"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "A0[3]|Injection|injection",
-        "description": "Must reference the OWASP Injection category (A03:2025)"
-      },
-      {
-        "type": "content_contains",
-        "value": "parameterized",
-        "description": "Must recommend parameterized queries as SQL injection remediation"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "encod|escap|sanitiz|DOMPurify",
-        "description": "Must recommend output encoding or sanitization for XSS remediation"
-      }
-    ]
-  },
-  {
-    "id": "owasp-threat-model-generation",
-    "title": "Generate a threat model for an authentication service",
-    "description": "Given a description of an authentication microservice, the skill should produce a threat model covering STRIDE categories, trust boundaries, and risk ratings.",
-    "prompt": "Build a threat model for the following service:\n\nAn authentication microservice that accepts username/password via REST API, validates against a PostgreSQL database, issues JWT tokens, supports OAuth2 with Google and GitHub, exposes a /reset-password endpoint that sends email via SendGrid, and runs in a Kubernetes pod with a public-facing ingress.",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "STRIDE|spoofing|tampering|repudiation|information disclosure|denial of service|elevation of privilege",
-        "description": "Must use STRIDE or enumerate STRIDE threat categories"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "trust boundar|boundary|ingress|external|internal",
-        "description": "Must identify trust boundaries between external clients, ingress, and internal services"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "JWT|token|session",
-        "description": "Must analyze JWT token security (signing, expiry, storage)"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "password reset|reset.password|account takeover",
-        "description": "Must identify password reset flow as a threat vector"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "Critical|High|Medium|Low|severity|risk.*(rating|level)",
-        "description": "Must assign risk or severity ratings to identified threats"
-      }
-    ]
-  }
-]