[ BACK_TO_LIBRARY ]
Architecture

Building an Automated, Manifest-Driven Portfolio Sync Engine

2026.03.02
7 min

The Vision: Zero-Maintenance Showcase

The goal of debatreyadas.dev was to build a portfolio that required zero manual updates to keep my project list current. As a final-year student, I didn't want to spend time editing JSON files every time I shipped a new feature or started a new internship project.

The solution was to treat the portfolio not as a static display, but as a dynamic "operating system" that consumes manifests and raw content via the GitHub API.

Home Page

Learning 1: Manifest-Driven Architecture

The core engineering learning was defining a strict data contract between my portfolio and my external repositories. I created the .debatreya JSON schema to act as the metadata layer.

Code Block
// The strict data contract defined for all my repos
{
  "id": "portfolio-os",
  "name": "debatreyadas.dev",
  "tagline": "A Manifest-Driven Developer OS",
  "techStack": ["Next.js", "Quarto", "KaTeX"],
  "featured": true,
  "priority": 100,
  "hasDeepDive": true 
}

This allows the portfolio to perform Feature Discovery simply by crawling my GitHub account.

Learning 2: Decoupled Sync Logic (The "Handshake")

The second major learning was implementing a secure and efficient discovery engine. I had to ensure the portfolio only fetched my projects.

The finalized logic uses a specific GitHub Search API query: user:Debatreya topic:portfolio

Conceptual Diagram: The API Handshake (Discovery -> Extraction -> Aggregation)

The Technical Challenge: MDX vs. Quarto

Originally, I intended to use standard MDX for project deep-dives. However, my high-level technical notes (like those on parallel computing) require complex LaTeX\LaTeX formulas. When using next-mdx-remote, this caused compilation errors because the Acorn parser attempted to treat LaTeX curly braces {} as JavaScript JSX expressions.

I learned that Quarto (.qmd) is a superior choice for an integrated engineering garden. It handles mathematical formulas natively, allowing me to define sync efficiency with professional notation:

Efficiency = \frac{Total\_Repositories\_Crawled}{Manifest\_Hits}

Implementing the Renderer in Next.js

The final learning was building the renderer in lib/content.ts. We configured the pipeline to parse the Quarto YAML frontmatter and use rehype-katex to render the formulas safely.

Code Block
// Example of the sync utility with a defined code-filename
export const getQuartoFile = async (path: string) => {
  const rawResponse = await fetchGitHubRaw(path);
  const { data, content } = matter(rawResponse);
  
  const processedContent = await remark()
    .use(remarkMath)
    .use(rehypeKatex) // Solves the Acorn math parsing error
    .process(content);

  return { meta: data, content: processedContent.toString() };
}

Results

This architecture enables a fully decoupled, self-sustaining Developer OS. It proves that agentic development, when guided by clear architectural principles, can deliver a professional-grade portfolio with zero long-term maintenance overhead.

System Note: This record is part of the initial debatreyadas.dev-v1 manifest and is synced via the GitHub API Discovery engine.


🧬 Connectivity Logic

Once you push this file to your TIL repo, here is how the Antigravity-built UI will render:

FeatureData SourceResult in UI
Knowledge Graphrelated_projects: ["portfolio-os"]Links the sidebar to the portfolio-os project card.
System Notesystem_manifest: "debatreyadas.dev-v1"Shows the stylized "Synced" callout at the bottom.
Math Formulas$$Efficiency = ...$$Renders perfectly with LaTeX tokens in Emerald Green (#14F195).
Code Windowcode-filename: "src/lib/github-sync.ts"Displays the filename in the window header with the Copy button.
#nextjs#github-api#automation#software-design