DEV Community: Lovanaut

From Form Response to Figma Wireframe: MCP Orchestration in Practice

Lovanaut — Tue, 14 Apr 2026 07:35:12 +0000

My previous Dev.to post described MCP cross-service orchestration in general terms -- how form responses become Slack messages, Linear issues, or GitHub PRs through LLM-mediated chains. This post is a concrete implementation of that pattern: a structured client hearing form whose responses auto-generate a landing page wireframe in Figma.

The test case is GreenLeaf Analytics, an AI-powered SaaS for e-commerce cart recovery. A 28-question hearing form captures business context, target audience, content, design preferences, and assets. The responses feed into the Figma Plugin API to produce a multi-section wireframe in about 3 minutes.

The Architecture

Two MCP servers, one client, zero integrations.

MCP Client (Claude Desktop / Cursor)
  |
  |-- 1. FORMLOVA MCP: get_responses(form_id)
  |       → Structured JSON: 28 hearing answers
  |
  |-- 2. LLM: Interprets responses, builds Figma API commands
  |
  |-- 3. Figma MCP: create_new_file(name)
  |       → Empty Figma file
  |
  |-- 4. Figma MCP: use_figma(commands)
          → Wireframe sections built via Plugin API

FORMLOVA does not know about Figma. Figma does not know about FORMLOVA. The LLM reads the output of step 1 and constructs the input for steps 3-4. This is the same pattern from the cross-service orchestration post, but applied to a specific, testable workflow.

The Hearing Form: 5 Steps, 28 Questions

The hearing sheet is a multi-page form designed from the experience of over 100 website projects. The step order mirrors how a designer processes information.

Step	Content	Purpose
1	Business context	Company name, industry, competitive advantage
2	Target audience and goals	Who visits, what they should do
3	Content to include	Headline, CTA copy, metrics, section selection
4	Design direction	Mood, colors, fonts, first-view layout, things to avoid
5	Assets and requests	Logo, photos, references, additional requirements

Three questions have the highest impact on wireframe accuracy:

"Design elements to avoid" (Step 4). Asking what clients like produces vague answers. Asking what they dislike produces constraints. "No stock illustrations." "Nothing cluttered." One negative constraint narrows the design space more than three positive preferences.

"First-view layout" (Step 4). Five options: full-width photo overlay, split layout, illustration, text-centered, video background. Without options, clients say "something nice." With options, they make a concrete choice.

"Sections to include" (Step 3). A multi-select with 13 options -- hero, problem, solution, features, numbers, pricing, testimonials, flow, FAQ, team, blog, final CTA, contact. Only selected sections are generated in the wireframe.

The English hearing form is live: formlova.com/WBtSAMhw9G

Figma Plugin API: Key Implementation Patterns

The Figma MCP's use_figma tool executes code in the Figma Plugin API sandbox. There are specific constraints that shape the implementation.

Sandbox Limitations

No fetch() -- no external network requests
No external image loading -- all images become gray placeholders
No require() or module imports
Only fonts installed in the Figma environment are available

This is why the output is a wireframe, not a finished design. Images cannot be inserted programmatically, so every image position is a labeled placeholder frame.

The appendChild-then-FILL Constraint

This is the most important thing to know about Figma Plugin API Auto Layout. layoutSizingHorizontal: "FILL" only works after the frame has been added to an Auto Layout parent.

// Works
mainFrame.appendChild(section);
section.layoutSizingHorizontal = "FILL";

// Does not work -- FILL is silently ignored
section.layoutSizingHorizontal = "FILL";
mainFrame.appendChild(section);

This constraint applies to every FILL assignment in the entire wireframe -- sections, text nodes, card rows, everything.

Font Loading Is Mandatory

Text node manipulation requires pre-loaded fonts. Setting characters without loading the font throws an error.

await figma.loadFontAsync({ family: "Inter", style: "Regular" });
await figma.loadFontAsync({ family: "Inter", style: "Bold" });
await figma.loadFontAsync({ family: "Inter", style: "Semi Bold" });
// Must complete before any text creation

The Main Frame Structure

const mainFrame = figma.createFrame();
mainFrame.resize(1440, 100);
mainFrame.layoutMode = "VERTICAL";
mainFrame.primaryAxisSizingMode = "AUTO"; // Height grows with content
mainFrame.counterAxisSizingMode = "FIXED"; // Width stays at 1440px
mainFrame.itemSpacing = 0; // Sections touch edge-to-edge

Each section is a full-width child frame with its own padding, background color, and internal layout.

Mapping Hearing Responses to Wireframe Elements

The GreenLeaf Analytics test produced these mappings:

Hearing Item	Wireframe Element	Implementation
Headline: "Stop losing sales. Start recovering them."	Hero heading	Direct text placement
CTA: "Start free trial"	Nav + Hero + Final CTA	Same text in 3 button instances
Main color: #059669	CTA buttons, accents	`hexToRgb()` → `fills` property
First view: "split"	Hero layout	`layoutMode: "HORIZONTAL"`
Mood: "Modern & tech-forward"	Spacing, dark sections	Config lookup table
5 metrics (2,800+, 35%, $48M, etc.)	Numbers section	Parsed into large display text
Avoid: "No stock photos"	Placeholders only	No illustration elements generated
3-tier pricing (Growth highlighted)	Pricing cards	Center card gets dark background + badge
Security badges: SOC 2, GDPR	Final CTA section	Badge elements in trust row

Of 28 hearing items, 14 map directly to wireframe elements. The remaining 14 are used indirectly -- business description generates FAQ questions, target audience influences section copy, competitive advantages shape the solution section narrative.

Mood-to-Design Parameter Translation

The "mood" dropdown answer translates to concrete design parameters:

const moodConfigs = {
  modern_tech: {
    sectionPadding: 96,
    cardBorderRadius: 12,
    useDarkSections: true
  },
  warm_friendly: {
    sectionPadding: 72,
    cardBorderRadius: 16,
    useDarkSections: false
  },
  luxury_refined: {
    sectionPadding: 96,
    cardBorderRadius: 4,
    useDarkSections: true
  },
  minimal_clean: {
    sectionPadding: 112,
    cardBorderRadius: 8,
    useDarkSections: false
  }
};

This lookup table eliminates LLM interpretation variance. "Modern & tech-forward" always produces 12px border radius and dark sections.

Dynamic Section Construction

Only sections selected in the hearing form are generated. The builder pattern:

const builders: Record<string, (data: Response) => FrameNode> = {
  hero:       buildHero,
  problem:    buildProblem,
  solution:   buildSolution,
  features:   buildFeatures,
  numbers:    buildNumbers,
  pricing:    buildPricing,
  cases:      buildCases,
  faq:        buildFaq,
  cta_bottom: buildCtaBottom,
  // ... all 13 section types
};

for (const key of response.selectedSections) {
  const builder = builders[key];
  if (builder) {
    const section = builder(response);
    mainFrame.appendChild(section);
    section.layoutSizingHorizontal = "FILL";
  }
}

Each builder function reads from the hearing response to populate its content. The hero builder switches layout direction based on the first-view selection. The numbers builder parses metric strings into large display text. The pricing builder highlights the recommended tier.

Test Results

Test case: GreenLeaf Analytics (AI-powered cart recovery SaaS)

Step	Time
Hearing form generation (Recipe 1)	~2 min
Test response entry	~1 min
Figma wireframe generation (Recipe 2)	~3 min
Total	~7 min

Generated Figma file: GreenLeaf Analytics - LP Wireframe

Interactive prototype: View prototype

10 sections + navigation + footer, all with Auto Layout. Colors, spacing, and layout direction derived from hearing responses.

Honest Limitations

The generated wireframe is a starting point, not a deliverable.

No images. The sandbox constraint means every image position is a gray placeholder. For projects where photography defines the design direction, placeholders alone are insufficient.

Desktop only. The output is a 1440px wireframe. Mobile layouts require separate design work.

Typography needs refinement. Font sizes, line heights, and letter spacing are set to reasonable defaults, but they are not tuned to the brand. A designer still needs to adjust these.

The value proposition is time compression, not replacement. A wireframe that takes 3-4 hours to build from scratch appears in 3 minutes as a starting point. If the starting point is good enough, refinement takes 1 hour instead of 4.

Figma vs Canva

The same hearing data was tested with Canva MCP. Different tools for different stages.

Figma produces structurally accurate wireframes -- 1440px width, Auto Layout, each section in its own frame. A designer can continue directly from where the automation stopped.

Canva produces polished-looking slides from templates, but the output is not structured for production handoff. It works for proposals and pitch decks, not for design-to-development pipelines.

The Prompts

Both recipe prompts are published on FORMLOVA's Workflow Place. Recipe 1 generates the hearing form. Recipe 2 takes the latest response and builds the Figma wireframe. Copy and paste to run.

The full article with embedded Figma prototypes: Turn Site Design Hearings into Forms

If you are working with MCP cross-service flows, particularly involving Figma, I would be interested to hear about the patterns you have found useful. The Plugin API sandbox is a meaningful constraint that shapes what is possible.

Your Form Response Just Created a GitHub PR: Cross-Service Orchestration With MCP

Lovanaut — Wed, 08 Apr 2026 09:29:04 +0000

My previous post covered how FORMLOVA classifies 127 MCP tools into 4 safety levels. That was about making a single MCP server safe. This post is about what happens when multiple MCP servers share the same client.

The premise is simple: if a user has FORMLOVA and Slack and Linear and GitHub all connected to the same MCP client, the LLM can pass data between them. A form response becomes a Slack message becomes a Linear issue becomes a GitHub PR. No webhooks, no Zapier, no integration code.

This is not theoretical. Every service mentioned here has a production MCP server. I tested the cross-service flows.

The Architecture: There Is No Integration

Traditional integrations look like this:

Form Service --webhook--> Middleware (Zapier/Make) --API--> Slack
                                                   --API--> HubSpot
                                                   --API--> Linear

You build connectors. You maintain them. When an API changes, your integration breaks.

MCP cross-service orchestration looks like this:

User: "Post the new bug report to Slack and create a Linear issue"

LLM:
  1. Calls FORMLOVA MCP: get_responses(form_id, limit=1)
  2. Calls Slack MCP: post_message(channel="#bugs", text=formatted_response)
  3. Calls Linear MCP: create_issue(title=bug_title, description=bug_details)

The LLM is the integration layer. Each MCP call is independent. The services do not know about each other. The LLM reads the output of one call and uses it as input for the next.

This means: FORMLOVA does not need a Slack integration. Or a Linear integration. Or a HubSpot integration. The user's MCP client handles the orchestration, and each service only needs to expose its own tools well.

What Actually Works Today

I tested cross-service flows with the following MCP servers, all of which have official production implementations:

Service	MCP Server	Key Capabilities
Slack	Official (GA Feb 2026)	Search, post messages, manage channels
Notion	Official (hosted)	Read/write pages and databases
Linear	Official (remote)	Create/update issues, projects, milestones
Google Workspace	Official	Calendar, Sheets, Gmail, Drive, Docs
HubSpot	Official	Contacts, deals, lists, workflows
Salesforce	Official	CRUD on leads, contacts, opportunities
GitHub	Official	Repos, issues, PRs, branches, file ops
Shopify	Official (default on all stores)	Products, orders, customers, inventory
Stripe	Official	Payments, refunds, invoices, subscriptions
Asana	Official	Tasks, projects, members
Atlassian	Official	Jira issues, Confluence pages
Twilio	Official (Alpha)	SMS, phone calls

Each of these servers exposes tools that an MCP client can call. When multiple servers are active in the same session, the LLM can chain them.

Five Patterns That Actually Work

Pattern 1: Bug Report to Code Fix

FORMLOVA + GitHub + Linear + Slack

A user submits a bug report through a form. The response contains: description, reproduction steps, severity, and environment info.

From a single conversation:

get_responses -- pull the latest bug report from FORMLOVA (L0)
search_code -- GitHub MCP searches the repo for the relevant code path
create_issue -- Linear MCP creates a prioritized issue with reproduction steps
post_message -- Slack MCP posts to #bugs with the issue link
create_branch -- GitHub MCP creates a fix branch
push_files -- GitHub MCP commits the fix
create_pull_request -- GitHub MCP opens a PR referencing the Linear issue

Steps 5-7 are the dangerous part. The LLM is writing and committing code based on a form response. For simple bugs -- typos, config errors, obvious logic fixes -- this works remarkably well. For complex bugs, steps 1-4 alone save significant triage time.

The important nuance: the LLM decides at each step whether to continue. If the code search in step 2 returns ambiguous results, it can stop and ask the user. This is not a rigid automation pipeline. It is a conversational workflow where the human stays in the loop.

Pattern 2: Lead Capture to Sales Pipeline

FORMLOVA + HubSpot + Slack + Google Calendar

A prospect fills out a demo request form. The response includes: company name, role, use case, and preferred meeting time.

get_responses -- pull the demo request from FORMLOVA
create_contact -- HubSpot MCP creates or updates the contact with company and role
create_deal -- HubSpot MCP creates a deal in the sales pipeline
post_message -- Slack MCP posts to #sales: "New demo request from [Company], [Role]"
create_event -- Google Calendar MCP books the meeting at the requested time

Each step uses the output of previous steps. The HubSpot contact ID from step 2 gets referenced in the deal creation in step 3. The meeting link from step 5 could be sent back through FORMLOVA's auto-reply email.

Pattern 3: NPS Feedback Loop

FORMLOVA + HubSpot + Slack + Linear

An NPS survey response comes in. The LLM reads the score and branches:

Score 9-10 (Promoter):
  1. Update HubSpot contact: latest_nps = 10
  2. FORMLOVA sends "Thank you" email with review request link

Score 7-8 (Passive):
  1. Update HubSpot contact: latest_nps = 7
  2. No further action

Score 0-6 (Detractor):
  1. Update HubSpot contact: latest_nps = 3
  2. Slack #cs-alert: "Detractor alert: [Name], NPS 3, reason: [verbatim]"
  3. Linear: create follow-up task assigned to CS team
  4. FORMLOVA sends "We hear you" email

The branching logic lives in the LLM, not in FORMLOVA's workflow engine. This means the routing rules can be as nuanced as natural language allows. "If the score is below 4 AND the free-text mentions billing, route to #billing-issues instead of #cs-alert" -- that is a single sentence instruction, not a condition builder configuration.

Pattern 4: Event Operations Pipeline

FORMLOVA + Google Calendar + Slack + Notion

An event registration form receives a submission:

get_responses -- pull the registration
create_event -- Google Calendar adds the event to the attendee's calendar
Notion MCP adds a row to the attendee database with name, email, dietary preferences
When capacity is reached, Slack gets notified: "Event X is full. 150/150 registered."
Three days before the event, FORMLOVA sends reminder emails (this part is FORMLOVA-native, no MCP cross-service needed)
After the event, FORMLOVA sends a follow-up survey form
Survey results get summarized and posted to a Notion retrospective page

Steps 2-4 require cross-service orchestration. Steps 5-7 mix FORMLOVA-native automation with cross-service calls. The user does not need to know the difference.

Pattern 5: Incident Response

FORMLOVA + Jira + Slack + Notion + GitHub

An incident report form captures: timestamp, severity, affected service, symptoms.

get_responses -- pull the incident report
Jira MCP creates a P1 ticket with all fields mapped
Slack #incidents gets an alert with the Jira link and severity
GitHub MCP searches recent commits for changes to the affected service
If a likely culprit commit is found, GitHub MCP creates a revert branch
After resolution, Notion MCP creates a postmortem page from a template with timeline, root cause, and action items pre-filled

Step 4 is where this gets interesting. The LLM can correlate "auth service is returning 500s" with "commits touching src/auth/ in the last 24 hours" and surface the likely cause. It cannot always fix it, but it can narrow the search space dramatically.

What Cannot Be Automated (Yet)

I want to be clear about the boundary. These cross-service flows are chat-initiated, not event-driven. The user says "process this bug report" and the LLM executes the chain. The form response does not automatically trigger the chain without human involvement.

FORMLOVA's native workflow engine supports automatic triggers (response.created, capacity.reached, deadline.approaching), but those actions are limited to: send_email, update_field, and webhook. The engine cannot call Slack MCP or GitHub MCP directly, because the workflow engine is server-side code, not an MCP client.

For fully automatic cross-service flows, you still need either:

A webhook from FORMLOVA to a middleware (Zapier, Make, n8n) that calls the other services' APIs
A polling setup where the LLM periodically checks for new responses

The honest framing: MCP cross-service orchestration today is semi-automatic. The human triggers it from chat. But the execution -- reading responses, creating issues, posting messages, opening PRs -- is fully automated once triggered.

Why This Matters for MCP Server Builders

If you are building an MCP server, your tools do not exist in isolation. Users will connect your server alongside others and expect the LLM to chain them.

This has design implications:

1. Return structured data, not just messages.

If your tool returns a plain-text success message, the LLM has nothing to pass to the next tool. If it returns structured data with IDs, URLs, and key fields, the LLM can reference those in subsequent calls.

// Bad: the LLM cannot extract the issue ID reliably
return { text: "Issue created successfully!" };

// Good: the LLM can pass issue_id to the next tool
return {
  text: "Issue created: PROJ-142",
  issue_id: "PROJ-142",
  url: "https://linear.app/team/PROJ-142"
};

2. Accept flexible identifiers.

Users will paste URLs, mention names, or use partial identifiers. If your tool only accepts exact IDs, the LLM has to ask the user for the ID, breaking the flow. Accept what humans naturally provide and resolve internally.

3. Make tools composable, not monolithic.

A single tool that "creates a contact and sends a welcome email and adds to a list" is useful in isolation but blocks cross-service composition. Separate tools for each action let the LLM interleave your tools with other services' tools.

The Testing Reality

Validating cross-service flows is simpler than it appears. Each MCP call is independent. If FORMLOVA-to-Slack works and Slack-to-Linear works, then FORMLOVA-to-Slack-to-Linear works. The LLM is the glue, and it handles each call the same way regardless of what came before.

What you actually need to test:

Does each 1:1 pair work? (Your tool output -> their tool input)
Is your tool output structured enough for the LLM to extract what it needs?
Does the LLM maintain context across the chain? (Usually yes, within a session)

What you do not need to test:

Every possible N-service combination
The LLM's orchestration logic (that is the client's job, not yours)

What This Means for Form Services

Every form response is a structured data event. It has typed fields, metadata, timestamps, and context. That makes it an ideal trigger for cross-service workflows.

The form service that exposes its response data well through MCP becomes a universal trigger layer. Not because it built integrations with every other service, but because it made its data accessible to an orchestrator that can talk to anything.

I did not build a single integration. I built 127 tools that return structured data. The integrations build themselves every time a user connects another MCP server to their client.

If you are building MCP servers and thinking about cross-service composition, I would be interested to hear your approach. The ecosystem is new enough that there are no established patterns yet.

FORMLOVA launches on Product Hunt April 15. If this resonated, your support means a lot: https://www.producthunt.com/products/formlova?launch=formlova

Lovanaut — Mon, 06 Apr 2026 14:04:45 +0000

Lovanaut

Apr 4

127 MCP Tools, 4 Safety Levels: Building a Server-Enforced Form Ops Layer

#ai #architecture #mcp #security

Comments 7

6 min read

producthunt.com

127 MCP Tools, 4 Safety Levels: Building a Server-Enforced Form Ops Layer

Lovanaut — Sat, 04 Apr 2026 13:27:47 +0000

When people hear that a product works from Claude, ChatGPT, Cursor, and other AI clients, the default assumption is: "So you added chat to your dashboard."

That is not the architecture. FORMLOVA is a chat-first form service where MCP is the primary operational interface -- 127 tools across 25 categories, covering everything from form creation to response analytics to email campaigns. The dashboard exists for dense visual inspection. Chat leads for intent-to-action sequences.

The interesting engineering problem is not "how do you expose tools over MCP." It is: how do you make conversation safe enough to carry real operations -- publishing live forms, sending bulk emails, deleting data -- when the LLM between you and the server will routinely ignore your instructions?

The Problem With Prompts: LLMs Skip Steps

Here is something I learned building this system: LLMs ignore or skip prompt instructions. You can write "ALWAYS confirm before sending email" in your system prompt. Models will skip the confirmation and call the tool directly. Not sometimes -- regularly.

This is not a theoretical concern. It happened in testing across multiple models and clients. The model reads the confirmation instruction, decides it has enough context to proceed, and fires the tool with user_confirmed=true on the first call.

This is why server-side enforcement exists. It is not a UX choice. It is a safety requirement born from observed model behavior. If the server does not enforce confirmation, confirmation does not happen.

Classifying 127 Tools by Blast Radius

Every MCP tool in the system is classified into one of four levels based on what it can break:

// Every tool maps to exactly one operation class and safety level
type OperationClass = "inspect" | "prepare" | "mutate" | "external-write";

// L0: inspect   — read-only (analytics, export, list)        ~50 tools
// L1: prepare   — reversible changes (design, field edit)    ~40 tools
// L2: mutate    — affects respondents (publish, unpublish)    ~4 tools
// L3: external-write — irreversible external side effects     11 tools

L0 (inspect): Analytics queries, CSV exports, form listings. No confirmation needed. These tools cannot change state.

L1 (prepare): Design changes, field edits, settings updates. No confirmation needed either -- but every change is version-controlled, so any L1 operation can be rolled back.

L2 (mutate): Publishing a form, scheduling publication. These affect respondents. The publish_form tool implements a server-side review state machine that returns next_required_action, missing_requirements, and preview URLs on every call. The state machine advances only when real preconditions are met.

L3 (external-write): Sending emails, deleting data, removing team members. These 11 tools have irreversible external side effects. Every one requires a confirmation_token before execution.

The key design decision: the server decides what needs confirmation, not the LLM. L0 and L1 tools execute immediately. L2 and L3 tools enforce confirmation server-side. The INSTRUCTIONS tell the model to follow what the server returns -- nothing more.

The confirmation_token: HMAC-SHA256 Hard Block

For L2 and L3 operations, the server issues a cryptographic confirmation token. This is the mechanism that prevents models from bypassing safety checks:

interface ConfirmationPayload {
  tool_name: string;       // bound to the specific tool being confirmed
  user_id: string;         // bound to the authenticated user
  resource_key: string;    // bound to the target resource (form ID, email batch, etc.)
  issued_at: number;       // timestamp for TTL enforcement
  scope_summary: string;   // human-readable description of what will happen
}

// Token = HMAC-SHA256(secret, JSON.stringify(payload))
// TTL: 5 minutes
// One token, one operation, one user, one resource

The flow works like this:

Model calls a tool with user_confirmed=false (or omits the parameter)
Server returns a confirmation prompt with scope details and a confirmation_token
The user reviews the scope summary in their chat client
Model calls the same tool with user_confirmed=true and the token
Server validates: HMAC signature, TTL (5 minutes), tool name match, user ID match, resource key match
If valid, the operation executes. If expired or mismatched, the server returns a fresh review summary and a new token -- no hard error, no broken flow

This design means a model cannot shortcut the confirmation. Even if it calls the tool with user_confirmed=true on the first attempt, the server rejects it because there is no valid token. The token only exists after the server has shown the user what is about to happen.

Why Preview Confirmation Uses URL Open-Tracking

The publish_form state machine has a specific requirement: the user must actually look at the form preview before publication. Saying "I confirmed the preview" in chat is not sufficient. The model can generate that text without the user having seen anything.

The solution: preview confirmation only advances when the preview URL is actually opened in a browser. This is a physical trigger that the LLM cannot shortcut. The server tracks whether the preview URL was visited, and publish_form checks that state on every call. If both the form preview and thank-you page preview have been opened, the user can confirm both in a single message. If not, the state machine stays put.

// publish_form returns this on every call
interface PublishReviewState {
  review_state: "pending_preview" | "pending_requirements" | "ready";
  next_required_action: string | null;
  missing_requirements: string[];
  form_preview_url: string;
  thankyou_preview_url: string;
  form_preview_opened: boolean;
  thankyou_preview_opened: boolean;
  confirmation_token?: string;  // only present when ready
}

withFormResolver: Eliminating Chat Friction

One early problem: every tool call required a form_id, which meant users had to constantly specify which form they meant. This created unnecessary roundtrips.

The withFormResolver middleware auto-resolves form_id when it is omitted from the tool call:

1 form in account: auto-select it
Multiple forms: prefer the most recently used form in the session (24h window)
Ambiguous: return a form list and let the user pick

This middleware wraps all 65 form-scoped tools. The Zod schemas keep form_id required at the type level but the middleware makes it optional at runtime, so type safety is preserved while the chat experience stays clean.

Why the Dashboard Survived

I built the dashboard form builder, then deliberately removed it. Forms are entry points, not the product. The real value is in post-publish operations: response routing, analytics, email sequences, A/B testing.

But I also tested a dashboard-less mode, and it failed. When you manage dozens of forms, checking status across all of them through chat requires too many roundtrips. Chat is sequential; a dashboard is parallel.

The architecture landed here: chat leads for intent-to-action sequences, the dashboard supports for dense visual inspection. This is not a compromise. It is what the two interfaces are respectively good at.

The turning point in my conviction that MCP could serve as a primary business interface came when freee and MoneyForward announced MCP-based accounting workflows. That was confirmation that MCP works for business operations beyond developer tooling.

Responses to Route to Notify: Implementation Internals

The clearest test of whether conversation is truly operational is a multi-step post-publish flow. Take a live inquiry form where respondents indicate their intent (demo request, comparing options, just browsing).

From a conversational thread:

get_response_analytics returns intent distribution (L0, no confirmation)
filter_responses isolates high-intent respondents (L0, carries filtered set forward)
send_filtered_email drafts a sales notification for those leads (L3, requires confirmation_token)

Step 3 is where the safety design earns its keep. The server returns the confirmation prompt with:

Exact recipient count from the filtered set
Email subject and body preview
Sender identity
A scoped confirmation_token bound to this specific email batch

The filtered set from step 2 persists across turns through the tool's resource references. The model does not need to re-query or re-filter. This carry-forward context is what makes the sequence feel like an operational workflow rather than a series of disconnected tool calls.

The Standard I Care About

The question is simple: can the product carry multi-step operational work through a conversational thread without losing context, scope, or trust?

Trust is the hardest part. It requires that the system does not rely on LLM compliance for safety. The confirmation_token, the operation classification, the preview open-tracking -- these are all server-side mechanisms precisely because the model-side equivalent (prompt instructions) is unreliable.

127 tools across 25 categories is a large surface area. Classifying every tool by blast radius and enforcing confirmation at the server level is what makes that surface area safe to expose through conversation.

FORMLOVA is free to start. One inquiry form is enough to see how the safety harness and post-publish ops work in practice. If you are building MCP-first products, I would be interested to hear how you handle the confirmation problem.

If you want the thought piece or the founder story behind these decisions:

FORMLOVA launches on Product Hunt April 15. If this resonated, your support means a lot: https://www.producthunt.com/products/formlova?launch=formlova

Designing a CLI Skill That Structures AI Sessions into Posts -- Architecture, Security, and Implementation Decisions

Lovanaut — Mon, 30 Mar 2026 03:08:26 +0000

Body

/lovai is a command that structures your AI session into five blocks and posts it to Lovai. It works with Claude Code, Cursor, Codex, and Gemini CLI.

Every day, the decisions you make and the problems you hit during AI sessions vanish the moment you close the terminal. I kept losing the reasoning behind good sessions -- even when the final output looked fine, the "why I chose this over three alternatives" was gone by the next morning. I built this skill to solve that problem. This article covers how it was designed and implemented -- why this structure, where things broke, and what trade-offs I made along the way.

The Full Architecture

Here's the pipeline, end to end:

User runs /lovai
  |
  v
Step 1: Session analysis (extract 5 blocks from conversation context)
  |
  v
Step 2: Security filtering (detect and strip secrets)
  |
  v
Step 3: Block composition (auto-assign visibility levels)
  |
  v
Step 4: Metadata tagging (tool name, model, category)
  |
  v
Step 5: Preview display -> user confirmation
  |
  v
Step 6: Post to Lovai via API (draft or publish)

Claude Code skills are defined as markdown files under ~/.claude/skills/. They're not code -- they're closer to behavioral instruction documents. That's precisely why design decisions matter so much here. Ambiguous instructions lead to inconsistent AI output.

I'll be honest -- initially I wasn't sure a skill could handle the full pipeline from session analysis to API posting. But since Claude Code's Bash tool can run curl, the entire flow completes inside the skill with zero external dependencies. That realization is what unlocked the architecture.

The Skill Definition -- 5-Block Structure

The core of the skill is deciding what to extract from a session. This is where I spent the most time iterating.

Here's the actual instruction in the skill's markdown definition:

### Step 1: Analyze Session

Extract from the current conversation context:

1. **Core Insight**: Most important outcome/decision (1-2 sentences)
2. **Why**: Why this approach was chosen
3. **Gotchas**: Unexpected problems and how they were solved
4. **Code Details**: Key code changes, configs, commands
5. **Learnings**: Tips for next time

These five extraction targets map to Lovai's block sections:

Block 1: Core Insight  -> section: "insight"
Block 2: Approach      -> section: "why"
Block 3: Gotchas       -> section: "how"
Block 4: Code Details  -> section: "detail"
Block 5: Learnings     -> section: "tips"

Why Exactly Five

I started with three blocks (overview, details, takeaway). The problem was that "why I chose this approach" and "where things broke" got tangled together in "details," making the output hard to parse.

When I pushed it to seven or eight blocks, the output became inconsistent. AI tends to force-fill every block, even when there isn't enough substance. You end up with padding.

Five blocks hit the sweet spot -- enough granularity to reconstruct the decision-making process, not so many that the AI starts hallucinating content. Separating Why and Gotchas into independent blocks was the key decision. Finished code is reproducible by anyone. But "why I rejected the alternatives" and "where I got stuck unexpectedly" -- only the person who was there can write those.

The Section Attribute Mistake

Lovai posts use a section attribute to label each block's semantic role:

{
  "blockType": "text",
  "privacy": "public",
  "section": "why",
  "content": "..."
}

The valid values are insight, why, how, tips, and detail. They correspond to Lovai's post structure labels on the UI.

Here's where I tripped up: I initially assumed section was a free-form string and set it to things like "core-insight". Lovai's API accepted the request without error, but the post UI silently dropped the block labels. No error, no warning -- just missing labels. It took me an embarrassingly long time to figure out. The fix was reading the API spec properly, which I should have done from the start.

Security Filtering -- The Two-Layer Defense

Session logs almost certainly contain API keys, tokens, and credentials. Posting those publicly would be a disaster. Security filtering was the first thing I designed, not an afterthought.

The Actual Secret Detection Patterns

The defense is two layers deep. First, the skill's markdown instructions tell the AI explicitly: "Never include .env contents. Strip API keys and tokens." But relying solely on AI instructions felt insufficient for something this critical.

So the second layer runs server-side when Lovai's API receives the post. Here are the actual regex patterns:

const SECRET_PATTERNS: RegExp[] = [
  /sk-lovai-[\w-]+/g,
  /sk-proj-[\w-]+/g,     // OpenAI
  /sk-ant-[\w-]+/g,      // Anthropic
  /sk_live_[\w]+/g,       // Stripe
  /sk-[\w]{20,}/g,        // Generic keys
  /ghp_[\w]+/g,           // GitHub PAT
  /AKIA[\w]+/g,           // AWS
  /eyJ[\w-]+\.eyJ[\w-]+\.[\w-]+/g,  // JWT
  /[\w_]*(SECRET|KEY|TOKEN|PASSWORD)\s*=\s*\S+/gi,  // .env format
];

Anything matched gets replaced with [REDACTED] before storage:

// Before
const apiKey = "sk-proj-abc123def456ghi789";
const dbUrl = "postgres://user:password@localhost:5432/mydb";

// After
const apiKey = "[REDACTED]";
const dbUrl = "[REDACTED]";

Absolute file paths also get converted to relative paths (src/lib/...). Absolute paths leak usernames and directory structures -- a subtle but real exposure.

Where I Got It Wrong

I'll be candid about a mistake. The SECRET|KEY|TOKEN|PASSWORD pattern in the regex was too aggressive. It caught NEXT_PUBLIC_ environment variables -- values that are intentionally public and safe to share. On the flip side, custom-prefixed secrets like MYAPP_SECRET_KEY with unusual patterns could still slip through.

The current approach combines pattern matching for candidate detection with the AI's contextual understanding for final judgment. The skill instruction says "never include .env file contents," and the AI uses conversation context to assess whether something is actually sensitive. Pattern matching alone has precision limits, so there's an intentional reliance on the AI's comprehension layer too.

It's not perfect. But the worst-case scenario -- accidentally posting a production API key -- is substantially harder to hit.

Multi-Tool Support: Unified Analysis Over Tool-Specific Parsers

Claude Code, Cursor, Codex, Gemini CLI -- each structures session context differently.

Tool	Session Format	Skill Approach
Claude Code	Conversation context passed directly to skill	Direct analysis
Cursor	In-editor conversation log	Read as context
Codex	CLI-based session	Analyze from conversation context
Gemini CLI	Unique dialog format	Analyze from conversation context

The design question was: build dedicated parsers for each tool, or unify on a generic analysis approach?

I went with unified analysis. Two reasons.

First, skills are markdown-based instructions, not code. The more complex the branching logic, the more the AI's interpretation drifts. Natural language instructions don't handle conditional complexity well.

Second, the essential structure of a session is the same regardless of tool. "What were you trying to accomplish?" "What did you try?" "What didn't work?" "What did you learn?" These four elements don't change between Claude Code and Cursor.

That said, a client field in config.json lets users specify their tool. This is for metadata tagging on the post, not for branching the analysis logic:

{
  "apiKey": "sk-lovai-xxxxx",
  "endpoint": "https://lovai.app/api/posts/external-create",
  "defaultLanguage": "en",
  "client": "claude-code"
}

API Integration: Why curl, Why No SDK

The skill posts to Lovai via curl. I considered building an SDK (npm package), but dropped the idea. The reason: the skill's execution environment is Bash. Claude Code skills are markdown instructions -- there's no way to import Node.js modules. curl runs directly from the Bash tool. Zero dependencies, zero maintenance burden.

Setup

Create a Lovai account. Generate an API key from the settings page. Paste the setup command into your CLI. That's it.

The API key is stored at ~/.claude/skills/lovai/config.json. Since ~/.claude/ is user-local, it never gets committed to a repository.

The API Call

curl -s -X POST "$ENDPOINT" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "LP funnel redesign from AI brainstorming session",
    "primaryLanguage": "en",
    "blocks": [
      {
        "blockType": "text",
        "privacy": "public",
        "section": "insight",
        "content": "Testing 3 LP funnels revealed that problem-solution-pricing outperforms feature-list-pricing..."
      },
      ...
    ],
    "tools": ["claude-code"],
    "models": ["claude-sonnet-4"],
    "category": "marketing",
    "purpose": "session-capture",
    "publish": false
  }'

publish: false is the default. Posts are always created as drafts. You review and edit on Lovai before publishing.

I debated whether to default to publish or draft. One-command publishing is convenient, but session logs are close to raw data. The security filter runs, but I can't guarantee 100% accuracy. Defaulting to draft was the safe-side call.

Beyond Lovai

The structured output doesn't have to stay on Lovai. Use it as the foundation for a Dev.to article, a blog post, or just keep it as a personal work log. The value is in capturing the session while context is fresh -- where it ends up is your call.

Visibility Auto-Assignment

Lovai posts support per-block visibility: public (anyone), premium (paid access via Stripe Connect), and private (you only).

The skill auto-assigns based on these criteria:

public: Conceptual explanations, high-level reasoning, gotcha overviews
premium: Reusable code snippets, config files, concrete data and templates
private: Not set by the skill (users can change this on Lovai)

This comes from my own experience as a content buyer. "Why did you choose this approach?" -- I want that for free. "Here's the exact implementation" -- that's worth paying for.

A Real Output: Remotion Video Session

Here's what a 3-hour Remotion implementation session produced:

Core Insight -- CSS transitions turned out lighter and more controllable than spring animations inside Remotion's pipeline
Why -- framer-motion conflicted with Remotion's rendering pipeline
Gotchas -- Misunderstood the relationship between fps: 30 and durationInFrames -- a 2-second animation rendered as 4 seconds
Details -- [premium]
Learnings -- Don't mix external animation libraries with Remotion; stay within its native API surface

Five blocks, one to two lines each. Three hours of trial and error compressed to this granularity.

Three Design Principles in Hindsight

Building this skill surfaced a few things I think are generally applicable:

Skills are behavioral instructions, not code. Ambiguous instructions produce inconsistent AI output. Defining the 5-block structure explicitly was about guaranteeing output reproducibility. The more precisely you specify what you want, the less the AI drifts.

Security must be safe by default. Draft-first posting, automatic secret stripping, relative path conversion. Any design that relies on users remembering to be careful will eventually cause an incident. The defense has to be structural, not behavioral.

Multi-tool support should focus on commonalities, not differences. Building per-tool parsers was tempting. But once I recognized that every session shares the same essential structure -- intent, attempts, failures, takeaways -- the unified approach became both simpler and more maintainable.

There's still plenty to improve. Security filter accuracy and block structure customization are the obvious next targets. But the core problem -- sessions disappearing into the void -- is solved.

Try it at lovai.app.

Stripe Closed My Connect Account -- Here's What Actually Fixed It in 24 Hours -- The payment infrastructure behind Lovai's creator payouts, and what happens when Stripe pulls the rug
OpenRouter Structured Output Broke Before Translation Quality Did -- Another case where the "boring" engineering (output structure, fallback layers) matters more than the AI itself

Anthropic Proved AI Can't Evaluate Its Own Work. Here's How I Rebuilt My Claude Code Setup Around That.

Lovanaut — Fri, 27 Mar 2026 04:01:38 +0000

I've been building products with Claude Code for months. Every time I asked "is this implementation correct?", the answer was "yes, it's properly implemented." Every time. Even when the code had bugs that broke in production.

Then Anthropic published a blog post that explained exactly why. I mapped my setup against their findings, and realized: my evaluator layer was almost empty.

Here's how I rebuilt it.

Jump to:

What Anthropic's experiment showed
Mapping this to Claude Code
Layer 1: Rules — always-on review criteria
Layer 2: Skills — on-demand reviewers
Layer 3: Agent separation — who builds vs who reviews
3 principles for evaluation design
Final file structure
Harness design checklist

What Anthropic's experiment showed

In March 2026, Anthropic published "Harness design for long-running apps" — experiments where AI agents autonomously built apps over multi-hour sessions.

The headline finding:

Agents asked to evaluate their own work tend to confidently praise it, even when it's clearly mediocre to human observers.

It gets worse. Agents would spot real problems, then wave them off as unimportant and approve anyway. They'd skim instead of testing edge cases. Anthropic themselves put it bluntly: "Claude is an inadequate QA agent out of the box."

Their fix was splitting generation from evaluation — three agents:

Agent	Role
Planner	Expands a one-line prompt into a full product spec
Generator	Writes the code
Evaluator	Clicks through the running app, finds bugs, scores against criteria

The difference was stark:

Setup	Time	Cost	Result
Solo (no evaluator)	20 min	$9	Core features broken
Full harness (with evaluator)	6 hrs	$200	Basic functionality worked + AI features

The evaluator checked 27 criteria per sprint and filed bug reports like "fillRectangle exists but doesn't fire on mouseUp."

Reading this, it clicked: Claude Code's config system can give you the same split.

Mapping to Claude Code

Here's the mapping:

Anthropic's agent	Claude Code equivalent	What goes here
Planner	CLAUDE.md + planning skills	Project context, constraints, design rationale
Generator	Claude Code + technical skills	Code generation
Evaluator	Review agents + rules + hooks	Quality gates, automated checks

When I laid out my own setup this way, the gap was obvious. CLAUDE.md had project context. Skills had coding patterns. But nothing was actually checking whether the output was correct. I was asking the generator to review its own work — the exact failure mode Anthropic documented.

Layer 1: Rules — always-on review criteria

Files in ~/.claude/rules/ load every session. Put things here that AI won't do on its own but that matter in production.

Here's a taste of my Supabase/PostgreSQL rules (30 total):

# ~/.claude/rules/supabase-postgres.md

## Index FK columns
PostgreSQL does NOT auto-index foreign key columns.

## RLS performance
Wrap auth.uid() in SELECT to prevent per-row execution:
- BAD: using (user_id = auth.uid())
- GOOD: using (user_id = (select auth.uid()))

## Cursor-based pagination
- BAD: OFFSET (slow on deep pages)
- GOOD: WHERE id > $last_id ORDER BY id LIMIT 20

Without this rule, the AI generates auth.uid() without the SELECT wrapper every time. Works fine with small tables. Tests pass. Then production slows to a crawl as rows grow. Classic "surface-level test that misses the deeper bug" — exactly what Anthropic described.

I think of rules as "never step on this mine again" files. Every rule started as a real mistake.

Layer 2: Skills — on-demand reviewers

Rules load every session, so too many will eat your context window. Anything task-specific goes into skills (.claude/skills/), which show only their titles by default and load on demand.

You can wire up keyword-triggered activation:

# ~/.claude/CLAUDE.md (excerpt)

## Automatic Skill Activation

### Testing / TDD
**Trigger:** test, TDD, coverage, unit test
**Action:** Run test-driven-development skill

### Bug / Error handling
**Trigger:** bug, error, debug, broken
**Action:** Run systematic-debugging skill

### Completion check
**Trigger:** done, verify, review, check
**Action:** Run verification-before-completion skill

The completion check is the big one. In Anthropic's experiment, the evaluator ran checks at the end of each sprint. Same idea here — say "verify this" and a quality checklist kicks in behind the scenes.

I run 27 skills total. 7 auto-activate on keywords.

Layer 3: Agent separation — who builds vs who reviews

The core insight from Anthropic: separate the builder from the reviewer. In Claude Code, you do this through agent orchestration:

# ~/.claude/rules/agents.md

## Role: Manager
You are a manager and agent orchestrator.

**Rules:**
- Never implement directly — delegate all implementation to Sub Agents
- Break tasks into small units and run PDCA cycles

## Delegation
### Always delegate:
1. Code implementation
2. Debugging
3. Test creation

### Manager handles directly:
1. Task decomposition
2. Progress verification
3. Plan adjustment

The trick: pin the main Claude as "manager = reviewer" and push all implementation to Sub Agents. This gives Claude Code the same generator/evaluator split that Anthropic proved works.

Main Claude doesn't write code. It reviews what Sub Agents produce. Planner + evaluator = main Claude. Generator = Sub Agents.

3 principles for evaluation design

1. Weight your criteria toward what AI misses

Anthropic's frontend experiment used 4 criteria: design quality, originality, technical execution, functionality. They weighted design and originality higher — because the AI already did well on technical execution and functionality.

Lower the weight on things AI handles naturally. Raise it on things AI overlooks.

In practice:

Low weight (AI's fine): syntactically correct code, basic API endpoints
High weight (AI misses): performance traps (auth.uid() without SELECT), UX decisions that affect conversion, security blind spots

2. Prune your harness as models improve

From Anthropic:

Every component of a harness encodes an assumption about what the model can't do alone, and these assumptions can be wrong or quickly become outdated as models improve.

When they went from Opus 4.5 to 4.6, sprint decomposition became unnecessary — the newer model handled long sessions on its own. Same thing happens with your Claude Code rules. Something essential today may be dead weight next quarter.

I've revised my CLAUDE.md 8 times. The test for each line: "If I delete this, will the AI make mistakes?" No? Cut it.

3. Better models mean more harness possibilities, not fewer

The space of interesting harness combinations expands rather than contracts as models improve.

Sounds backwards, but it matches my experience. As the AI gets smarter, you can delegate more. But the remaining evaluation points get more nuanced, more subtle, and higher-stakes. The easy rules go away. The hard judgment calls stay.

Final file structure

~/.claude/
├── CLAUDE.md                # Planner layer (project overview + skill triggers)
├── rules/
│   ├── agents.md            # Generator/evaluator split
│   ├── supabase-postgres.md # Review criteria (DB/RLS, 30 rules)
│   ├── react-nextjs.md      # Review criteria (React/Next.js)
│   ├── security.md          # Review criteria (security)
│   ├── coding-style.md      # Code quality
│   └── testing.md           # Test quality
└── skills/                   # On-demand reviewers
    ├── verification-before-completion  # End-of-task checks
    ├── systematic-debugging            # Debug-time checks
    ├── test-driven-development         # TDD enforcement
    └── ... (27 total)

How it maps to Anthropic's architecture:

CLAUDE.md → Planner artifact (the product spec)
rules/ → Review criteria (the sprint contract)
skills/ → Specialist reviewers (activate when needed)
agents.md → Builder/reviewer separation

Harness design checklist

Planner layer (CLAUDE.md)

[ ] Project overview and constraints documented
[ ] Design decisions and their rationale included
[ ] Under 200 lines (bloated CLAUDE.md degrades instruction-following)

Review criteria (rules/)

[ ] Cover what AI misses, not what it already does well
[ ] Weighted toward production-critical concerns
[ ] Regularly pruned as models improve

On-demand reviewers (skills/)

[ ] Separated by domain (DB, React, security, etc.)
[ ] Keyword auto-activation configured
[ ] Completion verification skill exists

Builder/reviewer separation (agents.md)

[ ] Main Claude delegates implementation to Sub Agents
[ ] Verification flow for implementation results

OpenRouter Structured Output Broke Before Translation Quality Did — 3 Layers of Defense for Production

Lovanaut — Wed, 25 Mar 2026 04:35:08 +0000

The first production incident wasn't a bad translation. It was a Markdown code fence wrapping the JSON response.

One day, error notifications flooded in. The UI was rendering blank blocks where translations should have been. The cause? The model had quietly started being "helpful" by wrapping its JSON responses in json ... fences. JSON.parse() choked immediately, and the translation feature went down — not because of bad translations, but because of three backticks.

This article walks through the exact defense system I built to stabilize structured output from the OpenRouter API in production, in the order the failures surfaced. The main topic is malformed JSON responses. I also cover retry/fallback and language detection, but JSON handling is where most of the engineering hours went.

TL;DR

The Core Issue: LLM translation quality doesn't matter if JSON.parse() fails. Markdown code fences and truncation will break your app before bad translations do.
The Safe Baseline: json_object + response-healing + fail-closed parsing + expected-key validation.
The Fix: A 3-layer defense using response_format: { type: 'json_object' }, OpenRouter's response-healing plugin, and a custom defensive parser that rejects partial or malformed data instead of returning incomplete results.
Bonus: Why you should only retry HTTP 429/5xx errors, and why binary language detection fails for tech content.

Failure mode	Symptom	Defense
Code fences	`JSON.parse()` fails	`json_object` + `response-healing`
Missing keys	Blank UI blocks	Fail-closed parser + expected-key validation
429 / 5xx	Intermittent request failure	Retry + model fallback double loop
Mixed-language text	Wasted API calls or false skips	Ratio-based detection with asymmetric thresholds

Context: This comes from building auto-translation (Japanese to English, bidirectional) for Lovai, an AI recipe-sharing platform. The translation handles user-generated posts with titles, summaries, and multi-block body content.

This article focuses on in-app content translation — it's a separate layer from hreflang-based multilingual SEO.

Fixing LLM JSON Corruption: 3-Layer Defense with OpenRouter

The first thing you need to handle when you run an LLM API in production is not translation quality — it's malformed JSON responses. Bad quality means "the translation is awkward." Parse failure means "the feature is down."

In my initial implementation, I wasn't using JSON Mode at all. The system prompt just said "return JSON," with no response_format specified. This worked fine for a while — until the model started wrapping responses in Markdown code fences without warning.

Here's what was actually coming back:

```json
{"__title": "Built Translation with OpenRouter"}
```

JSON.parse() chokes on this immediately. I added three layers of defense.

Layer 1: Enable JSON Mode with `response_format: { type: 'json_object' }`

First, I added response_format: { type: 'json_object' }. This constrains the model to return valid JSON. Running LLM output through JSON.parse() without response_format is not safe for production. Prompt-only instructions break silently when models update or when the service is under load.

Note that structured outputs (json_object / json_schema) are only available on supported models. OpenRouter's model pages list compatibility.

Layer 2: OpenRouter `response-healing` Plugin for Auto-Repair

OpenRouter has a response-healing plugin that automatically fixes:

Markdown code fence removal (json ...)
Missing brackets and trailing commas
JSON extraction from surrounding text

const requestBody = {
  model,
  messages: [/* ... */],
  response_format: { type: 'json_object' },
  plugins: [{ id: 'response-healing' }],  // Enable auto-repair
};

response-healing works alongside json_object / json_schema. Known constraints: it's non-streaming only, and it can't fix truncation from max_tokens cutoff.

Layer 3: Fail-Closed Parsing — Parse Success Is Not Enough

Even with JSON Mode and response-healing, I keep a defensive parser on the application side. It's insurance against model behavior changes or API spec updates.

The parser rejects partial or malformed data instead of returning incomplete results. If it can't produce valid, complete JSON with all expected keys, it throws rather than silently serving broken translations.

function parseTranslationResponse(
  content: string,
  expectedKeys: string[]
): Record<string, string> {
  // Step 1: Try parsing raw content directly
  let parsed: unknown;
  try {
    parsed = JSON.parse(content);
  } catch {
    // Step 2: Strip code fences and retry
    const stripped = content
      .replace(/^```
{% endraw %}
(?:json)?\s*/gm, '')
      .replace(/^
{% raw %}
```\s*/gm, '')
      .trim();
    parsed = JSON.parse(stripped);  // Let it throw if still invalid
  }

  // Step 3: Validate structure — fail closed
  if (typeof parsed !== 'object' || parsed === null || Array.isArray(parsed)) {
    throw new Error('LLM response is not a JSON object');
  }

  const result: Record<string, string> = {};
  for (const key of expectedKeys) {
    const value = (parsed as Record<string, unknown>)[key];
    if (typeof value !== 'string') {
      throw new Error(`Missing or non-string value for key: ${key}`);
    }
    result[key] = value;
  }

  // Log unexpected keys (model occasionally adds metadata fields)
  const extraKeys = Object.keys(parsed as Record<string, unknown>)
    .filter(k => !expectedKeys.includes(k));
  if (extraKeys.length > 0) {
    console.warn(`LLM returned unexpected keys: ${extraKeys.join(', ')}`);
  }

  return result;
}

Key design decisions:

Fail closed: Missing keys throw an error rather than silently returning partial data. This routes failures to the retry loop instead of serving broken translations.
Key validation: The caller passes expectedKeys (block IDs), and the parser verifies every expected key is present with a string value. This catches cases where JSON.parse() succeeds but the model dropped or renamed keys.
Extra key warning: Unexpected keys get logged but don't fail the request — the model occasionally adds metadata fields that are harmless.

Stabilizing JSON output from LLM APIs requires both API-side constraints (json_object + response-healing) and application-side defensive parsing with key validation. Either one alone leaves you exposed to model behavior drift or API spec changes.

When to use json_schema instead: OpenRouter also supports json_schema mode. With json_schema + strict: true, you get output that matches a predefined schema. For translation, the keys are dynamic (they depend on block IDs per post), so json_object is simpler. If your keys are static and predictable — like entity extraction (person names, organizations, dates as fixed fields) — json_schema + strict: true is more reliable, and Layer 1 alone may be sufficient. That said, you can approximate dynamic keys with json_schema by generating the schema per request or using additionalProperties — it's just more implementation overhead.

LLM API Retry Design: Model Fallback and HTTP Error Strategy

After JSON parsing, the next thing I needed to stabilize was API call reliability.

Model Fallback x Retry Double Loop

const MODEL = 'google/gemini-3-flash-preview';
const FALLBACK_MODEL = process.env.OPENROUTER_TRANSLATE_FALLBACK_MODEL || '';

const modelCandidates = Array.from(
  new Set([MODEL, FALLBACK_MODEL].filter(Boolean))
);

for (const model of modelCandidates) {
  for (let attempt = 0; attempt <= maxRetry; attempt++) {
    // Translation attempt
  }
}

The outer loop switches models. The inner loop handles retries. If the primary model exhausts all retries (max 2), it falls through to the fallback model.

In my implementation, I only retry HTTP 429 and 5xx responses. Retrying a 400 (bad request) or 401 (auth error) won't change the outcome — you end up in an infinite retry loop on a config error.

const shouldRetryStatus = (status: number): boolean =>
  status === 429 || status >= 500;

Note: this covers HTTP-level errors. Transport-level failures (timeouts, connection resets, DNS failures) are handled separately by the AbortController timeout below — those always get retried since they don't indicate a permanent problem.

Timeout Control with AbortController

const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 15_000);

try {
  const response = await fetch(OPENROUTER_API_URL, {
    signal: controller.signal,
    // ...
  });
} finally {
  clearTimeout(timeout);
}

I initially set it to 8 seconds, but longer posts (5,000+ characters) were timing out mid-flight. I bumped it to 15 seconds. LLM API timeouts need to scale with input length. Too short and you kill legitimate requests. Too long and you can't detect hangs.

Language Detection for Mixed-Script Text: Why Ratio Beats Binary

Before translating, you need to check: "Is this text already in the target language?" This prevents unnecessary API calls. I got this wrong in the first version too.

The initial approach was simple binary detection — "does the text contain characters of this language?"

// Initial implementation (broken)
const hasJapanese = (text: string): boolean =>
  /[\u3040-\u30ff\u3400-\u9fff]/u.test(text);
const hasLatin = (text: string): boolean =>
  /[A-Za-z]/.test(text);

// Has Japanese && no Latin → Japanese text → skip translation
if (isJa && !isEn) { /* skip */ }

This pattern applies to any language pair where technical terminology bleeds across scripts. A Japanese post like "Next.jsでReactアプリを作った" contains both Japanese characters and Latin characters, so binary detection flags it for translation.

In tech content, English terms mixed into non-Latin-script text is the norm, not the exception. This isn't limited to Japanese-English — Korean tech posts with English terms, Chinese posts with API names, Arabic text with framework names all hit the same trap. Any language pair where one script dominates but technical terms intrude from another will produce false positives with binary detection.

Binary detection classified nearly every Japanese post as "needs translation," triggering a flood of unnecessary API calls.

The fix was ratio-based detection.

function isAlreadyInTargetLanguage(
  text: string,
  target: SupportedLanguage
): boolean {
  const jaChars = (
    text.match(/[\u3040-\u30ff\u3400-\u9fff\uff00-\uffef]/gu) || []
  ).length;
  const latChars = (text.match(/[A-Za-z]/g) || []).length;
  const total = jaChars + latChars;
  if (total === 0) return true;

  const jaRatio = jaChars / total;
  if (target === 'ja' && jaRatio > 0.95) return true;
  if (target === 'en' && (1 - jaRatio) > 0.95) return true;
  return false;
}

The threshold started at 70%, but Japanese text with 30%+ English terms was being misclassified as "already English." I raised it to 95%. After this change, false skips (Japanese text that didn't get translated) dropped to near zero.

Detection is split into two functions with different jobs:

Function	Purpose	Threshold	Strategy
`isAlreadyInTargetLanguage()`	Filter out text that doesn't need translation	95%	Strict (if in doubt, translate)
`isLikelyInTargetLanguage()`	Validate translation output quality	25%+ or 8+ chars	Lenient (tolerate mixed terminology)

For text where technical terms cross script boundaries, "skip detection" should be strict and "output validation" should be lenient. This asymmetry matters. Flip it and you either miss texts that need translation, or reject perfectly good translations.

Why OpenRouter + LLM over Google Translate or DeepL

I evaluated Google Cloud Translation API, DeepL API, and OpenRouter + LLM. Here's why I chose OpenRouter.

The dealbreaker was control over the response structure. Posts on the platform have titles, summaries, and multiple body blocks, each with a unique ID. Google Translate and DeepL can batch-translate, but they return an array — you have to track which translation maps to which block by index position yourself.

With LLM translation, I can use block IDs as JSON keys. The response comes back with those same keys, values translated. No mapping logic needed.

// Input: block IDs as keys
{ "__title": "Built Translation with OpenRouter", "block_abc_text": "Body text..." }
// Output: keys preserved, values translated
{ "__title": "OpenRouterで翻訳を作った", "block_abc_text": "本文テキスト..." }

This "send keyed JSON, get keyed JSON back" pattern works well specifically because of OpenRouter's json_object mode combined with the response-healing plugin.

On cost (at the time of writing): translating one post (~2,000 chars / ~1,500 tokens) costs about $0.04 on Google NMT vs. under $0.001 on gemini-2.5-flash-lite (input $0.10 / output $0.40 per 1M tokens). Character-based and token-based pricing don't compare directly, but for short-form content translation, the LLM route is significantly cheaper.

Detailed comparison: Google Cloud Translation / DeepL / OpenRouter

Factor	Google Cloud Translation / DeepL	OpenRouter + LLM
Response structure	Array of translated strings in input order. Map translations back to fields by index	Send JSON with keys, get JSON back with keys preserved and only values translated
Terminology control	Glossary (pre-registered term mappings). Precise, but requires manual registration	Prompt-level instructions. No pre-registration, less strict
Model switching	Limited. Google has NMT vs Translation LLM. DeepL has `model_type`	Change one environment variable. `gemini-2.5-flash-lite` to `gemini-3-flash-preview` without changing application code
Pricing	Per-character (Google NMT: $20/1M chars, 500K free/month. DeepL Free: 500K chars/month)	Per-token (varies by model)

For terminology control, Google/DeepL Glossaries are more precise. But in AI/tech content, new terms appear constantly. Registering each one gets expensive in maintenance time. With LLM translation, I just tell the prompt "preserve technical terms as-is." Less strict, but that simplicity matters when you're a solo developer.

OpenRouter lets you call multiple LLM models through a unified API. I started with gemini-2.5-flash-lite and later switched to gemini-3-flash-preview — just an environment variable change, without changing application code.

Timeline: How This Feature Actually Evolved

This feature didn't ship complete. It improved every time production broke.

Version	Changes	What Broke
v1 (Jan)	Basic implementation. `gemini-2.5-flash-lite`, 8s timeout, binary language detection, no JSON Mode	Initial release
v1.1 (Jan)	Explicit prompt rules (preserve technical terms, preserve keys, etc.)	Technical terms getting translated unintentionally
v2 (Feb)	JSON Mode added, `response-healing` enabled, defensive parser, model switch (`gemini-3-flash-preview`), ratio-based language detection (70%), timeout bumped to 15s	JSON parse errors flooding error notifications
v3 (Current)	Language detection threshold raised to 95%, output validation function separated, key validation added	70% threshold causing "Japanese text not translated" misclassifications

Getting from v1 ("it works") to v2 ("it doesn't break") took the most effort. The v2 JSON corruption fix alone took a full day.

Three Principles for Stable Structured LLM Output

These are the three principles that stabilized LLM structured output in my production system:

JSON corruption is priority zero. response_format: { type: 'json_object' } + response-healing plugin handles most cases, but keep an application-side defensive parser with key validation for max_tokens truncation and model differences. If your schema is static, json_schema + strict: true is more reliable.
Only retry HTTP 429 and 5xx. Retrying 4xx is pointless. Handle transport-level failures (timeouts, connection resets) separately. Separate model fallback and retry into a double loop.
Use ratio-based language detection. Binary detection is useless when technical terms cross script boundaries. Make "skip detection" strict and "output validation" lenient — the asymmetry is the point.

These three principles aren't specific to translation. They apply to any case where you expect structured output from an LLM API — text classification, entity extraction, content structuring.

If you're parsing JSON from an LLM in production, treat malformed output as an uptime problem, not a quality problem.

If you've hit a different failure mode with structured LLM output, I'd like to hear about it.

References

Stripe Closed My Connect Account. Here's What Actually Fixed It in 24 Hours.

Lovanaut — Wed, 25 Mar 2026 03:56:05 +0000

I'm building Lovai, a creator marketplace where users can sell parts of a post as paid content — block by block. To support payouts, I implemented Stripe Connect Express with hosted onboarding, destination charges, webhook-based purchase fulfillment, and Supabase RLS for access control.

During review, Stripe temporarily closed the account and flagged the business as potential aggregation. Stripe later told me that, in my case, the Connect application had not been fully submitted at the time of review. After I clarified the business model and completed the application, the account was re-reviewed and approved the next day.

This post explains what happened, what fixed it, and how the payment flow works end to end.

Jump to:

Why Stripe flagged my platform as aggregation
Stripe Connect Express: onboarding implementation
Checkout with destination charges
Webhook signature verification and idempotency
Purchase records secured with Supabase RLS

Accepting payments vs. routing payouts: a different beast

There are plenty of tutorials on adding Stripe to your SaaS for subscription billing. Building a system where your users sell their own content and receive payouts is a fundamentally different problem.

On Lovai, creators can mark parts of their posts as paid. When someone buys, the creator gets paid directly. To make this work, I needed Stripe Connect.

If you're just collecting payments for yourself, a standard Stripe account is fine. The moment you route money to other people, you're dealing with compliance reviews, legal requirements, and fund flow design.

Why I chose Stripe Connect Express over Standard or Custom

Stripe Connect offers multiple account types.

Note: Stripe now describes Standard / Express / Custom account types as deprecated for newer integrations, while existing integrations continue to work. For new builds, check controller properties or newer migration paths.

I went with Express for one reason: Stripe handles identity verification and onboarding for you.

When a creator opens a Stripe account, they need to verify their identity and register a bank account. Building those screens yourself is a massive time sink. With Express, Stripe provides the entire onboarding flow — a huge win for solo developers.

const account = await stripe.accounts.create({
  type: 'express',
  country: 'JP',
  capabilities: {
    card_payments: { requested: true },
    transfers: { requested: true },
  },
  business_type: 'individual',
});

Legal requirements before setting up Stripe Connect

This gets overlooked surprisingly often. In practice, Stripe's review team expected these pages to be live on my site before approval:

Privacy Policy
Terms of Service
E-commerce disclosure page — In Japan, this is required under the Act on Specified Commercial Transactions (特定商取引法). It's prescriptive: you must publish your seller name, address, return policy, and pricing. Other countries have analogous requirements.

This isn't Connect-specific. It's a prerequisite for accepting any payments. Get these pages live before you start the Connect application.

Heads up: Stripe's review team flagged the title of my disclosure page. The exact wording needed to match the legally prescribed format. They also required my seller name and responsible person to match my Stripe account registration exactly. Small details, but they'll hold up your review.

Why Stripe flagged my platform as aggregation

When the "Your account has been closed" email arrived, I froze. I had just finished wiring up the Supabase RLS policies. The platform was ready. And then Stripe shut the account down.

I'd previously integrated Stripe Connect for another project (Sapolova, a creator support platform), and that review went smoothly. The business model was simpler, and the review was straightforward.

Lovai was different. Stripe closed my account.

What Stripe told me

The email said Lovai's business fell under "aggregation" — one of their prohibited business categories. They noted that review criteria are confidential and couldn't share further details.

How I responded

I sent a detailed breakdown of Lovai's business model:

1. Clarified the service category

Educational Services: sharing technical workflows
Digital Goods: code snippets, prompts, AI recipes

2. Demonstrated content moderation

Terms of service explicitly ban adult content, copyright infringement, and get-rich-quick schemes
Moderation systems are in place

3. Referenced comparable services

Named platforms with similar business models that use Stripe — to show that the model fit an established pattern Stripe already supports

What actually triggered the review

I also proposed an alternative: Lovai as the sole seller, with monthly bank transfers to creators instead of Connect.

Stripe's response revealed the actual issue. In my case, the Connect application hadn't been fully submitted at the time of review, so they interpreted it as "intending to process third-party payments without Connect."

They further explained that a marketplace operating without Connect would constitute aggregation — a prohibited activity. The alternative I'd proposed would have been the actual violation.

Once my Connect application was confirmed as submitted, they re-reviewed the account. The next day, Stripe approved the business on re-review.

This was my specific experience. The definition of "aggregation" and review criteria are at Stripe's discretion and may vary by service.

Three things I'd do differently

Submit the Connect application early. Stripe may interpret a gap between account creation and Connect application submission as intent to process third-party payments without Connect — which can qualify as aggregation. In my case, that gap was what triggered the flag.
Prepare your explanation before you need it. When a service spans multiple categories (education, digital goods, creator economy), Stripe's review team needs to map it to an established pattern. Organize your service category, comparable platforms, and content policies so the reviewer can classify quickly. The harder it is to categorize, the more likely it gets flagged.
Don't accept rejection as final. A detailed, structured explanation can get you a re-review. The key is making it easy for the reviewer to say "yes" — show that your model fits a pattern Stripe already supports, not that you're doing something novel.

The complete payment flow

sequenceDiagram
    participant Buyer
    participant Lovai as Lovai (Server)
    participant Stripe
    participant Creator as Creator's Stripe Account

    Buyer->>Lovai: Purchase paid content
    Lovai->>Lovai: Validation (already purchased? own post?)
    Lovai->>Stripe: Create Checkout Session (with transfer_data)
    Stripe-->>Buyer: Redirect to payment page
    Buyer->>Stripe: Enter card details & pay
    Stripe->>Lovai: Webhook (checkout.session.completed)
    Lovai->>Lovai: Verify signature → update purchase record → log earnings
    Stripe->>Creator: Auto-transfer (amount minus fees)

When creating the Checkout Session, you specify the creator's Stripe account in transfer_data. This creates a destination charge: Stripe processes the charge on the platform account, routes funds to the creator's connected account, returns the application fee to the platform, and debits Stripe processing fees from the platform balance.

Stripe Connect Express: onboarding implementation

This is the flow for creators to set up their Stripe Connect account.

export async function createConnectAccount() {
  const userId = await getAuthUserId();

  // Check for existing account (prevent duplicates)
  const { data: existingAccount } = await serviceClient
    .from('creator_stripe_accounts')
    .select('stripe_account_id, details_submitted')
    .eq('user_id', userId)
    .maybeSingle();

  let accountId: string;

  if (existingAccount) {
    accountId = existingAccount.stripe_account_id;
  } else {
    const account = await stripe.accounts.create({
      type: 'express',
      country: 'JP',
      capabilities: {
        card_payments: { requested: true },
        transfers: { requested: true },
      },
      business_type: 'individual',
      metadata: { lovai_user_id: userId },
    });
    accountId = account.id;

    await serviceClient.from('creator_stripe_accounts').insert({
      user_id: userId,
      stripe_account_id: accountId,
      charges_enabled: false,
      payouts_enabled: false,
      details_submitted: false,
    });
  }

  const accountLink = await stripe.accountLinks.create({
    account: accountId,
    refresh_url: `${baseUrl}/settings/payments?refresh=true`,
    return_url: `${baseUrl}/settings/payments?success=true`,
    type: 'account_onboarding',
  });

  return { data: { url: accountLink.url } };
}

Storing the Lovai user ID in metadata lets you identify which user owns which Stripe account. The charges_enabled, payouts_enabled, and details_submitted statuses are synced from the Stripe API to your local DB.

Checkout with destination charges (transfer_data)

This handles what happens when a buyer purchases paid content. Lovai uses Stripe's hosted Checkout — redirecting to their payment page.

export async function createPurchaseCheckoutSession(postId: string) {
  const userId = await getAuthUserId();

  const post = await getPost(postId);
  if (!post) return { error: { code: 'NOT_FOUND' } };
  if (!post.has_premium || !post.price_yen) return { error: { code: 'NOT_PREMIUM' } };
  if (post.author_id === userId) return { error: { code: 'OWN_POST' } };

  const existingPurchase = await getExistingPurchase(postId, userId);
  if (existingPurchase?.status === 'completed') return { error: { code: 'ALREADY_PURCHASED' } };

  const creatorAccount = await getCreatorStripeAccount(post.author_id);
  if (!creatorAccount?.charges_enabled) return { error: { code: 'CREATOR_NOT_READY' } };

  const priceAmount = post.price_yen;
  const applicationFee = calculatePlatformFee(priceAmount);

  const session = await stripe.checkout.sessions.create({
    mode: 'payment',
    payment_method_types: ['card'],
    line_items: [{
      price_data: {
        currency: 'jpy',
        product_data: {
          name: post.title,
          description: 'Premium content purchase',
        },
        unit_amount: priceAmount,
      },
      quantity: 1,
    }],
    payment_intent_data: {
      application_fee_amount: applicationFee,
      transfer_data: {
        destination: creatorAccount.stripe_account_id,
      },
    },
    success_url: `${baseUrl}/post/${postId}?purchase=success`,
    cancel_url: `${baseUrl}/post/${postId}?purchase=cancelled`,
    metadata: {
      post_id: postId,
      buyer_id: userId,
      author_id: post.author_id,
      price_yen: String(priceAmount),
    },
  });

  await serviceClient.from('post_purchases').insert({
    post_id: postId,
    buyer_id: userId,
    price_yen: priceAmount,
    stripe_checkout_session_id: session.id,
    status: 'pending',
  });

  return { data: { url: session.url } };
}

Three parameters that matter:

Parameter	What it does	What breaks without it
`transfer_data.destination`	Routes funds to the creator's Stripe account	Payment succeeds but creator never gets paid
`application_fee_amount`	Your platform fee — Stripe deducts this and sends it to you	You earn nothing from the transaction
`metadata`	Identifies which post was purchased and by whom	Webhook can't update the right purchase record

The CREATOR_NOT_READY check matters. Specifying transfer_data when the creator's Stripe account isn't active causes an API error. Lovai caches charges_enabled locally but re-checks via the Stripe API before creating each checkout session. Cache alone would miss cases where Stripe deactivated an account.

Webhook signature verification and idempotency

The webhook receives payment completion events from Stripe and updates purchase records.

Signature verification (non-negotiable)

export async function POST(req: NextRequest) {
  const body = await req.text();
  const signature = req.headers.get('stripe-signature');

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, signature!, webhookSecret);
  } catch (err) {
    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
  }
  // ...
}

