…ap-multi-venue-emitters

fix: register default hyperliquid emitter alias for primary venue

….adoc-guidance

docs: clarify default hyperliquid wallet handling

…rable

The Action struct had pointer fields (Create, Modify, Cancel) which made
it non-comparable in Go. Since OrderWork embeds Action and the typed queue
requires comparable structs, this violated Go's comparability requirements.

The fix removes the pointers and uses value types instead. The ActionType
field already indicates which action is active, making nil checks redundant.

This change:
- Changes Action fields from pointers to values
- Updates all action creation sites to use values instead of pointers
- Removes all nil pointer checks, replacing them with ActionType checks
- Updates all dereferences to use values directly
- Updates test assertions to remove NotNil checks

Resolves Bug #1: OrderWork Comparability Violation as described in
specs/multi_venue_emission.adoc

Fixed compilation errors from the Action struct pointer removal:
- storage/storage.go: Return &action.Create from LoadHyperliquidRequest
- filltracker/service.go: Remove & when assigning to Action fields (4 places)
- storage/sqlite_test.go: Remove nil checks and dereferences for value types

The cloneAction function no longer needs to check for nil or dereference
fields since Action now uses value types instead of pointers. A simple
struct copy is sufficient as Go will copy all value fields.

…y-011CUq9XdzPA2Jj9kyhTqGJK

fix: remove pointer fields from Action struct to make OrderWork comparable

This commit fixes three critical bugs in the scaled order system related to
multi-venue support:

Bug #2: Hard-coded Default Venue in Queries
- Remove venue_id filter from ListScaledOrdersByOrderId and ListScaledOrdersByDeal
- These queries now return records from all venues instead of just the default

Bug #3: Wrong Venue Assignment in InsertScaledOrderAudit
- Change InsertScaledOrderAudit to use venue/wallet from the OrderIdentifier parameter
- Add fallback to default venue for backward compatibility
- Each audit record now correctly reflects the actual submission venue

Bug #4: Missing Venue Context in Parameters
- Update ScaledOrderAuditParams and RecordScaledOrderParams to use OrderIdentifier
- Add Identifier field to orderscaler.Request
- Update BuildRequest to accept OrderIdentifier parameter
- Change applyScaling to accept OrderIdentifier and scale per-venue
- Refactor engine emission loop to scale each venue independently

The key architectural change is moving from "scale once, apply to all venues"
to "scale per-venue" which ensures each venue gets its own audit record with
the correct venue and wallet information.

Note: After pulling this commit, run `go generate ./...` to regenerate sqlc code.

Fixes #2-4

- Update orderscaler service tests to create OrderIdentifier for BuildRequest
- Update storage tests to use Identifier field instead of OrderId
- All tests now properly construct multi-venue identifiers

- Add VenueID and Wallet fields to ScaledOrderAudit struct
- Update convertScaledOrder to populate venue fields
- Fix filltracker reloadDeal to match scaled orders by identifier's venue
- Prevents applying wrong venue's multiplier/size to identifiers

This fixes a bug where ListScaledOrdersByOrderId returns audits from all
venues but filltracker was only using the last one for all identifiers,
causing venue mismatches when different venues have different scaled sizes.

…11CUqG7yAhQWJXAxWWLLa8g

Fix Multi-Venue Scaled Order Architecture

Add scaled_orders table migration to migrateDefaultVenueWalletLocked:
- Clone scaled_orders from old wallet to new wallet
- Delete scaled_orders associated with old wallet

This ensures the scaled order audit trail is preserved when a user
changes their Hyperliquid wallet address, matching the behavior of
hyperliquid_submissions and hyperliquid_status_history tables.

Fixes Bug #1: Missing scaled_orders in Wallet Migration

…igration-011CUogbE1CwSfpsy7mJXZme

fix: scaled orders wallet migration

This commit addresses three bugs related to multi-venue support:

Bug #2 (Medium): Take Profit Reconciliation Doesn't Fan Out
- Changed DealSnapshot.ActiveTakeProfit from *OrderSnapshot to []OrderSnapshot
- Updated snapshot building to collect ALL active take-profits across venues
- Modified ReconcileTakeProfits to iterate and reconcile each venue independently
- Added cancelTakeProfitBySnapshot and reconcileActiveTakeProfitBySnapshot helpers
- Location: filltracker/service.go:156-282

Bug #3 (Medium): Fill Tracker Unbounded Memory Growth
- Added CleanupStaleDeals method to remove completed/inactive deals
- Integrated periodic cleanup (every 10 minutes) in main event loop
- Removes deals with no activity for >1 hour and all orders complete
- Location: filltracker/service.go + cmd/recomma/main.go

Bug #4 (Low): Replay Logic Edge Case
- Documented edge case where venue additions mid-deal may miss replays
- Added inline comment suggesting periodic reconciliation for production
- Location: engine/engine.go:286-292

The take-profit fan-out fix ensures that when a deal has orders across
multiple venues, all venues' take-profits are reconciled correctly,
preventing stale orders on non-primary venues.

The memory cleanup prevents unbounded growth of the fill tracker's
in-memory state by periodically removing fully completed deals.

Updated all test assertions to use the new ActiveTakeProfits slice instead
of the single ActiveTakeProfit pointer. Changes include:
- Replace NotNil checks with Len(slice, 1) assertions
- Replace Nil checks with Empty(slice) assertions
- Access first element via [0] where needed

Updated adjustActionWithTracker to iterate through all active take-profits
when checking if a take-profit already matches the desired position. This
ensures proper handling of multi-venue scenarios where multiple take-profits
may exist.

