bridgebench 3.1.0-alpha.0 → 3.1.0-alpha.2

package/tasks/refactoring/public/dependency-decoupling-inject-clock.yaml

@@ -0,0 +1,237 @@
+id: dependency-decoupling-inject-clock
+version: 1.0.0
+category: refactoring
+cluster: dependency-decoupling
+difficulty: expert
+title: Decoupling Ledger From the Global Clock — Import Cycles, Singleton Sharing, and Init Order
+summary: >-
+  A Ledger is tightly coupled to a global Date.now(), the shared db singleton, and a config the
+  composition root overrides at startup. Four rewrites inject a Clock. Exactly one decouples the clock
+  while preserving the shared db instance, construction-after-override, and an acyclic import graph.
+  The decoys close an import cycle, construct a second database, or build the ledger before the
+  override. Classify each and name the observable difference.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (config-mod, db-mod, ledger-original,
+  module-graph, rewrite-a, rewrite-b, rewrite-c, rewrite-d). Cite artifact id(s) for every claim. Use
+  the verdict vocabulary: behavior-preserving / changes-behavior / meets-goal / fails-goal.
+
+  The transformation goal is to decouple Ledger.record from the global Date.now() by injecting a Clock,
+  while preserving all four properties module-graph lists: (1) the single shared `db` instance used
+  app-wide, (2) construction of the ledger AFTER main sets config.currency = 'EUR' (so entries stamp
+  'EUR'), (3) no import cycle among these modules, and (4) in production a timestamp equal to
+  Date.now().
+
+  1. Classify rewrite-a. Justify against all four preservation properties and the injection goal.
+
+  2. Classify rewrite-b. If it changes behavior, name the exact import cycle it introduces (the edges)
+     and state what goes wrong at startup and why, per module-graph's load order.
+
+  3. Classify rewrite-c. Name the observable difference from ledger-original in terms of which
+     Database instance ledger.record writes to, and the consequence for entries written through the
+     ledger.
+
+  4. Classify rewrite-d. State what currency a ledger entry carries and why, tracing the load order
+     from module-graph.
+
+  5. Exactly one rewrite decouples the clock without an import cycle, keeps the shared db singleton,
+     and constructs the ledger after the override. Name it. Then, for ledger-original, state the
+     ground truth: what currency does a ledger entry carry, and does the ledger write to the shared db
+     singleton?
+artifacts:
+  - id: config-mod
+    type: code
+    label: app/config.ts — the mutable config singleton
+    content: |
+      // app/config.ts — a single mutable config object, created at import.
+      export const config = {
+        currency: 'USD', // default; the composition root may override this before wiring services
+        dbUrl: 'postgres://prod/ledger',
+      };
+  - id: db-mod
+    type: code
+    label: app/db.ts — the shared database singleton
+    content: |
+      // app/db.ts — the shared database singleton, connected at import time from config.
+      import { config } from './config';
+
+      export class Database {
+        constructor(public readonly url: string) {}
+        write(entry: unknown): void {
+          /* append the entry to this connection */
+        }
+      }
+
+      export const db = new Database(config.dbUrl); // ONE connection, shared app-wide
+  - id: ledger-original
+    type: code
+    label: app/ledger.ts + app/main.ts — original (the reference behavior)
+    content: |
+      // app/ledger.ts — ORIGINAL: coupled to the db singleton, config, and the global clock.
+      import { db, Database } from './db';
+      import { config } from './config';
+
+      export class Ledger {
+        constructor(
+          private readonly database: Database,
+          private readonly currency: string,
+        ) {}
+        record(amount: number): void {
+          this.database.write({ amount, currency: this.currency, at: Date.now() }); // global clock
+        }
+      }
+
+      // app/main.ts — the composition root (the ONLY one).
+      import { db } from './db';
+      import { config } from './config';
+      import { Ledger } from './ledger';
+
+      config.currency = 'EUR';                        // override BEFORE wiring services
+      export const ledger = new Ledger(db, config.currency); // built after the override -> 'EUR'
+  - id: module-graph
+    type: note
+    label: app module graph — complete modules, import edges, load order, startup
+    content: |
+      app module graph — the complete set of modules, import edges, and load order.
+
+      Modules (the COMPLETE set): config.ts, db.ts, clock.ts (added by the decoupling), ledger.ts,
+      main.ts. main.ts is the ONLY composition root / entry point.
+
+      Original import edges (a DAG, no cycle):
+        db.ts     -> config.ts
+        ledger.ts -> db.ts, config.ts
+        main.ts   -> db.ts, config.ts, ledger.ts
+
+      ES module load order for the original (depth-first from the entry main.ts): config.ts, then
+      db.ts (which constructs the shared `db` singleton), then ledger.ts, then the main.ts body. A
+      module's top-level code runs once, when it is first imported.
+
+      Startup sequence in main.ts (authoritative): main sets config.currency = 'EUR' and THEN
+      constructs the ledger. So in the original the ledger is constructed AFTER the override and
+      stamps currency 'EUR'. The `db` singleton in db.ts is the ONE database connection the whole app
+      shares.
+
+      An acceptable decoupling must keep all of: (1) the single shared `db` instance used app-wide,
+      (2) construction of the ledger AFTER the config.currency override (so entries stamp 'EUR'),
+      (3) no import cycle among these modules, and (4) in production a timestamp equal to Date.now().
+      A circular import here means a module reads another module's export before that export has been
+      initialized.
+  - id: rewrite-a
+    type: code
+    label: rewrite-a — Clock leaf module, injected in main
+    content: |
+      // app/clock.ts — a LEAF module (imports nothing).
+      export interface Clock {
+        now(): number;
+      }
+      export const systemClock: Clock = { now: () => Date.now() };
+
+      // app/ledger.ts (rewrite-a) — receives the db and clock; imports types only.
+      import type { Database } from './db';
+      import type { Clock } from './clock';
+      export class Ledger {
+        constructor(
+          private readonly database: Database,
+          private readonly currency: string,
+          private readonly clock: Clock,
+        ) {}
+        record(amount: number): void {
+          this.database.write({ amount, currency: this.currency, at: this.clock.now() });
+        }
+      }
+
+      // app/main.ts (rewrite-a)
+      import { db } from './db';
+      import { config } from './config';
+      import { Ledger } from './ledger';
+      import { systemClock } from './clock';
+      config.currency = 'EUR';
+      export const ledger = new Ledger(db, config.currency, systemClock);
+  - id: rewrite-b
+    type: code
+    label: rewrite-b — clock imported from main
+    content: |
+      // app/clock.ts — same leaf module as rewrite-a.
+      export interface Clock { now(): number; }
+      export const systemClock: Clock = { now: () => Date.now() };
+
+      // app/ledger.ts (rewrite-b) — pulls the clock FROM main and builds the ledger at import.
+      import { db, Database } from './db';
+      import { config } from './config';
+      import { clock } from './main';                 // NEW edge: ledger.ts -> main.ts
+      export class Ledger {
+        constructor(
+          private readonly database: Database,
+          private readonly currency: string,
+          private readonly clock: Clock,
+        ) {}
+        record(amount: number): void {
+          this.database.write({ amount, currency: this.currency, at: this.clock.now() });
+        }
+      }
+      export const ledger = new Ledger(db, config.currency, clock); // runs at import of ledger.ts
+
+      // app/main.ts (rewrite-b)
+      import { Ledger } from './ledger';               // main.ts -> ledger.ts (closes the cycle)
+      import { systemClock } from './clock';
+      export const clock = systemClock;
+  - id: rewrite-c
+    type: code
+    label: rewrite-c — ledger builds its own Database
+    content: |
+      // app/clock.ts — same leaf module as rewrite-a.
+      export interface Clock { now(): number; }
+      export const systemClock: Clock = { now: () => Date.now() };
+
+      // app/ledger.ts (rewrite-c) — clock injected, but the ledger creates its OWN database.
+      import { Database } from './db';
+      import { config } from './config';
+      import type { Clock } from './clock';
+      export class Ledger {
+        private readonly database = new Database(config.dbUrl); // NEW connection, not the shared db
+        constructor(
+          private readonly currency: string,
+          private readonly clock: Clock,
+        ) {}
+        record(amount: number): void {
+          this.database.write({ amount, currency: this.currency, at: this.clock.now() });
+        }
+      }
+
+      // app/main.ts (rewrite-c)
+      import { config } from './config';
+      import { Ledger } from './ledger';
+      import { systemClock } from './clock';
+      config.currency = 'EUR';
+      export const ledger = new Ledger(config.currency, systemClock);
+  - id: rewrite-d
+    type: code
+    label: rewrite-d — ledger constructed at import time
+    content: |
+      // app/clock.ts — same leaf module as rewrite-a.
+      export interface Clock { now(): number; }
+      export const systemClock: Clock = { now: () => Date.now() };
+
+      // app/ledger.ts (rewrite-d) — clock injected and db shared, but the ledger is built at import.
+      import { db } from './db';
+      import { config } from './config';
+      import { systemClock } from './clock';
+      import type { Database } from './db';
+      import type { Clock } from './clock';
+      export class Ledger {
+        constructor(
+          private readonly database: Database,
+          private readonly currency: string,
+          private readonly clock: Clock,
+        ) {}
+        record(amount: number): void {
+          this.database.write({ amount, currency: this.currency, at: this.clock.now() });
+        }
+      }
+      export const ledger = new Ledger(db, config.currency, systemClock); // runs at import of ledger.ts
+
+      // app/main.ts (rewrite-d)
+      import { config } from './config';
+      import './ledger';                               // importing ledger triggers its construction
+      config.currency = 'EUR';                         // override runs AFTER ledger is already built
+      export { ledger } from './ledger';
+tags: [refactoring, dependency-decoupling, dependency-injection, import-cycle, singleton]

