CtrlK
BlogDocsLog inGet started
Tessl Logo

simon/skills

Auto-generated tile from GitHub (10 skills)

92

1.16x
Quality

94%

Does it follow best practices?

Impact

92%

1.16x

Average score across 44 eval scenarios

SecuritybySnyk

Advisory

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

task.mdevals/scenario-23/

Domain-Safe Payment Processing Types

Problem / Feature Description

A fintech startup is building a payment processing service that handles accounts, payments, and refunds. After several production incidents — one where a paymentId was accidentally passed to a function expecting an accountId, and another where unvalidated user input reached a database write — the engineering team has decided to add stricter type-level guarantees to the domain model.

The core problems:

  1. ID confusion. Both account IDs and payment IDs are represented as plain strings. TypeScript's structural typing means they are interchangeable, so passing the wrong one to a function silently compiles.
  2. Unvalidated input flowing through. Functions deep in the service sometimes receive raw strings from API request bodies and use them as trusted domain values. There is no compile-time evidence of whether a value has been validated.
  3. Incomplete event handling. As the product has grown, new payment event types have been added (refund, chargeback) and some handlers were not updated, causing silent no-ops.

The team wants a reference implementation of the domain type layer that future engineers can follow when adding new entity types or event variants.

Output Specification

Produce the following files:

  • domain-types.ts — branded type definitions for at least AccountId and PaymentId, plus a discriminated union for at least three payment event variants (e.g., deposit, withdrawal, refund).
  • validators.ts — validation utilities: assertion functions for at least two of the branded types, at least one type-predicate function, and a handler function that processes each event variant exhaustively.
  • usage-example.ts — a short example showing:
    • How raw strings from an API request body are validated into branded types before use.
    • How the exhaustive event handler is called.
    • A // @ts-expect-error comment on a line that passes the wrong branded type to a function expecting a different one, proving the type system catches it.

All files must compile with TypeScript with zero errors (excluding // @ts-expect-error lines). Include a tsconfig.json if needed.

evals

README.md

tile.json