ticket: add web tools and nix packaging

work-items/open/20260528-152959-nix-packaging/item.md

@@ -0,0 +1,60 @@
+---
+id: 20260528-152959-nix-packaging
+slug: nix-packaging
+title: Package Insomnia with Nix
+status: open
+kind: task
+priority: P2
+labels: [packaging, nix, distribution]
+created_at: 2026-05-28T15:29:59Z
+updated_at: 2026-05-28T15:29:59Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Insomnia should be easy to install and run on Nix/NixOS systems without requiring each user to hand-roll a local derivation. Add a Nix packaging entry point suitable for development and user installation.
+
+This ticket is about packaging and installability, not changing runtime behavior. The package should build the Rust workspace binaries and include the runtime resources needed by the installed commands.
+
+## Requirement
+
+- Add Nix packaging for the repository.
+  - Prefer a `flake.nix` entry point unless there is a strong project-local reason not to.
+  - Provide package outputs for the user-facing binaries, at minimum the Pod CLI and TUI binaries produced by the workspace.
+  - Provide a dev shell or equivalent developer environment if it can be done without large scope creep.
+- Ensure runtime resources are included or discoverable.
+  - Built-in prompts/resources required at runtime must be packaged in the derivation output.
+  - Installed binaries should not rely on the source checkout layout unless explicitly running in development mode.
+- Keep local/user configuration separate from packaged resources.
+  - Packaging should not bake user manifests, provider keys, sessions, memory, or runtime state into the derivation.
+  - Existing XDG / `INSOMNIA_*` path behavior should remain the source of user config/data/runtime locations.
+- Make the package reproducible and CI-friendly.
+  - Pin inputs through the flake lock if a flake is used.
+  - Avoid network access during the build.
+  - Vendor or hash Cargo dependencies through normal Nix Rust packaging mechanisms.
+- Document usage.
+  - How to build the package.
+  - How to run TUI/Pod binaries from Nix.
+  - How user config is discovered.
+  - Known limitations.
+
+## Acceptance criteria
+
+- `nix build` or the documented equivalent builds the package from a clean checkout.
+- Installed binaries can find built-in resources/prompts at runtime.
+- User config/data/runtime paths continue to resolve through existing path logic and are not stored in the Nix store.
+- A minimal smoke test or check verifies at least command startup/help/version without requiring real provider credentials.
+- Documentation exists for Nix users.
+- Packaging files are formatted by the relevant Nix formatter if one is adopted.
+- `cargo fmt --check`
+- Existing Rust checks affected by packaging changes still pass, or packaging-only validation is clearly documented.
+
+## Out of scope
+
+- Publishing to nixpkgs.
+- NixOS module / Home Manager module.
+- Packaging external LLM providers or model runtimes.
+- Secret management for provider API keys.
+- Changing manifest/path semantics specifically for Nix unless a separate design decision is made.

work-items/open/20260528-152959-nix-packaging/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: tickets.sh at: 2026-05-28T15:29:59Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---

work-items/open/20260528-152959-web-search-fetch-tools/item.md

@@ -0,0 +1,67 @@
+---
+id: 20260528-152959-web-search-fetch-tools
+slug: web-search-fetch-tools
+title: Add WebSearch and WebFetch tools
+status: open
+kind: task
+priority: P2
+labels: [tools, web, llm]
+created_at: 2026-05-28T15:29:59Z
+updated_at: 2026-05-28T15:29:59Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Insomnia currently has strong local filesystem / shell / memory tools, but the agent cannot directly consult current web information except through user-provided excerpts or shell commands. Add first-class WebSearch and WebFetch tools so the model can gather public web information through bounded, observable tool calls.
+
+This should be implemented as normal built-in tools, not as hidden context injection. Tool calls and results must remain visible in history, subject to manifest permission policy, and bounded by output limits.
+
+## Requirement
+
+- Add `WebSearch` tool.
+  - Input includes query string and optional result limit.
+  - Output returns structured results: title, URL, snippet/summary, source/search provider metadata where available.
+  - Search provider must be configurable. If no provider/API key is configured, the tool should fail with a clear diagnostic instead of falling back to scraping arbitrary search pages.
+- Add `WebFetch` tool.
+  - Input includes URL and optional mode/limits.
+  - Output returns normalized text content plus metadata such as final URL, status, content type, title if available, and byte/token truncation indication.
+  - HTML should be converted to readable text. Non-text content should be rejected or summarized only when a safe explicit handler exists.
+- Add manifest configuration for web tools.
+  - Enable/disable controls.
+  - Search provider/API key configuration.
+  - Fetch timeout, max response bytes, max output bytes/tokens, redirect limit.
+  - Allowed/denied URL schemes and host policy.
+- Integrate with built-in tool registration and manifest permission policy.
+  - Web tools are normal tool calls and should go through the existing tool permission mechanism.
+  - No implicit network access should happen outside a tool call.
+- Add security and reliability protections.
+  - Only `http`/`https` by default.
+  - Reject local/private/link-local/loopback addresses by default unless explicitly configured.
+  - Bound redirects and re-check final URLs.
+  - Bound download size and output size.
+  - Provide clear errors for timeout, DNS/network failure, unsupported content, blocked host/scheme, and truncation.
+- Prompts/tool descriptions should tell the model when to use WebSearch vs WebFetch and that fetched content may be stale/untrusted.
+
+## Acceptance criteria
+
+- `WebSearch` and `WebFetch` are registered built-in tools when enabled/configured.
+- Tool schemas are typed and validated.
+- Manifest docs/config examples describe how to enable/configure web tools.
+- Permission policy can allow/deny/ask these tools like other tools.
+- Tool results are bounded and visible in history; no hidden web context is injected.
+- Unit tests cover input validation, disabled/unconfigured errors, URL policy, redirect/final URL policy, output truncation, and representative HTML-to-text conversion.
+- At least one integration-style test uses a local test HTTP server or mock provider rather than the public internet.
+- `cargo fmt --check`
+- `cargo check -p tools -p manifest -p pod`
+- Relevant focused tests for tools/manifest.
+
+## Out of scope
+
+- Browser automation.
+- Authenticated browsing / cookies / sessions.
+- Javascript rendering.
+- File downloads as attachments.
+- Using arbitrary shell commands as the primary web access path.
+- Hidden pre-request browsing or automatic web context injection.

work-items/open/20260528-152959-web-search-fetch-tools/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: tickets.sh at: 2026-05-28T15:29:59Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---