Gap found by the #94 capstone ("GAP #4" in lead-finder.test.ts).
Problem. The epic proof map bullet is "addressComponents → {city, suburb, state, country}." Google returns addressComponents as an ARRAY of {longText, types:[…]}, where you pick the element whose types[] includes locality / administrative_area_level_1 / country. The map step's extract and the connector responseMap both use getPath, whose grammar (dotted + numeric index + arr[].{…}) has no "find the element where types[] contains X" predicate. So extract:{city:"addressComponents.locality"} resolves to null against real Google data — geo fields don't populate declaratively.
Evidence. getPath(googleAddressComponents,"locality") === undefined; map(..., extract:{city:"addressComponents.locality"}) → city:null. Asserted as GAP #4. (The recipe does this in code via geoFromComponents — comps.find(x => x.types.includes(t)).)
Consequence. The reference JSON keeps the extract block (correct intent) but geo fields stay null until this lands; the live worker still does it in code.
Proposed fix (pick one):
- Extend the
getPath/responseMap grammar with a type-predicate array filter, e.g. addressComponents[types~=locality].longText (select element whose types array contains the token, then sub-path).
- A small
map option fromComponents that takes {typeKey:"types", valueKey:"longText", pick:{city:"locality",state:"administrative_area_level_1",country:"country",suburb:"sublocality"}} — a declarative version of geoFromComponents.
Option 1 is the most general and also helps any "array of typed components" API. Part of #94.
Gap found by the #94 capstone ("GAP #4" in
lead-finder.test.ts).Problem. The epic proof
mapbullet is "addressComponents → {city, suburb, state, country}." Google returnsaddressComponentsas an ARRAY of{longText, types:[…]}, where you pick the element whosetypes[]includeslocality/administrative_area_level_1/country. Themapstep'sextractand the connectorresponseMapboth usegetPath, whose grammar (dotted + numeric index +arr[].{…}) has no "find the element where types[] contains X" predicate. Soextract:{city:"addressComponents.locality"}resolves tonullagainst real Google data — geo fields don't populate declaratively.Evidence.
getPath(googleAddressComponents,"locality") === undefined;map(..., extract:{city:"addressComponents.locality"})→city:null. Asserted as GAP #4. (The recipe does this in code viageoFromComponents—comps.find(x => x.types.includes(t)).)Consequence. The reference JSON keeps the
extractblock (correct intent) but geo fields stay null until this lands; the live worker still does it in code.Proposed fix (pick one):
getPath/responseMap grammar with a type-predicate array filter, e.g.addressComponents[types~=locality].longText(select element whosetypesarray contains the token, then sub-path).mapoptionfromComponentsthat takes{typeKey:"types", valueKey:"longText", pick:{city:"locality",state:"administrative_area_level_1",country:"country",suburb:"sublocality"}}— a declarative version ofgeoFromComponents.Option 1 is the most general and also helps any "array of typed components" API. Part of #94.