Strict parsing tests: typescript structural signatures #778

Existing coverage note: this language already has a handful of scattered regression tests in tests/core_engine/test_language_standards_strict.py -- the TypeScript half of test_thermodynamic_operator_collisions (test vs regex_execution) -- covering specific historical bugs. That is NOT the same as this epic's full per-signature template (positive/negative case + ambiguity sweep + ReDoS sweep for every non-None signature), which this language has never received. Fold the existing tests' coverage into (not duplicated by) the new suite where they already cover a signature.

Part of #518.

Language: typescript

• Lexical family: standard_block
• Extensions: .ts, .tsx, .mts, .cts, .d.ts, .d.mts, .d.cts
• 58 of the baseline structural signatures are defined (non-None) for this language in gitgalaxy/standards/language_standards.py.

Reference

gitgalaxy/standards/how_to_add_a_language.md is the canonical doc for what each signature is supposed to capture/exclude, the 5 lexical parsing families, and (recently added) the AI/ML and literate-programming extension packs. Read the INCLUDES/EXCLUDES wording there for any signature before writing its test -- the one-line descriptions below are a quick-reference copy, not the full spec.

A rule being None here is not a gap

Only write tests for the checklist below. If a signature isn't in this language's rules dict, or is explicitly None, that's an intentional "doesn't apply to this language" per the doc's Strict Feature Parity rule (#4) -- don't invent a synthetic match for it just to have a test.

Lexical family note: This language's lexical family is standard_block -- both line (//) and block (/* */) comment delimiters are used, but blocks cannot be nested; confirm dead_code/doc-style rules are wired to both styles, not just one (Engine Rule 12).

Known ambiguity patterns to check for this language

• test vs regex_execution: already found in TypeScript itself (myRegex.test('x') miscounted as a test-framework call) -- an isolated regression test (test_thermodynamic_operator_collisions) already exists; confirm it's absorbed into the full per-signature suite.
• bitwise_ops vs closures: already found in Rust (|a| a + 1 miscounted as bitwise-OR) and C++ (std::cout << miscounted as a bitwise shift) -- check whether TypeScript's => arrow functions or <</>> usage create an analogous overlap.
• func_start vs generics: already found in C# (deeply nested generic return types triggering catastrophic backtracking) -- check func_start/args against deeply nested TypeScript generic syntax (e.g. Array<Array<Array<T>>>).

