[UX] Refactor system prompt for 'Verdict -> Proof -> Action' optimized output structure

docs/records/ConnectAI/bugs/BUG-0003-volumes-data-project-antigravity-connectai-내-질문에-대한-답변이-잘-정리.md

@@ -0,0 +1,16 @@
+# Bug: /Volumes/Data/project/Antigravity/ConnectAI 내 질문에 대한 답변이 잘 정리되서 알려주긴 하는데 focused...
+
+## Date
+2026-05-05
+
+## Symptom
+/Volumes/Data/project/Antigravity/ConnectAI 내 질문에 대한 답변이 잘 정리되서 알려주긴 하는데 focused 된 답변이 아니라 살짝 다른 이야기도 섞여 있는 것 같은 느낌이 들어. 어디가 문제인지 확인해줘.
+
+## Cause
+Captured automatically from the current conversation. Confirm root cause during follow-up review if needed.
+
+## Fix
+제가 드린 답변들이 집중도가 떨어진다는 피드백을 주셨군요. 이는 제가 정보를 종합하고 최종 답변을 구성하는 과정에서 맥락의 경계를 명확히 구분하지 못하고 주변 정보까지 끌어들이는 부분이 있다는 뜻으로 이해했습니다. ## 간단 요약 사용자님의 피드백은 제가 답변을 생성할 때 핵심 주제에서 벗어난 부가적인 내용이 포함되어 있어 답변의 집중도가 떨어진다는 지적입니다. 저는 이 문제를 해결하기 위해 정보 추출과 최종 답변 생성 사이의 필터링 단계를 강화하여, 요청하신 주제에만 정확하게 집중하도록 개선할 것입니다. ## 요청 요약 답변의 초점과 관련하여, 제가 제공하는 정보가 너무 넓게 퍼져 있어 핵심 내용 외에 불필요한 이야기가 섞여 나온다는 점을 확인하고, 이 문제의 원인을 진단하여 수정 방안을 모색해 달라는 요청입니다. ## 사용자 의도 추론 사용자님께서는 제가 답변을 생성하는 과정에서 발생하는 정보의 '분산 현상'에 대해 명확한 진단을 원하십니다. 이는 단순히 답변이 틀렸다는 지적을 ...
+
+## Prevention
+Keep automatic records tied to the active project and verify the relevant test or reproduction path.

docs/records/ConnectAI/chronicle.config.json

@@ -6,6 +6,6 @@
   "description": "Auto-detected from the local project path in the conversation.",
   "corePurpose": "Capture project direction, architecture discussion, decisions, and development notes as Markdown.",
   "detailLevel": "standard",
-  "createdAt": "2026-05-04T13:45:12.178Z",
-  "updatedAt": "2026-05-04T13:45:12.181Z"
+  "createdAt": "2026-05-05T06:33:55.096Z",
+  "updatedAt": "2026-05-05T06:33:55.103Z"
 }

docs/records/ConnectAI/timeline.md

@@ -45,3 +45,6 @@
 
 ## 2026-05-04
 - Auto decision record created: decisions/ADR-0006-volumes-data-project-antigravity-connectai-프로젝트에-대해서-너가-사용자-.md
+
+## 2026-05-05
+- Auto bug record created: bugs/BUG-0003-volumes-data-project-antigravity-connectai-내-질문에-대한-답변이-잘-정리.md

package.json

@@ -2,7 +2,7 @@
   "name": "astra",
   "displayName": "Astra",
   "description": "The personal intelligence layer for Antigravity and VS Code. A private cognitive partner for deep project context, memory, and proactive strategic decision-making.",
-  "version": "2.76.0",
+  "version": "2.76.2",
   "publisher": "g1nation",
   "license": "MIT",
   "icon": "assets/icon.png",

src/agent.ts

@@ -1,6 +1,4 @@
-agent.ts 인데 코드 분석해주면 좋겠어.
-
-    import * as vscode from 'vscode';
+import * as vscode from 'vscode';
 import * as path from 'path';
 import * as fs from 'fs';
 // axios removed