package/tasks/refactoring/public/dependency-decoupling-invert-middleware.yaml

@@ -0,0 +1,177 @@
+id: dependency-decoupling-invert-middleware
+version: 1.0.0
+category: refactoring
+cluster: dependency-decoupling
+difficulty: expert
+title: Inverting the Middleware Chain — Registration Order, a Shared Registry, and Import Cycles
+summary: >-
+  A hard-coded middleware chain (auth, rateLimit, log) is to be inverted so each middleware
+  self-registers via an imported register(). Exactly one inversion preserves the execution order and
+  the single shared registry with no import cycle. The decoys import the middleware in the wrong
+  order, hand out a fresh registry per call, or make a middleware import app and close a cycle.
+  Classify each and name the observable difference on the final context.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (pipeline-original, registry-note,
+  rewrite-a, rewrite-b, rewrite-c, rewrite-d). Cite artifact id(s) for every claim. Use the verdict
+  vocabulary: behavior-preserving / changes-behavior / meets-goal / fails-goal.
+
+  The transformation goal is to invert control so each middleware self-registers via register(), while
+  preserving: the CANONICAL execution order auth -> rateLimit -> log (registry-note), the single shared
+  registry so all three run against the same ctx passed to run(ctx), and an acyclic import graph. The
+  observable outcome of handle(ctx) is the final ctx (ctx.user, ctx.rateBucket, ctx.log).
+
+  1. Classify rewrite-a. Justify against execution order, shared registry, and the acyclic-import
+     requirement.
+
+  2. Classify rewrite-b. If it changes behavior, give the resulting execution order and the concrete
+     final value of ctx.log after handle(ctx), and compare to pipeline-original.
+
+  3. Classify rewrite-c. State which middlewares actually run against ctx and what the final ctx
+     (ctx.user, ctx.rateBucket, ctx.log) looks like, and name the mechanism.
+
+  4. Classify rewrite-d. Name the exact import cycle (the edges) and state what happens at startup and
+     why, per registry-note's load-order rule.
+
+  5. Exactly one inversion preserves order, keeps one shared registry, and stays acyclic. Name it.
+     Then, for pipeline-original, state the ground truth: the execution order and the final ctx.log and
+     ctx.rateBucket after handle(ctx).
+artifacts:
+  - id: pipeline-original
+    type: code
+    label: app/context.ts + app/app.ts — original inline chain (the reference behavior)
+    content: |
+      // app/context.ts — the shared request Context.
+      export interface Context {
+        user?: string;
+        rateBucket?: string;
+        log: string[];
+      }
+
+      // app/app.ts — ORIGINAL: the middleware chain is built inline, in a fixed order.
+      import { Context } from './context';
+
+      function auth(ctx: Context): void { ctx.user = 'u-42'; }
+      function rateLimit(ctx: Context): void { ctx.rateBucket = ctx.user ?? 'anon'; } // reads ctx.user
+      function log(ctx: Context): void { ctx.log.push(`user=${ctx.user ?? 'none'}`); } // reads ctx.user
+
+      export function handle(ctx: Context): void {
+        auth(ctx);       // 1
+        rateLimit(ctx);  // 2
+        log(ctx);        // 3
+        // ...then the route handler runs
+      }
+  - id: registry-note
+    type: note
+    label: pipeline module graph — canonical order, registry sharing, load order (complete)
+    content: |
+      pipeline module graph — canonical order, registry sharing, and load order (complete).
+
+      The request pipeline runs three middlewares in this CANONICAL execution order:
+        1. auth       -> sets ctx.user = 'u-42'
+        2. rateLimit  -> sets ctx.rateBucket = ctx.user ?? 'anon'   (reads ctx.user)
+        3. log        -> pushes `user=${ctx.user ?? 'none'}` to ctx.log   (reads ctx.user)
+      Then the route handler runs. These are the COMPLETE set of middlewares, and app is the ONLY
+      place they are wired. The observable outcome of handle(ctx) is the final ctx (ctx.user,
+      ctx.rateBucket, ctx.log).
+
+      The inversion introduces registry.ts. In an acceptable inversion:
+        - registry.ts is a LEAF module (imports nothing) exposing a SINGLE shared list; register(fn)
+          appends to it and run(ctx) invokes the registered fns in registration (insertion) order.
+        - Each middleware module calls register(...) at import, and app.ts imports the middleware
+          modules so that registration order equals the CANONICAL execution order above, then calls
+          run(ctx).
+        - No import cycle: middleware -> registry, app -> middleware + registry, registry -> nothing.
+
+      A circular import here means a middleware imports app (or app is otherwise re-entered) so that a
+      value is read before it is initialized. run(ctx) invokes handlers in the order they were
+      registered, which is the order app.ts imports the middleware modules.
+  - id: rewrite-a
+    type: code
+    label: rewrite-a — shared registry, imports in canonical order
+    content: |
+      // app/registry.ts — a LEAF module (imports nothing); ONE shared chain.
+      import type { Context } from './context';
+      type Middleware = (ctx: Context) => void;
+      const chain: Middleware[] = [];
+      export function register(fn: Middleware): void { chain.push(fn); }
+      export function run(ctx: Context): void { for (const fn of chain) fn(ctx); } // insertion order
+
+      // app/auth.ts
+      import { register } from './registry';
+      register((ctx) => { ctx.user = 'u-42'; });
+      // app/rateLimit.ts
+      import { register } from './registry';
+      register((ctx) => { ctx.rateBucket = ctx.user ?? 'anon'; });
+      // app/log.ts
+      import { register } from './registry';
+      register((ctx) => { ctx.log.push(`user=${ctx.user ?? 'none'}`); });
+
+      // app/app.ts — import order equals the canonical execution order.
+      import './auth';
+      import './rateLimit';
+      import './log';
+      import { run } from './registry';
+      export function handle(ctx) { run(ctx); }
+  - id: rewrite-b
+    type: code
+    label: rewrite-b — shared registry, imports reordered
+    content: |
+      // app/registry.ts, app/auth.ts, app/rateLimit.ts, app/log.ts — identical to rewrite-a
+      // (single shared chain; each middleware self-registers at import).
+
+      // app/app.ts — import order differs from the canonical execution order.
+      import './log';
+      import './auth';
+      import './rateLimit';
+      import { run } from './registry';
+      export function handle(ctx) { run(ctx); }
+  - id: rewrite-c
+    type: code
+    label: rewrite-c — a fresh registry per call
+    content: |
+      // app/registry.ts — hands out a NEW registry instance on every call.
+      import type { Context } from './context';
+      type Middleware = (ctx: Context) => void;
+      export class Registry {
+        private fns: Middleware[] = [];
+        register(fn: Middleware): void { this.fns.push(fn); }
+        run(ctx: Context): void { for (const fn of this.fns) fn(ctx); }
+      }
+      export function getRegistry(): Registry { return new Registry(); } // new instance each call
+
+      // app/auth.ts
+      import { getRegistry } from './registry';
+      getRegistry().register((ctx) => { ctx.user = 'u-42'; });
+      // app/rateLimit.ts
+      import { getRegistry } from './registry';
+      getRegistry().register((ctx) => { ctx.rateBucket = ctx.user ?? 'anon'; });
+      // app/log.ts
+      import { getRegistry } from './registry';
+      getRegistry().register((ctx) => { ctx.log.push(`user=${ctx.user ?? 'none'}`); });
+
+      // app/app.ts — canonical import order.
+      import './auth';
+      import './rateLimit';
+      import './log';
+      import { getRegistry } from './registry';
+      export function handle(ctx) { getRegistry().run(ctx); }
+  - id: rewrite-d
+    type: code
+    label: rewrite-d — auth imports a constant from app
+    content: |
+      // app/registry.ts, app/rateLimit.ts, app/log.ts — identical to rewrite-a (shared chain).
+
+      // app/auth.ts — reads a constant from app at import.
+      import { register } from './registry';
+      import { DEFAULT_USER } from './app';        // NEW edge: auth.ts -> app.ts
+      const u = DEFAULT_USER;                       // read at import (top-level)
+      register((ctx) => { ctx.user = u; });
+
+      // app/app.ts — imports the middleware (app.ts -> auth.ts), then declares the constant.
+      import './auth';
+      import './rateLimit';
+      import './log';
+      import { run } from './registry';
+      export const DEFAULT_USER = 'u-42';
+      export function handle(ctx) { run(ctx); }
+tags: [refactoring, dependency-decoupling, inversion-of-control, import-cycle, ordering]

