Replichaun

How Replichaun Brainstorm Was Built

March 16, 2026

This brainstorm tool grew out of a problem I kept hitting while working on patent inventions. I track ideas across fields — bruxism biofeedback devices, carbon capture systems, aviation structures — in a tree-structured app. Each invention node carries prior art, constraints, and open questions. The missing piece was a way to brainstorm solutions directly inside the app, with Claude as a critic, without losing context between sessions.

Here's the conversation that shaped the tool.

The Problem: Context Loss

The invention tracker had a "Conversation Stack" feature — a giant textarea where you'd paste the full Claude Code transcript to preserve context across sessions. In theory, when you returned to a topic like bruxism biofeedback alert calibration, you'd paste the stack into your prompt and pick up where you left off.

In practice, nobody pastes transcripts into web forms.

Me
I don't understand the purpose of the "paste the conversation transcript here." The transcript if necessary gets pasted to the Claude Code session. It's saved on Inventing. I want to add user input so I can brainstorm my solutions there instead of here on Claude Code. Will there be lag / delays in transmitting my input to Claude? Can a new session be opened from there? Please review the replichaun.dev development work. It was a pretty good design but never solved the problem of aligning the session on Replichaun with the session on Claude Code.
Claude
What the conversation stack textarea actually is: useless as designed. You're not going to paste transcripts into a web form. The transcript is a reference artifact — if it's needed, Claude Code reads it from the database or file. I should remove that textarea and replace it with something useful.

What you actually want: input fields where you type your proposed solutions as part of the invention protocol. Problem is stated → you brainstorm a solution → you want critique → you iterate. The "you brainstorm a solution" step should happen in the app with proper structured fields.

The Alignment Problem

Replichaun had previously been a Claude Code session manager — a Node.js dashboard that tracked active terminal sessions. It worked for monitoring, but it never solved the core problem: how do you keep a web interface and a CLI session in sync?

Claude
The web-to-Claude-Code alignment problem is unsolved because:

• Claude Code sessions are local, stateless .jsonl files — read-only from outside
• No shared session identity between a web app and CLI
• Task queues are detached — you can queue work but can't bind it to a running session
• Finn MacCool (separate API chat) worked but was isolated from actual Claude Code work

After researching the landscape — read-only dashboards, web terminal wrappers like claude-code-web, multi-agent orchestration frameworks — one approach stood out.

Claude
Claude Code's headless mode is the real building block:

claude -p "critique this solution" --output-format json

session_id=$(claude -p "Start review" --output-format json | jq -r '.session_id')
claude -p "Continue" --resume "$session_id"

This means a Laravel web app can call Claude Code as a subprocess, capture the session ID, resume it later, and get structured output. No API costs — it uses your Claude Code plan.

The Split: Who Pays?

Claude built a working chat panel wired to the Claude API. It worked. Then I looked at the billing model:

Me
The Claude API should only be used for other people using the website. All my inventing activity should use Claude Code within my service plan.

This single constraint split one feature into two products. My own patent brainstorming — on topics like bruxism biofeedback threshold calibration, carbon capture economics at $600/ton, and aviation ring structures — should run through my Claude Code subscription. Zero marginal cost. The API is for serving other users.

Me
Add it as an alternative interface on replichaun.dev, behind OAuth.

The Storage Question

For the public tool, the question was where to keep user data. The options:

Claude
IndexedDB — Built into all modern browsers. Data persists across sessions transparently. User doesn't manage files — it just works. Risk: clearing browser data loses everything. Mitigated with export/import.

Download/Upload JSON — Most universal. User clicks "Save" and gets a .json file. To resume, they upload it. No server storage at all. This is how Excalidraw works — massively popular, zero server persistence. Bulletproof and cross-browser.

File System Access API — Chrome/Edge only. Lets a web app read/write actual files on the user's disk. Real "save to file" experience, but Safari/Firefox don't support it.

Hybrid — IndexedDB for auto-save (invisible), plus a "Download backup" button for export. Best of both worlds.

The hybrid approach won. IndexedDB handles auto-save transparently — you close the tab, come back, everything's there. The "Download Backup" button gives you a JSON file you can move between devices or archive. The server stores nothing about your brainstorms.

The Build

Me
Build 1 with headless mode. Build 2 as proposed.

Both products were built in a single session:

Product 1: Inventing Brainstorm (private, local) — Replaced the useless conversation stack textarea with a live chat panel. Calls claude -p --output-format json --model sonnet as a subprocess. The system prompt is built automatically from the node's hierarchy — field, category, problem — plus prior art, constraints, and open questions. Claude acts as an invention critic: challenges assumptions, identifies gaps, points out prior art conflicts. It never proposes the inventive step. Session IDs are stored for continuity via --resume.

Product 2: Replichaun Brainstorm (public, this site) — Converted from a static landing page to a Laravel app. The server is a thin proxy — holds the API key, enforces rate limits (30 Sonnet calls per day per IP, then automatic fallback to Haiku), returns the response. All user data lives in IndexedDB. Sessions, nodes, messages — everything stays on your device. Export as JSON anytime.

What I Learned

← Back to blog