@mailwoman/resolver-wof-sqlite 9.3.0 → 9.4.0

package/lib/address/point-interpolation.ts

@@ -33,7 +33,7 @@
  *   Standalone like the segment tier — core wiring rides the Phase 2 ordered `spatialTiers` list.
  */
 
-import type { InterpolationLookup } from "@mailwoman/resolver"
+import type { InterpolationLookup } from "@mailwoman/core/resolver"
 import { haversineKm } from "@mailwoman/spatial"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 
@@ -41,7 +41,6 @@ import type { AddressPointDatabase } from "#address/point-schema"
 import type { InterpolatedHit, InterpolationQuery, StreetInterpolator } from "#interpolation"
 import { hasTable, prepareAll, type PreparedAll } from "#sqlite-utils"
 import { canonicalizeRouteKey, type RouteKey, streetKeyVariants } from "#street/normalize"
-
 /**
  * Extrapolation cap for a single-sided bracket: at most one pair-span beyond the nearest known point (`t = 2`). Past
  * it, the two-point line carries no evidence about the query number.

package/lib/address/point.ts

@@ -15,13 +15,15 @@
  *   scopes missed). Multiple hits return the first by rowid — unit siblings share the building coord.
  */
 
-import type { AddressPointHit, AddressPointLookup } from "@mailwoman/resolver"
+import type { AddressPointHit, AddressPointLookup } from "@mailwoman/core/resolver"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 
 import type { AddressPointDatabase, AddressPointTable } from "#address/point-schema"
 import { hasTable, prepareGet, type PreparedGet } from "#sqlite-utils"
 import {
+	normalizeHouseNumberForKey,
 	normalizeLocalityForKey,
+	normalizeLocalityForKeyLocale,
 	type NameKey,
 	type StreetKey,
 	streetKeyVariants,
@@ -53,6 +55,13 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 		| PreparedGet<[postcode: string, locality: NameKey, street: StreetKey, number: string], AddressPointRow>
 		| undefined
 	readonly #byLocality: PreparedGet<[locality: NameKey, street: StreetKey, number: string], AddressPointRow> | undefined
+	/**
+	 * The scope key matched by its TAIL — a `zh` query that names the 鄉鎮市區 without its 縣市. Narrowed by the (street,
+	 * number) index first, so the LIKE walks the handful of rows that share the pair.
+	 */
+	readonly #byLocalityTail:
+		| PreparedGet<[street: StreetKey, number: string, tailPattern: string], AddressPointRow>
+		| undefined
 	readonly #byBbox:
 		| PreparedGet<
 				[street: StreetKey, number: string, minLat: number, maxLat: number, minLon: number, maxLon: number],
@@ -102,6 +111,12 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 				`SELECT ${SELECT_COLS} FROM address_point
 				 WHERE street_norm = ? AND number = ? AND lat BETWEEN ? AND ? AND lon BETWEEN ? AND ? LIMIT 1`
 			)
+
+			this.#byLocalityTail = prepareGet(
+				this.#db,
+				`SELECT ${SELECT_COLS} FROM address_point
+				 WHERE street_norm = ? AND number = ? AND locality_norm LIKE ? LIMIT 1`
+			)
 		}
 	}
 
@@ -110,20 +125,33 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 		number: string
 		postcode?: string
 		locality?: string
