yandecode 0.1.1 → 0.2.0

package/dist/chunks/update-OX5MZYQY.js.map

@@ -0,0 +1,7 @@
+{
+  "version": 3,
+  "sources": ["../../src/commands/update.ts"],
+  "sourcesContent": ["import type { Io } from '@cli/io';\nimport { requireWorkspace } from '@cli/modules/host';\nimport { printApplyReport, saveSelectionAndApply, type SetupDeps } from './setup';\n\n/**\n * Re-materializes the integration for the installed yandecode version and writes the config in\n * the current format (v0 configs are migrated in memory on every load; this persists it).\n */\nexport function runUpdate(\n  cwd: string,\n  flags: { force?: boolean },\n  io: Io,\n  deps: SetupDeps = {},\n): number {\n  const ws = requireWorkspace(cwd);\n  const { config, added, report } = saveSelectionAndApply(\n    ws.root,\n    ws.config.modules,\n    deps,\n    flags.force ? { force: true } : {},\n  );\n  io.out(`yandecode.json is at version ${config.version}\\n`);\n  printApplyReport(io, config.modules, added, report);\n  return 0;\n}\n"],
+  "mappings": ";;;;;;;;;;;;;;;;;AAQO,SAAS,UACd,KACA,OACA,IACA,OAAkB,CAAC,GACX;AACR,QAAM,KAAK,iBAAiB,GAAG;AAC/B,QAAM,EAAE,QAAQ,OAAO,OAAO,IAAI;AAAA,IAChC,GAAG;AAAA,IACH,GAAG,OAAO;AAAA,IACV;AAAA,IACA,MAAM,QAAQ,EAAE,OAAO,KAAK,IAAI,CAAC;AAAA,EACnC;AACA,KAAG,IAAI,gCAAgC,OAAO,OAAO;AAAA,CAAI;AACzD,mBAAiB,IAAI,OAAO,SAAS,OAAO,MAAM;AAClD,SAAO;AACT;",
+  "names": []
+}

package/dist/content/agents/yandecode-reviewer.md

@@ -0,0 +1,22 @@
+---
+name: yandecode-reviewer
+description: Reviews a given diff scope for real bugs and violations of the project's written rules, scoring each finding and returning only those with confidence ≥ 80. Dispatch from the yandecode-code-review skill with the exact scope (e.g. "git diff main...HEAD") and the paths of the applicable CLAUDE.md/AGENTS.md files.
+tools: Read, Grep, Glob, Bash, mcp__yandecode__code_search, mcp__yandecode__code_definition, mcp__yandecode__code_references, mcp__yandecode__code_symbols, mcp__yandecode__knowledge_search
+---
+
+You review one change. You do not edit files.
+
+1. Get the diff for the scope you were given (`git diff …`). Read the listed rule files.
+2. For each hunk, ask: can this break at runtime (wrong condition, missed null/empty case, off-by-one, unhandled rejection, race, resource leak, wrong API use)? Does it violate a rule written in the rule files? Check callers and callees with `code_references` / `code_definition` rather than reading whole files. Check `knowledge_search` for recorded decisions the change may contradict.
+3. Score each candidate 0–100 (80+ = verified and will matter). Drop everything below 80, pre-existing issues, formatter/linter territory and style preferences not in the rules.
+
+Return, and nothing else:
+
+```
+FINDINGS (confidence ≥ 80)
+- [score] path:line — problem; when it happens; smallest fix
+CHECKED
+- one line per area you verified
+```
+
+If there are no findings, return `FINDINGS: none` and the CHECKED list.

package/dist/content/agents/yandecode-security-reviewer.md

@@ -0,0 +1,23 @@
+---
+name: yandecode-security-reviewer
+description: Security review of a given diff scope — traces untrusted input to dangerous sinks (shell, SQL, HTML, paths, fetch, deserialization, CI) and returns only traced findings with confidence ≥ 80. Dispatch from the yandecode-code-review or yandecode-security-review skill with the exact scope.
+tools: Read, Grep, Glob, Bash, mcp__yandecode__code_search, mcp__yandecode__code_definition, mcp__yandecode__code_references
+---
+
+You review one change for security. You do not edit files.
+
+1. Get the diff for the scope you were given.
+2. Identify untrusted sources the change reads (request data, CLI args, files, env, webhook/issue text) and dangerous sinks it reaches (shell, SQL, HTML, filesystem paths, outbound URLs, deserializers, `eval`, CI `run:` steps). Follow the data with `code_references` / `code_definition`.
+3. Also check: authn/authz on new entry points, secrets in code or logs, disabled TLS, weak hashes for security purposes, overly broad permissions.
+4. Keep only findings with a concrete source → sink path and confidence ≥ 80.
+
+Return, and nothing else:
+
+```
+SECURITY FINDINGS (confidence ≥ 80)
+- [score] path:line — source → sink; impact; fix
+QUESTIONS (need a human decision)
+- …
+CHECKED
+- one line per sink/area verified
+```

package/dist/content/skills/NOTICE.md

@@ -0,0 +1,29 @@
+# Third-party notices for bundled skills
+
+The workflow skills (`yandecode-workflow`, `yandecode-tdd`, `yandecode-debugging`, `yandecode-verification`) are condensed adaptations of skills from **obra/superpowers** (commit 8ca22db), used under the MIT License:
+
+```
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```
+
+The change-folder format used by `yandecode-workflow` follows **Fission-AI/OpenSpec** (MIT, commit 79b6aa9); no OpenSpec code is included.

package/dist/content/skills/yandecode-code-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: yandecode-code-review
+description: Review a change (working tree, branch or PR) for real bugs and project-rule violations with a confidence filter. Use when asked to review code, before claiming a non-trivial change is done, or before opening a pull request.
+---
+
+# Code review
+
+Goal: few findings, each real and actionable. A review that lists ten maybes is worse than one that lists two certain bugs.
+
+## 1. Scope the change
+
+- Default scope: `git diff` (unstaged) plus `git diff --cached`; for a branch, `git diff $(git merge-base HEAD main)...HEAD`; for a PR, `gh pr diff <n>`.
+- List changed files and read the project rules that apply to them: root `CLAUDE.md`/`AGENTS.md` and any in the changed directories.
+- Run `quality_check` first. Do not report what the compiler, linter or tests already report — fix or mention the failing step instead.
+
+## 2. Review in parallel
+
+Dispatch the `yandecode-reviewer` agent (bugs + project rules) and, when the change touches input handling, auth, crypto, files, processes, SQL, HTML or CI, the `yandecode-security-reviewer` agent. Give each the exact diff scope and the rule files. Reviewers use `code_definition` / `code_references` to check callers instead of reading whole files.
+
+## 3. Score and filter
+
+Each finding gets a confidence score:
+
+| score  | meaning                                                                |
+| ------ | ---------------------------------------------------------------------- |
+| 0–25   | probably a false positive or pre-existing                              |
+| 26–50  | nitpick not required by the project rules                              |
+| 51–79  | real but minor, or unverified                                          |
+| 80–100 | verified bug, security issue or explicit rule violation that will bite |
+
+Report only findings scoring **≥ 80**. Before reporting, re-read the code path once more to confirm.
+
+Not findings: pre-existing issues, style a formatter owns, things silenced on purpose (lint-ignore comments), speculative performance, "consider adding tests" unless the rules require them.
+
+## 4. Report
+
+For each finding: `path:line` — what breaks, when, and the smallest fix. Group by severity. If nothing survives the filter, say so plainly ("no issues at ≥ 80 confidence") and list what was checked.

package/dist/content/skills/yandecode-debugging/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: yandecode-debugging
+description: Systematic debugging — find the root cause with evidence before changing code. Use for any bug, failing test, build failure, flaky behaviour or performance regression, especially when a quick fix seems obvious or earlier fixes did not work.
+---
+
+# Systematic debugging
+
+**No fix without a root cause.** Symptom patches create the next bug.
+
+## 1. Investigate
+
+- Read the whole error and stack trace; note files, lines, codes.
+- Reproduce reliably. Capture noisy runs with `ctx_run(command, intent="first failure")` and read exact lines with `ctx_get`; don't re-run to scroll.
+- Check what changed: `git log -n 20 --stat`, `git diff`, dependency and config changes.
+- Check memory: `knowledge_search("<error or component>")` — the same failure may already be recorded.
+- In multi-component paths (CI → build → deploy, API → service → DB) log what enters and leaves each boundary once, to see _where_ it breaks.
+- Trace the bad value backwards (`code_references`, `code_definition`) to where it originates.
+
+## 2. Compare
+
+Find similar code that works; list every difference between working and broken, however small.
+
+## 3. Hypothesis → minimal test
+
+State one hypothesis ("X is null because Y runs before Z"). Change one thing to test it. If it is wrong, form a new hypothesis — do not stack fixes. After three failed hypotheses, stop and question the design with the user.
+
+## 4. Fix
+
+Write a failing test that reproduces the root cause (`yandecode-tdd`), fix at the source, run the suite. Record the root cause with `memory_write(kind: "failure", sources: [...])` when it could bite again.
+
+---
+
+Adapted from obra/superpowers `systematic-debugging` (MIT); see NOTICE.md in the yandecode content directory.

