Adding skills & isac talent updates

docs/DESIGN_SYSTEM.md

@@ -347,6 +347,22 @@ Selecting equipment opens the searchable real-data catalog and its compatible
 configuration controls. Do not display a prototype option that the current
 loadout schema cannot save.
 
+Calculation readiness belongs at the point of resolution. Mark an incomplete
+matrix cell with a compact red text indicator and status rail, then let the
+cell open the editor that resolves it. The live calculation rail summarizes
+blocked output in one compact row. Do not repeat every missing slot in a large
+error panel. Keep system-owned blockers, such as an unpublished calculation
+profile, visible in that compact summary because the player cannot resolve
+them from a loadout cell.
+
+The builder uses three workbench columns on wide screens, moves the live
+summary below the matrix and editor at intermediate widths, and stacks all
+three regions on narrow screens. Every grid track and editor child must accept
+content shrinkage. At 560px and below, stack attribute picker/value pairs and
+section headings; keep the command actions in two equal columns. Validation
+markers use short visible labels while their full messages remain available
+to assistive technology and pointer users.
+
 Use `--shd-builder-canvas` for recessed equipment fields. Use
 `--shd-builder-selection` with `--shd-builder-selection-border` for the
 selected cell. Preserve button semantics, `aria-pressed`, focus-visible
@@ -922,12 +938,18 @@ attribute/value row pattern. Exotic is a status layered onto a weapon family,
 never a replacement for the family classification. Exotic definitions add a
 dedicated exotic-only talent after the two standard talent pools; their sixth
 augmentation cell communicates that this talent advances to Tier II.
-The exotic talent is owned by exactly one exotic weapon and is authored inline
-inside that weapon editor, never selected from a shared global pool. Its
-engineered sub-panel includes the talent name, shared description template,
-Tier I/II previews, and the shared source-owned mechanic program editor. The Talent
-Registry may display an owned exotic talent for discovery, but routes editing
-back to its weapon rather than opening the shared-talent editor.
+The exotic talent is authored in the Talent Registry under the `Exotic Weapon`
+category. The weapon editor uses the shared searchable assignment pattern to
+reference one registered exotic talent. Each option states whether another
+weapon owns it and whether contributors have documented Tier II. Assigned
+talents remain visible but unavailable to other weapon records. The selected
+talent stays removable from its current weapon.
+
+The Talent Registry owns the exotic talent name, icon, description template,
+Tier previews, and mechanic program. Its explicit Tier II documentation choice
+uses `DOCUMENTED` and `NOT YET DOCUMENTED`. Tier I remains required in both
+states. The registry shows `NOT YET DOCUMENTED` in the Tier II column instead
+of a zero value or synthesized description.
 
 Place shared weapon-category bonuses above the weapon registry in one collapsed
 profile console. Its six category buttons show the three inherited Attribute
@@ -2118,7 +2140,9 @@ control, or shared Trigger lifecycle.
 
 Each source supplies the value columns required by its progression:
 
-- Standard and exotic Talents show Tier I and Tier II.
+- Standard Talents show Tier I and Tier II. Exotic Talents show Tier I and an
+  explicit Tier II documentation state; the editor adds the Tier II value
+  column only when contributors select `DOCUMENTED`.
 - OS Protocol Talents show a base value and may scale an outcome through the
   protocol's zero-to-five upgrade expression.
 - Skill Chip Talents show minimum and maximum values.
@@ -2143,9 +2167,16 @@ technology support; mobile targets remain at least 44 pixels tall.
 The direct-event picker reads the 19 normalized events from the code-defined
 event registry. Use searchable single-assignment because the vocabulary exceeds
 the compact segmented-choice limit. Each branch presents its event, match
-policy and parameters, optional cooldown, state mutations, and outcomes.
-Recipe-generated predicates and weights remain visible in the generated
-script. State rows expose label, agent or target scope, initial value, bounds,
+policy and parameters, optional cooldown, condition, state mutations, and
+outcomes. The branch condition offers `ALWAYS`, `HEALTH BAND`, `EVENT FIELD`,
+and `STATE THRESHOLD` for manual authoring. Event-field conditions expose the
+field path, comparison operator, scalar type, and typed value. State thresholds
+compare an agent-scoped pool with a numeric value. Health bands expose an
+optional inclusive lower Health percentage and a required exclusive upper
+percentage; helper text states how exact thresholds resolve. Predicates outside
+these manual patterns remain preserved, display `ADVANCED`, and stay visible in
+the generated script. State rows expose
+label, agent or target scope, initial value, bounds,
 best-case value, and optional expiry. A state change that writes a target pool
 uses a `STATE OWNER` segmented control with `EVENT TARGET` and `EVENT ACTOR`;
 the selected owner remains visible in the generated script. Outcome rows expose
@@ -2192,10 +2223,13 @@ its state to assistive technology. Focus remains in the active field when the
 generated script refreshes, and reduced-motion preferences remove expansion
 and replacement transitions.
 
