Proposal: add a classless connected specialization tree with respecs

[zoeyrose]

Important

This issue is implemented in the fresh MIT-licensed Go server under the replacement program. Its gameplay and content-design decisions remain authoritative. C, CPython, classic packet, file-path, and enum details in the preserved specification are historical evidence only; do not copy, translate, or structurally port GPL implementation code.

Replacement implementation contract

Implement the preserved classless graph and respec design as compiled data plus a Go graph validator and atomic respec transaction. CEL may evaluate pure prerequisites but cannot perform effects. Protocol publishes catalog/state models for the Rust UI.

The server remains authoritative, consumes versioned compiled content, and exposes bounded generated Game Protocol 1 messages. Pure rules may use a specifically approved typed CEL environment. Starlark is not part of this issue unless the separate residual-scripting decision explicitly approves it.

Required verification

• Preserve every observable rule, balance decision, disclosure boundary, and anti-exploit invariant from the specification below.
• Add deterministic Go unit/property tests and wrapper-managed scenario coverage at the appropriate integration boundary.
• Add bounded malformed-input and persistence-failure cases where this feature accepts content, network, or stored data.
• Add Go/Rust protocol conformance fixtures for every new cross-process field; the client must not reconstruct authoritative rules from prose.
• Demonstrate that implementation and tests contain no copied GPL source/test material and execute no runtime Python.

Preserved product/design specification and historical implementation notes

Summary

Add one server-authoritative, connected character specialization graph without fixed character classes.

Characters keep Atrinik's use-based combat disciplines and may distribute a bounded shared pool of specialization points across martial, ranged, arcane, divine, defensive, support, and hybrid paths. Discipline levels and equipment profiles gate advanced nodes, but no creation-time class permanently locks a character out of another part of the graph.

Players may respecialize through a deliberate, atomic server transaction. The system should make builds distinct while preserving experimentation and recovery from balance or content changes.

Product decisions

• No fixed Warrior/Ranger/Arcanist/Acolyte class field.
• No classless fallback alongside classes; the connected graph is the only specialization model.
• No permanent branch exclusion based on a character-creation choice.
• One bounded character specialization-point pool, derived from documented functional-level milestones and capped with combat power.
• Use-based discipline levels remain authoritative for action scaling and node prerequisites.
• Respecialization is supported and must not require deleting or recreating a character.

Race remains ancestry/body/presentation and is independent of specialization. Renown remains the post-cap vocabulary from #30 and must not provide an unlimited source of specialization points.

Connected graph model

Start from a neutral central region and arrange authored clusters around stable combat identities such as:

• shared fundamentals, mobility, survivability, and resource control;
• Melee Combat and Unarmed;
• Archery and Throwing;
• Wizardry and Magic Devices;
• Divine Magic, restoration, warding, and support;
• bounded hybrid connectors that reward investment in more than one discipline.

The graph may contain ordinary stat/refinement nodes, Technique and Mastery ranks from #27, equipment-proficiency nodes, connectors, and build-defining keystones. It must contain more useful nodes than one capped character can buy.

Connectivity is a gameplay contract, not merely a visual layout. A purchase requires a valid path from the center through currently owned prerequisite nodes. Refunds must preserve connectivity or refund an affected dependent branch atomically.

Points and prerequisites

Derive available points from functional character-level milestones selected with #30. Store spent node IDs and purchase order, not a mutable duplicate of the derived point total.

Individual nodes may require:

• a minimum Melee Combat, Archery, Unarmed, Throwing, Wizardry, Divine Magic, or Magic Devices level;
• an eligible weapon/combat profile for activation;
• one or more prerequisite nodes;
• a stable content, quest, or trainer unlock where justified; or
• mutually exclusive keystone tags when two capstone effects cannot coexist safely.

Skill requirements gate advanced expression without turning the graph into a hidden class system. A low Wizardry character may path toward an arcane cluster, but cannot activate its advanced spell nodes until the actual discipline requirement is met.

Equipment eligibility should use stable proficiency tags granted by nodes or baseline character rules, not hard-coded required-class strings. An inactive or refunded node must immediately and safely invalidate dependent equipment/actions with a clear reason.

Respecialization

Support both a full reset and a connected branch refund while out of combat. The server transaction must:

1. validate combat/action state, requested refunds, resulting graph connectivity, and point totals;
2. determine deactivated Techniques, Masteries, proficiencies, equipment, and pending actions;
3. apply the complete new selection atomically;
4. cancel invalid actions and safely unapply or reject invalid equipment;
5. emit one coherent state update and actionable player feedback.

