Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@ROADMAP.md`:
- Line 78: The roadmap line about Decimal’s monomorphization gaps is incomplete:
update the sentence referencing Option<Decimal> to state that Option<Decimal>
returned from decimal_div/decimal_from_string and Ordering from decimal_compare
cannot currently be used with match or option_unwrap_or due to monomorphization
gaps; specifically mention Option<Decimal>, decimal_div, decimal_from_string,
decimal_compare, Ordering, match, and option_unwrap_or so readers know both
match and option_unwrap_or are affected.

In `@scripts/check_skill_examples.py`:
- Around line 46-47: The ALLOWLIST dict contains duplicate numeric keys (e.g.,
974, 1274, 1364 and the groups around 99/119-127) so later entries silently
override earlier reasons; fix by collapsing duplicates into a single entry per
key (merge the reasons into one list/string) or rename keys so each line number
is unique, and update any references that expect the original entries (search
for the ALLOWLIST definition and entries named 974, 1274, 1364 and the
99/119-127 groups to perform the merge/rename).

In `@SKILL.md`:
- Around line 556-561: Update SKILL.md examples to document the codegen
limitation for decimal_compare: after the existing line that shows
"decimal_compare(`@Decimal.0`, `@Decimal.1`) -- returns Ordering", add a brief note
that pattern matching (match) on the Ordering result is not yet supported by
codegen (reference Ordering and match) and advise users to avoid match on
decimal_compare outputs; also add explicit example signatures for
decimal_from_string and decimal_div (showing their parameter lists and that they
return Option<Decimal>) alongside the existing warning about Option<Decimal>
usage and mention that Option<Decimal> cannot be used with option_unwrap_or or
match due to monomorphization limitations (reference decimal_from_string,
decimal_div, and option_unwrap_or) so readers see both the functions and their
current restrictions.

In `@spec/09-standard-library.md`:
- Line 1561: Update the note in §9.7.2 to also mention that `Ordering` values
produced by `decimal_compare` suffer the same monomorphization gap as
`Option<Decimal>` (i.e., cannot be used with `option_unwrap_or`/`match` because
the monomorphizer does not produce `option_unwrap_or$Decimal` or the equivalent
for `Ordering`); specifically add `Ordering`/`decimal_compare` to the known
limitation sentence alongside `Option<Decimal>` and the functions `decimal_div`
and `decimal_from_string` so the limitation is complete and accurate.

In `@TESTING.md`:
- Line 36: Update the outdated conformance program counts in the README: change
the phrase "58 small, focused programs" found at the sentence referenced by line
80 to "59 small, focused programs" and similarly update the other two
occurrences (the references currently at lines 307 and 349) to read 59 so all
counts match the actual number of `.vera` files in tests/conformance; ensure any
adjacent text that references the count (e.g., summaries, totals or parentheses)
is updated to use 59 as well.

In `@tests/test_checker.py`:
- Around line 1710-1767: The TestDecimalChecker currently covers only some
Decimal built-ins; add tests in tests/test_checker.py under the
TestDecimalChecker class for the remaining functions (create a pair of tests for
each symbol): decimal_from_float, decimal_from_string, decimal_sub, decimal_mul,
decimal_div, decimal_neg, decimal_compare, decimal_round, and decimal_abs. For
each built-in add one _check_ok case exercising correct types (e.g., calling
decimal_sub(decimal_from_int(2), decimal_from_int(1)) or
decimal_from_float(1.23)) and one _check_err case passing a wrong arg type
(e.g., plain Int or String) asserting the checker returns a "type" (or "expects"
for arity errors) message; name tests descriptively like test_decimal_sub and
test_decimal_sub_wrong_type to match the existing pattern and use the same
_check_ok/_check_err helpers and docstring style so they integrate with the
existing TestDecimalChecker.

In `@tests/test_codegen.py`:
- Around line 8177-8187: The test only checks negation of 42 and misses the -0
path which the browser runtime produces as "-0" string; update tests to include
the zero edge-case by adding an assertion that decimal_neg(decimal_from_int(0))
compares equal to decimal_from_int(0) (via decimal_eq) or add a separate test
function (e.g., test_decimal_neg_zero) that calls
decimal_neg(decimal_from_int(0)) and asserts equality using decimal_eq so the
browser runtime's "-0" is exercised and fails if not normalized.
- Around line 8214-8221: The test test_decimal_to_float is too weak (uses floor)
and should assert exact conversion results: change the assertion to compare
decimal_to_float(decimal_from_int(42)) exactly to 42.0 (or the expected float
representation) and add an exact-string assertion for
decimal_to_string(decimal_from_int(42)) == "42"; also add extra cases for zero
and a negative value (e.g., decimal_from_int(0) -> 0.0 and decimal_from_int(-7)
-> -7.0) to cover edge behavior and composition with decimal_to_string so broken
implementations like 42.9 or "24" fail; locate and edit the test methods
test_decimal_to_float and the related test around decimal_to_string to implement
these exact equality checks.

In `@vera/browser/runtime.mjs`:
- Around line 1373-1463: The decimal helpers currently convert decimal strings
to JS Number in functions like decimal_add, decimal_sub, decimal_mul,
decimal_div, decimal_round, decimal_to_float and decimal_compare which
reintroduces IEEE-754 errors and can produce unnormalized "-0"; instead
implement all arithmetic and rounding using string-based or BigInt-safe routines
(use or expand decStrAdd, decStrSub, decStrMul, decStrDiv and a string-based
round) so operations on values stored in decimalStore never pass through Number;
also normalize results (e.g., convert "-0" -> "0", trim leading zeros, and a
canonical sign/scale) and update decimal_eq and decimal_to_string to
compare/return normalized strings; keep decimal_div returning allocOptionNone()
on exact division-by-zero as before.

In `@vera/codegen/api.py`:
- Around line 1347-1368: The host function host_decimal_from_string duplicates
raw memory access; replace the manual memory reads (the bytes/mem.data_ptr and
raw.decode steps) with the existing _read_wasm_string helper to get the UTF-8
string. In other words, inside host_decimal_from_string (the
wasmtime.Caller-based function handling ptr and length) call s =
_read_wasm_string(caller, ptr, length) and keep the try/except InvalidOperation,
_decimal_alloc(d), and the _alloc_option_some_i32/_alloc_option_none behavior
unchanged; remove the direct mem access lines so the function uses the helper
for consistent WASM memory reads.
- Around line 1497-1511: The host_decimal_round handler can raise
decimal.InvalidOperation when places is extreme; update the host_decimal_round
implementation (registered via linker.define_func for "vera","decimal_round") to
validate or clamp the places parameter and/or wrap the quantize call in a
try/except: fetch d from _decimal_store[h], compute a safe clamped_places (e.g.
limit to a reasonable min/max), build q from that clamped value, call
d.quantize(q) inside try/except catching decimal.InvalidOperation and return a
safe fallback (for example the original _decimal_alloc(d) or an error sentinel)
using the existing _decimal_alloc logic so WASM traps are prevented.

In `@vera/wasm/calls.py`:
- Around line 7305-7314: The Decimal host-import translators that return
heap-backed data (e.g., _translate_decimal_from_string and the other translators
that call _register_decimal_import for Decimal functions returning
Option/Ordering pointers or String pairs) must set self.needs_alloc = True so
the allocator is enabled; after calling _register_decimal_import (the call that
produces wasm_name) and before returning the instruction list, set
self.needs_alloc = True and then return arg_instrs + [f"call {wasm_name}"].
Ensure this change is applied to each translator that registers Decimal imports
which return heap-backed values.

In `@vera/wasm/inference.py`:
- Around line 857-858: _infer_fncall_wasm_type currently doesn't return types
for Decimal builtins; add explicit cases mapping builtin names to the correct
WASM return types: return "i32" for decimal_from_int, decimal_add, decimal_sub,
decimal_mul, decimal_neg, decimal_round, decimal_abs, decimal_from_string,
decimal_div; return "f64" for decimal_to_float; return "i32" for decimal_eq and
decimal_compare; and return "i32_pair" for decimal_to_string. Place these checks
alongside the other builtin handlers inside _infer_fncall_wasm_type (use the
builtin name strings to locate the switch/if chain). Also simplify the
host-import handle check that now does multiple startswith calls (the one
checking Map<, Set<, Decimal) by using a single startswith with a tuple or an
any(...) pattern to make it clearer and consistent.

---

Outside diff comments:
In `@SKILL.md`:
- Line 1576: Update the documentation sentence in SKILL.md that currently reads
"The `tests/conformance/` directory contains 39 small, self-contained
programs..." to reflect the current count by replacing "39" with "59" so it
reads "contains 59 small, self-contained programs..."; locate the exact sentence
mentioning `tests/conformance/` and change only the numeric count.

In `@vera/checker/resolution.py`:
- Around line 80-85: In _resolve_type, treat Decimal as an opaque non-generic
ADT: when name == "Decimal" and te.type_args is non-empty, emit a diagnostic
using the checker’s existing reporting mechanism (e.g. self.diagnostic /
self.report_error) indicating that Decimal does not accept type arguments, and
return the non-parameterised form (AdtType("Decimal", ())) instead of
constructing AdtType with args; otherwise continue returning AdtType("Decimal",
()) as before.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tests/test_codegen.py`:
- Around line 8277-8289: The test test_decimal_compare_less currently only calls
decimal_eq and doesn't exercise decimal_compare; update the test source so it
constructs two decimals via decimal_from_int (as already done) but calls
decimal_compare(`@Decimal.0`, `@Decimal.1`) and checks the returned ordering
(expecting a negative/“less than” result) instead of using decimal_eq; ensure
the assertion uses _run(...) to verify the decimal_compare return value (e.g.,
expecting -1 or whatever the host import returns for less-than) so the test
actually validates ordering and host import wiring for decimal_compare.
- Around line 8263-8275: The test function test_decimal_div_nonzero currently
performs decimal_add/decimal_round and never calls decimal_div; change the test
body so it actually invokes decimal_div (e.g., create `@Decimal` from 10 and 2,
call decimal_div(`@Decimal.0`, `@Decimal.1`) and then check decimal_round(..., 0) ==
decimal_from_int(5)) so the test calls decimal_div and still returns 1 on
success (update the comparison literal from 12 to 5); reference the test
function name test_decimal_div_nonzero, the helper _run, and the functions
decimal_from_int, decimal_div, decimal_round in your edit.
- Around line 8250-8262: The test test_decimal_from_string_valid is wrong
because it never calls decimal_from_string; update the test to invoke
decimal_from_string (not decimal_from_int) with at least one valid string (e.g.,
"0" and "42" or a single valid decimal string) and assert the result is the
expected Some/tag=1 value; use the existing decimal_eq helper (or compare .1/.0
as the pattern in the test) to verify equality and keep the test name and intent
unchanged so it actually exercises the decimal_from_string API.

