ticket: plan yoi rename

crates/llm-worker/src/token_counter.rs

@@ -6,8 +6,8 @@
 //! # 方針
 //!
 //! - ローカルトークナイザは持たない。実測値があればそれを採用し、
-//!   measurement 間はバイト数で按分、最新 measurement より先は測定済みの増分 rate
-//!   または byte/4 fallback で外挿する
+//!   measurement 間はバイト数で按分、最新 measurement より先は byte/4
+//!   fallback で外挿する
 //! - 推定の出どころは [`EstimateSource`] で呼び出し側に明示する。
 //!   課金判断には使えないが、compact / prune / memory extract trigger 等の
 //!   閾値判定には十分な精度
@@ -22,7 +22,7 @@ pub enum EstimateSource {
     Measured,
     /// 連続する 2 つの measurement の間をバイト按分で計算
     Interpolated,
-    /// 最後の measurement より新しい区間を最終 rate で外挿
+    /// 最後の measurement より新しい区間を byte/4 fallback で外挿
     Extrapolated,
     /// measurement が 1 件も無く、バイト数のみのフォールバック
     NoData,
@@ -122,33 +122,8 @@ pub fn tokens_at(
             let at_bytes = prefix[index];
             let delta_bytes = at_bytes.saturating_sub(lo_bytes);
 
-            let mut measured_span = None;
-            for pair in records.windows(2) {
-                let older = &pair[0];
-                let newer = &pair[1];
-                if newer.history_len > lo.history_len {
-                    break;
-                }
-
-                let older_bytes = prefix[older.history_len.min(cap)];
-                let newer_bytes = prefix[newer.history_len.min(cap)];
-                let span_bytes = newer_bytes.saturating_sub(older_bytes);
-                let span_tokens = newer
-                    .input_total_tokens
-                    .saturating_sub(older.input_total_tokens);
-                if span_bytes > 0 && span_tokens > 0 {
-                    measured_span = Some((span_tokens, span_bytes));
-                }
-            }
-
-            let delta_tokens = if let Some((span_tokens, span_bytes)) = measured_span {
-                (delta_bytes as u128 * span_tokens as u128 / span_bytes as u128) as u64
-            } else {
-                delta_bytes / 4
-            };
-
             TokenEstimate {
-                tokens: lo.input_total_tokens.saturating_add(delta_tokens),
+                tokens: lo.input_total_tokens.saturating_add(delta_bytes / 4),
                 source: EstimateSource::Extrapolated,
             }
         }
@@ -255,7 +230,7 @@ mod tests {
     }
 
     #[test]
-    fn extrapolation_prefers_latest_measured_incremental_span_rate() {
+    fn extrapolation_after_multiple_measurements_uses_byte_fallback_for_unmeasured_delta() {
         let history = vec![
             msg("first"),
             msg(&"measured increment ".repeat(20)),
@@ -263,15 +238,31 @@ mod tests {
         ];
         let records = vec![record(1, 10_000), record(2, 10_200)];
         let prefix = prefix_bytes(&history);
-        let measured_bytes = prefix[2].saturating_sub(prefix[1]);
         let delta_bytes = prefix[3].saturating_sub(prefix[2]);
-        let expected_delta = (delta_bytes as u128 * 200_u128 / measured_bytes as u128) as u64;
 
         let est = total_tokens(&history, &records);
 
         assert_eq!(est.source, EstimateSource::Extrapolated);
-        assert_eq!(est.tokens, 10_200 + expected_delta);
-        assert_ne!(est.tokens, 10_200 + delta_bytes / 4);
+        assert_eq!(est.tokens, 10_200 + delta_bytes / 4);
+    }
+
+    #[test]
+    fn extrapolation_does_not_reuse_measured_rate_after_context_projection() {
+        let compacted_span = msg("x");
+        let projected = vec![
+            msg("first"),
+            msg("summary only"),
+            compacted_span,
+            msg("new user input"),
+        ];
+        let records = vec![record(1, 10_000), record(3, 30_000)];
+        let prefix = prefix_bytes(&projected);
+        let delta_bytes = prefix[4].saturating_sub(prefix[3]);
+
+        let est = total_tokens(&projected, &records);
+
+        assert_eq!(est.source, EstimateSource::Extrapolated);
+        assert_eq!(est.tokens, 30_000 + delta_bytes / 4);
     }
 
     #[test]

crates/pod/src/compact/token_counter.rs

@@ -9,7 +9,7 @@
 //! # 方針
 //!
 //! - ローカルトークナイザは持たない。実測値があればそれを採用し、
-//!   measurement 間はバイト数で按分、最新 measurement より先は最終 rate で外挿する
+//!   measurement 間はバイト数で按分、最新 measurement より先は byte/4 で外挿する
 //! - Compact の retained split では、request-time pruning / projection 後の
 //!   `UsageRecord` を persisted history prefix の単調系列として扱わない。
 //!   現在の prompt occupancy 推定を raw serialized bytes に配分し、末尾の
@@ -245,7 +245,7 @@ pub(crate) fn savings_for_prune_impl(
 impl<C: LlmClient, St: Store> Pod<C, St> {
     /// 現在の history 全体の推定トークン数。
     ///
-    /// 最後の measurement と、その後に追加された未測定分のバイト按分／外挿。
+    /// 最後の measurement と、その後に追加された未測定分の byte/4 外挿。
     pub fn total_tokens(&self) -> TokenEstimate {
         let usage = self.usage_history();
         llm_worker::token_counter::total_tokens(self.history(), &usage)

docs/branding.md

@@ -0,0 +1,166 @@
+# Branding notes
+
+## Rename rationale
+
+The project must move away from the name `insomnia`. Kong already operates a well-known developer product named Insomnia, with overlapping surfaces such as an API/developer tool product, an `insomnia` package/binary, documentation, plugins, CLI tooling, and `.insomnia` project data. Even without making a legal judgment here, keeping `insomnia` would create unnecessary user confusion and distribution risk.
+
+The rename should not be a shallow package-name change. The public product name, CLI command, data/config directory names, environment variable prefix, documentation language, and repository-facing terminology should converge on the new name.
+
+## Product identity
+
+This project is not just an AI chat client. It is a local agent runtime for delegating long-running development work while preserving state, context, authority boundaries, and resumability.
+
+The product promise is:
+
+> You can leave the keyboard, and the system remains present with your work.
+
+That includes:
+
+- running and restoring Pods;
+- preserving session history, memory, workflows, and WorkItems;
+- coordinating delegated work through scoped permissions;
+- keeping human review and approval points explicit;
+- making long-running or interrupted work observable and resumable.
+
+The name should therefore avoid generic AI-agent vocabulary such as `agent`, `forge`, `sentinel`, or `autopilot`. It should express presence, custody, watchfulness, and delegated work without implying reckless full autonomy.
+
+## Proposed name: Yoi
+
+The leading candidate is **Yoi**, from the archaic Japanese word **夜居**.
+
+`夜居` means staying up or being present at night, including the sense of night duty or remaining at the workplace until late. This preserves the original emotional source of `Insomnia`—AI-induced sleeplessness and the desire for something to keep watch on the user's behalf—while moving the framing from a personal condition to a product role.
+
+`Insomnia` described what happened to the user.
+
+`Yoi` describes what the system does instead:
+
+> It stays with the work after the user leaves.
+
+## Why Yoi fits
+
+### Short and tool-shaped
+
+`yoi` is short, easy to type, and works naturally as a command name:
+
+```text
+yoi
+yoi pod
+yoi memory
+yoi workflow
+```
+
+It also maps cleanly to project/runtime surfaces:
+
+```text
+.yoi/
+~/.yoi/
+YOI_*
+```
+
+### Japanese but not overly literal
+
+The name has the same kind of compact Japanese-derived shape as names like Hono or Shiki. It does not sound like a generic enterprise AI product, and it leaves room for the project to develop its own vocabulary.
+
+### Presence rather than automation
+
+The important word in `夜居` is not only night, but **居**: to be there.
+
+That matches the system's architecture. Pods, sessions, memory, workflow state, WorkItems, and runtime metadata remain present so the user can return to them. The product is less about a single model response and more about maintaining a durable place where delegated work can continue.
+
+### Keeps the original story without keeping the problem
+
+The old name centered sleeplessness. The new name centers the replacement for sleeplessness: a system that remains at the worksite on the user's behalf.
+
+A useful internal phrasing is:
+
+> Insomnia was the problem. Yoi is the night presence that makes it unnecessary.
+
+## Handling ambiguity
+
+`Yoi` is intentionally short and has Japanese homophones or near associations such as `良い`, `宵`, and `酔い`. This ambiguity is acceptable if the official spelling and explanation consistently anchor the name as **Yoi (夜居)**.
+
+The ambiguity should be handled as follows:
+
+- Use `Yoi` for the product name in English-facing text.
+- Introduce it as `Yoi (夜居)` in README and high-level docs.
+- Use copy centered on presence, delegated work, and returning later.
+- Do not lean into alcohol-related `酔い` wordplay.
+- Do not over-explain the name in every document; establish the origin once and then use `Yoi` normally.
+
+## Candidate tagline directions
+
+Possible English taglines:
+
+- `Yoi is a local AI agent runtime that stays with your work after you leave.`
+- `Yoi keeps a presence at your desk while your agents work.`
+- `Yoi lets you delegate long-running development work without staying at the keyboard.`
+
+Possible Japanese descriptions:
+
+- `Yoi（夜居）は、あなたが離れたあとも仕事場に居続けるローカル AI エージェント実行環境です。`
+- `Yoi は、Pod、履歴、メモリ、ワークフローを保ち、長く続く開発作業の委譲を支えます。`
+
+## Rename surfaces to update
+
+If `Yoi` is adopted, the rename should cover at least:
+
+- product name: `Insomnia` -> `Yoi`;
+- CLI command: `insomnia` -> `yoi`;
+- workspace directory: `.insomnia/` -> `.yoi/`;
+- user data directory: `~/.insomnia/` -> `~/.yoi/`;
+- environment variables: `INSOMNIA_*` -> `YOI_*`;
+- Nix package/app names;
+- Cargo package names where public-facing;
+- prompt and resource text;
+- docs, reports, AGENTS instructions, tickets, and release material;
+- socket/runtime path labels and diagnostics where user-visible.
+
+Compatibility aliases should be considered separately, but the public identity should not preserve `insomnia` longer than necessary.
+
+## Adoption checks
+
+The required check for this project is Nixpkgs package-name availability, because the project is expected to be distributed as a Nix package.
+
+Checked on 2026-06-01:
+
+- Nixpkgs: `nix search nixpkgs '^yoi$' --json` returned no package.
+- Nixpkgs: `nix eval nixpkgs#yoi.meta.name --raw` reported that `nixpkgs` does not provide `yoi`.
+- Nixpkgs: a direct `<nixpkgs>` attribute check returned `false` for `builtins.hasAttr "yoi" pkgs`.
+- Nixpkgs: nearby existing attributes include `yo` and `yoink`, but not `yoi`.
+
+This satisfies the current required availability check for adopting `Yoi`.
+
+A broader package-manager pass was also performed on 2026-06-01. Results:
+
+- crates.io: `https://crates.io/api/v1/crates/yoi` returned 404; no exact crate found by `cargo search`.
+- npm: exact package `yoi` exists. `npm view yoi` reports `name: yoi`, `version: 1.9.15`, description `Easy (but powerful) NodeJS Server`, created in 2013 and modified in 2022. No `bin` field was reported. This blocks using the exact npm package name without owner coordination, but does not appear to be a CLI-name conflict.
+- PyPI: `https://pypi.org/pypi/yoi/json` returned 404.
+- Homebrew formula: `https://formulae.brew.sh/api/formula/yoi.json` returned 404.
+- Homebrew cask: `https://formulae.brew.sh/api/cask/yoi.json` returned 404.
+- Arch official packages: exact name search returned no package.
+- AUR: `https://aur.archlinux.org/rpc/v5/info/yoi` returned no result.
+- Alpine packages: package-name search returned no exact `yoi` package.
+- Debian packages: package-name search returned no exact `yoi` package.
+- Fedora packages: `https://src.fedoraproject.org/rpms/yoi` returned 404.
+- Gentoo packages: exact package pages checked under likely categories returned 404.
+- MacPorts: package search returned no exact `yoi` port.
+- Snap: Snapcraft API reported `No snap named 'yoi' found in series '16'.`
+- Flathub: direct appstream lookup did not find an app named `yoi`.
+- Scoop Main bucket: `bucket/yoi.json` returned 404.
+- winget-pkgs: `manifests/y/yoi` returned 404.
+- Chocolatey community package page returned 404.
+- Docker Hub: `library/yoi` and `yoi/yoi` returned 404.
+- RubyGems: `https://rubygems.org/api/v1/gems/yoi.json` returned 404.
+- NuGet: `https://api.nuget.org/v3-flatcontainer/yoi/index.json` returned 404.
+- Maven Central: artifact/group search did not show an exact `yoi` package identity.
+- Packagist: `https://packagist.org/packages/yoi/yoi.json` returned 404.
+
+The main package-manager concern found is the stale npm package. Since Nixpkgs is the required distribution target and npm distribution is not currently required, this does not block adopting `Yoi`, but it should be recorded as a known name collision if npm distribution is ever planned.
+
+Optional broader checks before a public release may still include:
+
+- GitHub repository/name availability;
+- domain availability such as `yoi.dev`, `yoi.rs`, `yoi.sh`, or `getyoi.dev`;
+- trademark search results in relevant jurisdictions.
+
+The main risk of `Yoi` is not semantic ambiguity but short-name collision. The required Nixpkgs check is clear, and the broader package-manager pass is acceptable apart from the npm package-name collision.

work-items/closed/20260530-013904-profile-authoring-requirements-sync/item.md

@@ -2,12 +2,12 @@
 id: 20260530-013904-profile-authoring-requirements-sync
 slug: profile-authoring-requirements-sync
 title: Sync profile authoring requirements before choosing the language
-status: open
+status: closed
 kind: task
 priority: P2
 labels: [manifest, profiles, architecture]
 created_at: 2026-05-30T01:39:04Z
-updated_at: 2026-05-30T02:03:58Z
+updated_at: 2026-06-01T07:02:44Z
 assignee: null
 legacy_ticket: null
 ---

work-items/closed/20260530-013904-profile-authoring-requirements-sync/resolution.md

@@ -0,0 +1 @@
+Closed as completed. The requirements sync served its purpose: it captured the Profile boundary, rejected proceeding with semantic-nix-profiles as the assumed direction, and led to the follow-up Lua implementation ticket. The concrete authoring direction was implemented and closed in lua-profile-authoring; remaining refinements should be tracked as separate follow-up tickets.

work-items/closed/20260530-013904-profile-authoring-requirements-sync/thread.md

@@ -15,4 +15,13 @@ Updated the requirements to reflect the current interpretation: Profile is a reu
 Lua-specific notes now record controlled `require` and a public `profile` constructor as likely core primitives, while keeping the exact language/API/return contract open.
 
 
+---
+
+<!-- event: close author: hare at: 2026-06-01T07:02:44Z status: closed -->
+
+## Closed
+
+Closed as completed. The requirements sync served its purpose: it captured the Profile boundary, rejected proceeding with semantic-nix-profiles as the assumed direction, and led to the follow-up Lua implementation ticket. The concrete authoring direction was implemented and closed in lua-profile-authoring; remaining refinements should be tracked as separate follow-up tickets.
+
+
 ---

work-items/open/20260601-064953-plugin-distribution-package-format/item.md

@@ -0,0 +1,89 @@
+---
+id: 20260601-064953-plugin-distribution-package-format
+slug: plugin-distribution-package-format
+title: Plugin distribution package format and discovery
+status: open
+kind: feature
+priority: P2
+labels: [plugin, distribution, workspace, user]
+created_at: 2026-06-01T06:49:53Z
+updated_at: 2026-06-01T06:50:33Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+The plugin extension surface ticket (`plugin-extension-surface`) defines Plugins as a safe contribution model for Tools and Hooks, with MCP, declarative hooks, and WASM treated as runtime mechanisms. The next design question is how plugins are distributed, discovered, installed, and enabled across user and workspace scopes.
+
+The desired initial direction is a single-file plugin package that can be placed in user or workspace plugin stores, for example:
+
+- `~/.config/insomnia/plugins/<id>.insomnia-plugin`
+- `./.insomnia/plugins/<id>.insomnia-plugin`
+
+The package should be easy to copy, inspect, cache, and pin, while preserving Insomnia's scope, permission, history, prompt-context, and trust invariants. In particular, workspace plugins may come from a repository checkout and must not execute merely because an archive exists under `./.insomnia/plugins`.
+
+## Requirements
+
+- Define a first-class plugin package format.
+  - Use a single archive file with an Insomnia-specific extension such as `.insomnia-plugin`.
+  - Require a root plugin manifest file such as `plugin.toml`.
+  - Support packaged assets such as `module.wasm`, JSON schemas, README, and license files.
+  - Specify archive safety rules, including path traversal rejection, bounded extraction, and deterministic digest calculation.
+- Define plugin stores and source/trust mapping.
+  - User plugin store: `~/.config/insomnia/plugins/`.
+  - Workspace/project plugin store: `./.insomnia/plugins/`.
+  - Map stores to the existing source vocabulary (`User`, `Project`/workspace, and future `Builtin`).
+  - Treat `user:<id>` and `project:<id>` as distinct plugin references; ambiguous unqualified IDs should fail closed.
+- Separate discovery from enablement.
+  - Insomnia may discover plugin packages in configured stores.
+  - Discovered packages must not register Tools/Hooks, initialize WASM, or start MCP servers until explicitly enabled by manifest/profile configuration.
+  - Enablement must resolve package identity, version/API compatibility, source, digest, requested capabilities, and host-granted capabilities.
+- Define package manifest semantics.
+  - Include fields for plugin id, version, plugin API version, runtime kind, source/provenance, metadata, contributed tools/hooks, configuration schema, and requested capabilities.
+  - Capability declarations are requests, not grants; effective grants remain controlled by manifest/profile policy, scope, permissions, web/network policy, secret references, and runtime-specific allowlists.
+- Define runtime-specific packaging expectations.
+  - Declarative hooks can be packaged as config-only assets without arbitrary code execution.
+  - WASM plugins should package a module plus schemas/assets and run only with explicit host imports/capabilities.
+  - MCP should remain modeled as a backend/bridge; packaging an MCP server or process command requires explicit process/capability design and must not auto-start from workspace packages.
+- Define cache/pinning behavior.
+  - Extract or materialize packages into a digest-keyed cache before runtime initialization.
+  - Consider digest pins in manifest/profile enablement entries or a future lock file.
+  - Record resolved package digest/source/provenance in the resolved manifest/session metadata where appropriate.
+- Define diagnostics.
+  - Report load/parse/compatibility/capability/runtime failures with plugin id, source, runtime kind, and phase.
+  - Diagnostics must not expose secret values, raw credentials, or unsafe command/environment details.
+
+## Non-goals
+
+- Implementing the full plugin runtime system in this ticket.
+- Implementing a package registry or network installer.
+- Auto-enabling plugins solely because they are present in a plugin directory.
+- Defining UI/TUI rendering extension packaging.
+- Allowing arbitrary host scripting languages as plugin packages.
+- Starting workspace-provided MCP servers without explicit enablement and capability approval.
+
+## Suggested phases
+
+1. **Architecture note**
+   - Define `.insomnia-plugin` package structure, `plugin.toml` fields, source/trust model, discovery vs enablement, archive safety, cache/digest behavior, and runtime mappings.
+2. **Manifest/profile config shape**
+   - Add or propose `[plugins]` enablement entries with source/id/version/digest selectors and capability grants.
+3. **Package discovery prototype**
+   - Implement read-only discovery of user/workspace plugin packages and diagnostics without runtime initialization.
+4. **Package validation and cache**
+   - Validate archive layout, parse `plugin.toml`, compute digest, and materialize into a digest-keyed cache.
+5. **Registry integration**
+   - Connect validated packages to the plugin contribution registry from `plugin-extension-surface` follow-up work.
+6. **Runtime-specific follow-ups**
+   - Split declarative hook packaging, WASM packaging, and MCP packaging/bridge behavior into separate tickets as needed.
+
+## Acceptance criteria
+
+- The repository has a documented plugin distribution/package proposal covering user and workspace plugin stores, single-file archive format, manifest fields, archive safety, cache/digest behavior, and discovery vs enablement.
+- The proposal explicitly states that placing a package in `~/.config/insomnia/plugins/` or `./.insomnia/plugins/` is discovery only, not execution or registration.
+- The design maps package sources to user/project/builtin trust categories and defines how ID collisions and ambiguous selectors are handled.
+- The design explains how capability requests differ from host-granted capabilities and how existing scope/permission/secret/web policy remains authoritative.
+- Runtime-specific notes cover declarative hooks, WASM packages, and MCP backend/bridge packaging constraints.
+- Follow-up implementation tickets can be cut independently for manifest/profile enablement, package discovery, archive validation/cache, WASM packaging, and MCP packaging alignment.
+- Any code changes in this ticket, if taken beyond design docs, are limited to safe internal boundaries and focused tests.

work-items/open/20260601-064953-plugin-distribution-package-format/thread.md

@@ -0,0 +1,22 @@
+<!-- event: create author: tickets.sh at: 2026-06-01T06:49:53Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-01T06:50:33Z -->
+
+## Decision
+
+Distribution direction from user discussion:
+
+- Initial plugin packages should be single-file archives placed in user or workspace plugin stores, such as `~/.config/insomnia/plugins/` and `./.insomnia/plugins/`.
+- Package presence is discovery only. Tool/Hook registration, WASM initialization, or MCP process startup requires explicit manifest/profile enablement and capability grant resolution.
+- The package should contain a root `plugin.toml` and optional runtime assets such as `module.wasm`, schemas, README, and license files.
+- User and workspace stores map to source/trust categories. `user:<id>` and `project:<id>` are distinct; ambiguous selectors should fail closed.
+- Workspace packages are repository-provided and must be treated conservatively, especially for executable runtimes and MCP/process-spawn behavior.
+
+
+---

work-items/open/20260601-080614-rename-insomnia-to-yoi/artifacts/yoi-rename-survey.md

@@ -0,0 +1,280 @@
+# Yoi rename survey
+
+Generated by read-only Pod `surveyor-yoi-rename-20260601` on 2026-06-01.
+
+## Executive stance
+
+Move implementation/public identity to `Yoi` / `yoi` / `.yoi` / `YOI_*` everywhere that is product, runtime, config, CLI, package, prompt, profile, diagnostic, test, or public documentation surface.
+
+Do not bulk-rename historical records, generated personal memory, old work-item threads, or rationale docs except where they currently function as live project instructions or public docs.
+
+A small bounded migration path is appropriate for existing dogfood data directories, but old public aliases should not be preserved long-term unless explicitly reapproved.
+
+## Major rename surfaces
+
+### Cargo package, crate, binary, lockfile
+
+Files:
+
+- `Cargo.toml`
+- `crates/insomnia/Cargo.toml`
+- `crates/insomnia/src/main.rs`
+- `Cargo.lock`
+- `crates/pod/src/entrypoint.rs`
+- tests that expect `insomnia` / `insomnia pod`
+
+Recommendations:
+
+- `crates/insomnia/` -> `crates/yoi/`
+- package `insomnia` -> `yoi`
+- workspace dependency key `insomnia` -> `yoi`
+- installed binary `insomnia` -> `yoi`
+- regenerate `Cargo.lock`
+- update help/tests from `Usage: insomnia ...` to `Usage: yoi ...`
+- do not ship an `insomnia` binary unless a compatibility alias is explicitly approved
+
+### Nix package/app/devshell
+
+Files:
+
+- `package.nix`
+- `flake.nix`
+- `devshell.nix` validation surface
+
+Recommendations:
+
+- `pname = "insomnia"` -> `pname = "yoi"`
+- flake description should say Yoi
+- flake app should point at `${package}/bin/yoi`
+- expose `yoi` package/app outputs
+- avoid long-term `insomnia` public output aliases
+
+### CLI/runtime command surfaces
+
+Files:
+
+- `crates/insomnia/src/main.rs`
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/client/src/spawn.rs`
+- `docs/environment.md`
+
+Recommendations:
+
+- `insomnia` -> `yoi`
+- `insomnia pod` -> `yoi pod`
+- `INSOMNIA_POD_RUNTIME_COMMAND` -> `YOI_POD_RUNTIME_COMMAND`
+- `INSOMNIA-READY` -> `YOI-READY`
+- runtime binary fallback `insomnia` -> `yoi`
+- update CLI help tests and command examples
+
+Mixed-version parent/child spawning need not be supported unless explicitly required.
+
+### Data/config/runtime directories
+
+Central files/surfaces:
+
+- `crates/manifest/src/paths.rs`
+- `crates/pod/src/entrypoint.rs`
+- `crates/session-store/src/fs_store.rs`
+- `crates/pod-registry/src/table.rs`
+- `crates/tui/src/single_pod.rs`
+- `crates/memory/src/workspace.rs`
+- `.insomnia/manifest.toml`
+
+Recommendations:
+
+- `INSOMNIA_HOME` -> `YOI_HOME`
+- `INSOMNIA_CONFIG_DIR` -> `YOI_CONFIG_DIR`
+- `INSOMNIA_DATA_DIR` -> `YOI_DATA_DIR`
+- `INSOMNIA_RUNTIME_DIR` -> `YOI_RUNTIME_DIR`
+- `~/.insomnia` -> `~/.yoi`
+- `~/.config/insomnia` -> `~/.config/yoi`
+- `$XDG_RUNTIME_DIR/insomnia` -> `$XDG_RUNTIME_DIR/yoi`
+- `/tmp/insomnia-*` -> `/tmp/yoi-*`
+- `.insomnia/` -> `.yoi/`
+- `.insomnia/{manifest.toml,workflow,knowledge,memory,prompts}` -> `.yoi/...`
+
+Migration recommendation:
+
+- Provide an explicit migration command/documented manual move, or a one-time startup migration if new paths do not exist and old paths do.
+- Do not keep old and new roots as equal long-term search paths.
+- Do not bulk-read or rewrite ignored personal `.insomnia/memory` contents during repository cleanup.
+
+### Environment variables
+
+Active variables to rename:
+
+- `INSOMNIA_HOME` -> `YOI_HOME`
+- `INSOMNIA_CONFIG_DIR` -> `YOI_CONFIG_DIR`
+- `INSOMNIA_DATA_DIR` -> `YOI_DATA_DIR`
+- `INSOMNIA_RUNTIME_DIR` -> `YOI_RUNTIME_DIR`
+- `INSOMNIA_POD_RUNTIME_COMMAND` -> `YOI_POD_RUNTIME_COMMAND`
+
+Historical/obsolete variables in old docs/work-items can remain if the file is historical.
+
+### Prompt/profile namespace
+
+Files:
+
+- `resources/prompts/system/default.md`
+- `resources/prompts/system/normal.md`
+- `resources/prompts/system/pod-orchestration.md`
+- `resources/prompts/internal/*.md`
+- `resources/profiles/default.lua`
+- `crates/manifest/src/profile.rs`
+- `crates/pod/src/prompt/loader.rs`
+
+Recommendations:
+
+- `insomnia system` -> `Yoi system` or `yoi system`
+- `$insomnia/...` -> `$yoi/...`
+- `require("insomnia")` -> `require("yoi")`
+- `require("insomnia.scope")` -> `require("yoi.scope")`
+- `insomnia.profile` -> `yoi.profile`
+- `insomnia.lua-profile.v1` -> `yoi.lua-profile.v1`
+- `.insomnia/prompts` -> `.yoi/prompts`
+
+Compatibility aliases should be avoided for public release unless separately approved.
+
+### Active project instructions and docs
+
+Rename active/live documentation and instructions:
+
+- `AGENTS.md`
+- `README.md`
+- `docs/environment.md`
+- `docs/manifest-profiles.md`
+- `docs/pod-factory.md`
+- active `docs/plan/*.md` and `docs/ref/*.md` as appropriate
+- active workflow instructions under `.insomnia/workflow/*.md` after path migration
+
+Do not bulk-rename historical records:
+
+- closed work items
+- historical reports in `docs/report/`
+- `docs/branding.md` old-name rationale
+- rename ticket title/content where it explicitly describes the transition
+
+### Tests, snapshots, fixtures
+
+Likely test surfaces:
+
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/client/src/spawn.rs`
+- `crates/manifest/src/paths.rs`
+- `crates/manifest/src/profile.rs`
+- `crates/memory/src/workspace.rs`
+- `crates/tools/src/web.rs`
+- `crates/pod/tests/*.rs`
+
+Recommendations:
+
+- expected CLI help: `insomnia` -> `yoi`
+- env tests: `INSOMNIA_*` -> `YOI_*`
+- path tests: `.insomnia` -> `.yoi`
+- Lua profile tests: `insomnia` module -> `yoi`
+- generic test sample strings should be renamed unless intentionally testing migration
+
+### User-visible diagnostics/log messages
+
+Relevant surfaces:
+
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/pod-registry/src/table.rs`
+- `crates/manifest/src/profile.rs`
+- `crates/pod/src/prompt/loader.rs`
+- `crates/insomnia/src/memory_lint.rs`
+- TUI status/action messages that show paths or commands
+
+Recommendations:
+
+- diagnostics should use `YOI_*`, `$yoi`, `require("yoi")`, `yoi pod`, and `.yoi` paths
+- old names should appear only in explicit migration diagnostics
+
+### Repository/path names outside code
+
+Surfaces:
+
+- local checkout path `/home/hare/Projects/insomnia`
+- repository name
+- worktree names
+- current runtime output paths under `/run/user/1000/insomnia/...`
+
+Recommendations:
+
+- Public repository name should eventually become `yoi`.
+- Local checkout/runtime output paths are not first-pass code-edit targets.
+- Current session/tool output paths are generated/historical.
+
+## Intentionally retained old-name references
+
+Do not bulk-rename by default:
+
+- `docs/branding.md` rationale explaining the collision and rename
+- this rename work item where it states old-to-new transition
+- closed work items under `work-items/closed/`
+- historical `docs/report/` files
+- generated/personal `.insomnia/memory` content
+- external session logs under old runtime paths
+- migration tests/docs that explicitly refer to legacy `insomnia` names
+
+## Proposed implementation order
+
+1. Decide canonical spellings:
+   - Product: `Yoi`
+   - command/package/crate: `yoi`
+   - dotdir: `.yoi`
+   - env prefix: `YOI_`
+   - builtin prompt prefix: `$yoi`
+   - Lua module namespace: `yoi`
+2. Rename Cargo/product package:
+   - move `crates/insomnia` -> `crates/yoi`
+   - update workspace manifest, package names, dependency keys, tests
+   - confirm `cargo metadata`
+3. Rename Nix packaging:
+   - update `package.nix`, `flake.nix`, app program, install check
+4. Rename CLI/runtime command surfaces:
+   - command/help/examples/tests
+   - runtime override env var
+   - ready marker
+   - binary fallback
+5. Rename path/env authority:
+   - centralize in `crates/manifest/src/paths.rs`
+   - decide legacy path migration behavior
+6. Rename workspace conventions:
+   - `.insomnia` -> `.yoi`
+   - move tracked workflow/knowledge/manifest assets
+   - avoid rewriting generated personal memory
+7. Rename profile/prompt namespace:
+   - `$yoi`
+   - `require("yoi")`
+   - builtin profile/schema/source strings
+8. Update active docs and project instructions.
+9. Update tests/fixtures and add migration tests if migration is implemented.
+10. Final grep/audit pass and classify remaining hits.
+
+## Validation checklist
+
+Minimum validation after implementation:
+
+- `cargo check --workspace`
+- `cargo test --workspace` or standard targeted test set
+- `cargo metadata --format-version 1`
+- `cargo run -p yoi -- --help` shows `yoi`
+- `cargo run -p yoi -- pod --help` shows `Usage: yoi pod`
+- spawn path test verifies parent expects `YOI-READY`
+- env/path tests verify `YOI_HOME`, `YOI_CONFIG_DIR`, `YOI_DATA_DIR`, `YOI_RUNTIME_DIR`, `YOI_POD_RUNTIME_COMMAND`
+- runtime path tests verify `~/.yoi`, `~/.config/yoi`, `$XDG_RUNTIME_DIR/yoi`, `.yoi/memory`, `.yoi/workflow`, `.yoi/knowledge`
+- Lua profile tests verify `require("yoi")` and no required `require("insomnia")`
+- prompt loader tests verify `$yoi/...` and `.yoi/prompts`
+- Nix validation verifies `$out/bin/yoi` and flake app launch
+- final residual search:
+
+```bash
+git grep -n -I -E 'insomnia|Insomnia|INSOMNIA|\.insomnia'
+```
+
+Every remaining hit must be branding rationale, migration code/test/doc, closed historical record, generated/personal ignored state, or an explicitly preserved external reference.

work-items/open/20260601-080614-rename-insomnia-to-yoi/item.md

@@ -0,0 +1,37 @@
+---
+id: 20260601-080614-rename-insomnia-to-yoi
+slug: rename-insomnia-to-yoi
+title: Rename project from Insomnia to Yoi
+status: open
+kind: task
+priority: P1
+labels: [branding, rename, release-hygiene]
+created_at: 2026-06-01T08:06:14Z
+updated_at: 2026-06-01T08:29:35Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+The project name `Insomnia` collides with Kong's established Insomnia API/developer tooling product, including public product naming, package/binary naming, CLI/tooling, plugins, documentation, and `.insomnia` project data. The project will adopt **Yoi** as the new public identity, from the archaic Japanese word **夜居**: staying present at night / night duty / remaining at the workplace until late.
+
+Branding rationale and adoption checks are recorded in `docs/branding.md`. Nixpkgs name availability is the required distribution check and currently passes; broader package-manager checks found only an npm package-name collision, which is not a current distribution blocker.
+
+## Requirements
+
+- Rename the public product identity from Insomnia to Yoi.
+- Rename user-facing CLI/package/config/runtime surfaces that currently expose `insomnia` where doing so is not purely internal implementation detail.
+- Prefer a clean public identity over long-lived compatibility with `insomnia`; any compatibility alias must be explicitly justified.
+- Preserve existing project behavior while renaming, without speculative redesign.
+- Keep generated/personal state handling safe; do not expose secrets or private session content during broad rename audits.
+- Update documentation, prompts, diagnostics, package metadata, and release-facing text consistently.
+
+## Acceptance criteria
+
+- The installable main binary/package identity is `yoi` rather than `insomnia`.
+- Nix package/app outputs expose `yoi` and no longer center the long-term public output on `insomnia`.
+- User data/config/workspace directories and environment variable prefixes are renamed or have an explicit migration/compatibility decision recorded.
+- User-visible docs, prompts, diagnostics, and command help refer to Yoi where appropriate.
+- Repository references to `insomnia` are either renamed, intentionally retained as historical/internal/generated context, or listed in the implementation report as deferred/intentional.
+- Tests and packaging checks relevant to renamed surfaces pass.

work-items/open/20260601-080614-rename-insomnia-to-yoi/thread.md

@@ -0,0 +1,308 @@
+<!-- event: create author: tickets.sh at: 2026-06-01T08:06:14Z -->
+
+## Created
+
+Created by tickets.sh create.
+
+---
+
+<!-- event: plan author: hare at: 2026-06-01T08:19:42Z -->
+
+## Plan
+
+# Yoi rename survey
+
+Generated by read-only Pod `surveyor-yoi-rename-20260601` on 2026-06-01.
+
+## Executive stance
+
+Move implementation/public identity to `Yoi` / `yoi` / `.yoi` / `YOI_*` everywhere that is product, runtime, config, CLI, package, prompt, profile, diagnostic, test, or public documentation surface.
+
+Do not bulk-rename historical records, generated personal memory, old work-item threads, or rationale docs except where they currently function as live project instructions or public docs.
+
+A small bounded migration path is appropriate for existing dogfood data directories, but old public aliases should not be preserved long-term unless explicitly reapproved.
+
+## Major rename surfaces
+
+### Cargo package, crate, binary, lockfile
+
+Files:
+
+- `Cargo.toml`
+- `crates/insomnia/Cargo.toml`
+- `crates/insomnia/src/main.rs`
+- `Cargo.lock`
+- `crates/pod/src/entrypoint.rs`
+- tests that expect `insomnia` / `insomnia pod`
+
+Recommendations:
+
+- `crates/insomnia/` -> `crates/yoi/`
+- package `insomnia` -> `yoi`
+- workspace dependency key `insomnia` -> `yoi`
+- installed binary `insomnia` -> `yoi`
+- regenerate `Cargo.lock`
+- update help/tests from `Usage: insomnia ...` to `Usage: yoi ...`
+- do not ship an `insomnia` binary unless a compatibility alias is explicitly approved
+
+### Nix package/app/devshell
+
+Files:
+
+- `package.nix`
+- `flake.nix`
+- `devshell.nix` validation surface
+
+Recommendations:
+
+- `pname = "insomnia"` -> `pname = "yoi"`
+- flake description should say Yoi
+- flake app should point at `${package}/bin/yoi`
+- expose `yoi` package/app outputs
+- avoid long-term `insomnia` public output aliases
+
+### CLI/runtime command surfaces
+
+Files:
+
+- `crates/insomnia/src/main.rs`
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/client/src/spawn.rs`
+- `docs/environment.md`
+
+Recommendations:
+
+- `insomnia` -> `yoi`
+- `insomnia pod` -> `yoi pod`
+- `INSOMNIA_POD_RUNTIME_COMMAND` -> `YOI_POD_RUNTIME_COMMAND`
+- `INSOMNIA-READY` -> `YOI-READY`
+- runtime binary fallback `insomnia` -> `yoi`
+- update CLI help tests and command examples
+
+Mixed-version parent/child spawning need not be supported unless explicitly required.
+
+### Data/config/runtime directories
+
+Central files/surfaces:
+
+- `crates/manifest/src/paths.rs`
+- `crates/pod/src/entrypoint.rs`
+- `crates/session-store/src/fs_store.rs`
+- `crates/pod-registry/src/table.rs`
+- `crates/tui/src/single_pod.rs`
+- `crates/memory/src/workspace.rs`
+- `.insomnia/manifest.toml`
+
+Recommendations:
+
+- `INSOMNIA_HOME` -> `YOI_HOME`
+- `INSOMNIA_CONFIG_DIR` -> `YOI_CONFIG_DIR`
+- `INSOMNIA_DATA_DIR` -> `YOI_DATA_DIR`
+- `INSOMNIA_RUNTIME_DIR` -> `YOI_RUNTIME_DIR`
+- `~/.insomnia` -> `~/.yoi`
+- `~/.config/insomnia` -> `~/.config/yoi`
+- `$XDG_RUNTIME_DIR/insomnia` -> `$XDG_RUNTIME_DIR/yoi`
+- `/tmp/insomnia-*` -> `/tmp/yoi-*`
+- `.insomnia/` -> `.yoi/`
+- `.insomnia/{manifest.toml,workflow,knowledge,memory,prompts}` -> `.yoi/...`
+
+Migration recommendation:
+
+- Provide an explicit migration command/documented manual move, or a one-time startup migration if new paths do not exist and old paths do.
+- Do not keep old and new roots as equal long-term search paths.
+- Do not bulk-read or rewrite ignored personal `.insomnia/memory` contents during repository cleanup.
+
+### Environment variables
+
+Active variables to rename:
+
+- `INSOMNIA_HOME` -> `YOI_HOME`
+- `INSOMNIA_CONFIG_DIR` -> `YOI_CONFIG_DIR`
+- `INSOMNIA_DATA_DIR` -> `YOI_DATA_DIR`
+- `INSOMNIA_RUNTIME_DIR` -> `YOI_RUNTIME_DIR`
+- `INSOMNIA_POD_RUNTIME_COMMAND` -> `YOI_POD_RUNTIME_COMMAND`
+
+Historical/obsolete variables in old docs/work-items can remain if the file is historical.
+
+### Prompt/profile namespace
+
+Files:
+
+- `resources/prompts/system/default.md`
+- `resources/prompts/system/normal.md`
+- `resources/prompts/system/pod-orchestration.md`
+- `resources/prompts/internal/*.md`
+- `resources/profiles/default.lua`
+- `crates/manifest/src/profile.rs`
+- `crates/pod/src/prompt/loader.rs`
+
+Recommendations:
+
+- `insomnia system` -> `Yoi system` or `yoi system`
+- `$insomnia/...` -> `$yoi/...`
+- `require("insomnia")` -> `require("yoi")`
+- `require("insomnia.scope")` -> `require("yoi.scope")`
+- `insomnia.profile` -> `yoi.profile`
+- `insomnia.lua-profile.v1` -> `yoi.lua-profile.v1`
+- `.insomnia/prompts` -> `.yoi/prompts`
+
+Compatibility aliases should be avoided for public release unless separately approved.
+
+### Active project instructions and docs
+
+Rename active/live documentation and instructions:
+
+- `AGENTS.md`
+- `README.md`
+- `docs/environment.md`
+- `docs/manifest-profiles.md`
+- `docs/pod-factory.md`
+- active `docs/plan/*.md` and `docs/ref/*.md` as appropriate
+- active workflow instructions under `.insomnia/workflow/*.md` after path migration
+
+Do not bulk-rename historical records:
+
+- closed work items
+- historical reports in `docs/report/`
+- `docs/branding.md` old-name rationale
+- rename ticket title/content where it explicitly describes the transition
+
+### Tests, snapshots, fixtures
+
+Likely test surfaces:
+
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/client/src/spawn.rs`
+- `crates/manifest/src/paths.rs`
+- `crates/manifest/src/profile.rs`
+- `crates/memory/src/workspace.rs`
+- `crates/tools/src/web.rs`
+- `crates/pod/tests/*.rs`
+
+Recommendations:
+
+- expected CLI help: `insomnia` -> `yoi`
+- env tests: `INSOMNIA_*` -> `YOI_*`
+- path tests: `.insomnia` -> `.yoi`
+- Lua profile tests: `insomnia` module -> `yoi`
+- generic test sample strings should be renamed unless intentionally testing migration
+
+### User-visible diagnostics/log messages
+
+Relevant surfaces:
+
+- `crates/pod/src/entrypoint.rs`
+- `crates/client/src/runtime_command.rs`
+- `crates/pod-registry/src/table.rs`
+- `crates/manifest/src/profile.rs`
+- `crates/pod/src/prompt/loader.rs`
+- `crates/insomnia/src/memory_lint.rs`
+- TUI status/action messages that show paths or commands
+
+Recommendations:
+
+- diagnostics should use `YOI_*`, `$yoi`, `require("yoi")`, `yoi pod`, and `.yoi` paths
+- old names should appear only in explicit migration diagnostics
+
+### Repository/path names outside code
+
+Surfaces:
+
+- local checkout path `/home/hare/Projects/insomnia`
+- repository name
+- worktree names
+- current runtime output paths under `/run/user/1000/insomnia/...`
+
+Recommendations:
+
+- Public repository name should eventually become `yoi`.
+- Local checkout/runtime output paths are not first-pass code-edit targets.
+- Current session/tool output paths are generated/historical.
+
+## Intentionally retained old-name references
+
+Do not bulk-rename by default:
+
+- `docs/branding.md` rationale explaining the collision and rename
+- this rename work item where it states old-to-new transition
+- closed work items under `work-items/closed/`
+- historical `docs/report/` files
+- generated/personal `.insomnia/memory` content
+- external session logs under old runtime paths
+- migration tests/docs that explicitly refer to legacy `insomnia` names
+
+## Proposed implementation order
+
+1. Decide canonical spellings:
+   - Product: `Yoi`
+   - command/package/crate: `yoi`
+   - dotdir: `.yoi`
+   - env prefix: `YOI_`
+   - builtin prompt prefix: `$yoi`
+   - Lua module namespace: `yoi`
+2. Rename Cargo/product package:
+   - move `crates/insomnia` -> `crates/yoi`
+   - update workspace manifest, package names, dependency keys, tests
+   - confirm `cargo metadata`
+3. Rename Nix packaging:
+   - update `package.nix`, `flake.nix`, app program, install check
+4. Rename CLI/runtime command surfaces:
+   - command/help/examples/tests
+   - runtime override env var
+   - ready marker
+   - binary fallback
+5. Rename path/env authority:
+   - centralize in `crates/manifest/src/paths.rs`
+   - decide legacy path migration behavior
+6. Rename workspace conventions:
+   - `.insomnia` -> `.yoi`
+   - move tracked workflow/knowledge/manifest assets
+   - avoid rewriting generated personal memory
+7. Rename profile/prompt namespace:
+   - `$yoi`
+   - `require("yoi")`
+   - builtin profile/schema/source strings
+8. Update active docs and project instructions.
+9. Update tests/fixtures and add migration tests if migration is implemented.
+10. Final grep/audit pass and classify remaining hits.
+
+## Validation checklist
+
+Minimum validation after implementation:
+
+- `cargo check --workspace`
+- `cargo test --workspace` or standard targeted test set
+- `cargo metadata --format-version 1`
+- `cargo run -p yoi -- --help` shows `yoi`
+- `cargo run -p yoi -- pod --help` shows `Usage: yoi pod`
+- spawn path test verifies parent expects `YOI-READY`
+- env/path tests verify `YOI_HOME`, `YOI_CONFIG_DIR`, `YOI_DATA_DIR`, `YOI_RUNTIME_DIR`, `YOI_POD_RUNTIME_COMMAND`
+- runtime path tests verify `~/.yoi`, `~/.config/yoi`, `$XDG_RUNTIME_DIR/yoi`, `.yoi/memory`, `.yoi/workflow`, `.yoi/knowledge`
+- Lua profile tests verify `require("yoi")` and no required `require("insomnia")`
+- prompt loader tests verify `$yoi/...` and `.yoi/prompts`
+- Nix validation verifies `$out/bin/yoi` and flake app launch
+- final residual search:
+
+```bash
+git grep -n -I -E 'insomnia|Insomnia|INSOMNIA|\.insomnia'
+```
+
+Every remaining hit must be branding rationale, migration code/test/doc, closed historical record, generated/personal ignored state, or an explicitly preserved external reference.
+
+
+---
+
+<!-- event: decision author: hare at: 2026-06-01T08:29:35Z -->
+
+## Decision
+
+Decision: adopt Yoi with no compatibility aliases.
+
+The rename should be implemented as a clean public identity change: `Yoi` / `yoi` / `.yoi` / `YOI_*`. Do not ship old `insomnia` binaries, command aliases, prompt/profile aliases, or environment-variable aliases.
+
+For existing dogfood/user state, implement only a bounded one-shot migration path from old local paths to the new Yoi paths. Old and new roots must not remain equal long-term search roots.
+
+
+---