fix(endpoint-form): a location group can come from a field-name prefix, so relocation stops asking visitors for coordinates

/embed/relocation-wheel rendered four raw latitude/longitude number inputs
plus a decimal-hours timezone, and it was the only widget that did. Never a
missing feature: the city-search substitution was already generic, it just
could not see this one shape.

A group used to come from object nesting alone, and groupHasLocation required
all three of LOCATION_TRIO by exact field name. Five of the six two-location
operations nest per person (person1/person2, personA/personB) so each already
got its own city box. generateRelocationChart is the only operation in the
spec that puts both coordinate pairs at the TOP level, told apart by a name
prefix, so no field was named latitude, the flat group failed the test, and
nothing was suppressed.

Three rules now, all derived from spec shape, no per-operation list anywhere:

- splitCoordinateName groups a flat *Latitude/*Longitude pair under its
  prefix, so a future partnerLatitude needs no code change. The prefix is
  harvested from coordinates ONLY, so birthDate does not invent a birth group
  holding a lone date.
- The field key stays the original wire name. A prefixed coordinate reports
  name: latitude but keeps key: birthLatitude, because the key is the
  serialisation identity and birth.latitude POSTs a body the API rejects.
  The fill handler now looks keys up from the model instead of building
  group.name, which is what made that assumption safe to break.
- LOCATION_PAIR: a group qualifies on lat+lon, timezone optional. Relocation
  has one top-level timezone and it is the BIRTH timezone, since relocating
  does not move the birth moment, so the relocation group owns none. Only the
  first location group claims an unowned flat timezone, else two city boxes
  overwrite each other with the wrong offset.

The browser audit then caught two things no model-level test could: the
placeholder was hardcoded "City of birth" so both boxes read the same, and
the help text hardcoded "Required: latitude, longitude, timezone", which is a
visible lie on the block that owns no timezone. Both now derive. Rendered
result: Birth location / Relocation location, Birth city / Relocation city,
"Fills latitude, longitude, timezone" vs "Fills latitude, longitude", zero
number inputs.

Verified: all 6 multi-location operations produce the right picker count, a
sweep of all 73 coordinate operations leaves 0 raw coordinates and creates 0
phantom single-field groups, new unit tests are sabotage-verified, a new
Playwright test renders relocation in a real browser, 474 unit and 27 e2e
green, axe still passes with the second picker.

Also in here, both found while auditing rather than assumed:

- e2e specs renamed to *.e2e.ts with testMatch pinned. Bun globs *.spec.ts as
  well as *.test.ts, so a bare `bun test` swept up the Playwright files and
  reported 4 failures. The enumerated test script hid it, but a red suite that
  is not red trains you to ignore the number. Bare bun test now 0 fail, and
  the test script is a glob instead of 16 hand-listed files, which was a real
  drift trap since a new test file silently never ran.
- release.yml: the git tag + git push --follow-tags pair is INERT here, since
  --follow-tags pushes only annotated tags. Tagging actually happens
  server-side in action-gh-release, which is why every tag on this remote is
  lightweight. Annotated in place after the identical two lines were found
  losing every tag in a sibling repo with no Release step. Not restructured on
  a release day.

Author: ph33nx

.github/workflows/release.yml

@@ -183,6 +183,15 @@ jobs:
           # and the committed codegen (registry, manifest, docs tables).
           git add packages/ registry/ apps/docs/manifest.js README.md AGENTS.md
           git commit -m "release: v$VERSION"
+          # These two lines are INERT and the tag you see on the remote is not from here.
+          # `git tag` makes a LIGHTWEIGHT tag and `git push --follow-tags` pushes only
+          # ANNOTATED ones, so this pushes the commit and silently drops the tag. Tagging
+          # actually happens server-side in the `action-gh-release` step below, via
+          # `tag_name`, which is why every tag on this remote is lightweight (no `^{}`
+          # dereference line in `git ls-remote --tags`). Verified 2026-08-05 after the same
+          # two lines were found losing every tag in a sibling repo that has no Release step.
+          # So do NOT remove `action-gh-release` or replace it with a plain `git push`
+          # believing this covers tagging. Cleanup tracked; not touched on a release day.
           git tag "v$VERSION"
           git push --follow-tags
 

AGENTS.md

@@ -141,6 +141,8 @@ Every snippet below follows this rule.
 
 Every chart endpoint (Western, Vedic, KP, synastry, transits, dasha, dosha, panchang) needs `latitude`, `longitude`, and `timezone`. Never ask the user to type coordinates. Call `/location/search` first, then feed the result into the chart endpoint.
 
+Two endpoints take TWO locations, and they name them differently. `POST /astrology/synastry`, `/astrology/composite-chart`, `/vedic-astrology/compatibility` and `/human-design/connection` nest a full location per person (`person1` / `person2`, or `personA` / `personB`). `POST /astrology/relocation-chart` instead takes `birthLatitude`, `birthLongitude`, `relocationLatitude`, `relocationLongitude` at the top level with a single `timezone`, which is the BIRTH timezone: relocating does not move the birth moment. `<roxy-endpoint-form>` renders a separate city search for each location automatically, so self-fetch mode needs no extra work.
+
 ```ts
 // Right
 const { data: cities } = await roxy.location.searchCities({ query: { q: 'Mumbai' } });

package.json

@@ -32,7 +32,7 @@
 		"check:previews": "bun run scripts/check-previews.ts",
 		"audit": "bun run scripts/audit.ts",
 		"typecheck": "tsc --noEmit",
-		"test": "bun test packages/ui/tests/utils.test.ts packages/ui/tests/components.test.ts packages/ui/tests/base-element.test.ts packages/ui/tests/bindings.test.ts packages/ui/tests/chart-width.test.ts packages/ui/tests/bodygraph.test.ts packages/ui/tests/theming.test.ts packages/ui/tests/themes.test.ts packages/ui/tests/field-schema.test.ts packages/ui/tests/taxonomy.test.ts packages/ui/tests/endpoint-form.test.ts packages/ui/tests/key-guard.test.ts packages/ui/tests/build-schemas.test.ts packages/ui/tests/widgets.test.ts packages/ui/tests/embed-tab.test.ts packages/ui/tests/check-sizes.test.ts --timeout 10000",
+		"test": "bun test --timeout 10000",
 		"test:e2e": "playwright test",
 		"check": "biome check . --fix",
 		"brand:check": "bun run scripts/brand-grep.ts",

packages/ui/src/components/endpoint-form.ts

@@ -10,6 +10,7 @@ import {
 	type FieldDef,
 	type FormModel,
 	isZodiacEnum,
+	LOCATION_PAIR,
 	LOCATION_TRIO,
 	type OpenApiDoc,
 	type OperationSchema,
@@ -500,6 +501,14 @@ export class RoxyEndpointForm extends LitElement {
 			this.groupHasLocation(f.group)
 		)
 			return 'location';
+		// A flat timezone in a group with no coordinates of its own is still suppressed when a
+		// location group has claimed it, otherwise the prefixed shape shows a raw decimal-hours
+		// box beside two city searches that already know the answer.
+		if (
+			f.name === 'timezone' &&
+			this.locationGroups().some((g) => this.timezoneFieldFor(g)?.key === f.key)
+		)
+			return 'location';
 		return 'normal';
 	}
 
@@ -516,10 +525,39 @@ export class RoxyEndpointForm extends LitElement {
 		return keys;
 	}
 
-	/** True when the fields in `group` (or the flat top level) carry latitude+longitude+timezone, so a location-search can autofill them. */
+	/** True when the fields in `group` (or the flat top level) carry a latitude+longitude pair, so a location-search can autofill them. Timezone is NOT required here, see {@link LOCATION_PAIR}. */
 	private groupHasLocation(group?: string): boolean {
 		const inGroup = this.fields.filter((f) => f.group === group);
-		return LOCATION_TRIO.every((n) => inGroup.some((f) => f.name === n));
+		return LOCATION_PAIR.every((n) => inGroup.some((f) => f.name === n));
+	}
+
+	/**
+	 * Location groups in field order. Order is load-bearing: when a request carries coordinate
+	 * groups but only ONE unprefixed top-level `timezone`, the FIRST group owns it, because that
+	 * timezone belongs to the primary moment (`generateRelocationChart` has one `timezone` and it is
+	 * the birth timezone). Without an owner both city boxes would write the same key and the second
+	 * pick would silently overwrite the first with the wrong offset.
+	 */
+	private locationGroups(): (string | undefined)[] {
+		return this.groupKeys().filter((g) => this.groupHasLocation(g));
+	}
+
+	/**
+	 * The timezone field a group's city search should fill, or undefined when there is none.
+	 *
+	 * Prefers a timezone inside the group (the nested `person1`/`person2` shape has its own). Falls
+	 * back to an unowned flat `timezone` for the first location group only, which is what makes the
+	 * prefixed shape work without leaving a decimal-hours box for a visitor to guess at.
+	 */
+	private timezoneFieldFor(group?: string): FieldDef | undefined {
+		const own = this.fields.find(
+			(f) => f.group === group && f.name === 'timezone',
+		);
+		if (own) return own;
+		if (this.locationGroups()[0] !== group) return undefined;
+		return this.fields.find(
+			(f) => f.group === undefined && f.name === 'timezone',
+		);
 	}
 
 	/**
@@ -561,9 +599,16 @@ export class RoxyEndpointForm extends LitElement {
 		return this.lang || undefined;
 	}
 
-	/** Location-select handler bound to a group: fills that group's lat/lng/timezone keys (flat top level when group is undefined). */
+	/**
+	 * Location-select handler bound to a group: fills that group's coordinate keys plus whichever
+	 * timezone field it owns.
+	 *
+	 * Keys are LOOKED UP from the model rather than built as `group.name`. That assumption held only
+	 * while every group came from object nesting; a prefixed group stores under the original wire
+	 * name (`birthLatitude`), so constructing `birth.latitude` would write a key the request builder
+	 * never reads and the coordinates would silently stay empty.
+	 */
 	private onLocationFor(group?: string) {
-		const prefix = group ? `${group}.` : '';
 		return (e: Event) => {
 			const detail = (e as CustomEvent).detail as {
 				latitude?: number;
@@ -572,12 +617,16 @@ export class RoxyEndpointForm extends LitElement {
 				utcOffset?: number;
 			};
 			if (!detail) return;
-			this.values = {
-				...this.values,
-				[`${prefix}latitude`]: detail.latitude,
-				[`${prefix}longitude`]: detail.longitude,
-				[`${prefix}timezone`]: detail.timezone ?? detail.utcOffset,
-			};
+			const keyOf = (name: string) =>
+				this.fields.find((f) => f.group === group && f.name === name)?.key;
+			const next: Record<string, unknown> = { ...this.values };
+			const lat = keyOf('latitude');
+			const lon = keyOf('longitude');
+			if (lat) next[lat] = detail.latitude;
+			if (lon) next[lon] = detail.longitude;
+			const tz = this.timezoneFieldFor(group);
+			if (tz) next[tz.key] = detail.timezone ?? detail.utcOffset;
+			this.values = next;
 		};
 	}
 
@@ -848,6 +897,20 @@ export class RoxyEndpointForm extends LitElement {
 		}
 	}
 
