Claude Code से ब्यूटी और वेलनेस प्रारंभिक फॉर्म जांच: सहमति और जोखिम संकेत रोकें

पहली विजिट के फॉर्म में “त्वचा संवेदनशील है”, “गर्भावस्था है” या “दवा चल रही है” लिखा है, लेकिन CSV निर्यात में वह सब एक सामान्य टिप्पणी कॉलम में छिप जाता है। बुकिंग स्वीकार हो चुकी है, ग्राहक आ चुका है, और स्टाफ को उसी समय पता चलता है कि सेवा रोकनी है, मेनू बदलना है, रद्दीकरण नियम समझाना है या समय बदलना है। ब्यूटी सैलून, वेलनेस स्टूडियो, रिलैक्सेशन सेवा और व्यक्तिगत प्रशिक्षण trial में यह छोटा इनपुट दोष नई landing page से पहले ठीक होना चाहिए।

फॉर्म को बहुत लंबा बनाना समाधान नहीं है। बहुत प्रश्न भरने वाले को बीच में रोकते हैं, और डेटा इकट्ठा करके समीक्षक तय न करना नया जोखिम बनाता है। व्यावहारिक लक्ष्य यह है कि AI समीक्षा से पहले बुकिंग के कॉलम, सहमति के कॉलम, जोखिम संकेतों की श्रेणियां और केवल स्टाफ के लिए रखी गई जानकारी अलग हो। यहां जोखिम संकेत से आशय स्वास्थ्य स्थिति, दवा, गर्भावस्था, त्वचा की स्थिति या उम्र जैसे बिंदु हैं, जिनसे सेवा जारी रखने का निर्णय बदल सकता है।

यह लेख Claude Code के साथ ब्यूटी और वेलनेस प्रारंभिक फॉर्म की स्थानीय preflight जांच बनाता है। शीर्षक live integration का दावा नहीं करता; यह भेजने से पहले स्थानीय अनुबंध जांच है। यह फॉर्म सेवा, बुकिंग सिस्टम, ग्राहक डेटाबेस या ईमेल भेजने वाली सेवा से नहीं जुड़ता। वर्तमान दावों के लिए आधिकारिक स्रोत देखे गए: Claude Code permissions, Claude Code settings and sandboxing, जापान PPC की व्यक्तिगत जानकारी सामग्री, जापान MHLW की ब्यूटी प्रतिष्ठान स्वच्छता सामग्री, और जापान Consumer Affairs Agency की beauty-medical सावधानी पेज। यह व्यक्तिगत कानूनी, चिकित्सकीय या संचालन सलाह नहीं है।

मुख्य बातें

• पहली विजिट के फॉर्म को बुकिंग कॉलम, स्टाफ समीक्षा कॉलम और AI कार्य CSV से बाहर रहने वाले कॉलम में बांटें।
• Claude Code को सिर्फ काल्पनिक या छिपाए गए CSV पढ़ने दें, ताकि सहमति, जोखिम संकेत, समीक्षा flag और संदेश जांचे जा सकें।
• सेवा योग्यता, स्वास्थ्य सूचना, सहमति की भाषा, व्यक्तिगत डेटा, नाबालिग सहमति, refund और cancellation का निर्णय इंसान करे।
• तीन Use case हैं: फॉर्म कॉलम सूची, CSV preflight, और स्टाफ पुष्टि संदेश का मसौदा।
• मुख्य CTA केवल दोबारा उपयोग होने वाले शुरुआती ढांचे के लिए product templates है।

Workflow: AI से पहले form अलग करना

सबसे पहले folder और record अलग करें। intake-raw/ में मूल जानकारी रहती है: नाम, फोन, ईमेल, त्वचा या शरीर की स्वतंत्र टिप्पणी, दवा, गर्भावस्था, नाबालिग सहमति, फोटो अनुमति और भुगतान से जुड़ा संदर्भ। intake-ai-work/ में AI कार्य प्रति रहती है: काल्पनिक ID, मांगा गया मेनू, आने का उद्देश्य, सहमति स्थिति, जोखिम श्रेणी और स्टाफ समीक्षा की जरूरत। intake-approved/ में स्टाफ से स्वीकृत checklist और संदेश रहता है।

सामग्री	AI कार्य प्रति	केवल स्टाफ के लिए
बुकिंग फॉर्म	मांगा गया मेनू, आने का उद्देश्य, पहली या दोबारा विजिट	नाम, फोन, ईमेल, पता
प्रारंभिक प्रश्न	जोखिम श्रेणी, सावधानी श्रेणी	निदान, दवा का नाम, विस्तृत स्वास्थ्य स्थिति
सहमति पाठ	सहमति है या नहीं, तारीख, जरूरी या वैकल्पिक	अंतिम कानूनी और संचालन भाषा
CSV निर्यात	कॉलम नाम, खाली जगह, स्टाफ समीक्षा flag	पहचान योग्य डेटा और मूल स्वतंत्र पाठ
स्टाफ checklist	समीक्षक, रोकने की शर्त, समय	सेवा योग्यता, मेनू बदलाव, refund निर्णय

flowchart TD
  A[intake-raw originals] --> B[Classify columns]
  B --> C[Redact into AI CSV]
  C --> D[Node.js preflight]
  D --> E[Claude Code gap review]
  E --> F[Staff review]
  F --> G[intake-approved checklist]

मुख्य आदत यह है कि Claude Code से “सब पढ़कर फैसला करो” न कहें। पहले कॉलम घटाएं। स्वतंत्र पाठ वाली प्रारंभिक टिप्पणियों में नाम, स्वास्थ्य विवरण और परिवार से जुड़ी जानकारी आ सकती है, इसलिए AI फाइल में sensitive_note_present: true जैसा flag बेहतर है। निर्णय चाहिए तो स्टाफ मूल रिकॉर्ड अलग से खोले।

Claude Code क्या संभाले और इंसान क्या तय करे

Claude Code छूटे हुए फॉर्म कॉलम, जोखिम भरे CSV कॉलम नाम, छूटे हुए सहमति flag, छूटे हुए स्टाफ समीक्षा flag और स्टाफ या ग्राहक के लिए संदेश मसौदा संभाल सकता है। उदाहरण: “क्या पहली विजिट के फॉर्म में फोटो अनुमति और रद्दीकरण सहमति है?” या “क्या जोखिम श्रेणी वाली हर पंक्ति में staff_review है?”।

इंसान तय करता है कि सेवा आगे बढ़ेगी या नहीं, कौन सा मेनू बदलेगा, स्वास्थ्य या दवा संबंधी टिप्पणी कैसे संभाली जाएगी, नाबालिग सहमति, refund, cancellation, विज्ञापन भाषा और व्यक्तिगत डेटा कैसे संभलेगा। Claude Code का “no obvious gap” सेवा स्वीकृति नहीं है। ब्यूटी और वेलनेस में आश्वस्त करने वाली भाषा आसानी से बढ़ा-चढ़ाकर किए गए दावे में बदल सकती है, इसलिए अंतिम मंजूरी इंसान के पास रहती है।

Claude Code permissions दस्तावेज बताता है कि नियम deny, ask, allow क्रम में देखे जाते हैं। settings पेज sandbox को Bash commands और child processes के file system तथा network सीमा के रूप में समझाता है। intake originals के लिए Read(/intake-raw/**) deny करें और सिर्फ intake-ai-work/ allow करें। यह privacy safety का proof नहीं, बल्कि गलती की entry को छोटा करने वाला guard है।

संबंधित पढ़ाई के लिए Claude Code permissions guide और beauty salon menu workflow उपयोगी हैं। फॉर्म और मेनू अलग जांचे जाने चाहिए, क्योंकि उनके टूटने की जगह अलग होती है।

तीन Use Case

Use case 1: first-visit form fields inventory करना

Input: फॉर्म कॉलम सूची, जरूरी या वैकल्पिक सेटिंग, मांगा गया मेनू, सहमति पाठ, फोटो अनुमति, cancellation conditions, और staff review वाली questions.

Output: बुकिंग कॉलम, स्टाफ समीक्षा कॉलम, AI से बाहर कॉलम, पहली विजिट की छोटी व्याख्या, और भेजने के बाद चेतावनी संदेश.

Human review: सेवा योग्यता, जोखिम संकेत का व्यवहार, नाबालिग सहमति, फोटो अनुमति, cancellation/refund conditions, और अंतिम सहमति भाषा.

inventory की शुरुआत यह तय करने से होती है कि क्या हटाना है। अगर trial form का काम सिर्फ slot reserve करना है, detailed health questions staff follow-up में जा सकते हैं। अगर कोई condition service से पहले हमेशा देखनी है, तो guest आने से पहले review flag चाहिए।

Use case 2: CSV में risky fields मिल रहे हैं या नहीं देखना

Input: redacted CSV column names, sample rows, required columns, staff-review flag, pre-send rules.

Output: अनुमति वाले कॉलम, रोके गए कॉलम, खाली मान की चेतावनी, staff_review वाली पंक्तियां, और मूल फील्ड जिन्हें स्टाफ देखे।

Human review: नाम, फोन, ईमेल, पता, मूल स्वतंत्र पाठ, दवा, निदान, गर्भावस्था, नाबालिग स्थिति, सहमति, फोटो अनुमति.

CSV निर्यात फॉर्म स्क्रीन से ज्यादा चुपचाप गलती छिपाता है। साफ दिखने वाला label निर्यात में एक note कॉलम बन सकता है। Claude Code से पहले स्थानीय जांच जोखिम वाले नाम और सरल जोखिम वाले मान रोकती है।

Use case 3: staff confirmation message draft करना

Input: काल्पनिक ID, मांगा गया मेनू, समीक्षा श्रेणी, appointment date band, staff owner, reply deadline, और दुकान का संपर्क channel.

Output: स्टाफ पुष्टि ईमेल, ग्राहक के लिए विजिट से पहले संदेश, review checklist, और वह जानकारी जो भेजनी नहीं है।

Human review: प्राप्तकर्ता, ग्राहक नाम, वास्तविक स्वास्थ्य विवरण, सेवा निर्णय, cancellation conditions, refund guidance, manager approval.

AI से वास्तविक व्यक्तिगत जानकारी न भरवाएं। “guest A” या “booking B-001” से मसौदा बनाएं, फिर स्टाफ मूल रिकॉर्ड देखकर भेजे। विनम्र भाषा उपयोगी है, लेकिन निर्णय सीमा साफ रहनी चाहिए।

Copy-Paste Prompt

यह prompt केवल intake-ai-work/intake-redacted.csv बनने के बाद चलाएं। मूल फॉर्म, customer records, charts, photos या payment data न जोड़ें।

Act as a beauty and wellness first-visit intake form reviewer.
Read only ./intake-ai-work/intake-redacted.csv and output in this order:

1. Columns that may be used by AI and columns that must be stopped
2. Missing consent, photo permission, and cancellation fields
3. Whether rows with contraindication categories have staff_review
4. Fields staff must check in the original record
5. Draft pre-visit confirmation message to the guest
6. Pre-publication checklist

Constraints:
- Do not decide service eligibility, medical issues, or refunds
- Do not infer name, phone, email, address, diagnosis, medication, pregnancy week, or raw free-text notes
- Do not touch intake-raw, customer databases, booking systems, email sending, or external networks
- If you detect personal-data-like values, stop and report only the field name
- End with: "Not sendable before staff review"

Working Check Code

अगर यह helper जोड़ें, तो path tools/check-beauty-intake-preflight.mjs है। यह लेख repository में file create नहीं करता। पूरा content नीचे है और test सिर्फ काल्पनिक local fixtures पर है।

const files = [
  {
    path: "intake-ai-work/intake-redacted.csv",
    text: "intake_id,menu,consent,contraindication_category,staff_review\nB-001,trial_facial,true,sensitive_skin,true"
  },
  {
    path: "intake-ai-work/bad.csv",
    text: "name,email,medication_note\nAiko,[email protected],blood pressure medicine"
  }
];

const blockedFields = [
  "name",
  "email",
  "phone",
  "address",
  "birthdate",
  "medication",
  "diagnosis",
  "pregnancy_week",
  "free_note"
];

const valuePatterns = [
  /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/,
  /\b\d{2,4}-\d{2,4}-\d{3,4}\b/,
  /\b(?:medicine|diagnosis|pregnant|allergy)\b/i
];

const findings = [];

for (const file of files) {
  const lowerText = file.text.toLowerCase();
  for (const field of blockedFields) {
    if (lowerText.includes(field)) {
      findings.push({ path: file.path, type: "blocked field", field });
    }
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) {
      findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
    }
  }
}

console.table(findings);
if (findings.length > 0) {
  process.exitCode = 1;
}

यह code सिर्फ यह साबित करता है कि स्थानीय fixed fixtures जोखिम वाले field names और सरल values पहचानते हैं। यह PDF, image, handwriting, कई कॉलम से दोबारा पहचान, live form integration या booking-system behavior साबित नहीं करता।

{
  "permissions": {
    "deny": [
      "Read(/intake-raw/**)",
      "Edit(/intake-raw/**)",
      "Read(/customer-records/**)",
      "Edit(/customer-records/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/intake-ai-work/**)",
      "Edit(/intake-ai-work/**)",
      "Bash(node tools/check-beauty-intake-preflight.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./intake-raw", "./customer-records"],
      "denyWrite": ["./intake-raw", "./customer-records"]
    }
  }
}

Pitfall: सामान्य कारण और सुधार

पहला कारण सहमति को आखिरी छोटी checkbox बनाना है। ग्राहक नहीं समझता कि किस बात पर सहमति दी, और स्टाफ पाठ का update trace नहीं कर पाता। सुधार: photo permission, cancellation, health confirmation और contact method अलग करें, फिर consent version या update date export करें।

दूसरा कारण जोखिम संकेत को सिर्फ स्वतंत्र पाठ में लेना है। स्वतंत्र पाठ लचीला लगता है, पर खोज मुश्किल है और AI के लिए risky है। सुधार: category fields और staff_review flag रखें, details original में रहने दें।

तीसरा कारण Read deny को पर्याप्त मानना है। Bash, child processes और स्थानीय helpers originals तक दूसरा रास्ता खोल सकते हैं। सुधार: Claude Code deny, sandbox denyRead और denyWrite, folder operation और काल्पनिक rejection tests को साथ लगाएं।

चौथा कारण validator को वास्तविक booking CSV पर test करना है। terminal history और logs values रख सकते हैं। सुधार: allow और reject samples काल्पनिक IDs से बनाएं, production logs में personal values print न करें।

छोटा ROI measurement

पहले दो सप्ताह सिर्फ पहली trial intake form मापें। बदलाव से पहले booking के बाद पुष्टि कॉल, उसी दिन मेनू बदलाव, सहमति समझाने पर रुके मामले, और staff द्वारा original दुबारा खोलने की गिनती लिखें। बदलाव के बाद वही संख्या लिखें और preflight द्वारा रोकी गई पंक्तियां जोड़ें।

गणना सरल हो सकती है: cases × (confirmation minutes + same-day rework minutes) के साथ preflight stops. bookings बढ़ें लेकिन same-day changes भी बढ़ें, तो form expectations align नहीं कर रहा। विजिट से पहले confirmations बढ़ें और उसी दिन cancellations घटें, तो workflow उपयोगी हो सकता है। results invent न करें; same period में same fields compare करें।

अक्सर पूछे जाने वाले सवाल

Q. क्या health या medication questions हटाना ज्यादा safe है?

नहीं। जरूरी service checks हटाने से operational risk बढ़ सकता है। लक्ष्य AI को कम fields देना और staff review fields बचाना है।

Q. क्या Claude Code permissions personal data handling के लिए काफी हैं?

अकेले नहीं। permissions tool boundaries बनाते हैं। sandboxing, folder separation, value-free logs और staff review भी जोड़ें।

Q. क्या Claude Code beauty-medical जैसे claims सुधार सकता है?

वह warning और review notes का मसौदा बना सकता है, पर medical advertising और legal review इस लेख से बाहर हैं। effect claims को official sources और shop rules से इंसान check करे।

Q. किस form से शुरू करें?

जहां first trial, photo permission, cancellation terms और health confirmation एक ही screen में मिलते हों, वहां से शुरू करें। सबसे ज्यादा same-day questions वाला form, highest traffic वाले form से बेहतर पहला लक्ष्य है।

Product Templates

यह preflight छोटा शुरुआती अभ्यास बन सकता है। काल्पनिक CSV बनाएं, देखें जोखिम वाले columns process रोकते हैं या नहीं, missing staff_review दिखता है या नहीं, और output staff review से पहले sendable नहीं कहता या नहीं।

इसी pattern को menu explanations, FAQ, reply drafts और publication checks में reuse करना हो तो product templates को एकमात्र अगला कदम रखें। संबंधित beauty salon menu workflow price और duration clarity संभालता है, और permissions guide access-control basics संभालता है।

वास्तव में क्या test किया गया

इस लेख में मैंने confirm किया कि /images/hero/hero-024.webp file site/public/images/hero/hero-024.webp में मौजूद है। official Claude Code permissions page, settings and sandbox page, Japan PPC personal information page, MHLW hygiene guidance और consumer agency beauty-medical caution page भी check किए गए।

JavaScript block काल्पनिक intake-ai-work/intake-redacted.csv और intake-ai-work/bad.csv को memory arrays की तरह दिखाता है। यह सिर्फ field names और simple values की स्थानीय fixture सीमा दिखाता है। form service, booking system, customer database, email sender या real customer data runtime test नहीं चलाया गया। publication checks इस slug, frontmatter, internal links, external links, CTA, code fences, ten locale files और Qiita article को target करेंगे।