@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/stripe-integration/references/payment-flows.md

@@ -1,147 +0,0 @@
-# Payment Flows
-
-Load this when building checkout sessions, Payment Intents, or choosing between Stripe's payment integration patterns.
-
-## Choosing a Payment Pattern
-
-### Stripe Checkout (Hosted)
-
-Use for most cases. Stripe hosts the payment page, handles SCA/3DS, and manages payment method collection.
-
-```typescript
-const session = await stripe.checkout.sessions.create({
-  mode: 'payment', // or 'subscription' or 'setup'
-  line_items: [{ price: 'price_xxx', quantity: 1 }],
-  success_url: 'https://example.com/success?session_id={CHECKOUT_SESSION_ID}',
-  cancel_url: 'https://example.com/cancel',
-  customer: customerId,
-  metadata: { orderId: 'order_123' },
-});
-// Redirect user to session.url
-```
-
-- PCI compliance: SAQ-A (simplest level).
-- Supports Apple Pay, Google Pay, bank transfers, and 40+ local payment methods.
-- Limited UI customization: colors, logo, and fonts only.
-
-### Payment Element (Embedded)
-
-Use when you need the payment form embedded in your own UI but still want Stripe to handle payment method rendering.
-
-```typescript
-// Server: create a PaymentIntent
-const paymentIntent = await stripe.paymentIntents.create({
-  amount: 2999,
-  currency: 'usd',
-  customer: customerId,
-  automatic_payment_methods: { enabled: true },
-  metadata: { orderId: 'order_123' },
-});
-
-// Client: mount the Payment Element
-const elements = stripe.elements({
-  clientSecret: paymentIntent.client_secret,
-});
-const paymentElement = elements.create('payment');
-paymentElement.mount('#payment-element');
-```
-
-- PCI compliance: SAQ-A-EP (moderate).
-- Full control over the surrounding page layout.
-- Stripe handles payment method selection and 3DS challenges.
-
-### Raw Payment Intents
-
-Use only when Payment Element does not meet your requirements (custom card entry, server-to-server charges).
-
-```typescript
-const paymentIntent = await stripe.paymentIntents.create({
-  amount: 2999,
-  currency: 'usd',
-  payment_method: 'pm_card_visa',
-  confirm: true,
-  return_url: 'https://example.com/return',
-});
-```
-
-- PCI compliance: SAQ-D (highest burden) if you handle raw card numbers.
-- You manage 3DS challenges, error handling, and payment method display.
-
-## Idempotency Keys
-
-Attach an idempotency key to every mutating Stripe API call. Stripe caches the response for 24 hours and returns the same result for duplicate requests.
-
-```typescript
-await stripe.paymentIntents.create(
-  { amount: 5000, currency: 'usd', customer: 'cus_xxx' },
-  { idempotencyKey: `order:${orderId}:payment` }
-);
-```
-
-- Derive keys from the business operation, not random UUIDs, so that retries of the same operation use the same key.
-- Different operations on the same entity need different keys: `order:123:payment` vs `order:123:refund`.
-- Idempotency keys are scoped to the API key (test vs live).
-
-## Handling 3D Secure (SCA)
-
-European regulations require Strong Customer Authentication. Payment Intents transition through states:
-
-```
-requires_payment_method -> requires_confirmation -> requires_action -> processing -> succeeded
-```
-
-```typescript
-// After confirming, check the status
-if (paymentIntent.status === 'requires_action') {
-  // Redirect the user to paymentIntent.next_action.redirect_to_url.url
-  // or use stripe.js handleNextAction() on the client
-}
-```
-
-- Always use `return_url` or `next_action` handling. Never assume payment succeeds after `confirm`.
-- Test with card `4000 0025 0000 3155` (requires authentication) and `4000 0000 0000 3220` (3DS2 required).
-
-## Currency and Amount Handling
-
-Stripe amounts are in the smallest currency unit (cents for USD, yen for JPY).
-
-```typescript
-// $29.99 in USD
-const amount = 2999;
-
-// For zero-decimal currencies (JPY, KRW), use the full amount
-const amountJpy = 3000; // 3000 yen
-
-// Helper for conversion
-function toCents(dollars: number): number {
-  return Math.round(dollars * 100);
-}
-```
-
-- Never use floating-point arithmetic for currency. Convert to integers immediately.
-- Use Stripe's `currency` parameter to declare the currency. Stripe validates the amount against the currency's decimal places.
-
-## Error Handling
-
-```typescript
-try {
-  const charge = await stripe.charges.create({ amount: 2000, currency: 'usd' });
-} catch (err) {
-  if (err instanceof Stripe.errors.StripeCardError) {
-    // Card was declined: err.code, err.decline_code
-    console.log('Decline code:', err.decline_code);
-  } else if (err instanceof Stripe.errors.StripeRateLimitError) {
-    // Too many requests: implement exponential backoff
-  } else if (err instanceof Stripe.errors.StripeInvalidRequestError) {
-    // Invalid parameters: fix the request
-  } else if (err instanceof Stripe.errors.StripeAPIError) {
-    // Stripe server error: retry with idempotency key
-  } else if (err instanceof Stripe.errors.StripeConnectionError) {
-    // Network error: retry with idempotency key
-  }
-}
-```
-
-- Always log `err.requestId` for Stripe support investigations.
-- Card errors are expected in normal flow; do not treat them as bugs.
-- Retry API errors and connection errors with exponential backoff and the same idempotency key.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/stripe-integration/references/subscription-lifecycle.md