+	/**
+	 * The fields this group's city search actually fills, named in the help text.
+	 *
+	 * Not the hardcoded "latitude, longitude, timezone" it used to say: a group does not always own a
+	 * timezone. `generateRelocationChart` has one top-level `timezone` that belongs to the birth
+	 * moment, so the relocation block fills coordinates only, and promising a timezone there would be
+	 * a visible lie on the one form that made this method necessary.
+	 */
+	private locationFillList(group?: string): string {
+		const names = [...LOCATION_PAIR] as string[];
+		if (this.timezoneFieldFor(group)) names.push('timezone');
+		return names.join(', ');
+	}
+
 	private locationBlock(group?: string) {
 		return html`<div class="location-block">
 			<label
@@ -860,10 +923,10 @@ export class RoxyEndpointForm extends LitElement {
 			<roxy-location-search
 				publishable-key=${ifDefined(this.publishableKey)}
 				@roxy-location-select=${this.onLocationFor(group)}
-				placeholder="City of birth"
+				placeholder=${group ? `${humanize(group)} city` : 'City of birth'}
 			></roxy-location-search>
 			<small class="help">
-				Required: latitude, longitude, timezone. Pick a city to autofill.
+				Fills ${this.locationFillList(group)}. Pick a city to autofill.
 			</small>
 		</div>`;
 	}

