apps/backend/src/lib/stripe.tsx (1)

184-196: Different handling for deleted customers compared to syncStripeSubscriptions.

syncStripeSubscriptions (line 71-73) silently returns when the customer is deleted, while this function throws a StackAssertionError. Consider aligning the behavior—either both should throw or both should return early—to maintain consistency.

apps/e2e/tests/backend/endpoints/api/v1/new-transactions.test.ts (1)

133-148: Duplicate sendStripeWebhook helper function.

This function duplicates sendStripeWebhook from apps/e2e/tests/backend/backend-helpers.ts (lines 1522-1549). The existing helper also supports invalidSignature, omitSignature, and custom secret options. Consider importing from backend-helpers.ts instead.

♻️ Suggested import

-import { Payments as PaymentsHelper, Project, Team, User, niceBackendFetch } from "../../../backend-helpers";
+import { Payments as PaymentsHelper, Project, Team, User, niceBackendFetch, sendStripeWebhook } from "../../../backend-helpers";

-const stripeWebhookSecret = process.env.STACK_STRIPE_WEBHOOK_SECRET ?? "mock_stripe_webhook_secret";
-
-async function sendStripeWebhook(payload: unknown) {
-  const timestamp = Math.floor(Date.now() / 1000);
-  const hmac = createHmac("sha256", stripeWebhookSecret);
-  hmac.update(`${timestamp}.${JSON.stringify(payload)}`);
-  const signature = hmac.digest("hex");
-  return await niceBackendFetch("/api/latest/integrations/stripe/webhooks", {
-    method: "POST",
-    headers: {
-      "content-type": "application/json",
-      "stripe-signature": `t=${timestamp},v1=${signature}`,
-    },
-    body: payload,
-  });
-}

apps/backend/prisma/schema.prisma (1)

1046-1048: Schema comment claims XOR constraint not enforced at DB level.

The comment states "exactly one of subscriptionId or oneTimePurchaseId must be set," but no database constraint enforces this. Currently, both can be null (for direct charges) or both could be set (incorrectly). If the XOR is a hard requirement, add a check constraint in the migration.

♻️ Example check constraint for migration

ALTER TABLE "StripeRefund" ADD CONSTRAINT "StripeRefund_source_xor_check" 
CHECK (
  ("subscriptionId" IS NOT NULL AND "oneTimePurchaseId" IS NULL) OR 
  ("subscriptionId" IS NULL AND "oneTimePurchaseId" IS NOT NULL) OR
  ("subscriptionId" IS NULL AND "oneTimePurchaseId" IS NULL)
);

Note: The third case allows neither to be set, which may be valid for standalone charges. Adjust based on business requirements.

apps/backend/prisma/migrations/20260107160000_add_transaction_tables/migration.sql (1)

5-21: Consider adding foreign key constraints for data integrity.

The StripeRefund table references subscriptionId and oneTimePurchaseId but lacks foreign key constraints. While this provides flexibility (e.g., if referenced records are deleted), it may lead to orphaned references. Consider adding FK constraints with ON DELETE SET NULL if referential integrity is desired.

apps/backend/src/lib/new-transactions.ts (1)

175-199: Currency list in buildChargedAmount could be extracted as a constant.

The hardcoded currency codes array is repeated and could drift out of sync with actual supported currencies. Consider extracting to a shared constant.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-07T00:55:19.856Z
Learning: The project uses PostgreSQL with Prisma ORM for database management; database models are located in `/apps/backend/src`

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-07T00:55:19.856Z
Learning: The project uses PostgreSQL with Prisma ORM for database management; database models are located in `/apps/backend/src`

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-07T00:55:19.856Z
Learning: Applies to **/e2e/**/*.{test,spec}.{ts,tsx,js,jsx} : ALWAYS add new E2E tests when changing the API or SDK interface; err on the side of creating too many tests due to the critical nature of the authentication industry

apps/backend/src/lib/new-transactions.ts (1)

185-186: Consider externalizing the currency code list.

