📝 Bug Description
Engram v2.2.1 prevents new empty prompt writes, but legacy prompt upserts whose content was already stored as empty still have no supported local repair, quarantine, tombstone, or journal-preserving discard path.
One affected project contains 14 such prompt mutations. They block the required-fields repair with upgrade_blocked_legacy_mutation_manual, which also prevents 187 otherwise repairable mutation titles and 260 source titles from being applied safely.
🔄 Steps to Reproduce
- Start Engram v2.2.1 with a legacy database containing a prompt upsert whose canonical row and frozen mutation payload both have empty content.
- Run engram doctor repair --project --check sync_mutation_required_fields --dry-run.
- Observe an unrepairable prompt action.
- Run engram cloud upgrade doctor --project .
- Observe upgrade_blocked_legacy_mutation_manual and no supported recovery operation.
- Confirm that applying the repairable subset would leave the required-fields blocker unresolved.
✅ Expected Behavior
Engram should provide a supported, project-scoped recovery operation for irrecoverable legacy prompt mutations. A safe solution could tombstone, quarantine, or discard the invalid prompt while preserving journal continuity, producing a WAL-consistent backup, and proving that no other project or mutation was changed.
The repair command should remain dry-run-first and report the exact affected entities before applying.
❌ Actual Behavior
The prompt actions remain unrecoverable and block the complete repair:
- 14 legacy prompt upserts have empty content.
- The canonical user_prompts rows, FTS copies, and complete mutation lineage also contain empty content.
- The required-fields dry-run reports 187 mutation-title repairs and 260 source-title repairs, but the 14 prompt actions remain blocked.
- cloud upgrade doctor returns upgrade_blocked_legacy_mutation_manual.
- No supported local repair exists without manual SQLite mutation or deletion.
Operating System
Linux (Other)
Engram Version
2.2.1
Agent / Client
Other
📋 Relevant Logs
engram doctor repair --project <project> --check sync_mutation_required_fields --dry-run
applied: false
actions: 14
repairs: 187
source_repairs: 260
reason_code: upgrade_blocked_legacy_mutation_manual
engram cloud upgrade doctor --project <project>
status: blocked
class: blocked
reason_code: upgrade_blocked_legacy_mutation_manual
💡 Additional Context
The source rows, FTS copies, and complete mutation lineage were checked, along with 91 available Engram backups. None contained non-empty content or the affected prompt sync IDs, so byte-exact recovery was impossible. No manual SQL, mutation deletion, quarantine, or partial repair was performed.
Related closed issues:
📝 Bug Description
Engram v2.2.1 prevents new empty prompt writes, but legacy prompt upserts whose content was already stored as empty still have no supported local repair, quarantine, tombstone, or journal-preserving discard path.
One affected project contains 14 such prompt mutations. They block the required-fields repair with upgrade_blocked_legacy_mutation_manual, which also prevents 187 otherwise repairable mutation titles and 260 source titles from being applied safely.
🔄 Steps to Reproduce
✅ Expected Behavior
Engram should provide a supported, project-scoped recovery operation for irrecoverable legacy prompt mutations. A safe solution could tombstone, quarantine, or discard the invalid prompt while preserving journal continuity, producing a WAL-consistent backup, and proving that no other project or mutation was changed.
The repair command should remain dry-run-first and report the exact affected entities before applying.
❌ Actual Behavior
The prompt actions remain unrecoverable and block the complete repair:
Operating System
Linux (Other)
Engram Version
2.2.1
Agent / Client
Other
📋 Relevant Logs
💡 Additional Context
The source rows, FTS copies, and complete mutation lineage were checked, along with 91 available Engram backups. None contained non-empty content or the affected prompt sync IDs, so byte-exact recovery was impossible. No manual SQL, mutation deletion, quarantine, or partial repair was performed.
Related closed issues: