Note

    ../../DOCS/features/projects.md

    Source Summary title: Projects description: Public list/detail pages for project supernodes that function as Hyphenomenon's primary project and proof surface...

    Source Summary

    --- title: Projects description: Public list/detail pages for project supernodes that function as Hyphenomenon's primary project and proof surfaces status: evolving lastUpdated: 2026-05-07 owner: Product/Engineering --- # Projects ## Routes - Index: /projects - Detail: /projects/:slug ## Purpose - Publish project supernodes that capture initiatives, prog

    Imported Context

    title: Projects description: Public list/detail pages for project supernodes that function as Hyphenomenon's primary project and proof surfaces status: evolving lastUpdated: 2026-05-07 owner: Product/Engineering

    Projects

    Routes

    • Index: /projects
    • Detail: /projects/:slug

    Purpose

    • Publish project supernodes that capture initiatives, programs, and experiments.
    • Group related constellation nodes under one project context and enable scoped exploration.
    • Support both curated external links and graph-derived boundary links from member-to-nonmember edges.
    • Feature project workflows inline on the detail page when relatedProjectSlugs references the project.
    • Treat project detail pages as the primary proof surface for Hyphenomenon.
    • Present each project with an editorial narrative instead of a metadata dump.
    • Keep screenshot galleries owned by the project (not note surfaces) and use them as evidence.

    Project Layout

    Project detail pages should generally follow this sequence:

    • Hero: title, summary, domains, key calls to action, and at-a-glance proof signals.
    • Case-study guide: a compact reading-path index that anchors the reader through the page in editorial order.
    • Narrative: editorial sections that explain context, approach, system shape, and outcomes.
    • Product surfaces: concrete user- or operator-facing surfaces tied to the project.
    • System design: data models, architecture highlights, and tech stack evidence.
    • Workflow design: repeatable process and AI/human collaboration structure where relevant.
    • Supporting evidence: connected artifacts and boundary links that deepen trust.

    Data Source Contract

    • Server-side catalog readers (canonical public catalog from knowledge backbone):
      • getProjects()
      • getProjectBySlug(slug)
    • Repo-authored fallback projects are merged into the runtime catalog when the DB-backed project set is partial; DB records win when slugs collide.
    • Pages are rendered with dynamic = "force-dynamic" so updates appear at runtime.
    • /projects renders the full public project catalog. The homepage project section is an editorial preview capped at four projects.

    UI Components

    ProjectCard

    src/components/ui/ProjectCard.tsx — shared building block used by all project list surfaces.

    Props:

    PropTypeDefaultDescription
    projectProjectrequiredProject data object
    variant"mediaRow" | "row" | "tile""mediaRow"Layout variant
    animationDelaynumber—animationDelay ms for stagger fade-in
    classNamestring—Extra classes on the root element

    Variants:

    • mediaRow — horizontal list entry with feature image, summary, and proof items derived from canonical metadata. Used on the homepage and /projects index.
    • row — horizontal text-first list entry (card-entry base). Left column: type + status badge. Right: title, domain tags, summary, and proof items.
    • tile — vertical card. aspect-[16/9] feature image on top (with subtle zoom-on-hover); falls back to a type-label placeholder. Below: type, status, domains, title, 2-line summary. Intended for grid layouts.

    Proof items:

    • Cards prefer visible evidence over generic scale.
    • When available, cards show counts for product surfaces, workflows, visuals, and key dates plus live-surface availability.
    • When richer evidence is unavailable, cards fall back to connected-node count.

    Domain/status rendering:

    • Only known domains (from DOMAINS constant in src/lib/domains.ts) are rendered as DomainTag badges. Unknown/custom domains are silently filtered.
    • status is rendered as a StatusBadge only when present (optional on Project).

    Feature image:

    • Add featureImage: { src: string; alt?: string } to a Project entry in src/content/projects.ts.
    • Local images: place in /public and use a root-relative path (e.g. /images/projects/my-project.jpg). No Next.js config changes needed.
    • External images: add the host to images.remotePatterns in next.config.mjs.

    Project Detail Supporting Blocks

    • A sticky case-study guide in the right rail links to each available proof section on the page.
    • Workflows are shown as compact summary cards in a grid (not full workflow cards).
    • Each workflow item links to the workflow detail page and highlights step counts.
    • Connected references should only point outward; links back to the current project are filtered out.
    • Screenshot galleries are attached to the project via meta.screenshots on the project entity (no screenshot-gallery notes).
    • The detail route uses a right rail for screenshot evidence, key dates, and outbound links.
    • Supporting artifacts stay visible, but below the main story so they reinforce narrative instead of competing with it.

    Primary Files

    • src/content/projects.ts — Project type definition + catalog
    • src/components/ui/ProjectCard.tsx — shared ProjectCard component
    • src/app/projects/page.tsx — projects index (uses variant="row")
    • src/app/_components/home/ProjectSectionAlternates.tsx — homepage project preview sections backed by the canonical catalog
    • src/app/projects/[slug]/page.tsx — project detail page
    • src/lib/server/content-catalog.ts — server-side catalog readers

    Provenance