Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/apursley2012/sys-witch/llms.txt

Use this file to discover all available pages before exploring further.

RitualReport is the full-page case study renderer used on the Case Studies page. It accepts a single case study object and lays out every section of the narrative in a flowing vertical timeline — each section scrolls into view with a Framer Motion fade-and-rise animation as the user reaches it. A large, watermark-scale sigil icon sits behind the entire article at 5% opacity to ground the piece in the site’s occult visual language.

How It Renders

The component wraps its output in an <article> element. At the top sits a centred header containing a circular sigil icon (neon-cyan, drop-shadow-glow-cyan) and an <h2> title in font-display with a neon-cyan text glow. Below the header, each entry in the sections array is rendered as an animated <section> block inside a space-y-12 stack. Every section follows the same structure:
  1. Section heading row — a rotating rune sigil (rune-1 through rune-7, cycling by index) followed by the heading text in font-display uppercase.
  2. Content block — the body paragraph, indented with pl-9 and bordered on the left by a border-neon-cyan/20 line that visually connects it to the heading sigil.
A RuneDivider component in neon-cyan is appended after all sections to close the article.
All entrance animations use whileInView with viewport={{ once: true, margin: "-100px" }}, so each section triggers only once as it enters the visible area.

Props

PropTypeRequiredDescription
caseStudyobjectYesA case study entry from data/caseStudies.js

Data Structure

Each case study in data/caseStudies.js has a flat header and a sections array. There is no fixed schema for the sections — heading strings are free-form, but the existing entries establish the canonical set used in practice.
// data/caseStudies.js
{
  id: string,        // URL-safe identifier
  title: string,     // Full display title including "RITUAL REPORT:" prefix
  sigilId: string,   // Sigil ID used for the header icon and background watermark
  sections: [
    {
      heading: string,  // Section heading, rendered uppercase
      content: string,  // Body paragraph text
    }
  ]
}

Real Case Study Data

Both case studies currently in data/caseStudies.js are reproduced below.
// data/caseStudies.js
const caseStudies = [
  {
    id: "nexus-rebuild",
    title: "RITUAL REPORT: NEXUS DASHBOARD REBUILD",
    sigilId: "case-studies",
    sections: [
      {
        heading: "Problem",
        content:
          "The legacy dashboard was suffering from severe performance degradation when rendering more than 500 data points. The DOM was bloated, and React was struggling to reconcile the massive component tree during real-time updates.",
      },
      {
        heading: "Goal",
        content:
          "Refactor the visualization layer to handle 10,000+ data points at 60fps without sacrificing the interactive tooltips and glowing neon aesthetics required by the design spec.",
      },
      {
        heading: "Process",
        content:
          "I initiated a profiling ritual using Chrome DevTools to identify the exact bottlenecks. The primary issue was the overhead of React managing thousands of SVG nodes. I decided to pivot the rendering strategy.",
      },
      {
        heading: "Design Decisions",
        content:
          "Maintained the visual language but shifted the heavy lifting from SVG to Canvas for the data points, while keeping SVG for the axes and interactive overlays to preserve accessibility and ease of styling.",
      },
      {
        heading: "Dev Decisions",
        content:
          "Implemented a hybrid approach: D3.js calculates the math and scales, React manages the state and SVG overlays, and a custom Canvas renderer draws the actual data points. Used requestAnimationFrame to batch updates.",
      },
      {
        heading: "Testing & Debugging",
        content:
          "Encountered a bug where the Canvas resolution looked blurry on Retina displays. Banished it by scaling the canvas internal resolution by window.devicePixelRatio and scaling it back down with CSS.",
      },
      {
        heading: "Result",
        content:
          "Achieved a stable 60fps rendering 15,000 data points. The payload size decreased by 40%, and the time-to-interactive improved by 2.5 seconds.",
      },
      {
        heading: "Skills Demonstrated",
        content:
          "Performance Profiling, Canvas API, D3.js, React Optimization, Problem Solving.",
      },
    ],
  },
  {
    id: "accessible-alchemy",
    title: "RITUAL REPORT: ACCESSIBLE ALCHEMY UI",
    sigilId: "projects",
    sections: [
      {
        heading: "Problem",
        content:
          "The initial version of the Alchemy UI library looked magical but was completely unusable for keyboard navigators and screen reader users. The custom interactive elements lacked semantic meaning.",
      },
      {
        heading: "Goal",
        content:
          "Retrofit the entire component library to meet WCAG 2.1 AA standards without compromising the complex animations and visual flair.",
      },
      {
        heading: "Process",
        content:
          "Audited every component using VoiceOver and axe DevTools. Mapped out the missing ARIA attributes and focus management requirements.",
      },
      {
        heading: "Dev Decisions",
        content:
          "Integrated Radix UI primitives as the base layer for complex components like Modals and Dropdowns to handle the intricate accessibility logic (focus trapping, escape key handling), then layered the custom Framer Motion animations on top.",
      },
      {
        heading: "Result",
        content:
          "100% accessibility score in Lighthouse. The library is now fully navigable via keyboard, and screen readers correctly announce state changes.",
      },
    ],
  },
];
Not every case study needs to include all eight canonical sections. The Accessible Alchemy UI entry omits Design Decisions, Testing & Debugging, and Skills Demonstrated — the component renders whatever sections are present and nothing more.

Canonical Section Headings

The following headings appear across the existing case studies and establish the expected narrative arc for new entries:

Problem

What was broken, slow, or missing before the work began.

Goal

The measurable outcome the work aimed to achieve.

Process

How the problem was investigated and a strategy chosen.

Design Decisions

Visual and UX trade-offs made during the project.

Dev Decisions

Technical implementation choices and architectural rationale.

Testing & Debugging

Specific bugs encountered and how they were resolved.

Result

Concrete outcomes — performance numbers, audit scores, delivery metrics.

Skills Demonstrated

A comma-separated list of technologies and competencies exercised.

JSX Usage

import { RitualReport } from "@/components/case/RitualReport";
import { caseStudies } from "@/data/caseStudies";

export default function CaseStudiesPage() {
  return (
    <main>
      {caseStudies.map((study) => (
        <RitualReport key={study.id} caseStudy={study} />
      ))}
    </main>
  );
}

Adding a New Case Study

1

Open the data file

Edit data/caseStudies.js and append a new object to the array.
2

Set the header fields

Provide a unique id, a title that follows the "RITUAL REPORT: ..." naming convention, and a valid sigilId (e.g. "case-studies" or "projects").
3

Write the sections array

Add one object per narrative beat. Use the canonical headings above for consistency, but only include the sections that are relevant to the project.
4

Verify the render

RitualReport renders all sections automatically — no changes to the component are needed.

Build docs developers (and LLMs) love