Bracketed text like [PHONE] incorrectly checked as missing-literal

[nullhack]

Description

Text enclosed in square brackets like [PHONE] in Gherkin step text is being incorrectly extracted as a literal value by beehave check, producing false-positive missing-literal errors.

Steps to Reproduce

Given a feature file with:

Feature: Example feature

  Rule: Example rule

    Example: Example scenario
      Given the value in seconds is [PHONE]
      When something happens
      Then the result is 42

And a test:

def test_example_scenario():
    assert 42 == 42

Run beehave check:

missing-literal: literal '[PHONE]' not found in function body

Expected Behavior

Bracketed text like [PHONE] should not be treated as a literal. Like angle-bracket placeholders <name>, square-bracket notation [name] is used to mark dynamic/replaceable values, not spec literals to verify.

Actual Behavior

Beehave treats [PHONE] as a string literal that must appear in the test function body, producing a false-positive missing-literal violation.

Root Cause

_extract_literals in gherkin.py extracts [PHONE] from step text through a code path beyond the _QUOTED_STRING_RE regex. The _QUOTED_STRING_RE pattern (?:"([^"]*)"|'([^']*)') does not match bracket-delimited tokens when the function is called in isolation — but through the parse_feature → _parse_step chained call path, the bracketed text is still extracted as a Literal.