Can I vibecode DocSend?

You are building a production-ready software product named “Prooflink”, a deliberately focused alternative to DocSend. Build a complete, usable vertical slice—not a landing page, static mockup, or disconnected collection of components.

WORKING AGREEMENT
Before writing implementation code, produce a short technical plan that names the routes or pages, server actions or endpoints, data tables, important state transitions, authorization boundaries, background jobs, and external adapters. Resolve contradictions in favor of the narrow audience and non-goals below. Prefer a small, legible architecture over speculative abstraction, but do not omit persistence, validation, error handling, or tests.

PRODUCT BRIEF
Primary user: a founder sharing pitch decks and sales documents.
Primary outcome: share a PDF with access controls and see whether recipients opened it.
Product principle: optimize the exact workflow below instead of copying the full breadth of DocSend. A first-time user should understand what to do from the interface itself, without a tour or documentation.

END-TO-END USER JOURNEYS
Implement all of these flows through the real interface and persistent data layer:
1. A founder uploads a PDF, confirms page count and title, applies lightweight company branding, then creates separate share links for two prospects.
2. A prospect opens an email-gated, passcode-protected link, starts a viewer session, reads selected pages in the browser, leaves, and later resumes through the same link.
3. The founder compares link activity, opens a session timeline with approximate page durations, exports analytics to CSV, duplicates a link, and revokes the original.

SCREENS AND INFORMATION ARCHITECTURE
Build these as coherent responsive views. Each screen must specify its primary action, secondary actions, visible status, validation feedback, empty state, loading or pending state, success confirmation, and recoverable failure state.
1. Document library: upload state, title, page count, created date, active-link count, recent views, search, rename, archive, and document-detail actions.
2. Document and link settings: branding preview, link name, email gate, passcode, expiry, active state, copy action, duplicate, revoke, and validation summary.
3. Secure PDF viewer: branded header, page canvas, page navigation, zoom, session status, access-expiry messaging, and no direct public object URL.
4. Analytics: totals by share link, gated viewer email when supplied, first and last activity, approximate duration, ordered page-view timeline, and filtered CSV export.

CORE CAPABILITIES
1. PDF upload with title and optional company branding
2. share links with email gate, passcode, and expiry
3. browser PDF viewer without a raw public object URL
4. visit timeline with pages viewed and total duration
5. link revoke, duplicate, and CSV analytics export

DETAILED BEHAVIOR AND BUSINESS RULES
Treat these as server-enforced product requirements, not interface suggestions:
1. Keep original PDFs private and authorize every page or range request against an active share link and viewer session using short-lived signed delivery.
2. Hash link passcodes, rate-limit attempts, normalize gated email addresses, and record the access terms that were satisfied without treating email as verified identity.
3. Calculate page duration from visibility and navigation events with idle cutoffs; label all analytics approximate and never add device fingerprinting.
4. Revocation and expiry prevent new viewer sessions and media grants immediately, while historical analytics remain attributable to the original immutable link identifier.

DATA MODEL AND LIFECYCLE
Design a small relational schema centered on Document, ShareLink, ViewerSession, PageView. Before implementing it, document:
1. Each table’s purpose, primary key, ownership or tenant boundary, timestamps, status fields, and important attributes.
2. Foreign keys, uniqueness constraints, check constraints, indexes needed by the named ...