Basically I'm designing a two layer interface, the first layer speaks app UI specific language and runs playwright directly (signin, dismiss toast, go to dashbo

Basically I'm designing a two layer interface, the first layer speaks app UI specific language and runs playwright directly (signin, dismiss toast, go to dashboard), and then the second speaks product language ("user opens dashboard" in Gherkin would translate to signin, wait for app to load, go to dashboard; for example). The translation from product level language to app level language is the step definition files bddgen uses. I'm building up a little skills library to try and force Claude to stick to these separate levels of abstraction; then also do deduplication and cleanup after implementing new specs. We don't really use images for acceptance testing, it's more functionality. I don't really care where the button is, just that if I click it, it does what it says it does. To that end, we already have multi-tenancy in the application (I highly recommend every app build this in, if only for testing; then you don't need to do the Postgres template1 seeding hacks), so we spin up a tenant for a test, do all the setup with the API (all the Given statements), playwright to do the validation of a feature (the When statements), and finally validation is a mix of Playwright and API (the Then statements). Sorry if that isn't super clear; maybe I could put together a little demo repo or something if people have any interest; I'm hoping to do that after I introduce typespec and dbml (basically spec/{acceptance,api,db}).