---

Outside diff comments:
In `@README.md`:
- Line 515: Update the documented release version string from "v0.0.96" to
"v0.0.97" in the README entry that currently reads "Vera is in **active
development** at v0.0.96." so the text matches the PR summary; locate and
replace the exact token v0.0.96 with v0.0.97 in README.md (the human-readable
release/version line).

---

Duplicate comments:
In `@TESTING.md`:
- Line 11: Update the inconsistent conformance program count in TESTING.md so
all mentions read "59" instead of "58": search for occurrences of the phrase
"Conformance programs" and the numeric "58" (notably the lines referenced around
Line 80, Line 307, Line 349 and the ranges around 36 and 117-125) and replace
them with "59" so the table row "| **Conformance programs** | 59 programs across
9 spec chapters, validating every language feature |" and all standalone counts
are consistent across the file.

In `@tests/test_codegen.py`:
- Around line 8177-8187: The test test_decimal_neg only checks neg(42) but omits
the zero edge-case where -0 can surface normalization bugs; update the
test_decimal_neg source to also compute decimal_neg(decimal_from_int(0)) and
assert via decimal_eq that it equals decimal_from_int(0) (e.g., include a
separate equality check or combine into the existing if) so the call to
decimal_neg and decimal_eq covers both 42 and 0 cases when invoking _run.
- Around line 8214-8221: The test_decimal_to_float currently asserts via
floor(decimal_to_float(decimal_from_int(42))) which allows incorrect
implementations; update test_decimal_to_float to assert the exact output value
from _run (use direct equality to 42.0 or appropriate language literal) instead
of wrapping with floor, and add sibling tests that call
decimal_to_float/decimal_from_int for zero and negative cases (e.g.,
decimal_from_int(0) -> 0.0, decimal_from_int(-1) -> -1.0) to cover edge cases;
locate and modify the test function named test_decimal_to_float and any similar
tests around lines referencing decimal_to_float, decimal_from_int, floor, and
_run to replace length/floor-style checks with exact-value assertions for
positive, zero, and negative inputs.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@spec/09-standard-library.md`:
- Line 1513: The spec currently contradicts itself: the "9.7.2 Decimal" section
is documented as implemented but §9.1 still lists Decimal under "Future types"
and §9.7 is titled "Built-in Types (Future)"; update the headings and lists to
be consistent by removing the "Future" marker where Decimal is implemented or
moving Decimal out of the §9.1 "Future types" list and renaming §9.7 from
"Built-in Types (Future)" to "Built-in Types" (or vice versa if Decimal should
remain future), and ensure all references to Decimal across §9.1 and §9.7 use
the same status label so the document is not contradictory.
- Around line 1515-1546: The spec currently claims Decimal provides exact
decimal arithmetic but does not document the browser runtime limitation where
arithmetic operations (decimal_add, decimal_sub, decimal_mul, decimal_div,
decimal_round, decimal_compare) route through Number() and lose precision;
update the spec text around the Decimal description to either (a) scope the
“exact arithmetic” guarantee to the Python/host runtime only, or (b) add a clear
note describing the browser MVP limitation (mention that decimal equality uses
raw string comparison but arithmetic is lossy), list the affected functions
(decimal_add, decimal_sub, decimal_mul, decimal_div, decimal_round,
decimal_compare), and reference the browser runtime migration to an
arbitrary-precision decimal library as the planned fix.

In `@vera/checker/resolution.py`:
- Around line 80-83: The Decimal branch currently drops any type arguments
(returning AdtType("Decimal", ())) instead of rejecting them; update the
resolver in resolution.py so that when encountering name == "Decimal" it checks
te.type_args and raises a resolution/type error if any type arguments are
present (mirroring how Array/Tuple/Map/Set are validated), otherwise return
AdtType("Decimal", ()). Refer to the existing handling of te.type_args in the
Array/Tuple code paths and use the same error-reporting mechanism used elsewhere
in the resolver to produce a clear rejection for parameterised Decimal.

In `@vera/wasm/calls.py`:
- Around line 257-293: These WASM builtin handlers (the call.name checks for
"decimal_from_int", "decimal_from_float", "decimal_from_string",
"decimal_to_string", "decimal_to_float", "decimal_add", "decimal_sub",
"decimal_mul", "decimal_div", "decimal_neg", "decimal_compare", "decimal_eq",
"decimal_round", "decimal_abs") must be gated for non-browser targets; update
the dispatch in vera/wasm/calls.py to detect the target/runtime (use the
existing env/target flag or runtime check) and only return the decimal
translation paths (_translate_decimal_unary, _translate_decimal_binary,
_translate_decimal_div, _translate_decimal_compare, _translate_decimal_eq,
_translate_decimal_round, _translate_decimal_from_string,
_translate_decimal_to_string) when the backend can guarantee exact decimals,
otherwise skip/raise or fall back to non-exact behavior for browser builds so
browser/WASM runs do not expose precision-dependent Decimal builtins.

---

Duplicate comments:
In `@tests/test_checker.py`:
- Around line 1710-1814: Add missing test cases in the TestDecimalChecker suite:
include _check_ok cases for decimal_from_float, decimal_sub, and decimal_mul,
and add corresponding _check_err cases that pass wrong-typed arguments (e.g.,
Int where Decimal is expected) for each Decimal builtin (decimal_from_float,
decimal_from_int, decimal_add, decimal_sub, decimal_mul, decimal_div,
decimal_eq, decimal_compare, decimal_round, decimal_neg, decimal_abs,
decimal_to_string, decimal_to_float) using the same pattern as existing tests
(_check_ok/_check_err with "type" or "expects" assertions); also add a rejection
test asserting that a parameterized Decimal like `@Decimal`<Int> is invalid to
lock in the non-parameterised Decimal rule — place these tests in the
TestDecimalChecker class alongside the existing methods to exercise functions
such as decimal_from_float, decimal_sub, decimal_mul and the resolver edge case.

In `@tests/test_codegen.py`:
- Around line 8276-8288: The test named test_decimal_from_string_valid currently
never calls decimal_from_string (it only uses decimal_from_int), so add a call
to decimal_from_string in the test source and assert the expected result to
exercise parsing/import paths; update the in-test source string inside
test_decimal_from_string_valid to invoke decimal_from_string with a valid string
(e.g., "0" and "42") instead of/in addition to decimal_from_int, then run via
_run and adjust the final assertion to verify the returned tag/value from
decimal_from_string (keep function name test_decimal_from_string_valid, helper
_run, and comparisons to decimal_eq as appropriate).
- Around line 8303-8315: The test test_decimal_compare_less never invokes
decimal_compare but instead only calls decimal_eq; update the test source so it
constructs two decimals with decimal_from_int (as currently done) and calls
decimal_compare on them (e.g., decimal_compare(`@Decimal.0`, `@Decimal.1`)) and
assert the runtime result equals the expected ordering value (e.g., -1 for 1 <
2). Ensure the test uses the decimal_compare call in the function body and that
the final assert in test_decimal_compare_less checks the returned comparison
integer.
- Around line 8289-8301: The test test_decimal_div_nonzero is supposed to
exercise decimal_div but currently uses decimal_add/decimal_round; update the
inline Wig source in test_decimal_div_nonzero to call decimal_div on two nonzero
decimals (use decimal_from_int(10) and decimal_from_int(2)), then assert the
result via decimal_eq (or decimal_round + decimal_eq) to the expected decimal
(e.g., decimal_from_int(5)). Locate the test by name and replace the decimal_add
line with a call to decimal_div and adjust the final decimal_eq check to compare
against the correct expected value.
- Around line 8226-8247: The tests for decimal conversion (test_decimal_to_float
and test_decimal_to_float_non_integer) are too weak—replace the loose
floor/range checks with stricter assertions that validate exact or
tightly-bounded round-trip behavior for decimal_to_float/decimal_from_int and
decimal_to_float/decimal_from_float: assert exact float values where appropriate
(e.g. decimal_from_int(42) -> 42.0), test that decimal_from_float(x) ->
decimal_to_float returns a value within machine epsilon of the original (or
assert exact repr for known literals like 3.14), and add edge-case cases (zero,
negative, large, fractional extremes); similarly tighten any string/format
checks (string_length usage) to assert exact formatted output and length for
known inputs so broken conversions/formatting cannot pass; update test names and
bodies (test_decimal_to_float, test_decimal_to_float_non_integer and the
string-length-related tests) accordingly.

In `@vera/browser/runtime.mjs`:
- Around line 1452-1456: The decimal_eq implementation currently compares raw
strings from decimalStore and thus treats "1" and "1.0" as different; update the
comparison in imports.vera.decimal_eq (or normalize on insert into decimalStore)
to compare canonicalised numeric values instead of raw formatting: either store
a normalized representation when values are inserted into decimalStore (e.g.,
using a Decimal library or a normalization function that strips insignificant
trailing zeros and normalizes scale) or make decimal_eq fetch both entries and
compare their normalized forms (e.g., Decimal.normalize(a) ===
Decimal.normalize(b) or apply the same trimming/scale normalization to both
strings) so numerically-equal decimals evaluate as equal.
- Around line 1388-1391: The browser implementations of decStrAdd, decStrSub,
decStrMul, decStrDiv (and related decimal_compare, decimal_round, decimal_div)
incorrectly convert decimals via Number/Math.round causing precision loss and
wrong rounding/underflow behavior; replace the Number-based approach by using a
proper arbitrary-precision decimal routine (e.g., integrate a small decimal
library like decimal.js/decimal.js-light or implement string/BigInt scaled
arithmetic) to perform addition, subtraction, multiplication, division,
comparison, and rounding directly on decimal strings; ensure decimal_div treats
tiny non-zero divisors (e.g., "1e-1000") as non-zero by using the chosen decimal
implementation’s division and implement Decimal-standard "half" rounding rules
in decimal_round and decimal_compare instead of Math.round/Number conversions.

In `@vera/codegen/api.py`:
- Around line 1494-1505: The quantiser creation (q = PyDecimal(10) ** -places)
can raise outside the try and cause a WASM trap; update host_decimal_round so
the power expression is performed inside the try (or clamp/validate places
before) so both constructing q and calling d.quantize(q) are guarded; modify the
function around _decimal_store, PyDecimal, _decimal_alloc and InvalidOperation
to ensure any exception during quantiser creation falls through to the same
fallback that returns _decimal_alloc(d).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@TESTING.md`:
- Line 73: Update the stale pytest count in the Markdown so both references
match the actual total for test_conformance.py: change the occurrence that
currently reads "290 tests" to "295 tests" so it aligns with the table row for
`test_conformance.py` stating 295 conformance tests.

