RELATIONSHIP_COMBAT_SYSTEMS_NOTE.md

music/RELATIONSHIP_COMBAT_SYSTEMS_NOTE.md

Relationship and Combat Systems — Development Flag (per-chapter, living-spine)

CANON SUBORDINATION — this document is PROPOSAL-TIER: it serves canon and never outranks it.
The canon: the CVD · the T1 foundation docs · the T0 registries (registries/) · the spine
(docs/spine/CH_*.md) · the region pages (_source/02_Tier_2_Region_Pages/). Authority order: docs/DOC_MAP.md § 0.
Canon served (scanned from this document's own citations — widen it by hand where it is thin):
T1_CVD_Creative_Vision_Document · T1_Combat_System_Spec · T1_Integrity_Paths_Worldstates_Master · (+2 more tier) · T0_Familiar_Registry · docs/spine/CH_12.md
READ THAT CANON FIRST — open it and derive from it before you build anything from this document.
If this document disagrees with canon, CANON WINS and this document is the defect — fix the
document, never the canon. Nothing here is applied until it is ratified into canon.

Proposal, cascade v2.4, DRAFT. Design-development flag only — NOT a spec. Per Josh (2026-07-08): these systems are "not well defined yet, but we do need to touch on it." This note does not edit canon, does not resolve any of the systems below, and invents no mechanics; it enumerates the systems that must be developed as the chapters build one at a time, names what already anchors each one, and marks what is still open for Josh to shape. Josh authors the systems; this note is the roadmap that keeps them on the radar as the cascade advances. Every claim traces to a resolvable [SRC:].

Why this note exists

The Story Spine cascade builds the 79 nodes one at a time, and several player-facing systems are not resolved at the world-canon layer yet — they are meant to be developed per-chapter, as each quest line surfaces the concrete beat that needs them. Left unnamed, they risk being improvised inconsistently node to node, or deferred until they are expensive to retrofit. This note holds them as a standing development set so that each chapter build asks, in its own context, "what does this node need from each of these systems, and how does that align with what earlier nodes established." It is the counterpart, on the systems side, to the way the Care Doctrine is the standing lens on the cultural side.

The framing discipline: develop these incrementally and in-context, not all at once and not in the abstract. Do not over-specify ahead of the chapter that needs the detail. Each system below is a heading to grow, not a spec to fill.

The systems to develop, one chapter at a time

1. Traveling companions and battling-partners that grow with the player

The protagonist accumulates a roster that travels and fights alongside her and deepens over the arc — the familiars are the canonical spine of this today (Shell the sustained-bond Water familiar, plus the accumulating bonded rotational roster, each bonded at a specific chapter and carrying per-slot mechanics) [SRC: T3_Familiars_Named # Shell] [SRC: T0_Familiar_Registry]. The human side of the traveling roster is anchored by the healer's child, who joins as the primary human companion at Ch 13 [SRC: T3_Core_Characters # The Healer's Child]. What is not yet defined: how a companion or battling-partner grows with the player mechanically (bond progression, shared-combat behavior, how a partner's capability scales alongside the protagonist's), and how that growth reads across the age-stage progression. Develop per-chapter as each new companion or familiar bond lands, keeping per-slot mechanics deferred to the registry until the node needs them, exactly as the current spine entries already defer them.

2. Supporting-character, NPC, and faction relationships

Around the traveling roster sits the wider web — teaching NPCs, recurring supporting characters, and factions whose standing tracks the protagonist's treatment of specific groups, villages, and organizations [SRC: T1_Integrity_Paths_Worldstates_Master # 8.7]. Faction standing already has a canonical frame (it updates independently per faction, interacts with but is distinct from integrity, and gates certain questline entries) [SRC: T1_Integrity_Paths_Worldstates_Master # 8.7]. What is not yet defined at the per-chapter layer: how relationship accumulators for named supporting characters advance and decay, how a relationship gate opens or closes downstream content, and how the found-family layer (the recurring teaching communities each chapter leaves behind) is tracked as a persistent relationship state. Develop per-chapter as each node's ally roster and faction list are authored; the per-chapter faction lists and relationships are already owned by the ChapterDesign brief and the region page, which is where this detail belongs [SRC: T1_Integrity_Paths_Worldstates_Master # 8.7].

3. The assimilation mechanic

The protagonist assimilates into each culture, hiding what she is, and builds her relationships from inside the community rather than as a stranger. This is now anchored as a first-class integrity mechanic — the assimilation-integrity choice — coupling the identity-concealment arc to the integrity, path, faction, and mark systems [SRC: T1_Integrity_Paths_Worldstates_Master # 5.5]. The concealment arc-state itself (identity_hiding_status, identity_hiding_pressure) is owned by the Story Spine build logic and carried in every spine entry [SRC: T99_Story_Spine_Build_Logic # 9.6]. What is not yet defined: how assimilation is expressed as playable action moment to moment (how a player earns and holds a cover, what pressures threaten it, how discovery risk is modeled), beyond the integrity-choice coupling. The canonical first-anchor instance is the Ch 12 Dahomey captive-raiding test [SRC: docs/spine/CH_12.md # Decisions surfaced]. Develop per-chapter as each culture's assimilation beat is authored against the §5.5 architecture; the per-chapter anchors beyond Ch 12 are authored at the cascade and are not pre-assigned [SRC: T1_Integrity_Paths_Worldstates_Master # 5.5].

4. Dialogue-path, integrity, and the mark

The choice layer that binds the others: the canonical six-option dialogue-and-action system (Truly Good, Truly Bad, and the four biography-shaped options), the integrity signal it feeds, and the mark the protagonist leaves on each community — the local, community-specific world-state and faction record of what she did while she was one of them [SRC: T1_Integrity_Paths_Worldstates_Master # 6] [SRC: T1_Integrity_Paths_Worldstates_Master # 5.5]. The band architecture, the appearance-and-voice coupling, and the world-state mapping are canonically specified [SRC: T1_Integrity_Paths_Worldstates_Master # 4] [SRC: T1_Integrity_Paths_Worldstates_Master # 7]. What is not yet defined at the per-chapter layer: how a given node's specific dialogue paths realize the six options in that culture's register, how the mark is surfaced back to the player at the Ch 59-65 revisits and in the modern arc, and how relationship and faction state modulate which options are available. Develop per-chapter; specific dialogue implementation is already owned by the Story Spine and quest writing scope, and per-chapter integrity consequences by the ChapterDesign brief [SRC: T1_Integrity_Paths_Worldstates_Master # 1.2].

5. Combat mechanics

The per-encounter fight system. Pillar-8 doctrine already binds every fight (blended mode with a primary and secondary verb, a three-axis Patterns-Puzzles-Preparation split that is never 100-0-0, phase escalation that evolves the moveset rather than swapping it, at least two counters per signature attack, and a reward on win and on death) [SRC: docs/spine/CH_12.md # Boss structure] [SRC: T1_Combat_System_Spec], and the combat encounter types including the environmental and atmospheric boss are owned by the combat spec [SRC: T1_Combat_System_Spec]. What is not yet defined at the per-chapter layer: how each node's specific movesets, verbs, counters, and phase escalations are authored, how combat capability scales with the ability tree and the growing companion roster (system 1), and how the difficulty dial (vril-density reach) modulates a given encounter [SRC: docs/proposals/DIFFICULTY_SYSTEM.md]. Develop per-chapter as each boss and encounter is authored against Pillar 8 and the combat spec; the boss personas and per-beat combat detail are already authored per-node and routed per the Care Doctrine (combat never on a protected community) [SRC: T1_CVD_Creative_Vision_Document # 17.1].

Per-chapter development, against a living spine

These systems are developed incrementally, in the context of the quest line that first needs each one, and then enhanced as later nodes surface more of the same system. That cadence only works because the Story Spine is a LIVING backbone, not a frozen one: the 79-node spine (77 chapters + Prologue + Epilogue) is the single aligning structure that every system, registry, and pipeline hangs off of, and it is enhanced per-chapter as the cascade advances while staying the spine that keeps all nodes and pipelines consistent with one another [SRC: docs/CASCADE_RUNBOOK.md] [SRC: docs/SPINE_LIVING_REVISION_LOG.md]. The spine's creative authority remains the Story Spine build logic, with per-section enhancements overlaid as they are authored [SRC: T99_Story_Spine_Build_Logic]. Each system above grows one node at a time; the spine is what holds those per-node increments in alignment across the whole arc.

Scope and status

This is a development-roadmap flag for Josh to shape, not a specification and not a set of rulings. It resolves nothing; it names the systems, their current anchors, and their open questions so they are developed deliberately and consistently as the chapters build. The systems themselves — their mechanics, their numbers, their per-chapter realizations — are Josh's to author, and the cardinal do-not-invent rule binds throughout. As each system is shaped, its home is the owning tier doc (T1_Integrity_Paths for integrity, dialogue, faction, assimilation, and the mark; T1_Combat_System_Spec for combat; T3 and the registries for companions and familiars), with the per-node realization authored into the spine entries at the cascade.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root