weapons

data/weapons.ts

Top-level barrel re-export for the weapons data domain. The legacy import path @/data/weapons is preserved here; the actual implementation, per-weapon specs, helpers, and legendary definitions live under ./weapons/ (a sibling subdirectory). This file declares nothing of its own — it has no runtime logic, no types, no constants, no side effects beyond the re-exports. Consumers should import from data/weapons (this barrel) rather than reaching into data/weapons/* directly.

Source comment is explicit: “Barrel re-export — all weapon types and data now live in ./weapons/. This file preserves the original import path for all existing consumers.”

λ — The crossing surface

Single export { ... } from './weapons/index' block. Every symbol below is a forwarded re-export; nothing originates here.

Type re-exports

Symbol	Origin (inside ./weapons/)	Role
WeaponFamily	_types	Weapon-family tag union (rifle / shotgun / etc.)
TargetMode	_types	Target-selection mode for WeaponBehavior
CollisionMode	_types	Projectile collision rule
WeaponBehavior	_types	Discriminated behavior contract per weapon
ScalingCurve	_types	Stat-scaling curve identifier (linear / curve remap)
AreaMode	_types	Area / radius interpretation mode
WeaponStat	_types	Single-stat record { base, scaling }
SteppedStat	_types	Stepped stat (level-keyed sparse table)
WeaponCoreSpec	_types	Full weapon definition shape (every entry in WEAPONS)
EnemyWeaponDef	_types	Enemy-side weapon-spec shape (consumed by enemy shooters)
WeaponTag	legendaries	Tag identifier used for legendary-pair lookup

Value re-exports — helpers

Symbol	Origin	Purpose
getEffectiveLevel	_helpers	Remap level 1..20 through ScalingCurve
getWeaponStatAtLevel	_helpers	Resolve a WeaponStat at a given level
getSteppedStatAtLevel	_helpers	Resolve a SteppedStat at a given level
getProbabilisticSteppedStat	_helpers	Stochastic variant of getSteppedStatAtLevel
getVfxTier	_helpers	VFX-tier resolution from level
getWeaponDamageMult	_helpers	Damage multiplier including legendary baseline
LEGENDARY_DAMAGE_BASELINE_MULT	_helpers	Constant baseline multiplier applied to legendaries

Value re-exports — catalog

Symbol	Origin	Purpose
WEAPONS	weapons/index	Full weapon array (17 canonical + legendaries appended via spread)
WEAPON_MAP	weapons/index	Record<weaponId, WeaponCoreSpec> built from WEAPONS
WEAPON_ORDER	weapons/index	Ordered weaponId[] for UI display
getExtraProjectiles	weapons/index	Bonus-projectile lookup keyed on weaponId × more_projectiles horizontal level
RARITY_COLORS	weapons/index	UI border / label color map keyed on rarity string
resolveWeaponRarity	weapons/index	Returns 'common' | 'legendary' for a weapon def (flattened rarity)

Value re-exports — enemy weapons

Symbol	Origin	Purpose
ENEMY_WEAPON_STATS	_enemy	Enemy-side weapon stat table

Value re-exports — legendaries

Symbol	Origin	Purpose
LEGENDARY_WEAPONS	legendaries	The 10 merge-result weapon defs
LEGENDARY_PAIR_MAP	legendaries	Map keyed by canonical pair key → legendary id
getLegendaryForPair	legendaries	Lookup helper: two WeaponTags → legendary id (if any)
pairKey	legendaries	Canonical key builder for a tag pair
sortTagPair	legendaries	Sorts a tag pair so pairKey is order-independent

Κ — Consumer contract

• Import path stability. All existing consumers historically imported from @/data/weapons (or relative equivalents). This barrel exists solely to keep that path valid after the per-weapon split into ./weapons/*.ts. Do not change consumer import paths to reach into ./weapons/index or ./weapons/_types directly.
• Type-vs-value split. Type re-exports use export { type X, ... } syntax (inline type modifier on each symbol), so they are erased at build and contribute zero to the runtime bundle. Value re-exports forward at runtime.
• No barrel-private symbols. Anything not in the explicit export { ... } list here is not part of the public surface — consumers must not reach into ./weapons/_types, ./weapons/_helpers, ./weapons/_enemy, ./weapons/legendaries, or per-weapon spec files (./weapons/rifle, ./weapons/shotgun, etc.) from outside this domain.
• Single source-of-truth file. The full forwarding list lives only at ./weapons/index.ts. This top-level barrel re-exports from ./weapons/index (not from each leaf), so adding or removing a symbol requires editing ./weapons/index.ts, not this file.

Σ — What is not re-exported

./weapons/index.ts exports a superset of what this barrel forwards. Symbols defined in ./weapons/index.ts that are not re-exported through data/weapons.ts:

• Per-weapon spec named exports (rifle, shotgun, railgun, missile, lightning, revolver, cannon, mortar, disc, flame, defy, sweep, line, barrier, fire_trail, fire_ring, burst, magnetar, coilgun). These are consumed inside ./weapons/index.ts to build the WEAPONS array; external consumers read them indirectly via WEAPON_MAP / WEAPONS.

The barrel surface is intentionally narrower than the internal subdirectory surface.

Π — Where this flows

• Consumed by: every runtime module that touches weapon data — engine/weapons/*, engine/weapons/archetypes.ts, reward generation, UI ship/weapon screens, mod-grid services, telemetry, balance tooling.
• Reaches: ./weapons/index.ts exclusively. All other ./weapons/*.ts files are transitively reachable only through that index.
• No imports. This file imports nothing — it only re-exports. (Compare ./weapons/index.ts, which imports per-weapon specs to assemble WEAPONS.)

EXTRACT-CANDIDATE

• This file is a one-line barrel (single export { ... } from './weapons/index' block). Once all known consumers have been audited to confirm none rely on the legacy data/weapons path, the file can be deleted and consumers can import from data/weapons/index directly. Until then the file is load-bearing as a compat shim — verify with a repo-wide grep for from .*data/weapons['"] (no trailing /) before removal.
• The re-export list duplicates the export list inside ./weapons/index.ts. Drift between the two surfaces is possible (adding a symbol in weapons/index.ts without forwarding it here makes it inaccessible at the legacy path). A typecheck-time assertion (e.g., a test that imports both modules and confirms key set equality) would catch drift mechanically.
• Type re-exports are flagged via the inline type modifier (type WeaponFamily, type TargetMode, …). Equivalent semantics could be expressed with a single export type { ... } block followed by a separate value export { ... } block, which is how ./weapons/index.ts itself is structured. Aligning the two for consistency is cosmetic but reduces cognitive load when comparing files side-by-side.