@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/javascript-best-practices/references/testing.md

@@ -1,253 +0,0 @@
-# Testing Reference
-
-## Test Runner Selection
-
-| Runner | Best For | Key Feature |
-| --- | --- | --- |
-| **Vitest** | Most projects, browser + Node | Vite-native, ESM-first, built-in coverage, UI mode |
-| **node:test** | Node-only, zero dependencies | Ships with Node, no install, fast startup |
-| **Deno.test** | Deno projects | Built into runtime, permissions-aware |
-| **Bun test** | Bun projects | Fastest startup, Jest-compatible API |
-
-## Vitest Setup and Configuration
-
-```javascript
-// vitest.config.js
-import { defineConfig } from 'vitest/config';
-
-export default defineConfig({
-  test: {
-    globals: false,           // Explicit imports preferred
-    environment: 'node',      // or 'jsdom', 'happy-dom'
-    coverage: {
-      provider: 'v8',
-      reporter: ['text', 'lcov'],
-      exclude: ['**/*.test.js', '**/test/**'],
-    },
-    testTimeout: 10_000,
-    hookTimeout: 15_000,
-  },
-});
-```
-
-### Writing Tests with Vitest
-
-```javascript
-import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
-import { fetchUserProfile } from './user-service.js';
-
-describe('fetchUserProfile', () => {
-  beforeEach(() => {
-    vi.useFakeTimers();
-  });
-
-  afterEach(() => {
-    vi.useRealTimers();
-    vi.restoreAllMocks();
-  });
-
-  it('returns user data on success', async () => {
-    const mockResponse = { id: '1', name: 'Alice' };
-    vi.spyOn(globalThis, 'fetch').mockResolvedValueOnce(
-      new Response(JSON.stringify(mockResponse), { status: 200 })
-    );
-
-    const user = await fetchUserProfile('1');
-
-    expect(user).toEqual({ id: '1', name: 'Alice' });
-    expect(fetch).toHaveBeenCalledWith(
-      expect.stringContaining('/users/1'),
-      expect.any(Object)
-    );
-  });
-
-  it('throws on HTTP error', async () => {
-    vi.spyOn(globalThis, 'fetch').mockResolvedValueOnce(
-      new Response('Not Found', { status: 404 })
-    );
-
-    await expect(fetchUserProfile('999')).rejects.toThrow('HTTP 404');
-  });
-
-  it('respects abort signal', async () => {
-    const controller = new AbortController();
-    controller.abort();
-
-    await expect(
-      fetchUserProfile('1', { signal: controller.signal })
-    ).rejects.toThrow('aborted');
-  });
-
-  it('retries on transient failure', async () => {
-    const fetchSpy = vi.spyOn(globalThis, 'fetch')
-      .mockResolvedValueOnce(new Response('', { status: 503 }))
-      .mockResolvedValueOnce(new Response('', { status: 503 }))
-      .mockResolvedValueOnce(
-        new Response(JSON.stringify({ id: '1' }), { status: 200 })
-      );
-
-    // Advance timers through retry delays
-    const promise = fetchUserProfile('1');
-    await vi.advanceTimersByTimeAsync(2_000);
-    await vi.advanceTimersByTimeAsync(4_000);
-
-    const result = await promise;
-    expect(result.id).toBe('1');
-    expect(fetchSpy).toHaveBeenCalledTimes(3);
-  });
-});
-```
-
-## Node.js Built-in Test Runner
-
-```javascript
-import { describe, it, mock, before, after } from 'node:test';
-import assert from 'node:assert/strict';
-import { buildUrl } from './url-utils.js';
-
-describe('buildUrl', () => {
-  it('combines base, path, and params', () => {
-    const result = buildUrl('https://api.example.com', '/users', { page: '2' });
-    assert.equal(result, 'https://api.example.com/users?page=2');
-  });
-
-  it('handles empty params', () => {
-    const result = buildUrl('https://api.example.com', '/health');
-    assert.equal(result, 'https://api.example.com/health');
-  });
-
-  it('encodes special characters', () => {
-    const result = buildUrl('https://api.example.com', '/search', {
-      q: 'hello world',
-    });
-    assert.match(result, /q=hello\+world|q=hello%20world/);
-  });
-});
-
-// Run: node --test src/**/*.test.js
-// Coverage: node --test --experimental-test-coverage src/**/*.test.js
-```
-
-## Mocking Strategies
-
-### Mock fetch (Vitest)
-
-```javascript
-// Global fetch mock with type-safe responses
-const mockFetch = (responses) => {
-  let callIndex = 0;
-  return vi.spyOn(globalThis, 'fetch').mockImplementation(async () => {
-    const resp = responses[callIndex++];
-    if (resp instanceof Error) throw resp;
-    return new Response(
-      JSON.stringify(resp.body),
-      { status: resp.status ?? 200, headers: resp.headers }
-    );
-  });
-};
-
-// Usage
-mockFetch([
-  { body: { users: [] }, status: 200 },
-  { body: { error: 'rate limited' }, status: 429 },
-]);
-```
-
-### Mock Timers
-
-```javascript
-// Vitest
-vi.useFakeTimers();
-const promise = retryWithBackoff(fn);
-await vi.advanceTimersByTimeAsync(5_000);
-const result = await promise;
-vi.useRealTimers();
-
-// Node.js test runner
-import { mock } from 'node:test';
-mock.timers.enable({ apis: ['setTimeout', 'setInterval'] });
-mock.timers.tick(5_000);
-mock.timers.reset();
-```
-
-### Mock File System
-
-```javascript
-// Use a virtual filesystem instead of mocking fs
-import { vol, fs } from 'memfs';
-
-beforeEach(() => {
-  vol.fromJSON({
-    '/app/config.json': JSON.stringify({ port: 3000 }),
-    '/app/data/users.csv': 'id,name\n1,Alice',
-  });
-});
-
-// Inject the mock fs into your module
-const config = await loadConfig({ fs });
-```
-
-## Testing Async Generators
-
-```javascript
-import { describe, it, expect } from 'vitest';
-
-describe('fetchAllPages', () => {
-  it('yields items from multiple pages', async () => {
-    const items = [];
-    for await (const item of fetchAllPages(mockUrl)) {
-      items.push(item);
-    }
-    expect(items).toHaveLength(30);
-    expect(items[0]).toHaveProperty('id');
-  });
-
-  it('stops on cancellation', async () => {
-    const controller = new AbortController();
-    const items = [];
-
-    for await (const item of fetchAllPages(mockUrl, { signal: controller.signal })) {
-      items.push(item);
-      if (items.length >= 5) controller.abort();
-    }
-    // Should not have fetched all pages
-    expect(items.length).toBeLessThanOrEqual(10); // One page max
-  });
-});
-```
-
-## Snapshot Testing
-
-```javascript
-import { expect, it } from 'vitest';
-
-it('renders the config correctly', () => {
-  const config = generateConfig({ env: 'production', region: 'us-east-1' });
-  expect(config).toMatchSnapshot();
-  // First run: creates .snap file
-  // Subsequent runs: compares against snapshot
-  // Update: vitest --update
-});
-
-// Inline snapshots (stored in the test file)
-it('formats error message', () => {
-  const msg = formatError(new Error('timeout'), '/api/users');
-  expect(msg).toMatchInlineSnapshot(`"Request to /api/users failed: timeout"`);
-});
-```
-
-## Cross-Runtime Test Execution
-
-```json
-{
-  "scripts": {
-    "test": "vitest run",
-    "test:node": "node --test src/**/*.test.js",
-    "test:deno": "deno test src/",
-    "test:bun": "bun test",
-    "test:all": "npm run test && npm run test:deno"
-  }
-}
-```
-
-Keep test utilities in a shared `test-utils.js` file and avoid runtime-specific test APIs in the utilities themselves.

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