The hardcoded array of 18 currency codes creates a maintenance burden. If new currencies need to be supported, this code must be updated. Consider moving the currency list to a configuration constant or deriving it from the price schema definition.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/src/lib/new-transactions.ts (5)

175-199: Use integer arithmetic for money calculations.

The function uses parseFloat and floating-point multiplication for money amounts, which can introduce rounding errors. Additionally, there's no validation that quantity is a positive integer.

💰 Proposed fix

 function buildChargedAmount(
   product: InferType<typeof productSchema>,
   priceId: string | null,
   quantity: number
 ): Record<string, string> {
+  if (quantity < 0 || !Number.isInteger(quantity)) {
+    throw new Error(`Invalid quantity: ${quantity}. Must be a non-negative integer.`);
+  }
   if (!priceId || product.prices === "include-by-default") return {};
   const price = getOrUndefined(product.prices, priceId);
   if (!price) return {};

   const result: Record<string, string> = {};
   const currencyCodes = ["USD", "EUR", "GBP", "CAD", "AUD", "JPY", "CNY", "INR", "BRL", "MXN", "CHF", "SGD", "HKD", "KRW", "SEK", "NOK", "DKK", "NZD"];

   for (const code of currencyCodes) {
     const amount = price[code as keyof typeof price];
     if (typeof amount === "string" && amount !== "0") {
-      // Simple multiplication (assumes integer quantities for now)
-      const numValue = parseFloat(amount);
-      if (!isNaN(numValue)) {
-        result[code] = (numValue * quantity).toString();
-      }
+      // Use integer arithmetic to avoid floating-point errors
+      const decimalParts = amount.split('.');
+      const integerPart = parseInt(decimalParts[0] ?? '0', 10);
+      const fractionalPart = parseInt((decimalParts[1] ?? '0').padEnd(2, '0').slice(0, 2), 10);
+      const totalCents = (integerPart * 100 + fractionalPart) * quantity;
+      const resultInteger = Math.floor(totalCents / 100);
+      const resultFraction = totalCents % 100;
+      result[code] = `${resultInteger}.${resultFraction.toString().padStart(2, '0')}`;
     }
   }

   return result;
 }

---

844-844: Unsafe any type cast bypasses type checking.

The as any cast disables Prisma's type safety. While the comment acknowledges complexity, this could mask type errors.

Consider using a more specific type or Prisma's Prisma.SubscriptionWhereInput type:

where: where as Prisma.SubscriptionWhereInput,

---

206-207: Missing defensive validation for product schema.

The code directly casts subscription.product to InferType<typeof productSchema> without validation. If the database contains invalid data, this could cause runtime errors.

As per coding guidelines, prefer defensive coding with ?? throwErr(...).

const product = (subscription.product ?? throwErr("Missing product in subscription")) as InferType<typeof productSchema>;

---

618-619: Unsafe type casting without validation.

The code casts change.oldValue and change.newValue to specific shapes without validation. If the data doesn't match the expected shape, the code will silently use undefined values, potentially causing incorrect transaction entries.

Add validation or use the ?? throwErr(...) pattern from coding guidelines:

const oldValue = (change.oldValue ?? null) as { productId?: string, priceId?: string } | null;
const newValue = (change.newValue ?? null) as { productId?: string, priceId?: string } | null;

---

254-268: Consider extracting repeated included items logic.

The logic for iterating through includedItems and creating item_quantity_change entries is duplicated across multiple transaction builders (lines 254-268, 321-334, 383-398, 566-581). This violates the DRY principle.

Extract into a helper function:

function buildItemQuantityChangeEntries(
  product: InferType<typeof productSchema>,
  customerType: CustomerTypeValue,
  customerId: string,
  quantity: number
): ItemQuantityChangeEntry[] {
  const entries: ItemQuantityChangeEntry[] = [];
  const includedItems = getOrUndefined(product, "includedItems") ?? {};
  for (const [itemId, itemConfig] of Object.entries(includedItems)) {
    const itemQuantity = (itemConfig as { quantity?: number }).quantity ?? 0;
    if (itemQuantity > 0) {
      entries.push({
        type: "item_quantity_change",
        adjusted_transaction_id: null,
        adjusted_entry_index: null,
        customer_type: customerType,
        customer_id: customerId,
        item_id: itemId,
        quantity: itemQuantity * quantity,
      });
    }
  }
  return entries;
}

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/prisma/migrations/20260107160000_add_transaction_tables/migration.sql (2)