package/dist/content/skills/yandecode-instructions/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: yandecode-instructions
+description: Write and maintain CLAUDE.md / AGENTS.md so they stay short, true and useful. Use when creating or editing agent instruction files, when the user corrects you about a project convention, or when instructions_audit reports issues.
+---
+
+# Project instructions
+
+Instruction files load into every session, so each line costs tokens every time. Keep what an agent cannot discover quickly and would get wrong without being told.
+
+## What belongs
+
+- How to build, test, lint and run the project — exact commands (`instructions_audit` lists the detected ones).
+- Non-obvious conventions and constraints ("migrations are append-only", "never import across packages except via the index").
+- Where things are when the layout is surprising.
+- Workflow rules the team actually enforces (branching, commit style, review).
+
+## What does not
+
+- Things the code or `package.json` already say, generic advice ("write clean code"), long tutorials (move them to a skill or `docs/`), history of past decisions (use `memory_write` / ADRs).
+
+## Maintaining
+
+1. Edit the smallest relevant file: root `CLAUDE.md` for project-wide rules, a nested `CLAUDE.md`/`AGENTS.md` for one directory.
+2. When the user corrects you on a convention, add the rule in one line, with the reason if it is not obvious.
+3. Run `instructions_audit`; fix missing paths, unknown commands and duplicates it reports; keep each file under ~2 000 tokens.
+4. Leave the `<!-- yandecode:start -->` block alone — YandeCode regenerates it from the enabled modules.

package/dist/content/skills/yandecode-memory/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: yandecode-memory
+description: When and how to record project knowledge with memory_write and read it back with knowledge_search / knowledge_get. Use when you make or discover a decision, a non-obvious convention, a gotcha, or the root cause of a failure worth remembering in later sessions.
+---
+
+# Project memory
+
+Memory is for knowledge a future session would otherwise have to rediscover. It is stored as Markdown files (one per memory) and injected at session start as titles only.
+
+## Read before re-deriving
+
+1. `knowledge_search(query)` returns ids and titles (memories) and `path:lines § heading` (docs). It is cheap.
+2. `knowledge_get([ids])` returns full bodies with their sources. Only fetch what you need.
+3. Treat a memory flagged **stale** (its source file is gone) as a lead to verify, not a fact.
+
+## Write when it will matter later
+
+Record with `memory_write`:
+
+| kind     | write it when                                                   | example title                                   |
+| -------- | --------------------------------------------------------------- | ----------------------------------------------- |
+| decision | a choice was made, with its reason                              | "Sessions use opaque tokens, not JWT"           |
+| pattern  | a convention the code follows that is not obvious from one file | "Repositories return null, services throw"      |
+| fact     | an environmental truth that cost time to learn                  | "Integration tests need `docker compose up db`" |
+| failure  | a bug's root cause and the fix                                  | "Flaky auth test: clock skew in token expiry"   |
+| note     | anything else short-lived (use `durability: "ephemeral"`)       | "Waiting on API key from ops"                   |
+
+Rules:
+
+- One idea per memory. Title = the claim; body = why and how to apply it, a few lines.
+- Always cite `sources` (paths with `:line`, commit ids, URLs, ctx handles) so the memory can be verified and invalidated.
+- Do not store what the repository already records (code structure, git history, README content).
+- When knowledge changes, write the new memory with `supersedes: [old id]`; do not leave contradictions. Use `memory_forget` only for memories that were wrong.
+- Near-duplicates of the same kind are merged automatically; rewriting a memory with a better statement is fine.
+
+Session summaries (`kind: session`) are recorded automatically and expire; do not write them yourself.

