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 GroupEventIntentwould add cuisine preference, dietary constraints, table size;DinnerOptionwould addrestaurantId, cuisine tags, and reservation deep-links.MeetingIntent extends GroupEventIntentwould add duration, agenda, required attendees vs. optional.WeddingIntent extends GroupEventIntentwould 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.
GolfIntent, GolfConstraint, GolfOption, and the weather readout live at @golf/shared/schemas. The TypeScript types live at @golf/shared/types.