+		region?: string
+		subregion?: string
 		bbox?: { minLat: number; maxLat: number; minLon: number; maxLon: number }
 	}): AddressPointHit | null {
 		if (!this.#byPostcode || !this.#byLocality || !this.#byBbox) return null
-		const number = query.number.trim().toLowerCase()
+		const number = normalizeHouseNumberForKey(query.number, this.#locale)
 
 		if (!number) return null
 
+		// A `zh` extract scopes a point by 縣市 + 鄉鎮市區, the pair the parse tags `region` + `subregion`; the Taiwanese
+		// register carries no postcode and the parse no `locality`. The pair becomes the locality key here, on the
+		// reader that was built with the same fold, and a Latin extract never sees the two fields. A line that names
+		// only the 鄉鎮市區 (`中和區中興街281號`, 14.7% of the TW board) matches the stored pair by its tail instead.
+		const scoped =
+			this.#locale === "zh" && !query.locality && query.subregion
+				? query.region
+					? { ...query, locality: `${query.region}${query.subregion}` }
+					: { ...query, localityTail: normalizeLocalityForKeyLocale(query.subregion, "zh") }
+				: query
+
 		// Key-variant ladder (see `streetKeyVariants`): the literal key first, then the doubled-type
 		// collapse and the saint↔st register swap — each variant runs the FULL number ladder below, and
 		// the first variant to answer wins, so an attested literal key is never second-guessed.
 		let row: AddressPointRow | undefined
 
 		for (const streetNorm of streetKeyVariants(query.street, streetLocaleForSurface(query.street, this.#locale))) {
-			row = this.#findForKey(streetNorm, number, query)
+			row = this.#findForKey(streetNorm, number, scoped)
 
 			if (row) break
 		}
@@ -152,6 +180,7 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 			number: string
 			postcode?: string
 			locality?: string
+			localityTail?: NameKey
 			bbox?: { minLat: number; maxLat: number; minLon: number; maxLon: number }
 		}
 	) {
@@ -186,6 +215,19 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 			}
 		}
 
+		// Sub-number fallback for the Taiwanese register: `14之12` is building 12 off number 14, `30附40` an attached
+		// number, stored as number `14` / `30` with the rest in `unit`. A query that kept the pair on the number span
+		// falls to the base number — the same adjacent-parcel approximation the letter-suffix rung makes, priced the
+		// same: on the 2,000-row served read the rows answered this way sit a median 256 m and at most 1.0 km from the
+		// building.
+		if (!row && this.#locale === "zh") {
+			const base = /^(\d+)(?:[之附]\d+)+$/u.exec(number)?.[1]
+
+			if (base) {
+				row = this.#probe(streetNorm, base, query)
+			}
+		}
+
 		return row
 	}
 
@@ -199,6 +241,7 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 		query: {
 			postcode?: string
 			locality?: string
+			localityTail?: NameKey
 			bbox?: { minLat: number; maxLat: number; minLon: number; maxLon: number }
 		}
 	): AddressPointRow | undefined {
@@ -226,6 +269,11 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 			row = this.#byLocality!(this.#localityKey(query.locality), streetNorm, number)
 		}
 
