0.2.0: deploy an adapter into a workspace, in place

deploy — the second half of hermit's OpenCode request.

0.1.x could only convert: emit a configuration into a directory of its own, which
you then copied into a project. This release adds the other route, which is what
hermit issue #35 and the
roadmap in #37 §3 ask for.

pip install https://github.com/argszero/hermit-opencode/releases/download/0.2.0/hermit_opencode-0.2.0-py3-none-any.whl
hermit-opencode deploy path/to/adapter --workspace /path/to/your/project

What deploy writes

The same four parts convert emits, in place: .opencode/context.md and its
instructions entry, .opencode/skills/, .opencode/agents/ (mode: subagent),
and opencode.json's mcp entry. Plus .opencode/adapter/ — its copy of the
adapter, namespaced there because a project may already have an adapter/
directory — and .opencode/hermit-opencode.json, the record that makes a
workspace this tool's own.

How it treats a tree that is not its own

• It merges opencode.json; it never replaces it. Your other keys, your own
  instructions entries and your other MCP servers stay.
• It refuses a workspace it did not create, and --force adopts one, printing
  which of its own files that adoption overwrote ("adopted": ["opencode.json"]).
• It never deletes anything. A role or skill an earlier deploy wrote and the
  adapter no longer declares stays where it is; removing it is yours to do.
• Two refusals hold even with --force, because merging is the only thing it does
  to your files and both mean it cannot merge: an opencode.json that is not valid
  JSON, and one whose instructions or mcp key holds the wrong type. It stops
  and names the file instead of overwriting what it could not read.
• No managed block in AGENTS.md — the context travels as .opencode/context.md
  through instructions, which OpenCode combines with your AGENTS.md, so your
  file is never edited. No lifecycle hooks (refused, as convert refuses them,
  unless --allow-lossy), no container isolation, no per-task context_tool.

convert and 0.1.x's command spelling are unchanged: hermit-opencode <adapter> --output DIR still converts.

Which hermit this needs

Hermit is needed only for the tool server, and the mcp entry requires one that
reads the .hermit/adapter.yaml + exports.yaml layout: hermit-harness 0.2.0
or later, from PyPI.

pip install "hermit-harness>=0.2.0"
python -c "from hermit.adapter import manifest; print(manifest.MANIFEST)"   # .hermit/adapter.yaml

hermit-harness 0.1.0 cannot serve the embedded adapter: its manifest reader wants
adapter.yaml at the adapter root, the layout hermit replaced in its own #41.
Nothing in convert or deploy needs hermit at all; only the server does.

What was verified

• 25 tests pass, no network and no hermit installed. The new ones cover the
  four paths that matter in somebody else's tree: a fresh deploy; a second deploy
  that is byte-identical and leaves a user file, a user skill and the audit log
  untouched; a workspace this tool did not create, refused with nothing written;
  and --force adopting one and reporting what it overwrote.
• A real deployment, then a real MCP exchange. A project holding its own
  main.py and AGENTS.md was adopted with --force; both survived byte for byte.
  The mcp command the deploy emitted was then run from the workspace with
  cwd: ".", PYTHONPATH cleared, under hermit-harness 0.2.0 from PyPI:
  initialize / tools/list / tools/call returned
  count_words('one two three') -> {"count": 3}, exit 0, and appended to
  .opencode/audit/tool-calls.jsonl inside the workspace.
• The deployed opencode.json validates against https://opencode.ai/config.json
  (Draft202012, schema vendored in the repository), with cwd: "." and no absolute
  path anywhere in it.
• The install command at the top was run from a clean virtualenv with
  PYTHONPATH cleared, so PyYAML 6.0.3 was genuinely fetched; both convert and
  deploy then ran from that install.

What was NOT verified

No live OpenCode session has ever loaded this output — convert's or
deploy's. No OpenCode credentials or model backend were available, so the
end-to-end path stops at the MCP server: the configuration is schema-valid and its
server command works, but "OpenCode started, read .opencode/, and used the skill
and subagent" is unproven. A schema-valid configuration is not a loaded one.

deploy deserves that caveat more than convert does, because it writes into a
project you already have. Run it first in a fresh directory, or in a tree under
version control.

Assets

• hermit_opencode-0.2.0-py3-none-any.whl — sha256 853b8097f5f3783ad8515b42007f2a89fc707161a1c350ac3e97fff0f3c56fd8
• hermit_opencode-0.2.0.tar.gz — sha256 8c984a0d233c84e196ed7a98461a82268d49b614fdd2914f434660d9c231f246

0.1.1's tag and release are untouched. Its corrected notes still apply to that
version, including the withdrawal of the "install hermit from git" advice.