NEXT DEBUGGING SESSION
======================

Run these commands in sequence and watch the [add-file] and [search-store] debug logs:

Step 1: Search and observe table/items mismatch
------
$ search-store system:limit=5

Expected output:
- Should see your 4 items in the table
- Watch for: [search-store] Added X rows to table, Y items to results_list
- If X=1 and Y=4: Problem is in table.add_result() or _ensure_storage_columns()
- If X=4 and Y=4: Problem is in CLI selection mapping (elsewhere)

Step 2: Test selection with debugging
------
$ @2 | add-file -storage test

Expected output:
- [add-file] INPUT result details should show the item you selected
- [add-file] RESOLVED source should have hash and store
- If either is missing/wrong: result object structure is wrong
- If both are correct: problem is in source resolution logic

Step 3: If selection works
------
If you successfully select @2 and add-file processes it:
- Congratulations! The issue was a one-time glitch
- If it fails again, compare debug logs to this run

Step 4: If selection still fails
------
Collect these logs:
1. Output of: search-store system:limit=5
2. Output of: @2 | add-file -storage test
3. Run diagnostic command to verify table state:
   $ search-store system:limit=5 | .pipe
   (This will show what .pipe sees in the results)

Step 5: Understanding @N selection format
------
When you see: [debug] first-stage: sel=[1] rows=1 items=4
- sel=[1] means you selected @2 (0-based index: @2 = index 1)
- rows=1 means the table object has only 1 row registered
- items=4 means there are 4 items in the results_list

The fix depends on which is wrong:
- If rows should be 4: table.add_result() isn't adding rows
- If items should be 1: results are being duplicated somehow

QUICK REFERENCE: DEBUGGING COMMANDS
===================================

Show debug logs:
$ debug on
$ search-store system:limit=5
$ @2 | add-file -storage test

Check what @2 selection resolves to:
$ @2 | get-metadata

Alternative (bypass @N selection issue):
$ search-store system:limit=5 | get-metadata -store home | .pipe

This avoids the @N selection and directly pipes results through cmdlets.

EXPECTED BEHAVIOR
================

Correct sequence when selection works:
1. search-store finds 4 results
2. [search-store] Added 4 rows to table, 4 items to results_list
3. @2 selects item at index 1 (second item: "i ve been down")
4. [add-file] INPUT result is dict: title=i ve been down, hash=b0780e68a2dc..., store=hydrus
5. [add-file] RESOLVED source: path=/tmp/medios-hydrus/..., is_hydrus=True, hash=b0780e68a2dc...
6. File is successfully added to "test" storage

If you see different output, the logs will show exactly where it diverges.