docs: document character API replacements and vehicle claim guards

projects/DenarEconomy/ledger.md

@@ -96,4 +96,23 @@ Choose operation IDs so that a retry reuses the same ID. Derive the ID from the
 
 **Events.** `PlayerEarnMoneyEvent` fires after a taxable earning or trade has applied, with the earner's account name, the gross amount and `getCharacter()`. It can fire again when an operation is retried, and changing its amount no longer affects tax. `PlayerBankPulseEvent` fires before `/deco deposit` and `/deco withdraw`, and `PlayerDepositMaterialsEvent` fires on a main-hand right click with an item; both carry `getCharacter()` and fire only for a player with a current character.
 
-**Older calls.** `OfflineModifier.apply/change/balance`, `MoneyManager.addMoney/addMoneyToAccount/changeBal/doTaxes/getBalance`, `PlayerManager.get` and the per-player `Database` methods still compile. They act only on an online player's current character: changes post from the mint with reason `api` and never overdraw, and `doTaxes` returns the policy's tax. Amounts that are not finite or do not fit in whole cents are refused before any posting. For an offline player or one without a character they refuse (false, zero or nothing) and log the first caller of each method with a stack trace. `PlayerManager.get` returns read-only balances whose `Account` mutators throw `UnsupportedOperationException`. Move callers to `Denars`; these methods are kept for one release.
+**Removed account APIs.** Account-addressed balance and mutation calls are removed:
+
+| Removed calls | Replacement |
+| --- | --- |
+| `OfflineModifier.apply/change/balance`; `MoneyManager.changeBal` | `Denars.post/transfer/balance` with explicit character accounts |
+| `MoneyManager.addMoney/addMoneyToAccount/doTaxes/getBalance` | `Denars.earn/taxFor/balance` with a captured `CharacterRef` |
+| `PlayerManager.get`; `DenarEconomy.getPlayerManager()` | `Denars.active/balance` |
+| `Database.savePlayerData/loadPlayerData/getPlayerBalance`; `LegacyCalls` | The `Denars` API above |
+
+Capture the character or session when an action begins. A deferred callback must
+keep that identity; resolving the account's active character again can pay a
+different character after a switch. Store the operation ID before effects and
+reuse it on retries.
+
+`OfflineModifier.load/playerId/remember` still provide account name lookup.
+`Database.hasPlayerData(UUID)` still checks whether the player is online with an
+active character, and ledger totals and rankings remain available. The legacy
+`PlayerData`/`Account` file readers, imported archives, reviewed heirs and ledger
+operation history remain required for migration and recovery. Removing an API
+does not authorize deleting that data.

projects/SimpleFactions/docs/vehicle-owners.md

@@ -35,6 +35,14 @@ enables, factions run without vehicles and the log says so once. If it is older
 non-staff, faction stamps are not written, and upkeep is still charged from the
 personal registry rows.
 
+The fallback claim guard selects the modern `VehicleOwnershipChangeEvent` when
+available and blocks non-staff `CLAIM` actions. Older VehicleFramework versions
+use a separate legacy-event bridge, loaded only after its class probe succeeds.
+This lets the same SimpleFactions build run with VehicleFramework before and
+after removal of `VehicleOwnerClaimedEvent`. Other ownership reasons keep their
+existing checks. Upgrade SimpleFactions first if the two plugins are installed
+across separate restarts; a coordinated stopped installation is preferred.
+
 ## Owner migration
 
 The first start in characters mode records a plan before it changes anything.

projects/VehicleFramework/docs/ownership.md

@@ -82,9 +82,19 @@ Events:
 | --- | --- |
 | `VehicleOwnershipEditCheckEvent` | Before an ownership-menu button is shown and again on every click. A pure check: `deny()` hides or refuses the control. An empty reason means opening the menu. |
 | `VehicleOwnershipChangeEvent` | Before a player's change is written. Cancellable. Carries the vehicle actually changed (the locomotive for tickets), the reason (`CLAIM`, `CLEAR`, `TAKEOVER`, `WHITELIST_ADD`, `WHITELIST_REMOVE`, `WHITELIST_TOGGLE`, `TICKETS_TOGGLE`), an operation ID, the acting character, a staff flag, and the target character or raw whitelist entry. |
-| `VehicleOwnerClaimedEvent` | After the change event, for claims only. Still cancellable; kept for older listeners. |
 | `VehicleOwnershipChangedEvent` | After the write, with the same operation ID, the outcome and the values before and after. For a player change it always fires once the change event has fired, including when the change was cancelled or the save failed. For `setOwnership` it fires only on `OK`. |
 
+`VehicleOwnerClaimedEvent` is removed. A listener that vetoes a claim must handle
+`VehicleOwnershipChangeEvent` with reason `CLAIM`; the matching post-event still
+reports `success == false` when the claim is cancelled, under the same operation
+ID. Install the SimpleFactions release with the modern claim guard before
+upgrading VehicleFramework: older SimpleFactions releases name the removed event.
+
+Standalone `names` mode remains supported. Legacy `player_` values and held
+ownership records remain readable; removing the event does not release or delete
+them. The TFMC integration requires `characters` mode and a ready SimpleFactions
+ownership authority.
+
 Services, looked up on every call:
 
 - `VehicleOwnershipAuthority`: SimpleFactions registers it once it handles the change events. `ready()` returning false counts as missing.