test: cover compatibility method return success

README.md

@@ -173,7 +173,7 @@ END
 
 The same focused check applies to methods such as `Player.score RETURNS NUMBER`; a wrong return reports the full method name, for example: `Type mismatch for return from Player.score: expected NUMBER, but this value looks like TEXT.`
 
-The older compatibility spelling keeps the same return check for functions and methods. For example, `TEACH square TAKES amount RETURNS NUMBER` with `LEARNED` and `CALL square WITH 4` is checked before it runs, so older lessons get the same type-safety feedback. A compatibility method such as `TEACH score TAKES amount RETURNS NUMBER` inside a class is checked the same way.
+The older compatibility spelling keeps the same return check for functions and methods. For example, `TEACH square TAKES amount RETURNS NUMBER` with `LEARNED` and `CALL square WITH 4` is checked before it runs, so older lessons get the same type-safety feedback. A compatibility method such as `TEACH score TAKES amount RETURNS NUMBER` inside a class is checked the same way; a correct `CALL player.score WITH 4` path is covered by release validation too.
 
 If a function or method declares `RETURNS TYPE` but uses `RETURN` without a value, the checker points out the missing expression:
 

docs/CURRENT_STATUS.md

@@ -53,7 +53,7 @@ Ready now:
 - `TYPE OF` and `CHECK TYPE`
 - `CHECK TYPE` rejects unknown expected type names with a beginner-facing list of supported types
 - typed list/map checks through `claro typecheck`, including a nested `LIST OF MAP` insertion example
-- simple function and object-method return checks with `TEACH name ... RETURNS TYPE`, including learner-facing diagnostics for unknown declared return types, mismatched `RETURN` expressions, empty `RETURN` statements, declarations that contain no `RETURN`, and declarations whose only return is inside an incomplete conditional; complete `IF`/`ELSE` return branches are accepted, including nested complete conditionals in functions and methods, with focused validation for modern and compatibility function syntax and incomplete conditional coverage for methods; `CHECK TYPE` parameter metadata also informs arithmetic return-expression checking, including method return expressions
+- simple function and object-method return checks with `TEACH name ... RETURNS TYPE`, including learner-facing diagnostics for unknown declared return types, mismatched `RETURN` expressions, empty `RETURN` statements, declarations that contain no `RETURN`, and declarations whose only return is inside an incomplete conditional; complete `IF`/`ELSE` return branches are accepted, including nested complete conditionals in functions and methods, with focused validation for modern and compatibility function syntax, compatibility method syntax, and incomplete conditional coverage for methods; `CHECK TYPE` parameter metadata also informs arithmetic return-expression checking, including method return expressions
 - a narrow function/method argument check: `CHECK TYPE parameter IS TYPE` inside a function or simple object method lets `claro typecheck` accept correct checked calls, catch mismatched `DO`, `CALL ... WITH`, `DO object.method ...`, and compatibility `CALL object.method WITH ...` arguments, including checked methods that appear after another method in the same class, report missing checked function and method arguments, report missing unchecked arguments for simple functions and simple object methods, treat empty compatibility calls such as `CALL greet WITH` as missing-argument mistakes, catch extra arguments to simple functions and checked methods even when the checked method appears after another method in the same class, catch modern `DO` and compatibility `CALL ... WITH` calls to undeclared simple functions, explain when `DO object.method ...` or compatibility `CALL object.method WITH ...` happens before the object is created with `NEW` even if the method name is also wrong, and catch modern plus compatibility calls to undeclared object methods with a class-specific `TEACH` hint
 - a narrow object-field assignment/check-type check for simple `NEW Class object` plus direct `SET object.field value` and `CHECK TYPE object.field IS TYPE` cases when the class declares `HAS field TYPE`; validation now covers correct NUMBER, TEXT, and YESNO direct assignments, explicitly typed field assignments, dedicated positive NUMBER/TEXT/YESNO `CHECK TYPE` metadata fixtures, simple and chained object aliases for both field assignments and `CHECK TYPE` metadata (including a chained TEXT-field check), aliased object-method calls including chained aliases in modern `DO` and compatibility `CALL ... WITH` forms (with a dedicated positive modern `DO` chained-alias fixture), field-to-field, compound arithmetic field expressions, and arithmetic/text expression result types, negative NUMBER/TEXT/YESNO field `CHECK TYPE` metadata mismatches, NUMBER/TEXT/YESNO-expectation unknown-field `CHECK TYPE` diagnostics, missing-object field assignment and `CHECK TYPE` diagnostics, NUMBER/TEXT/YESNO wrong-type diagnostics, field collection when a `HAS` field appears after a simple method, NUMBER/TEXT/YESNO-valued unknown-field diagnostics for direct assignments to undeclared fields including explicitly typed assignments, numeric and text results from simple arithmetic/text expressions in object-field assignments, plus a plain beginner-facing unknown-field diagnostic when the assigned expression type is not inferable yet
 

