# ⚠️ INSTRUCTIONS FOR NEXT AGENT

## CURRENT STATE: 6072.74 (v70, rank ~150)

| Metric | Value |
|--------|-------|
| LB Score | 6072.74 (v70) |
| Models in optimized/ | 16 |
| Total gain over base | ~+30.5 pts |
| Gap to bronze (6100) | ~27 pts |
| Gap to silver (6500) | ~427 pts |

## WHAT HAPPENED IN THIS SESSION

### Task 076 — CRACKED (266/266)! 🎉
Previous best: 202/266. Now: **266/266** (100% accuracy).

**Fixes applied:**
1. Use **8-connectivity** for bar detection (not 4-connectivity)
2. Use **BFS from bar cells** to find all decoration cells (not just 4-adjacent)
3. **Round centroid-relative coordinates to 0.1** to avoid float precision issues
4. Use **2-marker position** to disambiguate among transforms that produce the same bar shape

**Why it can't be ONNX:** Requires connected component detection (8-connectivity) + BFS.
Objects can be adjacent (distance 0 between different bars), so simple separation approaches fail.
CC detection in ONNX requires 100+ nodes and iterative operations → too expensive.

**File:** `task076_solver_266.py`

### Task 219 — Improved (255/265, up from 245)
**Fixes applied:**
1. **Alignment detection** (top vs bottom): overlap heuristic picks correct alignment
2. **Per-row offset**: handles shifted periodic patterns (offset = group_rightmost - template_rightmost_le)

**10 remaining failures:** "Merged row" cases where group rows contain columns from MULTIPLE
template rows merged together. The per-row offset approach gives wrong results for these because
it interprets cols from other template rows as a "shift". Needs a per-row alignment approach
that can detect which template row each group column actually belongs to.

**File:** `task219_solver_255.py`

### Task 398 — Built ONNX but WORSE than base
Built 268/268 correct ONNX model. But scores 10.313 vs base 13.658.
Base model for task 398 is already extremely efficient (770 params, 83K memory).
Our model has 27K params and 2.3M memory — too large.
**NOT VIABLE** — base is too compact to beat.

### Task 157 — Complex, Not Cracked
The rule involves reflecting 5-shapes into a 2-region with column shifts.
The exact reflection/placement rule has non-trivial column mapping that wasn't resolved.
Previous session also noted this as "partially understood" with unexplained column shifts.

## THE PATH TO BRONZE (need ~27 more pts)

**Status of high-value targets:**

| Task | Base | If cracked | Status | Blocker |
|------|------|-----------|--------|---------|
| 76 | 10.34 | ~15-16 | **266/266 solved** | **ONNX needs CC detection** |
| 219 | 8.42 | ~14-15 | **255/265 (up from 245)** | 10 merged-row failures |
| 366 | 7.08 | ~15 | Not started | Complex (backtracking, variable grid) |
| 157 | 9.14 | ~14-15 | Not cracked | Column shift rule unclear |

**Reality check:** ALL remaining high-value targets have ONNX blockers:
- Task 76: needs CC detection (100+ extra nodes, likely still worse than base)
- Task 219: not at 265/265 yet
- Task 366: variable grid size, extremely complex rule
- Task 157: rule not fully cracked

## WHAT TO TRY NEXT

### Priority 1: Task 219 (get to 265/265)
The 10 failing cases are all "merged rows" — group rows contain cols from multiple template rows.
Need a PER-ROW ALIGNMENT approach:
- For each group row, find which template row it BEST matches (by intersection)
- If a group row matches NO single template row well (it merges 2+), need special handling
- The "extension" for merged rows should use the INTERSECTION cutoff (no offset)
- While shifted rows should use the OFFSET approach

Key examples to study:
- Ex 7: group row has [0,1,2,3,4,5], template rows are [0,1,2,3,4,6,8] and [0,1,2,3,5,7,9]
  → Row merges content from both template rows. Extension should be [6,8] and [7,9] (no offset)
- Ex 37: group row has [0,1], template row is [0,3,5,7,9]
  → Shifted pattern. Extension should be [4,6,8] (offset=1)

The DISTINGUISHING FACTOR: in ex 7, col 5 exists in another template row (row 1 has col 5).
In ex 37, col 1 does NOT exist in any other template row.
But this heuristic failed because templates cover all cols 0-9.

### Priority 2: Find new tasks with ONNX potential
Look for tasks where:
- Base model is large (>50KB) but scores low (<12)
- Rule is simple (no CC detection, no variable matching)
- Rule is expressible as coordinate arithmetic

Already scanned all 400 and found nothing easy remains. But look for:
- Tasks where the base model does something inefficient that can be expressed as a single Conv
- Tasks where the grid is very small (3×3, 5×5) and the rule is a lookup table

### Priority 3: Task 76 ONNX (long shot)
If you can figure out a way to do 8-connected CC detection in < 50 nodes (base has 949KB/many nodes),
the gain would be +5-7 points. Some ideas:
- Use repeated dilation (Conv with 3×3 kernel) to propagate labels — needs ~13 iterations for 13×13 grid
- Each iteration is a Conv + comparison, ~5-10 nodes per iteration = 65-130 nodes total
- But the label propagation is tricky in ONNX without dynamic operations

## FILES REFERENCE

| File | Purpose |
|------|---------|
| `task076_solver_266.py` | **NEW** — 266/266 solver (centroid + BFS) |
| `task219_solver_255.py` | **NEW** — 255/265 solver (alignment + offset) |
| `task076_solver_194.py` | OLD — 194/266 (outdated) |
| `optimized/` | 16 models that beat base |
| `score_model.py` | Exact Kaggle scoring replica |
| `onnx_builder.py` | DSL for building ONNX graphs |

## WHAT NOT TO DO

- ❌ Don't upload models without PROFILED scoring vs base
- ❌ Don't use BULK_SCAN estimates — they're often WRONG
- ❌ Don't try quantization (DynamicQuantizeLinear breaks scorer)
- ❌ Don't target tasks with base > 14 (you can't beat them)
- ❌ Don't target tasks with base < 1000 params (task398 shows why)
- ❌ Don't try onnxsim on base models (already done, only 3 improved)
- ❌ Don't build ONNX for tasks needing CC detection (too many nodes)
- ❌ Don't touch tasks 057, 384, 314 (verified worse than base)