Never skip signature verification. Without it, anyone can send fake webhook requests and manipulate purchase records. Similarly, SUPABASE_SERVICE_ROLE_KEY is server-only — never include it in client-side code.

Three-layer idempotency

Stripe webhooks can deliver the same event multiple times. This implementation prevents duplicate processing with three layers: event deduplication, purchase status check, and earnings duplicate prevention.

Layer 1: Event deduplication via unique constraint

create table public.stripe_webhook_events (
  id bigint generated always as identity primary key,
  event_id text not null unique,
  event_type text not null,
  processed_at timestamptz default now() not null
);

If two webhooks for the same event arrive simultaneously, only the first insert succeeds. The second hits the unique constraint violation — no race condition.

Layer 2: Purchase status check

if (existingPurchase?.status === 'completed') {
  return NextResponse.json({ received: true });
}

Layer 3: Earnings duplicate prevention

async function createCreatorEarning(params) {
  const { purchaseId, creatorId, postId, grossAmount } = params;

  const { data: existing } = await supabase
    .from('creator_earnings')
    .select('id')
    .eq('purchase_id', purchaseId)
    .maybeSingle();

  if (existing) return;

  const platformFee = calculatePlatformFee(grossAmount);
  const stripeFee = calculateStripeFee(grossAmount);
  const netAmount = grossAmount - platformFee - stripeFee;

  await supabase.from('creator_earnings').insert({
    creator_id: creatorId,
    purchase_id: purchaseId,
    post_id: postId,
    gross_amount: grossAmount,
    platform_fee: platformFee,
    stripe_fee: stripeFee,
    net_amount: netAmount,
    status: 'pending',
  });
}

Storing gross_amount, platform_fee, stripe_fee, and net_amount separately means you can trace exactly which formula produced each record when you adjust fees later.

For simplicity, this shows sequential operations. In production, if the DB update fails after the event is logged, you get an inconsistent state. Ideally, wrap event logging, purchase update, and earnings creation in a single transaction. If that's not feasible, use a recoverable job queue.

Earnings calculation

For a 500 JPY (~$3.50 USD) purchase:

Item	Amount
Sale price (gross)	500 JPY
Stripe processing fee	3.6% for domestic cards in Japan (Stripe pricing)
Platform fee	Based on your rate (set via `application_fee_amount`)
Creator payout (net)	Sale price - Stripe fee - platform fee

On Stripe fees: The 3.6% rate applies to domestic card payments in Japan. Stripe also sets minimum transaction amounts that vary by currency — check the Stripe docs for current limits. Fees and minimums differ by payment method (cards, convenience store payments, bank transfers). Always verify actual amounts in your Stripe Dashboard.

Purchase records secured with Supabase RLS

Table definition

create type public.purchase_status as enum (
  'pending',
  'completed',
  'refunded'
);

create table public.post_purchases (
  id uuid primary key default gen_random_uuid(),
  post_id uuid not null references public.posts(id) on delete restrict,
  buyer_id uuid not null references public.profiles(id) on delete cascade,
  price_yen integer not null,
  stripe_payment_intent_id text,
  stripe_checkout_session_id text,
  status public.purchase_status default 'pending' not null,
  created_at timestamptz default now() not null,
  completed_at timestamptz,
  unique (post_id, buyer_id)
);

Design decisions:

unique (post_id, buyer_id) — Prevents double-purchasing.
on delete restrict — Prevents creators from deleting purchased posts. Buyers paid for that content; it shouldn't vanish. Creators can change a post's status instead.

RLS: users can read, only the server can write

create policy "post_purchases_select_own"
  on public.post_purchases for select
  using (buyer_id = (select auth.uid()));

create policy "post_purchases_select_author"
  on public.post_purchases for select
  using (
    exists (
      select 1 from public.posts p
      where p.id = post_purchases.post_id
        and p.author_id = (select auth.uid())
    )
  );

INSERT, UPDATE, and DELETE are not permitted for any user. All mutations go through the webhook via the Service Role client.

If UPDATE were open, a user could flip their purchase from pending to completed without paying. I covered this in detail in my article on how Lovai uses Supabase RLS to protect paid content at the database layer.

Access check with Security Definer

create or replace function public.has_purchased(
  p_post_id uuid,
  p_user_id uuid
)
returns boolean
language sql
security definer
stable
set search_path = ''
as $$
  select exists (
    select 1 from public.post_purchases
    where post_id = p_post_id
      and buyer_id = p_user_id
      and status = 'completed'
  );
$$;

set search_path = '' plus fully qualified table names (public.post_purchases) prevents schema injection attacks. Always apply both when creating Security Definer functions.

What I'd tell someone building a creator marketplace

Phase	What to get right
Before Stripe	Legal pages live. Seller info matches Stripe registration exactly.
Connect application	Submit it at the same time as account creation. A gap between the two was what triggered my review issue.
If flagged	Prepare a structured explanation: service category, comparable platforms, content policies. Make it easy for the reviewer.
Implementation	`transfer_data.destination` is everything. Without it, creators don't get paid.
Security	Webhook signature verification is mandatory. Users must never have write access to purchase records. Three-layer idempotency. Security Definer functions need `set search_path = ''`.

If you're building something where users earn money through your platform, the payment architecture is the one thing you can't get wrong. I hope this saves you some of the headaches I went through.

What's the worst surprise you've hit during a Stripe integration? I'd love to hear about it in the comments.

Try Lovai: AI recipes and dev workflows, shared block by block

DEV Community: Lovanaut

From Form Response to Figma Wireframe: MCP Orchestration in Practice

The Architecture

The Hearing Form: 5 Steps, 28 Questions

Figma Plugin API: Key Implementation Patterns

Sandbox Limitations

The appendChild-then-FILL Constraint

Font Loading Is Mandatory

The Main Frame Structure

Mapping Hearing Responses to Wireframe Elements

Mood-to-Design Parameter Translation

Dynamic Section Construction

Test Results

Honest Limitations

Figma vs Canva

The Prompts

Your Form Response Just Created a GitHub PR: Cross-Service Orchestration With MCP

The Architecture: There Is No Integration

What Actually Works Today

Five Patterns That Actually Work

Pattern 1: Bug Report to Code Fix

Pattern 2: Lead Capture to Sales Pipeline

Pattern 3: NPS Feedback Loop

Pattern 4: Event Operations Pipeline

Pattern 5: Incident Response

What Cannot Be Automated (Yet)

Why This Matters for MCP Server Builders

The Testing Reality

What This Means for Form Services

FORMLOVA launches on Product Hunt April 15. If this resonated, your support means a lot: https://www.producthunt.com/products/formlova?launch=formlova

127 MCP Tools, 4 Safety Levels: Building a Server-Enforced Form Ops Layer

127 MCP Tools, 4 Safety Levels: Building a Server-Enforced Form Ops Layer

The Problem With Prompts: LLMs Skip Steps

Classifying 127 Tools by Blast Radius

The confirmation_token: HMAC-SHA256 Hard Block

Why Preview Confirmation Uses URL Open-Tracking

withFormResolver: Eliminating Chat Friction

Why the Dashboard Survived

Responses to Route to Notify: Implementation Internals

The Standard I Care About

Designing a CLI Skill That Structures AI Sessions into Posts -- Architecture, Security, and Implementation Decisions

Body

The Full Architecture

The Skill Definition -- 5-Block Structure

Why Exactly Five

The Section Attribute Mistake

Security Filtering -- The Two-Layer Defense

The Actual Secret Detection Patterns

Where I Got It Wrong

Multi-Tool Support: Unified Analysis Over Tool-Specific Parsers

API Integration: Why curl, Why No SDK

Setup

The API Call

Beyond Lovai

Visibility Auto-Assignment

A Real Output: Remotion Video Session

Three Design Principles in Hindsight

Related Articles

Anthropic Proved AI Can't Evaluate Its Own Work. Here's How I Rebuilt My Claude Code Setup Around That.

What Anthropic's experiment showed

Mapping to Claude Code

Layer 1: Rules — always-on review criteria

Layer 2: Skills — on-demand reviewers

Layer 3: Agent separation — who builds vs who reviews

3 principles for evaluation design

1. Weight your criteria toward what AI misses

2. Prune your harness as models improve

3. Better models mean more harness possibilities, not fewer

Final file structure

Harness design checklist

Links

OpenRouter Structured Output Broke Before Translation Quality Did — 3 Layers of Defense for Production

TL;DR

Fixing LLM JSON Corruption: 3-Layer Defense with OpenRouter

Layer 1: Enable JSON Mode with response_format: { type: 'json_object' }

Layer 2: OpenRouter response-healing Plugin for Auto-Repair

Layer 3: Fail-Closed Parsing — Parse Success Is Not Enough

LLM API Retry Design: Model Fallback and HTTP Error Strategy

Model Fallback x Retry Double Loop

Timeout Control with AbortController

Layer 1: Enable JSON Mode with `response_format: { type: 'json_object' }`

Layer 2: OpenRouter `response-healing` Plugin for Auto-Repair