Project Types — Prototype Spec

01The link

02The four types

Every surface reads one canonical order, defined once in src/core/types/ProjectType.ts. It is a reading order: the work with a client and a clock on it first, then the type that behaves most like it, then the two cultivated pools that are rarely urgent.

Pipelines, Succession Plans and Talent Pools share one capability profile — no fee, no contract, no client mandate. Wherever a screen behaves differently “on a Talent Pool, Pipeline or Succession Plan”, it is that one set being tested, not three separate branches (POOL_LIKE_PROJECT_TYPES).

03Screen by screen

Each screenshot is the prototype as deployed. The components underneath are the real ones, edited in place — that edit is the design spec.

Projects index — one type at a time

The index shows exactly one project type at a time, chosen from the header picker. That single-select rule is what makes the rest of the index coherent: stage positions are only comparable inside one type's stage set, so “highest stage reached” can only be filtered or sorted once the list is narrowed to one type. Per-type columns, per-type status options and the incumbent filter all follow from the same premise.

Create Project

Admin → Customization → Project Workflow → Stages

Each project type edits its own stage set, so the tab renders one section per type rather than one table. Editing one does not affect the others.

Project panel — candidate board

Project panel — candidate table (new)

A third view alongside kanban and list. Rows are grouped into collapsible stage buckets, so the stage set stays legible as a spine while the row data becomes scannable and sortable in a way the cards never were.

Person panel — Projects tab

Hub

04Rules the prototype encodes

These are invariants, not pixels. They are the part most likely to be lost in translation, so they are stated explicitly.

• One canonical order, defined once. PROJECT_TYPE_ORDER is read by the index picker, the Hub's sections, the person panel's sub-tabs, and the create and edit forms. There were four separate orderings at one point, each individually justified — which is exactly how a product ends up naming the same four things in four sequences. Do not add a second one. The admin Stages page is the single documented exception, and it says so in a comment.
• A type is always rendered. project_type_id is NOT NULL and existing rows backfill to Search, so the card, global search and both project autocompletes always show a type, falling back to Search rather than omitting the chip. The filters had already chosen that fallback, and display disagreeing with filtering is worse than either rule alone. A project rendering no type is a data defect to raise, not a state to design for.
• Search is the fallback everywhere, not an error case. Everything predating project types belongs to Search: the original stage set, the original column set, and any project List — which spans types and so has no type of its own.
• The index is single-select by necessity. Not a UI preference. Stage positions are only comparable inside one type's stage set.
• Type-scoped filters clear on a type switch; type-agnostic ones survive. Stage and incumbent are scoped; status, company, tags and dates are not.
• The index view preference is client-side and per-device. It is the same class of state as the grid/list toggle beside it, not an account setting worth a round trip. A stored value that is no longer a real tag falls back to the tenant default rather than filtering the list down to nothing.

// src/core/types/ProjectType.ts

export const PROJECT_TYPE_ORDER: readonly TProjectTypeTag[] = [
  'search',
  'succession_plan',
  'pipeline',
  'talent_pool',
];

export const POOL_LIKE_PROJECT_TYPES: readonly TProjectTypeTag[] = [
  'pipeline',
  'succession_plan',
  'talent_pool',
];

export const DEFAULT_PROJECT_TYPE_TAG: TProjectTypeTag = 'search';

/** The incumbent is the only field that genuinely separates the pool-like types. */
export function hasIncumbent(tag: TProjectTypeTag): boolean {
  return tag === 'succession_plan';
}

export function defaultProjectTypeForTenant(isVcPeCustomer: boolean): TProjectTypeTag {
  return isVcPeCustomer ? 'pipeline' : 'search';
}

// admin Stages: a section reads its config instead of branching on the tag inline.
// src/legacy/pages/admin/customization/project-workflow/components/projectTypesData.ts

export type TProjectTypeConfig = {
  tag: TProjectTypeTag;
  showOffLimits: boolean;            // Search only: presupposes an engagement
  showHideCandidatesToggle: boolean; // Search only: presupposes a client who can see it
};

// Section order here is ALPHABETICAL — the one exception to PROJECT_TYPE_ORDER.
export const PROJECT_TYPES: readonly TProjectTypeConfig[] = [
  { tag: 'pipeline',        showOffLimits: false, showHideCandidatesToggle: false },
  { tag: 'search',          showOffLimits: true,  showHideCandidatesToggle: true  },
  { tag: 'succession_plan', showOffLimits: false, showHideCandidatesToggle: false },
  { tag: 'talent_pool',     showOffLimits: false, showHideCandidatesToggle: false },
];

05What's real and what's faked

The prototype runs the actual application bundle. Everything you see rendered is the real component tree; everything it asks the network for is intercepted.

06Known gaps in the prototype

Artefacts of the mock layer, not intended design. Flagged so nobody builds them.

• gap  Deep links into a panel tab 404. Pasting /people/<id>/associations straight into the address bar lands on Page Not Found. Open the record first, then click the tab. Not a design change — an unhandled route in the prototype.
• gap  A few endpoints have no handler, so those areas render empty or as skeletons: the person panel's Experience tab (employments/grouped_by_company, educations), task counts, custom report templates, and outreach sources. Unrelated to Project Types.
• gap  Only one tenant type is live at the shared URL. The deployment opens on Executive Search Firm. The VC/PE default shown in section 03 needs a different launch flag, so treat that screenshot as the specification for the behaviour.

07Where the code is

These are the files the prototype actually changed. There is no diff to read, so this list is the map.

08Related documents

• Product brief — 2026-08-20_product-brief_project-types.md
• Solution design — 2026-08-20_solution-design_project-types.md
• Decision memo — 2026-08-20_decision-memo_project-types.md
• Jira epic — 2026-08-25_jira-epic_project-types.md
• Visual brief — 2026-08-25_visual-brief_project-types.html