limlock

spec · v0.1 · experimental · last updated

GolfIntent extends GroupEventIntent v0.1

GolfIntent is the first concrete specialization of GroupEventIntent. It adds golf-specific fields to the four mutable primitives (Constraint, Option, Vote, BookingProposal) and tightens groupSize to a maximum of 4.

This page documents only the additions on top of the horizontal primitives — read the GroupEventIntent page first for the inherited shape.

Intent — golf additions

interface GolfIntent extends GroupEventIntent {
  groupSize: 1 | 2 | 3 | 4;   // Tightened from N
  // No additional intent-level fields in v0.1.
  // The constraint set carries the per-player preferences.
}

The cap of 4 reflects the standard golf foursome. Future specializations of GroupEventIntent would relax or change this — a DinnerIntent with groupSize 8 is plausible — but golf is bounded.

Constraint — golf additions

interface GolfConstraint extends Constraint {
  holesPreference: 9 | 18 | null;  // null = no preference
  cartRequired: boolean;           // true = need a cart (mobility, mandate)
  // maxPriceCents inherited from Constraint
}

holesPreference being null is meaningfully different from "either is fine" when scoring options — a null value contributes no signal to the rank, while 9 or 18 down-weights options that don't match. cartRequired is binary: a player who needs a cart cannot accept a walking-only course, even one that scores well on every other dimension.

Option — golf additions

interface GolfOption extends Option {
  courseId: string;        // UUID — internal limlock course id
  courseName: string;
  holes: 9 | 18;
  cartIncluded: boolean;
  weather: WeatherReadout | null;
  stale: boolean;          // True if the underlying tee-time has expired
}

weather is null when forecasts are disabled or unavailable for the option's tee hour; otherwise it carries a WeatherReadout (temperature, wind, precip probability, UV index, severe condition). The full readout shape is published in the reference implementation at @golf/shared/schemas.

stale covers the case where the underlying tee-time row has been booked elsewhere or expired between resolution and read. The agent should refresh the option set or warn the user before tapping the booking link.

BookingProposal — golf additions

interface GolfBookingProposal extends BookingProposal {
  courseId: string;
  courseName: string;
  holes: 9 | 18;
  cartIncluded: boolean;
}

The proposal carries enough course context that downstream payment protocols (AP2 cart mandates etc.) can validate the line item without re-querying Limlock.

The extension pattern

Future verticals follow the same shape:

  • DinnerIntent extends GroupEventIntent would add cuisine preference, dietary constraints, table size; DinnerOption would add restaurantId, cuisine tags, and reservation deep-links.
  • MeetingIntent extends GroupEventIntent would add duration, agenda, required attendees vs. optional.
  • WeddingIntent extends GroupEventIntent would add date-firmness, vendor categories, deposit windows.

Verticals are not implemented in v0.1 — they're documented here as extension points only. Limlock's productization stays focused on golf. Vertical breadth is preserved as optionality, not as a shipping commitment.

Reference implementation The Zod schemas for GolfIntent, GolfConstraint, GolfOption, and the weather readout live at @golf/shared/schemas. The TypeScript types live at @golf/shared/types.