nonoka-cli 0.2.10__tar.gz → 0.2.12__tar.gz

{nonoka_cli-0.2.10 → nonoka_cli-0.2.12}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: nonoka-cli
-Version: 0.2.10
+Version: 0.2.12
 Summary: OpenCode backend for the Nonoka Agent framework
 License: MIT
 License-File: LICENSE
@@ -14,7 +14,7 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.10
-Requires-Dist: nonoka>=1.3.7
+Requires-Dist: nonoka>=1.3.8
 Requires-Dist: pydantic>=2.0
 Requires-Dist: python-dotenv>=1.0
 Requires-Dist: pyyaml>=6.0
@@ -33,7 +33,7 @@ English | [简体中文](README.zh-CN.md)
 
 OpenCode backend for the [Nonoka](https://pypi.org/project/nonoka/) Agent framework.
 
-`nonoka-cli` runs as a stdio NDJSON bridge server (`nonoka-cli --server`) that
+Nonoka runs as a stdio NDJSON bridge server (`python -m nonoka_cli --server`) that
 talks to the `nonoka-opencode-provider` TypeScript package. When used inside
 OpenCode, Nonoka acts as the conversation/decision backend while OpenCode owns
 tool execution and human-in-the-loop (HITL) approval using its native tools.
@@ -57,18 +57,18 @@ After installing, configure your API key and run `nonoka`:
 
 ```bash
 # Interactive: it will ask for your key and save it to ~/.config/nonoka/.env
-nonoka-cli config init
+nonoka config init
 
 # Or set it manually
 export DEEPSEEK_API_KEY=<your-key>
 
-nonoka-cli doctor
+nonoka doctor
 nonoka
 ```
 
-`nonoka` is a shortcut for `nonoka-cli run` and starts the OpenCode TUI with the
-Nonoka backend. You can also use `nonoka run --message "<task>"` for one-shot
-CLI usage.
+`nonoka` is the primary command. It starts the OpenCode TUI when invoked without
+a subcommand, while `nonoka run --message "<task>"` provides one-shot CLI usage.
+The legacy `nonoka-cli` executable remains available for compatibility.
 
 `nonoka-cli` automatically loads `~/.config/nonoka/.env` and `./.env` on startup,
 so you don't need to `export` every time if you save the key in `.env`.
@@ -94,24 +94,24 @@ npm install -g nonoka-opencode-provider
    `~/.config/nonoka/.env`):
 
 ```bash
-nonoka-cli config init
+nonoka config init
 ```
 
 For scripted setups, use the non-interactive mode (you'll still need to set the
 API key via `.env` or `export`):
 
 ```bash
-nonoka-cli config init --yes --model deepseek/deepseek-v4-pro
+nonoka config init --yes --model deepseek/deepseek-v4-pro
 ```
 
 2. Generate an OpenCode config in the current project or globally:
 
 ```bash
 # Project-level
-nonoka-cli opencode init
+nonoka init
 
 # User-level
-nonoka-cli opencode init --global
+nonoka init --global
 ```
 
 3. Make sure your model API key is exported, then run:
