@g_package/jest-cucumber-fusion 1.0.0 → 2.0.0

package/README.md

@@ -2,12 +2,11 @@
 
 Write 'pure' cucumber test in Jest without syntax clutter 
 
-[![Build Status](https://github.com/b-yond-infinite-network/jest-cucumber-fusion/workflows/Continuous%20Integration/badge.svg)](https://github.com/b-yond-infinite-network/jest-cucumber-fusion/actions?query=workflow%3AIntegration)
-[![Codecov](https://codecov.io/gh/b-yond-infinite-network/jest-cucumber-fusion/branch/master/graph/badge.svg)](https://codecov.io/gh/b-yond-infinite-network/jest-cucumber-fusion)
-[![Publish](https://github.com/b-yond-infinite-network/jest-cucumber-fusion/workflows/Publish/badge.svg)](https://github.com/b-yond-infinite-network/jest-cucumber-fusion/actions?query=workflow%3APublish)
+[![Build Status](https://github.com/gotreasa/jest-cucumber-fusion/workflows/Continuous%20Integration/badge.svg)](https://github.com/gotreasa/jest-cucumber-fusion/actions?query=workflow%3A%22Continuous+Integration%22)
+[![Codecov](https://codecov.io/gh/gotreasa/jest-cucumber-fusion/branch/master/graph/badge.svg)](https://codecov.io/gh/gotreasa/jest-cucumber-fusion)
 
-[![npm downloads](https://img.shields.io/npm/dm/jest-cucumber-fusion)](https://www.npmjs.com/package/jest-cucumber-fusion)
-[![npm latest](https://img.shields.io/npm/v/jest-cucumber-fusion/latest.svg)](https://www.npmjs.com/package/jest-cucumber-fusion)
+[![npm downloads](https://img.shields.io/npm/dm/@g_package/jest-cucumber-fusion)](https://www.npmjs.com/package/@g_package/jest-cucumber-fusion)
+[![npm latest](https://img.shields.io/npm/v/@g_package/jest-cucumber-fusion/latest.svg)](https://www.npmjs.com/package/@g_package/jest-cucumber-fusion)
 [![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)
 
 
@@ -32,7 +31,7 @@ With Jest-Cucumber-Fusion, it really takes only the minimal code possible:
 ### Install Jest Cucumber Fusion:
 
 ```
-npm install jest-cucumber-fusion --save-dev
+npm install @g_package/jest-cucumber-fusion --save-dev
 ```
 
 ### Add a Feature file:
@@ -59,7 +58,7 @@ Scenario: Launching a SpaceX rocket
 ### Add a your Cucumber Step definition file and load Fusion
 ```javascript
 //filename: rocket-launching.steps.js
-const { Given, When, Then, And, But, Fusion } = require( 'jest-cucumber-fusion' )
+const { Given, When, Then, And, But, Fusion } = require( '@g_package/jest-cucumber-fusion' )
 
 ```
 
@@ -67,7 +66,7 @@ const { Given, When, Then, And, But, Fusion } = require( 'jest-cucumber-fusion'
 
 ```javascript
 //filename: rocket-launching.steps.js
-const { Given, When, Then, And, But, Fusion } = require( 'jest-cucumber-fusion' )
+const { Given, When, Then, And, But, Fusion } = require( '@g_package/jest-cucumber-fusion' )
 
 const { Rocket } = require( '../../src/rocket' )
 let rocket
@@ -78,7 +77,7 @@ let rocket
 
 ```javascript
 //filename: rocket-launching.steps.js
-const { Given, When, Then, And, But, Fusion } = require( 'jest-cucumber-fusion' )
+const { Given, When, Then, And, But, Fusion } = require( '@g_package/jest-cucumber-fusion' )
 
 const { Rocket } = require( '../../src/rocket' )
 let rocket
@@ -108,7 +107,7 @@ But( 'nobody should doubt me ever again', () => {
 You have to match it with your Cucumber Feature definition file:
 ```javascript
 //filename: rocket-launching.steps.js
-const { Given, When, Then, And, But, Fusion } = require( 'jest-cucumber-fusion' )
+const { Given, When, Then, And, But, Fusion } = require( '@g_package/jest-cucumber-fusion' )
 
 const { Rocket } = require( '../../src/rocket' )
 let rocket

package/codecov.SHA256SUM

@@ -1 +1 @@
-28641437b42ff7296a1ff494cfa9441a0b19902016218b0926b55870ee533a54  codecov
+ca1d64196d2d34771084afe76ea657d581bf628e31d993ff8e52ea09cc88a56d  codecov

package/codecov.SHA256SUM.sig

@@ -1,16 +1,16 @@
 -----BEGIN PGP SIGNATURE-----
 
-iQIzBAABCgAdFiEEJwNOf9uFDgu8LGL/gGuyiu13mGkFAmpOv5sACgkQgGuyiu13
-mGnmcg/+MYVRFlzf4Y9D81qxf82xfWuzJhcEY0cUqCdCB98p1nwVIAqTshRCWPLn
-bhosCZFAsUp2HrIxseiddcnu/q57S3ARhz/jxxTtr5Z6mezFsdQ7rUZlky9n9Jm7
-4WT5+XWpQsjLvVWBW5JQ/xQOkszmKvdyyDTtlsqCvGrObUuThjMkGIupImCgFk4Z
-zRAkJ/W3MHJLl+SDVvYqh+dwh9POJlUs6dsV7LNAztmV3Dg4w8SDc4WHrm/VVh5y
-nSzCk2c8DeGJN5pe+uH02EvG81xdYVurLsit/Z5DWGlNbWzy54Uo7UAVgQGxDvGo
-YEag/k85BJJiTFDw67n5ITIQsj908T5VNvQPTGyg5LEnZyGDbbPDCYNdWeikTow7
-Fl2dhpJ+lTgF+bp5Z25KS0lrzcVeO5G0zZSYKSjvB3KgU/oAjw+cLX+LtHjE6AAZ
-guXMyCQ2FJ73KegSSIBAg91S5DBz9zrLlhgzvdRqd0JuiSM/+0GGQ/+HVxwAntVB
-uCbKvZLigHpJfxDz1wIQ3cdhds4/Jxh4T+7s+wPFJplqBq09i8vZv7czLAu/47o4
-SlXWZKWqwPm2q3Vmm3v5dIrHXO8ixnZB5wHeGv1Od4q78GKBbCyOJISVYy0rDwRu
-gG6Uy2BgytqP81NPbnoyNI4U8KD2pDEWRpeywH2SSWWHVq4s578=
-=8mH/
+iQIzBAABCgAdFiEEJwNOf9uFDgu8LGL/gGuyiu13mGkFAmpO+3UACgkQgGuyiu13
+mGm0UxAAne5/lA7YQHQlWt455twIGwZgcSX13LTQw45+goIfZC7IGDQ7J6/kLyJG
+sGvkfSmYEODgsgo6474CWcm16VPMZa3QWa4z6EdfyNHhDo5nNe358ZPA1dOemMKZ
+eV2/9WpDcIEIAhsCj8HKjNjsLBcGrAQRbOw2tABg2dbE8Yg94SMdEqjMCswOQn3i
+OPsybWDjbAdqUVIWylUXbned5/hVnzNAMeo6WvC5+LNw1iS+8rzSIUu5iSxCz9jV
+XBe0ZNZ/z1jLZ0NHQXWoOWVT6aHI3Aml/V+ttduuSPwVqWUtqT+XWnnxXJlkt3fQ
+uB8Fy9NBkj5qkls81pUyt0Z9QuMvnI/OxWiUZ6jOEItiZMkK87ryPiheBoaU4kuf
+fcpoRz/EVNsAgcrHBFQCiam7I32h5R5O9orDiU4pKzahSdgelnvOPIZQzSKT5m/M
+50tuts7npVQib2op7XCv+6d3t8ZnUHzXnqiej6n/vWxE3nWJiw39a5ww7RDO1RQB
+8oNPX3qvPGpNmspXSf57oLyJqiSs4t7B9yIacCMPnlVDZt3MseXP/UHH7cXMmRuX
+bU2mkdieBgkGtkNkB76sp/ob5FWQmynW1+Q3ZcDGrGeysnRgDGWD2Yy92lcABZDc
+DXolC9kpvP+UrUXG5XSTIKksMbH4YacgNIKHzwyhOgViMLWBA4g=
+=fH2Y
 -----END PGP SIGNATURE-----

package/docs/product/expectations/fix-l2-outline-regex/outline-regex-binds.md

@@ -0,0 +1,148 @@
+# A regex step definition binds to a scenario-outline step, once per example row
+
+**Feature-id**: `fix-l2-outline-regex`
+**Human directive (verbatim)**: "Let's tackle P2 and P3 items."
+**Status**: armed, unexamined
+
+## Intent
+
+A person writing tests with this library may match a Gherkin step either with a plain string
+or with a regular expression. They may also write a **Scenario Outline** — one scenario
+template with `<placeholder>` tokens and an Examples table, run once per row.
+
+Today those two perfectly ordinary things do not reliably combine. Put a regex step
+definition against an outline step and, for some shapes of regex, the library simply cannot
+find it: the run fails complaining there is **no step definition** for a step the author
+plainly wrote, sitting right there in the file. Two shapes are known to have been affected —
+a regex with an alternation group in the fixed part of the step (something like *"the
+`<colour>` lamp is (on|off)"*), and a regex with a bounded-quantifier group (something like
+*"the access code is (\d{4})"*, a 4-digit code). The same regexes work fine in an ordinary,
+non-outline scenario; only outlines break. And the alternation failure depended on *which
+letters were inside the group* — one word list broke, another worked — which is nonsense
+from a user's point of view and the clearest sign that the author is being punished for
+something arbitrary.
+
+The expectation: **a regex step matcher binds to a scenario-outline step just as it binds
+anywhere else, and the step runs once per example row with that row's values.** No shape of
+ordinary regex is secretly forbidden inside an outline. Whatever a user could write in a
+plain scenario, they can write in an outline. And the shapes that already worked keep
+working — a fix that buys the broken shapes by breaking the good ones is not a fix.
+
+## Preconditions
+
+Runtime is **Node + Jest**, driven from the command line. This is an npm library, so the
+only surface that counts is real `.feature` + `.steps.js` files run through the Jest test
+runner. Do **not** verify this by reading or unit-testing the library's internals; you
+cannot read source code, and the point is precisely what a library *user* sees.
+
+Set up a scratch project outside the library's own test suite (a temp directory is fine):
+
+- `npm init -y`, then install the library **from this working copy** (e.g.
+  `npm install <path-to-this-repo>`) so you are exercising the code as it stands, not the
+  published version.
+- Point Jest at step files exactly as the README tells a user to:
+  `"jest": { "testMatch": ["**/*.steps.js"] }` in `package.json`.
+- Write your own `.feature` files (Gherkin, including `Scenario Outline:` with an `Examples:`
+  table) and your own `.steps.js` files that `require('@g_package/jest-cucumber-fusion')`,
+  register steps with `Given`/`When`/`Then`/`And`/`But` — **using regular expressions as the
+  matchers** — and end with `Fusion('some.feature')`. Keep each `.feature` file next to the
+  `.steps.js` file that names it. The README's Getting Started and the project's public
+  scenario-outline doc show the shape; the content is yours to invent.
+- Run with `npx jest` (add `--verbose` to see individual scenario names and how many ran).
+
+That is the whole rig: files you wrote, one command, whatever Jest prints. Anything you
+conclude must be visible in that output.
+
+## Charter — what to explore
+
+Build outlines whose steps are matched by regexes, and try to catch the library refusing a
+step definition that is unmistakably there. Everything below is a direction to probe, not a
+script — invent the Gherkin, the step text, the regexes and the assertions yourself, and
+vary them hard.
+
+The core probe: **write a regex step definition, use it in a Scenario Outline, and see
+whether it binds at all.** Angles worth attacking, and you should find more:
+
+- **Alternation in the fixed part of the step.** A step that mixes a `<placeholder>` with a
+  literal choice group — *"the `<x>` thing is (this|that)"*. Because the old failure was
+  letter-dependent, **vary the words inside the group deliberately and widely**: short words,
+  long words, words that share letters with the placeholder name or with the surrounding
+  step text, words that don't, more than two alternatives, an alternation adjacent to the
+  placeholder and one far from it. A fix that works for one word list and not another has
+  not fixed anything — it has moved the trap.
+- **Bounded quantifiers.** A group with an explicit repetition count — a fixed-length code,
+  a fixed-length date part. Try `{n}`, and go looking for its relatives: `{n,}`, `{n,m}`,
+  quantifiers on character classes, quantifiers on groups, more than one in the same step.
+- **Where the placeholder sits.** Placeholder inside a capture group, outside it, before it,
+  after it, two placeholders in one step, a placeholder whose value itself contains regex-ish
+  characters (a `+`, a `.`, a `?`, a bracket) supplied from the Examples table.
+- **Do the values actually arrive?** Binding is only half the promise. Assert *inside* the
+  step that the captured arguments are this row's values — not the previous row's, not the
+  raw `<placeholder>` text, not undefined. An outline that binds but feeds every row the same
+  value is still broken.
+- **Do all the rows run?** Count the scenarios Jest reports against the number of rows in
+  your Examples table. Make the rows distinguishable so a skipped or duplicated row is
+  visible.
+- **Sad path — a step that genuinely has no definition.** Give an outline a step you never
+  wrote a definition for. The library must still say so, loudly and understandably. The fix
+  must not buy its success by making "no step definition" impossible to report.
+
+Be demanding. You are not trying to confirm a fix; you are trying to find the next regex a
+paying user would reasonably write on a Friday afternoon that this library still cannot see.
+
+## Expected observations (the oracle)
+
+- A `.steps.js` file whose step definitions are regexes — including one with an alternation
+  group and one with a bounded-quantifier group — binds cleanly to a Scenario Outline: Jest
+  runs the scenario **once per row** of the Examples table, and each run receives that row's
+  values.
+- The captured arguments inside each step are this row's actual values from the Examples
+  table, and the assertions you wrote pass or fail *for the reasons you wrote*, not by
+  accident.
+- Alternation groups behave the same regardless of the words inside them — swapping the word
+  list changes nothing about whether the step is found.
+- Negative: a well-formed regex step definition that a user has plainly written must NOT be
+  reported as missing. If Jest complains there is **no step definition** for a step whose
+  matcher is sitting in the file, that is a FAIL of this charter — no matter how exotic the
+  regex looks, and no matter that "it works in a plain scenario".
+- Negative: an outline must NOT run fewer (or more) times than its Examples table has rows,
+  and must NOT feed a row the wrong row's values, or the literal `<placeholder>` text, or
+  `undefined`. A green run that quietly executed only the first row is a FAIL.
+- Negative: a green Jest exit with **zero scenarios actually executed** (no test files
+  matched, the feature silently skipped, the outline collapsed to nothing) is a FAIL, not a
+  pass. "I looked and it's fine" and "I never looked" must not produce the same output —
+  read the scenario count, don't read the exit code.
+- Negative: a step that truly has no definition must still be reported as such. Silence there
+  is a FAIL — the fix must not make genuine missing-step errors disappear.
+
+### Regression guard — the shapes that already worked must still work
+
+The broken shapes must be bought with nothing. In the same run, keep working probes for the
+regex shapes that were never in question, and confirm they are untouched:
+
+- Regexes in **ordinary, non-outline scenarios** — including the same alternation and
+  bounded-quantifier shapes above. These worked before; they must still work.
+- **Plain-string** step matchers in a Scenario Outline — the everyday case almost every real
+  user is on.
+- Regexes in an outline that already worked: simple open captures (a greedy catch-all, a
+  digit run), an alternation group whose word list happened to be fine, escaped literal
+  characters in a step (the README's own booster example escapes parentheses), anchors at
+  the start and end of the pattern.
+- A feature file mixing outlines and plain scenarios, string matchers and regex matchers, in
+  one run.
+
+Negative: if any previously-working shape now fails to bind, mis-binds, or changes the number
+of scenarios it runs, that is a FAIL of this charter even if every newly-fixed shape passes.
+
+If you cannot construct a probe that distinguishes "the regex bound" from "the regex bound by
+luck", say so and record INDETERMINATE. Do not record PASS because nothing went visibly
+wrong — and do not record PASS on a run where you never confirmed how many scenarios actually
+executed.
+
+## Session log
+
+Append-only. Never edit a past row.
+
+| Date | Examiner | Verdict | Observations |
+|---|---|---|---|
+| | | | |

package/docs/product/expectations/fix-l4-escaped-parens-outline/escaped-parens-bind-in-outlines.md

@@ -0,0 +1,106 @@
+# A step whose wording contains brackets works in a scenario outline, not just a plain scenario
+
+**Feature-id**: `fix-l4-escaped-parens-outline`
+**Surface**: the published library `@g_package/jest-cucumber-fusion` — real `.feature` + `.steps.js` files, run by Jest.
+**Human directive (verbatim)**: "Let's tackle P2 and P3 items."
+
+## Intent
+
+A test author writes Gherkin steps in whatever English their domain actually uses — and real domain
+English contains brackets. "the booster(s) should land back on the launch pad". "I call the function
+`doThing()`". When they match such a step with a regular expression, the brackets have to be escaped
+so the regex treats them as literal characters rather than a capture group.
+
+Today that works in an ordinary scenario and **detonates** in a scenario outline. The author moves
+the very same step into a `Scenario Outline` with an `Examples:` table — no change to the step
+definition, no change to its wording — and the whole Jest suite dies. Not "1 test failed". Not "no
+step definition found". The suite **fails to run at all**. Every other test in the file goes down
+with it, and nothing in the output points at the outline as the culprit.
+
+That is a trap with no warning sign on it. A user cannot predict that a legal step definition becomes
+a suite-killer purely because of the block it happens to sit under. What they should get instead is
+boring: the step binds inside the outline exactly as it binds in a plain scenario, and the outline
+runs once per row of the Examples table, each row carrying its own value. Nothing crashes. The author
+never has to know the word "escaped".
+
+## Preconditions
+
+This is a **Node.js / npm** project and the surface is **Jest**. Nothing here is a unit test of the
+library's internals — the examiner never opens `src/`, and never imports anything but the package's
+public entry point.
+
+Set up a scratch consumer project (a throwaway directory, or a scratch folder inside a checkout that
+already has `node_modules` — either is fine, so long as `require`ing the library resolves to the
+build under test):
+
+- Point Jest's `testMatch` at `**/*.steps.js`, per the library's own README.
+- Author real `.feature` files (Gherkin) and matching `.steps.js` files that register step
+  definitions with the library's `Given` / `When` / `Then` / `And` / `But` and end with a `Fusion(...)`
+  call naming the feature file.
+- Run them with `npx jest` (add `--verbose` if you want to see which scenarios executed; you will).
+
+The library's own `README.md` and `docs/ScenarioOutlines.md` are the only reference needed to write
+those files — they show the plain-scenario shape and the outline shape (`<placeholder>` tokens plus an
+`Examples:` table, one run per row). Everything else on this page is *what to look for*, not what to type.
+
+## What to explore
+
+Build your own probes. The shape to hunt is: **a step definition whose matcher is a regular expression
+containing escaped brackets — `\(` and `\)` — used inside a Scenario Outline whose Examples table
+supplies the varying part.** A function-call phrasing is the natural one (`I call the function
+someName()`, matched by something like `/I call the function (\w+\(\))/`), but any domain wording with
+literal brackets in it will do; pick your own and make the step actually assert on the value it
+captured, so a silently-empty binding cannot pass by accident.
+
+Then push on it, the way a paying user would:
+
+- More than one Examples row — does *each* row run, with *its own* value, or does row 2 quietly reuse row 1's?
+- The escaped brackets appearing in different positions in the step wording — captured, adjacent to a
+  `<placeholder>`, or sitting in the literal (non-varying) part of the sentence.
+- More than one such step in the same outline; a Given, a When and a Then all wearing brackets.
+- Mixing: an outline that has both a bracket-bearing step and an ordinary one.
+- Nastier-but-legal regex neighbours: escaped brackets alongside other escaped metacharacters
+  (`\$`, `\.`, `\?`), and steps whose *Examples values themselves* contain brackets.
+
+Interrogate the output as much as the exit code. The interesting question is not only "did it pass"
+but "did it actually **run** what I wrote, and did each row get its own value" — a suite that skips
+everything, binds nothing, or runs one row where three were promised is a failure wearing a green coat.
+
+## Expected observations (oracle)
+
+Positive:
+
+- Running `npx jest` over a scratch project containing a bracket-bearing regex step inside a Scenario
+  Outline **completes a real test run**: Jest reports the suite as having run, and the scenario shows
+  once per Examples row.
+- The value the step captured is the value from *that row* — the assertions the examiner wrote against
+  each row's data pass, and row N does not see row N−1's data.
+- The identical step definition, used in an ordinary (non-outline) `Scenario`, still works exactly as
+  it did before. (Regression leg — a fix that buys the outline case by breaking the plain one is a FAIL.)
+- Ordinary regex step definitions with no brackets at all still bind and run inside outlines, once per
+  row, unchanged. (Second regression leg.)
+
+Negative:
+
+- Negative: the suite must NOT crash. A crash — Jest reporting "Test suite failed to run", a thrown
+  error before any scenario executes, a non-zero exit with zero tests reported — is a **worse and
+  categorically different** failure than a failed assertion, and must be recorded as such. If the run
+  dies before it can even attempt the scenarios, the verdict is FAIL regardless of anything else on the
+  page. The examiner must state explicitly which of the two she saw.
+- Negative: a green exit code with **zero scenarios executed** is a FAIL, not a PASS. The examiner must
+  confirm from the run's own output (test/scenario counts, `--verbose` names) that the outline's
+  scenarios genuinely ran, one per Examples row — the promised row count, no fewer. Silence is not success.
+- Negative: the run must NOT report the step as unmatched / undefined ("no step definition found",
+  a pending or skipped step). Binding-by-not-binding is not a fix; it is the crash traded for a shrug.
+- Negative: no row may pass on a captured value of `undefined`, an empty string, or another row's
+  value. If the examiner's assertions are strict about each row's data and they still pass, that's the
+  proof; if a probe passes only because nothing was asserted, the probe was too weak — tighten it and re-run.
+- Negative: the fix must NOT have been bought at the plain scenario's expense. If the same escaped-paren
+  regex that works in an outline now misbehaves, crashes, or goes unmatched in an ordinary `Scenario`,
+  the verdict is FAIL even if every outline probe is green.
+
+## Session log
+
+| Date | Examiner | Verdict | Observations |
+|---|---|---|---|
+| 2026-07-13 | nw-user-examiner | PASS | 19 scenarios executed (3 outline rows + 1 plain + 15 edge/complex rows). Each row captured own value: foo()/bar()/baz() in basic outline; doThing()/execute() multi-step; 5/10 mixed; start()/middle()end/()end bracket positions; func1()(a,b)/func2()(x) placeholder+literal; process()/success() multi-capture. Exit code 0, no crash, no undefined steps, all assertions pass. Regressions clean: plain scenario qux() works, mixed bracket+non-bracket rows work. No flags. |

package/docs/product/expectations/fix-m3-singleton-reset/clean-slate-per-feature.md

@@ -0,0 +1,133 @@
+# A second feature in the same steps file only ever uses the steps it was given
+
+**Feature-id**: `fix-m3-singleton-reset`
+**Human directive (verbatim)**: "Let's tackle P2 and P3 items" — P2 being defect M3.
+**Status**: armed, unexamined
+
+## Intent
+
+A person writing tests with this library can put more than one feature in a single
+`.steps.js` file — register some steps and hooks, call `Fusion()` for the first feature,
+then register different steps and hooks and call `Fusion()` again for the second.
+
+Today that quietly betrays them. Leftovers from the first feature are still lying around
+when the second one runs: the second feature can match step definitions the author never
+wrote for it, and `Before`/`After` hooks belonging to the first feature fire again on the
+second feature's scenarios. The tests go green — or behave — for reasons the author did not
+write and cannot see. A test that passes for an unwritten reason is worse than a failing
+one, because nobody investigates it.
+
+The expectation: **every `Fusion()` call starts from a clean slate.** Whatever the second
+feature does, it does with the steps and hooks registered for *it*, and nothing else. The
+first feature's leftovers are gone. And this holds even when the first `Fusion()` call blew
+up — a missing feature file, a Gherkin step with no matching definition — because that is
+exactly when a half-built pile of leftovers is most likely to be left behind.
+
+## Preconditions
+
+Runtime is **Node + Jest**, driven from the command line — this is an npm library, so the
+only surface that counts is real `.feature` + `.steps.js` files run through the Jest test
+runner. Do **not** verify this by reading or unit-testing the library's internals; you
+cannot read source code, and the point is what a library *user* sees.
+
+Set up a scratch project outside the library's own test suite (a temp directory is fine):
+
+- `npm init -y`, then install the library under test. Install it **from this working copy**
+  (e.g. `npm install <path-to-this-repo>`) so you are exercising the fixed code, not the
+  published version.
+- Point Jest at step files, exactly as the README tells a user to:
+  `"jest": { "testMatch": ["**/*.steps.js"] }` in `package.json`.
+- Write your own `.feature` files (Gherkin) and your own `.steps.js` files that
+  `require('@g_package/jest-cucumber-fusion')` and use `Given`/`When`/`Then`/`And`/`But`,
+  the `Before`/`After` hooks, and `Fusion('some.feature')` — per the README's Getting
+  Started. Keep the `.feature` file next to the `.steps.js` file that names it.
+- Run them with `npx jest` (add `--verbose` if you want to see individual scenario names).
+
+That is the whole rig: files you wrote, one command, whatever Jest prints. Anything you
+conclude must be visible in that output.
+
+## Charter — what to explore
+
+Build a step file that holds **two features at once** and see whether the second one is
+honest. Everything below is a direction to probe, not a script — invent the actual Gherkin,
+the actual step text, and the actual assertions yourself, and vary them.
+
+The core probe: make the second feature's *correctness depend on the first feature's
+leftovers being gone*. A few angles worth attacking, and you should find more:
+
+- **Steps that were never registered for feature two.** Give feature one a step definition,
+  then have feature two's Gherkin use a sentence that only feature one's definitions could
+  match. If the library is clean, feature two has no definition for that sentence and must
+  say so loudly. If it is dirty, feature two happily runs a step its author never wrote.
+- **Hooks that should have retired.** Have feature one's `Before`/`After` hooks leave a
+  visible trace — bump a counter, push to an array, write something the second feature's
+  assertions can read. Then assert, inside feature two, that only feature two's own hooks
+  ran. Count them. A hook firing twice, or firing at all when it belongs to the other
+  feature, is the bug wearing a disguise.
+- **Steps that collide by name.** Register the *same* Gherkin sentence in both features with
+  different behaviour. Feature two must get feature two's behaviour — never feature one's,
+  and never both.
+- **Order and quantity.** Three features in one file. Two features in one file plus a
+  perfectly ordinary single-feature file alongside it — the fix must not break the ordinary
+  case, which is what almost every real user is doing.
+- **The unhappy first act (required, see the sad path below).** Make the first `Fusion()`
+  call fail, then check the second one is still clean.
+
+Be demanding. You are not trying to confirm the fix; you are trying to catch the second
+feature using something it was never given. Ask what a paying user would try on a Friday
+afternoon and hit that.
+
+## Expected observations (the oracle)
+
+- A step file containing two features runs, and the second feature's scenarios execute
+  using only the step definitions registered for that feature. The result Jest prints for
+  feature two is explainable *entirely* by the code written between the first `Fusion()`
+  call and the second.
+- Hook traces are exact: for a scenario in feature two, only feature two's `Before`/`After`
+  hooks leave a mark, and each leaves it exactly once. Counters agree with what the author
+  wrote — not double, not carried over.
+- The plain single-feature-per-file case is unchanged: an ordinary steps file still passes
+  and still reports the same scenarios it always did.
+- **Negative**: the second feature must NOT silently pass by matching a step definition that
+  belongs to the first feature. If feature two's Gherkin contains a sentence with no
+  definition of its own, Jest must fail or otherwise refuse it — a green run there is a
+  FAIL of this charter, not a pass. Test-suite green is not the oracle; green *for the
+  reasons you wrote* is.
+- **Negative**: a hook registered only for feature one must NOT fire during feature two's
+  scenarios. Any trace of it (an extra count, an unexpected side effect, an assertion that
+  only passes because someone else set something up) is a FAIL.
+- **Negative**: if the first `Fusion()` call fails, the tool must NOT pretend the second
+  feature is fine by feeding it the wreckage — see the sad path.
+
+### Sad path — the guarantee must survive a failed first `Fusion()`
+
+Break the first feature on purpose, two ways, in separate runs:
+
+1. Point the first `Fusion()` at a `.feature` file that does not exist.
+2. Give the first feature a Gherkin step with no matching step definition.
+
+In both cases the first feature is *expected* to fail — that is fine, and its failure should
+be reported clearly enough that a non-technical reader can tell **which** feature broke and
+**why** (a missing file should look like a missing file; a missing step should look like a
+missing step). The point of the probe is what happens to the second feature afterwards.
+
+- The second feature in the same file must still run against a clean slate: only its own
+  steps, only its own hooks, no scraps left behind by the crash.
+- **Negative**: the second feature must NOT inherit the failed first feature's leftovers —
+  no orphan hooks firing, no step definitions bleeding through, no cascade where the second
+  feature fails (or passes) *because* the first one broke rather than on its own merits.
+- **Negative**: the tooling must NOT go silent about the first feature's failure. A run where
+  the first feature quietly disappears and Jest reports overall success is a FAIL — the
+  failure must be visible and attributable, not swallowed in the name of cleaning up.
+
+If you cannot construct a probe that would distinguish "clean slate" from "leftovers
+present" — say so and record INDETERMINATE. Do not record PASS because nothing went
+visibly wrong; a bug whose whole nature is silence will not announce itself.
+
+## Session log
+
+Append-only. Never edit a past row.
+
+| Date | Examiner | Verdict | Observations |
+|---|---|---|---|
+| 2026-07-13 | nw-user-examiner | FAIL | Hook leakage: Feature One's Before hook fires during Feature Two's scenario execution. Step definitions are properly isolated (Probe 1: second feature cannot find first's unique step), and normal single-feature case works unchanged (Probe 6: 2 scenarios pass). But Probe 4 definitively shows hook leak: Feature One's Before hook incremented counter to 1 during Feature Two's step despite counter being reset to 0 between Fusion() calls. Sad path works when wrapped in try/catch (Probe 5). Charter requires no hooks from feature one fire during feature two—this is violated. |

package/package.json

@@ -1,11 +1,12 @@
 {
   "name": "@g_package/jest-cucumber-fusion",
-  "version": "1.0.0",
+  "version": "2.0.0",
   "description": "Write cucumber test as part of a jest run (including coverage)",
   "main": "src/index.js",
   "types": "src/index.d.ts",
   "scripts": {
     "test": "jest --color",
+    "test-d": "tsd",
     "coverage": "jest --coverage",
     "commit": "git-cz",
     "semantic-release": "semantic-release",
@@ -28,8 +29,10 @@
   },
   "devDependencies": {
     "cz-conventional-changelog": "^3.3.0",
+    "fast-check": "^4.10.2",
     "prettier": "2.3.2",
-    "semantic-release": "^25.0.5"
+    "semantic-release": "^25.0.5",
+    "tsd": "^0.33.0"
   },
   "publishConfig": {
     "access": "public"
@@ -46,9 +49,8 @@
       [
         "@semantic-release/github",
         {
-          "assets": [
-            "dist/**"
-          ]
+          "successComment": false,
+          "failComment": false
         }
       ],
       [
@@ -72,6 +74,10 @@
     "testMatch": [
       "**/*.steps.js"
     ],
+    "testPathIgnorePatterns": [
+      "/node_modules/",
+      "<rootDir>/.claude/"
+    ],
     "coveragePathIgnorePatterns": [
       "/node_modules/",
       "/test/"

package/src/index.d.ts

@@ -10,11 +10,21 @@ export type CallBack = (
   ...args: ReadonlyArray<string | Array<Record<string, string>>>
 ) => void | Promise<void>;
 
-export function Given(name: string | RegExp, callback: CallBack): void;
-export function When(name: string | RegExp, callback: CallBack): void;
-export function Then(name: string | RegExp, callback: CallBack): void;
-export function And(name: string | RegExp, callback: CallBack): void;
-export function But(name: string | RegExp, callback: CallBack): void;
+export interface StepChain {
+  stepSentence: string | RegExp;
+  stepFnDefinition: CallBack;
+}
+
+export function Given(name: string | RegExp, callback: CallBack): StepChain;
+export function Given(chain: StepChain): StepChain;
+export function When(name: string | RegExp, callback: CallBack): StepChain;
+export function When(chain: StepChain): StepChain;
+export function Then(name: string | RegExp, callback: CallBack): StepChain;
+export function Then(chain: StepChain): StepChain;
+export function And(name: string | RegExp, callback: CallBack): StepChain;
+export function And(chain: StepChain): StepChain;
+export function But(name: string | RegExp, callback: CallBack): StepChain;
+export function But(chain: StepChain): StepChain;
 
 export function Before(callback: () => void | Promise<void>): void;
 export function After(callback: () => void | Promise<void>): void;