package/dist/content/skills/yandecode-security-review/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: yandecode-security-review
+description: Security-focused review of a change — injection, auth, secrets, unsafe deserialization, SSRF, path traversal, CI workflow injection. Use when a change handles untrusted input, credentials, processes, files, network or CI, or when the user asks for a security review.
+---
+
+# Security review
+
+Trace untrusted data from where it enters (HTTP params, CLI args, files, env, webhooks, issue/PR text in CI) to where it is used (shell, SQL, HTML, file paths, URLs fetched, deserializers, `eval`). A finding needs a concrete source → sink path.
+
+## Checklist per sink
+
+- **Shell**: arguments passed as an array (`execFile`, `spawn`, `subprocess.run([...])`), never interpolated into a command string.
+- **SQL**: parameters/placeholders only.
+- **HTML**: text rendering or a vetted sanitizer; no `innerHTML` / `dangerouslySetInnerHTML` with input.
+- **Paths**: resolved and checked to stay inside the intended root (no `..` escape, symlinks considered).
+- **URLs fetched server-side**: allowlist host/scheme (SSRF), no internal addresses.
+- **Deserialization**: JSON / `yaml.safe_load`; never `pickle`, `yaml.load`, `torch.load` without `weights_only` on untrusted data.
+- **Auth**: every new endpoint/handler checks authentication _and_ authorization for the specific resource; tokens compared in constant time; secrets from the environment, never in code or logs.
+- **Crypto**: no MD5/SHA-1 for security, no custom crypto, TLS verification on.
+- **CI (GitHub Actions)**: event data (`github.event.*.title/body/...`) reaches `run:` only through `env:` and quoted variables; `pull_request_target` never checks out untrusted code with secrets.
+
+## Report
+
+Only findings with a traced path and confidence ≥ 80 (same scale as yandecode-code-review). For each: `path:line`, source → sink, impact, and the fix. Mention anything that needs a human decision (e.g. threat model) separately, as a question.

