BUG - IDEX L2B Spin phases should use instrument spin phase instead of spacecraft spin phase

[aldo9253]

Description of the issue

Issue 1: Use IDEX instrument spin phase instead of spacecraft spin phase

Problem

idex_l1b.get_spice_data() currently calculates spacecraft spin phase using:

get_spacecraft_spin_phase(query_met_times=met)

The expected quantity is IDEX instrument-frame spin phase

The shared SPICE utility already provides this calculation:

get_instrument_spin_phase(met, SpiceFrame.IMAP_IDEX)

Evidence

• All 13 manually reviewed event times matched L1B records within 0.8 ms.
• CDF phases differed from manually calculated phases by approximately 176°.
• Applying the defined IDEX offset reduced the disagreement to 3.4–4.5° and placed every event in the same 90° bin as the manual calculation.

The remaining few-degree discrepancy should be investigated using identical spin-table, frame-kernel, and spacecraft-clock dependencies.

Recommended changes

1. Confirm that the required quantity is IDEX instrument spin phase.
2. Use get_instrument_spin_phase(..., SpiceFrame.IMAP_IDEX) in L1B.
3. Update L1B and L2B metadata to identify the phase frame explicitly.
4. Add regression tests using known event times and expected instrument phases.

Steps to reproduce the issue

No response

Expected vs Actual behavior

No response

Code Snippet (If applicable)

Code

Additional notes, affected areas, and suggested fixes

No response

[camirian]

Thanks for the detailed evidence on the IDEX spin-phase discrepancy. I’m running a small reproducible AI-assisted engineering experiment using externally specified, public open-source tasks, and this issue appears suitable because the required quantity and the event-based evidence are concrete.

Would you — or an IMAP maintainer interested in this issue — be willing to support a bounded independent evaluation?

The setup would stay lightweight:

• you confirm the intended instrument-frame semantics;
• you retain a small set of hidden event/phase edge cases;
• before I start, you provide only a SHA-256 hash of that hidden test bundle;
• I work from this public issue and visible repository tests without seeing the hidden cases;
• after I freeze the candidate patch, you run the hidden tests and return pass/fail evidence.

No proprietary, private, controlled, or export-restricted data is needed, and there is no obligation to merge anything. The goal is to test whether an implementation generalizes beyond the tests visible to the implementer. Any public write-up would require your agreement.