@aistastudio/myc 0.3.3 → 0.3.4

package/README.md

@@ -31,7 +31,7 @@ Installation is one command:
 
 ```bash
 bun install -g @aistastudio/myc   # 3.20 MB, 10 files, no models pulled at install
-myc --version                     # myc 0.3.3 (schema 1)
+myc --version                     # myc 0.3.4 (schema 1)
 ```
 
 The embedding model is **not** downloaded during install. Semantic search is
@@ -56,6 +56,7 @@ writing a config that silently won't start.
 ```bash
 ./dist/myc init                     # .myc/ + SQLite + migrations in this repo
 ./dist/myc wire                     # hooks for Claude Code / Codex / opencode / Kimi
+./dist/myc wire --scope user        # the same for agents in git worktrees (Claude Code's user layer)
 ./dist/myc ready                    # what can be picked up right now
 ./dist/myc remember "why X, not Y"  # record a fact or decision
 ./dist/myc recall "how retrieval works"
@@ -65,6 +66,25 @@ writing a config that silently won't start.
 
 Full command list: `./dist/myc --help`.
 
+**Agents in git worktrees.** `myc wire` writes into the project:
+`.claude/settings.json`, `.mcp.json`. An agent that orca starts in a git
+worktree of a nested repository (`~/orca/workspaces/<repo>/<branch>`) lives in
+the team's tree, where those files are not, even though `myc` itself finds the
+main copy's workspace from there. `myc wire --scope user` puts the same into
+Claude Code's user layer, which every session reads:
+`~/.claude/helpers/myc-hooks.mjs`, SessionStart/PreCompact/PostToolUse hooks and
+`Bash(myc <command>:*)` rules in `~/.claude/settings.json` (merged node by node;
+the hooks of orca, herdr and other tools stay byte for byte), the skill in
+`~/.claude/skills/myc`, and the MCP server through `claude mcp add --scope user`.
+Before anything else the helper checks, without starting myc, whether there is
+a workspace here (a git worktree is resolved through its main copy), and stays
+silent when there is none or the project wires myc itself: in a project without
+myc the hook costs one node start, and prime never arrives twice. Outside a
+workspace the MCP server offers zero tools and no instructions. The user's
+`statusLine` is never touched (it belongs to orca), and `--hook-mode replace`
+is refused here. The journal is `~/.myc/wire-user.json`; `myc unwire --scope
+user` restores the settings node by node and removes the MCP server.
+
 ## Heavy commands take turns
 
 Several agents on one machine — in one tree or in neighbouring projects — each
@@ -266,6 +286,34 @@ myc code grep "<lit>"    exhaustive, every occurrence; --in <path> narrows it
 myc skeleton <file>      the file's API — 26× cheaper than reading it
 ```
 
+The file list is git's own (`git ls-files`, so `.gitignore` applies; a tree
+without git is walked, and the command says so). On top of any list,
+secret-named files are never indexed, whatever `.gitignore` says: `.env` and
+`.env.*` (templates like `.env.example` are indexed), `*.pem`, `*.key`,
+keystores, private SSH keys, `.npmrc`, `.netrc` and other credential files —
+`code index` counts them without naming them, and `code grep` refuses to read one.
+
+**Nested repositories and git worktrees.** A workspace can be an ecosystem: a
+root that is a git repository with independent repositories inside it (not
+submodules). It has one code index, built from the root — one row per file,
+paths like `messaging-server/server/src/x.ts`. From inside a nested
+repository every code command answers from that repository's part of the
+root index, with paths relative to the repository you are in; from the root
+the answers do not change. `myc code index` run inside a nested repository
+refreshes its part of the root index instead of building a second copy of the
+same files, and so does the background refresh. A git worktree — even one
+outside the workspace tree — is answered from the index of the main checkout:
+there is no index per branch. When the worktree is on another commit, or has
+uncommitted changes to tracked files, every answer carries
+`WARN code_index.worktree_divergent` naming both branches, because lines and
+spans may not match your files. `code grep` reads the worktree's files (the
+line numbers are yours, the owning symbols come from the index); `skeleton`
+shows the main copy's declarations when your copy differs from what the index
+saw, and says so. When nothing covers the repository, the hint is the command
+for the workspace root (`myc -C <root> code index`), not one that would build a
+duplicate. Anchors set from the root and from inside a repository are stored
+under different keys; `code symbol` reads both.
+
 Anchors tie knowledge to a span and follow the code as it moves; that half is
 language-agnostic and was verified on Python as well as TypeScript.