-The recipe starter opens with no recipe selected. Keep its count, duration, and
-distance parameters hidden until the author chooses a recipe. Disable `ADD
-RECIPE BRANCH` while the selection is empty, and show `REPLACE PROGRAM` only
-after the author selects a recipe and the current program contains a branch.
+The recipe starter opens with no recipe selected. Keep its count, duration,
+distance, and Health-band parameters hidden until the author chooses a recipe.
+Health-band recipes expose ordered strict upper thresholds and editable band
+labels. Stack each band row on narrow screens and keep its remove action at
+least 44 pixels tall. Disable `ADD RECIPE BRANCH` while the selection is empty,
+and show `REPLACE PROGRAM` only after the author selects a recipe and the
+current program contains a branch.
 
 #### AI mechanic drafting
 

docs/TALENT_MECHANIC_RULES.md

@@ -0,0 +1,114 @@
+# Talent Mechanic Rules
+
+The project owner confirmed these game rules on July 29, 2026. Apply them when
+importing Talents, editing mechanic programs, evaluating combat events, or
+deciding whether a Talent still requires assumptions.
+
+## Shared timed-stack lifecycle
+
+Timed stack pools use one shared duration:
+
+- Gaining a stack refreshes the duration for the full pool.
+- The pool loses all stacks when the duration expires.
+- A qualifying activation at maximum stacks refreshes the duration. The stack
+  count remains at its maximum.
+
+This rule covers Combat Inspiration, Simple Pleasures, Explosive Fury, Injured
+Taunt, Defense Enhancement, Explosive Burst, Unstoppable, Painkillers, Injured
+Concealment, Hypervigilant, Suppressive Fire, Defensive Charge, and Battlelust.
+
+## Trigger definitions
+
+Use these event boundaries:
+
+- **Hit taken:** Count any hit, including a hit absorbed by Extra Health.
+  Friendly Skill healing also counts as a hit.
+- **Healing:** Count each healing event. A heal-over-time effect counts each
+  tick as a separate event.
+- **Extra Health gained:** Count every Extra Health grant, including a grant
+  received while the Agent already has Extra Health.
+- **Reloading:** Trigger on reload completion when the weapon had at least one
+  round to load. A canceled reload does not count. A weapon that loads one
+  round at a time produces one completed-reload event for each round.
+- **Taking damage:** Require Health loss. A hit absorbed by Extra Health does
+  not count as taking damage.
+
+## Talent cooldowns
+
+A Talent starts its cooldown when it activates. A failed chance roll does not
+start the cooldown.
+
+Battlelust can grant no more than one stack per second because a successful
+activation starts its one-second cooldown. Its five-second duration and
+three-stack maximum still allow the Agent to reach three stacks. A successful
+activation at maximum stacks refreshes the five-second duration.
+
+Apply the same activation-only cooldown rule to Explosive Fury and Explosive
+Burst. A trigger that occurs during cooldown cannot activate the Talent.
+
+## Persistent deployed Skills
+
+Inspiration and Crossfire use a binary deployed-Skill state:
+
+- The benefit remains active while the Agent has at least one persistent
+  deployed Skill object.
+- Destruction or timed expiration removes that object from the active count.
+  The benefit ends when no qualifying objects remain.
+- Instant-use Skills do not qualify.
+- Multiple deployed Skill objects do not multiply the benefit.
+
+Ability data must identify whether an ability leaves a persistent deployed
+object. Use that flag instead of inferring deployment behavior from an ability
+name or category.
+
+## Downed allies
+
+Suppression Rescue and Instant Triage activate while a downed ally is within 30
+meters:
+
+- Moving within 30 meters of an ally who is already downed qualifies.
+- Each qualifying presence refreshes the ten-second duration.
+- Leaving the radius or reviving the ally does not cancel the current
+  ten-second duration.
+- The wearer does not count as an ally.
+
+## Emergency Retreat
+
+Emergency Retreat activates whenever at least one enemy is within 20 meters and
+the Talent is off cooldown. The same enemy can activate it again when the
+cooldown ends. Each activation lasts three seconds from its activation time.
+Leaving the radius does not end that active three-second effect.
+
+## Second Wind
+
+Second Wind follows the shared reload-completion rule. Any completed reload
+qualifies when the weapon had at least one round to load. This includes each
+round inserted by a weapon that reloads one round at a time. A canceled reload
+does not qualify.
+
+Resolve the Extra Health amount from the Agent's displayed Firepower when
+Second Wind activates. Include all equipped-item and active-buff contributions
+in that Firepower value:
+
+- Tier I grants Extra Health equal to 600% of displayed Firepower.
+- Tier II grants Extra Health equal to 840% of displayed Firepower.
+
+Second Wind adds its Extra Health to Extra Health from other sources. Its
+five-second duration and five-second cooldown start when it activates. Expiry
+removes only the Second Wind contribution. At the five-second boundary, the
+prior grant can expire as a qualifying reload completion grants a new amount.
+If Second Wind supplies the Agent's only Extra Health, the old amount expires
+and the new amount begins at that boundary.
+
+## Nothing to Lose
+
+Nothing to Lose uses a forward-looking deployment window:
+
+- Each Health-damage instance makes its own 50% activation roll. Damage
+  absorbed by Extra Health does not roll.
+- A successful activation applies to every Skill deployed during the five
+  seconds after that damage instance. Several Skills can qualify during the
+  same window.
+- Calculate each reduction from the Skill's total cooldown after equipment
+  modifiers.
+- A Skill can receive no more than three reductions during one cooldown cycle.

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