BROWSER WORKFLOW · WORKSPACE UI 19

Keep and link original documents

Upload exact source revisions into reviewed folders without changing existing procedure links

Open the saved library

In the browser, open Sidebar → Documents → Original files. The existing library is also available from Account → Original files. It has a folder pane, exact revision cards, search, archived filter and saved details. Close another operational form before opening it. Original files Help opens separately without submitting anything.

All files includes every permitted project original matching the archive filter. Library root means no folder has been assigned; it is not another copy of the file. A folder shows its directly assigned revisions, not all descendants. Folder counts use the archive filter and count revisions, not unique document families or approved procedures.

Search all folders matches title, code, source revision, filename or the saved folder path, even when another folder was selected. Results display their location. Changing the search, archive filter or selected folder clears document selections so hidden rows cannot be moved accidentally. Include archived revisions shows earlier retained sources; archived does not mean deleted.

Details shows the exact revision ID, family ID, SHA-256 checksum, original filename, source revision, import metadata, notes and folder path. These are saved metadata, not an approval of the file. Refresh saved library reads again; a failed refresh clears old rows and offers Retry instead of claiming the folder is empty.

Missing from the demo? Original files is shown only when the signed-in project account has Original documents → View and download original documents. An administrator can review that permission in Administration. Public visitors use the configured non-administrator guest; do not make that account an administrator to expose the menu. Uploading originals and organising folders remain named-administrator actions. The sidebar entry opens the same library without changing its files, permissions or the underlying workspace.

Create and organise folders

Named project administrators with Original-file access can use Create folder, or select a folder and choose Rename folder, Move folder or Remove empty folder. Choose the destination/name, enter a reason and choose Review change. Review the path and affected contents, explicitly confirm, then choose Save folder change. Back or editing requires fresh confirmation. Merely opening a form or choosing a destination saves nothing.

Folders are shared project metadata, not Windows directories, a personal browser preference or permission boundaries. They do not change who can access an original. Only the organisation tables change; stored file bytes, filenames, titles, source revisions, exact IDs and hashes remain unchanged. Existing checklist and maintenance links keep their original pinned revisions. Moving or renaming a parent updates displayed descendant paths, not the source documents.

The first folder pass supports up to 200 folders, six levels below Original files and names of up to 80 characters. Names are unique within their parent after Unicode normalisation and case folding. Enter one name, not a slash-separated path. The root cannot be renamed, moved or removed. Cycles and over-deep trees are refused.

Remove empty folder removes only that folder record. Child folders and all assigned revisions, including archived files hidden by the filter, prevent removal. It never deletes files or recursively removes contents. Move those revisions deliberately first. There is no automatic classification or template-generated folder tree.

Move exact source revisions

Select the actual revision cards, or use Select displayed (up to 100), then Move selected revisions. The review lists each title, source revision, exact revision ID, previous location and proposed destination. Enter a reason, confirm and save. A single action accepts at most 100 revisions. Selecting revision A does not move revision B automatically, even when they belong to the same document family.

Select a destination different from every selected revision's current folder. Library root deliberately removes the folder assignment; it does not delete the source. Moves are transactional: an invalid selected revision, missing folder or changed catalogue refuses the whole proposal, not just the affected row.

Saved outcomes and folder history

The server compares the complete reviewed library snapshot again inside the write transaction. A newly imported, archived or removed revision, or another saved folder change, can make that review stale. After a refusal, cancel the proposal, refresh the library and review again. The existing named-account, project and Original-file permission checks still apply. Readers can browse and download but cannot organise folders or view the administrator folder-history screen.

Folder history shows the most recent 100 folder operations, with administrator, time, reason and changed paths/revisions. Earlier folder history remains stored; the viewer is limited. File import/archive/permanent-removal history remains separate. Each revision move also appends to that original's existing audit trail; earlier history is not rewritten.

Folder proposals exist only in the open browser form. They are not offline drafts or automatically queued work. Closing an unfinished proposal warns before discarding it. Ordinary Close/Escape and duplicate save are blocked during a save. A request already sent may still complete after a workspace change; the guard cannot undo a committed action.

A lost or unreadable response is an unconfirmed outcome, not proof of failure. Retain the tab and use Retry same operation: the same operation ID and exact proposal can return its recorded result without applying the change twice. A refused request instead requires a refreshed review. Losing the tab loses that in-memory retry context; inspect the saved library and folder history before starting a replacement action. No recovery, offline or exactly-once guarantee is implied beyond the server's recorded operation replay.

Original downloads and supported files

Open / save original requests the existing authorised file download. The server verifies stored size and checksum; browsers with Web Crypto also check the downloaded SHA-256. Plain HTTP local browsers may lack that independent browser check. The UI18 library rechecks the selected account/session and open view before sending and after the asynchronous download/checksum work. It does not render Office/PDF contents as trusted application HTML or create an automatic offline file cache.

The existing library limit is 500 original revisions per project. Excel originals keep all worksheets, hidden tabs, formatting, formulas, pictures, VBA and saved connections unchanged. Wavelink does not run macros, calculate cells or refresh queries. A container check is not a malware scan or content approval. Review hidden sheets, credentials and metadata before sharing a complete file; active content in a downloaded file must follow IT policy.

