================================================================================
ADDITIONAL GOTCHAS FROM PRIOR ENGINES — FOR CONTRARIAN AUDIT
================================================================================
Date: 2026-03-20
Source: Project brain (prior 2D/3D engine experience)
Target: EQUATIONS_SPEC_v2.txt contrarian audit
Advisory Signal ID: 668 (deposited to Memory Cortex)

================================================================================
GOTCHA [HIGH]: c_eff UNIFORMITY
================================================================================

SpatialSolver must set c_eff=1.0 everywhere when apex_lag_enabled=False.

In the previous 2D/3D engine, there was a bug where the wave propagation
speed was not uniform across the grid when certain features were disabled.
The 4D engine must ensure c is set correctly and uniformly across the entire
4D grid, especially when sweeping c_4D values.

VERIFICATION AGAINST EQUATIONS_SPEC_v2:
  The v2 spec uses a single c per sweep run (not position-dependent). The
  potential term modifies effective dynamics but c itself is uniform.
  AUDIT_REPORT_v2 Finding: RESOLVED.

  HOWEVER: The contrarian should verify that when the potential term
  omega_0^2 * psi * (1 + A(x)/A_ref) is active, the EFFECTIVE propagation
  speed is still uniform. The term A(x)/A_ref creates a position-dependent
  mass-like term that modifies the local dispersion relation. While this
  is physically correct (it's in the Lagrangian), it means the effective
  wave speed varies spatially. This is NOT the same bug as the prior engine
  (which had c itself non-uniform), but it's worth documenting that the
  effective speed varies by design.


================================================================================
GOTCHA [MEDIUM]: CFL AND RUNTIME
================================================================================

SpatialSolver CFL with r_apex=0.01, n_theta=64 gives dt~5e-4 in prior engine.
Batch 4E takes 2-3+ hours on VPS.

In 4D, the CFL stability condition is TIGHTER:
  dt < h / (c * sqrt(d)) where d=4, so dt < h / (2c)

With c_4D up to 1.8c and a 32^4 grid:
  h = 6.0/32 = 0.1875
  dt < 0.1875 / (2 * 1.8) = 0.052 (basic CFL)
  With safety factor 0.9: dt = 0.9 * 0.1875 / 3.6 = 0.047
  Steps per period (T=1): ~21 steps
  100 periods: ~2100 steps
  1M grid points per step: ~2100 * 1M = 2.1 billion operations
  At ~1 GFlop/s (NumPy single core): ~2 seconds per run

VERIFICATION AGAINST EQUATIONS_SPEC_v2:
  The v2 spec gives dt = 0.03125 (using h=0.125 for N=48 Phase 2 grid).
  For Phase 1 (N=32), h=0.1875 gives a larger dt, so runtime is FASTER.
  Runtime estimates: Phase 1 ~3 seconds/run, 13-run sweep ~40 seconds.
  AUDIT_REPORT_v2 Finding: RESOLVED. Estimates are realistic.

  NOTE: The prior engine's problem (2-3+ hours) was for a DIFFERENT
  geometry (spherical grid with r_apex=0.01, n_theta=64). The 4D engine
  uses a Cartesian grid, which has much simpler memory access patterns and
  better cache performance. The comparison is not directly applicable, but
  the lesson remains: CFL constraints must be computed carefully.


================================================================================
VERIFICATION CHECKLIST FOR CONTRARIAN
================================================================================

1. [RESOLVED] Does the spec account for uniform c across the 4D grid?
   YES — c is a single value per sweep run.

2. [RESOLVED with NOTE] Is the CFL condition correctly stated for 4D?
   YES — dt < h/(2c) is correct (sqrt(4)=2). The modified CFL with
   potential term has a minor conservative algebraic error (New Issue B
   in AUDIT_REPORT_v2) but the error is safe (over-constrains dt by <2%).

3. [RESOLVED] Is grid size vs runtime tradeoff addressed?
   YES — three resolution phases (N=32, 48, 64) with memory and runtime
   estimates for each.

4. [RESOLVED] Is the c_4D sweep (13 runs) feasible on the VPS?
   YES — Phase 1 total sweep ~40 seconds. Phase 2 ~5.4 minutes. Phase 3
   ~17 minutes. All feasible on Hetzner VPS with 4+ GB RAM.

5. [RESOLVED with LIMITATION] Does the spec handle r=0.5 overflow?
   YES — Section 8 implements a thin 5D capture layer (N_5=8, c_5D=2.625).
   LIMITATION: No lateral coupling between adjacent 4D positions in the
   5D layer. Acceptable for Phase 1 energy accounting.

6. [OPEN — NEW ISSUE A from v2 audit] Sign of alpha in curvature-decoherence
   coupling. Does negative Laplacian at energy peaks cause r(x) to increase
   or decrease? The theory says decoherence increases at peaks, which
   requires careful sign convention. This could interact with the c_eff
   uniformity concern if alpha causes the effective wave speed to vary
   spatially in unexpected ways.


================================================================================
CROSS-REFERENCE
================================================================================

Related files:
  - EQUATIONS_SPEC.txt (v1, original spec)
  - EQUATIONS_SPEC_v2.txt (revised spec addressing v1 audit)
  - AUDIT_REPORT_v1.txt (20 original findings)
  - AUDIT_REPORT_v2.txt (v2 audit: 17 resolved, 2 partial, 2 new issues)

Gotchas registered in Memory Cortex:
  - c55af4fc (HIGH): c_eff uniformity
  - 7cd3fccb (MEDIUM): CFL/runtime constraints
  - Advisory Signal 668: Full audit context deposited

================================================================================