diff --git a/PATCHNOTES.md b/PATCHNOTES.md
index ec2adfe..15a4ff7 100644
--- a/PATCHNOTES.md
+++ b/PATCHNOTES.md
@@ -1,3 +1,10 @@
+# Patch Notes - v2.36.2 (2026-05-02)
+
+## 📝 Documentation Fix
+- **Repository URL Correction:** Fixed incorrect GitHub repository URLs in `README.md` and `package.json` to point to the authoritative `g1nations/locallm` repository.
+
+---
+
 # Patch Notes - v2.36.1 (2026-05-02)
 
 ## 🛠️ Stability & Refinement
diff --git a/README.md b/README.md
index 245a552..3bd08e7 100644
--- a/README.md
+++ b/README.md
@@ -34,7 +34,7 @@ NumPy 기반의 행렬 연산을 활용하여 기존의 반복문 기반 검색
 
 ### 소스 빌드 환경
 ```bash
-git clone https://github.com/wonseokjung/connect-ai.git
+git clone https://github.com/g1nations/locallm.git
 cd connect-ai
 npm install
 npm run compile
diff --git a/docs/records/ConnectAI/development/2026-05-02_progressive-answer-format.md b/docs/records/ConnectAI/development/2026-05-02_progressive-answer-format.md
new file mode 100644
index 0000000..ec77fdc
--- /dev/null
+++ b/docs/records/ConnectAI/development/2026-05-02_progressive-answer-format.md
@@ -0,0 +1,29 @@
+# Development Log: Progressive Answer Format
+
+## Purpose
+Reduce reading burden for long answers by putting the main point before detailed explanation.
+
+## User Intent
+The user likes the content quality but feels rushed or overwhelmed when the answer starts with a long detailed explanation. They want the answer to first provide a simple conclusion, then a short summary, then the detailed answer.
+
+## Implementation Summary
+- Added progressive disclosure guidance to the base system prompt.
+- Updated Chronicle Guard prompt order so idea, planning, architecture, and feature answers start with:
+  1. Short conclusion
+  2. Brief summary
+  3. Detailed answer
+- Kept the rule scoped to substantial answers so tiny replies do not become overly structured.
+- Added tests to lock the Guard prompt structure.
+
+## Changed Files
+- `src/utils.ts`
+- `src/features/projectChronicle/guardPrompt.ts`
+- `tests/projectChronicleGuardPrompt.test.ts`
+
+## Verification
+- `./node_modules/.bin/tsc --noEmit`
+- `npm run compile`
+- `./node_modules/.bin/jest --runInBand`
+
+## Result
+Long answers should now be easier to enter: the user can understand the answer from the top section, then read details only if needed.
diff --git a/docs/records/ConnectAI/timeline.md b/docs/records/ConnectAI/timeline.md
index f67474a..88d4a89 100644
--- a/docs/records/ConnectAI/timeline.md
+++ b/docs/records/ConnectAI/timeline.md
@@ -14,3 +14,4 @@
 - Improved Second Brain Trace output with a collapsed-by-default details section to reduce answer noise.
 - Tuned Second Brain Trace retrieval quality: raw notes are excluded by default, curated records are preferred, and trace wording now says selected context rather than overstating actual usage.
 - Removed hard-coded local template replies for Second Brain overview and unproductive-response correction.
+- Added progressive answer format guidance: short conclusion first, brief summary second, detailed answer third.
diff --git a/package.json b/package.json
index e484e26..f5a2ab2 100644
--- a/package.json
+++ b/package.json
@@ -2,13 +2,13 @@
   "name": "g1nation",
   "displayName": "G1nation",
   "description": "High-performance autonomous local AI coding agent for VS Code. Features vectorized inference, asynchronous task management, and 100% offline processing.",
-  "version": "2.36.1",
+  "version": "2.36.2",
   "publisher": "connectailab",
   "license": "MIT",
   "icon": "assets/icon.png",
   "repository": {
     "type": "git",
-    "url": "https://github.com/wonseokjung/connect-ai"
+    "url": "https://github.com/g1nations/locallm"
   },
   "engines": {
     "vscode": "^1.80.0"
diff --git a/src/features/projectChronicle/guardPrompt.ts b/src/features/projectChronicle/guardPrompt.ts
index c1d21e4..14c3bd7 100644
--- a/src/features/projectChronicle/guardPrompt.ts
+++ b/src/features/projectChronicle/guardPrompt.ts
@@ -20,16 +20,19 @@ export function buildProjectChronicleGuardContext(project: ProjectProfile | null
         'This guard is active for project ideas, feature requests, architecture proposals, implementation planning, and design decisions.',
         '',
         'Required response order for new ideas or feature requests:',
-        '1. Request summary.',
-        '2. Inferred user intent.',
-        '3. Project record target check. If no project is selected, ask whether to use an existing project, create a new project, or skip recording.',
-        '4. Record path check. If no record root is available, say a Markdown record path is required before writing files.',
-        '5. Ask only 1 to 3 blocking questions.',
-        '6. For every question, include "Question reason" explaining why it changes storage, scope, dependencies, or implementation direction.',
-        '7. Direction review focused on project fit and dependency risk.',
-        '8. Recommend a low-dependency MVP first.',
-        '9. Put Vector DB, relational DB, knowledge graph, semantic search, and complex automation only under "Later expansion" unless the user explicitly asks for them now.',
-        '10. End with "Candidate records for this discussion" and list planning, discussions, decisions, development, bugs, or retrospectives paths as candidates.',
+        '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.',
+        '3. Detailed answer.',
+        '4. Request summary.',
+        '5. Inferred user intent.',
+        '6. Project record target check. If no project is selected, ask whether to use an existing project, create a new project, or skip recording.',
+        '7. Record path check. If no record root is available, say a Markdown record path is required before writing files.',
+        '8. Ask only 1 to 3 blocking questions.',
+        '9. For every question, include "Question reason" explaining why it changes storage, scope, dependencies, or implementation direction.',
+        '10. Direction review focused on project fit and dependency risk.',
+        '11. Recommend a low-dependency MVP first.',
+        '12. Put Vector DB, relational DB, knowledge graph, semantic search, and complex automation only under "Later expansion" unless the user explicitly asks for them now.',
+        '13. End with "Candidate records for this discussion" and list planning, discussions, decisions, development, bugs, or retrospectives paths as candidates.',
         '',
         'Decision policy:',
         '- Do not mark a decision as accepted until the user confirms it.',
@@ -38,6 +41,7 @@ export function buildProjectChronicleGuardContext(project: ProjectProfile | null
         '',
         '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.',
         '- 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.',
diff --git a/src/utils.ts b/src/utils.ts
index 16142f2..6b343ef 100644
--- a/src/utils.ts
+++ b/src/utils.ts
@@ -148,8 +148,12 @@ Core behavior:
 - For local file, folder, code, project, or terminal work, use action tags so the extension can execute the operation.
 - 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, write readable Markdown using ## and ### headings, short paragraphs, bullets, and tables where useful.
-- Avoid wall-of-text output. Make the answer scannable before adding detail.
+- 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.
+- Keep the brief summary compact: 3-5 bullets or a short paragraph.
+- Put long explanations, tradeoffs, tables, and supporting detail under a clear "Detailed Answer" section.
+- 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.
 - Do not use grand labels like "final execution mandate", "engineering standard", "knowledge distiller", or "Antigravity's yardstick" unless the user explicitly asks for that style.
diff --git a/tests/projectChronicleGuardPrompt.test.ts b/tests/projectChronicleGuardPrompt.test.ts
index 8e9ad15..bcab8e3 100644
--- a/tests/projectChronicleGuardPrompt.test.ts
+++ b/tests/projectChronicleGuardPrompt.test.ts
@@ -17,6 +17,9 @@ describe('buildProjectChronicleGuardContext', () => {
         const context = buildProjectChronicleGuardContext(profile);
 
         expect(context).toContain('Project selection status: selected');
+        expect(context).toContain('Short conclusion first');
+        expect(context).toContain('Brief summary');
+        expect(context).toContain('Detailed answer');
         expect(context).toContain('Project record target check');
         expect(context).toContain('Record path check');
         expect(context).toContain('Question reason');