Adding skills & isac talent updates

docs/architecture.md

@@ -275,19 +275,25 @@ remain fixed. Each successful save appends a
 `game_data/weapon_bonus_profile.updated` audit event with the complete previous
 and resulting profile.
 
-# Weapon-owned exotic talents
+# Referenced exotic weapon talents
 
 Standard weapon talent pools remain reusable across weapons and use Talent 1 /
-Top or Talent 2 / Bottom. One exotic weapon owns each exotic talent through
-`weapons.exotic_talent_id`.
+Top or Talent 2 / Bottom. Contributors create dedicated talents in the Talent
+Registry under `Exotic Weapon`. The database stores these records as Weapon
+talents with Exotic scope and no standard slot.
 
-The weapon editor creates and updates the underlying normalized `talents`,
-`talent_tiers`, description template, and typed conditional rule together with
-the weapon. Server validation rejects an exotic talent ID owned by another
-weapon and rejects any shared Talent. Converting a weapon back to standard
-clears the relationship and archives its now-unowned exotic Talent. The shared
-Talent Registry rejects exotic Talent creation and editing so contributors
-cannot bypass weapon ownership.
+An exotic weapon references one active exotic talent through
+`weapons.exotic_talent_id`. The weapon editor lists registered exotic talents
+and identifies talents assigned to another weapon. Server validation rejects
+standard talents, inactive talents, and talents already assigned elsewhere.
+Changing or clearing a weapon relationship leaves the previous talent active
+and available for another assignment.
+
+Tier I and its modeled mechanic are required when a contributor saves an
+exotic talent. Tier II may remain undocumented. An undocumented Tier II has no
+`talent_tiers` row or conditional-effect value variant. A later Talent Registry
+edit adds the Tier II projection and mechanic values without changing the
+weapon reference.
 
 # OS Protocol progression
 
@@ -395,9 +401,20 @@ Talent, OS Protocol Talent, Skill Chip Talent, or Specialization tree rank. The
 `source_type` and `source_id` pair identifies that owner. No standalone Trigger
 record or shared Trigger relationship participates in execution.
 
+The builder supplies normalized timeline events to each equipped mechanic.
+`movement_snapshot.values.state` is `immobile`, `moving`, or `sprinting`; the
+mechanic's moving and sprinting scenario controls select that state, with
+sprinting taking precedence. Enabled Skill activation profiles emit
+`skill_deployed` events on the same cadence as Skill calculations and identify
+the deployed ability. An `on_event` Skill modifier applies to that activation
+until the ability's next deployment or the encounter ends.
+
 Each source supplies a fixed value-variant contract:
 
-- Standard and exotic Talents require Tier I and Tier II values.
+- Standard Talents require Tier I and Tier II values. Exotic Talents require
+  Tier I and may omit Tier II until contributors document its game values.
+  Builder calculations use Tier I while an equipped exotic Talent has no Tier
+  II mechanic variant.
 - OS Protocol Talents store a base value. An outcome may use an expression that
   reads `equipment.protocolTalentUpgrades`, from zero through five, so selected
   values can scale to twice the base at upgrade five.
@@ -484,6 +501,15 @@ coefficient to a percentage divides the Attribute value by 100. Evaluation
 fails when the loadout does not supply a referenced Attribute; the runtime does
 not 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.
+
 Continuous restoration resolves the outcome's total when the branch activates,
 then delivers that total at a constant rate over the configured duration.
 Activations create independent streams, overlapping streams add, and restoration