The initial policy may use a modest coin fee, trainer, cooldown, or confirmation to make respec deliberate. It must remain repeatable, cannot consume a rare one-time item, and cannot be used as an in-combat loadout toggle. Development/admin repair and automatic refunds for removed or invalid nodes remain free and deterministic.

Data and persistence

Define the graph through the authoritative schema/field metadata owned by atrinik/content#15 and migrated by atrinik/content#8. Each node needs a stable domain-qualified ID, display metadata, cost, graph edges, prerequisites, ranks, effect references, exclusion tags, and ordering/layout hints.

Persist selected stable node IDs and purchase order in typed player state. Reject cycles, disconnected nodes, dangling effect/profile/discipline references, impossible costs, contradictory exclusions, and graphs with no valid route from the center during collection/startup.

Do not serialize display names, enum ordinals, screen coordinates, or array positions as durable identity. Removed/renamed nodes must produce a deterministic refund with diagnostics rather than corrupting or trapping the character.

Server and client ownership

The server owns points, prerequisites, connectivity, purchases/refunds, effective node state, and every gameplay effect. The client receives a bounded public graph catalog and current selection state, renders search/path/requirement previews, and submits stable purchase/refund requests.

The UI should support pan/zoom, search, highlighted reachable paths, available/spent points, node ranks, unmet skill/profile requirements, prospective path cost, and an explicit respec preview. It must remain keyboard-accessible and usable at atrinik/client#20's supported UI scales.

Relationships

• Add data-driven combat disciplines, weapon techniques, and mastery trees #27 owns combat profiles, action shapes, Techniques, Masteries, and their server-authoritative effects; this issue owns their connected graph, shared point pool, and respec policy.
• Define stable combat-discipline and spell-tradition identities #18 owns consolidated combat-skill identities and explicit spell traditions.
• Redesign player cap and endgame progression around level-101–115 group encounters #30 owns the functional level cap, point-award pacing, endgame power ceiling, and Renown boundary.
• Proposal: establish stable content identities and cross-reference validation content#19 owns stable content identity and reference policy.
• Content schema: define authoritative schemas and generated field metadata content#15/#203 own authoritative schema metadata and authored-source migration.
• Rebuild modern controls and onboarding around semantic actions client#14 owns semantic input actions and onboarding for graph navigation and respec confirmation.

Delivery plan

1. Specify the point schedule, graph schema, connectivity/refund rules, and representative fixtures.
2. Add typed player persistence and server validation with a small shared-fundamentals plus two-discipline vertical slice.
3. Integrate Add data-driven combat disciplines, weapon techniques, and mastery trees #27 Technique/Mastery nodes and equipment proficiency tags.
4. Add the bounded protocol/catalog and accessible client graph/respec UI.
5. Expand the authored graph across all launch disciplines, then balance hybrid and capstone paths.
6. Add trainers/help/onboarding and remove superseded per-discipline point stores or class assumptions.

Acceptance criteria

• Every character uses one connected specialization graph and no fixed class identity gates the graph.
• One bounded shared point pool is derived from documented functional-level milestones and cannot grow without limit through Renown.
• Use-based discipline levels remain meaningful prerequisites and scaling inputs.
• A capped character cannot purchase every useful node; martial, ranged, magical, divine, support, and hybrid builds remain materially distinct.
• Graph connectivity, ranks, prerequisites, exclusions, profile requirements, and point totals are server-authoritative and validated.
• Full and branch respecs are repeatable, out-of-combat, atomic, and cannot leave invalid actions, equipment, or disconnected selections.
• Removed or invalid nodes refund deterministically without requiring a compatibility alias.
• Stable IDs persist safely; display names, enum ordinals, and UI coordinates are not durable identities.
• The client provides a searchable, accessible graph and exact purchase/refund preview without becoming gameplay-authoritative.
• Focused server, protocol, persistence, content-validation, and UI tests cover pure and hybrid builds, capstones, respecs, down-leveling, reconnect, and malformed requests.

Non-goals

• Fixed classes, multiclass slots, or creation-time permanent role locks.
• Unlimited post-cap combat power.
• In-combat specialization loadouts.
• A second independent perk system beside Add data-driven combat disciplines, weapon techniques, and mastery trees #27's Techniques and Masteries.