Checklist (this language's non-None structural signatures)

Phase 1: Logic Topology & Structure

• branch -- Control flow that forces a decision or jump: if, else, switch, for, while, catch, try, &&, ||, ternary.
• args -- Parameter blocks of functions, methods, and lambdas. Must safely step over type hints and generics without ReDoS.
• structural_boundaries -- Keywords defining structural boundaries and straight-line execution: var, return, class, import.
• func_start -- Exact syntax anchoring the start of an executable block of logic: method signatures, constructors.
• class_start -- The syntax defining an object-oriented class, struct, or record.

Phase 2: Safety & Execution Risk

• safety -- Defensive programming constructs that prevent crashes at runtime: try/catch, explicit null checks, guard.
• safety_bypasses -- Syntax that actively bypasses type safety, swallows errors, or relies on unpredictable state: force unwrapping (!), any, raw memory casting, linter bypasses (@ts-ignore).
• high_risk_execution -- Process-killing commands and catastrophic runtime vulnerabilities: eval, exec, process.exit.
• io -- Interaction with disk, network, or external systems: file reading/writing, HTTP clients, sockets.
• api -- Code exposed to the outside world. Captures explicit visibility markers (export, public) AND implicit architectural defaults for implicitly-public languages (Python, Fortran).
• state_mutation -- Reassignment of variables or modifying collections: let, mut, volatile, .push(), .set().
• dead_code -- Commented-out structural code and unused logic trails: // if (x), /* var y */.
• doc -- Structured documentation meant to be parsed by IDEs or generators: JSDoc, docstrings.
• test -- Assertions and unit testing framework keywords: describe, it, assert, expect.

Phase 3: Architecture & Domain Sensors

• concurrency -- Asynchronous logic and parallel execution: async, await, Promise, Thread.
• ui_framework -- DOM manipulation and UI components: HTML tags, React hooks.
• closures -- Anonymous functions, lambdas, inline callbacks: fat arrows (=>).
• globals -- Accessing global state, environment variables, or system registries: window., process.env.
• decorators -- Annotations applied to classes/methods: @Injectable, [Obsolete].
• generics -- Type parameters indicating generic abstractions: , List.
• comprehensions -- Collection iterators or inline looping: .map(, .filter(.
• scientific -- Math, data science, and complex rendering libraries: Math., numpy.
• reflection_metaprogramming -- Metaprogramming, reflection, and dynamic property assignment: Reflection, Proxy, .bind().
• import -- Dependency resolution and module loading (import, require, using), plus the paired capture-group rule that extracts the exact dependency path string for the dependency graph.
• ownership -- Authorship metadata: @author, Created by:.

Phase 4: Specialized Sub-systems

• planned_debt -- Annotated future work: TODO, WIP, STUB.
• fragile_debt -- Explicit admissions of fragile or dangerous logic: HACK, FIXME, XXX.
• spec_exposure -- Audit tags establishing traceability of intent: [SPEC-123], [audit].
• ssr_boundaries -- Server-Side Rendering computation boundaries: getServerSideProps.
• events -- Event-driven architecture signatures and message brokers: emit, EventEmitter, Kafka.
• dependency_injection -- Inversion of Control (IoC) injection markers: @Autowired, @Inject.
• memory_alloc -- Explicit unmanaged memory allocations and raw heap manipulations: malloc, new.

Phase 5: Resource Management & Stability

• telemetry -- Structured logging and observability frameworks.
• debug_prints -- Ad-hoc, temporary debug statements: print(, console.log(.
• explicit_casts -- Explicitly bypassing the compiler's type-checker: as String, (int), static_cast.
• panics_and_aborts -- Forcefully destroying the current execution context: throw, raise, panic!, abort().
• thread_sleeps -- Thread blocking or forced timeouts: sleep(, delay(.
• bitwise_ops -- Bitwise operations manipulating raw bytes.
• sync_locks -- Explicitly coordinating threaded logic to prevent race conditions.
• immutability_locks -- Explicitly locking data so it cannot be mutated: const, final, readonly.
• cleanup -- Explicitly destroying state or releasing resources: free(, dispose(), .close().
• encapsulation -- Explicitly hiding logic from the rest of the application: private, protected, internal.
• listeners -- Waiting to receive state from an external broadcast: on(, addEventListener, subscribe(.
• test_skip -- Bypassed tests or ignored verification specs: @ignore, test.skip(.

Phase 6: Hybrid Domain Sensors

• serialization_parsing -- JSON, XML, YAML parsing libraries.
• regex_execution -- Native regex evaluation commands.
• time_date_logic -- Time/date instantiation and math.
• ipc_rpc_bridges -- Inter-process or RPC bridging commands.

AI/ML Extension Pack (this language carries this pack per how_to_add_a_language.md)

• _named_token_capture -- Capture-group rule that extracts the exact imported symbol name(s) from a from X import Y statement, for dependency-graph precision beyond what the baseline _dependency_capture rule gives you.
• dl_frameworks -- Deep learning frameworks. Includes: tensorflow, torch, keras.
• exfiltration_camouflage -- Outbound HTTP calls disguised as telemetry/metrics/audit traffic. Includes: requests.post/urllib.request/httpx.post whose payload references telemetry/metrics/audit-shaped keys.
• lazy_evaluation -- Generators and deferred-execution constructs. Includes: yield, Generator, Iterator (and their Async* counterparts).
• llm_api -- Direct calls into a hosted LLM provider SDK. Includes: openai, anthropic.
• llm_orchestrator -- Agent/RAG orchestration frameworks. Includes: langchain, llama_index.
• llm_vector_store -- Vector database clients. Includes: chromadb, pinecone.
• ml_traditional -- Classical (non-deep-learning) ML libraries. Includes: sklearn.
• rce_funnel -- Spawning a shell/interpreter subprocess from application code -- a common agentic-tool-use RCE shape. Includes: child_process.spawn/exec/execSync invoking python/bash/sh/node.
• vectorized_math -- Tensor/matrix math operations. Includes: einsum, matmul, tensordot, .dot(, the @ matmul operator.

Test template

For each checked signature: (1) a positive-match test against its documented includes, capturing exact group text where applicable; (2) a negative-match test against its documented excludes; (3) any cross-rule ambiguity check flagged above; (4) a ReDoS immunity test (reuse assert_redos_immune from tests/core_engine/test_language_standards_strict.py) sized to this rule's actual quantifiers. Group multiple signatures that share the same simple pattern into one parametrized test rather than writing near-duplicates -- don't force one test per key if several are trivially similar for this language.

New tests land in tests/core_engine/test_language_standards_strict.py, the existing home for this style of test.