mathiasandClaude Opus 4.8
a884e7e9c5
Close the gap where docs/use-cases/*.feature claimed to be the behavior spec but nothing executed them — so scenarios drifted (the stale "auto summarizes every new video" and "manual is the default" were proof). Decision (per issue #5 BDD-runner fork): no godog — keep .feature as design records, add a cheap name-coverage gate instead. TestScenarioCoverage parses every scenario and asserts each non-@pending one maps to an existing Go test in the scenarioCoverage manifest; it flags unmapped scenarios, missing/renamed tests, and stale entries. It checks the link, not that the test exercises the scenario (the deliberate trade for skipping godog). Also: - Fix the stale ADR-018 drift: "Manual is the default" -> auto is the default for new users; added an explicit default scenario + a plain manual scenario. - Tag 4 documented-but-unbuilt/untested scenarios @pending with reasons (Vimeo connect, BYO config flow, logout->welcome, re-register-after-delete) so they are tracked without a false coverage claim. - CLAUDE.md BDD section now describes the real setup (design records + the gate + @pending convention) instead of claiming an executable spec. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
49 lines
2.3 KiB
Gherkin
49 lines
2.3 KiB
Gherkin
Feature: Register and manage a multi-user account
|
|
As one of a handful of trusted users
|
|
I want my own account, isolated from everyone else's
|
|
So that Tapir can serve several people from one deployment without leaking data
|
|
|
|
# Stage 1 (ADR-012): Dex authenticates, Tapir authorizes per user. A Dex subject
|
|
# with no users row is a new user and must register before reaching any data.
|
|
|
|
Scenario: A new Dex subject is routed to registration
|
|
Given I am authenticated by Dex with a subject that has no Tapir account
|
|
When I open any page that requires an account
|
|
Then I am routed to the registration page
|
|
And no summaries are shown until I register
|
|
|
|
Scenario: Registering creates the account and its identity mapping
|
|
Given I am authenticated by Dex with a subject that has no Tapir account
|
|
When I complete registration
|
|
Then a user row is created for me
|
|
And a user_identities row maps my Dex subject to that user
|
|
And I am taken into the app as a registered user
|
|
|
|
Scenario: A returning subject passes straight through
|
|
Given I am authenticated by Dex with a subject that already has a Tapir account
|
|
When I open the app
|
|
Then I am not asked to register again
|
|
And I see my own summaries
|
|
|
|
Scenario: Deleting an account removes only my data and leaves other users untouched
|
|
Given I am a registered user with summaries, a connected account, and recorded actions
|
|
And another user exists with their own summaries
|
|
When I delete my account
|
|
Then all of my rows are removed across every user-owned table
|
|
And my stored secret references are removed
|
|
And the other user's data remains intact
|
|
And my Dex identity is left intact
|
|
|
|
@pending
|
|
# Re-registration after delete is supported by design (delete leaves the Dex identity,
|
|
# ADR-013) but has no dedicated end-to-end test yet.
|
|
Scenario: A deleted user can register again as a fresh account
|
|
Given I deleted my Tapir account but my Dex identity still exists
|
|
When I sign in again
|
|
Then I am routed to the registration page as a new user
|
|
And registering creates a fresh user row with none of my old data
|
|
|
|
# Isolation is DB-enforced (Postgres RLS, ADR-012, migration 003): a user can never
|
|
# read or write another user's rows even if an application WHERE clause is wrong.
|
|
# Deletion is Tapir-side only — the shared Dex directory is never modified (ADR-013).
|