Secret vault
WeftKit’s answer to credentials in tests is not encryption after the fact — it is never capturing the value in the first place. During recording a credential field becomes a named reference; you supply the value once, afterwards, into your operating system’s credential vault.
References, not values
Passwords, reusable tokens, and API keys are replaced with named references during recording — for example ${secret.ADMIN_PASSWORD}. Suites, logs, AI provider packets, and reports retain the reference only. There is no reveal action anywhere in the app, because there is nothing stored in the app to reveal.
| Surface | What it holds |
|---|---|
| Suite payload | Reference only. |
| Frontend store | Never exposed — values do not enter the UI layer. |
| Runner resolution | The desktop runner resolves the reference at replay time from the OS credential vault, falling back to WeftKit’s encrypted local store when the vault will not return it to an updated build. |
| Reports and AI packets | Reference only. Credential-shaped strings are scrubbed before anything is persisted or sent. |
The credential setup queue
After a recording, every reference it detected appears in a queue with the suite that needs it. Until you define a value, that suite is marked Needs attention rather than failing halfway through a replay. Each entry states its scope — the host and path where the credential is used — so you can tell two similarly named references apart.
One-time codes stay human
References that look like one-time codes — OTP, TOTP, MFA and two-factor patterns — are deliberately refused by the vault. A code that is valid once cannot be a stored secret, so WeftKit treats those steps as human checkpoints instead of pretending to automate them.
Scoping
- A reference belongs to a project, and can optionally be narrowed to a single suite.
- A suite-specific value takes precedence over a project-wide value with the same name.
- Deleting a project removes its vaulted entries, including git tokens, rather than orphaning them.