packages/ui/src/utils/field-schema.ts

@@ -109,6 +109,47 @@ export const TILE_MAX = 12;
 /** The latitude+longitude+timezone trio the form suppresses in favour of a city search. Centralised so the render path and tests agree. */
 export const LOCATION_TRIO = ['latitude', 'longitude', 'timezone'] as const;
 
+/**
+ * The coordinate pair that DEFINES a location group. `timezone` is deliberately absent.
+ *
+ * @remarks
+ * A group qualifies for a city search on latitude+longitude alone, because a timezone is not always
+ * part of the group that owns the coordinates: `generateRelocationChart` carries two coordinate
+ * pairs and exactly ONE top-level `timezone`, which is the BIRTH timezone (relocating does not move
+ * the birth moment), so the relocation pair correctly has no timezone of its own. Requiring all
+ * three would leave that operation rendering raw number inputs, which is the bug this exists to
+ * prevent.
+ */
+export const LOCATION_PAIR = ['latitude', 'longitude'] as const;
+
+/**
+ * Split a flat coordinate property into its group prefix and canonical leaf name, or `null` when the
+ * name is not a prefixed coordinate.
+ *
+ * @remarks
+ * **Two shapes carry two locations in one request and this handles the second one.** Most
+ * multi-location operations nest per person (`person1`/`person2`, `personA`/`personB`), so object
+ * nesting alone already groups them. `generateRelocationChart` is the only operation in the spec
+ * that instead puts both pairs at the TOP level and distinguishes them by a name prefix
+ * (`birthLatitude` / `relocationLatitude`). Keying the grouping off the prefix as well as off the
+ * nesting means both shapes converge on the same group machinery, and a future `partnerLatitude`
+ * needs no code change.
+ *
+ * Matching is deliberately restricted to the coordinate pair. A prefix is NOT harvested from any
+ * other field name, so `birthDate` stays an ordinary field in the flat group and does not invent a
+ * phantom `birth` group with a lone date in it.
+ */
+export function splitCoordinateName(
+	name: string,
+): { group: string; leaf: (typeof LOCATION_PAIR)[number] } | null {
+	const m = name.match(/^(.+?)(Latitude|Longitude)$/);
+	if (!m) return null;
+	return {
+		group: m[1],
+		leaf: m[2].toLowerCase() as (typeof LOCATION_PAIR)[number],
+	};
+}
+
 /** Canonical lowercase zodiac set, derived from {@link SIGNS_ORDER} so sign detection and the glyph map can never disagree. */
 const ZODIAC_LOWER = SIGNS_ORDER.map((s) => s.toLowerCase());
 