In `@tests/test_codegen.py`:
- Around line 8271-8310: The two tests test_decimal_from_int_different_values
and test_decimal_inequality duplicate the same check that decimal_eq returns
false for two different decimal_from_int values; keep one as-is (e.g.,
test_decimal_from_int_different_values) and change the other
(test_decimal_inequality) to exercise a non-overlapping edge case: for example,
use decimal_from_int with a negative value, a large value, or compare
decimal_round behavior (use decimal_from_int, decimal_eq, decimal_round or
decimal_add to form the new assertion). Update test_decimal_inequality to
construct that distinct scenario so it no longer duplicates
decimal_eq(`@Decimal.1`, `@Decimal.0`) on two small positive ints.
- Around line 8262-8269: The test test_decimal_from_float uses floor(...) == 3
which is too weak; change the assertion to compare the actual float produced by
decimal_to_float(decimal_from_float(3.14)) against the exact representable float
value (i.e., assert decimal_to_float(decimal_from_float(3.14)) ==
<expected_float_literal>), or capture the result in a variable and assert exact
equality to the language's nearest float representation for 3.14, rather than
using floor.
- Around line 8311-8386: The tests (test_decimal_div_host_called,
test_decimal_from_string_host_called, test_decimal_compare_host_called, and the
related decimal_* tests) only return constants so they don't validate that the
host functions are actually wired; update each test to assert the compiled WAT
or codegen output contains the expected import/call for the host symbol (e.g.,
"decimal_div", "decimal_from_string", "decimal_compare") or the generated
callsite (call/import names used by your codegen), by invoking the test helper
that returns WAT (or adding a helper to compile to WAT) and asserting the
presence of the host import/call pattern for that specific function instead of
just returning a constant; keep the existing runtime assertions for coverage but
add the WAT/assertion check to ensure the host wiring is exercised.

