Fix #2 Preserve unsigned 64-bit decoded values

README.md

@@ -414,6 +414,34 @@ Fields:
 
 ---
 
+### Raw value representation and precision
+
+`DecodedSignalValue::rawValue` is a C++17
+`std::variant<std::int64_t, std::uint64_t>`. For a valid signal, signed definitions
+produce the `int64_t` alternative and unsigned definitions produce the `uint64_t`
+alternative. Raw values remain exact across their full 64-bit ranges. Check
+`valid` before using the value; an invalid result's default value is not decoded data.
+
+Use `std::get` when the numeric type is known, or `std::visit` to handle both:
+
+```cpp
+std::visit([] (auto raw) { std::cout << raw; }, decodedSignal.rawValue);
+```
+
+This replaces the previous `int64_t` field: consumers that read or print
+`rawValue` directly must handle the variant.
+
+Physical conversion uses the active numeric type:
+`physicalValue = static_cast<double>(raw) * factor + offset`.
+`physicalValue` remains a `double` and is approximate for large integers.
+On usual IEEE 754 binary64 implementations, integers are exactly representable
+through 2^53; above that, some integers round to the same floating-point value.
+For example, unsigned `UINT64_MAX` remains exact in `rawValue`, but converts to
+approximately 18446744073709551616 in binary64 before scaling.
+Use `rawValue` whenever exact integer values are required.
+
+---
+
 ## `DecodedFrameValue`
 
 Represents one decoded frame result.
@@ -839,3 +867,9 @@ DBC parser → DbcDatabase → DecodeDatabase → DbcDecoder
 ```
 
 This gives FrameTap a much better foundation for real use, because both browsing and decoding are supported without forcing one representation to do the other's job.
+
+## Regression tests
+
+See [tests/README.md](tests/README.md) for compiler and qmake commands.
+Tests cover Intel and Motorola extraction, signed and unsigned 64-bit boundaries,
+physical conversion, numeric output, and invalid signal payloads.