r34 private workflow and conversation lifecycle controls

This revision adds end-user controls to restore or permanently delete archived private workflows, and to delete saved AI research conversations. The product version remains r34. These operations are not exposed as AI tools. They do not require a configured AI key and do not consume model calls.

Restore an archived workflow

1. Open My workflows and enable Show archived.
2. Select the archived workflow and choose Restore workflow.
3. Follow the displayed validation notice, then explicitly activate the workflow when validation passes.

Restore keeps the workflow's identity, versions and execution history. It returns the workflow to an inactive draft state and clears its current activation and validation decision. A previous validation is retained as historical evidence. If installed source or the active override stack changed, save a new workflow version and validate it before activation. Restore does not bypass source, runtime, dependency, policy or validation checks.

Export/Import remains available for backup, sharing, transfer and independent copies or variants. Import creates a separate workflow and still requires its own validation and activation. Exported bundles and copies elsewhere are not removed by deleting the original workflow.

Permanently delete a workflow

Archive the workflow first. Select it with Show archived enabled and choose Permanently delete workflow. Review the confirmation's removal and retention scope before confirming. Deletion targets this workflow's versions, validation records, execution records and associated execution files. Separately saved conversations, override layers and unrelated results remain.

Only archived workflows can be permanently deleted. Delete is individual, not a bulk action. Permanent deletion has no Restore or Undo operation. A failed or interrupted deletion continues toward removal; partially removed content cannot be safely restored.

Delete a saved conversation

Select a saved conversation in the AI research assistant and choose Delete conversation. The confirmation describes what is removed and what remains.

Deletion removes the saved transcript, provider continuation context, investigation checkpoints and conversation attachments. Separately saved workflows, override layers and results remain. If saved layers or derived runs still require the original source/input evidence, an execution-only technical context is retained independently; it is hidden from the saved conversation list and does not consume a saved-conversation slot. It contains the required source/run binding and evidence, without messages, provider context, checkpoints or conversation attachments.

Use the assistant's Saved derived runs panel to find retained results after deleting their conversation. Inspect saved run opens the existing report and files; Discuss saved run starts a fresh conversation from that recorded run without executing it again or restoring old messages.

A workflow generated from the conversation keeps its historical source-session identifier, marked as a deleted conversation. Reopening the original simulation can create a fresh conversation; it does not restore deleted messages. Text or images already copied into independently retained results, workflow code or exports are outside conversation deletion. This operation does not request removal from an external AI provider's records, exported files or backups.

Pending cleanup and recovery

The server records the deletion request and hides the target in one database transaction before removing files. A durable cleanup operation remains even if the browser closes, a response is lost or the process stops. Deleted targets cannot be edited, restored or continued by stale browser tabs.

The Cleanup operations panel shows Deletion pending, the recorded stage, a sanitized error when applicable, and Retry deletion. Repeated requests resume the same operation. Already absent target files count as removed. A minimal completed receipt retains identifiers, times and counts; it does not retain transcript text or attachment names.

Recovery is bounded background work after authenticated owner access, with at most two pending operations admitted per 30-second interval. Standalone recovery requires the application to be running. Explicit Retry deletion is available when the blocker is resolved. There is no blocking all-user startup cleanup scan.

Database failure before the deletion transaction commits leaves the original item intact. After commit, cleanup must finish before the operation reports completed. The operation may remain pending indefinitely while an external service is permanently unavailable; the interface does not claim success merely because the target is no longer listed.

Workflow and conversation item allowances are reclaimed when their records are removed. Retained technical contexts do not consume saved-conversation slots. Pending physical bytes remain accounted for until cleanup confirms removal. Independently retained evidence and shared blobs continue consuming storage.

Upgrade, backup and rollback

The existing record database is reused; existing item IDs and relationships are preserved. New durable deletion and execution-context record types support the lifecycle operations. The first restore, permanent deletion or receipt reconciliation installs a database write compatibility guard in the same transaction. SQLite and PostgreSQL guards reject older application writers that do not identify support for lifecycle records. If the database role cannot install the guard, the operation fails before committing the requested lifecycle change. A PostgreSQL operator can install it through the normal controlled migration using table-owner privileges and Store.install_lifecycle_guard. Other database engines are not supported for these lifecycle changes. Stop active work and preserve a coordinated copy of the database and its local/BYOS evidence before upgrading or attempting recovery.

Do not run older application code against state already modified by lifecycle operations. Older code does not understand the retained contexts and deletion receipts. A rollback must restore the matching application, database and filesystem/BYOS evidence together from the same pre-upgrade recovery point. A partially restored database or storage snapshot is not a supported rollback.

An older backup can contain subsequently deleted content. Preserve current deletion receipts outside the rollback set and reconcile the restored objects before exposing the restored application to users. The receipt document includes operation and target IDs, owner hash and request times; it does not include chat content. Its checksum detects corruption, not forgery. Only an administrator's protected, trusted export may authorize cleanup of restored data.

For standalone local storage, from the application directory:

python -m pf_assistant.recovery --state-dir EXISTING_STATE_DIR --owner local export --output NEW_RECEIPTS.json
python -m pf_assistant.recovery --state-dir RESTORED_STATE_DIR --owner local inventory --receipts NEW_RECEIPTS.json
python -m pf_assistant.recovery --state-dir RESTORED_STATE_DIR --owner local apply --receipts NEW_RECEIPTS.json --confirm-owner local

Replace the directory placeholders with existing state directories. Export current receipts after deletion changes and protect that file separately from older backups. inventory is read-only. Inspect its scope before apply, and stop application processes and workers while applying reconciliation. Repeated application is safe. An inconsistent snapshot with orphaned child records blocks reconciliation visibly; repair or restore a consistent snapshot rather than editing lifecycle JSON or SQL manually.

For a hosted metadata database, supply its configured --database-url before the subcommand and repeat for every exact owner scope, including each applicable project scope. Do not guess owner identifiers. The CLI supports local file cleanup and refuses remote-bound deletion without the configured storage resolver. BYOS deployments use pf_assistant.recovery.apply_receipts(assistant, owner, document) with the deployment's configured assistant and residency adapter, in the same offline maintenance procedure. This retains normal storage ownership checks, shared-blob protection and pending cleanup retries.

Existing backup files and exported bundles are not erased. Do not erase pending cleanup records or manually reconstruct half-deleted items. Backup recovery is an operator procedure, not an application Undo action.

Release evidence and verification

Current scoped acceptance belongs to validation_r34_lifecycle and qualification schema 7.0.0. Historical startup-correction records remain byte-for-byte intact in validation_r34_startup; they are not relabeled as executions of this source. The lifecycle tool pins the exact incoming startup ZIP and its checksum inventory, preserves each changed original, and verifies fresh command receipts against the frozen current source and output inventories.

python release_tools/validate_r34_lifecycle.py verify --package

The packaged source and verification report identify the actual commands, artifacts and counts. Startup qualification remains background work. Workflow validation and authorization remain independent of release badge presentation. Historical scientific statuses and scopes remain unchanged; built-in benchmark evidence does not scientifically qualify private programs or custom inputs.

The acceptance scope is targeted lifecycle and retained enhancement regression, not a fresh execution of every scientific benchmark. Linux tests, simulated storage failures and browser checks do not establish native Windows, live paid AI-provider, production cloud, or every third-party BYOS-provider behavior.