// AUTO-GENERATED by scripts/gen-static-assets.ts — DO NOT EDIT.
// Run `npm run codegen` to regenerate.
//
// Package-owned markdown assets bundled into code for the Bun-compiled
// binary path. These files live under `src/` in the repo, but the compiled
// binary cannot rely on runtime filesystem reads inside `/$bunfs/`.

export const BUNDLED_PROMPTS: Readonly<Record<string, string>> = {
  "canopy-describe": "You write one-sentence summaries of source files for a code intelligence system.\n\nGiven the file metadata below, respond with a single sentence describing\nwhat the file's purpose is at the architectural level. Do not describe\nsyntax or structure already visible in the exports list.\n\nRules:\n- Exactly one sentence.\n- Maximum {{budget}} characters.\n- No markdown, no quotes, no preamble.\n- If the file is configuration, generated, or trivial, say so.\n\nFile: {{path}}\nLanguage: {{language}}\nExports: {{exports}}\nImports: {{imports}}\nTop comment: {{top_comment}}\n\nFirst {{first_n}} lines:\n{{first_lines}}\n",
  "consolidation": "You are consolidating related observations from a knowledge vault into a single comprehensive note.\nYou have a budget of ~{{maxTokens}} tokens for your response.\n\nThese {{count}} observations are all of type \"{{observation_type}}\" and were found to be semantically similar.\n\nYour task: decide whether they should be consolidated into one note, or kept separate.\n\n## Default: consolidate\n\nThese observations were grouped because they are semantically similar. The default action is to consolidate them. Only decline if you have a strong reason.\n\nMultiple observations about the same technology, system, component, or concept SHOULD be consolidated — even if they describe different aspects, failure modes, or angles. A single comprehensive reference is more valuable than scattered fragments.\n\nExamples that SHOULD consolidate:\n- 3 gotchas about SQLite WAL mode (shared memory, writer locks, checkpoint blocking) → one \"SQLite WAL Operational Constraints\" note\n- 4 trade-offs about CI/CD pipelines (caching, versioning, Docker, commits) → one \"CI/CD Pipeline Trade-offs\" note\n- 3 decisions about the same authentication system → one \"Authentication Design Decisions\" note\n\n## When NOT to consolidate\n\nOnly decline when observations are about genuinely unrelated topics that happen to share a type:\n- A decision about database choice + a decision about UI framework + a decision about error handling → these are about completely different systems\n- A gotcha about SQLite + a gotcha about Docker networking → unrelated technologies\n\nThe key test: would a reader looking up one of these topics benefit from seeing the others in the same note? If yes, consolidate.\n\n## Critical rules\n\n- PRESERVE specific details from each source: file names, error messages, function names, concrete values\n- A synthesis that generalizes away specifics is WORSE than the original observations\n- Include ALL relevant source IDs in source_ids — no hallucinated IDs, no omissions\n- source_ids must be a subset of the IDs shown below\n- If only some observations belong together, consolidate the related subset and exclude the unrelated ones\n- Wisdom notes should be COMPREHENSIVE but not redundant — include all distinct insights, specifics, and actionable details from the sources, but don't repeat the same point in different words\n\n## Observations\n\n{{candidates}}\n\n---\n\nRespond with JSON only. Two valid formats:\n\nIf they should NOT be consolidated:\n{\"consolidate\": false, \"reason\": \"brief explanation\"}\n\nIf they SHOULD be consolidated:\n{\"consolidate\": true, \"title\": \"Concise title for the wisdom note\", \"content\": \"Full markdown content synthesizing all observations. Preserve specifics.\", \"source_ids\": [\"id-1\", \"id-2\", \"id-3\"], \"tags\": [\"tag1\", \"tag2\"]}\n",
  "digest-10000": "Budget: ~10,000 tokens. Use the FULL budget — this is the institutional knowledge tier.\n\nThis is the complete project context — an agent reading this should have the equivalent of MONTHS of project history and team knowledge. It should be able to make architectural decisions, understand why any part of the system exists, trace the evolution of features, and anticipate risks that aren't obvious from the current code.\n\nThis tier exists for complex work: major refactors, architectural reviews, onboarding new team members, or debugging systemic issues where understanding history matters.\n\n## Required Sections\n\n### Project Identity & Vision (~500 tokens)\nWhat is this project? What problem does it solve? Who uses it and how? What's the long-term vision? What makes it unique? Ground the agent in purpose so it can evaluate whether proposed changes serve the project's goals.\n\n### Architecture Deep Dive (~1,000 tokens)\nHow the system fits together — subsystems, data flows, integration points, deployment model. Include the conceptual architecture (not just file paths) and explain WHY it's structured this way. What are the boundaries? What are the invariants? Where does complexity live and why?\n\n### Active Work & Recent History (~1,200 tokens)\nDetailed narrative of the last 5-10 sessions. What was built, what problems were solved, what changed and why. Include the story arc — how did the project get from where it was to where it is now? This gives the agent a sense of trajectory, not just current state.\n\nFor each major piece of recent work: what triggered it, what was the approach, what was the outcome, and what's still pending.\n\n### Decision Archive (~1,500 tokens)\nA comprehensive log of the decisions that shaped the project. Each decision should include:\n- What was decided\n- What alternatives were considered and rejected\n- The rationale — why THIS choice over the alternatives\n- Whether the decision is still active or has been superseded\n\nRecent decisions (last 2-4 weeks) get full treatment. Older decisions that are still load-bearing get compressed but preserved. Superseded decisions are mentioned briefly with what replaced them.\n\nThis section should grow and compress over time — early decisions get shorter as they become settled, but never disappear entirely if they still affect how the system works.\n\n### Accumulated Wisdom & Patterns (~1,200 tokens)\nEverything the team has learned that isn't obvious from reading the code. Organize by domain:\n\n- **Architecture & Design**: Patterns that emerged, abstractions that work, boundaries that matter\n- **Operational**: Deployment gotchas, configuration pitfalls, monitoring insights\n- **Development**: Testing strategies that work, debugging approaches, tooling quirks\n- **Agent Behavior**: How AI agents interact with this codebase — what they get wrong, what helps them succeed\n\nEach item should be specific and actionable, not generic advice. \"SQLite WAL mode requires shared memory\" is useful; \"be careful with databases\" is not.\n\n### Trade-offs & Design Tensions (~800 tokens)\nThe active tensions in the system where there isn't a clean answer. For each:\n- What's the tension (e.g., \"local inference quality vs. speed\")\n- What's the current balance point\n- What would shift it (e.g., \"if we move to cloud inference, we'd revisit X\")\n\nThese help the agent make judgment calls that align with the team's values and constraints. They also signal where the system is most likely to need rethinking as conditions change.\n\n### Team Knowledge (~600 tokens)\nWho has been working on what? What are their areas of expertise? What's the collaboration model? How does code get reviewed and merged? What are the testing expectations?\n\nInclude working patterns that affect how the agent should behave — e.g., \"Chris prefers bundled PRs for refactors\" or \"the team uses subagent-driven development for plan execution.\"\n\n### Thread History (~1,200 tokens)\nThe evolution of major features and initiatives. Not just \"what shipped\" but \"how it evolved\" — what was the original idea, how did it change during implementation, what surprised the team, what would they do differently?\n\nThis is the institutional memory that prevents the team from repeating mistakes or losing context on why something that looks simple was actually hard.\n\nWhen the vault is small, this section covers all threads in detail. As the vault grows, older threads compress into lessons learned and only active/recent threads get full treatment.\n\n### Risks & Open Questions (~500 tokens)\nWhat could go wrong? What's unresolved? What assumptions might break? What technical debt is accumulating? These help the agent be appropriately cautious and flag risks early.\n\n### Glossary & Reference (~500 tokens)\nProject-specific terminology, acronyms, and concepts. Include terms that have specific meanings in this project that differ from general usage. Also include key file paths and components that are frequently referenced.\n\n## Priority Rules\n- USE THE FULL 10,000 TOKENS — this tier should be DENSE with useful information\n- This is the one tier where historical depth matters — don't compress away the story\n- Recent activity (last 5-10 sessions) gets narrative detail with context\n- Older activity becomes patterns, lessons, and compressed summaries — but key moments are preserved\n- Trade-offs, wisdom, and thread history should be the RICHEST sections — they grow over time\n- When the vault is small and you can't fill 10K: go DEEP on what exists — explain reasoning, include examples, explore implications, document the \"why\" behind every decision thoroughly\n- When the vault is large and 10K feels tight: ruthlessly prioritize by relevance to current work, but preserve foundational decisions and hard-won lessons even if they're old\n",
  "digest-1500": "Budget: ~1,500 tokens. Use the full budget.\n\nThis is the executive briefing — an agent reading this should immediately know what project it's in, what's happening right now, and what not to step on.\n\n## Required Sections\n\n### Project Identity (~200 tokens)\nWhat is this project? What does it do? What's the tech stack? 2-3 sentences that orient a newcomer.\n\n### Current Focus (~400 tokens)\nWhat is actively being worked on RIGHT NOW? What branches are active? What's the immediate goal? Be specific — name the features, not just \"ongoing development.\"\n\n### Critical Warnings (~400 tokens)\nWhat will bite the agent if it doesn't know? Active gotchas, known bugs, things that look like they should work but don't. These are the \"stop and read before you touch anything\" items.\n\n### Who & How (~200 tokens)\nWho is working on this? What's their focus? Any active collaboration patterns the agent should know about?\n\n### Recent Momentum (~300 tokens)\nWhat just shipped or changed in the last few sessions? This gives the agent a sense of velocity and direction.\n\n## Priority Rules\n- When the vault is small: fill every section generously with available detail\n- When the vault is large: compress historical context, emphasize last 3-5 sessions\n- NEVER leave sections empty — if there's no data for a section, say so explicitly (\"No active blockers\")\n",
  "digest-3000": "Budget: ~3,000 tokens. Use the full budget.\n\nThis is the team standup — an agent reading this should be able to start contributing meaningfully within minutes. It needs to understand not just what's happening, but why things are the way they are.\n\n## Required Sections\n\n### Project Identity & Architecture (~400 tokens)\nWhat is this project? What are the major components and how do they fit together? What's the tech stack? Don't describe code structure — describe the system's purpose and shape.\n\n### Current Sprint (~600 tokens)\nWhat's actively being worked on? What branches are in flight? What's the immediate priority? Include enough detail that the agent knows where to focus without asking.\n\n### Recent Activity (~500 tokens)\nNarrative of what happened in the last few sessions. What was accomplished? What problems were solved? What changed? This gives the agent momentum context.\n\n### Key Decisions & Rationale (~500 tokens)\nThe most important decisions that are currently shaping the project. WHY things are done a certain way, not just what was decided. Include the reasoning — this prevents agents from second-guessing established choices.\n\n### Active Gotchas & Conventions (~500 tokens)\nPatterns to follow, pitfalls to avoid, things that aren't obvious from reading the code. Include both \"do this\" and \"don't do that\" guidance.\n\n### Team & Workflow (~300 tokens)\nWho's working on what? What's the collaboration model? Any active plans or milestones?\n\n### Open Questions (~200 tokens)\nThings that are unresolved, under discussion, or need attention. Helps the agent know where to be careful.\n\n## Priority Rules\n- When the vault is small: go deep on decisions and reasoning — explain the \"why\" thoroughly\n- When the vault is large: compress older decisions into brief mentions, expand recent activity\n- Decisions that are still actively shaping work get full treatment; settled decisions get one-liners\n- Recent sessions (last 3-5) get narrative detail; older sessions become trend summaries\n",
  "digest-5000": "Budget: ~5,000 tokens. Use the FULL budget — this is a rich context tier.\n\nThis is deep onboarding — an agent reading this should understand the project as well as a team member who's been on the project for weeks. It needs to know not just what and why, but the patterns, trade-offs, accumulated wisdom, and team dynamics that shape daily work.\n\n## Required Sections\n\n### Project Identity & Purpose (~400 tokens)\nWhat is this project? What problem does it solve? Who uses it? What's the vision? Ground the agent in the project's reason for existing.\n\n### Architecture & Key Components (~600 tokens)\nHow the system fits together at a high level. Major subsystems, data flow, integration points. Focus on the concepts and boundaries, not file paths — the agent can read code for implementation details.\n\n### Current State & Active Work (~700 tokens)\nWhat's in progress right now? What branches are active? What's the immediate priority? What shipped recently? Give enough detail that the agent could pick up a task without asking for orientation.\n\n### Decision Log (~800 tokens)\nThe important decisions that shaped the project and are still relevant. For each: what was decided, what alternatives were considered, and WHY this path was chosen. These prevent agents from relitigating settled questions or unknowingly violating established direction.\n\nWhen the vault is large, compress older decisions but preserve their conclusions. Recent decisions get full treatment with rationale and alternatives rejected.\n\n### Accumulated Wisdom (~700 tokens)\nCross-cutting lessons the team has learned. Recurring gotchas, established patterns, things that aren't obvious from the code. These are the \"we learned this the hard way\" items that save time.\n\nOrganize by theme (e.g., \"Configuration & Settings\", \"Testing Patterns\", \"Agent Behavior\") rather than chronologically.\n\n### Trade-offs & Tensions (~500 tokens)\nActive tensions in the system — things where there isn't a clean answer and the agent needs to understand the balance. Performance vs. quality, simplicity vs. flexibility, local vs. remote, etc. These help the agent make judgment calls that align with the team's values.\n\n### Team Dynamics & Workflow (~400 tokens)\nWho is working on what, and how? Communication patterns, review processes, branch strategies, testing expectations. How does work get done here?\n\n### Open Threads & Risks (~400 tokens)\nUnfinished work, known risks, things that need attention soon. Helps the agent understand where the edges are and what to be careful about.\n\n### Glossary (~500 tokens)\nProject-specific terminology that an agent needs to know. Include terms that have specific meanings in this codebase that differ from general usage.\n\n## Priority Rules\n- USE THE FULL 5,000 TOKENS — sparse output at this tier is a failure\n- When the vault is small: go deep on every section, explain reasoning thoroughly, include examples\n- When the vault is large: recent activity (last 5-10 sessions) gets detailed treatment; older context compresses into patterns and conclusions\n- Trade-offs and wisdom should GROW over time as the team learns more — these sections should get richer, not shorter\n- Decisions from early in the project that are still load-bearing get preserved; decisions that were superseded get dropped or mentioned briefly\n",
  "digest-7500": "Budget: ~7,500 tokens. Use the FULL budget — this is the institutional knowledge tier.\n\nThis is the complete project context — an agent reading this should have the equivalent of months of project history and team knowledge. It should be able to make architectural decisions, understand why any part of the system exists, and anticipate risks that aren't obvious from the current code.\n\nThis tier exists for complex work: major refactors, architectural reviews, onboarding new team members, or debugging systemic issues where understanding history matters.\n\n## Required Sections\n\n### Project Identity & Vision (~400 tokens)\nWhat is this project? What problem does it solve? Who uses it and how? What's the long-term vision? Ground the agent in purpose so it can evaluate whether proposed changes serve the project's goals.\n\n### Architecture Deep Dive (~800 tokens)\nHow the system fits together — subsystems, data flows, integration points, deployment model. Include the conceptual architecture (not just file paths) and explain WHY it's structured this way. What are the boundaries? What are the invariants?\n\n### Active Work & Recent History (~1,000 tokens)\nDetailed narrative of the last 5-10 sessions. What was built, what problems were solved, what changed and why. Include the story arc — how did the project get from where it was to where it is now?\n\nFor each major piece of recent work: what triggered it, what was the approach, what was the outcome, and what's still pending.\n\n### Decision Archive (~1,200 tokens)\nThe decisions that shaped the project. Each decision should include:\n- What was decided\n- What alternatives were considered and rejected\n- The rationale — why THIS choice over the alternatives\n- Whether the decision is still active or has been superseded\n\nRecent decisions (last 2-4 weeks) get full treatment. Older decisions that are still load-bearing get compressed but preserved.\n\n### Accumulated Wisdom & Patterns (~900 tokens)\nEverything the team has learned that isn't obvious from reading the code. Organize by domain:\n\n- **Architecture & Design**: Patterns that emerged, abstractions that work, boundaries that matter\n- **Operational**: Deployment gotchas, configuration pitfalls, monitoring insights\n- **Development**: Testing strategies, debugging approaches, tooling quirks\n- **Agent Behavior**: How AI agents interact with this codebase — what they get wrong, what helps them succeed\n\nEach item should be specific and actionable, not generic advice.\n\n### Trade-offs & Design Tensions (~600 tokens)\nThe active tensions in the system where there isn't a clean answer. For each:\n- What's the tension\n- What's the current balance point\n- What would shift it\n\nThese help the agent make judgment calls that align with the team's values and constraints.\n\n### Team Knowledge (~500 tokens)\nWho has been working on what? What are their areas of expertise? What's the collaboration model? Include working patterns that affect how the agent should behave.\n\n### Thread History (~900 tokens)\nThe evolution of major features and initiatives. Not just \"what shipped\" but \"how it evolved\" — what was the original idea, how did it change during implementation, what surprised the team?\n\nWhen the vault is small, cover all threads in detail. As it grows, older threads compress into lessons learned and only active threads get full treatment.\n\n### Risks & Open Questions (~400 tokens)\nWhat could go wrong? What's unresolved? What assumptions might break? What technical debt is accumulating?\n\n### Glossary & Reference (~400 tokens)\nProject-specific terminology and concepts. Include terms that have specific meanings in this project that differ from general usage. Key file paths and components that are frequently referenced.\n\n## Priority Rules\n- USE THE FULL 7,500 TOKENS — this tier should be DENSE with useful information\n- This is the one tier where historical depth matters — don't compress away the story\n- Recent activity (last 5-10 sessions) gets narrative detail with context\n- Older activity becomes patterns, lessons, and compressed summaries — but key moments are preserved\n- Trade-offs, wisdom, and thread history should be the RICHEST sections — they grow over time\n- When the vault is small and you can't fill 7,500: go DEEP on what exists — explain reasoning, include examples, explore implications\n- When the vault is large and 7,500 feels tight: ruthlessly prioritize by relevance to current work, but preserve foundational decisions and hard-won lessons\n",
  "digest-system": "You are Myco's digest engine. Your role is to maintain a living understanding of a software project by synthesizing observations, session histories, plans, and team activity into a coherent context representation.\n\nYou will receive:\n1. Your previous synthesis (if one exists) — this is your accumulated understanding from prior cycles\n2. New substrate — recently captured knowledge that needs to be incorporated\n\nYour output will be injected directly into an AI agent's context window at the start of every session. The agent will rely on this as its primary understanding of the project. Write for that audience.\n\nCRITICAL RULES:\n- NEVER fabricate file paths, function names, commands, or architecture not explicitly in the substrate\n- NEVER invent plans, issues, or next steps not mentioned in the substrate\n- Omission is better than fabrication — if the substrate doesn't mention it, leave it out\n- Reference code or files ONLY using paths and names that appear verbatim in the substrate\n- Focus on WHAT the project does, WHY decisions were made, and WHAT to watch out for — not HOW the code is structured (the agent can read code itself)\n\nBUDGET DISCIPLINE:\n- You MUST use the full token budget generously — a 5,000-token tier should produce close to 5,000 tokens of content\n- Sparse output wastes the budget the user is paying for — fill the space with genuinely useful detail\n- When the knowledge base is small, go deeper on what exists rather than being brief\n- When the knowledge base is large, prioritize recent activity and compress older context — but never drop foundational knowledge entirely\n\nKNOWLEDGE LIFECYCLE:\n- Recent sessions and observations carry more weight than older ones — they reflect current state\n- Foundational knowledge (project identity, architecture decisions, team conventions) persists across cycles even when old\n- Completed work transitions from \"active focus\" to \"historical context\" — compress it, don't drop it\n- Contradictions between old and new substrate should be resolved in favor of the new — note what changed\n- As the vault grows, your role shifts from \"capture everything\" to \"surface what matters most right now\"\n\nFORMATTING:\n- Use markdown with clear section headings\n- Present tense for active state, past tense for completed work\n- Use tables, bullet lists, and structured formats to maximize information density\n",
  "extraction": "You are analyzing a coding session conversation for session \"{{sessionId}}\".\nYou have a budget of ~{{maxTokens}} tokens for your response.\n\n## Session Conversation\n{{conversation}}\n\n## Task\nAnalyze this session conversation and produce a JSON response with exactly this structure:\n{\n  \"summary\": \"A concise narrative of what happened in this session (2-4 sentences).\",\n  \"observations\": [\n    {\n      \"type\": \"gotcha|bug_fix|decision|discovery|trade_off\",\n      \"title\": \"Short descriptive title\",\n      \"content\": \"Detailed explanation of the observation. Be thorough — include the context, the specifics, and why this matters. A teammate reading this should fully understand the issue without needing to look at the code.\",\n      \"tags\": [\"relevant\", \"tags\"]\n    }\n  ]\n}\n\n## Type-Specific Fields\nInclude these additional fields when appropriate for the observation type:\n\n- **bug_fix**: add \"root_cause\" (what caused the bug — be specific) and \"fix\" (what resolved it — include the approach, not just the file name)\n- **decision**: add \"rationale\" (why this choice was made — include constraints and context) and \"alternatives_rejected\" (what was considered and why it was ruled out)\n- **trade_off**: add \"gained\" (what was achieved) and \"sacrificed\" (what was given up, and why the tradeoff was acceptable)\n\nThese fields are optional — only include them when the session provides clear evidence.\n\n## Observation Guidelines\nOnly include observations that meet ALL criteria:\n- Valuable to a teammate encountering the same code/problem\n- Not obvious from reading the code itself\n- Not specific to this session's transient state\n\nTypes:\n- \"gotcha\": A non-obvious problem, pitfall, or workaround — include the symptom, the root cause, and the fix or workaround\n- \"bug_fix\": Root cause of a bug and what fixed it — include enough detail that someone could recognize the same bug\n- \"decision\": An architectural or technical choice — explain the reasoning, constraints, and what was rejected\n- \"discovery\": A significant learning about the codebase, tooling, or domain — explain what was surprising or non-obvious\n- \"trade_off\": What was sacrificed and why — include both sides of the tradeoff and what tipped the balance\n\nRoutine activity (file reads, searches, test runs, navigation) goes in the summary only.\nTarget 0-5 observations. Err on fewer, higher-quality observations with rich detail over many thin ones.\n\nRespond with valid JSON only, no markdown fences.\n",
  "session-similarity": "Rate how related these two coding sessions are on a scale of 0.0 to 1.0.\n\n## Current Session\n{{currentSummary}}\n\n## Candidate Parent Session\n{{candidateSummary}}\n\n## Scoring Guidelines\n\n1. **Same feature/bug** (high weight): Both sessions working on the same feature, bug fix, or component? Same file names or modules?\n2. **Continuation pattern** (high weight): Does the current session continue work from the candidate? References decisions, plans, or outcomes?\n3. **Related work** (medium weight): Related but distinct features? Same area of the codebase?\n4. **Unrelated** (low score): Different features, different parts of the codebase.\n\n## Score Ranges\n\n- 0.9-1.0: Direct continuation (picks up exactly where the other left off)\n- 0.7-0.9: Same feature/bug (clearly related work)\n- 0.5-0.7: Related work (same area, related features)\n- 0.3-0.5: Loosely related (some overlap but different focus)\n- 0.0-0.3: Unrelated (different work entirely)\n\nRespond with ONLY a single number between 0.0 and 1.0.",
  "summary": "You are summarizing a coding session for user \"{{user}}\" (session \"{{sessionId}}\").\n\n## Session Content\n{{content}}\n\n## Task\nWrite a concise summary of this session in 2-4 sentences. Cover what was accomplished, key decisions made, and where things stand. Skip routine details — focus on outcomes someone would need to know months later.\n\nRespond with plain text only, no JSON or markdown fences.\n",
  "supersession": "You are evaluating whether a new observation supersedes any existing observations in a knowledge vault.\n\nAn observation is superseded ONLY when the new one makes it factually outdated or incorrect.\nDo NOT supersede observations that:\n- Discuss the same topic from a different angle\n- Record a different decision about the same component\n- Describe a trade-off that was considered (even if a different choice was made later)\n\nExamples of supersession:\n- New: \"The unload API uses instance_id field\" → Supersedes: \"The unload API uses model field\"\n- New: \"ensureLoaded runs every cycle\" → Supersedes: \"ensureLoaded runs once via modelReady flag\"\n\nExamples of NOT supersession:\n- New: \"We chose Ollama for digest\" → Does NOT supersede: \"LM Studio requires KV cache management\"\n  (Both are valid observations about different providers)\n- New: \"Added retry logic to summarize\" → Does NOT supersede: \"summarize throws on 404\"\n  (The 404 behavior is still true; retry is additive)\n\n## New Observation\n\n{{new_spore}}\n\n## Existing Observations\n\n{{candidates}}\n\n---\n\nReturn a JSON array of IDs from the existing observations that the new observation supersedes.\nIf none are superseded, return an empty array: []\n\nReturn ONLY the JSON array, no other text.\n",
  "title": "Given this session summary, produce a short, descriptive title (5-10 words) that captures the primary accomplishment or focus of the session.\n\nSummary:\n{{summary}}\n\nSession ID: {{sessionId}}\n\nRespond with the title text only, no quotes, no punctuation at the end.\n"
} as const;

export const BUNDLED_MARKDOWN_TEMPLATES: Readonly<Record<string, string>> = {
  "portal": "# Myco Portal\n\nOpen the Myco dashboard in your browser: [http://localhost:{{port}}](http://localhost:{{port}})\n\n> This file is generated by the Myco daemon on startup. Do not edit.\n"
} as const;
