Language

Product specs, roles and actors

A product spec declares what an application owes the people using it. It attaches expectations to a U code and names the components, starting conditions, actions and outcomes of a scenario.

The declaration

A spec can contain component, given, action, then and role sections. The compiler resolves the specification vocabulary and produces a manifest. The test runner executes lane scenarios; eligible field-tagged lines can also be observed in a running application.

Roles establish test identities

A spec role declaration defines a reusable fixture. A role can be scoped to an entity, such as a tenant. The fixture must establish identity through the product's real authentication path when that is what the test claims to exercise.

Setting a label in a demo UI is useful for proving browser-context isolation, but it is not authentication and grants no permission.

Actors name callers

A cast inside role binds actor names to role fixtures. There is no separate actor keyword:

role {
  maker = cashier
  checker = supervisor of tenant "store-1"
}

Later sections can use maker and checker blocks to act and assert in the corresponding caller's context. Each caller keeps its own browser context. Opening a named case does not navigate to a URL; use navigate to change location.

Run a campaign

node n1/vulcan/lang/bin/vulc.ts test path/to/product.spec.v --ui-profile path/to/profile.json
node n1/vulcan/lang/bin/vulc.ts spec path/to/product.spec.v --json

The profile supplies the environment, fixture and driver. The spec command inspects what the declaration says; it is not a substitute for running the test against the application.

Field observation has limits

A browser observes one current caller. Named casts are skipped by field observation, including a cast with one named actor. Unknown caller identity is ungated evidence, not a proven role match. Observing a role never grants authorization.

Use lane tests for multi-caller behavior, keep fixture cleanup bounded, and retain failure evidence when an environment fails. Passing a mocked driver test does not prove behavior on a physical device.