Reviewing the as-is specification
The as-is specification is the record of what your legacy system does today, written as Gherkin scenarios and extracted from the code. It is the thing everything else is built on, so it is worth the read.
What a feature is here
A feature groups scenarios that belong to one piece of behaviour. Features are discovered per module, and each carries a title, a description, and the scenarios themselves.
Where a feature's title has no Latin letters, it also carries an English name. That is not cosmetic: branch names are derived from titles, and a title that slugs to nothing would produce a branch nobody can work with.
Reading a scenario
A scenario describes behaviour from the outside — what a user does, and what the system does back. Two annotations matter when you are reviewing:
# @id: ASIS-nnnis the scenario's stable identity. Ids are never renumbered. Everything that refers to a scenario later — a to-be scenario tracing back to it, a test result, a report — refers to this id, which is why editing a scenario is safe and reordering it changes nothing.@code-refpoints at the legacy code the behaviour was read from. The paths are validated, and a scenario's related files open at the annotated lines, so you can check a claim against the source in two clicks rather than searching for it.
That chain — scenario to code and back — is what makes the as-is reviewable rather than something you have to take on faith. It is protected: the links cannot be quietly dropped by a later edit.
Focusing discovery
Discovery does not have to swallow the whole codebase at once. You can choose individual files as the focus, which is the usual way to handle a large system: run discovery over the area you are about to work on, review it properly, then move on.
Refining what came out
Discovery is a first pass, and refinement improves it. Refinement of as-is Gherkin stays legacy-scoped — it sharpens the description of what the legacy system does and never quietly introduces behaviour you have not asked for. That boundary is the point: the as-is is a record, not a wish list.
You can also edit scenarios directly. A bulk-action toolbar handles the repetitive cases, and the view state persists when you leave a feature and come back, so a long review survives an interruption.
Splitting and merging
A discovered feature is sometimes the wrong size — two behaviours in one, or one behaviour spread across several. Features can be split, and a feature that has been split is marked as such rather than disappearing.
When the as-is is good enough
It does not have to be perfect. It has to be true: every scenario should be something the legacy system actually does, and anything you cannot verify against the code is worth deleting rather than carrying forward. The next step turns this record into decisions, and a decision made against a scenario nobody checked is the expensive kind of mistake.