Tracking reads, creates and deletes still use v1 where 5.2.1 already serves v2

[hokiepokedad2]

Only the edit path uses /api/v2. Everything else the tracking proxy does is still v1, even though 5.2.1 — the version running everywhere — already serves a v2 equivalent for five of the six calls.

PoracleTrackingProxy	line	v2 equivalent, live on 5.2.1
GET /api/tracking/{type}/{id}	72	GET /v2/humans/{id}/tracking/{type}
POST /api/tracking/{type}/{id}?silent=true	93	POST /v2/humans/{id}/tracking/{type}
DELETE .../byUid/{uid}?silent=true	174	DELETE /v2/.../tracking/{type}/{uid}
POST .../delete?silent=true	195	DELETE /v2/.../tracking/{type}?uid=a,b
GET /api/tracking/all/{id}	208	GET /v2/humans/{id}/tracking
GET /api/tracking/allProfiles/{id}	220	none

PoracleHumanProxy has the same gap in miniature: start and stop are still v1 while enable and disable already try v2.

This is wider than it looks

The v2 read shape is not the v1 read shape, and 26 files consume the v1 one. Three differences, all load-bearing:

Wildcards come back as null. v1 returns the stored sentinel ("size": -1, "rarity": -1, "costume": 9000); v2 returns null and expects omission on the way back. Anything comparing a read against a stored value — TrackingUpdateReconciler, TrackingFieldPreserver, CleaningService's fetch-mutate-POST, QuickPickService — is comparing different things depending on which surface answered.

Enums are strings. team: 4 becomes team: "any", gender and rsvp_changes likewise. TrackingV2Translator already has the tables for the write direction; the read direction has nothing.

The create response is a different document. v1 answers {"newUids":[7],"alreadyPresent":0,"updates":1,"insert":0} and TrackingCreateResult parses exactly that. v2 answers {"created":[{…,"uid":36535}],"updated":[],"unchanged":[]} — richer, and it names the rules rather than counting them, which would let BulkUidRemap stop pairing on content.

Do #227 first

POST /v2/…/tracking/pokemon inherits v2's validation, which is the problem #835 solved for edits and which is unsolved for creates. pokemon_id is declared required, minimum 1, so every !track everything rule becomes uncreatable — 653 of them exist here. Moving creates before jfberry/PoracleNG#227 lands would break a feature that works today.

Reads and deletes have no such dependency and can go first.

Suggested order

