Tommy D. Rossi remorses

Mintlify MDX Components — Complete Reference

Source: https://www.mintlify.com/docs/components/index

This document lists every MDX component Mintlify supports, with their props and descriptions. Use this as the roadmap for Holocron's MDX component implementation.

Implementation Status

Components already implemented in Holocron (vite/src/components/markdown/mintlify/compat.tsx and index.tsx) are marked with [IMPLEMENTED].

Hybrid ClickHouse + Iceberg Architecture

Overview

Three-tier query architecture with Iceberg on R2 as the source of truth, chDB in a Cloudflare Container as the always-available query engine, and an optional ClickHouse server on Fly.io for fast pre-aggregated dashboards.

┌──────────────────────────────────────────────────────────────────────┐
│  Your app / browser / backend                                        │
│  OTel SDK sends logs/spans/metrics                                   │

Single Server, Multiple Directories

How OpenCode uses one server process for all repositories instead of spawning a separate server per project.

The problem

If you spawn a new opencode serve per repository, you end up managing N server processes, N ports, N health checks — and the client needs to track which server maps to which project. This doesn't scale.

How OpenCode solves it

description

Start Ralph Wiggum loop in current session

argument-hint

PROMPT [--max-iterations N] [--completion-promise TEXT]

allowed-tools

Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)

hide-from-slash-command-tool

true

Ralph Loop Command

Execute the setup script to initialize the Ralph loop:

Multi-Bundler RSC Abstraction Plan

Abstract spiceflow's React Server Components implementation so it works with both Vite and Parcel (and potentially other bundlers in the future).

Current State: Where Vite is Coupled

The spiceflow RSC implementation has 3 layers of Vite coupling:

title: Platform Abstraction Plan — Discord + Slack description: | Plan for abstracting Discord-specific APIs into a platform-independent KimakiAdapter interface that supports both Discord and Slack. prompt: | Explored all 48 files with discord.js imports across discord/src/. Read the chat SDK source (opensrc/repos/github.com/vercel/chat/packages/chat) including types.ts, chat.ts, thread.ts, channel.ts, and index.ts. Compared chat SDK's Adapter interface with Kimaki's needs.

title: Event Listener Runtime Migration Plan description: >- Detailed migration blueprint for moving Kimaki Discord session handling to one long-lived OpenCode event listener per thread runtime with centralized Zustand state updates. Hardened with feasibility review, concrete code snippets, file-by-file refactor map, and staged acceptance criteria. prompt: | [38m since last message | UTC: 2026-03-01 15:39:12 UTC | Local

	#!/usr/bin/env python3
	"""
	token_dream.mp4 - A YouTube Poop about being an LLM
	Generated entirely with Pillow + stdlib. No numpy.
	"""

	import os
	import math
	import random
	import struct

	profano/0.0.1


	Usage:
	$ profano <files...>


	Commands:
	<files...> Analyze .cpuprofile files and print top functions by self-time

	Duration: 15.65s
	Samples: 1231 active / 10157 total (87.9% idle)

	Samples %Active Function Location
	─────── ─────── ────────────────────────────────────────── ────────────────────────────────
	133 10.8% readFileUtf8 (native)
	79 6.4% prepare nm/libsql/index.js:125
	74 6.0% internalModuleStat (native)
	55 4.5% read (native)
	49 4.0% compileSourceTextModule esm/utils:343