package/dist/content/skills/yandecode-tdd/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: yandecode-tdd
+description: Test-driven development — write a failing test for the behaviour, watch it fail for the right reason, write the minimum code, watch it pass, refactor. Use when implementing any feature or bug fix before writing production code.
+---
+
+# Test-driven development
+
+**No production code without a failing test that demands it.**
+
+## Cycle
+
+1. **Red** — write one test for the next behaviour (or the bug's reproduction). Run it (`ctx_run("<test command> <file>", intent="failure reason")`). It must fail, and fail _because the behaviour is missing_ — not from a typo, import error or wrong fixture. If it passes, the test is wrong or the behaviour already exists.
+2. **Green** — write the simplest code that makes it pass. No extra options, no speculative generality.
+3. **Run everything relevant** — the new test and the suite around it. All green.
+4. **Refactor** — remove duplication, improve names, keep behaviour. Re-run.
+5. Next behaviour.
+
+## Good tests
+
+- Test behaviour through public interfaces, not private helpers or call counts.
+- One behaviour per test; the name states it ("rejects an expired token").
+- Cover the failure cases the acceptance criteria name, not only the happy path.
+- Real code over mocks; mock only true boundaries (network, clock, randomness) and keep the mock faithful.
+- Deterministic: no sleeps, fixed clocks, isolated temp directories.
+
+## Bugs
+
+Reproduce the bug as a failing test first (see `yandecode-debugging` for finding the root cause). The fix is done when that test passes and the suite is green.
+
+## When you catch yourself
+
+- wrote code before the test → keep it aside, write the test, watch it fail against the old code, then bring the code back;
+- a test passed on the first run → make it fail deliberately once to prove it can;
+- "too simple to test" → the test takes a minute; write it.
+
+---
+
+Adapted from obra/superpowers `test-driven-development` (MIT); see NOTICE.md in the yandecode content directory.

package/dist/content/skills/yandecode-verification/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: yandecode-verification
+description: Evidence before claims — run the command that proves a claim and read its output before saying work is done, fixed, passing or ready. Use before reporting completion, checking a task, committing, or opening a PR.
+---
+
+# Verification before completion
+
+**No completion claim without fresh evidence from this turn.**
+
+## Gate
+
+1. Identify the command that proves the claim (tests, typecheck, lint, build, a reproduction).
+2. Run it now — `quality_check` for the project's standard checks, `ctx_run` for anything else.
+3. Read the result: exit code, failure count, the failing lines.
+4. Claim only what the output shows, and quote the evidence ("vitest: 214 passed, 0 failed").
+
+| claim             | evidence required                 | not enough                    |
+| ----------------- | --------------------------------- | ----------------------------- |
+| tests pass        | fresh run, 0 failures             | an earlier run, "should pass" |
+| bug fixed         | the reproduction now passes       | code changed                  |
+| build works       | build exit 0                      | lint passing                  |
+| subagent finished | its diff reviewed                 | its report                    |
+| requirement met   | each acceptance criterion checked | tests green                   |
+
+Words like "should", "probably", "looks good" before running the check mean: run the check. When `work_check` marks a task done, pass the evidence you just saw.
+
+---
+
+Adapted from obra/superpowers `verification-before-completion` (MIT); see NOTICE.md in the yandecode content directory.

package/dist/content/skills/yandecode-workflow/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: yandecode-workflow
+description: How to take non-trivial work from idea to verified change with resumable state — clarify, write a change folder (proposal/design/specs/tasks), then implement task by task with TDD and evidence. Use when asked to build a feature, change behaviour across files, or run a multi-step task that may be interrupted.
+---
+
+# Workflow: idea → verified change
+
+State lives in files, not in the conversation: any session (or loop iteration) resumes with `work_status` and `work_next`.
+
+## 0. Size the work
+
+- **Question / spike** — answer it; no change folder.
+- **Bounded** (one flow that already exists, a few files) — agree a short design in chat, then implement with `yandecode-tdd`. A change folder is optional.
+- **Architectural** (new subsystem, interface others depend on, several steps) — full flow below.
+
+When unsure, take the heavier path.
+
+## 1. Understand before designing
+
+Search first: `knowledge_search` (past decisions), `code_search` / `repo_map` (where things live). Ask the user one question at a time about purpose, constraints and success criteria; prefer multiple choice. Write back your understanding and let them correct it.
+
+## 2. Change folder
+
+`work_new(title, why, what)` creates `<changes>/<id>/proposal.md`. Then, as needed:
+
+- `design.md` — context, decisions (with rejected alternatives), migration plan, risks.
+- `specs/<capability>/spec.md` — requirements as `### Requirement:` with `#### Scenario:` (GIVEN/WHEN/THEN).
+- `tasks.md` — the plan:
+
+```markdown
+- [ ] T1 Parse the new config field
+  - AC: missing field → default 30 s
+  - AC: negative value → error naming the field
+  - Files: src/config/schema.ts, test/config.test.ts
+- [ ] T2 …
+```
+
+Tasks are small (one commit each), ordered by dependency, with acceptance criteria a test can check. Get the user's approval on the plan before implementing architectural work.
+
+## 3. Implement
+
+Loop: `work_next(id)` → implement with `yandecode-tdd` → verify with `yandecode-verification` (`quality_check`) → `work_check(id, task_id, evidence)` → commit. Independent tasks may go to parallel subagents with the full task text and acceptance criteria; review their diff before checking the task.
+
+## 4. Finish
+
+All tasks checked → run the full `quality_check`, review with `yandecode-code-review`, record decisions worth keeping with `memory_write`, then `work_archive(id)`.
+
+---
+
+Adapted from obra/superpowers (MIT) and the OpenSpec change format (MIT); see NOTICE.md in the yandecode content directory.

package/package.json

@@ -1,43 +1,49 @@
 {
   "name": "yandecode",
-  "version": "0.1.1",
-  "description": "YandeCode CLI — local-first agent harness for Claude Code",
+  "version": "0.2.0",
+  "description": "YandeCode \u2014 modular context harness for Claude Code: code navigation, context isolation, memory, workflows and guards, installed once and chosen per project",
   "license": "MIT",
+  "author": "Yande Labs",
   "type": "module",
+  "keywords": [
+    "claude-code",
+    "mcp",
+    "context",
+    "code-navigation",
+    "retrieval",
+    "developer-tools",
+    "ai",
+    "agents"
+  ],
   "engines": {
     "node": ">=22"
   },
   "bin": {
     "yandecode": "./dist/bin.js"
   },
-  "main": "./dist/index.js",
-  "types": "./dist/index.d.ts",
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
-    }
-  },
   "files": [
     "dist"
   ],
   "repository": {
     "type": "git",
-    "url": "https://github.com/whoisclebs/yandecode.git",
+    "url": "https://github.com/yandelabs/yandecode.git",
     "directory": "packages/cli"
   },