@@ -1,43 +0,0 @@
-# Kaizen Iteration -- Eval Assertions
-
-## Eval 001: Sprint Retrospective with Root Cause Analysis
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `root cause` | The response must perform root cause analysis, not just list problems. Surface-level observation without digging into causes produces ineffective improvements. |
-| 2 | contains | `hypothesis` | The response must frame improvements as testable hypotheses because vague commitments like "improve communication" are unmeasurable and rarely lead to action. |
-| 3 | contains | `metric` | The response must identify specific metrics to track improvement because without measurement, the team cannot determine whether the change worked. |
-| 4 | contains | `owner` | The response must recommend assigning owners because shared ownership of improvements results in no ownership. |
-| 5 | contains | `categor` | The response must categorize observations because patterns emerge from categories, not individual data points. |
-
-### What a Passing Response Looks Like
-
-A passing response:
-- Categorizes all 5 observations into groups (process, tooling, quality, communication).
-- Selects the top 2 issues based on impact (likely: production bugs and code review delays).
-- Performs 5 Whys analysis on each, reaching actionable root causes.
-- Proposes 1-2 improvement experiments with hypothesis, owner, metric, and timebox.
-- Does not propose more than 2 experiments (WIP limit principle).
-- Includes a format for tracking the experiment outcome at the next retrospective.
-
----
-
-## Eval 002: Metrics-Driven Improvement Cycle
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `baseline` | The response must establish baseline values for each metric because improvements cannot be measured without a starting point. |
-| 2 | contains | `recovery` | The response must identify MTTR as a key improvement area because at 6x the industry median, it represents the largest relative gap. |
-| 3 | contains | `experiment` | The response must propose a structured experiment, not a general recommendation, because kaizen requires testable changes. |
-| 4 | contains | `timebox` | The response must set a fixed evaluation period because open-ended experiments prevent evaluation and decision-making. |
-| 5 | contains | `failure rate` | The response must address the change failure rate because it is above the industry median and likely contributes to the MTTR problem. |
-
-### What a Passing Response Looks Like
-
-A passing response:
-- Presents all 4 DORA metrics with baseline values and industry comparison.
-- Identifies MTTR (6 hours vs. 1 hour median) as the most impactful improvement opportunity.
-- Notes the connection between change failure rate (22%) and MTTR.
-- Designs an experiment with: specific change (e.g., implement runbook-based incident response), target metric (MTTR < 2 hours), timebox (4 weeks), owner, and success criteria.
-- Includes a measurement plan for how to track the metric during the experiment.
-- Recommends a follow-up analysis at the timebox boundary.

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

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "kaizen-iteration-eval-001",
-    "name": "Sprint retrospective with root cause analysis",
-    "description": "Evaluate the skill's ability to facilitate a structured retrospective, extract patterns from observations, and perform root cause analysis using the 5 Whys technique.",
-    "prompt": "Run a retrospective for our sprint. Here are the observations from the team: (1) We missed the deadline for the search feature by 3 days. (2) Two critical bugs were found in production after deployment. (3) Code reviews took an average of 4 days to complete. (4) The design handoff was unclear, causing 2 days of rework. (5) Deployment pipeline failed 6 times during the sprint. Categorize these, perform root cause analysis on the top 2 issues, and propose improvement experiments.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "root cause",
-        "description": "Should perform root cause analysis using 5 Whys or equivalent technique to dig beneath symptoms"
-      },
-      {
-        "type": "contains",
-        "value": "hypothesis",
-        "description": "Should formulate improvements as testable hypotheses with measurable outcomes"
-      },
-      {
-        "type": "contains",
-        "value": "metric",
-        "description": "Should identify specific metrics to track whether improvements are working"
-      },
-      {
-        "type": "contains",
-        "value": "owner",
-        "description": "Should recommend assigning a single owner to each improvement experiment"
-      },
-      {
-        "type": "contains",
-        "value": "categor",
-        "description": "Should categorize observations into types like process, tooling, communication, or technical debt"
-      }
-    ]
-  },
-  {
-    "id": "kaizen-iteration-eval-002",
-    "name": "Metrics-driven improvement cycle evaluation",
-    "description": "Evaluate the skill's ability to analyze team metrics, establish baselines, identify improvement opportunities, and design experiments with timeboxes.",
-    "prompt": "Here are our team's DORA metrics for the last quarter: Deployment frequency: 2/week (industry median: 1/week). Lead time for changes: 8 days (industry median: 1 week). Change failure rate: 22% (industry median: 15%). Mean time to recovery: 6 hours (industry median: 1 hour). Analyze these metrics, identify the most impactful improvement opportunity, and design a kaizen experiment to address it. Include baseline, target, timebox, and success criteria.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "baseline",
-        "description": "Should establish a clear metrics baseline from the provided data before proposing changes"
-      },
-      {
-        "type": "contains",
-        "value": "recovery",
-        "description": "Should identify MTTR as a significant improvement opportunity since it is 6x the industry median"
-      },
-      {
-        "type": "contains",
-        "value": "experiment",
-        "description": "Should design a structured improvement experiment with clear parameters"
-      },
-      {
-        "type": "contains",
-        "value": "timebox",
-        "description": "Should set a fixed evaluation period for the improvement experiment"
-      },
-      {
-        "type": "contains",
-        "value": "failure rate",
-        "description": "Should address the change failure rate as it is above industry median"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/kotlin-best-practices/evals/assertions.md

@@ -1,33 +0,0 @@
-# Kotlin Best Practices - Eval Assertions
-
-## Eval 1: Coroutine-Based Service Implementation
-
-This eval tests the skill's ability to design a concurrent service layer with structured concurrency, timeouts, and graceful degradation.
-
-### Assertions
-
-1. **Uses supervisorScope for independent parallel calls** -- The 3 enrichment API calls are independent, so one failure should not cancel the others. `supervisorScope` or launching `async` within a `SupervisorJob` allows sibling coroutines to complete even when one fails. Using plain `coroutineScope` would cancel all siblings on the first failure, which contradicts the graceful degradation requirement.
-
-2. **Applies timeouts at both overall and individual levels** -- The 2-second deadline for the entire operation should use `withTimeout(2000)` or `withTimeoutOrNull(2000)` wrapping all parallel calls. Individual API calls should also have timeouts to prevent one slow call from consuming the entire budget. `withTimeoutOrNull` is preferred for individual calls to enable partial results.
-
-3. **Models partial success with sealed types** -- When some enrichment calls fail or time out, the service should return partial data rather than failing entirely. A sealed class (e.g., `sealed interface EnrichmentResult`) or nullable fields with documentation captures which data is available. Raw exceptions should not leak to the caller.
-
-4. **Uses Dispatchers.IO for blocking calls** -- Network and database calls must run on `Dispatchers.IO` via `withContext(Dispatchers.IO)` to avoid blocking the caller's dispatcher. Blocking `Dispatchers.Default` (the computation pool) with I/O calls would starve CPU-bound coroutines.
-
-5. **Does not catch CancellationException** -- Structured concurrency relies on `CancellationException` propagating correctly. Code that catches `Exception` broadly (e.g., in `runCatching`) accidentally catches `CancellationException`, breaking cancellation. The response must either avoid catching it or explicitly rethrow it.
-
-## Eval 2: Multiplatform Module Design
-
-This eval tests the skill's ability to architect a Kotlin Multiplatform module with proper source set separation and cross-platform patterns.
-
-### Assertions
-
-1. **Correct KMP source set structure** -- The Gradle configuration must define `commonMain`, `androidMain`, and `iosMain` source sets within the shared module. This is the fundamental KMP architecture. The build file should use `kotlin { sourceSets { } }` DSL with proper dependency declarations.
-
-2. **Sealed types in commonMain** -- Domain modeling with sealed classes/interfaces belongs in `commonMain` because it is pure Kotlin with no platform dependencies. Each order state variant should be a `data class` carrying state-specific data. The compiler enforces exhaustive `when` matching across all platforms.
-
-3. **Repository interface returning Flow** -- The repository abstraction in `commonMain` should return `Flow<T>` for reactive data access. `Flow` is part of `kotlinx.coroutines` which is available in `commonMain`. The actual database implementation lives in platform source sets, but the interface is shared.
-
-4. **kotlinx.serialization for API models** -- Cross-platform serialization must use `kotlinx.serialization` (not Gson, Moshi, or Jackson, which are JVM-only). Models should be annotated with `@Serializable` in `commonMain`. The serialization plugin must be applied in the Gradle build.
-
-5. **expect/actual for platform logging** -- Platform-specific functionality like logging requires the `expect`/`actual` mechanism. An `expect fun log(message: String)` in `commonMain` has `actual fun log(message: String)` implementations in `androidMain` (using Android `Log`) and `iosMain` (using `NSLog` or `println`). This demonstrates the standard pattern for platform abstraction in KMP.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/kotlin-best-practices/evals/evals.json

@@ -1,32 +0,0 @@
-{
-  "skill_name": "kotlin-best-practices",
-  "platform": "claude-code",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I'm building a Kotlin backend service that needs to fetch user profiles from a database, enrich them with data from 3 external APIs (preferences, activity, recommendations), and return the combined result. Each external API call takes 200-500ms. Design a coroutine-based service layer with proper structured concurrency, timeout handling (2 second deadline for the whole operation), and graceful degradation (return partial data if some enrichment calls fail).",
-      "expected_output": "A coroutine-based service using supervisorScope for parallel enrichment calls with individual timeouts, a composed deadline via withTimeout, and result types that model partial success.",
-      "files": [],
-      "assertions": [
-        "Uses supervisorScope or async with SupervisorJob for parallel enrichment calls so that one failure does not cancel siblings",
-        "Applies withTimeout or withTimeoutOrNull for the overall 2-second deadline and individual call timeouts",
-        "Uses a sealed class or Result type to model partial success where some enrichment data may be missing",
-        "Dispatches I/O calls on Dispatchers.IO using withContext and does not block the calling dispatcher",
-        "Includes structured error handling that does not catch CancellationException (or explicitly rethrows it)"
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "I'm starting a Kotlin Multiplatform project that shares a domain layer between an Android app and an iOS app. The shared module needs: a data model with sealed types for order states, a repository interface with Flow-based reactive queries, kotlinx.serialization for API responses, and expect/actual for platform-specific logging. Show me the module structure and key implementations.",
-      "expected_output": "A KMP module structure with commonMain containing sealed domain types, repository interface returning Flow, serialization models, and expect/actual declarations, plus androidMain and iosMain actual implementations.",
-      "files": [],
-      "assertions": [
-        "Defines the shared module with commonMain, androidMain, and iosMain source sets in the Gradle configuration",
-        "Uses sealed class or sealed interface in commonMain for order state modeling with data class variants",
-        "Defines a repository interface in commonMain returning Flow<T> for reactive data access",
-        "Uses @Serializable annotations from kotlinx.serialization for API response models in commonMain",
-        "Implements expect/actual pattern for platform-specific logging (expect in commonMain, actual in androidMain and iosMain)"
-      ]
-    }
-  ]
-}

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