Critical fixes for multi-venue take-profit reconciliation:

Issue #1 (P1): Each venue's take-profit was being sized to the GLOBAL net
position instead of that specific venue's position. This caused oversized
exit orders (e.g., if venue A had 60 and venue B had 40, both would try
to exit 100, totaling 200 and overshooting inventory).

Fix: Added calculateVenuePositions() to compute net position per venue
by summing filled buy/sell quantities for each venue identifier. Each
venue's take-profit is now correctly sized to match only its position.

Issue #2 (P1): ensureTakeProfit was only called when NO active take-profits
existed. If one venue had an active TP, other venues without TPs would
never get them created, leaving the multi-venue fan-out incomplete.

Fix: Changed logic to iterate through ALL venue positions and reconcile
or create take-profits for each venue independently. Now checks per-venue:
- If venue has position but no TP: create one
- If venue has position and TP: reconcile size
- If venue has no position but TP exists: cancel it

Location: filltracker/service.go:155-215

Critical fix for position calculation:

Problem: calculateVenuePositions was using full OrderIdentifier (including
OrderId with specific BotEventID) as map key. This created separate entries
for each order even if they were from the same venue. For example:
- baseOrder (BotEventID=1) at venue A: +5
- closeOrder (BotEventID=3) at venue A: -5
Result: Two separate map entries instead of one aggregated position of 0

Also, activeTPs map couldn't match against venuePositions because the
OrderIds differed (TP has its own BotEventID).

Fix:
1. Added venueKey struct to key positions by venue+wallet only
2. Modified calculateVenuePositions to aggregate all orders per venue
3. Changed activeTPs lookup to use venueKey instead of full OrderIdentifier
4. Added cleanup loop to cancel TPs for venues with no position

This ensures:
- Orders from same venue aggregate correctly (5 buy + 5 sell = 0 net)
- TPs can be matched to their venue's position for reconciliation
- TPs without positions get canceled
- Each venue's TP is sized to that venue's specific holdings

Location: filltracker/service.go:155-247

Test failures showed that when creating TPs for venues, the code was using
base order OrderIds instead of the take-profit's OrderId.

Problem: In venuePositions map, identifiers come from non-TP orders (base
orders, safety orders, etc). When creating a TP for a venue without one,
passing this identifier meant using the wrong OrderId (e.g., base order's
BotEventID=1 instead of TP's BotEventID=2).

Fix: Added buildTakeProfitIdentifier() helper that:
1. Searches snapshot for any TP order to get the correct TP OrderId
2. Falls back to loading TP metadata from storage
3. Constructs identifier with target venue+wallet but TP's OrderId
4. Returns nil if no TP metadata exists (lets ensureTakeProfit handle lookup)

This ensures:
- Created TPs use the correct take-profit OrderId
- Each venue gets a TP with matching OrderId but venue-specific venue+wallet
- Tests expecting specific TP OrderIds now pass

Fixes failing tests:
- TestUpdateStatusIgnoresOlderTimestamps/recreates_missing_take_profit
- TestEnsureTakeProfitRecreatesAfterStaleSubmission

Location: filltracker/service.go:211-238

Critical bug: calculateVenuePositions was skipping ALL reduce-only orders,
including filled take-profits. This caused venues with fully-exited positions
to still report positive net quantities, leading to infinite TP recreation.

Example of the bug:
  Buy order:    +100 units (filled)
  TP order:     -100 units (filled, reduce-only)

  WRONG (before): Skip TP because reduce-only → venueNetQty = +100
  ReconcileTakeProfits sees +100, creates new TP
  Next cycle: still +100, creates another TP (infinite loop!)

  CORRECT (now): Include TP filled qty → venueNetQty = 0
  ReconcileTakeProfits sees 0, cancels any active TPs

The confusion was thinking we should exclude TPs from position calculation,
but we should only exclude UNFILLED quantities. Using FilledQty automatically
handles this:
- Filled TPs: FilledQty > 0, correctly reduces position
- Active TPs: FilledQty = 0 or partial, doesn't affect net calculation

This matches the original behavior where snapshot.Position.NetQty included
all fills (including reduce-only).

Location: filltracker/service.go:246-278

Critical P1 bug: adjustActionWithTracker was comparing individual venue
take-profits against the global Position.NetQty, causing mismatches in
multi-venue scenarios.

Problem:
  Venue A: 60 units position, TP remaining = 60
  Venue B: 40 units position, TP remaining = 40
  Global:  100 units net

  adjustActionWithTracker checks:
    Does 60 == 100? No
    Does 40 == 100? No

  Falls through to sizing logic → tries to set TP.Size = 100
  Oversizes venue TPs until ReconcileTakeProfits corrects them

Root cause: adjustActionWithTracker is called BEFORE fanning out to venues,
so it doesn't have per-venue position data. It only sees global net qty.

Solution: Detect multi-venue scenario (multiple active TPs) and skip the
fast-path sizing logic. Let ReconcileTakeProfits handle all multi-venue
sizing correctly with its per-venue position calculation.

Behavior:
- Single venue (0-1 active TPs): Fast path applies global sizing ✓
- Multi-venue (2+ active TPs): Fast path defers to reconciliation ✓
- ReconcileTakeProfits: Always uses correct per-venue sizing ✓

This prevents the engine from oversizing venue TPs while still allowing
the fast path to work for single-venue deals.

Location: engine/engine.go:524-604

…tion-011CUqSqMgqYrhQuWUx8Usei

fix: resolve multi-venue reconciliation and memory issues