@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/spring-boot/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "secure-rest-api-with-spring-security",
-    "description": "Validate that the skill produces a secure Spring Boot REST API with Spring Security 6 lambda DSL, JWT authentication, record DTOs, and proper test coverage.",
-    "prompt": "Create a Spring Boot 3.4 REST API for a product catalog. Use Java records for ProductRequest and ProductResponse DTOs. Implement Spring Security 6 with a SecurityFilterChain bean using the lambda DSL to configure JWT authentication with a bearer token filter. Add @PreAuthorize for admin-only create and delete. Include a ProductController with GET (list, by-id), POST (create), and DELETE endpoints. Write a @WebMvcTest with MockMvc that tests both authorized and unauthorized access.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "SecurityFilterChain",
-        "description": "Must define a SecurityFilterChain bean using Spring Security 6's component-based configuration instead of the removed WebSecurityConfigurerAdapter."
-      },
-      {
-        "type": "contains",
-        "value": "record ",
-        "description": "Must use Java records for DTO definitions to enforce immutability and reduce boilerplate."
-      },
-      {
-        "type": "contains",
-        "value": "@PreAuthorize",
-        "description": "Must use @PreAuthorize with SpEL expressions for method-level authorization on restricted endpoints."
-      },
-      {
-        "type": "contains",
-        "value": "MockMvc",
-        "description": "Must use MockMvc for controller-layer integration testing that exercises the security filter chain."
-      },
-      {
-        "type": "contains",
-        "value": "@WebMvcTest",
-        "description": "Must use @WebMvcTest slice annotation to load only the web layer without the full application context."
-      }
-    ]
-  },
-  {
-    "name": "reactive-webflux-endpoint",
-    "description": "Validate that the skill produces correct reactive WebFlux endpoints with Mono/Flux return types, WebClient for external calls, reactive security, and WebTestClient for testing.",
-    "prompt": "Build a Spring Boot 3.4 reactive endpoint for a real-time stock price service. Create a @RestController that returns a Flux<StockPrice> stream using Server-Sent Events. Use WebClient to fetch prices from an external API. Add reactive Spring Security with a SecurityWebFilterChain bean that requires authentication for the stream endpoint. Include a record for StockPrice, a service that aggregates prices with Flux operators (map, filter, onErrorResume), and a @SpringBootTest with WebTestClient that verifies the SSE stream and security.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "Flux<",
-        "description": "Must use Flux return type for streaming reactive responses such as Server-Sent Events."
-      },
-      {
-        "type": "contains",
-        "value": "WebClient",
-        "description": "Must use WebClient for non-blocking HTTP calls to external services in the reactive pipeline."
-      },
-      {
-        "type": "contains",
-        "value": "SecurityWebFilterChain",
-        "description": "Must define SecurityWebFilterChain for reactive security configuration instead of the servlet-based SecurityFilterChain."
-      },
-      {
-        "type": "contains",
-        "value": "WebTestClient",
-        "description": "Must use WebTestClient for testing reactive endpoints including SSE streams and security."
-      },
-      {
-        "type": "contains",
-        "value": "TEXT_EVENT_STREAM",
-        "description": "Must produce TEXT_EVENT_STREAM media type for Server-Sent Events endpoints."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sqlalchemy/evals/assertions.md

@@ -1,51 +0,0 @@
-# Assertions Reference
-
-## Eval 1: Async session with relationship loading
-
-This eval tests the core async SQLAlchemy workflow: configuring sessions correctly for async, using appropriate eager loading strategies for different relationship types, and handling nullable relationships.
-
-### Assertion 1: expire_on_commit=False
-**What it checks:** The async session factory sets `expire_on_commit=False`.
-**Why it matters:** This is the single most common source of `MissingGreenlet` errors. After commit, SQLAlchemy expires loaded attributes by default. In async mode, the implicit lazy reload cannot run without a greenlet context. Setting `expire_on_commit=False` keeps loaded data accessible.
-
-### Assertion 2: joinedload for many-to-one
-**What it checks:** The query uses `joinedload()` for the `User.team` relationship.
-**Why it matters:** `joinedload` uses a LEFT JOIN in a single query, which is the correct strategy for many-to-one and one-to-one relationships. Using `selectinload` for a single object adds an unnecessary extra query. Using no eager loading at all will raise `MissingGreenlet` in async.
-
-### Assertion 3: selectinload for one-to-many
-**What it checks:** The query uses `selectinload()` for the `Team.projects` collection.
-**Why it matters:** `selectinload` uses a separate `SELECT ... WHERE id IN (...)` query, which is the correct strategy for collections. Using `joinedload` on a collection creates a cartesian product that duplicates parent rows and wastes bandwidth.
-
-### Assertion 4: None handling for nullable relationship
-**What it checks:** The code handles `user.team` being `None` before accessing `team.projects`.
-**Why it matters:** A user without a team will have `team=None`. Accessing `None.projects` raises `AttributeError`. Production code must guard against this, especially when the relationship is optional (nullable foreign key).
-
-### Assertion 5: 2.0-style select() syntax
-**What it checks:** The code uses `select(User).where(...)` instead of `session.query(User).filter(...)`.
-**Why it matters:** The legacy `Query` API is soft-deprecated in SQLAlchemy 2.0. The `select()` API is composable, supports type inference, works identically in sync and async, and is the only API receiving future improvements.
-
----
-
-## Eval 2: Alembic migration strategy
-
-This eval tests safe migration practices for production databases: handling non-nullable columns on tables with existing data, concurrent index creation, and rollback support.
-
-### Assertion 1: server_default for existing rows
-**What it checks:** The migration uses `server_default` when adding the column.
-**Why it matters:** Adding a non-nullable column to a table with 2M rows without a server default will fail immediately because existing rows violate the NOT NULL constraint. `server_default` tells the database to apply a default value at the storage engine level, which is fast and does not require a full table rewrite on Postgres.
-
-### Assertion 2: Concurrent index creation
-**What it checks:** The migration creates the index with `postgresql_concurrently=True` or equivalent.
-**Why it matters:** Standard `CREATE INDEX` acquires a SHARE lock on the table, blocking all writes for the duration. On a 2M row table, this can mean minutes of downtime. `CREATE INDEX CONCURRENTLY` builds the index without blocking writes, which is essential for zero-downtime deployments.
-
-### Assertion 3: Both upgrade() and downgrade()
-**What it checks:** The migration script includes both `upgrade()` and `downgrade()` functions.
-**Why it matters:** Production rollback capability is non-negotiable. If the deployment fails after the migration runs, the downgrade path must be available to revert the schema change. Auto-generated migrations often have incomplete or missing downgrade logic.
-
-### Assertion 4: Enum column type
-**What it checks:** The column uses a proper enum type (Python enum mapped to DB ENUM or CHECK constraint).
-**Why it matters:** Storing roles as plain strings allows invalid values. A database-level ENUM or CHECK constraint enforces valid values at the storage layer, preventing data corruption regardless of application-level validation.
-
-### Assertion 5: Transaction boundary for concurrent index
-**What it checks:** The migration handles the transaction boundary correctly for `CREATE INDEX CONCURRENTLY`.
-**Why it matters:** `CREATE INDEX CONCURRENTLY` cannot run inside a transaction block. Alembic wraps each migration in a transaction by default. The migration must explicitly commit or end the transaction before creating the concurrent index, or the command will fail with a Postgres error.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sqlalchemy/evals/evals.json

@@ -1,32 +0,0 @@
-{
-  "skill_name": "sqlalchemy",
-  "platform": "claude-code",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I have an async FastAPI application using SQLAlchemy 2.0 with asyncpg. I need to load a User along with their Team and all the team's Projects in a single endpoint. The User has a many-to-one relationship to Team, and Team has a one-to-many relationship to Project. Show me how to set up the async session, write the query with proper eager loading, and handle the case where the user has no team. I keep getting MissingGreenlet errors.",
-      "expected_output": "A complete solution showing async session configuration with expire_on_commit=False, a select() query using joinedload for the User->Team relationship and selectinload for Team->Projects, proper error handling for None team, and explanation of why MissingGreenlet occurs.",
-      "files": [],
-      "assertions": [
-        "Output uses expire_on_commit=False in async_sessionmaker configuration to prevent MissingGreenlet errors after commit",
-        "Query uses joinedload for the many-to-one User.team relationship (single LEFT JOIN, efficient for single objects)",
-        "Query uses selectinload for the one-to-many Team.projects collection (separate IN query, avoids cartesian product)",
-        "Solution includes handling for user.team being None before accessing team.projects",
-        "Code uses SQLAlchemy 2.0 select() syntax instead of legacy Query API"
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "I need to add a non-nullable 'role' enum column (admin, member, viewer) to our existing 'users' table that has 2 million rows in production Postgres. Write the Alembic migration that won't lock the table or fail on existing rows. Also show me how to add a concurrent index on the new column. We use async SQLAlchemy with asyncpg.",
-      "expected_output": "A multi-step Alembic migration that adds the column safely: first as nullable with server_default, then optionally alters to non-nullable, with concurrent index creation outside a transaction, and both upgrade() and downgrade() functions.",
-      "files": [],
-      "assertions": [
-        "Migration adds the column with server_default to handle existing rows without failure on the 2M row table",
-        "Migration uses postgresql_concurrently=True or equivalent for index creation to avoid locking the table",
-        "Migration includes both upgrade() and downgrade() functions for rollback capability",
-        "Column type uses a Python enum mapped to database ENUM or VARCHAR with CHECK constraint",
-        "Migration handles the transaction boundary correctly for concurrent index creation (commits or runs outside transaction)"
-      ]
-    }
-  ]
-}

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/evals/assertions.md