@@ -1,209 +0,0 @@
-# Subscription Lifecycle
-
-Load this when implementing recurring billing, handling plan changes, managing trials, or building dunning logic.
-
-## Creating Subscriptions
-
-### Via Checkout Session
-
-```typescript
-const session = await stripe.checkout.sessions.create({
-  mode: 'subscription',
-  customer: customerId,
-  line_items: [{ price: 'price_monthly_pro', quantity: 1 }],
-  subscription_data: {
-    trial_period_days: 14,
-    metadata: { userId: 'user_123', plan: 'pro' },
-  },
-  success_url: 'https://app.example.com/welcome',
-  cancel_url: 'https://app.example.com/pricing',
-});
-```
-
-### Via API (for returning customers)
-
-```typescript
-const subscription = await stripe.subscriptions.create({
-  customer: customerId,
-  items: [{ price: 'price_monthly_pro' }],
-  default_payment_method: 'pm_xxx',
-  trial_period_days: 14,
-  payment_behavior: 'default_incomplete',
-  expand: ['latest_invoice.payment_intent'],
-});
-```
-
-- `default_incomplete` requires the client to confirm payment before activating. Use this for SCA compliance.
-- `allow_incomplete` activates immediately and creates a pending invoice. Use for trusted customers or free trials.
-
-## Subscription States
-
-```
-trialing -> active -> past_due -> canceled
-                   -> canceled (immediate)
-                   -> unpaid (after all retries)
-                   -> paused (manual)
-```
-
-- **trialing**: No charge yet. Transitions to `active` when trial ends and first payment succeeds.
-- **active**: Payment current. The desired steady state.
-- **past_due**: Payment failed but retries remain. User should still have access during grace period.
-- **canceled**: Terminal state. No more invoices. Access should be revoked.
-- **unpaid**: All retries exhausted. Configure this vs `canceled` in Stripe subscription settings.
-
-## Plan Changes (Upgrades and Downgrades)
-
-### Immediate Proration (Default)
-
-```typescript
-const subscription = await stripe.subscriptions.retrieve(subId);
-const baseItem = subscription.items.data[0];
-
-await stripe.subscriptions.update(subId, {
-  items: [{ id: baseItem.id, price: 'price_monthly_enterprise' }],
-  proration_behavior: 'create_prorations',
-});
-```
-
-- Stripe calculates unused time on the old plan as a credit and charges the remaining time on the new plan.
-- The proration appears as line items on the next invoice.
-
-### Proration Options
-
-| Behavior | Effect |
-|----------|--------|
-| `create_prorations` | Credit old plan, charge new plan prorated (default) |
-| `always_invoice` | Same as above but immediately creates and pays an invoice |
-| `none` | No proration. New price applies at next billing cycle |
-
-### Previewing Proration
-
-```typescript
-const preview = await stripe.invoices.retrieveUpcoming({
-  customer: customerId,
-  subscription: subId,
-  subscription_items: [
-    { id: itemId, price: 'price_monthly_enterprise' },
-  ],
-  subscription_proration_behavior: 'create_prorations',
-});
-
-console.log('Next invoice total:', preview.total); // in cents
-console.log('Proration line items:', preview.lines.data);
-```
-
-- Always show the proration preview to the user before confirming a plan change.
-
-## Trial Periods
-
-```typescript
-// Trial on subscription creation
-const sub = await stripe.subscriptions.create({
-  customer: customerId,
-  items: [{ price: 'price_monthly_pro' }],
-  trial_period_days: 14,
-});
-
-// Trial with explicit end date
-const sub = await stripe.subscriptions.create({
-  customer: customerId,
-  items: [{ price: 'price_monthly_pro' }],
-  trial_end: Math.floor(Date.now() / 1000) + 14 * 24 * 60 * 60,
-});
-
-// End trial immediately (start billing now)
-await stripe.subscriptions.update(subId, {
-  trial_end: 'now',
-});
-```
-
-- Collect a payment method during trial signup. Trials without payment methods have high churn.
-- Send a reminder email 3 days before trial ends using the `customer.subscription.trial_will_end` event.
-
-## Cancellation Patterns
-
-### Cancel at Period End (Recommended)
-
-```typescript
-await stripe.subscriptions.update(subId, {
-  cancel_at_period_end: true,
-});
-// User retains access until the end of the billing period
-// Stripe fires customer.subscription.updated immediately
-// Stripe fires customer.subscription.deleted at period end
-```
-
-### Cancel Immediately
-
-```typescript
-await stripe.subscriptions.cancel(subId);
-// Access should be revoked immediately
-// Stripe fires customer.subscription.deleted
-```
-
-### Reactivate Before Period End
-
-```typescript
-await stripe.subscriptions.update(subId, {
-  cancel_at_period_end: false,
-});
-```
-
-## Dunning Strategy
-
-Stripe retries failed payments automatically based on your Smart Retries configuration. Your application handles the user-facing communication.
-
-```typescript
-// Webhook: invoice.payment_failed
-async function handlePaymentFailed(invoice: Stripe.Invoice) {
-  const attemptCount = invoice.attempt_count;
-  const userId = invoice.subscription_details?.metadata?.userId;
-
-  switch (attemptCount) {
-    case 1:
-      await notify(userId, 'payment_failed_gentle', {
-        message: 'Your payment failed. We will retry automatically.',
-        updatePaymentUrl: await createPortalUrl(invoice.customer as string),
-      });
-      break;
-    case 2:
-      await notify(userId, 'payment_failed_urgent', {
-        message: 'Second payment attempt failed. Please update your payment method.',
-        daysUntilCancellation: 7,
-      });
-      break;
-    case 3:
-      await notify(userId, 'payment_failed_final', {
-        message: 'Final payment attempt failed. Your subscription will be cancelled.',
-      });
-      break;
-  }
-}
-```
-
-### Dunning Best Practices
-
-- Show an in-app banner for `past_due` subscriptions with a direct link to update payment.
-- Keep access active during the retry period (typically 1-3 weeks).
-- Send the Customer Portal URL so users can update their payment method without contacting support.
-- Configure Smart Retries in Stripe Dashboard for optimal retry timing.
-- Use `invoice.upcoming` webhook to warn users about upcoming charges 3 days before renewal.
-
-## Metered Billing
-
-```typescript
-// Report usage on a metered subscription item
-await stripe.subscriptionItems.createUsageRecord(
-  meteredItemId,
-  {
-    quantity: 150,          // units consumed
-    timestamp: timestamp,   // when usage occurred
-    action: 'increment',    // or 'set' to replace
-  }
-);
-```
-
-- Use `increment` for additive reporting (safer with retries).
-- Use `set` only when you maintain the canonical usage count and report the total.
-- Report usage before the billing period ends. Unreported usage is not billed.
-- Stripe aggregates usage records per billing period and adds them to the invoice.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/stripe-integration/references/webhook-handling.md

