The Gap
We have facts-delete-protection.test.ts which tests that built-in facts survive `_delete: true`. What we don't have is any E2E test that verifies the happy path — that setting `_delete: true` in the YAML editor actually deletes the thing.
This is a consistent gap across every editor-based command that supports deletion:
| Command |
Deletable types |
| `/me facts` |
User facts |
| `/me traits` |
Traits |
| `/me topics` |
Topics |
| `/me people` |
People |
| `/quotes` |
Quotes |
| `/context` |
Messages |
| `/queue` |
Queue items (just added in feat/queue-panel) |
| `/dlq` |
Dead-letter queue items (just added in feat/queue-panel) |
Why It Matters
The `_delete` convention is the primary way users remove data in the TUI. It's used everywhere. And right now, none of it has E2E coverage for the actual deletion flow — only the protection edge case.
The Pattern Already Exists
`facts-delete-protection.test.ts` already figured out the hard part: set `EDITOR` to a shell/Python script that flips `_delete: false → true` in the YAML file. The `@microsoft/tui-test` runner supports this via `test.use({ env: { EDITOR: scriptPath } })`. The infrastructure is there, we just haven't written the happy-path tests.
Scope
One test file per command (or group related ones). Each test:
- Seeds a checkpoint with the relevant data
- Sets `EDITOR` to a script that marks one item for deletion
- Runs the command
- Verifies the item is gone and the notification reflects the deletion
Why This Is a Batch Job
Filing this separately from the queue panel work because retrofitting all 8 command types at once is way more coherent than doing one-offs. The patterns are identical — write the framework once, stamp out the tests.
Low urgency, high completeness value. Good "rainy day" ticket.
The Gap
We have
facts-delete-protection.test.tswhich tests that built-in facts survive `_delete: true`. What we don't have is any E2E test that verifies the happy path — that setting `_delete: true` in the YAML editor actually deletes the thing.This is a consistent gap across every editor-based command that supports deletion:
Why It Matters
The `_delete` convention is the primary way users remove data in the TUI. It's used everywhere. And right now, none of it has E2E coverage for the actual deletion flow — only the protection edge case.
The Pattern Already Exists
`facts-delete-protection.test.ts` already figured out the hard part: set `EDITOR` to a shell/Python script that flips `_delete: false → true` in the YAML file. The `@microsoft/tui-test` runner supports this via `test.use({ env: { EDITOR: scriptPath } })`. The infrastructure is there, we just haven't written the happy-path tests.
Scope
One test file per command (or group related ones). Each test:
Why This Is a Batch Job
Filing this separately from the queue panel work because retrofitting all 8 command types at once is way more coherent than doing one-offs. The patterns are identical — write the framework once, stamp out the tests.
Low urgency, high completeness value. Good "rainy day" ticket.