+		if (!row && query.localityTail && this.#byLocalityTail) {
+			// A Han key carries no `%` or `_`, so the tail is a literal suffix pattern.
+			row = this.#byLocalityTail(streetNorm, number, `%${query.localityTail}`)
+		}
+
 		// Bbox fall-through (#247): the point carries no postcode/locality of its own, but its coordinate falls
 		// inside the resolved locality's box. Only reached when the scoped probes missed AND a bbox was supplied.
 		if (!row && query.bbox) {
@@ -248,9 +296,9 @@ export class AddressPointSqliteLookup<DB extends AddressPointDatabase = AddressP
 	 * 13e Arrondissement" and "Paris" both hit; a no-op for every other locale.
 	 */
 	#localityKey(locality: string): NameKey {
-		return this.#locale === "fr"
-			? stripArrondissement(normalizeLocalityForKey(locality))
-			: normalizeLocalityForKey(locality)
+		if (this.#locale === "fr") return stripArrondissement(normalizeLocalityForKey(locality))
+
+		return normalizeLocalityForKeyLocale(locality, this.#locale)
 	}
 
 	/**

package/lib/ancestry/index.ts

@@ -15,10 +15,9 @@
  *   geocoding always does).
  */
 
+import { allRows } from "@mailwoman/core/utils"
 import type { DatabaseClient } from "@mailwoman/sqlite/client"
 
-import { allRows } from "#sqlite-utils"
-
 /**
  * WOF placetype → containment depth, coarsest = 1. Higher = finer. Placetypes we never resolve (continent, empire, …)
  * map to 0 and sort last. NOT the same table as the FST's `PLACETYPE_ORDER` (fst-serialize.ts) — that one is a

package/lib/build-candidate.ts

@@ -97,9 +97,11 @@ export interface BuildCandidateOptions {
 	/**
 	 * Optional LOCALITY extracts (`spr` rows with `placetype='locality'` + real coords, e.g. localities-nz-linz.db — the
 	 * #1564 NZ suburb tier) — folded through the same extract loop as the postcode extracts, staged as `locality`
-	 * candidate rows with no region scope and UNMEASURED population (`neg_rank 0`: a extract row ranks behind any
-	 * populated namesake and wins only where its key is the answer). Each extract's `names` table folds as aliases,
-	 * `is_primary = 0`, same as the delivery-city pass.
+	 * candidate rows with UNMEASURED population (`neg_rank 0`: a extract row ranks behind any populated namesake and wins
+	 * only where its key is the answer). Each extract's `names` table folds as aliases, `is_primary = 0`, same as the
+	 * delivery-city pass. An extract whose `ancestors` table names an admin region for a row gives that row the region's
+	 * scope (`region_id`) plus closure rows for the region and the region's own chain above it; an extract without one
+	 * stays unscoped, as before.
 	 */
 	localities?: string[]
 	/**
@@ -520,6 +522,8 @@ export async function buildCandidateTable(opts: BuildCandidateOptions): Promise<
 	}
 
 	let nLocality = 0
+	let nLocalityScoped = 0
+	let nLocalityAncestor = 0
 
 	for (const locDB of opts.localities ?? []) {
 		const folded = foldExtract({
@@ -529,14 +533,23 @@ export async function buildCandidateTable(opts: BuildCandidateOptions): Promise<
 			ccID,
 			ptID,
 			stageRow,
+			attrs,
 			progress,
 		})
 
 		nLocality += folded.primaries
+		nLocalityScoped += folded.scoped
+		nLocalityAncestor += folded.ancestorRows
 	}
 
 	if (nLocality > 0) {
-		progress("localities", `${nLocality.toLocaleString()} extract localities folded`)
+		progress(
+			"localities",
+			`${nLocality.toLocaleString()} extract localities folded` +
+				(nLocalityScoped
+					? `; ${nLocalityScoped.toLocaleString()} carry a region scope (${nLocalityAncestor.toLocaleString()} closure rows)`
+					: "")
+		)
 	}
 
 	// --- code dictionaries: typed batch inserts via kdb (a few hundred rows — Kysely is clean here) ---
@@ -610,8 +623,8 @@ export async function buildCandidateTable(opts: BuildCandidateOptions): Promise<
 		abbrevs: nAbbr,
 		postcodes: nPostcode,
 		postcodeAliases: nPostcodeAlias,
-		ancestorRows: sidecar.ancestorRows,
-		ancestorPlaces: sidecar.ancestorPlaces,
+		ancestorRows: sidecar.ancestorRows + nLocalityAncestor,
+		ancestorPlaces: sidecar.ancestorPlaces + nLocalityScoped,
 		intervalPlaces: sidecar.intervalPlaces,
 		...roles,
 		...(importance ? { importanceScored: importance.matched, importanceFiltered: importance.refused } : {}),

package/lib/candidate/extract-fold.ts

@@ -8,17 +8,51 @@
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 import { tableExists } from "@mailwoman/sqlite/introspection"
 
+import { CANDIDATE_ANCESTOR_COLUMNS, CANDIDATE_ANCESTOR_TABLE } from "#candidate-ancestors-schema"
 import type { CandidateDatabase } from "#candidate-schema"
 import type { PlaceAttrs, StageRow } from "#candidate/place-attrs"
 import type { WOFDatabase } from "#schema"
 import { normalizeLocalityForKey } from "#street/normalize"
 
+/**
+ * The extract's own region-tier ancestry, when it carries any: extract id → the admin region's id. A locality extract
+ * derived from a national register (the Taiwanese 鄉鎮市區 from the civil-affairs address points) knows which 縣市 each row
+ * belongs to, and writes that as an `ancestors` row against the admin region's WOF id. Without it a folded row has no
+ * region scope, so a `parentID`-scoped probe misses it and the cascade widens to whatever namesake carries the key.
+ *
+ * Only a region the admin build staged (`attrs`) counts: an id the admin does not know cannot be denormalized into a
+ * closure row, and a scope nothing can match would be a silent zero rather than an absence.
+ */
+function extractRegionAncestry(pc: DatabaseClient<WOFDatabase>, attrs: Map<number, PlaceAttrs>): Map<number, number> {
+	const regionOf = new Map<number, number>()
+
+	if (!tableExists(pc, "ancestors")) {
+		return regionOf
+	}
+
+	for (const r of pc
+		.prepare(
+			"SELECT id, MIN(ancestor_id) AS ancestor_id FROM ancestors WHERE ancestor_placetype = 'region' GROUP BY id"
+		)
+		.iterate()) {
+		const rid = Number(r.ancestor_id)
+
+		if (attrs.has(rid)) {
+			regionOf.set(Number(r.id), rid)
+		}
+	}
+
+	return regionOf
+}
+
 /**
  * Fold ONE extract (`spr` rows at `extractPlacetype` carrying real coordinates) in, then pass 4b: the alias names
  * hanging off that same extract's `names` table.
  *
  * Self-contained by construction — it shares only the staging statement and the code dictionaries with the admin passes
- * above it, and nothing downstream reads anything it produces except the two counters it returns.
+ * above it, and nothing downstream reads anything it produces except the counters it returns. The one thing it writes
+ * beyond the staging table is a depth-1 closure row for a row whose extract names its region (see
+ * {@link extractRegionAncestry}), so the pick's stamped ancestors agree with the scope it was found under.
  */
 export function foldExtract(ctx: {
 	/**
@@ -30,8 +64,13 @@ export function foldExtract(ctx: {
 	ccID: (code: string | null) => number
 	ptID: (pt: string | null) => number
 	stageRow: StageRow
+	/**
+	 * The admin places pass 1 staged — what an extract's region ancestry is resolved against. Absent, no extract row
+	 * takes a region scope (the postcode extracts, which carry none).
+	 */
+	attrs?: Map<number, PlaceAttrs>
 	progress: (phase: string, message: string) => void
-}): { primaries: number; aliases: number } {
+}): { primaries: number; aliases: number; scoped: number; ancestorRows: number } {
 	const { out, extractPath, extractPlacetype, ccID, ptID, stageRow, progress } = ctx
 
 	progress(extractPlacetype === "postalcode" ? "postcodes" : "localities", `reading ${extractPath}`)
@@ -41,8 +80,24 @@ export function foldExtract(ctx: {
 	// Per-extract, not the admin `attrs` map: pass 1 only ever sees the admin DB, so the alias pass
 	// below has nothing to join against unless this primary loop records what it staged.
 	const pcAttrs = new Map<number, PlaceAttrs>()
+	const regionOf = ctx.attrs ? extractRegionAncestry(pc, ctx.attrs) : new Map<number, number>()
+
+	const insAncestor = out.prepare(
+		`INSERT OR IGNORE INTO ${CANDIDATE_ANCESTOR_TABLE} VALUES (${CANDIDATE_ANCESTOR_COLUMNS.map(() => "?").join(", ")})`
+	)
+
+	// The region's own closure rows, as the sidecar pass wrote them. A scoped row inherits the whole chain above its
+	// region — macroregion, country — not the region alone: the widened-scope refusal reads a pick's stamped ancestors
+	// against the parent the walk resolved, and a 縣市 that resolves to its macroregion record (`桃園市`, which WOF names
+	// only at that tier) would otherwise contradict a lineage that stops at the region.
+	const regionChain = out.prepare(
+		`SELECT depth, parent_spr_id, parent_placetype_id, parent_name, parent_name_key FROM ${CANDIDATE_ANCESTOR_TABLE} WHERE spr_id = ? ORDER BY depth`
+	)
+
 	let primaries = 0
 	let aliases = 0
+	let scoped = 0
+	let ancestorRows = 0
 
 	out.exec("BEGIN")
 
@@ -60,12 +115,15 @@ export function foldExtract(ctx: {
 
 		const lat = r.latitude as number
 		const lon = r.longitude as number
+		const id = Number(r.id)
+		const rid = regionOf.get(id) ?? 0
 
-		// region_id 0 (a postcode is unique by name+country — no same-name disambiguation); neg_rank 0
-		// (no population). bbox = the postcode's own min/max (falls back to the centroid point).
+		// region_id from the extract's own ancestry when it names one, else 0 (a postcode is unique by
+		// name+country — no same-name disambiguation); neg_rank 0 (no population). bbox = the row's own
+		// min/max (falls back to the centroid point).
 		const a: PlaceAttrs = {
 			cid: ccID(r.country as string | null),
-			rid: 0,
+			rid,
 			ptid: pcPtid,
 			name,
 			lat,
@@ -83,8 +141,31 @@ export function foldExtract(ctx: {
 			imp: null,
 		}
 
-		pcAttrs.set(Number(r.id), a)
-		stageRow(key, a, Number(r.id), 1)
+		pcAttrs.set(id, a)
+		stageRow(key, a, id, 1)
+
+		if (rid !== 0) {
+			const region = ctx.attrs!.get(rid)!
+
+			insAncestor.run(id, 1, rid, region.ptid, region.name, region.pkey)
+
+			scoped++
+
+			ancestorRows++
+
+			for (const link of regionChain.iterate(rid)) {
+				insAncestor.run(
+					id,
+					Number(link.depth) + 1,
+					Number(link.parent_spr_id),
+					Number(link.parent_placetype_id),
+					String(link.parent_name ?? ""),
+					String(link.parent_name_key ?? "")
+				)
+
+				ancestorRows++
+			}
+		}
 
 		primaries++
 	}
@@ -134,5 +215,5 @@ export function foldExtract(ctx: {
 		progress("postcode-aliases", `${extractPath} has no \`names\` table — no delivery-city aliases to fold`)
 	}
 
-	return { primaries, aliases }
+	return { primaries, aliases, scoped, ancestorRows }
 }

package/lib/candidate/own-name.ts

@@ -127,6 +127,7 @@ export function romanizeNameKey(key: string): string | null {
  * Edit similarity between a holder's primary name key and one of its alias keys, both romanized and
  * abbreviation-expanded. `null` when either side's script is uncovered.
  */
+// repo-health-ignore export-name-affix -- romanizes and expands abbreviations first; `nameSimilarity` compares as given.
 export function ownNameSimilarity(primaryKey: string, aliasKey: string): number | null {
 	const primary = romanizeNameKey(primaryKey)
 	const alias = romanizeNameKey(aliasKey)

package/lib/candidate-lookup.ts

@@ -4,10 +4,10 @@
  * @author Teffen Ellis, et al.
  *
  *   Node-side {@link PlaceLookup} over the byte-range CANDIDATE table (`build-candidate.ts`) — the
- *   SAME gazetteer the browser demo resolves against ({@link WOFCandidateTableLookup} in
- *   `docs/src/shared/httpvfs-resolver.ts`), but reading a LOCAL `candidate.db` via `node:sqlite`
- *   instead of sql.js-httpvfs. This is what makes the server/CLI resolver match the demo: one
- *   lookup surface, one artifact, one ranking.
+ *   SAME gazetteer the browser runtime resolves against ({@link WOFCandidateTableLookup} in
+ *   `packages/resolver-wof-wasm/lib/httpvfs/resolver.ts`), but reading a LOCAL `candidate.db` via
+ *   `node:sqlite` instead of sql.js-httpvfs. This is what makes the server/CLI resolver match the
+ *   browser: one lookup surface, one artifact, one ranking.
  *
  *   The query is a single contiguous probe on the `WITHOUT ROWID` B-tree keyed `(name_key,
  *   country_id, region_id, placetype_id, neg_rank, spr_id)`. `name_key` is the SHARED
@@ -23,13 +23,15 @@
  *   `bbox` field on {@link FindPlaceQuery}).
  */
 
-import { jaroWinkler, levenshteinSimilarity } from "@mailwoman/match/comparators"
 import {
 	expandPlacetypeFilter,
-	partitionByContainment,
 	type Ancestor,
 	type GazetteerArtifactCoverage,
-} from "@mailwoman/resolver"
+	referentialFromPopulation,
+} from "@mailwoman/core/resolver"
+import { allRows } from "@mailwoman/core/utils"
+import { jaroWinkler, levenshteinSimilarity } from "@mailwoman/match/comparators"
+import { partitionByContainment } from "@mailwoman/resolver"
 import { haversineKm } from "@mailwoman/spatial"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 import type { PathBuilderLike } from "path-ts"
@@ -44,12 +46,11 @@ import {
 import { CANDIDATE_FTS_TABLE } from "#candidate-fts"
 import type { CandidateDatabase, CandidateTable, CountryCodeTable, PlacetypeCodeTable } from "#candidate-schema"
 import { readGazetteerCoverageManifest } from "#coverage-manifest-schema"
-import { referentialFromPopulation } from "#place-importance-schema"
 import { POSTAL_CITY_CANDIDATE_TABLE, type PostalCityCandidateTable } from "#postal/city-candidate-schema"
 import { rankByPrimaryPreference, type RankedRow, RERANK_FETCH } from "#primary-preference"
 import { applyProximityRerank } from "#proximity-rerank"
 import { REGION_CLASS_PLACETYPES, regionQualifierProbeKeys } from "#region-keys"
-import { allRows, hasColumn, hasTable } from "#sqlite-utils"
+import { hasColumn, hasTable } from "#sqlite-utils"
 import { type NameKey, normalizeLocalityForKey, stripLocalityQualifier } from "#street/normalize"
 import type { FindPlaceQuery, PlaceCandidate, PlaceLookup, WOFPlacetype } from "#types"
 

package/lib/candidate-schema.ts

@@ -5,7 +5,7 @@
  *
  *   Typed schema for the byte-range CANDIDATE gazetteer (`candidate.db`) — the single source of truth
  *   for the columns shared by the BUILDER ({@link buildCandidateTable}) and the READERS (the Node
- *   {@link WOFCandidateTableLookup} + the browser `httpvfs-resolver.ts`). Before this module each
+ *   {@link WOFCandidateTableLookup} + the browser `@mailwoman/resolver-wof-wasm/httpvfs/resolver`). Before this module each
  *   side hand-wrote the column list; a rename in one place broke the other at runtime. Now the
  *   contract is a Kysely `Database` interface (`new DatabaseClient<CandidateDatabase>(...)` for
  *   typed inserts) plus the table DDL as strings — so a column change is a compile error on every

package/lib/candidate-scoring.ts

@@ -7,12 +7,12 @@
  *   ordered — the weighted-sum score and the exact-match tiering that ranks over it.
  */
 
+import { compareReferential, referentialFromPopulation } from "@mailwoman/core/resolver"
 import { haversineKm } from "@mailwoman/spatial"
 import type { DatabaseClient } from "@mailwoman/sqlite/client"
 
 import { exactMatchIDs, officialNameIDs } from "#exact-match"
 import { foldQueryText } from "#fts/index"
-import { compareReferential, referentialFromPopulation } from "#place-importance-schema"
 import { populationBoostTerm, type RankingWeights } from "#ranking-weights"
 import type { RawSearchRow } from "#search-fetch"
 import type { FindPlaceQuery, PlaceCandidate, WOFPlacetype } from "#types"

package/lib/coincident-roles.ts

@@ -38,14 +38,13 @@
  *   be wired as a post-step of the main `scripts/build-unified-wof.ts`.
  */
 
-import type { CoincidentLocality } from "@mailwoman/resolver"
+import type { CoincidentLocality } from "@mailwoman/core/resolver"
+import { allRows } from "@mailwoman/core/utils"
 import { haversineKm } from "@mailwoman/spatial"
 import type { DatabaseClient } from "@mailwoman/sqlite/client"
 import { tableExists } from "@mailwoman/sqlite/introspection"
 
 import type { WOFDatabase } from "#schema"
-import { allRows } from "#sqlite-utils"
-
 /**
  * Table of places that hold more than one admin role — a locality that is also its county seat. Written by the
  * gazetteer build, read by the resolver when a coincident locality has to be chosen.

package/lib/coverage-manifest-schema.ts

@@ -29,10 +29,11 @@ import {
 	type CountryCoverageFact,
 	type GazetteerArtifactCoverage,
 } from "@mailwoman/core/resolver"
+import { allRows } from "@mailwoman/core/utils"
 import type { DatabaseClient } from "@mailwoman/sqlite/client"
 import { sql, type Kysely } from "kysely"
 
-import { allRows, hasTable } from "#sqlite-utils"
+import { hasTable } from "#sqlite-utils"
 
 /**
  * One country's hard-filter coverage measurement — the storage form of {@link CountryCoverageFact}.

package/lib/fst/builder.ts

@@ -11,6 +11,7 @@
  *   PlaceEntry at terminals → return FSTMatcher.
  */
 
+import { allRows, getRow } from "@mailwoman/core/utils"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 import { resolvePath } from "path-ts"
 
@@ -20,7 +21,6 @@ import { FSTMatcher, normalizeTokens } from "#fst/matcher"
 import type { BuildFSTOpts, BuildFSTResult, FSTProvenance, PlaceEntry, PlacetypeID } from "#fst/types"
 import { loadImportanceSplit } from "#place-importance-schema"
 import type { WOFDatabase } from "#schema"
-import { allRows, getRow } from "#sqlite-utils"
 
 const DEFAULT_PLACETYPES: PlacetypeID[] = [
 	"country",

package/lib/fst/freshness.ts

@@ -146,7 +146,6 @@ export async function peekFSTStampFields(path: string): Promise<FSTStampFields |
  * Re-exported from `@mailwoman/core/hash`. This package's own test imports it from here, and the sidecar convention
  * below is what it is for.
  */
-export { md5File } from "@mailwoman/core/hash"
 
 /**
  * The source identity an FST build should stamp, or a check should compare against.

package/lib/interpolation.ts

@@ -27,7 +27,7 @@
  */
 
 import { parseJSONStrict } from "@mailwoman/core/json"
-import type { InterpolationLookup } from "@mailwoman/resolver"
+import type { InterpolationLookup } from "@mailwoman/core/resolver"
 import { clampFraction, haversineKm, pointAlong } from "@mailwoman/spatial"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 

package/lib/lookup.ts

@@ -10,7 +10,8 @@
  *   See `docs/plan/phases/PHASE_4_2_wof_sqlite.md` for the design rationale.
  */
 
-import { expandPlacetypeFilter, type Ancestor, type CoincidentLocality } from "@mailwoman/resolver"
+import { expandPlacetypeFilter, type Ancestor, type CoincidentLocality } from "@mailwoman/core/resolver"
+import { allRows } from "@mailwoman/core/utils"
 import { haversineKm } from "@mailwoman/spatial"
 import type { SQLInputValue } from "@mailwoman/sqlite/client"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
@@ -51,7 +52,6 @@ import { DEFAULT_WEIGHTS, populationScaleTerm, type RankingWeights } from "#rank
 import type { WOFDatabase } from "#schema"
 import { fetchSearchRows, type RawSearchRow } from "#search-fetch"
 import { SqliteConventionSource } from "#sqlite-convention-source"
-import { allRows } from "#sqlite-utils"
 import type { FindPlaceQuery, PlaceCandidate, PlaceLookup, WOFPlacetype } from "#types"
 
 export interface WOFSQLitePlaceLookupOpts {

package/lib/place-importance-schema.ts

@@ -32,11 +32,10 @@
  */
 
 import { referentialFromPopulation } from "@mailwoman/core/resolver"
+import { allRows } from "@mailwoman/core/utils"
 import type { DatabaseClient } from "@mailwoman/sqlite/client"
 import type { Kysely } from "kysely"
 
-import { allRows } from "#sqlite-utils"
-
 //#region Schema
 
 /**
@@ -106,13 +105,6 @@ export async function createPlaceImportanceTable(db: Kysely<PlaceImportanceDatab
  * (backend-agnostic — it cannot import this package) reads the same number. Re-exported HERE so the schema module stays
  * the one-stop read for the table: the column and the function that fills it are one hop apart.
  */
-export {
-	compareReferential,
-	REFERENTIAL_LOG2_SCALE,
-	REFERENTIAL_POPULATION_DIVISOR,
-	REFERENTIAL_SATURATION_POPULATION,
-	referentialFromPopulation,
-} from "@mailwoman/core/resolver"
 
 //#endregion
 

package/lib/poi/lookup.ts

@@ -25,13 +25,12 @@
  *   it).
  */
 
+import { allRows } from "@mailwoman/core/utils"
 import { haversineKm, shortCellToInt, type H3Cell } from "@mailwoman/spatial"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 import { gridDisk, latLngToCell } from "h3-js"
 
 import type { POICategoryCodeTable, POIDatabase, POITable } from "#poi/schema"
-import { allRows } from "#sqlite-utils"
-
 /**
  * Resolution the `poi` table's `h3_cell` column is keyed at — matches the builder (spec §3.4).
  */

package/lib/primary-preference.ts

@@ -5,8 +5,8 @@
  *
  *   Bounded cross-country PRIMARY-NAME preference over a population-ordered candidate row set — the
  *   `is_primary` ranking signal, PURE and platform-free so the Node candidate lookup
- *   (`candidate-lookup.ts`) and the browser twin (`docs/src/shared/httpvfs-resolver.ts`) rank with the
- *   SAME function rather than two copies that drift (the #861 server↔demo parity contract).
+ *   (`candidate-lookup.ts`) and the browser twin (`packages/resolver-wof-wasm/lib/httpvfs/resolver.ts`) rank with
+ *   the SAME function rather than two copies that drift (the #861 server↔browser parity contract).
  *
  *   Only type imports and arithmetic live here: anything with a `node:` import stays out.
  */
@@ -207,17 +207,27 @@ export function rankByPrimaryPreference<R extends PrimaryPreferenceRow>(
 			? 1
 			: 0
 
+	// 1 for a PRIMARY-name row whose prominence is unmeasured (population 0), 0 for everything else. Two unmeasured
+	// rows tie on `neg_rank`, and that tie used to fall through to scan order — the B-tree's `spr_id`, which is no
+	// evidence about either place. A row that IS named X ranks ahead of one merely also-known-as X when nothing else
+	// separates them: Taiwan's 溪州鄉 township row (its own name, unmeasured) over the village 溪洲 30 km away that
+	// carries `溪州鄉` as an alias (unmeasured), which the lower WOF id had been winning. Populated ties are untouched —
+	// a populated alias ("NYC") never reaches this term, and two populated rows keep the order they had.
+	const unmeasuredPrimary = (r: R): number =>
+		r.is_primary === 1 && typeof r.population === "number" && r.population === 0 ? 1 : 0
+
 	return (
 		rows
 			.map((r, i) => ({ row: annotate(r), i }))
-			// Effective rank ASC; ties keep population order, then the seat preference DESC, then original
-			// index (stable).
+			// Effective rank ASC; ties keep population order, then the seat preference DESC, then the primary name
+			// among unmeasured rows, then original index (stable).
 			// oxlint-disable-next-line unicorn/no-array-sort -- sorts a freshly-built array; toSorted would double-allocate on a hot path
 			.sort(
 				(a, b) =>
 					a.row.effectiveNegRank - b.row.effectiveNegRank ||
 					a.row.neg_rank - b.row.neg_rank ||
 					seatPreference(b.row) - seatPreference(a.row) ||
+					unmeasuredPrimary(b.row) - unmeasuredPrimary(a.row) ||
 					a.i - b.i
 			)
 			.slice(0, limit)

package/lib/reverse.ts

@@ -29,6 +29,7 @@
  */
 
 import { tryParsingJSON } from "@mailwoman/core/json"
+import { allRows } from "@mailwoman/core/utils"
 import { bboxAround, geometryContains, haversineKm, type ParsedGeometry } from "@mailwoman/spatial"
 import { DatabaseClient } from "@mailwoman/sqlite/client"
 import { tableExists } from "@mailwoman/sqlite/introspection"
@@ -36,9 +37,7 @@ import { tableExists } from "@mailwoman/sqlite/introspection"
 import { ancestorLineage, placetypeDepth } from "#ancestry/index"
 import { PLACE_BBOX_TABLE } from "#fts/index"
 import type { WOFDatabase } from "#schema"
-import { allRows } from "#sqlite-utils"
 import type { PlaceCandidate, WOFPlacetype } from "#types"
-
 /**
  * Largest absolute latitude in WGS-84 degrees.
  */