@@ -1,163 +0,0 @@
-# Webhook Handling
-
-Load this when setting up Stripe webhook endpoints, processing events, or debugging delivery issues.
-
-## Endpoint Setup
-
-### Express/Next.js Webhook Route
-
-The critical requirement is receiving the **raw request body** for signature verification. Parsed JSON bodies will fail verification.
-
-```typescript
-// Next.js App Router
-export async function POST(req: NextRequest) {
-  const rawBody = await req.text(); // raw body, not req.json()
-  const signature = req.headers.get('stripe-signature')!;
-
-  let event: Stripe.Event;
-  try {
-    event = stripe.webhooks.constructEvent(
-      rawBody,
-      signature,
-      process.env.STRIPE_WEBHOOK_SECRET!
-    );
-  } catch (err) {
-    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
-  }
-
-  // Process event...
-  return NextResponse.json({ received: true });
-}
-```
-
-```typescript
-// Express.js -- must use raw body parser for the webhook route
-app.post(
-  '/webhooks/stripe',
-  express.raw({ type: 'application/json' }),
-  (req, res) => {
-    const event = stripe.webhooks.constructEvent(
-      req.body,
-      req.headers['stripe-signature']!,
-      process.env.STRIPE_WEBHOOK_SECRET!
-    );
-    // Process event...
-    res.json({ received: true });
-  }
-);
-```
-
-- Never apply JSON body parsing middleware to the webhook route.
-- Return HTTP 200 immediately. Process the event asynchronously.
-- Stripe retries on non-2xx responses with exponential backoff for up to 3 days.
-
-## Event Idempotency
-
-Stripe guarantees at-least-once delivery. Your handler must be idempotent.
-
-```typescript
-async function processEvent(event: Stripe.Event) {
-  // Strategy 1: Deduplicate by event ID
-  const processed = await db.processedEvent.findUnique({
-    where: { stripeEventId: event.id },
-  });
-  if (processed) return; // already handled
-
-  // Strategy 2: Check object version (for updates)
-  if (event.type === 'customer.subscription.updated') {
-    const sub = event.data.object as Stripe.Subscription;
-    const local = await db.subscription.findUnique({
-      where: { stripeId: sub.id },
-    });
-    // Skip if local version is newer (based on Stripe's created timestamp)
-    if (local && local.lastEventTimestamp >= event.created) return;
-  }
-
-  await handleEvent(event);
-
-  await db.processedEvent.create({
-    data: {
-      stripeEventId: event.id,
-      type: event.type,
-      processedAt: new Date(),
-    },
-  });
-}
-```
-
-## Essential Events by Feature
-
-### Checkout
-
-| Event | When | Action |
-|-------|------|--------|
-| `checkout.session.completed` | Payment succeeds | Activate order or subscription |
-| `checkout.session.expired` | Session unused for 24h | Clean up pending records |
-| `checkout.session.async_payment_succeeded` | Bank transfer clears | Activate order |
-| `checkout.session.async_payment_failed` | Bank transfer fails | Notify user |
-
-### Subscriptions
-
-| Event | When | Action |
-|-------|------|--------|
-| `customer.subscription.created` | New subscription | Record in database |
-| `customer.subscription.updated` | Plan change, status change | Sync local state |
-| `customer.subscription.deleted` | Subscription cancelled | Revoke access |
-| `invoice.payment_succeeded` | Recurring payment works | Confirm active status |
-| `invoice.payment_failed` | Payment retry fails | Send dunning email |
-| `invoice.upcoming` | 3 days before renewal | Notify user (optional) |
-
-### Payment Intents
-
-| Event | When | Action |
-|-------|------|--------|
-| `payment_intent.succeeded` | Payment confirmed | Fulfill order |
-| `payment_intent.payment_failed` | Card declined | Show error to user |
-| `payment_intent.requires_action` | 3DS challenge needed | Redirect user |
-
-## Webhook Security
-
-```typescript
-// Always verify signatures
-const event = stripe.webhooks.constructEvent(rawBody, signature, secret);
-
-// Rotate webhook secrets during key rotation:
-// 1. Add new endpoint with new secret
-// 2. Verify against both secrets during transition
-// 3. Remove old endpoint after confirming delivery
-function verifyWithFallback(body: string, sig: string): Stripe.Event {
-  try {
-    return stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!);
-  } catch {
-    return stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET_OLD!);
-  }
-}
-```
-
-## Local Development with Stripe CLI
-
-```bash
-# Listen to all events
-stripe listen --forward-to localhost:3000/api/webhooks/stripe
-
-# Listen to specific events only
-stripe listen --events checkout.session.completed,invoice.payment_failed \
-  --forward-to localhost:3000/api/webhooks/stripe
-
-# Trigger a specific event sequence
-stripe trigger payment_intent.succeeded
-
-# Replay a specific event from your Stripe account
-stripe events resend evt_xxxxxxxxxxxxx
-```
-
-- The CLI prints the webhook signing secret on startup. Use it as `STRIPE_WEBHOOK_SECRET` for local development.
-- CLI-forwarded events use a different signing secret than your production webhook endpoint.
-
-## Debugging Delivery Issues
-
-1. Check the Stripe Dashboard under Developers > Webhooks for failed deliveries.
-2. Look at the HTTP response code and body your endpoint returned.
-3. Verify the raw body is passed to `constructEvent`, not a parsed JSON object.
-4. Confirm the webhook secret matches the endpoint (test vs live, CLI vs dashboard).
-5. Check that no middleware is transforming the request body before your handler.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/svelte-sveltekit/evals/assertions.md