-  "homepage": "https://github.com/whoisclebs/yandecode",
-  "scripts": {
-    "build": "tsc -b",
-    "typecheck": "tsc --noEmit"
+  "homepage": "https://github.com/yandelabs/yandecode#readme",
+  "bugs": {
+    "url": "https://github.com/yandelabs/yandecode/issues"
+  },
+  "publishConfig": {
+    "access": "public"
   },
+  "scripts": {},
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.30.0",
-    "@yandecode/core": "0.1.1",
-    "@yandecode/plugin": "0.1.1",
-    "@yandecode/retrieval": "0.1.1",
-    "@yandecode/swarm": "0.1.1",
+    "better-sqlite3": "^13.0.3",
     "commander": "^15.0.0",
+    "ignore": "^7.0.9",
+    "tree-sitter-wasms": "0.1.13",
+    "web-tree-sitter": "0.20.8",
     "zod": "^4.6.5"
   }
 }

package/dist/bin.d.ts

@@ -1,3 +0,0 @@
-#!/usr/bin/env node
-import './commands/index.js';
-//# sourceMappingURL=bin.d.ts.map

package/dist/bin.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"bin.d.ts","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA,OAAO,qBAAqB,CAAC"}

package/dist/claude-bin.d.ts

@@ -1,2 +0,0 @@
-export declare function resolveClaudeBin(): string;
-//# sourceMappingURL=claude-bin.d.ts.map

package/dist/claude-bin.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"claude-bin.d.ts","sourceRoot":"","sources":["../src/claude-bin.ts"],"names":[],"mappings":"AAAA,wBAAgB,gBAAgB,IAAI,MAAM,CAEzC"}

package/dist/claude-bin.js

@@ -1,4 +0,0 @@
-export function resolveClaudeBin() {
-    return process.env.YANDECODE_CLAUDE_BIN ?? 'claude';
-}
-//# sourceMappingURL=claude-bin.js.map

package/dist/claude-bin.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"claude-bin.js","sourceRoot":"","sources":["../src/claude-bin.ts"],"names":[],"mappings":"AAAA,MAAM,UAAU,gBAAgB;IAC9B,OAAO,OAAO,CAAC,GAAG,CAAC,oBAAoB,IAAI,QAAQ,CAAC;AACtD,CAAC"}

package/dist/cli.d.ts

@@ -1,6 +0,0 @@
-import { Command } from 'commander';
-export type CommandRegistrar = (program: Command) => void;
-export declare function registerCommand(registrar: CommandRegistrar): void;
-export declare function buildProgram(): Command;
-export declare function main(argv: string[]): Promise<void>;
-//# sourceMappingURL=cli.d.ts.map

package/dist/cli.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAGpC,MAAM,MAAM,gBAAgB,GAAG,CAAC,OAAO,EAAE,OAAO,KAAK,IAAI,CAAC;AAI1D,wBAAgB,eAAe,CAAC,SAAS,EAAE,gBAAgB,GAAG,IAAI,CAEjE;AAED,wBAAgB,YAAY,IAAI,OAAO,CAStC;AAED,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,IAAI,CAAC,CAExD"}

package/dist/cli.js

@@ -1,21 +0,0 @@
-import { Command } from 'commander';
-import { VERSION } from './version.js';
-const registrars = [];
-export function registerCommand(registrar) {
-    registrars.push(registrar);
-}
-export function buildProgram() {
-    const program = new Command();
-    program
-        .name('yandecode')
-        .description('YandeCode — local-first agent harness for Claude Code')
-        .version(VERSION, '-v, --version')
-        .showHelpAfterError();
-    for (const register of registrars)
-        register(program);
-    return program;
-}
-export async function main(argv) {
-    await buildProgram().parseAsync(argv);
-}
-//# sourceMappingURL=cli.js.map