@@ -132,11 +132,11 @@ Example output:
 
 ```
 nonoka-cli doctor
-✓ nonoka-cli 0.2.10
+✓ nonoka-cli 0.2.12
 ✓ Python 3.11
 ✓ opencode 1.18.2
-✓ provider nonoka-opencode-provider@0.2.16
-✓ nonoka framework 1.3.7
+✓ provider nonoka-opencode-provider@0.2.17
+✓ nonoka framework 1.3.8
 ✓ config ~/.config/nonoka/config.yaml
 ✓ API key DEEPSEEK_API_KEY set
 ✓ OpenCode provider config in /home/user/.config/opencode/opencode.json
@@ -403,7 +403,7 @@ similarity score without storing raw cache queries. `max_total_tokens` and
 is unavailable, `fail_on_unknown_cost: true` terminates the task rather than
 silently exceeding the cost budget.
 
-### `nonoka-cli opencode init`
+### `nonoka init`
 
 Generate or merge an `opencode.json` in the current directory and create
 `.opencode/agents/build.md` from your nonoka `system_prompt`. The generated
@@ -412,7 +412,8 @@ nonoka config path to the backend.
 
 ## OpenCode configuration
 
-`nonoka-cli opencode init` generates two things:
+`nonoka init` generates two things. `nonoka opencode init` remains as a
+backward-compatible, explicit spelling:
 
 1. `opencode.json` in the current directory, which wires OpenCode to the
    `nonoka-opencode-provider` package and sets HITL permissions.
@@ -429,7 +430,7 @@ A typical generated `opencode.json` looks like:
       "npm": "nonoka-opencode-provider",
       "name": "Nonoka",
       "options": {
-        "serverCommand": ["bash", "-c", "nonoka-cli --server 2>/tmp/nonoka-server.log"],
+        "serverCommand": ["/path/to/python", "-m", "nonoka_cli", "--server"],
         "cwd": ".",
         "configPath": "~/.config/nonoka/config.yaml"
       },
@@ -463,12 +464,12 @@ A typical generated `opencode.json` looks like:
 
 The `"tools": {"skill": false}` line disables OpenCode's native `skill:<name>`
 tool so it does not collide with nonoka's `load_skill` / `skill__<name>__<tool>`
-workflow. `nonoka-cli opencode init` writes this automatically.
+workflow. `nonoka init` writes this automatically.
 
 ## Prompt ownership
 
 Nonoka owns the canonical system prompt via `system_prompt` in
-`~/.config/nonoka/config.yaml`. When you run `nonoka-cli opencode init`, the
+`~/.config/nonoka/config.yaml`. When you run `nonoka init`, the
 command adapts that prompt and writes it to `.opencode/agents/build.md` so
 OpenCode uses it for its primary agent. OpenCode-specific guidelines (tool
 names, approval behavior, path conventions) are appended automatically; they are
@@ -482,10 +483,9 @@ When running inside OpenCode, HITL is handled by OpenCode itself. The generated
 Nonoka forwards OpenCode's native tool definitions to the model, approval
 dialogs render natively for `bash`, `read`, `write`, and `edit` operations.
 
-`nonoka-cli`'s own `cli.auto_approve` and `hitl.policy` settings only apply to
-standalone server / CLI mode. In OpenCode mode, permissions are governed by the
-`permission` block in `opencode.json`. To keep `nonoka.yaml` as the single
-source of truth, add a `permissions` block and re-run `nonoka-cli opencode init`:
+In OpenCode mode, `nonoka init` derives both generated permission blocks from
+`cli.auto_approve` and optional `permissions` overrides in `nonoka.yaml`. Add a
+`permissions` block and re-run `nonoka init` to keep YAML as the source of truth:
 
 ```yaml
 permissions:
@@ -495,8 +495,9 @@ permissions:
   edit: ask
 ```
 
-`cli.auto_approve: true` still auto-allows the core coding tools when no
-`permissions` block is present. For standalone mode, use `hitl.policy: auto`.
+`cli.auto_approve: true` auto-allows the core coding tools, including read-only
+`glob` and `grep`, before explicit overrides are applied. For standalone mode,
+`hitl.policy` still controls Nonoka-owned tool approval.
 
 ## External-tools mode
 
@@ -511,12 +512,14 @@ default. OpenCode sends its native tool list (e.g. `bash`, `read`, `write`,
   `Runner.resume_external_tools()`.
 
 To start external-tools mode, run OpenCode with the generated `opencode.json`;
-the provider spawns `nonoka-cli --server` automatically.
+the provider automatically spawns `python -m nonoka_cli --server` with the
+interpreter that generated the project config.
 
 ## MCP and Skill support
 
-nonoka-cli can merge MCP tools and lazy-loaded skills alongside OpenCode's
-native tools. Configure them in `~/.config/nonoka/config.yaml`:
+nonoka-cli can merge custom Python tools, MCP tools, and lazy-loaded skills
+alongside OpenCode's native tools. Configure them in
+`~/.config/nonoka/config.yaml`:
 
 ```yaml
 model: deepseek/deepseek-v4-pro
@@ -527,6 +530,9 @@ mcp_servers:
     command: npx
     args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/docs"]
 
+tool_paths:
+  - /home/user/.config/nonoka/tools
+
 skills:
   - code-review
   - nextjs-best-practices