@@ -1,45 +0,0 @@
-# Stitch Eval Assertions
-
-## Eval 1: New Screen From Stitch Artifact
-
-This eval checks the default Stitch-first implementation loop for a new web screen: verify availability, inspect enabled tools, fetch the real artifact, then map it into the current stack and design system.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-| --- | --- | --- | --- |
-| 1 | contains | `stitch_get_status` | A Stitch workflow that does not verify reachability first can fabricate screen details or assume the wrong profile. |
-| 2 | contains | `mcp_gateway_status` | Cubis Foundry is the client-facing runtime, so the skill must confirm the MCP gateway is healthy before depending on Stitch passthrough tools. |
-| 3 | contains | `stitch_list_enabled_tools` | Stitch environments can expose different upstream capabilities; the skill should discover those instead of hardcoding an assumed toolset. |
-| 4 | pattern | `PageShell|Card|Button|design system|token` | The implementation must reuse the repo's existing primitives or tokens rather than dumping raw generated markup into production. |
-| 5 | pattern | `responsive|mobile|desktop|accessib` | Production-ready Stitch usage still has to preserve accessibility and responsive behavior. |
-
-### What a passing response looks like
-
-- Starts with Stitch and gateway preflight instead of guessing the artifact.
-- Mentions enabled Stitch tool discovery before choosing a retrieval path.
-- Maps the design into the existing Next.js route and shared primitives.
-- Calls out responsive and accessibility verification as part of the implementation.
-
----
-
-## Eval 2: Minimal-Diff Stitch Sync For Existing Screen
-
-This eval checks the update workflow: use the latest Stitch artifact as a diff source, preserve working local logic, and patch only the changed UI surface in a mobile implementation.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-| --- | --- | --- | --- |
-| 1 | contains | `stitch_get_status` | The skill must verify that the refreshed Stitch artifact is actually reachable before claiming design parity. |
-| 2 | contains | `stitch_list_enabled_tools` | Tool discovery matters for update flows too, especially when comparing local UI against the current Stitch surface. |
-| 3 | pattern | `minimal diff|patch only|changed only|diff` | Refreshing from Stitch should not default to a full rewrite when an implementation already exists. |
-| 4 | pattern | `analytics|feature flag|business logic|preserve` | Existing instrumentation and product logic are usually validated already and should survive the UI sync. |
-| 5 | pattern | `React Native|mobile|component|accessib|token` | The final patch must respect the target mobile stack and retain design-system and accessibility quality. |
-
-### What a passing response looks like
-
-- Treats Stitch as the source of truth for changed UI details, not for reauthoring the whole screen.
-- Preserves analytics hooks, feature flags, and business logic.
-- Describes a targeted patch path in React Native or another mobile stack.
-- Mentions accessibility, component reuse, and design-token consistency in the final implementation notes.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stitch/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "stitch-eval-01",
-    "name": "New screen from Stitch artifact",
-    "description": "Validate that the skill starts with Stitch and gateway preflight, pulls real Stitch artifacts, and maps them into the existing web stack instead of copying raw generated output.",
-    "prompt": "Implement a new account overview screen for a Next.js app from the latest Google Stitch artifact. The app already has `PageShell`, `Card`, `Button`, and tokenized typography primitives. Put the screen at `/account`, support desktop and mobile layouts, and keep the implementation aligned with the existing design system instead of pasting raw generated markup.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "stitch_get_status",
-        "description": "Must verify Stitch availability before relying on any artifact details."
-      },
-      {
-        "type": "contains",
-        "value": "mcp_gateway_status",
-        "description": "Must check Cubis Foundry MCP gateway status so the skill confirms Stitch passthrough is actually reachable."
-      },
-      {
-        "type": "contains",
-        "value": "stitch_list_enabled_tools",
-        "description": "Must inspect enabled Stitch tools before choosing which upstream artifact workflow to use."
-      },
-      {
-        "type": "pattern",
-        "value": "PageShell|Card|Button|design system|token",
-        "description": "Must map the Stitch output into the repo's existing primitives or token system rather than cloning raw one-off markup."
-      },
-      {
-        "type": "pattern",
-        "value": "responsive|mobile|desktop|accessib",
-        "description": "Must preserve responsive behavior and accessibility as part of the production implementation."
-      }
-    ]
-  },
-  {
-    "id": "stitch-eval-02",
-    "name": "Minimal-diff Stitch sync for existing screen",
-    "description": "Validate that the skill treats refreshed Stitch output as a diff input, preserves local business logic, and translates the update into the destination mobile stack.",
-    "prompt": "Update an existing React Native settings screen from refreshed Google Stitch output. Preserve analytics hooks, feature flags, and business logic already in the app. Only patch the visual and structural differences between the current local screen and the latest Stitch artifact, and keep the final result accessible and consistent with the app's existing components.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "stitch_get_status",
-        "description": "Must start with Stitch reachability checks before claiming parity with the latest artifact."
-      },
-      {
-        "type": "contains",
-        "value": "stitch_list_enabled_tools",
-        "description": "Must confirm which Stitch passthrough tools are enabled for the current environment."
-      },
-      {
-        "type": "pattern",
-        "value": "minimal diff|patch only|changed only|diff",
-        "description": "Must frame the work as a minimal patch against the existing implementation rather than a full rewrite."
-      },
-      {
-        "type": "pattern",
-        "value": "analytics|feature flag|business logic|preserve",
-        "description": "Must explicitly preserve validated local logic while updating only the UI surface."
-      },
-      {
-        "type": "pattern",
-        "value": "React Native|mobile|component|accessib|token",
-        "description": "Must translate the Stitch artifact into the destination mobile stack with accessibility and design-system awareness."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stripe-integration/SKILL.md

@@ -1,95 +0,0 @@
----
-name: stripe-integration
-description: "Use when building Stripe payment integrations: checkout sessions, subscriptions, webhook handling, idempotent API calls, fraud prevention, and end-to-end payment testing with Stripe CLI."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: Claude Code, Codex, GitHub Copilot
----
-# Stripe Integration
-
-## Purpose
-
-Guide the design and implementation of production-grade Stripe payment integrations covering one-time checkout sessions, recurring subscriptions with lifecycle management, secure webhook processing, idempotent server-side calls, and comprehensive test coverage using Stripe test mode and CLI tooling.
-
-## When to Use
-
-- Building a new Stripe Checkout or Payment Intent flow from scratch.
-- Adding subscription billing with plan upgrades, downgrades, and cancellations.
-- Implementing webhook endpoints that handle payment and subscription events.
-- Securing payment flows with idempotency keys, signature verification, and fraud prevention.
-- Writing integration tests against Stripe test mode or Stripe CLI fixtures.
-- Debugging failed payments, subscription state mismatches, or webhook delivery issues.
-
-## Instructions
-
-1. **Select the integration pattern before writing code** because Stripe offers hosted Checkout, embedded Payment Element, and raw Payment Intents, each with different PCI compliance burden and UI control tradeoffs. Default to hosted Checkout unless custom UI is required.
-
-2. **Create products and prices in Stripe Dashboard or via API before building flows** because all checkout sessions and subscriptions reference price IDs, and defining them upfront avoids runtime price creation that is harder to audit.
-
-3. **Generate checkout sessions server-side with explicit line items and metadata** because the server is the trust boundary for amounts, currency, and tax behavior. Never let the client dictate pricing.
-
-4. **Attach idempotency keys to every mutating Stripe API call** because network retries without idempotency can create duplicate charges, subscriptions, or refunds. Use a deterministic key derived from the business operation (e.g., `order:{orderId}:checkout`).
-
-5. **Store the Stripe customer ID in your database at creation time** because every subsequent operation (checkout, subscription, invoice, portal) requires the customer reference, and re-creating customers produces orphaned records.
-
-6. **Implement webhook signature verification on every incoming event** because unsigned webhooks can be forged by any attacker who discovers the endpoint URL. Use `stripe.webhooks.constructEvent` with the raw body and endpoint secret.
-
-7. **Return HTTP 200 from webhook handlers immediately, then process asynchronously** because Stripe retries delivery if it does not receive a 2xx within a timeout, and long-running synchronous processing causes duplicate delivery.
-
-8. **Handle webhook events idempotently by checking event ID or object version** because Stripe may deliver the same event multiple times during retries and endpoint recovery. Deduplicate by storing processed event IDs.
-
-9. **Sync subscription status exclusively through webhooks, not polling** because webhooks deliver state changes in near-real-time and avoid the latency, rate-limit pressure, and cost of periodic API calls.
-
-10. **Implement dunning logic for failed subscription payments** because Stripe retries automatically, but your application must notify users, display payment update prompts, and enforce grace periods before access revocation.
-
-11. **Use Stripe Customer Portal for self-service billing management** because building plan change, payment method update, and invoice history UI from scratch is error-prone and duplicates functionality Stripe provides.
-
-12. **Configure Stripe Radar rules for fraud prevention** because automated fraud detection with configurable risk thresholds, velocity checks, and block lists reduces chargebacks without manual review overhead.
-
-13. **Test every payment flow with Stripe test card numbers and Stripe CLI** because test mode isolates your integration from real money, and `stripe trigger` plus `stripe listen --forward-to` reproduce webhook sequences locally without deploying.
-
-14. **Separate API keys by environment and never commit them to source control** because leaked live keys grant full access to your Stripe account. Use environment variables and restrict live keys to production deployments.
-
-15. **Handle SCA and 3D Secure flows by using Payment Intents with `requires_action` status** because European regulations mandate Strong Customer Authentication, and payment flows that skip it will see elevated decline rates.
-
-16. **Log Stripe request IDs alongside your internal operation IDs** because Stripe support requires request IDs to investigate issues, and correlating them with your operations accelerates debugging.
-
-## Output Format
-
-```
-## Integration Architecture
-[Checkout/subscription/payment flow diagram and pattern choice rationale]
-
-## Implementation
-[Server and client code with idempotency, error handling, and type safety]
-
-## Webhook Setup
-[Events to subscribe, signature verification, idempotent processing logic]
-
-## Testing Plan
-[Test card numbers, Stripe CLI commands, edge case scenarios]
-```
-
-## References
-
-| File                          | Load when                                                                                     |
-| ----------------------------- | --------------------------------------------------------------------------------------------- |
-| `references/payment-flows.md` | Building checkout sessions, redirect flows, or embedded payment forms.                       |
-| `references/subscription-lifecycle.md` | Implementing recurring billing, plan changes, trials, dunning, and customer portal flows. |
-| `references/webhook-handling.md` | Setting up webhook endpoints, handling events, and debugging delivery behavior.           |
-
-## Examples
-
-- "Set up Stripe Checkout for a SaaS app with monthly and annual subscription plans."
-- "Implement a webhook handler for subscription lifecycle events with idempotent processing."
-- "Add Stripe Customer Portal for self-service billing with plan upgrade and downgrade support."
-
-## Copilot Platform Notes
-
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
-- User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
-- Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stripe-integration/evals/assertions.md

@@ -1,47 +0,0 @@
-# Stripe Integration Eval Assertions
-
-## Eval 1: Subscription Flow with Webhooks
-
-This eval tests the core Stripe subscription workflow: creating checkout sessions, handling lifecycle webhooks idempotently, and synchronizing subscription state to the application database.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `stripe.checkout.sessions.create` — Server-side session creation | Checkout sessions must be created server-side to ensure the server controls pricing, currency, and tax. Client-initiated amounts are a security vulnerability. |
-| 2 | contains | `constructEvent` — Webhook signature verification | Every webhook must be verified with `stripe.webhooks.constructEvent` to prevent forged events from triggering fulfillment or state changes. |
-| 3 | contains | `customer.subscription` — Subscription lifecycle events | The handler must process subscription lifecycle events (created, updated, deleted) to keep application state in sync with Stripe's source of truth. |
-| 4 | contains | `idempotency` — Idempotent webhook processing   | Stripe may deliver the same event multiple times. Without idempotency checks, duplicate processing causes data corruption and double-fulfillment. |
-| 5 | contains | `stripe_customer_id` — Customer ID persistence  | The Stripe customer ID must be stored in the database to link Stripe objects (subscriptions, invoices, payments) back to application users. |
-
-### What a passing response looks like
-
-- A server route that creates Checkout Sessions with explicit price IDs, customer reference, and metadata.
-- Webhook endpoint that verifies signatures using `constructEvent` before processing any event.
-- Event handlers for `customer.subscription.created`, `updated`, and `deleted` that update database records.
-- Idempotency guard that checks processed event IDs or object versions before applying state changes.
-- Database schema with `stripe_customer_id` and `stripe_subscription_id` columns on the users or subscriptions table.
-
----
-
-## Eval 2: Checkout Session Implementation
-
-This eval tests the Checkout Session flow: creating sessions with line items and metadata, handling post-payment webhooks, and supporting multiple payment methods.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `line_items` — Explicit line item configuration  | Checkout Sessions must define line items server-side with quantities and tax behavior. Omitting them causes checkout to display no items. |
-| 2 | contains | `success_url` — Post-checkout redirect           | Users must be redirected to a confirmation page after payment. Without success_url, Stripe has nowhere to send the user after checkout completes. |
-| 3 | contains | `metadata` — Session metadata attachment         | Metadata links the Stripe session to the internal order, enabling webhook handlers to correlate payment events with application records. |
-| 4 | contains | `checkout.session.completed` — Fulfillment webhook | Fulfillment must be triggered by the webhook, not the client redirect, because users may close the browser before the redirect completes. |
-| 5 | contains | `4242` — Test card numbers                       | Including test card numbers proves the implementation accounts for test mode verification, which is essential for development and CI testing. |
-
-### What a passing response looks like
-
-- API route that builds Checkout Session with line_items array, each containing price_data or price ID.
-- success_url and cancel_url configured with `{CHECKOUT_SESSION_ID}` template variable for order lookup.
-- Metadata attached to the session containing internal order ID and user ID.
-- Webhook handler for `checkout.session.completed` that marks the order as paid and triggers fulfillment.
-- Test section listing Stripe test card numbers (4242... for success, 4000... for various decline scenarios).

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/stripe-integration/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "subscription-flow-with-webhooks",
-    "description": "Validate that the skill produces a complete subscription flow with Stripe Checkout, webhook handling for lifecycle events, idempotent processing, and proper subscription status synchronization.",
-    "input": "Implement a SaaS subscription system with Stripe. Users choose between Basic ($10/mo) and Pro ($25/mo) plans. Use Stripe Checkout for the payment flow. Handle all subscription lifecycle webhooks (created, updated, deleted, past_due). Store subscription state in a PostgreSQL database. Ensure webhook handlers are idempotent and return 200 immediately.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "stripe.checkout.sessions.create",
-        "description": "Must create Checkout Sessions server-side with explicit price IDs and customer references, never allowing the client to set amounts."
-      },
-      {
-        "type": "contains",
-        "value": "constructEvent",
-        "description": "Webhook handler must verify signatures using stripe.webhooks.constructEvent with the raw body and endpoint secret to prevent forged events."
-      },
-      {
-        "type": "contains",
-        "value": "customer.subscription",
-        "description": "Must handle subscription lifecycle events (customer.subscription.created, updated, deleted) to synchronize subscription state from Stripe to the database."
-      },
-      {
-        "type": "contains",
-        "value": "idempotency",
-        "description": "Must implement idempotent webhook processing by checking event IDs or object versions to prevent duplicate processing on retry delivery."
-      },
-      {
-        "type": "contains",
-        "value": "stripe_customer_id",
-        "description": "Must persist the Stripe customer ID in the application database to associate Stripe objects with application users across all operations."
-      }
-    ]
-  },
-  {
-    "name": "checkout-session-implementation",
-    "description": "Validate that the skill produces a secure Checkout Session implementation with proper configuration, success/cancel handling, metadata attachment, and post-payment fulfillment through webhooks.",
-    "input": "Build a Stripe Checkout integration for an e-commerce store using Next.js. Create an API route that generates Checkout Sessions for cart items. Include tax calculation with Stripe Tax. Attach order metadata to the session. Handle the checkout.session.completed webhook to fulfill the order. Support both card and Apple Pay/Google Pay payment methods. Include error handling and test card numbers for verification.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "line_items",
-        "description": "Checkout Session must specify line_items with price_data or price IDs, quantities, and tax behavior for each cart item."
-      },
-      {
-        "type": "contains",
-        "value": "success_url",
-        "description": "Must configure success_url and cancel_url for post-checkout redirects, using session ID template variables for order confirmation pages."
-      },
-      {
-        "type": "contains",
-        "value": "metadata",
-        "description": "Must attach application-specific metadata (order ID, user ID) to the Checkout Session for correlating Stripe events with internal records."
-      },
-      {
-        "type": "contains",
-        "value": "checkout.session.completed",
-        "description": "Must handle the checkout.session.completed webhook event for order fulfillment, not relying solely on client-side redirect for confirmation."
-      },
-      {
-        "type": "contains",
-        "value": "4242",
-        "description": "Must include Stripe test card numbers (4242424242424242 for success) for testing the payment flow in development."
-      }
-    ]
-  }
-]