Regex Tester mechanism

Model scope

Core JavaScript regex testing is plausible, but the engine description, supported-flag scope, result API, error reporting, offset convention, and zero-length/global-match contract must be specified before the instrument can receive PASS.

• "JS RegExp engine execution (NFA-based matching)" is not a precise or universally correct formula: JavaScript specifies RegExp matching semantics, while engines may use backtracking, hybrid, or other implementations; backreferences and lookarounds are not regular-language NFA operations.
• The supported flag list is incomplete for JavaScript semantics: it omits at least y (sticky), d (hasIndices), and v (Unicode sets, where supported).
• "Flags common errors" is underspecified: the spec does not define which syntax errors, unsupported flags, invalid escapes, or runtime behaviors must be detected and reported.
• Match-list behavior is ambiguous because JavaScript results differ among RegExp.prototype.exec, String.prototype.match, String.prototype.matchAll, and test; especially when g is present and for zero-length matches.

Units and conventions

• There are no physical units.
• Match spans are assumed to use JavaScript UTF-16 code-unit offsets, with an exclusive end offset.
• The pattern syntax and flags are assumed to be JavaScript RegExp syntax, not PCRE, POSIX, ICU, or another flavor.
• With the u flag, matching is Unicode-aware, but JavaScript match indices still refer to UTF-16 code-unit positions.
• A global scan is assumed for match lists and counts; zero-length global matches are assumed to advance according to JavaScript RegExp rules.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "pattern": "cat",
    "flags": "gi",
    "test_string": "Cat scat"
  },
  "expected_outputs": {
    "match_list": [
      {
        "text": "Cat",
        "start": 0,
        "end": 3,
        "groups": []
      },
      {
        "text": "cat",
        "start": 5,
        "end": 8,
        "groups": []
      }
    ],
    "capture_groups": [
      [],
      []
    ],
    "highlighted_match_spans": [
      [
        0,
        3
      ],
      [
        5,
        8
      ]
    ],
    "match_count": 2
  },
  "working": "1. UTF-16 positions in \"Cat scat\": C=0, a=1, t=2, space=3, s=4, c=5, a=6, t=7. 2. /cat/i matches \"Cat\" at start 0, exclusive end 0+3=3. 3. It also matches the final three characters of \"scat\": start 5, exclusive end 5+3=8. 4. Global matching returns 2 matches. 5. 2 matches × 0 capture groups gives capture arrays [], []."
}

Failure boundary

• Division-by-zero is not applicable to this instrument, but an unguarded global zero-length pattern can cause an infinite loop if the implementation does not advance after an empty match.
• Invalid patterns or flags must produce a defined error result rather than a match list.
• UTF-16 offsets can split surrogate pairs when u is absent; the UI must label offsets as UTF-16 code units or explicitly convert them.
• Regexes with catastrophic backtracking can cause severe latency or denial of service; execution limits or cancellation are needed.
• Global matching state can persist in lastIndex when a reusable RegExp object is used, causing surprising results unless lastIndex is reset or managed explicitly.
• The native iOS note is correct: ICU NSRegularExpression is not behaviorally identical to JavaScript RegExp and must not be presented as an equivalent engine.
• The honest label should also disclose that JavaScript engine versions and supported flags can differ, and that match indices and zero-length behavior depend on the selected API contract.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche4/tranche4-results.json