Gather — the spec

Gather is a client-portal web app that gives small teams (2–10 people) a shared space to collect, annotate, and draft web content together. Instead of content living in scattered browser bookmarks or Slack threads, teams work from a single organized source of truth — structured around collections, governed by permissions, and built for the write-draft-review loop.

---

Decisions locked

---

The core loop

1. A team member creates a new collection (e.g. "Q3 Blog Research") and sets permission levels for each teammate.
2. They paste a URL or upload a file to add a snippet to the collection, then annotate it with a note or highlight.
3. A writer opens the collection, reviews the annotated snippets, and drafts content in-context.
4. A reviewer with editor-level access reads the draft, leaves inline comments, and marks it ready.
5. The team lead with admin access approves and closes the review cycle.

---

v1 scope

Team-wide shared collections and folders
Collections are the primary organizational unit — named, nestable into folders, and visible to every invited team member based on their permissions. Lives on the main dashboard and the collection detail screen.

Permission levels per collection or folder
Three roles — Viewer, Editor, Admin — assigned at the collection or folder level, not just globally. Admins control who can read, annotate, or manage each collection. Managed from a collection settings panel.

Snippet capture and annotation tools
Team members paste a URL or upload a file to create a snippet inside a collection. Each snippet supports a highlight and a free-text note. Drafting happens inline alongside the captured content on the collection detail screen.

---

Deliberately later

• One-click browser extension save — validating the core loop with manual URL input first keeps v1 scope tight; the extension adds real value once collections have proven daily-use habits.
• Full-text search — meaningful only after teams have accumulated enough content that browsing breaks down; premature search adds infrastructure cost with low day-one payoff.
• Tagging and keyword filtering — folders and permissions are the v1 navigation layer; a tag taxonomy becomes useful when collections number in the dozens.
• Activity feed of recent team saves — a social layer that accelerates engagement at scale; irrelevant when teams are small enough to communicate directly.
• Export to markdown or PDF — a workflow exit ramp that matters post-adoption; shipping it at v1 risks optimizing for output before the input habit is formed.

---

Data model sketch

• users — id, name, email, hashed_password, created_at
• teams — id, name, owner_user_id, created_at
• team_members — id, team_id, user_id, global_role (owner | member)
• collections — id, team_id, name, parent_folder_id (nullable), created_by, created_at
• collection_permissions — id, collection_id, user_id, role (viewer | editor | admin)
• snippets — id, collection_id, source_url (nullable), file_upload_url (nullable), raw_content, created_by, created_at
• annotations — id, snippet_id, user_id, highlight_text, note, created_at
• drafts — id, collection_id, snippet_id (nullable), body_text, status (draft | in_review | approved), created_by, updated_at
• uploads — id, user_id, file_name, file_url, mime_type, created_at

---

Screens

• Login / Sign-up — account creation and authentication for team members.
• Dashboard — lists all collections and folders the current user can access.
• Collection detail — displays snippets, annotations, and drafts within one collection.
• Snippet view — shows captured content with highlight and annotation tools alongside the draft editor.
• Collection settings — manages name, folder placement, and per-user permission levels.
• Team admin panel — invites members, manages team-wide roles, and handles billing.
• Notifications / inbox — surfaces review requests and annotation replies via email or SMS trigger.

---

How to use this document

• Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
• Hand it to a developer as the complete v1 brief — scope, data model, and screen list are all here.
• Keep it as the single source of truth while you build, so every feature decision stays anchored to what v1 is actually for.