Persist /turftakeover history + expose via API

Suggestion:
Core schema (sketch)

Treat takeovers structurally identical to wars (metadata + per-event kill feed + per-event damage feed). Keeps the data model symmetric with what already exists and minimizes server-side aggregation.

turf_takeovers — one row per attempt:

• id, turf_id, attacker_faction_id, defender_faction_id (owner at start), started_at, ended_at, outcome

turf_takeover_players — roster snapshot (analog of /wars/{id}/players):

• takeover_id, player_id, faction_id (snapshot at the time), tier

Per-kill and per-damage data is reused from the existing event streams by tagging events with turf_takeover_id analogous to how they're tagged with war_id. No new event tables — just an association/filter on what
already gets emitted.

API endpoints (mirror /wars/)

• GET /v2/public/turfs/takeovers?since=&turf_id=&attacker_faction_id=&defender_faction_id=&outcome=&cursor= — paginated list
• GET /v2/public/turfs/takeovers/{id} — metadata
• GET /v2/public/turfs/takeovers/{id}/players — roster (anyone in zone during window)
• GET /v2/public/turfs/takeovers/{id}/kills — per-event kill feed, same shape as /wars/{id}/kills (weapon_id, kill_type, location, killer/killed factions + tiers)
• GET /v2/public/turfs/takeovers/{id}/damage — per-event damage feed, same shape as /wars/{id}/damage (per-event damage with wartime_faction_id/current_faction_id)
• GET /v2/public/turfs/{id}/takeovers — per-turf history
• GET /v2/public/players/{id}/takeovers — player participation history

Public + 15-minute delay matches the war feed convention; an OAuth no-delay variant (analog of /v2/wars/) could come later under a new faction.turfs scope if useful.

Open implementation questions

1. The damage event currently exposes per-event records globally with a war_id tag — could turf takeovers be a parallel tag (turf_takeover_id) so the per-event kill/damage feed is reused rather than duplicated?
2. Damage events don't currently carry a location field in the public output the way kills do — is position available server-side for damage events (even if not currently exposed)? If yes, zone-tagging damage events

is essentially free. If no, that's an extra hook on the damage write path.

1. Is there a single chokepoint where the takeover resolves (success or fail), or do success and fail go through separate code paths? Determines where the "write the row" hook goes.
2. During an active takeover, is per-player enter/leave tracked, or only timer-based member-count checks? If only timer-based, the roster snapshot would be a union of "members present at any check tick."
3. How does current logic treat a third faction entering a takeover zone mid-attempt? Determines whether the roster needs a side field or if attacker_faction_id/defender_faction_id on the takeover row + each player's

faction_id snapshot is enough.

Who benefits:
Wars are extremely rare, but /turftakeover is the actual day-to-day faction-conflict surface — and currently leaves no record. The live UCP shows current ownership and holder counts but no history.

Fits cleanly into things that already exist:

• Public surface precedent. Current turf ownership, top holder factions, and per-turf owners are already public on the UCP. History is the obvious missing layer.
• Event-shaped, not continuous. Each takeover has a clear start/end/outcome — the data reads as faction history, not as a deathmatch stats feed. Same framing the

war pages already use.

• Low compute cost. The server already runs all the relevant logic (member counts, position-in-zone, success/fail resolution). The ask is essentially "write a row when the existing logic resolves" + tracking

participants during the bounded 5-min window. No new continuous monitoring.

For the community: per-takeover archives, "longest hold of X turf," historical matchup records, narrative artifacts ("remember when Y took Z from W") — all things active players would use and reference.

Who is hurt:
Storage cost is small (sparse events — takeovers are bounded 5-min windows) but worth flagging since it adds to existing kill/damage event volume. No new continuous logging.

The structural sketch above is shaped by what I'd want to derive on the Tita Enza side — not a prescription. You'll know far better than I would where this slots into existing hooks, whether some of the tagging can
ride on infra that already exists, or whether a different shape avoids redundant storage entirely. Treat the schema/endpoint shapes as the output I'd want, and feel free to take a smarter implementation path to get
there.