package/tasks/refactoring/public/extract-and-inline-closure-capture.yaml

@@ -0,0 +1,132 @@
+id: extract-and-inline-closure-capture
+version: 1.0.0
+category: refactoring
+cluster: extract-and-inline
+difficulty: expert
+title: Extracting makeHandler From a Loop — Per-Iteration Capture, Shared var, and Eager Render
+summary: >-
+  A loop that registers deferred event handlers is to be refactored by extracting the handler-building
+  logic into a makeHandler helper. Exactly one extraction preserves, for every registered handler,
+  which widget object render runs on, the index it receives, and that render runs only on emit. The
+  decoys share a var across iterations, capture only the index wrong, or call render eagerly at
+  registration. Classify each and name the observable difference.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (register-original, bus-note, rewrite-a,
+  rewrite-b, rewrite-c, rewrite-d). Cite artifact id(s) for every claim. Use the verdict vocabulary:
+  behavior-preserving / changes-behavior / meets-goal / fails-goal.
+
+  The transformation goal is to lift the handler-building logic out of the loop into a reusable helper
+  WITHOUT changing, for each registered event, (i) which widget object render is called on, (ii) the
+  index argument render receives, or (iii) that render runs only when the event is emitted, never
+  during registration (see bus-note for what is observable).
+
+  1. Classify rewrite-a relative to register-original. Justify by tracing what each registered handler
+     captures across iterations.
+
+  2. Classify rewrite-b. If it changes behavior, state precisely: when the event 'refresh:' +
+     widgets[0].id is later emitted, which widget object render is called on and what index argument
+     it receives.
+
+  3. Classify rewrite-c. Name the observable difference from register-original, in terms of when
+     render runs and how many times, for widgets that are never emitted.
+
+  4. Classify rewrite-d. If it changes behavior, state what render receives (widget object and index)
+     when 'refresh:' + widgets[0].id is emitted, and how this differs from rewrite-b.
+
+  5. Exactly one extraction is the only behavior-preserving refactor. Name it. Then, for
+     register-original, state the ground truth: when 'refresh:' + widgets[0].id is emitted, which
+     widget object render is called on, with what index, and at what time.
+artifacts:
+  - id: register-original
+    type: code
+    label: dashboard/wire.ts — original inline loop (the reference behavior)
+    content: |
+      // dashboard/wire.ts — original. registerWidgets is the ONLY function that wires refresh
+      // handlers (see bus-note).
+      import type { EventBus } from './bus';
+      import type { Widget } from './widget';
+
+      export function registerWidgets(bus: EventBus, widgets: Widget[]): void {
+        for (let i = 0; i < widgets.length; i++) {
+          const widget = widgets[i];                 // per-iteration block binding
+          bus.on(`refresh:${widget.id}`, () => {
+            widget.render(i);                        // captures THIS iteration's widget and i
+          });
+        }
+      }
+  - id: bus-note
+    type: note
+    label: dashboard wiring — EventBus semantics, render observability, completeness
+    content: |
+      dashboard wiring — EventBus semantics and observability (complete).
+
+      EventBus.on(event, handler) registers handler under the event name; it does NOT call handler.
+      Later, EventBus.emit(event) invokes every handler registered under that event, in registration
+      order. Handlers may be invoked zero, one, or many times depending on runtime events.
+
+      widget.render(index) paints the widget and increments a global paint_count (an observable side
+      effect); the index argument is recorded in the paint. render is a method on the widget object
+      (it reads its own `this`), so which widget object a handler calls render on is observable, as is
+      the index argument.
+
+      registerWidgets is the ONLY function that wires refresh handlers, and it is called exactly once
+      at startup. The `widgets` array is frozen after registration: neither its length nor its element
+      identities change. This is the complete wiring surface.
+
+      Reference behavior of register-original: for each index k, a handler is registered under
+      'refresh:' + widgets[k].id that, WHEN LATER EMITTED, calls widgets[k].render(k) — the widget
+      object and the index captured at iteration k. render is not called during registration.
+  - id: rewrite-a
+    type: code
+    label: rewrite-a — makeHandler(widget, i) by value
+    content: |
+      // rewrite-a — extract a helper that takes the widget and index by value.
+      function makeHandler(widget: Widget, i: number): () => void {
+        return () => widget.render(i);
+      }
+
+      export function registerWidgets(bus: EventBus, widgets: Widget[]): void {
+        for (let i = 0; i < widgets.length; i++) {
+          const widget = widgets[i];
+          bus.on(`refresh:${widget.id}`, makeHandler(widget, i));
+        }
+      }
+  - id: rewrite-b
+    type: code
+    label: rewrite-b — hoisted var bindings
+    content: |
+      // rewrite-b — "hoist the temporaries out of the loop body."
+      export function registerWidgets(bus: EventBus, widgets: Widget[]): void {
+        for (var i = 0; i < widgets.length; i++) {
+          var widget = widgets[i];                   // var: one shared binding for the whole loop
+          bus.on(`refresh:${widget.id}`, () => widget.render(i));
+        }
+      }
+  - id: rewrite-c
+    type: code
+    label: rewrite-c — makeHandler computes render up front
+    content: |
+      // rewrite-c — "precompute the render inside the helper."
+      function makeHandler(widget: Widget, i: number): () => void {
+        const result = widget.render(i);             // render invoked here, during registration
+        return () => result;
+      }
+
+      export function registerWidgets(bus: EventBus, widgets: Widget[]): void {
+        for (let i = 0; i < widgets.length; i++) {
+          const widget = widgets[i];
+          bus.on(`refresh:${widget.id}`, makeHandler(widget, i));
+        }
+      }
+  - id: rewrite-d
+    type: code
+    label: rewrite-d — const widget, var i
+    content: |
+      // rewrite-d — "keep widget local, hoist just the counter."
+      export function registerWidgets(bus: EventBus, widgets: Widget[]): void {
+        for (var i = 0; i < widgets.length; i++) {   // var i: shared counter
+          const widget = widgets[i];                 // const: per-iteration binding
+          bus.on(`refresh:${widget.id}`, () => widget.render(i));
+        }
+      }
+tags: [refactoring, extract-and-inline, closure, capture, evaluation-order]

