Fix: Repository URL in README and package.json

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.',

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.