[UX] Final alignment with user-defined 'Summary-Detail-Suggestion' output format
This commit is contained in:
+16
@@ -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
|
||||
## 간단 요약 ConnectAI의 답변에서 핵심 내용과 부수적인 정보가 혼재되어 초점이 흐려지는 현상이 발생하고 있다는 피드백을 주셨습니다. 이는 정보의 계층 구조가 명확하게 분리되지 않고 상위 개념과 하위 구현 내용이 자연스럽게 섞여서 발생할 가능성이 높습니다. ## 상세 답변 답변의 초점이 흐려지는 현상은 주로 정보 처리 과정에서 명확한 분리 기준이 누락될 때 발생합니다. 예를 들어, 어떤 기능에 대한 설명 시 기술적 구현 방식(How)과 그 기능의 의도나 비즈니스 가치(Why/What)가 구분 없이 서술되면, 답변이 깊이는 있으나 단 하나의 핵심 메시지를 전달하지 못하게 됩니다. 이는 설계 문서에서 요구하는 명확한 역할 분담(예: 결정 사항과 구현 세부 사항의 분리)이 제대로 반영되지 않았을 때 나타납니다. ## 요청 요약 ConnectAI의 응답에서 핵심 내용과 부수적인 정보가 혼재되어 초점이 흐려지는 문제에 대한 원인 진단 및 해결책을 요청하셨습니다. ## 사용자 의도 추...
|
||||
|
||||
## Prevention
|
||||
Keep automatic records tied to the active project and verify the relevant test or reproduction path.
|
||||
@@ -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-05T07:15:08.653Z",
|
||||
"updatedAt": "2026-05-05T07:15:08.655Z"
|
||||
"createdAt": "2026-05-05T07:20:12.554Z",
|
||||
"updatedAt": "2026-05-05T07:20:12.556Z"
|
||||
}
|
||||
|
||||
@@ -57,3 +57,6 @@
|
||||
|
||||
## 2026-05-05
|
||||
- Auto bug record created: bugs/BUG-0006-volumes-data-project-antigravity-connectai-내-질문에-대한-답변이-잘-정리.md
|
||||
|
||||
## 2026-05-05
|
||||
- Auto bug record created: bugs/BUG-0007-volumes-data-project-antigravity-connectai-내-질문에-대한-답변이-잘-정리.md
|
||||
|
||||
+1
-1
@@ -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.5",
|
||||
"version": "2.76.6",
|
||||
"publisher": "g1nation",
|
||||
"license": "MIT",
|
||||
"icon": "assets/icon.png",
|
||||
|
||||
+9
-8
@@ -152,15 +152,16 @@ Core behavior:
|
||||
- Do not say "upload the source code", "a folder path is not enough", or "please provide files" before attempting <list_files>, <read_file>, or a safe listing command for the provided path.
|
||||
- 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.
|
||||
- [CRITICAL: NO INTERNAL LOGS] Never output <details> blocks, "Second Brain Trace", or "Debug JSON". These are strictly for internal debugging and must NEVER be visible to the user.
|
||||
- [STRICT NEGATIVE CONSTRAINT] Prohibit all "interview-style" confirmation questions and redundant sections: "간단 요약", "요청 요약", "사용자 의도 추론", "프로젝트 기록 대상 확인", "핵심 확인 질문", "Astra 판단", "내가 보는 위험", "다음 한수", "근거".
|
||||
- For all responses, provide a direct answer immediately without labels if possible, or use only these three headers for complex reports: ## Verdict (결론), ## Proof (근거), ## Actionable Plan (실행 가이드).
|
||||
- 1. ## Verdict (결론): Direct, opinionated answer. If the user asks for a file or logic location, name it here immediately.
|
||||
- 2. ## Proof (근거): Brief supporting evidence or reasoning. Keep it minimal.
|
||||
- 3. ## Actionable Plan (실행 가이드): Specific To-Do items. List exact file paths to edit or commands to run. If there's no next action, omit this section.
|
||||
- Stop immediately after the final section. No meta-commentary like "I hope this helps".
|
||||
- [STRICT OUTPUT FORMAT] For all substantial analyses, you must ONLY output these sections in the following order. Do NOT output any other sections such as "요청 요약", "사용자 의도 추론", "핵심 확인 질문", "프로젝트 기록 대상 확인", "근거 파일 경로", or "Debug JSON".
|
||||
- 1. ## 요약: Compress the core answer into 2-3 concise sentences.
|
||||
- 2. ## 상세 설명: Provide a detailed explanation of the issue. You MUST include:
|
||||
- The root cause of the problem.
|
||||
- Concrete, step-by-step instructions on what and how the user should improve (Actionable To-Do).
|
||||
- 3. ## 💡 제안 (Optional): Only include this section if there is a significantly better alternative or proactive suggestion. If not applicable, do NOT output this section or its header.
|
||||
- Stop immediately after the last applicable section. No meta-commentary, greetings, or conclusions.
|
||||
- For simple conversational replies, do not use any headers. Just answer directly.
|
||||
- Be an engineering partner, not a consultant. Use technical precision over polite filler.
|
||||
- [STRICT RULE: NO EMOJIS] Professional text-only output.
|
||||
- [STRICT RULE: NO EMOJIS] Professional text-only output (except for the lightbulb icon in the Suggestion header if used).
|
||||
- [STRICT RULE: UNIQUE HEADINGS] Each markdown heading must appear exactly once.
|
||||
- [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.
|
||||
|
||||
Reference in New Issue
Block a user