package/dist/cli.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"cli.js","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AACpC,OAAO,EAAE,OAAO,EAAE,MAAM,cAAc,CAAC;AAIvC,MAAM,UAAU,GAAuB,EAAE,CAAC;AAE1C,MAAM,UAAU,eAAe,CAAC,SAA2B;IACzD,UAAU,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;AAC7B,CAAC;AAED,MAAM,UAAU,YAAY;IAC1B,MAAM,OAAO,GAAG,IAAI,OAAO,EAAE,CAAC;IAC9B,OAAO;SACJ,IAAI,CAAC,WAAW,CAAC;SACjB,WAAW,CAAC,uDAAuD,CAAC;SACpE,OAAO,CAAC,OAAO,EAAE,eAAe,CAAC;SACjC,kBAAkB,EAAE,CAAC;IACxB,KAAK,MAAM,QAAQ,IAAI,UAAU;QAAE,QAAQ,CAAC,OAAO,CAAC,CAAC;IACrD,OAAO,OAAO,CAAC;AACjB,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,IAAI,CAAC,IAAc;IACvC,MAAM,YAAY,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC;AACxC,CAAC"}

package/dist/commands/doctor.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=doctor.d.ts.map

package/dist/commands/doctor.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"doctor.d.ts","sourceRoot":"","sources":["../../src/commands/doctor.ts"],"names":[],"mappings":""}

package/dist/commands/doctor.js

@@ -1,19 +0,0 @@
-import { registerCommand } from '../cli.js';
-import { defaultProbeVersion, doctorExitCode, formatDoctor, runDoctor } from '../doctor/checks.js';
-import { VERSION } from '../version.js';
-registerCommand((program) => {
-    program
-        .command('doctor')
-        .description('Check the YandeCode installation and this project')
-        .action(() => {
-        const results = runDoctor({
-            cwd: process.cwd(),
-            probeVersion: defaultProbeVersion,
-            nodeVersion: process.version,
-            yandecodeVersion: VERSION,
-        });
-        process.stdout.write(formatDoctor(results));
-        process.exitCode = doctorExitCode(results);
-    });
-});
-//# sourceMappingURL=doctor.js.map

package/dist/commands/doctor.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"doctor.js","sourceRoot":"","sources":["../../src/commands/doctor.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,WAAW,CAAC;AAC5C,OAAO,EAAE,mBAAmB,EAAE,cAAc,EAAE,YAAY,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAC;AACnG,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AAExC,eAAe,CAAC,CAAC,OAAO,EAAE,EAAE;IAC1B,OAAO;SACJ,OAAO,CAAC,QAAQ,CAAC;SACjB,WAAW,CAAC,mDAAmD,CAAC;SAChE,MAAM,CAAC,GAAG,EAAE;QACX,MAAM,OAAO,GAAG,SAAS,CAAC;YACxB,GAAG,EAAE,OAAO,CAAC,GAAG,EAAE;YAClB,YAAY,EAAE,mBAAmB;YACjC,WAAW,EAAE,OAAO,CAAC,OAAO;YAC5B,gBAAgB,EAAE,OAAO;SAC1B,CAAC,CAAC;QACH,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,YAAY,CAAC,OAAO,CAAC,CAAC,CAAC;QAC5C,OAAO,CAAC,QAAQ,GAAG,cAAc,CAAC,OAAO,CAAC,CAAC;IAC7C,CAAC,CAAC,CAAC;AACP,CAAC,CAAC,CAAC"}

package/dist/commands/hook.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=hook.d.ts.map

package/dist/commands/hook.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"hook.d.ts","sourceRoot":"","sources":["../../src/commands/hook.ts"],"names":[],"mappings":""}

package/dist/commands/hook.js

@@ -1,23 +0,0 @@
-import { registerCommand } from '../cli.js';
-import { runHookCommand } from '../hooks/handlers.js';
-async function readStdin() {
-    if (process.stdin.isTTY)
-        return '';
-    const chunks = [];
-    for await (const chunk of process.stdin)
-        chunks.push(Buffer.from(chunk));
-    return Buffer.concat(chunks).toString('utf8');
-}
-registerCommand((program) => {
-    program
-        .command('hook <event>')
-        .description('Claude Code hook entry point (reads the hook JSON from stdin)')
-        .action(async (event) => {
-        const stdinText = await readStdin();
-        const result = await runHookCommand(event, stdinText, process.cwd());
-        if (result.stdout)
-            process.stdout.write(result.stdout);
-        process.exitCode = result.exitCode;
-    });
-});
-//# sourceMappingURL=hook.js.map