@@ -1,49 +0,0 @@
-# Svelte 5 + SvelteKit -- Eval Assertions
-
-## Eval 01: Rune-based component state management
-
-This eval validates correct usage of Svelte 5 runes for reactive state in a temperature converter component.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `$state` | Verifies the skill uses the Svelte 5 `$state` rune for mutable reactive declarations. In Svelte 5, `$state` replaces plain `let` for reactivity and enables fine-grained tracking across component boundaries. |
-| 2 | contains | `$derived` | Verifies the skill uses `$derived` for computed values. The Fahrenheit value is a pure derivation of Celsius, so `$derived` is the correct rune -- it automatically recomputes when dependencies change. |
-| 3 | contains | `$effect` | Verifies the skill uses `$effect` for side effects (console logging). Effects in Svelte 5 run after DOM updates and auto-track their reactive dependencies. |
-| 4 | pattern | `<script[^>]*>` | Verifies the output includes a Svelte component script block. All Svelte 5 components with logic must have a `<script>` tag. |
-| 5 | excludes | `$:` | Verifies the skill does NOT use Svelte 4 reactive declarations. The `$:` syntax is the legacy approach replaced by runes in Svelte 5. Mixing them causes confusing behavior. |
-
-### What a passing response looks like
-
-A passing response creates a `TemperatureConverter.svelte` component with:
-- A `$state(0)` declaration for the Celsius input value
-- A `$derived(celsius * 9/5 + 32)` computation for Fahrenheit
-- An `$effect(() => { console.log(...) })` for logging conversions
-- Input validation that guards against non-numeric entries
-- No usage of Svelte 4 `$:` reactive labels
-
----
-
-## Eval 02: SvelteKit form action with progressive enhancement
-
-This eval validates correct implementation of SvelteKit form actions with server-side validation and progressive enhancement.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `use:enhance` | Verifies the skill applies SvelteKit's progressive enhancement directive. `use:enhance` intercepts native form submission to provide SPA-like behavior while maintaining the no-JS fallback. |
-| 2 | contains | `fail(` | Verifies the skill uses SvelteKit's `fail()` helper for returning validation errors. `fail()` sets the correct HTTP status and makes errors available via `$page.form` on the client. |
-| 3 | pattern | `actions.*=.*\{` | Verifies the skill exports a form actions object. SvelteKit form actions must be exported from `+page.server.ts` as a named `actions` constant. |
-| 4 | pattern | `z\.(string\|object)\|zod` | Verifies the skill uses Zod for server-side validation. Schema-based validation is critical because client-side checks can be bypassed. |
-| 5 | contains | `+page.server.ts` | Verifies the skill correctly places form action logic in the server-only file. Form actions must run on the server to protect secrets and enforce authorization. |
-
-### What a passing response looks like
-
-A passing response provides:
-- A `+page.server.ts` file with `actions` export containing form validation logic
-- Zod schemas for name (string, min 2, max 100) and email (string, email format)
-- Usage of `fail(400, { errors })` to return validation errors
-- A `+page.svelte` file with a `<form method="POST" use:enhance>` that displays loading and error states
-- An `+error.svelte` boundary for unexpected server errors

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/svelte-sveltekit/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "svelte-sveltekit-eval-01",
-    "name": "Rune-based component state management",
-    "description": "Validate that the skill correctly guides creation of a Svelte 5 component using $state, $derived, and $effect runes for a counter with computed values and side effects.",
-    "prompt": "Create a Svelte 5 component called `TemperatureConverter.svelte` that lets users enter a Celsius value and shows the Fahrenheit equivalent. Use $state for the Celsius input, $derived for the Fahrenheit computation, and $effect to log every conversion to the console. Include input validation that rejects non-numeric values.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "$state",
-        "description": "Must use $state rune for mutable reactive state instead of Svelte 4 let declarations"
-      },
-      {
-        "type": "contains",
-        "value": "$derived",
-        "description": "Must use $derived rune for computed Fahrenheit value instead of reactive statements ($:)"
-      },
-      {
-        "type": "contains",
-        "value": "$effect",
-        "description": "Must use $effect rune for the console logging side effect"
-      },
-      {
-        "type": "pattern",
-        "value": "<script[^>]*>",
-        "description": "Must include a script block using Svelte 5 component syntax"
-      },
-      {
-        "type": "excludes",
-        "value": "$:",
-        "description": "Must NOT use Svelte 4 reactive declaration syntax ($:) since the component targets Svelte 5 runes"
-      }
-    ]
-  },
-  {
-    "id": "svelte-sveltekit-eval-02",
-    "name": "SvelteKit form action with progressive enhancement",
-    "description": "Validate that the skill correctly guides implementation of a SvelteKit form action with server-side validation, use:enhance progressive enhancement, and proper error handling.",
-    "prompt": "Implement a SvelteKit contact form with a name field (required, 2-100 chars) and email field (required, valid format). Create the +page.server.ts with a form action that validates with Zod, the +page.svelte with use:enhance for progressive enhancement showing loading and error states, and the +error.svelte boundary. Return validation errors to the form using SvelteKit's fail() helper.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "use:enhance",
-        "description": "Must use SvelteKit's use:enhance directive for progressive enhancement of the form"
-      },
-      {
-        "type": "contains",
-        "value": "fail(",
-        "description": "Must use SvelteKit's fail() helper to return validation errors with appropriate HTTP status codes"
-      },
-      {
-        "type": "pattern",
-        "value": "actions.*=.*\\{",
-        "description": "Must define form actions using the SvelteKit actions export pattern in +page.server.ts"
-      },
-      {
-        "type": "pattern",
-        "value": "z\\.(string|object)|zod",
-        "description": "Must use Zod schema validation for server-side form data validation"
-      },
-      {
-        "type": "contains",
-        "value": "+page.server.ts",
-        "description": "Must reference or create the +page.server.ts file for server-side form action handling"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/swift-best-practices/evals/assertions.md

@@ -1,35 +0,0 @@
-# Swift Best Practices — Eval Assertions
-
-## Eval 1: Actor-Based Service Design
-
-Tests whether the agent produces correct Swift 6 actor-based architecture for a network service.
-
-### Assertions
-
-1. **uses-actor-for-shared-state** — The service uses `actor` (not `class` with manual locks or DispatchQueue) for managing mutable shared state. Actors provide compiler-enforced isolation. Look for `actor NetworkService` or similar declaration with mutable properties inside the actor body.
-
-2. **protocol-based-interface** — A protocol (e.g., `protocol UserProfileService`) defines the async throwing contract. The actor conforms to this protocol. This enables dependency injection in consumers and allows test doubles without subclassing. Reject code that exposes the concrete actor type directly to consumers.
-
-3. **cancellation-propagation** — The code demonstrates cancellation awareness: either `Task.isCancelled` checks in loops, `try Task.checkCancellation()` calls, or `withThrowingTaskGroup` usage where child tasks are automatically cancelled when the group scope exits. Reject code that ignores cancellation entirely.
-
-4. **typed-throws-and-sendable** — Error handling uses a specific error enum (e.g., `enum NetworkError: Error`) and typed throws syntax (`throws(NetworkError)`) if targeting Swift 6.0+. All types passed across actor isolation boundaries (parameters and return types of actor methods) conform to `Sendable`. Reject code using untyped `throws` with `NSError` or stringly-typed errors.
-
-5. **async-stream-or-sequence** — All asynchronous patterns use `async`/`await`, `AsyncSequence`, or `AsyncStream`. No completion handlers, no `DispatchQueue.global().async`, no callback-based patterns in new code. Legacy patterns indicate the agent is not following Swift 6 idioms.
-
----
-
-## Eval 2: SwiftUI State Management Migration
-
-Tests whether the agent correctly migrates from ObservableObject to @Observable with proper SwiftUI data flow.
-
-### Assertions
-
-1. **observable-macro-adoption** — The cart model uses `@Observable class Cart` instead of `class Cart: ObservableObject`. Properties are plain `var` stored properties, not annotated with `@Published`. The `@Observable` macro automatically tracks access and mutations. Reject code that mixes `@Observable` with `@Published`.
-
-2. **state-and-environment-usage** — The view uses `@State` to own a local `@Observable` object, or receives shared state through `@Environment`. It does NOT use `@StateObject` or `@ObservedObject`, which are the old ObservableObject-era property wrappers. Accept `@Bindable` for creating bindings from `@Observable` properties.
-
-3. **pure-view-bodies** — The `var body: some View` computed property contains only view declarations. Side effects like saving to disk, network calls, or logging are in `.task { }` modifiers, `.onChange` modifiers, or explicit action closures (e.g., `Button("Save") { cart.save() }`). Reject code that performs I/O directly in the body computation.
-
-4. **parent-child-data-flow** — Data flows downward through initializer parameters or `@Environment`. Child views that need two-way binding use `@Bindable var cart: Cart` to create `$cart.propertyName` bindings. Reject code where child views independently fetch or create their own state objects.
-
-5. **value-types-and-immutability** — Individual cart items (e.g., `CartItem`) are modeled as `struct` with value semantics. The `Cart` container is a class (required for `@Observable`) but its contents prefer value types. This ensures items are `Sendable` by default and safe to pass between views without reference-counting overhead.