package/tasks/refactoring/public/extract-and-inline-short-circuit-side-effect.yaml

@@ -0,0 +1,120 @@
+id: extract-and-inline-short-circuit-side-effect
+version: 1.0.0
+category: refactoring
+cluster: extract-and-inline
+difficulty: expert
+title: Inlining hasFunds — Short-Circuit Side Effects, the >= Boundary, and Meets-Goal vs Fails-Goal
+summary: >-
+  A validator delegates to hasFunds, whose only side effect (a funds_check metric) fires only when a
+  && short-circuit reaches it. The task is to inline hasFunds and remove it. One rewrite preserves
+  behavior and meets the goal; one increments the metric unconditionally; one flips >= to >; one
+  preserves behavior but never actually inlines. Classify each against both behavior and goal.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (validate-original, order-note, rewrite-a,
+  rewrite-b, rewrite-c, rewrite-d). Cite artifact id(s) for every claim. Use the verdict vocabulary:
+  behavior-preserving / changes-behavior / meets-goal / fails-goal.
+
+  The transformation goal is to INLINE hasFunds into canCheckout and REMOVE the hasFunds function,
+  while preserving observable behavior exactly: the boolean canCheckout returns for every order, AND
+  the number of times metrics.inc('funds_check') fires (see order-note — the && short-circuit means it
+  fires only when order.itemsValid is true).
+
+  1. Classify rewrite-a against BOTH dimensions (behavior vs validate-original, and whether it meets
+     the inline goal). Justify by tracing the itemsValid=false and itemsValid=true paths.
+
+  2. Classify rewrite-b. If it changes behavior, name the observable difference and give the exact
+     order shape that reveals it, stating how many funds_check increments validate-original vs
+     rewrite-b produce on that order.
+
+  3. Classify rewrite-c. Give the exact order field values (itemsValid, balance, total) on which its
+     return value differs from validate-original, and state both return values.
+
+  4. Classify rewrite-d against BOTH dimensions. If its behavior matches validate-original, say so, and
+     separately state whether it satisfies the transformation goal, with the reason.
+
+  5. Exactly one rewrite both preserves behavior AND meets the inline goal. Name it. Then, for
+     validate-original, state the ground truth: when order.itemsValid is false, how many times does
+     metrics.inc('funds_check') fire, and what does canCheckout return?
+artifacts:
+  - id: validate-original
+    type: code
+    label: checkout/validate.ts — shipped validator (the reference behavior)
+    content: |
+      // checkout/validate.ts — the shipped validator.
+      import { metrics } from './metrics';
+      import type { Order } from './order';
+
+      function hasFunds(order: Order): boolean {
+        metrics.inc('funds_check');                  // the ONLY producer of the funds_check counter
+        return order.balance >= order.total;
+      }
+
+      export function canCheckout(order: Order): boolean {
+        return order.itemsValid && hasFunds(order);  // && short-circuits: hasFunds skipped if !itemsValid
+      }
+  - id: order-note
+    type: note
+    label: checkout — observability, the complete call surface, and the goal
+    content: |
+      checkout — observability and the complete call surface.
+
+      Order fields itemsValid (boolean), balance (number), total (number) are plain data properties:
+      reading them has no getter and no side effect. metrics.inc('funds_check') is the ONLY side
+      effect anywhere in this flow; the funds_check counter is watched on the ops dashboard.
+
+      hasFunds is the ONLY function that calls metrics.inc('funds_check'), and canCheckout is the ONLY
+      caller of hasFunds. So the number of funds_check increments per canCheckout call is fully
+      determined by canCheckout's control flow. This is the complete surface.
+
+      Reference behavior of canCheckout (validate-original): because `&&` short-circuits, hasFunds —
+      and therefore metrics.inc('funds_check') — runs if and only if order.itemsValid is true. When
+      itemsValid is true, canCheckout returns (order.balance >= order.total); when itemsValid is
+      false, it returns false and funds_check is NOT incremented. The comparison is `>=`, so an order
+      whose balance equals its total counts as funded.
+
+      The transformation goal is to INLINE hasFunds into canCheckout and remove the hasFunds function,
+      preserving that behavior exactly.
+  - id: rewrite-a
+    type: code
+    label: rewrite-a — inline with an early return
+    content: |
+      // rewrite-a — inline hasFunds, guard with an early return.
+      export function canCheckout(order: Order): boolean {
+        if (!order.itemsValid) return false;
+        metrics.inc('funds_check');
+        return order.balance >= order.total;
+      }
+  - id: rewrite-b
+    type: code
+    label: rewrite-b — compute the funds check, then AND it in
+    content: |
+      // rewrite-b — "compute the funds check up front, then AND it with itemsValid."
+      export function canCheckout(order: Order): boolean {
+        metrics.inc('funds_check');
+        const funded = order.balance >= order.total;
+        return order.itemsValid && funded;
+      }
+  - id: rewrite-c
+    type: code
+    label: rewrite-c — inline with an early return, tightened comparison
+    content: |
+      // rewrite-c — inline hasFunds, guard with an early return.
+      export function canCheckout(order: Order): boolean {
+        if (!order.itemsValid) return false;
+        metrics.inc('funds_check');
+        return order.balance > order.total;
+      }
+  - id: rewrite-d
+    type: code
+    label: rewrite-d — rewrite the caller as a ternary
+    content: |
+      // rewrite-d — "tidy the expression with a ternary."
+      function hasFunds(order: Order): boolean {
+        metrics.inc('funds_check');
+        return order.balance >= order.total;
+      }
+
+      export function canCheckout(order: Order): boolean {
+        return order.itemsValid ? hasFunds(order) : false;
+      }
+tags: [refactoring, extract-and-inline, inline, short-circuit, side-effect]