test: cover the reachable paths in negative-literal serialization

The bool-operand test asserted "${-True}", which no HCL input can
produce: UnaryOpRule serializes its operand with inside_dollar_string
set, and LiteralValueRule yields the string "true" in that context.
Assert the helper contract directly instead, and add TestNegatedKeywords
for the path a parse actually takes.

-1e10 lexes as a single FLOAT_LITERAL and never reaches the unary path.
Add the spaced form, which does, and whose operand is a string under
preserve_scientific_notation.

Pin -0 normalization, and add -0 and -true to the integers round-trip
suite. The spaced forms stay out of that fixture because the direct
pipeline normalizes the space away, which would break the byte-exact
direct-reconstruct assertion.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: kkozik-amplify

test/integration/hcl2_original/integers.tf

@@ -5,6 +5,8 @@ locals {
   negative_int = -42
   negative_one = -1
   negative_large = -9876543210
+  negative_zero = -0
+  negated_keyword = -true
   int_calculation = 105 * 3 / 2
   int_subtraction = 10 - 3
   int_negated_reference = -var.count

test/integration/hcl2_reconstructed/integers.tf

@@ -5,6 +5,8 @@ locals {
   negative_int          = -42
   negative_one          = -1
   negative_large        = -9876543210
+  negative_zero         = 0
+  negated_keyword       = -true
   int_calculation       = 105 * 3 / 2
   int_subtraction       = 10 - 3
   int_negated_reference = -var.count

test/integration/json_reserialized/integers.json

@@ -7,6 +7,8 @@
       "negative_int": -42,
       "negative_one": -1,
       "negative_large": -9876543210,
+      "negative_zero": 0,
+      "negated_keyword": "${-true}",
       "int_calculation": "${105 * 3 / 2}",
       "int_subtraction": "${10 - 3}",
       "int_negated_reference": "${-var.count}",

test/integration/json_serialized/integers.json

@@ -7,6 +7,8 @@
       "negative_int": -42,
       "negative_one": -1,
       "negative_large": -9876543210,
+      "negative_zero": 0,
+      "negated_keyword": "${-true}",
       "int_calculation": "${105 * 3 / 2}",
       "int_subtraction": "${10 - 3}",
       "int_negated_reference": "${-var.count}",

test/unit/rules/test_expressions.py

@@ -469,8 +469,22 @@ def test_force_parens_keeps_expression_form(self):
         self.assertEqual(rule.serialize(options=opts), "${-3}")
 
     def test_boolean_operand_is_not_treated_as_a_number(self):
-        rule = self._make_unary("-", True)
-        self.assertEqual(rule.serialize(), "${-True}")
+        """`bool` subclasses `int`, so without the guard `-true` would serialize to -1.
+
+        Asserted against the helper rather than `serialize()`: no HCL input can
+        route a Python bool here, because `UnaryOpRule` serializes its operand
+        with `inside_dollar_string` set, and `LiteralValueRule` yields the string
+        "true" in that context. See `TestNegatedKeywords` for the parsed path.
+        """
+        options = SerializationOptions()
+        self.assertIsNone(UnaryOpRule._negate_numeric_literal("-", True, options))
+        self.assertIsNone(UnaryOpRule._negate_numeric_literal("-", False, options))
+
+    def test_zero_operand_returns_zero_not_none(self):
+        """The caller must test `is not None`; plain truthiness would drop `-0`."""
+        result = UnaryOpRule._negate_numeric_literal("-", 0, SerializationOptions())
+        self.assertEqual(result, 0)
+        self.assertIsNotNone(result)
 
 
 # --- ExpressionRule._wrap_into_parentheses tests ---

test/unit/test_api.py

@@ -327,7 +327,51 @@ def test_parenthesised_negation_is_still_an_expression(self):
         self.assertEqual(loads("x = -(3)\n"), {"x": "${-(3)}"})
 
     def test_scientific_notation_is_unaffected(self):
+        """`-1e10` never reaches the unary path: it lexes as a single FLOAT_LITERAL."""
         self.assertEqual(loads("x = -1e10\n"), {"x": "${-1e10}"})
 
+    def test_spaced_negation_of_scientific_notation_stays_an_expression(self):
+        """The spaced form *is* a unary op, and its operand is a string.
+
+        `preserve_scientific_notation` (on by default) keeps `1e10` as source
+        text, so there is no number to negate and the expression form stands.
+        """
+        self.assertEqual(loads("x = - 1e10\n"), {"x": "${-1e10}"})
+
+    def test_spaced_negation_of_integer_is_still_a_number(self):
+        self.assertEqual(loads("x = - 3\n"), {"x": -3})
+
+    def test_negative_zero_normalises_to_zero(self):
+        """`-0` is 0. The dict path drops the sign; the direct path keeps the source."""
+        self.assertEqual(loads("x = -0\n"), {"x": 0})
+        self.assertEqual(dumps(loads("x = -0\n")), "x = 0\n")
+
     def test_round_trip_through_dumps(self):
         self.assertEqual(loads(dumps(loads("x = -3\n"))), {"x": -3})
+
+
+class TestNegatedKeywords(TestCase):
+    """`-true` is not arithmetic, so it stays an expression.
+
+    This is the parsed counterpart to the `bool` guard in
+    `UnaryOpRule._negate_numeric_literal`: a keyword operand is serialized with
+    `inside_dollar_string` set and so arrives as the string "true", never as a
+    Python bool. Without that distinction `bool` subclassing `int` would turn
+    `-true` into -1.
+    """
+
+    def test_negated_true(self):
+        self.assertEqual(loads("x = -true\n"), {"x": "${-true}"})
+
+    def test_negated_false(self):
+        self.assertEqual(loads("x = -false\n"), {"x": "${-false}"})
+
+    def test_negated_null(self):
+        self.assertEqual(loads("x = -null\n"), {"x": "${-null}"})
+
+    def test_not_operator_on_keyword(self):
+        self.assertEqual(loads("x = !true\n"), {"x": "${!true}"})
+
+    def test_bare_keywords_are_still_python_values(self):
+        """Outside an expression the keywords keep their Python mappings."""
+        self.assertEqual(loads("x = true\ny = false\nz = null\n"), {"x": True, "y": False, "z": None})