@@ -1,51 +0,0 @@
-# Kubernetes Deploy Eval Assertions
-
-## Eval 1: Rolling Deployment with Health Checks
-
-This eval tests the core Kubernetes deployment skill: configuring a Deployment with rolling updates, probes, resource management, security hardening, and disruption protection.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `startupProbe:` — Startup probe configuration   | Startup probes handle slow container initialization (database migrations, cache warming) without the liveness probe killing the pod prematurely during first boot. |
-| 2 | contains | `readinessProbe:` — Readiness probe configuration| Readiness probes tell Kubernetes when a pod can accept traffic. During rolling updates, unready pods are excluded from Service endpoints, preventing requests to pods still initializing. |
-| 3 | contains | `maxSurge:` — Rolling update surge control       | `maxSurge: 1` with `maxUnavailable: 0` ensures zero-downtime deploys by requiring a new pod to be ready before terminating an old one. Uncontrolled surge can exhaust node resources. |
-| 4 | contains | `runAsNonRoot:` — Non-root security context      | Running as non-root prevents privilege escalation attacks. A compromised process running as root inside a container can escape to the host via kernel vulnerabilities. |
-| 5 | contains | `PodDisruptionBudget` — Disruption protection    | PDBs prevent node drains and cluster upgrades from evicting all replicas simultaneously. Without a PDB, a node maintenance event can take down the entire service. |
-
-### What a passing response looks like
-
-- A Deployment in the `commerce` namespace with `metadata.name: order-api` and `spec.replicas: 3`.
-- Rolling update strategy: `maxSurge: 1`, `maxUnavailable: 0`.
-- All three probes configured: `startupProbe` (with `failureThreshold: 30`), `readinessProbe`, and `livenessProbe` hitting `/healthz`.
-- Resource requests: `memory: 256Mi`, `cpu: 250m`. Limits: `memory: 512Mi`, `cpu: 500m`.
-- Pod anti-affinity using `requiredDuringSchedulingIgnoredDuringExecution` or `preferredDuringSchedulingIgnoredDuringExecution` with `topologyKey: kubernetes.io/hostname`.
-- Security context: `runAsNonRoot: true`, `readOnlyRootFilesystem: true`, with an `emptyDir` volume for `/tmp` if needed.
-- A separate PodDisruptionBudget resource with `maxUnavailable: 1` selecting pods via matching labels.
-
----
-
-## Eval 2: Helm Chart Design
-
-This eval tests the Helm chart authoring skill: creating parameterized templates with environment-specific value overrides, autoscaling, and production configuration.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `{{ .Values.` — Helm value templating           | All configurable fields (replicas, image tag, resources, domain) must be parameterized via `.Values` references so that a single chart serves all environments without template edits. |
-| 2 | contains | `HorizontalPodAutoscaler` — HPA resource        | An HPA with CPU-based autoscaling ensures the service scales elastically under load, preventing both under-provisioning (dropped requests) and over-provisioning (wasted cost). |
-| 3 | contains | `values-production` — Production values override | A dedicated production values file separates environment-specific configuration from defaults, making the differences between environments explicit and auditable. |
-| 4 | contains | `tls:` — TLS configuration in Ingress           | Production Ingress must terminate TLS. Serving traffic over plain HTTP exposes user data to interception and violates compliance requirements for most applications. |
-| 5 | contains | `ConfigMap` — Externalized configuration         | Application settings in a ConfigMap can be updated independently of the Deployment image, enabling configuration changes without a full redeployment cycle. |
-
-### What a passing response looks like
-
-- A chart directory with `Chart.yaml`, `values.yaml`, `values-production.yaml`, and `templates/` containing `deployment.yaml`, `service.yaml`, `ingress.yaml`, `configmap.yaml`, and `hpa.yaml`.
-- Templates using `{{ .Values.image.repository }}:{{ .Values.image.tag }}`, `{{ .Values.replicaCount }}`, `{{ .Values.resources }}`.
-- Default `values.yaml` with `replicaCount: 2`, reasonable dev resource limits, and a placeholder domain.
-- `values-production.yaml` overriding with `replicaCount: 4`, higher resource limits, production domain, and TLS secret name.
-- HPA targeting the Deployment with `minReplicas: 2`, `maxReplicas: 10`, CPU target 70%.
-- Ingress with `tls:` section referencing a TLS secret and `hosts:` from values.
-- ConfigMap with application settings mounted as a volume or injected as environment variables.

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

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "rolling-deployment-with-health-checks",
-    "description": "Validate that the skill produces a Kubernetes Deployment with proper rolling update strategy, all three probe types, resource management, and production hardening.",
-    "input": "Create a Kubernetes Deployment manifest for a Node.js API service called 'order-api' in the 'commerce' namespace. Configure 3 replicas with a rolling update strategy (maxSurge: 1, maxUnavailable: 0). Add startup, readiness, and liveness probes hitting /healthz. Set resource requests (256Mi memory, 250m CPU) and limits (512Mi memory, 500m CPU). Add pod anti-affinity to spread replicas across nodes. Run as non-root user with a read-only root filesystem. Include a PodDisruptionBudget allowing at most 1 unavailable pod.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "startupProbe:",
-        "description": "The Deployment must include a startup probe to handle slow container initialization without triggering premature liveness probe failures."
-      },
-      {
-        "type": "contains",
-        "value": "readinessProbe:",
-        "description": "The Deployment must include a readiness probe so Kubernetes removes unhealthy pods from Service endpoints during rolling updates."
-      },
-      {
-        "type": "contains",
-        "value": "maxSurge:",
-        "description": "The rolling update strategy must specify maxSurge to control how many extra pods are created during deployment, managing cluster resource consumption."
-      },
-      {
-        "type": "contains",
-        "value": "runAsNonRoot:",
-        "description": "The pod security context must enforce non-root execution to prevent privilege escalation attacks from within the container."
-      },
-      {
-        "type": "contains",
-        "value": "PodDisruptionBudget",
-        "description": "A PodDisruptionBudget must be defined to prevent voluntary disruptions (node drains) from evicting too many replicas simultaneously."
-      }
-    ]
-  },
-  {
-    "name": "helm-chart-design",
-    "description": "Validate that the skill produces a well-structured Helm chart with parameterized values, environment-specific overrides, and deployment best practices.",
-    "input": "Create a Helm chart for a microservice called 'notification-service'. The chart should include: a Deployment template with configurable replicas, resources, and image tag; a Service (ClusterIP); an Ingress with TLS; a ConfigMap for application settings; a HorizontalPodAutoscaler scaling between 2-10 replicas based on CPU (70% target). Provide values.yaml with sensible defaults and a values-production.yaml override with higher replicas, stricter resources, and production domain.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "{{ .Values.",
-        "description": "Templates must use Helm value references for all configurable fields so that environment-specific overrides work without modifying templates."
-      },
-      {
-        "type": "contains",
-        "value": "HorizontalPodAutoscaler",
-        "description": "The chart must include a HorizontalPodAutoscaler resource to enable automatic scaling based on resource utilization metrics."
-      },
-      {
-        "type": "contains",
-        "value": "values-production",
-        "description": "A production values file must be provided with environment-specific overrides for replicas, resources, and domain configuration."
-      },
-      {
-        "type": "contains",
-        "value": "tls:",
-        "description": "The Ingress resource must include TLS configuration to enforce encrypted traffic for production endpoints."
-      },
-      {
-        "type": "contains",
-        "value": "ConfigMap",
-        "description": "Application configuration must be externalized into a ConfigMap rather than hardcoded in the Deployment, enabling configuration changes without redeployment."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/laravel/SKILL.md

@@ -1,68 +0,0 @@
----
-name: laravel
-description: "Use when building Laravel 11+ applications with Eloquent ORM, middleware pipelines, queue-driven jobs, event broadcasting, and API resources for JSON:API-style responses."
----
-# Laravel
-
-## Purpose
-
-Use when building Laravel 11+ applications with Eloquent ORM, middleware pipelines, queue-driven jobs, event broadcasting, and API resources for JSON:API-style responses.
-
-## When to Use
-
-- Building or extending Laravel REST APIs with Eloquent-backed resources.
-- Designing middleware stacks, request validation, and authorization gates.
-- Implementing queue-based job processing, event/listener pipelines, or scheduled tasks.
-- Reviewing Laravel code for N+1 queries, mass-assignment safety, and queue reliability.
-
-## Instructions
-
-1. **Confirm the Laravel and PHP baseline first** because version-specific features (e.g., Laravel 11 slim skeleton, PHP 8.2+ enums) determine which patterns are available and which are outdated.
-2. **Define Eloquent models with explicit fillable/guarded arrays and relationship methods** because mass-assignment vulnerabilities and missing relationships are the most common source of data-integrity bugs.
-3. **Use Eloquent API Resources and Resource Collections for all JSON responses** because leaking raw model attributes exposes internal schema details and makes versioning painful.
-4. **Eager-load relationships at the query level with `with()` or `load()`** because N+1 queries silently degrade performance and are hard to catch without tooling.
-5. **Place business logic in dedicated service classes, not in controllers or models** because fat controllers and fat models resist testing and create coupling between HTTP concerns and domain rules.
-6. **Write Form Request classes for all validation instead of inline `$request->validate()`** because Form Requests centralize authorization checks, custom messages, and complex conditional rules in a testable unit.
-7. **Compose middleware for cross-cutting concerns like rate limiting, CORS, and tenant scoping** because middleware keeps controllers focused on happy-path logic and makes policies reusable across routes.
-8. **Dispatch jobs to queues for any work exceeding 200ms wall-clock time** because synchronous heavy work blocks the HTTP response cycle and degrades user-perceived latency.
-9. **Implement retry, backoff, and `failed()` methods on every queued job** because transient failures in mail, payment, and third-party APIs are normal and jobs without retry logic silently drop work.
-10. **Use events and listeners for side effects that should not block the primary action** because decoupling side effects (notifications, audit logs, cache invalidation) makes the primary action easier to test and reason about.
-11. **Register authorization via Policies tied to models, not ad-hoc Gate closures** because Policies co-locate all authorization rules for a resource and integrate with `authorize()` and `can()` helpers automatically.
-12. **Use database transactions for multi-step writes and wrap them with `DB::transaction()`** because partial writes without transactions leave data in an inconsistent state that is expensive to recover from.
-13. **Write feature tests using `RefreshDatabase` and factory-seeded data** because feature tests that hit real routes with real middleware catch integration bugs that unit tests miss.
-14. **Run `php artisan model:show` and `route:list` as verification checkpoints** because these commands surface missing relationships, duplicate routes, and middleware gaps before code review.
-15. **Configure queue workers with Horizon or Supervisor for production reliability** because artisan queue:work without supervision silently dies on memory leaks and unhandled exceptions.
-16. **Pin dependencies with `composer.lock` and run `composer audit` in CI** because unpinned dependencies introduce supply-chain risk and audit catches known CVEs before deployment.
-
-## Output Format
-
-Provide implementation guidance, code examples, Artisan commands, and configuration snippets as appropriate to the task. Include migration snippets when schema changes are involved.
-
-## References
-
-Load on demand. Do not preload all reference files.
-
-| File | Load when |
-| --- | --- |
-| `references/eloquent.md` | You need Eloquent model patterns, relationships, scopes, accessors/mutators, or query optimization guidance. |
-| `references/middleware-routing.md` | You need middleware composition, route grouping, rate limiting, or request lifecycle guidance. |
-| `references/queues-events.md` | You need queue job design, retry/backoff strategies, event/listener wiring, or Horizon configuration. |
-| `references/testing.md` | You need feature test patterns, factory design, mocking external services, or Pest/PHPUnit integration. |
-| `references/security.md` | You need CSRF protection, authentication guards, authorization policies, encryption, or input sanitization. |
-
-## Scripts
-
-No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
-
-## Examples
-
-- "Help me build a Laravel API resource for orders with nested line items"
-- "Review my Laravel queue job for retry safety and failure handling"
-
-## Gemini Platform Notes
-
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
-- User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.

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

@@ -1,21 +0,0 @@
-# Laravel Skill Assertions
-
-## Eval 1: API Resource with Eloquent Relationships
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Uses JsonResource | contains | `JsonResource` | API Resources are the canonical Laravel pattern for shaping JSON output. Raw model `toArray()` leaks schema internals. |
-| 2 | Eager-loads relationships | contains | `with(` | Eager loading with `with()` prevents N+1 queries when serializing related models through API Resources. |
-| 3 | Defines belongsTo | contains | `belongsTo` | The Order-to-Customer relationship must be explicitly defined on the model for Eloquent to resolve it. |
-| 4 | Defines hasMany | contains | `hasMany` | The Order-to-OrderItems relationship must be explicitly defined for nested resource serialization. |
-| 5 | Registers routes | contains | `Route::` | Route registration is required to expose the API Resource controller to HTTP clients. |
-
-## Eval 2: Queue-Based Job Processing
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Implements ShouldQueue | contains | `implements ShouldQueue` | The ShouldQueue interface is required for Laravel to dispatch the job to a queue driver instead of running it synchronously. |
-| 2 | Defines backoff | contains | `backoff` | Exponential or stepped backoff prevents thundering-herd retries against a failing third-party API. |
-| 3 | Implements failed() | contains | `failed(` | The `failed()` method is the designated hook for handling permanent failures after all retries are exhausted. |
-| 4 | Dispatches the job | contains | `dispatch(` | The job must be dispatched from the controller or service to enter the queue pipeline. |
-| 5 | Uses event dispatch | contains | `event(` | Post-payment side effects (notifications, audit logs) should be decoupled via events to keep the job focused. |