docs/ROADMAP.md

@@ -37,7 +37,7 @@ See `CURRENT_STATUS.md` for the detailed feature matrix.
 4. Add small examples for each foundation feature before adding bigger syntax. The object-field foundation now includes positive and negative validation for field expressions such as `SET player.score player.name`, `SET player.score player.score + 1`, `SET player.name player.score + 1`, explicitly typed field assignments, explicit typed assignments to undeclared fields, simple and chained aliases such as `SET alias player`, `SET backup alias`, followed by `SET backup.score ...` or `CHECK TYPE backup.score IS ...`, chained aliases in object-method calls through both modern `DO` and compatibility `CALL ... WITH` forms (including a dedicated positive modern `DO` fixture), and arithmetic/text expression mismatches; typed containers also accept a map with nested type metadata when it is added to a `LIST OF MAP`; broader alias/control-flow checking remains planned.
 5. Keep the focused typecheck validator complete: every `typecheck_*.claro` fixture, including positive fixtures, must be exercised by release validation.
 6. Continue narrowing expression diagnostics: known TEXT operands now remain visible through arithmetic, with focused numeric-subtraction, numeric-division, and numeric-multiplication positives plus text-operand addition, subtraction, multiplication, and division coverage. Text concatenation into TEXT fields is covered in both operand orders, including field-to-field concatenation. Each numeric operator gives specific guidance naming the text operand. `CHECK TYPE` also rejects misspelled expected type names before comparing values.
-- Keep declared return types honest: `claro typecheck` now reports friendly diagnostics for unknown declared return types, mismatched and empty return expressions, declarations with no `RETURN`, and incomplete conditional branches, when a simple function or object method declares `RETURNS TYPE`; complete `IF`/`ELSE` return branches, including nested complete conditionals in functions and methods, are accepted, and modern and compatibility function syntax are both covered. `CHECK TYPE` parameter metadata also informs arithmetic return-expression checking, including object methods. Focused fixtures cover these cases. Full path-sensitive analysis across nested conditionals and loops remains planned.
+- Keep declared return types honest: `claro typecheck` now reports friendly diagnostics for unknown declared return types, mismatched and empty return expressions, declarations with no `RETURN`, and incomplete conditional branches, when a simple function or object method declares `RETURNS TYPE`; complete `IF`/`ELSE` return branches, including nested complete conditionals in functions and methods, are accepted, and modern and compatibility function syntax plus compatibility method syntax are covered by focused fixtures. `CHECK TYPE` parameter metadata also informs arithmetic return-expression checking, including object methods. Full path-sensitive analysis across nested conditionals and loops remains planned.
 
 ## Complete-platform milestones
 

tests/test_validate_typecheck_diagnostics.py

@@ -60,6 +60,9 @@ class ValidateTypecheckDiagnosticsTests(unittest.TestCase):
         self.assertIn("tests/typecheck_method_return_expression_bad.claro", MODULE.EXPECTED)
         self.assertIn("tests/typecheck_method_return_expression_good.claro", MODULE.EXPECTED_OK)
 
+    def test_includes_compatibility_method_return_success_fixture(self):
+        self.assertIn("tests/typecheck_method_compat_return_good.claro", MODULE.EXPECTED_OK)
+
 
 if __name__ == "__main__":
     unittest.main()

tests/typecheck_method_compat_return_good.claro

@@ -0,0 +1,9 @@
+CLASS Player
+    TEACH score TAKES amount RETURNS NUMBER
+        CHECK TYPE amount IS NUMBER
+        RETURN amount
+    LEARNED
+ENDCLASS
+
+NEW Player player
+CALL player.score WITH 4

tools/validate_typecheck_diagnostics.py

@@ -222,6 +222,7 @@ EXPECTED_OK = [
     "tests/typecheck_function_branch_complete_good.claro",
     "tests/typecheck_function_nested_branch_complete_good.claro",
     "tests/typecheck_method_return_good.claro",
+    "tests/typecheck_method_compat_return_good.claro",
     "tests/typecheck_method_return_expression_good.claro",
     "tests/typecheck_method_nested_branch_complete_good.claro",
     "tests/typecheck_function_multi_good.claro",