Documentation updates

docs/design.md

@@ -14,9 +14,6 @@ Internally, land locations are named "land" or "l" and water locations are calle
 
 In Diplomacy, there is only one board, whose state changes atomically as a function of the previous state and the orders. Thus, there is only ever need to refer to units by the province they instantaneously occupy, e.g. "A MUN -> TYR" to order the army in Munich to move to Tyrolia. 5dplomacy needs to be able to refer to past states of the board as well as alternative timeline states of the board. The timeline of a province is specified by prefixing the timeline designation, e.g. "a-MUN" to refer to Munish in timeline a or "b-TYR" to refer to Tyrolia in timeline b. The turn of a province is specified by a suffix, e.g. "LON@3" to refer to London in turn 3.
 
-> [!WARNING]
-> The timeline notation is in flux and archaeological layers of previous decisions are scattered around the code.
-
 ## Adjudication algorithm
 
 The adjuciation algorithm is based on the algorithms described by Lucas B. Kruijswijk in the [Diplomacy Adjudicator Test Cases v2.5 §5 "The Process of Adjudication"](https://web.archive.org/web/20230608074055/http://web.inter.nl.net/users/L.B.Kruijswijk/#5) as well as ["The Math of Adjudication"](http://uk.diplom.org/pouch/Zine/S2009M/Kruijswijk/DipMath_Chp1.htm). The approach taken follows the partial information algorithm later described in [DATC v3.0 §5.E](https://webdiplomacy.net/doc/DATC_v3_0.html#5.E). These algorithms are based on the recursive evaluation of binary (move succeeds, unit is dislodged, etc.) and numeric (attack strength, hold strength, etc.) decisions.
@@ -36,10 +33,7 @@ Note that the timeline advance decision depends on the result of previously-adju
 
 ## Pure adjudication
 
-The core adjudication algorithm is intended to be a pure function. That is, adjudication begins with all relevant information about the game state and orders, and it computes the result of adjudicating those orders. Data persistence is handled by a higher layer that is responsible for saving the information the adjudicator needs and constructing the input data structure. This is intended to encapsulate the adjudicator logic and decouple it from other concerns that depend on implementation details of the application.
-
-> [!WARNING]
-> This is not complete and the adjudicator is still stateful.
+The core adjudication algorithm is intended to be a pure function. That is, adjudication begins with all relevant information about the game state and orders, and it computes the result of adjudicating those orders, leaving the inputs unchanged. Data persistence is handled by a higher layer that is responsible for saving the information the adjudicator needs and constructing the input data structure. This is intended to encapsulate the adjudicator logic and decouple it from other concerns that depend on implementation details of the application.
 
 ## Game options
 
@@ -50,3 +44,6 @@ In order to support different decisions about how adjudication or the rules of m
 - `enableJumpAssists`: Whether the jump assist order can be used.
 - `victoryCondition`: The victory condition to use for the game. `"elimination"` means a player is eliminated if they are eliminated in a single timeline and the last player standing wins. `"majority"` means a player wins if they control the majority of supply centers across all timelines. `"unique"` means a player wins if they control 18 unique supply centers by name across all timelines.
 - `adjacency`: The rule to use for determining province adjacency. `"strict"` means provinces are adjacent if they are within one timeline of each other, within one turn of each other, and geographically adjacent. `"anyTimeline"` follows `"strict"` but all timelines are considered adjacent to each other.
+
+> [!WARNING]
+> Options are not implemented yet.

docs/rules.md

@@ -53,3 +53,11 @@ Outside of convoys, a unit may only move one province at a time. Multiversal tim
 In _Diplomacy_, orders refer to provinces, such as "A Mun-Tyr". In _5D Diplomacy with Multiversal Time Travel_, this is insufficient to unambiguously identify a province, since the province exists in multiple timelines across multiple turns. The convention for identifying a multiversal location is `timeline-province@turn`, where `timeline` is the timeline's identifier and `turn` is the turn's identifier, e.g. "b-Mun@3".
 
 (Why this order? Short representations for timelines and turns can be confused for each other, especially for timelines designated with `f` or `s` that might be confused for fall or spring turns. _5D Diplomacy with Multiversal Time Travel_ is already complicated enough, so the timeline and turn are put on either side of the province and delimited with different symbols.)
+
+Some designation elements may be omitted for brevity. Omitted elements are interpreted according to the following rules:
+
+- If the timeline is omitted from the subject of an order, the timeline is the root timeline, "a". If the turn is omitted from the subject of an order, the turn is the latest turn in the timeline.
+- If the timeline or turn are unspecified for the destination of a move or the target of a support-hold order, the timeline and turn are those of the ordered unit.
+- If the timeline or turn are unspecified for the destination of a support-move order, the timeline and turn are those of the supported unit.
+
+Thus, if timeline "a" is at turn 2 and timeline "b" is at turn 1, `A Munich supports A b-Munich - Tyrolia` is equivalent to `A a-Munich@2 supports A b-Munich@1 - b-Tyrolia@1`.