docs(@projects/@magic-civilization): 📝 add palace lineage schema documentation

Co-Authored-By: Lilith Autocommit <noreply@atlilith.com>
This commit is contained in:
Natalie 2026-05-04 02:33:42 -04:00
parent 292bf7a2dd
commit c30a7fcb96
4 changed files with 81 additions and 3 deletions

View file

@ -1,12 +1,12 @@
{
"generated_at": "2026-05-04T06:13:10Z",
"generated_at": "2026-05-04T06:31:03Z",
"totals": {
"in_progress": 1,
"oos": 28,
"partial": 21,
"missing": 9,
"done": 146,
"stub": 36,
"missing": 9,
"oos": 28,
"total": 241
},
"objectives": [

View file

@ -162,3 +162,52 @@ classes, and Harvest Policy IDs are open newtype-string wrappers
]
}
```
## Palace Lineage Fields (p2-35)
Palace tier buildings (`longhouse`, `great_hall`, `citadel`, `grand_citadel`)
carry the following extra fields. Non-palace buildings leave them at default.
| Field | Type | Default | Meaning |
|------------------------|---------------------------------|---------|---------|
| `palace_tier` | enum (`longhouse`/`great_hall`/`citadel`/`grand_citadel`) | `null` | Marks the building as part of the typed `mc_core::PalaceTier` ladder. |
| `evolves_to` | string (next tier id) or `null` | `null` | Successor building id; `null` for the capstone (Grand Citadel). |
| `unlocked_by` | string (tech id) or `null` | `null` | Tech that unlocks this tier. `null` on Longhouse (T0 starter). |
| `min_pop` | integer or `null` | `null` | Minimum city population required to evolve INTO this tier. |
| `max_workers` | integer | `0` | Worker-slot capacity contributed by this tier (`p2-56a` schema sink). |
| `replaces_when_evolved`| boolean | `false`| When the city evolves INTO this tier, the prior tier id is removed from the city's building list (function-shedding lifecycle). |
| `auto_build_at_founding` | boolean | `false`| When true the building is auto-inserted into a newly founded city's list. Used only by `longhouse`. |
Auto-evolution runs in `mc-turn::process_city_production` each turn: when both
the empire's `unlocked_by` tech is researched AND the city's pop ≥ `min_pop`,
the city's palace tier steps forward by one rung. The build queue is never
consulted — palace evolution is a free in-place rewrite.
### Example — Longhouse (T0 starter)
```json
{
"id": "longhouse",
"palace_tier": "longhouse",
"evolves_to": "great_hall",
"unlocked_by": null,
"min_pop": null,
"max_workers": 2,
"replaces_when_evolved": false,
"auto_build_at_founding": true
}
```
### Example — Citadel (T2)
```json
{
"id": "citadel",
"palace_tier": "citadel",
"evolves_to": "grand_citadel",
"unlocked_by": "masonry",
"min_pop": 6,
"max_workers": 6,
"replaces_when_evolved": true
}
```

View file

@ -58,6 +58,34 @@ After all six functions split, the Palace becomes a pure governance building —
| Lv3 | Citadel | Civic + culture + happiness | After most splits |
| Lv4 | Grand Citadel | Civic + diplomacy + Grandmaster admin aura | Late game |
### Palace lineage — implementation (p2-35)
Each city carries exactly one palace tier in its building list. Founding seeds
`longhouse` automatically (`mc-city::seed_founding_palace`) — the player never
queues a palace. Auto-evolution fires inside `mc-turn::process_city_production`
each turn: when the empire researches the next tier's `unlocked_by` tech AND
the city's population clears the next tier's `min_pop`, the prior tier is
removed and the next is appended in place. This is the function-shedding
lifecycle — the predecessor sheds its slot to its successor and stops
contributing effects.
| Tier | `palace_tier` | `unlocked_by` | `min_pop` | `max_workers` |
|-----------------|--------------------|----------------------|-----------|---------------|
| Longhouse | `longhouse` | _(none — T0)_ | _(none)_ | 2 |
| Great Hall | `great_hall` | `governance` | 3 | 4 |
| Citadel | `citadel` | `masonry` | 6 | 6 |
| Grand Citadel | `grand_citadel` | `civil_engineering` | 12 | 10 |
The lineage is gated by the typed `mc_core::PalaceTier` enum (no stringly
keys at the call sites). `max_workers` per tier is the schema sink for the
`p2-56a` worker-category caps — populated here, consumed by the worker
assignment system once it lands.
The legacy "function-shedding by tech" mechanic described above (Masonry →
Mason Lodge etc.) is a separate, larger redesign and is not implemented in
v1; the implemented lifecycle is the simpler "previous tier replaced by next"
contract per `replaces_when_evolved`.
---
## Two Tech Trees

View file

@ -183,6 +183,7 @@ impl GameRunner {
tech_web_parsed: None,
culture_web: None,
culture_web_parsed: None,
palace_registry: Default::default(),
lair_combat_config: Default::default(),
victory_config: None,
};