@@ -537,6 +543,10 @@ Store each skill at `.agents/skills/<name>/SKILL.md` in the project or at `~/.ag
 - **MCP tools** are executed locally by nonoka-cli and are exposed with a
   `mcp__<server>__<tool>` namespace prefix so they do not collide with OpenCode
   native tools.
+- **Custom Python tools** discovered from `tool_paths` are executed locally by
+  nonoka-cli and exposed as `custom__<tool>` in OpenCode mode. Built-in CLI
+  file/shell tools are omitted there because OpenCode already supplies native
+  equivalents. Standalone mode keeps the original unprefixed tool names.
 - **Skills** use nonoka-agent's lazy `SkillRegistry`. Discovery reads names and descriptions without importing skill tools; enabled skill tools are resolved when the runtime catalog is built, while full guidance, its root directory, and bundled resource paths are loaded on-demand via `load_skill` and protected from normal context compaction. Skill tools are prefixed with `skill__<skill>__<tool>` in external-tools mode.
 
 Both MCP tools and skill tools remain available in standalone mode without any
@@ -702,7 +712,8 @@ here because they affect the TUI/HITL experience but cannot be fixed inside
 
 ## Server logs and request traces
 
-When running inside OpenCode, the provider spawns `nonoka-cli --server` as a
+When running inside OpenCode, the provider spawns the interpreter-pinned
+`python -m nonoka_cli --server` command as a
 long-lived NDJSON bridge. Server stderr is redirected by the provider to a
 per-working-directory log file so it does not pollute OpenCode's TUI:
 

{nonoka_cli-0.2.10 → nonoka_cli-0.2.12}/README.md

@@ -4,7 +4,7 @@ English | [简体中文](README.zh-CN.md)
 
 OpenCode backend for the [Nonoka](https://pypi.org/project/nonoka/) Agent framework.
 
-`nonoka-cli` runs as a stdio NDJSON bridge server (`nonoka-cli --server`) that
+Nonoka runs as a stdio NDJSON bridge server (`python -m nonoka_cli --server`) that
 talks to the `nonoka-opencode-provider` TypeScript package. When used inside
 OpenCode, Nonoka acts as the conversation/decision backend while OpenCode owns
 tool execution and human-in-the-loop (HITL) approval using its native tools.
@@ -28,18 +28,18 @@ After installing, configure your API key and run `nonoka`:
 
 ```bash
 # Interactive: it will ask for your key and save it to ~/.config/nonoka/.env
-nonoka-cli config init
+nonoka config init
 
 # Or set it manually
 export DEEPSEEK_API_KEY=<your-key>
 
-nonoka-cli doctor
+nonoka doctor
 nonoka
 ```
 
-`nonoka` is a shortcut for `nonoka-cli run` and starts the OpenCode TUI with the
-Nonoka backend. You can also use `nonoka run --message "<task>"` for one-shot
-CLI usage.
+`nonoka` is the primary command. It starts the OpenCode TUI when invoked without
+a subcommand, while `nonoka run --message "<task>"` provides one-shot CLI usage.
+The legacy `nonoka-cli` executable remains available for compatibility.
 
 `nonoka-cli` automatically loads `~/.config/nonoka/.env` and `./.env` on startup,
 so you don't need to `export` every time if you save the key in `.env`.
@@ -65,24 +65,24 @@ npm install -g nonoka-opencode-provider
    `~/.config/nonoka/.env`):
 
 ```bash
-nonoka-cli config init
+nonoka config init
 ```
 
 For scripted setups, use the non-interactive mode (you'll still need to set the
 API key via `.env` or `export`):
 
 ```bash
-nonoka-cli config init --yes --model deepseek/deepseek-v4-pro
+nonoka config init --yes --model deepseek/deepseek-v4-pro
 ```
 
 2. Generate an OpenCode config in the current project or globally:
 
 ```bash
 # Project-level
-nonoka-cli opencode init
+nonoka init
 
 # User-level
-nonoka-cli opencode init --global
+nonoka init --global
 ```
 
 3. Make sure your model API key is exported, then run:
@@ -103,11 +103,11 @@ Example output:
 
 ```
 nonoka-cli doctor
-✓ nonoka-cli 0.2.10
+✓ nonoka-cli 0.2.12
 ✓ Python 3.11
 ✓ opencode 1.18.2
-✓ provider nonoka-opencode-provider@0.2.16
-✓ nonoka framework 1.3.7
+✓ provider nonoka-opencode-provider@0.2.17
+✓ nonoka framework 1.3.8
 ✓ config ~/.config/nonoka/config.yaml
 ✓ API key DEEPSEEK_API_KEY set
 ✓ OpenCode provider config in /home/user/.config/opencode/opencode.json
@@ -374,7 +374,7 @@ similarity score without storing raw cache queries. `max_total_tokens` and
 is unavailable, `fail_on_unknown_cost: true` terminates the task rather than
 silently exceeding the cost budget.
 
-### `nonoka-cli opencode init`
+### `nonoka init`
 
 Generate or merge an `opencode.json` in the current directory and create
 `.opencode/agents/build.md` from your nonoka `system_prompt`. The generated
@@ -383,7 +383,8 @@ nonoka config path to the backend.
 
 ## OpenCode configuration
 
-`nonoka-cli opencode init` generates two things:
+`nonoka init` generates two things. `nonoka opencode init` remains as a
+backward-compatible, explicit spelling:
 
 1. `opencode.json` in the current directory, which wires OpenCode to the
    `nonoka-opencode-provider` package and sets HITL permissions.