1. Deletes. Smallest surface, no response shape to reinterpret, and the v2 bulk form takes ?uid=a,b,c which is what we already build.
2. Reads, behind the same per-server capability check the write path uses, with one normaliser turning a v2 rule back into the v1 shape the services expect. Normalising at the proxy boundary keeps the change to one file instead of twenty-six. GET /v2/humans/{id}/tracking was measured slower than the v1 call it would replace (50ms/189KB against ~24ms), so the all-tracking read is worth benchmarking before adopting rather than assuming it is an improvement.
3. Creates, once fix(quick-picks): Rocket Leaders pick sent gruntType=mixed (#221) #227 is resolved.

Watch for

Do not normalise in the services. Twenty-six files consuming two shapes is how a read-path migration turns into a year of one-off bugs. One normaliser, at the proxy, with the v1 shape as the internal contract.

The allProfiles read has no v2 route at all, so the profile overview page stays on v1 regardless. Whatever is built has to keep both surfaces working rather than assuming a clean cut.

?silent=true has to survive. v1 takes it as a query parameter on every write; confirm the v2 routes honour the same suppression before moving anything that writes, or every migrated delete starts DMing users (#848 was exactly this bug on the v1 path).

[hokiepokedad2]

Two corrections to the plan above, both found by reading 5.2.1's handlers

Deletes are not the free warm-up this issue calls them

v1 and v2 scope a delete differently, and the difference is not cosmetic.

v1's HandleDeleteMonster calls db.DeleteByUID(deps.DB, "monsters", id, uid) — keyed on human id and uid only. The profile lookup beside it exists solely to build the confirmation message. v2's handler calls v2FindOwnedRow, which reads SelectByIDProfile(humanID, profileNo) and returns 404 "<type> rule <uid> not found for this human" when the uid is not in the active profile. The bulk form is the same shape: filterOwnedRows works off scopedRows(deps, human.ID, profileNo), so a uid on another profile is silently skipped and the call answers 200 with deleted: [].

I enumerated every caller before assuming that was safe — all ten alarm services, CleaningService, HumanService.DeleteAllAlarmsByUserAsync, TrackingUpdateReconciler, NaturalKeyTrackingUpdate, and the UserOwnedOverrideAreaProxy decorator. Every uid list originates from a profile-scoped read, and the profiles overview page deletes profiles rather than alarms, so nothing depends on the loose behaviour by design.

One case does depend on it by accident. MonsterService.DeleteAsync (and its nine siblings) passes the uid straight through with no re-read:

public async Task<bool> DeleteAsync(string userId, int uid)
{
    await this._proxy.DeleteByUidAsync(TrackingType, userId, uid);
    return true;
}

PoracleNG's active-hours scheduler can change current_profile_no out of band — that is the whole reason /api/auth/me resyncs the JWT. If it fires between the list render and the delete click, v2 answers 404, the existing handler swallows that as "already deleted", the card disappears and the row survives. Today v1 deletes the right row regardless.

So a v2 delete has to fall back to v1 on a rule-not-found 404 rather than swallowing it, which means the migration is v2 plus a v1 fallback on the only case where the two differ. Still worth doing to retire the surface; not worth doing for any behavioural gain.

The all-tracking read is not as slow as recorded here

Measured against production 5.2.1 on 2026-09-15, three runs each, two admin accounts:

account	v1 /api/tracking/all/{id}	v2 /v2/humans/{id}/tracking
A	21ms / 10.8ms / 13.3ms, 22641 B	17.5ms / 18.0ms / 19.9ms, 24613 B
B	8.9ms / 8.2ms / 10.3ms, 1704 B	12.6ms / 13.2ms / 16.2ms, 1842 B

v2 is consistently slower — roughly 1.5x on these accounts — but both are well under the 50ms against 24ms this issue records, and the payloads are within 10%. That earlier measurement was presumably a much heavier account, so the number to watch is how the gap scales, not the gap itself. Worth re-measuring against a 500-rule account before the read migration commits.

Unchanged

The create path still waits on jfberry/PoracleNG#227. The allProfiles read still has no v2 route. The one-normaliser-at-the-proxy rule still stands, and is now load-bearing for a second reason: TrackingFieldPreserver re-reads a row before a PUT, so a field the normaliser restores wrongly does not just display wrongly, it gets written back.

[hokiepokedad2]

Step 2 as written is the wrong shape, and the measurements say why

Step 1 is #889. Before starting step 2 I pulled the same rules from both surfaces on production 5.2.1 and compared them field by field, rather than working from the three differences this issue lists. The gap is wider than "wildcards, enums, and the create envelope".

For 38 pokemon rules, paired by uid, 30 of 36 fields differ — and they differ the same way every time:

atk        0        -> null  x38      max_rarity  6       -> null  x38
clean      0        -> null  x38      max_size    5       -> null  x38
costume    9000     -> null  x38      max_weight  9000000 -> null  x38
form       0        -> null  x38      pvp_ranking_best  1 -> null  x33
gender     0        -> null  x38      pvp_ranking_worst 4096 -> null x6
max_cp     9000     -> null  x38      rarity      -1      -> null  x38
max_iv     100      -> null  x38      size        -1      -> null  x38
max_level  55       -> null  x4       override_location_label "" -> null x38

v1-only: description, id, ping, profile_no. v2-only: edit, summary. And fort.change_types is a JSON string on v1 ("[\"location\"]") against a real array on v2.

So a normaliser turning a v2 rule back into the v1 shape is not a handful of enum tables. It is a per-field table of stored wildcards: 137 nullable fields across the eleven rule schemas.

The server does not publish those values

I checked, because reading them from the target instance is what #859 did for the value bounds and it is the design that ages:

$ jq '[.components.schemas.V2PokemonRule.properties | to_entries[]
      | select(.value.default != null)] | length'
0

Zero of 36 pokemon fields carry a machine-readable default. The values exist only inside English descriptions — "Omit to impose no upper bound (stored as 9000 = the CP cap sentinel)" — and a regex over those prose strings finds a number for 59 of the 137 nullable fields. The remaining 78 are booleans and strings whose mapping is structural rather than per-field, so they are coverable, but the numeric core would be either parsed out of documentation or hand-maintained against upstream's cleanRow.

Why getting one wrong is worse than it sounds

TrackingFieldPreserver.PreserveStoredFieldsAsync re-reads the stored row through GetByUserAsync — the very call step 2 would move — and merges every property the row carries and the submission does not into the write. TrackingUpdateReconciler.CountUpdatableDifferences compares against rows read the same way.

So a wrong restored wildcard does not merely display wrongly. It is written back into the user's rule, and it changes whether the collision guard fires. That is the #553 and #561 failure surface, reached through a table of 137 values with no way to detect drift.

CLAUDE.md is explicit about this class: prefer refusing the impossible over allowing only the known. "No control characters, no more than the column holds" ages well. "One of these thirty values" does not. A hundred and thirty-seven values do not either.

And the gain is zero by construction

The normaliser's whole purpose is that every consumer keeps seeing the v1 shape. Nothing reads better, nothing is deleted, no user sees a difference. The things a v2 migration is actually meant to retire — TrackingUpdateReconciler, PoracleJsonHelper's coercion, the unwrap plumbing — go away when services stop speaking v1, not when the proxy round-trips v2 back into v1 for them. The normaliser is explicitly a stepping stone that has to be removed again later, and it is the riskiest available one.

It is also slower. Measured on production, three runs per account:

	v1	v2
all-tracking, account A	21 / 10.8 / 13.3 ms	17.5 / 18.0 / 19.9 ms
all-tracking, account B	8.9 / 8.2 / 10.3 ms	12.6 / 13.2 / 16.2 ms

Proposed re-scope: migrate a type, not a verb

Drop the read normaliser. Move one tracking type at a time, all three verbs together, and change that type's service to the v2 shape directly — no intermediate contract, nothing to remove afterwards. A type is ready when it can read, write and delete on v2, which for pokemon means jfberry/PoracleNG#227 first.

That gets the same end state without ever holding two shapes at once, and it deletes v1 handling as it goes instead of adding a layer that has to be deleted later. The one-normaliser rule in this issue was right about the danger — twenty-six files consuming two shapes — and the way to avoid it is to not have two shapes, rather than to build a converter between them.

Under that plan step 2 waits on #227 alongside step 3, and the migration is unblocked by one upstream fix rather than two.

allProfiles still has no v2 route, so the profiles overview page stays on v1 whatever is decided here.