Skip to content

Structured O.C.C. starting loadouts and authoritative provisioning #62

Description

@StreamDemon

Third prerequisite for #57 under umbrella #12.

Predecessor #61 is complete through PR #64, merged and validated on local main. This issue is the sole current next-up task.

Approved design

Structured loadout content

  • Add a page-stamped O.C.C. startingLoadout with fixed catalog grants, fixed or dice-based quantities, named choice groups, and checklist-only entries.
  • Choice groups use explicit item ids or printed item-category constraints; prose is never parsed to create inventory.
  • Fail content loading for unknown items, empty or unsatisfiable groups, invalid quantities, duplicate keys, contradictory options, or category mismatches.
  • Keep vehicles, loose ammunition, credits, and incidental non-catalog gear as visible checklist guidance rather than counterfeit inventory records.

Pure planning and builder behavior

  • One pure planner produces fixed grants, legal choices, quantity ranges, and checklist guidance.
  • Add a builder loadout step that stores only player selections and clears selections owned by a previously selected O.C.C.
  • The review shows fixed and selected items, ranges for unrolled quantities and armor capacity, and a separate checklist.
  • Generic printed choices such as energy pistol or rifle offer only source-verified catalog items matching the structured category constraint.

Atomic authoritative provisioning

  • Character creation accepts loadout selections, not a client-authored starting inventory.
  • In one mutation, reload authoritative O.C.C. content, validate choices, roll dice quantities and every dice-capacity armor instance, construct inventory, validate the full character, and insert it.
  • Any failure aborts the entire creation; partial characters or inventories cannot exist.
  • Starting armor is owned but unworn. Equipping remains an explicit action.
  • After creation, inventory remains ordinary mutable character state; disposing of starting gear never makes the build illegal.

Ley Line Walker boundary

  • Replace the existing prose equipment and weapon fields with the structured model.
  • Auto-provision only newly forged Ley Line Walkers; do not migrate, grant to, or rewrite existing characters.
  • Preserve vehicles, ammunition, starting funds, and other unmodeled benefits as page-stamped checklist guidance.

Proof

  • Rules tests cover exact grants, quantities, options, category constraints, and malformed content.
  • Backend tests cover tampered choices, transactional failure, dice quantities, per-suit armor rolls, and unchanged legacy characters.
  • Web tests cover selection reset and review behavior.
  • Live browser acceptance forges a Ley Line Walker, verifies inventory and the concrete armor roll after navigation/reload, equips the armor, and confirms a pre-existing character is unchanged.

Authoritative sources include the rendered Ley Line Walker entry on RUE pp. 113-116 and every referenced item/equipment page. Do not infer items, quantities, or options from memory.

Explicitly out of scope: retroactive grants/migration, Coalition Grunt content (#57), a general vehicle or wallet system, ammunition consumption, and unrelated inventory behavior.

Success requires rules/backend/web package checks and tests, root vp check and vp test, and the live browser acceptance above.

Predecessor: #61 (complete).
Successor: #57.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:backendConvex backendarea:frontendWeb app (builder + sheet)area:rulesRules engine (@riftforge/rules)needs:loadoutsRequires structured O.C.C. starting loadouts and authoritative inventory provisioningnext-upThe immediate next task

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions