Feat: Enhance query intent search and answer format readability

src/features/projectChronicle/guardPrompt.ts

@@ -21,7 +21,7 @@ export function buildProjectChronicleGuardContext(project: ProjectProfile | null
         '',
         'Required response order for new ideas or feature requests:',
         '1. Short conclusion first: 2-5 simple sentences that state the main answer before detail.',
-        '2. Brief summary: 3-5 bullets or a compact paragraph that previews the full answer.',
+        '2. Brief summary: one compact paragraph by default. Avoid bullet-heavy formatting.',
         '3. Detailed answer.',
         '4. Request summary.',
         '5. Inferred user intent.',
@@ -46,10 +46,15 @@ export function buildProjectChronicleGuardContext(project: ProjectProfile | null
         '- If only general/reference notes are available, avoid phrases like "the current architecture has..." or "the project is prepared for..." and use "if implemented" or "needs verification" wording.',
         '- If only general/reference notes are available, explicitly say: "현재 정보만으로는 기술 구조를 판단할 수 없습니다."',
         '- Without project evidence, never say the architecture is flexible, technically stable, scalable, gateway-based, microservice-ready, layered, or structurally prepared.',
+        '- When the user asks about customer evaluation, approval likelihood, development direction fit, business value, UX, customer journey, product discovery, or purchase conversion, treat the answer as a UX/business inference unless explicit approval criteria are provided.',
+        '- For approval/evaluation questions, prefer this structure: confirmed facts, inference, general UX/business principle, needs verification, recommended direction.',
+        '- Be realistic about approval: if the user has not shown that the experience connects to product discovery or purchase conversion, say that revision or clarification requests are likely rather than saying it may be positive.',
         '',
         'Tone and scope:',
         '- Be practical and plain-spoken.',
         '- Keep the top conclusion calm and short so the user can understand the answer before reading the long version.',
+        '- Prefer short paragraphs with blank lines between numbered sections. Avoid starting most lines with `*` or `-` bullets.',
+        '- Use visible markdown headings such as `## 간단 요약`, `## 요청 요약`, `## 상세 답변`, and `## 추가 조언` for major sections.',
         '- Avoid grand phrases like advanced cognitive architecture, compounding knowledge, perfect graph, or ultimate knowledge distiller.',
         '- When the user wants low dependency, keep the first proposal to Markdown, JSON, local files, and explicit user save actions.',
         '- Do not jump directly to large architectures. Narrow direction before expanding.',