* feat(memory): add structured schema and usage index
Add schema-v1 frontmatter for memory files, including stable ids, deterministic signatures, soft delete metadata, TTL handling, and migration support for legacy stores.
Track recalled memories in usage_index.json so retrieval can prioritize useful memories and auto-dream can review stale unused entries before pruning.
Keep project and ohmo memory backends aligned under the same behavior while preserving runtime compatibility for unmigrated Markdown files.
* fix(memory): make backend migration defaults explicit
The Windows PowerShell installer (scripts/install.ps1) hard-coded openh.exe
as the expected binary and printed "Launch (PowerShell): openh" in the
final instructions. The `openh` console-script alias was added in ce84a6a,
which landed after the v0.1.6 tag — so `pip install openharness-ai`
(the default install path) fetches a wheel whose entry_points.txt only
declares `oh`, `ohmo`, and `openharness`. openh.exe is never created, and
users follow the install banner straight into a "not recognized" error
(issue #144).
Instead of requiring a new PyPI release before the installer becomes
correct, detect which launcher the wheel actually produced and guide the
user to it. Preference order: openh (no shell collisions) -> openharness
(no collisions, always present) -> oh (collides with PowerShell's
Out-Host alias unless invoked as oh.exe).
Verification now succeeds against whichever launcher exists, and the
final "Next steps" block recommends the matching command along with the
relevant Out-Host caveat.
Co-authored-by: José Maia <glitch-ux@users.noreply.github.com>
The existing srt/bubblewrap sandbox only wraps shell commands — file I/O
tools bypass it entirely via direct Python calls. This adds Docker as a
second sandbox backend that provides container-level isolation for tool
execution while keeping the engine and API keys on the host.
- Add DockerSandboxSettings with image, resource limits, and env config
- Add backend field to SandboxSettings ("srt" or "docker")
- Implement DockerSandboxSession: long-running container per session
- Route shell, glob, and grep subprocess calls through docker exec
- Add path validation for file tools when Docker sandbox is active
- Auto-build default sandbox image (python:3.11-slim + ripgrep + git)
- Network isolation: --network=none by default, bridge when domains allowed
- Lifecycle integration: container starts/stops with the session
- atexit safety net for cleanup on unexpected exit
- 34 unit tests, 19 E2E tests (require Docker daemon)
Co-authored-by: José Maia <glitch-ux@users.noreply.github.com>
Python 3.11+ blocks system-wide pip install. Now the installer creates
~/.openharness-venv, installs into it, and adds venv/bin to PATH via
shell profile (~/.zshrc or ~/.bashrc).
A lightweight open-source Python implementation of the Agent Harness architecture.
44x lighter than Claude Code (11K vs 512K lines), 98% core tool coverage.
- 43 tools with Pydantic validation and parallel execution
- Skills system compatible with anthropics/skills (17+ tested)
- Plugin system compatible with claude-code/plugins (12+ tested)
- API retry with exponential backoff
- Multi-level permissions with path rules
- React/Ink TUI with "Oh my Harness!" branding
- 114 unit tests + 6 E2E test suites
- MIT License
Yang XiuYuan