@@ -232,8 +273,23 @@ export function buildFormModel(
 					);
 				}
 			} else {
+				// A prefixed coordinate joins a group named after its prefix and reports the
+				// canonical leaf name, so the trio logic and the city search match it unchanged.
+				// `key` stays the ORIGINAL property name because it is the storage and wire
+				// identity: rewriting it to `birth.latitude` would serialise a body the API
+				// rejects.
+				const coord = splitCoordinateName(name);
 				fields.push(
-					toField(name, resolved, { key: name, required: required.has(name) }),
+					coord
+						? toField(coord.leaf, resolved, {
+								key: name,
+								group: coord.group,
+								required: required.has(name),
+							})
+						: toField(name, resolved, {
+								key: name,
+								required: required.has(name),
+							}),
 				);
 			}
 		}

packages/ui/tests/e2e/components.spec.ts packages/ui/tests/e2e/components.e2e.tspackages/ui/tests/e2e/components.spec.ts renamed to packages/ui/tests/e2e/components.e2e.ts

@@ -19,6 +19,11 @@ const FORMS = [
 	{ id: 'e2e-tarot-draw', endpoint: 'tarot/draw', method: 'POST' },
 	{ id: 'e2e-natal', endpoint: 'astrology/natal-chart', method: 'POST' },
 	{ id: 'e2e-synastry', endpoint: 'astrology/synastry', method: 'POST' },
+	{
+		id: 'e2e-relocation',
+		endpoint: 'astrology/relocation-chart',
+		method: 'POST',
+	},
 ];
 
 async function mountForms(page: Page): Promise<void> {
@@ -45,7 +50,10 @@ async function mountForms(page: Page): Promise<void> {
 		const sy = document.getElementById('e2e-synastry');
 		return (
 			!!ho?.shadowRoot?.querySelector('[role="radiogroup"]') &&
-			!!sy?.shadowRoot?.querySelector('fieldset.person-group')
+			!!sy?.shadowRoot?.querySelector('fieldset.person-group') &&
+			!!document
+				.getElementById('e2e-relocation')
+				?.shadowRoot?.querySelector('roxy-location-search')
 		);
 	});
 }