36-37: Reconsider DEFAULT 1 for quantity fields.

Defaulting oldQuantity and newQuantity to 1 may misrepresent actual changes if callers omit these values. For example, a change from 0 to 5 items could be incorrectly recorded as 1 to 5, corrupting transaction history.

Consider making these fields nullable without defaults, requiring explicit values to ensure accuracy.

♻️ Suggested alternative

-    "oldQuantity" INTEGER NOT NULL DEFAULT 1,
-    "newQuantity" INTEGER NOT NULL DEFAULT 1,
+    "oldQuantity" INTEGER,
+    "newQuantity" INTEGER,

---

61-80: Consider additional indexes for common query patterns.

Current indexes cover foreign-key lookups well. Consider adding:

• Index on SubscriptionChange.changeType if you'll filter by specific change types (e.g., "show all PRICE_CHANGE events")
• Indexes on createdAt fields if you'll query by time ranges frequently

These can be added in a follow-up migration once query patterns are confirmed.

📊 Example additional indexes

-- If filtering by change type is common
CREATE INDEX "SubscriptionChange_tenancyId_changeType_idx" ON "SubscriptionChange"("tenancyId", "changeType");

-- If time-range queries are common
CREATE INDEX "StripeRefund_tenancyId_createdAt_idx" ON "StripeRefund"("tenancyId", "createdAt");
CREATE INDEX "ProductChange_tenancyId_createdAt_idx" ON "ProductChange"("tenancyId", "createdAt");
CREATE INDEX "SubscriptionChange_tenancyId_createdAt_idx" ON "SubscriptionChange"("tenancyId", "createdAt");

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/src/lib/new-transactions.ts (3)

183-207: Consider using dynamic currency handling and address decimal precision.

The function has a hardcoded list of 18 currency codes (line 193), which may be incomplete and requires maintenance when supporting new currencies. Additionally, the comment on line 198 indicates that decimal quantities are not properly handled, and using parseFloat with direct multiplication (lines 199-202) can introduce floating-point precision errors in financial calculations.

Consider:

1. Iterating over all keys in the price object dynamically instead of maintaining a hardcoded currency list
2. Using a decimal library or integer-based calculations (cents) to avoid floating-point precision issues
3. Validating and documenting the expected behavior for decimal quantities

