Handoff

Handoff는 transcript, 메모, 이슈, 업무 요청을 단순 요약이 아니라 다음 Agent Run이 이어받을 수 있는 실행 상태로 바꾸는 해커톤 MVP입니다. 흩어진 맥락을 목표, 필요한 맥락, 실행 요청, 검증 증거, 기억 후보, 다음 액션으로 구조화합니다.

Lovable 데모: https://view-capture-match.lovable.app

첫 번째 입력/데모 사용 사례는 고객 미팅 transcript입니다. 다만 제품 전체를 Meeting Delivery 서비스로 좁히지 않습니다. 사용자가 transcript, 메모, 이슈, 업무 요청을 입력하면 Lovable UI가 n8n Webhook을 호출하고, n8n은 Upstage API를 통해 내용을 agent-ready 실행 상태로 구조화한 뒤 결과를 다시 화면에 보여줍니다.

Execution Memory는 이 제품이 겨냥하는 문제 정의이자 카테고리입니다. Lovable 데모와 GitHub 문서의 전면 제품명은 Handoff로 확정합니다.

Hermes는 이 thesis의 기술 코어입니다. Hermes는 회의록 요약기나 메일 자동화가 아니라, AI Agent가 목표, 필요한 맥락, 실행 요청, 검증 증거, 기억 후보, 다음 액션을 잃지 않도록 하는 coordination + continuity runtime입니다. 자세한 방향은 docs/hermes-mcp-direction.md를 봅니다.

어떤 서비스인가

Handoff는 고객 미팅, 내부 메모, 이슈, 업무 요청을 다음 Agent가 실행 가능한 run packet으로 바꿔줍니다.

• 목표, 사용된 맥락, 결정사항, 요구사항, 리스크, 부족한 정보를 파악합니다.
• Agent가 이어서 실행할 수 있는 실행 요청과 전달물을 생성합니다.
• 다음 실행이 이전 맥락을 이어받을 수 있도록 기억 후보와 next action을 남깁니다.
• 완료 증거, 부족한 증거, 품질 체크리스트, 다음 검증 단계를 함께 보여줍니다.

사용 경험은 챗봇이 아니라 업무용 워크벤치에 가깝습니다. 사용자는 transcript나 업무 요청을 붙여넣고, 필요한 산출물 유형을 선택한 뒤, 실행 결과를 네 가지 영역에서 검토합니다: Goal State, Execution Requests, Execution Memory, Evidence Ledger.

데모 관점

대부분의 회의 AI는 기록과 요약에서 멈춥니다. Handoff는 transcript를 다음 실행으로 이어지는 상태로 바꿉니다. 무엇이 목표인지, 어떤 맥락을 사용했는지, 어떤 실행 요청이 필요한지, 어떤 증거로 완료를 확인할 수 있는지, 다음 Agent Run이 무엇을 이어받아야 하는지를 한 번에 보여주는 것이 핵심입니다.

런타임 흐름

User
-> Lovable web app
-> n8n Webhook
-> Upstage API
-> n8n result assembly
-> Goal State
-> Context Used
-> Execution Requests
-> Evidence
-> Next Action
-> Lovable result screen

사용자 화면에서는 기억, 증거, 다음 실행을 전면에 둡니다. Hermes/Harness는 발표에서 설명할 수 있는 기술 구조이지만, Lovable UI의 전면 제품 라벨로 쓰지는 않습니다.

현재 MVP 구성

• 사용자-facing 제품 UI를 위한 Lovable 프론트엔드 스타터
• 제품 백엔드/워크플로우 런타임 역할을 하는 n8n Webhook workflow
• transcript를 실행 상태로 구조화하기 위한 Upstage Solar API 호출
• 회의 이해, 전달물 패키지, 기억/다음 실행, 증거 영역의 출력 계약
• 완료 증거 계약과 trajectory log
• 향후 persistence, CRM, email, calendar, RAG 확장을 위한 Supabase 및 integration notes

현재 데모 상태

• 2026-05-26 KST 기준 공개 Lovable URL은 n8n Cloud production webhook 환경변수로 갱신되었습니다.
• 제출 전 최종 증거로 공개 Lovable URL에서 실제 입력 -> n8n -> Upstage -> Handoff dashboard까지 한 번 더 캡처합니다.
• GitHub 기준 production handoff는 n8n Cloud import + Header Auth credential + Production Webhook URL + Lovable env redeploy 경로로 정리했습니다.
• n8n MCP endpoint는 로컬 Codex 설정에 등록되어 있지만, 현재 세션에서는 callable n8n MCP tool이 노출되지 않았습니다. MCP는 workflow control-plane으로 쓰고, Lovable runtime은 production webhook으로 연결합니다.
• n8n workflow path의 /webhook/upflow는 기존 runtime 식별자로 유지합니다. 제품명과 문서/화면 카피는 Handoff입니다.
• Upstage는 n8n을 통해 필요한 구조화 JSON을 반환합니다.
• Lovable UI 연동은 VITE_N8N_WEBHOOK_URL을 사용하고, 불필요한 CORS preflight를 피하기 위해 URLSearchParams로 POST합니다.
• Hosted Lovable preview에서는 localhost를 사용할 수 없으므로 n8n Cloud URL 같은 public HTTPS URL이 필요합니다.
• 공개 Lovable UI는 demo fallback을 사용하지 않습니다. lovable/src/lib/n8n.ts는 VITE_N8N_WEBHOOK_URL만 호출하며, webhook URL 누락, localhost, 네트워크 실패, non-2xx 응답은 hard error로 표시합니다.

메모리 기반 작업 과정

이 repo는 한 번에 새로 만든 산출물이 아니라, 프로젝트 메모리와 실행 로그를 따라 문제를 좁히며 정리한 결과입니다. 핵심 흐름은 docs/trajectory-log.md, evidence/2026-05-23-demo-run.md, Lovable handoff 문서, n8n workflow 백업에 남겨두었습니다.

1. 처음에는 고객 미팅 후속 자동화 형태로 출발했습니다. 이후 프로젝트 메모리와 PRD 정리를 통해 방향을 Execution Memory로 재정의했습니다. 즉, CRM 액션 생성기가 아니라 다음 Agent Run이 이어받을 실행 상태를 남기는 제품으로 좁혔습니다.
2. Lovable 폴더의 최신 wireframe/spec을 기준으로 전면 제품명을 Handoff로 확정했습니다. Execution Memory는 제품 카테고리/문제 정의로 두고, UI에서는 Goal State, Context Used, Execution Requests, Evidence Ledger, Next Action을 중심 언어로 사용합니다.
3. n8n workflow는 기존 sales output 스키마에서 meetingUnderstanding, deliverablePack, executionMemory, harness 네 영역을 반환하는 구조로 바꿨습니다. Upstage는 transcript를 이 실행 상태로 구조화하는 역할을 맡습니다.
4. Lovable UI에서는 open-ended chatbot처럼 보이지 않도록 입력 폼, 런타임 진행 상태, 결과 대시보드, 네 개의 상세 화면, 오류 화면, raw JSON/debug 확인 흐름을 갖춘 업무용 workbench 방향으로 정리했습니다.
5. 실제 병목은 n8n이나 Upstage 스키마가 아니라 브라우저에서 로컬 n8n을 호출하는 노출 계층이었습니다. localhost는 hosted Lovable preview에서 접근할 수 없었고, localtunnel은 HTTP 511 interstitial 문제를 만들었습니다.
6. 최종적으로 Cloudflare Tunnel로 public HTTPS endpoint를 열고, Lovable의 VITE_N8N_WEBHOOK_URL을 production webhook URL로 교체했습니다. 프론트엔드는 URLSearchParams로 POST해 불필요한 CORS preflight를 피하도록 정리했습니다.
7. 현재까지의 검증은 tunnel root HTTP/2 200, production webhook HTTP 200, 응답의 네 영역 존재, JSON parse, Lovable TSX bundle check까지 완료했습니다. 최종 제출용으로는 Lovable 공개 URL에서 debug test, main execution, dashboard, 네 detail screen screenshot을 캡처하면 됩니다.

안전 규칙

• 실제 API key나 고객 데이터는 커밋하지 않습니다.
• 실제 credential은 n8n credentials/env, Lovable environment variables, Supabase project settings, provider console에만 둡니다.
• 이메일 발송, CRM/calendar write, 자동 프로젝트 생성은 초기 데모 범위에서 제외합니다.
• 완료 증거 계약이 충족되기 전까지 이 repo는 최종 완료 상태로 보지 않습니다.

빠른 시작

1. n8n Cloud에서 n8n/workflows/upflow-sales-ops-main.json을 import합니다.
2. n8n Credential에 Upstage API Key를 만듭니다. 타입은 Header Auth, header name은 Authorization, value는 Bearer <UPSTAGE_API_KEY>입니다.
3. workflow의 Upstage Solar Structured Output 노드에 위 credential을 연결합니다.
4. workflow를 Save/Publish 또는 Activate하고 Production Webhook URL을 복사합니다.
5. Lovable에서 lovable/lovable-handoff.md를 기준으로 UI를 생성하거나 업데이트합니다.
6. 기존 Lovable 화면을 업데이트하는 경우 lovable/lovable-wireframe-update-prompt.md를 먼저 붙여넣습니다.
7. Lovable environment variables에 VITE_N8N_WEBHOOK_URL만 설정합니다.
8. 실제 고객 미팅 transcript 또는 업무 요청을 입력해 실행합니다.
9. 결과 증거를 evidence/2026-05-23-demo-run.md에 기록합니다.

상세 배포 절차는 docs/n8n-cloud-setup.md, MCP control-plane 절차는 docs/n8n-mcp-integration.md를 봅니다.

Hosted Lovable preview에서는 localhost webhook URL을 사용하지 않습니다. 아래와 같은 public HTTPS URL 형태를 사용합니다.

VITE_N8N_WEBHOOK_URL=https://YOUR_N8N_CLOUD_SUBDOMAIN.app.n8n.cloud/webhook/upflow

로컬 Vite preview에서만 localhost를 사용할 수 있습니다.

VITE_N8N_WEBHOOK_URL=http://localhost:5678/webhook/upflow

현재 공개 Lovable 앱을 고치려면 Lovable에서 최신 lovable/src/lib/n8n.ts와 lovable/src/components/HandoffDemo.tsx를 반영한 뒤 redeploy합니다. 배포 bundle 안에 localhost:5678 문자열이 남아 있으면 아직 최신 코드가 반영되지 않은 상태입니다.

현재 UI 기준 문서

Lovable 프론트엔드는 아래 파일들을 최신 기준으로 봅니다.

1. lovable/lovable-handoff.md
2. lovable/handoff-landing-core.md
3. lovable/build-prompt.md
4. lovable/wireframe-to-lovable.md
5. lovable/lovable-wireframe-update-prompt.md
6. lovable/feature-spec-for-lovable.md
7. lovable/ui-requirements.md

GitHub

GitHub: chattchatt/upflow