@@ -400,7 +401,7 @@ A typical generated `opencode.json` looks like:
       "npm": "nonoka-opencode-provider",
       "name": "Nonoka",
       "options": {
-        "serverCommand": ["bash", "-c", "nonoka-cli --server 2>/tmp/nonoka-server.log"],
+        "serverCommand": ["/path/to/python", "-m", "nonoka_cli", "--server"],
         "cwd": ".",
         "configPath": "~/.config/nonoka/config.yaml"
       },
@@ -434,12 +435,12 @@ A typical generated `opencode.json` looks like:
 
 The `"tools": {"skill": false}` line disables OpenCode's native `skill:<name>`
 tool so it does not collide with nonoka's `load_skill` / `skill__<name>__<tool>`
-workflow. `nonoka-cli opencode init` writes this automatically.
+workflow. `nonoka init` writes this automatically.
 
 ## Prompt ownership
 
 Nonoka owns the canonical system prompt via `system_prompt` in
-`~/.config/nonoka/config.yaml`. When you run `nonoka-cli opencode init`, the
+`~/.config/nonoka/config.yaml`. When you run `nonoka init`, the
 command adapts that prompt and writes it to `.opencode/agents/build.md` so
 OpenCode uses it for its primary agent. OpenCode-specific guidelines (tool
 names, approval behavior, path conventions) are appended automatically; they are
@@ -453,10 +454,9 @@ When running inside OpenCode, HITL is handled by OpenCode itself. The generated
 Nonoka forwards OpenCode's native tool definitions to the model, approval
 dialogs render natively for `bash`, `read`, `write`, and `edit` operations.
 
-`nonoka-cli`'s own `cli.auto_approve` and `hitl.policy` settings only apply to
-standalone server / CLI mode. In OpenCode mode, permissions are governed by the
-`permission` block in `opencode.json`. To keep `nonoka.yaml` as the single
-source of truth, add a `permissions` block and re-run `nonoka-cli opencode init`:
+In OpenCode mode, `nonoka init` derives both generated permission blocks from
+`cli.auto_approve` and optional `permissions` overrides in `nonoka.yaml`. Add a
+`permissions` block and re-run `nonoka init` to keep YAML as the source of truth:
 
 ```yaml
 permissions:
@@ -466,8 +466,9 @@ permissions:
   edit: ask
 ```
 
-`cli.auto_approve: true` still auto-allows the core coding tools when no
-`permissions` block is present. For standalone mode, use `hitl.policy: auto`.
+`cli.auto_approve: true` auto-allows the core coding tools, including read-only
+`glob` and `grep`, before explicit overrides are applied. For standalone mode,
+`hitl.policy` still controls Nonoka-owned tool approval.
 
 ## External-tools mode
 
