anchor.diff:  
   IMPORTANT: `TraversalStrategy` categories are sorted within their category and the categories are then executed in the following order: decoration, optimization, finalization, and verification. If a designed strategy does not fit cleanly into these categories, then it can implement `TraversalStrategy` and its prior and posts can reference strategies within any category.
   
  -Another example `OptimizationStrategy` in action is provided below.
  +An example of a `VendorOptimizationStrategy` is provided below.
   
   [source,groovy]
   g.V().has('name','marko')
  
positive.code: 
  [source,java]
  ----
  public final class TinkerGraphStepStrategy extends AbstractTraversalStrategy<TraversalStrategy.OptimizationStrategy> implements TraversalStrategy.OptimizationStrategy {
  
      private static final TinkerGraphStepStrategy INSTANCE = new TinkerGraphStepStrategy();
      private static final Set<Class<? extends OptimizationStrategy>> PRIORS = new HashSet<>();
  
      static {
          PRIORS.add(IdentityRemovalStrategy.class);
      }
  
      private TinkerGraphStepStrategy() {
      }
  
negative.code:         }
      }
  
      public static TinkerGraphStepStrategy instance() {
          return INSTANCE;
      }
  }
  ----
  
  The traversal is redefined by simply taking a chain of `has()`-steps after `g.V()` (`TinkerGraphStep`) and providing them to `TinkerGraphStep`. Then its up to TinkerGraphStep to determine if an appropriate index exists. In the code below, review the `vertices()` method and note how if an index exists, for a particular `HasContainer`, then that index is first queried before the remaining `HasContainer` filters are serially applied. Given that the strategy uses non-TinkerPop3 provided steps, it should go into the `VendorOptimizationStrategy` category to ensure the added step does not corrupt the `OptimizationStrategy` strategies.
  
  [gremlin-groovy,modern]
  ----
  