From local source files to a clean client decision record.

Start with the decision

Create a project and write the brief before importing files. A useful brief says what the recipient is reviewing, which decision is expected, and how the returned response should be sent.

1. Name the project and round.

   Use a stable reference code when filenames or client names may repeat.

2. Choose the default policy.

   Proofing records a per-version outcome; selection enforces a count; comment-only asks for narrative feedback.

3. Add reviewer slots.

   Export one distribution per reviewer if separate lanes matter. Slot labels are organizational, not identity verification.

4. Choose preview settings.

   Preview size affects readability and package weight. Watermarks deter casual reuse but do not prevent copying.

Prepare review derivatives

Drop JPEG, PNG, static WebP, or PDF files onto the Assets screen. Each source is inspected before a derivative is committed. Choose an explicit PDF page range, inspect first-page thumbnails, warnings, duplicates, and failures, then choose the destination section. PNG derivatives retain transparency; JPEG, WebP, and PDF pages use bounded JPEG previews. The folder control is a browser-dependent, one-time batch picker: it does not grant persistent directory access, watch a folder, synchronize changes, or keep a live folder link. Use Choose files when directory selection is unsupported.

Organize the light table

• Keep the current asset filename visible while adding a clearer client-facing title. Every version retains its own recorded, NFC-normalized source filename for comparison, search, response display, and reports.
• The Brief screen's Primary section policy edits only the named first section, which is the initial intake target. Add or manage every other section and its independent policy on Assets.
• Group work into sections; rename, describe, reorder, delete, and set a policy for each section in the section manager. Proofing and comment policies can require a response only from included assets also marked Required response. A selection policy instead requires every included item to be decided and enforces its section count; it has no separate closing-note field.
• When selected assets move into a selection section, incompatible item-level policy overrides are cleared so the one section-wide count remains valid. Choosing the section they already occupy makes no project revision when no override needs clearing.
• Mark required items and exclude anything that should remain internal.
• Add a replacement as a new version of the same logical asset when decisions should remain traceable.
• Use keyboard move controls whenever drag-and-drop is inconvenient.

Preflight and generate

Preflight checks included items, page counts, rules, metadata, matching prior versions, naming collisions, compatibility limits, and output size. When prior versions are enabled, every prior version containing a current unit's page number is included; a prior version without that page is omitted with a warning. Generation is available only after blocking findings are resolved.

For self-contained HTML, Recipient Preview opens the same embedded review shell with disposable feedback state. The preview control is not a .reviewpack Reader test: download a .reviewpack and open it through Reader before sending. A .reviewpack does not contain Reader and is not a standalone double-click document; the recipient must first load Reader from the product site over HTTPS or localhost, or use a locally served product copy. Offline reopening works only after the Reader shell and its bundled assets are cached.

Instructions for the recipient

1. Open the HTML file, or load Reader and choose the .reviewpack.

   The HTML package is self-contained. A .reviewpack requires separately available Reader; selecting it does not upload the package through this application.

2. Review each required item.

   Keep favorites separate from formal decisions. Pins and rectangles remain tied to an exact version and PDF page.

3. Download drafts during a long review.

   When browser storage is available, Reader stores convenience state under the exact distribution and manifest digest and validates the response before restoring it. This state can still be cleared or evicted, and local-file origins vary, so an explicitly downloaded draft remains the durable path.

4. Check the final summary.

   Selection limits and missing required feedback must be resolved before completion.

5. Return the downloaded .review.json.

   The response contains structured decisions and comments, not the preview images.

Import without overwriting history

The response inspector validates project, package, distribution, revision, manifest digest, asset IDs, version IDs, pages, limits, and relationships before mutation.

• A wrong project or changed manifest is rejected.
• An exact duplicate is a no-op.
• The same responseId with a higher responseRevision is an amendment. Its comparison covers added, changed, and removed decisions; added, edited, resolved, reopened, and removed threads; favorites; acknowledgement; response status; completion; and reviewer label/reference changes.
• A new responseId starts independent response history in its exact round, even if reviewer labels match an earlier return.
• An old-version binding is classified as stale, rendered with its recorded historical filename/version/page and feedback, and never becomes current approval.

Reviewer slot, name, and reference are unverified labels, not response identity. The decision matrix contains every exact packaged version/page in the selected round's immutable sent manifests, including older versions that the recipient could inspect; current project assets and versions never sent in that round are excluded. Creator resolutions and standalone tasks made from the creator-outcome cell are selected-round records. "Resolve visible rows" applies one canonical outcome, and one optional note, to every row the current matrix filter is showing, writing exactly the records the single-cell path writes; rows whose asset is no longer in the project are skipped and counted. Reviewer responses are never changed by it. A task linked to reviewer feedback, or made from a specific reviewer cell, carries complete package, distribution, response-lane, and matching item/version/page provenance. A round-wide resolution or task appears in each exact-distribution checklist whose sent manifest contains that binding; a lane-linked task appears only in its exact distribution. If a later amendment removes or suppresses its linked thread, the creator task remains in the checklist as a historical linked-task row. Legacy unscoped entries are labeled and excluded from follow-up and report scopes; resaving a legacy resolution scopes that resolution to the selected round. Removing an asset explicitly removes its linked creator resolutions and tasks while retaining immutable package and reviewer-response history. Historical feedback for a removed asset never creates an empty follow-up package: it is skipped when valid current assets remain, or the operation stops with an explanation. Revision tasks remain editable and can shape follow-up scope without modifying reviewer history.

Back up meaningful work

IndexedDB helps the application reopen projects, but browser storage can be cleared or evicted. Export a versioned .reviewproject archive after an intake, response import, or reconciliation session. Import verifies every archived blob and replaces matching local blob bytes as part of the atomic restore, so an intact archive can repair local bytes whose metadata survived browser-storage damage. Scoped creator records are also checked against the exact sent-manifest bindings before the archive is accepted.

Choose the record that fits the handoff

• Decision ledger CSV: exact asset, recorded source filename, version, page, reviewer lane, and outcome.
• Comments and regions CSV: text, requested action, priority, and normalized coordinates.
• Revision checklist CSV: reviewer feedback joined to creator outcomes and revision tasks, with stable version and response IDs so duplicate labels or thread IDs remain distinguishable.
• Filename selection list: a plain-text bridge back to original-file catalogs.
• Accessible HTML summary: readable without spreadsheet software.
• Contact-sheet HTML: printable visual overview. When embedded previews would exceed its 16 MiB UTF-8 ceiling, it becomes a printable text and decision index with an explanation instead of embedding images. A PDF made through the browser's Print command is not claimed to be tagged-accessible.
• Project activity snapshot: project identity/revision metadata, the exact manifest without preview bytes, imported response revisions for the distribution, creator resolutions, revision tasks, and derived active/superseded identifiers plus conflict, stale-binding, and open-thread counts. It contains no local event log or evidence-grade audit history; names and device times remain unverified.
• Handoff and checksum text: scope prompts plus SHA-256 verification for the exported report set.

Each export captures one validated workspace snapshot before restoring any manifest, so edits or imports made while the files are being built cannot mix report moments. Each operational report uses the newest amendment for each responseId. The activity snapshot retains the imported response revisions supplied for that exact distribution. Multi-distribution and all-report exports normally use one ZIP with a separate folder per exact distribution. When a report set exceeds the bounded ZIP capacity, export produces numbered ZIP parts; an oversized individual textual artifact is losslessly split into numbered chunks with reassembly instructions. Multipart exports open a list of explicit download links instead of starting several automatic downloads. The status records that a request was started, not that the browser saved it; verify every numbered part in Downloads.