---

Duplicate comments:
In `@tests/test_checker.py`:
- Around line 1712-1750: Add missing wrong-type checker tests: for each existing
happy-path test functions (test_decimal_from_int, test_decimal_eq,
test_decimal_to_string, test_decimal_to_float) add a corresponding
_check_err(...) case that calls the same built-in (decimal_from_int, decimal_eq,
decimal_to_string, decimal_to_float) with an incorrect argument type and asserts
a "type" error; place each new _check_err next to its _check_ok sibling and
ensure the expected error string is "type".

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@spec/09-standard-library.md`:
- Line 1566: Update the spec sentence to clarify that browser `decimal_eq`
performs strict representation equality (string comparison) rather than numeric
equivalence: mention that `decimal_eq` uses exact string comparison of decimal
representations so `"1.0"` ≠ `"1"`, and contrast this with the Python runtime’s
numeric equivalence; reference the browser runtime operations (`decimal_add`,
`decimal_sub`, `decimal_mul`, `decimal_div`, `decimal_round`, `decimal_compare`,
`decimal_eq`) and state that only `decimal_eq` is representation-based in the
browser MVP.

In `@TESTING.md`:
- Line 9: Update the summary row in TESTING.md that currently reads the tests
total as "~32,100 lines of test code" (the table row starting with "| **Tests**
| 2,884 across 26 files") to "~33,100 lines of test code" so the overview
matches the sum of the "Lines" column in the test file table.

---

Duplicate comments:
In `@TESTING.md`:
- Line 149: Update the stale pytest test count in the TESTING.md header that
currently reads "# Via pytest (parametrized — 290 tests)" to the correct total
(295 tests) to match the conformance count stated earlier ("295 conformance
tests (59 programs × 5 checks)"); simply replace "290" with "295" so both
references are consistent.

In `@tests/test_checker.py`:
- Around line 1712-1913: Add negative wrong-type tests for the four Decimal
built-ins that currently only have happy-path tests: decimal_from_int,
decimal_eq, decimal_to_string, and decimal_to_float. For each corresponding test
function (e.g. add test_decimal_from_int_wrong_type, test_decimal_eq_wrong_type,
test_decimal_to_string_wrong_type, test_decimal_to_float_wrong_type) add a
_check_err call that invokes the built-in with an incorrect argument type (e.g.
pass an Int where a Decimal or String/Float64 is expected) and assert a "type"
error; place them alongside the existing test_* functions in
tests/test_checker.py so signature enforcement is covered.