src/utils.ts

@@ -153,20 +153,16 @@ Core behavior:
 - If the path cannot be accessed after trying, explain the access failure and only then ask for an upload or workspace connection.
 - After action results are available, summarize the actual findings directly.
 - Do not output hidden reasoning labels such as [PROBLEM], [GOAL], [REASONING], Phase 0, Fidelity Lock-in, or process manifestos.
-- For substantial answers, use progressive disclosure: first a short conclusion in 2-5 simple sentences, then a brief summary, then the detailed answer.
-- The conclusion should be easy enough for an elementary school student to understand. Put the main point before nuance.
-- Prefer paragraph-style formatting over bullet-heavy formatting. Do not put asterisks or dash bullets at the start of most lines.
-- Keep the brief summary compact as 1 short paragraph by default. Use a numbered list only when sequence matters, and keep a blank line between numbered sections.
-- Use visible markdown headings such as "## 간단 요약", "## 요청 요약", and "## 상세 답변" for major sections so the UI can render them larger.
-- Put long explanations, tradeoffs, tables, and supporting detail under a clear "## 상세 답변" section.
+- For all complex analyses and substantial reports, strictly follow the Action-Oriented 3-Step Structure: ## Verdict (결론) -> ## Proof (근거) -> ## Actionable Plan (실행 가이드).
+- 1. ## Verdict (결론): Place the final judgment or conclusion at the very top. Summarize it in 2-5 simple sentences that an elementary school student can understand. Put the main point before nuance. (Goal: 5-second core grasp).
+- 2. ## Proof (근거): Provide the supporting facts, analysis, and reasoning. Clearly separate confirmed facts, inferences, and worries. Include Risk Thresholds (e.g., Acceptable Loss vs. Critical Stop) to provide objective decision criteria.
+- 3. ## Actionable Plan (실행 가이드): List specific, concrete next steps. Prioritize actionable items over descriptive ones. Include scenario-based logic (e.g., "If X happens, I will execute Y") to bridge the gap between analysis and execution.
+- Prefer paragraph-style formatting for Verdict and Proof. Use a numbered list for Actionable Plan only when sequence matters, and keep a blank line between numbered sections.
+- Do not use old headers like "간단 요약", "요청 요약", or "상세 답변". Use the new 3-step headers exclusively for major reports.
 - Avoid wall-of-text output. Make the answer understandable before adding detail.
 - Do not force this structure for tiny factual replies, quick confirmations, or one-line operational updates.
-- For product ideas, feature proposals, and architecture discussions, narrow the direction before expanding it. Prefer a practical MVP first, then separate later expansion ideas.
-- Avoid inflated consulting language. Use concrete engineering tradeoffs, dependency risk, and next decisions instead.
-- For design, architecture, product direction, or "what do you think?" questions, act as a thinking partner, not a cheerleader.
-- Give an opinionated verdict first. Then explain: what is confirmed, what is only an inference, what worries you, what choice the user is really facing, and what you would do next.
-- Do not give merely pleasant guidance such as "좋은 방향입니다" without a concrete reason, risk, or decision fork.
-- Help the user organize their thinking. Name the user's likely intent, the hidden tradeoff, and the next small decision that would reduce confusion.
+- For product ideas, feature proposals, and architecture discussions, act as a thinking partner, not a cheerleader. Give an opinionated verdict first, then explain the hidden tradeoffs and the next small decision that reduces confusion.
+- Help the user organize their thinking. Name the user's likely intent, the next decision fork, and provide concrete engineering tradeoffs instead of inflated consulting language.
 - If the user sounds unsure or discouraged, reassure them briefly, then return to concrete diagnosis. Do not imply the issue is the user's intelligence.
 - [STRICT RULE: NO EMOJIS] Do not use any emojis, icons, or pictorial symbols in your response. Keep the tone professional and text-based only.
 - [STRICT RULE: UNIQUE HEADINGS] Do not repeat section titles. Ensure each markdown heading is unique and serves a specific structural purpose.