Updating mechanics for OS protocols

docs/architecture.md

@@ -584,6 +584,9 @@ state, with sprinting taking precedence. Enabled Skill activation profiles emit
 the deployed ability. An `on_event` Skill modifier applies to that activation
 until the ability's next deployment or the encounter ends.
 
+`skill_deployed.values.abilityId` and `skill_hit.values.abilityId` identify the
+same ability for mechanics that bind an effect to the next deployed Skill.
+
 Each source supplies a fixed value-variant contract:
 
 - Standard Talents require Tier I and Tier II values. Exotic Talents require
@@ -631,11 +634,11 @@ timestamp.
 the hit resolved. A producer omits the field when it lacks authoritative aiming
 state; the runtime does not replace missing evidence with a scenario assumption.
 Predicates compare this field explicitly with `true` or `false`; negation and
-inequality cannot turn missing evidence into a match. A weapon-hit event may
-also include an event-target-centered area sample. The bounded sample lists up
-to 256 valid ally and enemy entity IDs with their distances from the hit target
-and includes that target as an enemy at zero meters. Duplicate IDs, negative
-distances, or a missing center target invalidate the evaluation.
+inequality cannot turn missing evidence into a match. A `weapon_hit` or
+`skill_hit` event may include an event-target-centered area sample. The bounded
+sample lists up to 256 valid ally and enemy entity IDs with their distances from
+the hit target and includes that target as an enemy at zero meters. Duplicate
+IDs, negative distances, or a missing center target invalidate the evaluation.
 
 `extra_health_changed` is Agent-scoped. Normalized timeline producers emit it
 when the Agent receives an Extra Health grant, when the remaining amount
@@ -730,11 +733,13 @@ substitute zero.
 The read-only `combat.currentHealthPercent` reference divides resolved current
 Health by resolved maximum Health and returns a value from 0 through 100. The
 runtime derives it when a predicate is evaluated instead of storing a second
-Health value that could become stale. Current timing observes deterministic
-resource changes from earlier branches at the same event. Health-band mechanics
-use strict upper bounds and inclusive lower bounds, so bands do not overlap and
-an exact threshold enters the next weaker band. Maximum-potential evaluation
-applies the same predicates before emitting passive outcomes.
+Health value that could become stale. Pre-event timing reads the combat snapshot
+before mechanic branches process the event. Current timing observes
+deterministic resource changes from earlier branches at the same event.
+Health-band mechanics use strict upper bounds and inclusive lower bounds, so
+bands do not overlap and an exact threshold enters the next weaker band.
+Maximum-potential evaluation applies the same predicates before emitting passive
+outcomes.
 
 Continuous restoration resolves the outcome's total when the branch activates,
 then delivers that total at a constant rate over the configured duration.
@@ -876,17 +881,18 @@ applicable, default value, and best-case value. ISAC retains these definitions
 for continued mechanic authoring. Current Builder and shared Build pages do not
 render or evaluate them. Their calculation panels display `COMING SOON` instead.
 
-Loadout schema version 5 stores one focus, selected tree ranks, nine Skill
-Chips, a unified conditional-effect state map, encounter assumptions,
-per-ability activation controls, and `calculationMode`. Runtime readers accept
-the exact version 5 structure. The schema retains its simulation fields, but the
-current player UI ignores them. Version 4 is obsolete prototype data. A
-backed-up prototype migration removes version 4 drafts, saved builds, and
-calibration snapshots instead of translating them.
+Loadout schema version 6 stores one focus, selected tree ranks, nine Skill
+Chips, independent T1/T2 choices for each equipped gear and weapon Talent, a
+unified conditional-effect state map, encounter assumptions, per-ability
+activation controls, and `calculationMode`. Runtime readers accept the exact
+version 6 structure. A backed-up migration translated version 5 equipment
+Talents from their previous equipment-tier-derived behavior. The schema retains
+its simulation fields, but the current player UI ignores them. Version 4 remains
+obsolete prototype data.
 
 ## Planned player calculation modes
 
-Loadout v5 defines `maximum` and `custom` modes for the planned simulation UI:
+Loadout v6 defines `maximum` and `custom` modes for the planned simulation UI:
 
 - Maximum mode supplies each scenario input's best-case value, selects peak
   conditional-effect state, and runs selected abilities on cooldown against