-`as` on mismatch must raise a TypeError (not return 0 / pass-through).
-`is` must return `0/1` deterministically (no “unknown → 0” unless it is truly not a match).
3) No hardcode / no new env sprawl
- No “BoxName string match special-cases” except small alias normalization shared with frontend (`IntegerBox`/`StringBox` etc.).
- Do not add new environment variables for behavior.
---
## 2. Design constraint: LLVM harness value representation (key risk)
In llvmlite harness, a runtime “value” is currently represented as an `i64`, but it mixes:
- raw integers (from `const i64`)
- boxed handles (e.g. strings are boxed to handles via `nyash.box.from_i8_string`)
- various call/bridge conventions
Because a handle is also an `i64`, **the harness cannot reliably decide at runtime** whether an `i64` is “raw int” or “handle”, unless the value representation is made uniform.
This means TypeOp parity cannot be achieved reliably without addressing representation.
---
## 3. Recommended implementation strategy (P2): make representation uniform for TypeOp
### Strategy A (recommended): “all values are handles” in LLVM harness
Make every runtime value in llvmlite harness be a handle (i64) to a boxed value:
-`cast/as`: call `is_type_h`; if false, emit a runtime error (use existing “panic”/error path if available) or call a kernel `nyash.panic.type_error` style function (add if missing).
Also update other lowerers incrementally so that values feeding TypeOp are handles (start with the fixture path).
### Strategy B (fallback): keep mixed representation, but document divergence (not parity)
If Strategy A is too large for P2, constrain scope:
- Implement `TypeOp` using compile-time `resolver.value_types` hints.
- Document clearly in Phase 274 README: LLVM harness TypeOp is “best-effort using type facts” and is not SSOT-correct under re-assignment.
This keeps the harness useful for SSA/CFG validation, but is not runtime-parity.
Note: Strategy B should be treated as temporary and must be called out as backend divergence in docs.
- Do not implement a full static type system here.
- Do not add rule logic to the resolver (no “guessing chains”).
- Do not add new environment variables for behavior selection.
- If you must limit scope, limit it by fixtures and document it in Phase 274 README as explicit divergence.
### Fixture rule (important)
To avoid “TypeOp disappeared” false negatives:
- Do not use pure compile-time constants for `is/as` checks.
- Prefer a union value formed by a runtime-unknown branch (e.g. `process.argv().size() > 0`).
- Note: `env.process.argv` is currently not supported on Rust VM, and `env.get` is not linked for LLVM AOT yet; keep harness fixtures minimal unless the required externs are implemented in NyRT.
