162af9a7b8
Save the current implementation and README, status, and known-issue documentation at the user-requested stop. No completed release or deployment is claimed. Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: GPT-6 Codex <noreply@openai.com>
3.7 KiB
Native file and collection workflows
Record Files exposes standard QQQ record actions and forms. The action steps call the existing FileReviewService or CollectionService; they do not write tables directly or bypass the services' current permissions, source visibility, lifecycle checks and mandatory audits.
From a managed record's Files panel, Review retained files and File collections open native queries pinned to that source table and canonical record ID. These links come from server metadata. The generic frontend validates that metadata and always appends the current source pins; the server remains authoritative if someone edits a URL. Ordinary Collaboration installations without this metadata show no extra links. The interrupted-upload recovery link remains separate.
On a retained file, use Change review status, Change category, Release quarantined file, or Mark quarantined file failed. Review statuses and categories use native searchable references to user-authored configuration. A required review note is checked by the service. A blank category clears classification. Release is a human decision requiring record-files.release; it is not a malware-scan verdict. Marking failure retains the original and denies content access. Routine changes use the normal Submit action.
On the business record, Create file collection asks for a title and optional expected item count. The result references the new collection. A newly launched create action intentionally creates another collection; there is no distributed exactly-once claim for manual process creation.
On an OPEN collection, Add retained file accepts an exact retained version and optional caption. The service checks that it belongs to the same source and rejects duplicate membership. Reorder collection displays filenames and captions with keyboard-accessible Move up and Move down controls. The client loads the complete bounded list before enabling changes and submits the exact identities automatically; users do not enter internal IDs. Missing, duplicate, malformed or additional identities are rejected. The service locks the collection and persists positions and the success event in one transaction. The native collection-item association provides normal detail navigation to member files.
Finalize collection explicitly confirms that membership and order will be fixed, then verifies the expected count, at least one member, and released/superseded content before closing membership and order. A quarantined or failed member leaves the collection OPEN. Repeated add/finalize operations fail safely rather than creating duplicate members or success events. Identical review/category updates retain the services' existing idempotency. Permission and current source checks run again when Save executes, even after a form was opened successfully.
Supported deployment evidence remains the qualified file-H2 configuration and existing storage-owner constraints. Native process tests exercise real file-H2 state and audits, but are not proof of production object-store retention, malware scanning, broad-table pagination, or a deployed UI host.
Verified print observations
The independent Record Files app exposes the standard record_files_observe_print process to a currently authorized reporter when a trusted Java authority is configured. Input is only the accepted intent ID and committed event ID; the service verifies evidence and durably records/replays it. The reporter does not need source-byte access and cannot assert a result state. See PRINT-OBSERVATIONS.md for the authority and evidence contract. Parent gate 57042 passed 27 selected tests with Checkstyle, including all six new native-process cases and the existing trusted-observation/producer regressions.