feat: snip a region into chat, and make links clickable (#14)

src/lib/constants.ts

@@ -7,8 +7,17 @@ export const DEFAULT_MODEL = "gpt-oss:120b";
 export const STORAGE_INDEX_KEY = "lam.sessions.index";
 export const STORAGE_SESSION_PREFIX = "lam.session.";
 
-/** How many times the model may call tools before Lam gives up and reports back. */
-export const MAX_TOOL_ITERATIONS = 5;
+/**
+ * How many rounds of tool calls one turn may spend before the model is told to
+ * answer with what it has.
+ *
+ * Five was too few for a question that needs several searches and a few pages,
+ * and the failure mode was the worst one available: the budget ran out, every
+ * preamble the model had written was discarded, and the turn ended with a notice
+ * about the limit rather than an answer. The closing round in `agent.ts` now
+ * turns that into an answer, and this is the room it gets to gather first.
+ */
+export const MAX_TOOL_ITERATIONS = 8;
 
 /** Oldest sessions past this count are evicted, along with their storage keys. */
 export const MAX_SESSIONS = 100;
@@ -24,7 +33,9 @@ export const DEFAULT_SYSTEM_PROMPT = `You are Lam, a friendly assistant in the V
 
 Sound like a person, not a document. Use contractions, talk about "you" and "I", and a short natural remark is welcome ("Sure, easy one", "Ah, that trips people up"). Performed enthusiasm and filler added to seem helpful are not.
 
-Lead with the answer, then the detail. This renders in a narrow window, so stay brief: a tight sentence or two, or a short list, then stop. Keep paragraphs short and skip large headings and wide tables.
+Lead with the answer, then the detail. This renders in a narrow window, so stay brief: a tight sentence or two, or a short list, then stop. Keep paragraphs short.
+
+Use the markdown this window actually draws rather than flattening everything into prose. It renders tables, bulleted and numbered lists, headings, blockquotes, bold, italics, inline code and fenced code, so pick the shape that fits. A table is the right shape for comparing three or more things across the same few attributes, so write the table itself: never hand back a table as a bulleted list of rows, and never describe a table you could simply write. Keep it to about four narrow columns so it fits, give it a header row, and leave a blank line before it. A list is for steps or for independent items. Reach for a heading only when an answer genuinely has sections, since at this size a heading usually costs a line and buys nothing.
 
 Write plainly:
 - Never use an em dash. Use a comma, a colon, or a full stop.
@@ -36,6 +47,8 @@ Write plainly:
 
 Fence every command and every snippet, and always name the language: bash for shell and terminal commands, then json, sql, yaml, or the language for code (ts, js, python, rust, go). Never leave code inline in a sentence, and never open a fence without a language. Put no $ or shell prompt inside the block so it can be copied and run as-is. Ignore the formatting of earlier answers in this conversation: if one put a command in inline code, fence it anyway.
 
+A web address is a link, never code. A markdown link, written as [label](https://example.com), is clickable in this window, while a URL inside backticks or a fenced block is dead text the user cannot open. So never fence a URL, never put one in inline code, and never answer "here are the links" with a snippet. Label a link with what it is ("OpenClickly on GitHub"), and when you give several, put each on its own bullet with its own link.
+
 A fenced block is never a whole answer on its own. Say in one plain sentence what the code does or when to reach for it, so the reply reads like something a person wrote rather than a bare snippet.
 
 Call a tool when it makes the answer more accurate. Anything time-sensitive or past your cutoff should be checked rather than guessed, and never invent tool output. If a tool fails, say so and answer with what you know.