Implement Crafting, Social, Magic discipline stubs with expandable root-and-branch structure #234
Labels
No labels
Blocked
Duplicate
MoSCoW/Could Have
MoSCoW/Must Have
MoSCoW/Should Have
Points/1
Points/13
Points/2
Points/21
Points/3
Points/5
Points/8
Priority/Backlog
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
State/Completed
State/In progress
State/In review
State/Paused
State/Unverified
State/Verified
State/Wont Do
Type/Bug
Type/Epic
Type/Feature
Type/Legendary
Type/Task
Type/Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#225 Epic: Non-Combat Discipline Trees
aethyr/Aethyr
Reference: aethyr/Aethyr#234
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Metadata
feature/m4-non-combat-discipline-stubsfeat(skills): implement Crafting, Social, Magic discipline stubsBackground and Context
While the Combat and Survival disciplines have full multi-tier trees, the remaining three disciplines — Crafting, Social, and Magic — need expandable stub structures for the v1.3.0 release. Each gets its root node (already defined) plus a set of tier-1 branch stubs that establish the intended direction of each discipline without implementing the full depth.
These stubs serve multiple purposes: they show players the breadth of the skill system, they provide a framework for future expansion, and they validate that the
SkillTreedata model handles multiple discipline trees simultaneously without issues.Expected Behavior
Crafting Discipline Stubs (tier 1, require Crafting level 1):
Social Discipline Stubs (tier 1, require Social level 1):
Magic Discipline Stubs (tier 1, require Magic level 1):
YAML Structure: Each stub follows the same schema as combat/survival branches, with clear descriptions indicating these are expandable starting points.
Tree Structure:
Extensibility: Each stub node's YAML includes a
# TODO: Add tier-2+ branches in future epicscomment to signal intended expansion.Acceptance Criteria
conf/skill_trees.yaml.conf/skill_trees.yaml.conf/skill_trees.yaml.list_by_disciplinereturns correct counts: Crafting 4, Social 4, Magic 4.children_of("crafting")returns Smithing, Tailoring, Woodworking.children_of("social")returns Persuasion, Barter, Leadership.children_of("magic")returns Elemental, Restoration, Enchantment.validate!passes with all 5 discipline trees loaded simultaneously.Subtasks
conf/skill_trees.yamlunder crafting.conf/skill_trees.yamlunder social.conf/skill_trees.yamlunder magic.list_by_disciplinereturns correct counts for all 3 disciplines.children_ofreturns correct stubs for each discipline root.validate!passes with all 32 nodes across 5 disciplines.check_unlockablecorrectly gates stubs behind discipline root level 1.tests/unit/non_combat_stubs.featurecovering stub loading from YAML, prerequisite gating for discipline roots, children_of for crafting/social/magic, full tree validation with 32 nodes, discipline listing counts.tests/integration/for Crafting, Social, Magic discipline stubs with full tree validation.bundle exec rake unit_profileand verify no performance regressions.bundle exec rake unit. If coverage is <97% then review the current unit test coverage report atbuild/tests/unit/coverage/and use it to write new Cucumber based unit tests to improve code coverage. Specifically, write Cucumber/Gherkin style unit tests that are descriptively named and specifically improve coverage on whichever file has the most uncovered lines by writing tests that will target the uncovered lines in the report. Once that is done rerunbundle exec rake unitto verify all tests pass and coverage is above >=97%. Only mark this as complete once coverage is >=97%, if not repeat this task as many times as is needed until coverage reaches >=97%.bundle exec rake(default task: unit tests with coverage) andbundle exec rake integration, fix any errors if needed ensuring both pass across entire code base, do not ignore any failure even if it seems unrelated to this commit, fix it.Definition of Done
This issue is complete when:
master, reviewed, and merged before this issue is marked done.