Upload a new original in the browser

A named project administrator with Original-file access can choose Upload new original. Use the established HTTPS address or localhost: the form requires browser SHA-256 file verification. It reads a fresh authorised library snapshot, but opening it creates nothing. Upload one supported file of up to 20 MB, including Excel. Larger Excel originals retain their native-admin import route.

The guide follows File & document → Destination & reason → Review upload. Select the file, enter its title, code, source revision and notes, then explicitly choose a folder or Original files (Library root / unfiled). No destination is preselected. Give a reason for the import. Review the filename, exact byte size, SHA-256, source revision, folder, reason and upload reference. Explicitly confirm and choose Upload original. Back, changes or refreshing the saved library requires fresh confirmation.

The hub validates the received bytes and size, rechecks the current account and library, then saves the immutable original, location, import audit and operation receipt in one transaction. An invalid file or stale review saves none of those parts. Folder selection is organisation, not an access boundary. Uploading does not publish or approve a procedure, create working log rows, or change source links in an existing checklist or maintenance order. Signature/container checks are not malware scanning.

Add a new source revision

On an active revision card or its Details page, choose Add revision. The guide names the exact earlier revision ID and document family. Choose the new file, enter a different source revision label and explicitly select its own destination. A blank new revision or a duplicate label in that family, including case-only differences, is refused. An archived selected revision cannot start this action.

The new revision receives a new ID in the selected family. Earlier bytes, IDs, hashes, archive state, folder locations and frozen procedure references stay unchanged. The application does not automatically archive earlier revisions or relink existing records. Publishing or changing a linked procedure remains a separate reviewed workflow.

Upload outcomes, retry and local work

File selections and upload values exist only in the open form: there is no offline upload queue or automatic draft. The ordinary save-status journal stores operation metadata, not the file, filename, title or reason. Preserve other unsent Wavelink work. Cancel and Close warn about abandoning an unfinished upload; Close/Escape and duplicate submission are blocked while preparing or sending a file. A sent request can still commit after a lost connection or changed page.

A confirmed receipt shows the saved exact revision ID, hash, destination at upload and time. Show saved revision in library reads the library again; later moves or archival may differ from that original receipt. A failed browser refresh does not undo a confirmed upload.

After an unconfirmed response, the exact file, review and upload reference are held unchanged. Use Retry same upload to resend that same request, or Check saved upload outcome to look up its operation receipt without resending file bytes. A matching receipt confirms the original save and settles only its matching local upload warning. Ordinary library GETs do not confirm writes. An unavailable receipt can mean the earlier request is still running; it is not proof that nothing saved.

A changed account, session, project or form prevents further sending from the old view. The retry and status lookup both recheck current authority. Closing or reloading loses the memory-only file and retry context: record the upload reference and inspect the original project's saved library before another upload. A known local receipt-storage failure before transmission is reported as not sent, not a successful hub save. If the hub receipt is confirmed but local warning storage fails, retain that receipt and review Connection & saves rather than repeat the import.

Native import, linking and source lifecycle

The existing Windows route remains available: Admin → Original documents → Add original… / Add revision…. Native imports continue to start at Library root and keep their existing size limits. The UI19 browser now supports the separate reviewed upload workflow above, including its explicit destination. Native folder-authoring controls are not added by this browser release.

Link an original through Checklist Editor → Document tools → Link originals… or the Builder's Introduction & details step, then save and publish after review. Existing operational records retain their exact source revisions. Browser checklist definition editing does not replace the native original-link editor. Existing linked-original buttons remain available in checklist document details.

Archive / restore… hides/restores a source for normal selection without breaking saved links. Native Used by… shows source dependencies. Permanent file deletion is still a separate native action requiring an archived, unreferenced source, its exact title and a reason. The browser folder controls offer no file deletion or approval action.

Original documents stores source files without creating working log rows. Use Logs → Logbook setup → Import workbook… or a prepared .ajlogs package for the separate reviewed working-log import. Editing a downloaded copy does not replace the stored original; import another source revision.

Transfer, rollback and boundaries

Using this UI18 runtime, Complete project and supported selected-workspace transfers that include Original documents retain logical folders, revision locations and folder history. Excluding that workspace removes its folder metadata from the disposable exported copy as well; the source project is untouched. These are sensitive whole-workspace transfers, not permission-filtered sharing. Import into a new project using the established reviewed transfer workflow.

Older reusable-setup and linked-template exports keep their existing format and do not carry folder organisation. Native folder authoring remains unfinished. Browser destination choice is now available. Selective workspace transfers deliberately clear the existing operation-retry cache; an in-flight browser upload cannot be resumed across a transferred project. Keep and review its result in the original project first. A UI17 rollback retains the added database tables and original bytes but hides folder organisation; older selective-export code may refuse the unfamiliar tables. Do not downgrade, delete tables or reset a project to force an export.

This browser/server update does not provide cloud/vessel synchronisation, new company isolation, an embedded Office editor, malware scanning, operational approval or an approved off-host recovery procedure. Preserve unsent browser work and the persistent project. The pristine recovery helper remains unapproved for the overlaid runtime.