@@ -214,3 +222,40 @@ test.describe('practitioner theme preset', () => {
 		await scanThemed();
 	});
 });
+
+/**
+ * The two-locations-in-one-request case, rendered rather than modelled.
+ *
+ * `generateRelocationChart` is the only operation in the spec that carries two coordinate pairs at
+ * the TOP level, told apart by a name prefix (`birthLatitude` / `relocationLatitude`) instead of by
+ * per-person object nesting. Grouping used to come from nesting alone, so this form fell through to
+ * four raw number inputs and a decimal-hours timezone box, which no visitor of an embedder's site
+ * can answer. The unit tests assert the form MODEL; this asserts what a browser actually paints,
+ * which is the only claim that matters to the person filling it in.
+ */
+test.describe('two-location form', () => {
+	test('relocation renders two city searches and no raw coordinate inputs', async ({
+		page,
+	}) => {
+		await mountForms(page);
+
+		const pickers = page.locator('#e2e-relocation roxy-location-search');
+		await expect(pickers).toHaveCount(2);
+
+		// Each block is labelled from its group, so the two are tellable apart.
+		const labels = await page
+			.locator('#e2e-relocation .location-block label')
+			.allInnerTexts();
+		expect(labels.join(' | ').toLowerCase()).toContain('birth');
+		expect(labels.join(' | ').toLowerCase()).toContain('relocation');
+
+		// No coordinate or timezone field may survive as a typed input.
+		const names = await page
+			.locator('#e2e-relocation input')
+			.evaluateAll((els) =>
+				els.map((e) => (e as HTMLInputElement).name || e.id || ''),
+			);
+		const raw = names.filter((n) => /latitude|longitude|timezone/i.test(n));
+		expect(raw, `raw inputs still rendered: ${raw.join(', ')}`).toEqual([]);
+	});
+});