RELAY.

01 / THE BUILDApproval belongs to a version

RELAY is a fictional client-review workspace for one sample project: Fieldwork Studio — Website Refresh. Its promise, “Good progress. Shared clearly.”, becomes useful only when the workspace can answer a precise question: what did the client actually approve?

The supplied 1.1 source follows a complete review loop. A business publishes a deliverable, a client reviews that version, requests a reasoned revision, and reviews a later version before approving it. Overview, Milestones, Deliverables, and Activity are connected views of that work, not four unrelated dashboard mockups.

The visual introduction uses a warm, layered CSS 3D composition. The working area is calmer: readable previews, selected versions, comments, comparison, and a clear decision state. This is not a real client engagement, a launched SaaS business, or evidence of reduced review time.

02 / THE BUILDA new version cannot inherit consent

This reference figure only explains eligibility. It does not publish deliverables or approve a real version. In the supplied backend, the selected version is only part of the check: the command also carries an expected project revision, and the server checks identity, membership, role, and command receipts.

Version 2 can remain historically approved while version 3 needs review. If a new publication arrives during a review, the old screen cannot quietly apply its decision to the new content. The appropriate response is to refresh and review the current version, not to turn a project-wide status green.

03 / THE BUILDTwo environments, different guarantees

The portable browser sandbox demonstrates the workflow with local state. Its business/client switch is a teaching control, not authentication. Browser storage and draft recovery do not establish multi-user authorization, cross-device persistence, or database transactions.

The separate local backend uses native Node HTTP and SQLite. It includes server-side command checks, immutable publications, revision conflict handling, and idempotent receipts. A transaction groups the mutation, activity entry, and receipt. That is a much narrower and more defensible statement than calling the activity feed tamper-proof.

The local identity helper is restricted to explicit local/test operation. It is not a public sign-in product. This package is not a Cloudflare Worker, D1 application, Hono service, or Vite project; porting it would be new engineering work.

04 / THE BUILDRecovery should preserve the reviewer’s work

The 1.1 package makes the unpublished preview reflect the actual draft. A draft retains its base version, and another publication requires a deliberate choice of a new base. Same-identity recovery preserves the selected version and draft, while late reads and overlapping saves are guarded against overwriting newer state.

An API failure is not relabeled a successful save, and reauthentication does not automatically replay a mutation whose outcome might be unknown. These behaviors matter more than decorative confirmation messages: they preserve the relationship between what someone saw, what they intended, and what the system accepted.

05 / THE BUILDWhat was checked here

The live domain returned RELAY’s title and JavaScript-required notice. Interactive live review was not verified because browser navigation was blocked. No client decision, publication, or production API mutation was attempted.

All 30 supplied compiled tests passed again, including the package’s local HTTP and SQLite checks. These tests run the supplied compiled build; they do not establish a fresh TypeScript compilation or clean dependency installation. The source-package image above is not a current production screenshot.

Before publication, verify the source-to-build relationship, native browser sessions and storage, origin and cookie behavior, the deployed version, and supported browsers. Real uploads, external notifications, billing, team chat, and production identity remain outside the demonstrated scope.