---
type: reference
title: Proto Preview's project overview — teardown
slug: prototype-overview-teardown
status: active
owner: adi
created: 2026-09-01
summary: >
  What Adi's WordPress prototype (prototype.demoing.info) does on its single-project
  overview, read from source at /srv/apps/prototype/wp-content/plugins/proto-preview.
  Records the data model and the three views, and marks which parts are in easel's
  scope and which belong to `review`.
---

# Proto Preview's overview — what it actually does

Source: `/srv/apps/prototype/wp-content/plugins/proto-preview/`
(`templates/player.php`, `assets/js/proto-preview-player.js` 3,231 lines,
`includes/class-proto-meta-boxes.php`). We are in `prototype-dev`, so read it
directly rather than from screenshots.

## The data model (the part that matters most)

**Screen** — `id · name · slug · nav_group (primary|subpage|footer) ·
parent_name · dev_url · status · visibility (internal|client) · layouts[]`

**Layout (= easel's option)** — `id · version ("Option 1") · name · file_path ·
badge · is_selected_choice`

Two fields carry most of the difference from easel:

- **`nav_group` + `parent_name` give screens a TREE.** The overview is not a
  gallery of screens, it is a **map of the site being designed**. This is what
  powers the sitemap view and the list view's hierarchy mode. easel's screens
  are a flat ordered list, which is why its board can only ever be a gallery.
- **`visibility: internal`** hides a screen from the client entirely, with an
  audience filter and a client-preview toggle for the designer.

**`status`** is a six-phase DELIVERY pipeline: building_prototype →
waiting_approval → building_page → waiting_review → done / later. Progress is a
weighted score over it (done 100, review 80, building 55…), shown as a % bar
plus filter chips with counts.

## Three views of one dataset, each answering a different question

Deep-linked as `?overview=1&layout=matrix|sitemap|listview`.

1. **Matrix** — cards, up to 5 columns at 1920px. Which design?
2. **Sitemap** — the IA tree. What is this site?
3. **List** — a spreadsheet tracker with bulk-select and columns: # · Screen /
   Page Flow · Architecture Section · Audience Scope · Mockup & Dev URL ·
   Workflow & Delivery Phase · Comments & Notes · Action. Where is everything?

Plus: stakeholders as first-class (`team` + `client_stakeholders` with
name/email/role, copy-emails, a "🔔 Active Review / 🔕 Review Closed" badge),
search across screen and option names, and inline per-screen status editing.

## What easel already does better

Per-option thumbnails (the prototype shows only the active option's), real
auth and permissions, pins as resolvable threads, per-step approvals, stars,
the tool walkthrough, and sandboxed isolation of client-authored HTML.

## The scope line — this needs rian, not a judgement call here

The prototype's overview is a **project delivery dashboard** that contains a
design review. rian's `brief.md` scopes easel to the design-review step alone:
*"easel is the mockup presentation & feedback step; review (build signoff) is a
separate future caddie app."*

So the pipeline splits cleanly:

- **Legitimately easel's** — screen hierarchy (`parent`/`nav_group`), audience
  scope (internal screens), stakeholders, the three view modes, and a progress
  read computed from easel's OWN signals (options ready, beats approved,
  direction chosen).
- **`review`'s, not easel's** — `dev_url` and the build phases
  (`building_page`, `waiting_review` against staging). Porting those is how
  easel quietly becomes review.

A second reason to hold: easel's status is a PROJECT-level rollup of six frozen
states from the caddie tool contract, where the prototype's is per-SCREEN.
Per-screen status is a modelling change against a frozen contract.