PF Simulation r34 — continuation storage and attachment management

This revision adds Remove beside assistant attachments and stores new investigation checkpoints in a compact, lossless format. It retains the r34 scientific core, completed run outputs, private source layers and recorded investigation history. The changes apply to standalone and hosted assistant sessions, including hosted personal storage.

Continue a retained investigation

The assistant now pools repeated long strings, including repeated image payloads, before compressing private checkpoint data. Decoding restores the original JSON values, including provider-native tool history, reasoning/signature blocks and cached results. Compression does not summarize or discard that state.

Checkpoint storage stays bounded:

Stored byte counts and expanded byte counts describe different limits. The Continuation checkpoint capacity details show the available numeric diagnostics and the capacity boundary encountered. These limits are also separate from PF_AI_MAX_CONTEXT_BYTES, provider response limits, the model's token context window and the owner's private-storage allowance. A compact checkpoint can still require a larger context budget to make its next provider request.

The reader accepts intact legacy schema-1 checkpoints as well as the new compact schema-2 envelope. Both must pass the same provider, tool, evidence, profile, credential and source binding checks. Corrupt, oversized or mismatched state is rejected; checksums detect damage and do not replace those binding checks.

Use Continue investigation or Retry saved investigation when the session reports a retained checkpoint. Each action starts one bounded investigation step and remains subject to applicable usage limits. When only the context budget is insufficient, the checkpoint remains retained and the interface reports the minimum required context budget. An operator can adjust that budget within supported limits and reload the application.

An older checkpoint_too_large, checkpoint_storage_limit or checkpoint_unavailable result may have no saved private state. Updating the application, raising a budget, or removing attachments cannot reconstruct it. Start a new question using the remaining evidence and the historical findings. Upgrading also does not bypass existing source or evidence binding checks for a checkpoint that has become stale.

Remove an attachment

1. Open the assistant session and find the attachment below the conversation.
2. Select Remove beside its download link and review the confirmation.
3. Confirm removal. The attachment leaves the active evidence list and its download becomes unavailable.
4. If the session had a saved continuation, start a new question about the remaining evidence.

Removal first commits a tombstone containing the attachment's identity, filename, size, hash and removal time, then deletes its retained payload. If that metadata transaction fails, the active attachment and its bytes remain intact. Historical messages and citations remain unchanged; the removal record marks the payload as unavailable to the session. Removing a file cannot retract material already sent to a model or erase quotations from earlier messages.

If local file cleanup fails, the attachment remains removed from active evidence and its tombstone reports cleanup_pending. The interface offers Retry removal to finish deleting the stored file. New investigations in that session remain blocked until cleanup succeeds, so a file still awaiting physical deletion cannot re-enter the assistant's evidence tools. A retry uses the existing removal record and does not repeat research work. This local cleanup state also survives an application restart.

Removal clears private provider continuation data and saved investigation checkpoints for that session. Its existing investigation status becomes stale with reason attachment_removed, so the assistant cannot resume against evidence that is no longer available. Completed scientific runs, result artifacts, proposals and source layers remain retained.

Only users allowed to edit a hosted project can remove attachments. Removal requests are scoped to the current owner and session; repeating a successful request for the same attachment is safe. An attachment from another session cannot be removed through the current session.

Selecting a file uploads it immediately. The file chooser clearing itself after upload means that selection has been processed; it does not remove the uploaded file. New identical uploads in the same session reuse an active attachment when filename, SHA-256 and byte size all match. The supplied matching bytes also repair a missing or corrupted retained payload; personal storage verifies or repairs its remote object before reporting durability. An unavailable storage destination remains a retryable pending operation rather than a successful duplicate acknowledgement. A different filename or different contents creates a separate attachment. Existing historical duplicates remain available for explicit removal. Re-uploading a removed file creates a new active attachment; its earlier removal record remains in the audit.

Personal storage and pending removal

When personal storage is enabled, removal also deletes the corresponding remote object. If that storage operation fails, the active attachment remains removed from the session while a durable operation journal records the unfinished deletion. The interface reports pending_delete and offers Retry removal. It does not report remote deletion as complete before the storage operation succeeds.

Restore the session's configured storage destination if necessary, then select Retry removal. The retry finishes the retained storage operation without repeating model requests, tool calls or scientific execution. Other profile mutations remain paused until the pending operation is resolved. A process interruption with uncertain effects remains an operator-reconciliation case; it is not automatically replayed as an ordinary completed-operation retry.

Upgrade and verify

Keep the existing assistant database, stored evidence, personal-storage configuration and credential vault key when updating. Restart the application and reload the browser. Do not purge saved history to clear a capacity warning.

The current acceptance gate requires the continuation-storage, checkpoint-service, attachment-management, hosted attachment and personal-storage regression modules, plus a dedicated attachment interface suite. It also retains the six existing interface suites and all 25 original, personal-key and personal-storage provider lifecycles. Source hashes, retained evidence hashes, exact required module identities and scientific-core integrity are rechecked by verification.

python release_tools/audit_r34_core.py verify
python release_tools/validate_r34_byos_release.py verify
python release_tools/validate_r34_byos_release.py execute --baseline /path/to/original/r34.zip

Each new execution saves its source hashes, exact test selection, runtime/environment identity and baseline identity before starting work. Completed stages receive durable receipts; regression tests run in bounded sequential shards with their own exact collected-test manifests, logs, JUnit and receipts. If the environment interrupts execution, resume that same directory with unchanged source, baseline and runtime:

python release_tools/validate_r34_byos_release.py execute --baseline /path/to/original/r34.zip --resume validation_r34_byos/executions/EXECUTION_ID

Resume rechecks a completed stage or shard before reusing it. Failed or incomplete work is not counted as passed; retry attempts preserve prior evidence. A changed plan is rejected and requires a new execution. Older interrupted runs without the initial source-bound plan cannot be adopted as acceptance evidence, even if an individual lifecycle finished. Only a completed, verified overall record establishes acceptance. Read-only verification also works from a fresh extraction; rerunning or resuming additionally requires the recorded runtime and baseline.

execute and --resume require a POSIX host, the research/development dependencies and Node.js. The runner's host requirement does not change the application's supported platforms. Read validation_r34_byos/test_execution.json for the actual execution status and limitations. The gate uses scripted provider HTTP responses, local numerical execution, SQLite and loopback storage fixtures; it does not establish live paid-model accuracy, production PostgreSQL, deployed Docker isolation or a live cloud/NAS deployment.