@@ -482,12 +483,14 @@ default. OpenCode sends its native tool list (e.g. `bash`, `read`, `write`,
   `Runner.resume_external_tools()`.
 
 To start external-tools mode, run OpenCode with the generated `opencode.json`;
-the provider spawns `nonoka-cli --server` automatically.
+the provider automatically spawns `python -m nonoka_cli --server` with the
+interpreter that generated the project config.
 
 ## MCP and Skill support
 
-nonoka-cli can merge MCP tools and lazy-loaded skills alongside OpenCode's
-native tools. Configure them in `~/.config/nonoka/config.yaml`:
+nonoka-cli can merge custom Python tools, MCP tools, and lazy-loaded skills
+alongside OpenCode's native tools. Configure them in
+`~/.config/nonoka/config.yaml`:
 
 ```yaml
 model: deepseek/deepseek-v4-pro
@@ -498,6 +501,9 @@ mcp_servers:
     command: npx
     args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/docs"]
 
+tool_paths:
+  - /home/user/.config/nonoka/tools
+
 skills:
   - code-review
   - nextjs-best-practices
@@ -508,6 +514,10 @@ Store each skill at `.agents/skills/<name>/SKILL.md` in the project or at `~/.ag
 - **MCP tools** are executed locally by nonoka-cli and are exposed with a
   `mcp__<server>__<tool>` namespace prefix so they do not collide with OpenCode
   native tools.
+- **Custom Python tools** discovered from `tool_paths` are executed locally by
+  nonoka-cli and exposed as `custom__<tool>` in OpenCode mode. Built-in CLI
+  file/shell tools are omitted there because OpenCode already supplies native
+  equivalents. Standalone mode keeps the original unprefixed tool names.
 - **Skills** use nonoka-agent's lazy `SkillRegistry`. Discovery reads names and descriptions without importing skill tools; enabled skill tools are resolved when the runtime catalog is built, while full guidance, its root directory, and bundled resource paths are loaded on-demand via `load_skill` and protected from normal context compaction. Skill tools are prefixed with `skill__<skill>__<tool>` in external-tools mode.
 
 Both MCP tools and skill tools remain available in standalone mode without any
@@ -673,7 +683,8 @@ here because they affect the TUI/HITL experience but cannot be fixed inside
 
 ## Server logs and request traces
 
-When running inside OpenCode, the provider spawns `nonoka-cli --server` as a
+When running inside OpenCode, the provider spawns the interpreter-pinned
+`python -m nonoka_cli --server` command as a
 long-lived NDJSON bridge. Server stderr is redirected by the provider to a
 per-working-directory log file so it does not pollute OpenCode's TUI:
 

{nonoka_cli-0.2.10 → nonoka_cli-0.2.12}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "nonoka-cli"
-version = "0.2.10"
+version = "0.2.12"
 description = "OpenCode backend for the Nonoka Agent framework"
 readme = "README.md"
 license = { text = "MIT" }
@@ -20,7 +20,7 @@ classifiers = [
   "Programming Language :: Python :: 3.13",
 ]
 dependencies = [
-  "nonoka>=1.3.7",
+  "nonoka>=1.3.8",
   "structlog>=24.0.0",
   "pydantic>=2.0",
   "pyyaml>=6.0",

{nonoka_cli-0.2.10 → nonoka_cli-0.2.12}/src/nonoka_cli/__init__.py

@@ -2,4 +2,4 @@
 
 from __future__ import annotations
 
-__version__ = "0.2.10"
+__version__ = "0.2.12"

{nonoka_cli-0.2.10 → nonoka_cli-0.2.12}/src/nonoka_cli/cli.py

@@ -3,6 +3,7 @@
 from __future__ import annotations
 
 import argparse
+import importlib.metadata
 import logging
 import os
 import sys
@@ -42,6 +43,14 @@ from nonoka_cli.utils.logging import setup_logging
 logger = structlog.get_logger("nonoka_cli.cli")
 
 
+def _version() -> str:
+  """Return the installed CLI version, including editable installs."""
+  try:
+    return importlib.metadata.version("nonoka-cli")
+  except importlib.metadata.PackageNotFoundError:
+    return "unknown"
+
+
 def _load_env_files() -> None:
   """Load .env files so config env-var substitution works transparently.
 
@@ -61,9 +70,14 @@ def _load_env_files() -> None:
 def _build_parser() -> argparse.ArgumentParser:
   """Build the argument parser."""
   parser = argparse.ArgumentParser(
-    prog="nonoka-cli",
+    prog="nonoka",
     description="Terminal frontend for the Nonoka Agent framework",
   )
+  parser.add_argument(
+    "--version",
+    action="version",
+    version=f"%(prog)s {_version()}",
+  )
   parser.add_argument(
     "--config",
     type=Path,
@@ -96,6 +110,7 @@ def _build_parser() -> argparse.ArgumentParser:
   subparsers = parser.add_subparsers(dest="command")
   config_cmd.add_subparser(subparsers)
   doctor_cmd.add_subparser(subparsers)
+  opencode_cmd.add_init_subparser(subparsers)
   opencode_cmd.add_subparser(subparsers)
   plugin_cmd.add_subparser(subparsers)
   run_cmd.add_subparser(subparsers)
@@ -116,28 +131,23 @@ def main() -> int:
   parser = _build_parser()
   args = parser.parse_args()
 
-  # Load .env files early so configuration and LLM providers see API keys.
-  _load_env_files()
+  log_level = (
+    logging.DEBUG if args.debug
+    else logging.INFO if args.verbose
+    else logging.WARNING
+  )
+  setup_logging(level=log_level, console=args.verbose or args.debug)
 
+  # Load .env files after logging is configured so the debug-only path message
+  # does not leak into normal command output.
+  _load_env_files()
   if args.server:
     return server_main(config_path=args.config, model=args.model)
 
   if args.command and getattr(args, "func", None):
-    log_level = (
-      logging.DEBUG if args.debug
-      else logging.INFO if args.verbose
-      else logging.WARNING
-    )
-    setup_logging(level=log_level, console=args.verbose or args.debug)
     return args.func(args)
 
   # No subcommand given: launch the OpenCode TUI by default.
-  log_level = (
-    logging.DEBUG if args.debug
-    else logging.INFO if args.verbose
-    else logging.WARNING
-  )
-  setup_logging(level=log_level, console=args.verbose or args.debug)
   return run_cmd.launch_tui(args)