♻️ Suggested refactor

 function buildChargedAmount(
   product: InferType<typeof productSchema>,
   priceId: string | null,
   quantity: number
 ): Record<string, string> {
   if (!priceId || product.prices === "include-by-default") return {};
   const price = getOrUndefined(product.prices, priceId);
   if (!price) return {};
 
   const result: Record<string, string> = {};
-  const currencyCodes = ["USD", "EUR", "GBP", "CAD", "AUD", "JPY", "CNY", "INR", "BRL", "MXN", "CHF", "SGD", "HKD", "KRW", "SEK", "NOK", "DKK", "NZD"];
 
-  for (const code of currencyCodes) {
+  // Iterate over all currency keys in the price object
+  for (const code of Object.keys(price)) {
     const amount = price[code as keyof typeof price];
     if (typeof amount === "string" && amount !== "0") {
-      // Simple multiplication (assumes integer quantities for now)
       const numValue = parseFloat(amount);
       if (!isNaN(numValue)) {
+        // TODO: Consider using decimal library for precise money calculations
         result[code] = (numValue * quantity).toString();
       }
     }
   }
 
   return result;
 }

---

289-369: Optimize: avoid rebuilding the original transaction.

Line 296 calls buildNewStripeSubTransaction(subscription).entries just to extract the entries, which rebuilds the entire transaction unnecessarily. This is wasteful as it creates temporary objects that are immediately discarded.

♻️ Potential optimization

Consider extracting a helper function that returns just the entries for a subscription's included items, or pass the needed data directly rather than rebuilding the full transaction:

function getSubscriptionItemEntries(subscription: Subscription): NewTransactionEntry[] {
  const product = subscription.product as InferType<typeof productSchema>;
  const customerType = customerTypeToCrud(subscription.customerType);
  const entries: NewTransactionEntry[] = [];
  
  const includedItems = getOrUndefined(product, "includedItems") ?? {};
  for (const [itemId, itemConfig] of Object.entries(includedItems)) {
    const itemQuantity = (itemConfig as { quantity?: number }).quantity ?? 0;
    if (itemQuantity > 0) {
      entries.push({
        type: "item_quantity_change",
        adjusted_transaction_id: null,
        adjusted_entry_index: null,
        customer_type: customerType,
        customer_id: subscription.customerId,
        item_id: itemId,
        quantity: itemQuantity * subscription.quantity,
      });
    }
  }
  return entries;
}

---

1702-1710: Simplify cursor extraction logic.

The type union at line 1704 and the property checking at line 1708 are unnecessarily complex. According to the DatabasePaginatedList._nextOrPrev implementation (lines 802-811), all items have both itemCursor, prevCursor, and nextCursor properties set to the same value. The conditional check is therefore redundant.

♻️ Simplified implementation

   const hasMore = result.items.length > limit;
   const transactions = result.items.slice(0, limit).map((item) => item.item);
-  type ItemWithCursor = { itemCursor: string } | { nextCursor: string };
-  const lastItem = result.items[limit - 1] as ItemWithCursor | undefined;
+  const lastItem = result.items[limit - 1];
   const nextCursor = hasMore
-    ? (lastItem
-      ? ("itemCursor" in lastItem ? lastItem.itemCursor : lastItem.nextCursor)
-      : null)
+    ? (lastItem?.nextCursor ?? null)
     : null;

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/src/lib/new-transactions.ts (2)

1492-1502: Incomplete implementation: Item quantity renewals require customerId filter.

The current implementation returns empty results when no customerId is provided (lines 1492-1502), with a comment noting this is incomplete. This limits the usefulness of the item-quantity-renewal transaction type for admin or aggregate queries.

This appears to be a known limitation. Do you want me to generate a solution that iterates through customers to support listing without the customerId filter, or would you prefer to track this as a follow-up issue?

---

1713-1721: Optional: Simplify cursor extraction logic.

The inline type definition and complex conditional (lines 1716-1720) for extracting nextCursor could be more readable.

♻️ Suggested simplification

   const hasMore = result.items.length > limit;
   const transactions = result.items.slice(0, limit).map((item) => item.item);
-  type ItemWithCursor = { itemCursor: string } | { nextCursor: string };
-  const lastItem = result.items[limit - 1] as ItemWithCursor | undefined;
-  const nextCursor = hasMore
-    ? (lastItem
-      ? ("itemCursor" in lastItem ? lastItem.itemCursor : lastItem.nextCursor)
-      : null)
-    : null;
+  const lastItem = result.items[limit - 1];
+  const nextCursor = hasMore && lastItem
+    ? (lastItem.itemCursor ?? lastItem.nextCursor)
+    : null;

This assumes both itemCursor and nextCursor can coexist as optional properties, which appears to be the case based on line 816.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

apps/backend/prisma/schema.prisma (2)

1072-1102: Consider adding relations for referential integrity.

The ProductChange model lacks Prisma relations to Subscription and Tenancy. While this works, adding relations would provide:

• Referential integrity with onDelete: Cascade
• Easier querying via Prisma's relation loading
• Protection against orphaned records

This is consistent with patterns like SubscriptionInvoice which relates to Subscription.

---

1114-1137: Add relation to Subscription for referential integrity.

SubscriptionChange has a required subscriptionId but no Prisma relation to Subscription. Without the relation:

• Orphaned records can exist if a subscription is deleted
• No cascade delete behavior
• Manual joins required for queries

Suggested addition

   subscriptionId String       @db.Uuid
   customerId     String
   customerType   CustomerType
+
+  subscription Subscription @relation(fields: [tenancyId, subscriptionId], references: [tenancyId, id], onDelete: Cascade)

Note: This would also require adding a back-reference array in the Subscription model.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-07T00:55:19.871Z
Learning: The project uses PostgreSQL with Prisma ORM for database management; database models are located in `/apps/backend/src`

apps/dashboard/src/components/data-table/transaction-table.tsx (1)

37-37: The RefundableTransactionType alias adds no value.

Since TransactionType doesn't include null, the union TransactionType | null is only useful if the function parameter can be null. However, the guard isRefundableTransactionType is meant to narrow from TransactionType | null to a subset of TransactionType, but the return type annotation says it narrows to TransactionType (the full union), which doesn't accurately describe the narrowing behavior.

Consider defining the type to represent the actual refundable subset:

-type RefundableTransactionType = TransactionType | null;
+type RefundableTransactionType = 'purchase' | 'new-stripe-sub' | 'stripe-one-time';

Then update the guard accordingly:

-function isRefundableTransactionType(transactionType: RefundableTransactionType): transactionType is TransactionType {
+function isRefundableTransactionType(transactionType: TransactionType | null): transactionType is RefundableTransactionType {

packages/stack-shared/src/interface/crud/transactions.ts (1)

14-18: The validation test is always true for non-empty objects.

The test Object.values(value).some((amount) => typeof amount === "string") will always pass for any non-empty object with string values, which is already guaranteed by the schema's value type (yupString().defined()). The test adds no additional validation beyond what the schema already enforces.

If the intent is to ensure the object is non-empty, consider:

Suggested improvement

 const chargedAmountSchema = yupRecord(yupString(), yupString().defined()).test(
   "at-least-one-currency",
   "charged_amount must include at least one currency amount",
-  (value) => Object.values(value).some((amount) => typeof amount === "string"),
+  (value) => value != null && Object.keys(value).length > 0,
 ).defined();

apps/backend/src/lib/new-transactions.ts (2)

200-212: Potential floating-point precision issues in financial calculations.

Using parseFloat and floating-point multiplication for currency amounts can introduce precision errors. For financial calculations, consider using a decimal library or integer-based cent calculations.

Additionally, the hardcoded currency list on line 201 may not cover all currencies configured in products.

Consider using integer arithmetic for precision

-  for (const code of currencyCodes) {
-    const amount = price[code as keyof typeof price];
-    if (typeof amount === "string" && amount !== "0") {
-      // Simple multiplication (assumes integer quantities for now)
-      const numValue = parseFloat(amount);
-      if (!isNaN(numValue)) {
-        result[code] = (numValue * quantity).toString();
-      }
-    }
-  }
+  for (const code of currencyCodes) {
+    const amount = price[code as keyof typeof price];
+    if (typeof amount === "string" && amount !== "0") {
+      // Use string-based multiplication to preserve precision
+      // Convert to cents, multiply, convert back
+      const parts = amount.split(".");
+      const cents = parseInt(parts[0], 10) * 100 + (parts[1] ? parseInt(parts[1].padEnd(2, "0").slice(0, 2), 10) : 0);
+      const totalCents = cents * quantity;
+      result[code] = (totalCents / 100).toFixed(2);
+    }
+  }

---

1484-1502: Potential issue with empty customerId passed to getSubscriptions.

When options.filter.customerId is undefined, an empty string "" is passed to getSubscriptions (line 1488). This call happens before the guard that returns early on lines 1492-1501. Depending on how getSubscriptions handles an empty customerId, this could cause unexpected behavior or errors.

Consider moving the guard check before the getSubscriptions call:

Move guard before database call

   override async _nextOrPrev(...) {
     const now = new Date();
     const renewals: ItemQuantityRenewalData[] = [];

+    // Need customerId for customer-specific renewals
+    if (!options.filter.customerId) {
+      return {
+        items: [],
+        isFirst: true,
+        isLast: true,
+        cursor: options.cursor,
+      };
+    }
+
     // Get all subscriptions for the tenancy
     const subscriptions = await getSubscriptions({
       prisma: this.prisma,
       tenancy: this.tenancy,
       customerType: options.filter.customerType ?? "user",
-      customerId: options.filter.customerId ?? "",
+      customerId: options.filter.customerId,
     });

-    // If filtering by customer, we need the customerId
-    if (!options.filter.customerId) {
-      // ...
-      return { ... };
-    }

apps/e2e/tests/backend/endpoints/api/v1/internal/transactions-refund.test.ts (1)

250-253: Consider adding more specific assertions after refund.

The assertion on line 253 only checks that the original purchase transaction still exists. Consider also verifying that a stripe-refund transaction was created, which would provide better coverage of the refund flow.

// Verify refund transaction was created
const refundTx = transactionsAfterRefund.body.transactions.find((tx: any) => tx.type === "stripe-refund");
expect(refundTx).toBeDefined();

apps/e2e/tests/backend/endpoints/api/v1/new-transactions.test.ts (2)

134-147: Duplicated sendStripeWebhook helper.

This sendStripeWebhook function duplicates Payments.sendStripeWebhook from backend-helpers.ts (shown in relevant code snippets at lines 1524-1551). Consider using the existing helper to avoid duplication.

-const stripeWebhookSecret = process.env.STACK_STRIPE_WEBHOOK_SECRET ?? "mock_stripe_webhook_secret";
-
-async function sendStripeWebhook(payload: unknown) {
-  const timestamp = Math.floor(Date.now() / 1000);
-  const hmac = createHmac("sha256", stripeWebhookSecret);
-  hmac.update(`${timestamp}.${JSON.stringify(payload)}`);
-  const signature = hmac.digest("hex");
-  return await niceBackendFetch("/api/latest/integrations/stripe/webhooks", {
-    method: "POST",
-    headers: {
-      "content-type": "application/json",
-      "stripe-signature": `t=${timestamp},v1=${signature}`,
-    },
-    body: payload,
-  });
-}
+// Use PaymentsHelper.sendStripeWebhook instead of local implementation

Then update all calls to use PaymentsHelper.sendStripeWebhook(payload) instead of sendStripeWebhook(payload).

---

881-918: Redundant product-change empty list tests.

The three tests at lines 881-892, 894-905, and 907-918 are nearly identical - they all verify that an empty list is returned when no product changes exist. Consider consolidating into a single test to reduce redundancy.

-it("product-change: returns empty list when no product changes exist", async () => {
-  // ... identical assertions
-});
-
-it("product-change: remains empty without explicit product change records", async () => {
-  // ... identical assertions
-});
-
-it("product-change: stays empty when no product change entries are recorded", async () => {
-  // ... identical assertions
-});
+it("product-change: returns empty list when no product changes exist", async () => {
+  await setupProjectWithPaymentsConfig();
+
+  const response = await niceBackendFetch(NEW_TRANSACTIONS_ENDPOINT, {
+    accessType: "admin",
+    query: { type: "product-change" },
+  });
+  expect(response.status).toBe(200);
+  expect(response.body.transactions).toEqual([]);
+  expect(response.body.has_more).toBe(false);
+  expect(response.body.next_cursor).toBeNull();
+});

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-13T18:14:29.974Z
Learning: Applies to packages/stack-shared/src/config/schema.ts : Whenever making backwards-incompatible changes to the config schema, update the migration functions in `packages/stack-shared/src/config/schema.ts`

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-13T18:14:29.974Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Always add new E2E tests when changing the API or SDK interface, erring on the side of creating too many tests due to the critical nature of the industry

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-13T18:14:29.974Z
Learning: Applies to **/*.test.{ts,tsx,js,jsx} : Use `.toMatchInlineSnapshot` over other selectors in tests when possible, and check/modify snapshot-serializer.ts to understand how snapshots are formatted

Learnt from: CR
Repo: stack-auth/stack-auth PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-01-13T18:14:29.974Z
Learning: Applies to **/*.{ts,tsx} : Code defensively using `?? throwErr(...)` instead of non-null assertions, with good error messages explicitly stating violated assumptions