package/dist/commands/hook.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"hook.js","sourceRoot":"","sources":["../../src/commands/hook.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,eAAe,EAAE,MAAM,WAAW,CAAC;AAC5C,OAAO,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAEtD,KAAK,UAAU,SAAS;IACtB,IAAI,OAAO,CAAC,KAAK,CAAC,KAAK;QAAE,OAAO,EAAE,CAAC;IACnC,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,IAAI,KAAK,EAAE,MAAM,KAAK,IAAI,OAAO,CAAC,KAAK;QAAE,MAAM,CAAC,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,KAAe,CAAC,CAAC,CAAC;IACnF,OAAO,MAAM,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC;AAChD,CAAC;AAED,eAAe,CAAC,CAAC,OAAO,EAAE,EAAE;IAC1B,OAAO;SACJ,OAAO,CAAC,cAAc,CAAC;SACvB,WAAW,CAAC,+DAA+D,CAAC;SAC5E,MAAM,CAAC,KAAK,EAAE,KAAa,EAAE,EAAE;QAC9B,MAAM,SAAS,GAAG,MAAM,SAAS,EAAE,CAAC;QACpC,MAAM,MAAM,GAAG,MAAM,cAAc,CAAC,KAAK,EAAE,SAAS,EAAE,OAAO,CAAC,GAAG,EAAE,CAAC,CAAC;QACrE,IAAI,MAAM,CAAC,MAAM;YAAE,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;QACvD,OAAO,CAAC,QAAQ,GAAG,MAAM,CAAC,QAAQ,CAAC;IACrC,CAAC,CAAC,CAAC;AACP,CAAC,CAAC,CAAC"}

package/dist/commands/index-cmd.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=index-cmd.d.ts.map

package/dist/commands/index-cmd.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"index-cmd.d.ts","sourceRoot":"","sources":["../../src/commands/index-cmd.ts"],"names":[],"mappings":""}

package/dist/commands/index-cmd.js

@@ -1,47 +0,0 @@
-import { registerCommand } from '../cli.js';
-import { openRuntime } from '../context.js';
-import { createRetrieval } from '../retrieval-runtime.js';
-function printStatus(status) {
-    process.stdout.write(`documents ${status.documents}, chunks ${status.chunks}, dirty ${status.dirtyFiles}, generation ${status.generation}, vectors ${status.vectorCount}, inSync ${status.inSync}\n`);
-}
-registerCommand((program) => {
-    program
-        .command('index')
-        .description('Build or update the local RAG index for this repository')
-        .option('--full', 'reprocess every file from scratch, bumping the index generation')
-        .option('--rebuild-vectors', 'rebuild the vector index from stored embeddings without re-embedding')
-        .option('--status', 'print index status and exit without indexing')
-        .action(async (options) => {
-        const rt = openRuntime(process.cwd());
-        const retrieval = createRetrieval(rt);
-        try {
-            if (options.status) {
-                printStatus(retrieval.indexing.status());
-                return;
-            }
-            const mode = options.rebuildVectors
-                ? 'rebuild-vectors'
-                : options.full
-                    ? 'full'
-                    : 'incremental';
-            const report = await retrieval.indexing.run({
-                mode,
-                onProgress: (p) => {
-                    process.stdout.write(`\r${p.phase.padEnd(8)} ${p.done}/${p.total}${p.path ? ` ${p.path}` : ''}${' '.repeat(20)}`);
-                },
-            });
-            process.stdout.write('\n');
-            process.stdout.write(`added ${report.added}, changed ${report.changed}, removed ${report.removed}, unchanged ${report.unchanged}, chunks ${report.chunks}, generation ${report.generation}, ${report.durationMs}ms\n`);
-            const status = retrieval.indexing.status();
-            if (!status.inSync) {
-                process.stderr.write('index is out of sync after the run; try "yandecode index --rebuild-vectors"\n');
-                process.exitCode = 1;
-            }
-        }
-        finally {
-            await retrieval.dispose();
-            rt.close();
-        }
-    });
-});
-//# sourceMappingURL=index-cmd.js.map