Pat Sukprasert
9a3c90594f
Final Phase-1 PR of the modular native-harness registry refactor: move registry-parallel enumerations onto HarnessCapabilities. - Add a fork_history axis (ForkHistory enum: none/rebuild/preamble) to HarnessCapabilities, declared per harness in _BUILTIN_CAPABILITIES. Derive the server's two fork-history gating frozensets in _sessions/common.py from it instead of hand-listing. The derivation emits each canonical id plus its reversed native-<key> spelling, because native-claude/native-codex/native-cursor are valid ids canonicalize_harness passes through unchanged and the read sites match on the canonicalized id (guarded by the existing reversed-spelling fork test) — so the derived sets are a superset of the prior literals. - Add optional shell_tool_name / shell_tool_prompt fields carrying the harness bench's shell-tool provocation; delete the bench's hardcoded _NATIVE_TOOL_PROVOCATION table and read the fields off capabilities in native_vendor() (byte-identical (tool_name, prompt) per harness). - Delete the dead _HARNESS_MODULES literal in runtime/harnesses/__init__.py (~120 lines, overwritten unconditionally by harness_modules() next line). - Extend the drift-guard tests in test_harness_capabilities.py. Scope kept tight to the doc's mandate: sets that would need new NativeCodingAgent identity fields (_ANTIGRAVITY_FAMILY_HARNESSES, _PROVIDER_RESOLUTION_HARNESS, *_NATIVE_TERMINAL_ROLE) are left as-is; noted as follow-ups. Co-authored-by: Isaac Signed-off-by: Pat Sukprasert <pattara.sk127@gmail.com>
41 lines
1.7 KiB
Python
41 lines
1.7 KiB
Python
"""
|
|
Harness package — per-conversation subprocesses that implement a
|
|
subset of the Omnigent REST API.
|
|
|
|
See ``designs/SERVER_HARNESS_CONTRACT.md`` for the full contract.
|
|
The harness IS an HTTP service speaking the same Pydantic models AP
|
|
serves to external clients (re-use ``omnigent.server.schemas`` —
|
|
there is no separate protocol module).
|
|
|
|
This package contains:
|
|
|
|
- ``_HARNESS_MODULES``: registry mapping harness name (the value of
|
|
``spec.executor.harness`` in an agent spec) to the fully-qualified
|
|
Python module path that exports a zero-argument ``create_app() ->
|
|
FastAPI``. Populated as per-harness wraps land (Phase 1 step 4).
|
|
- ``process_manager``: ``HarnessProcessManager`` — owns
|
|
per-conversation subprocess lifecycle.
|
|
- ``_runner``: shared ``python -m`` entrypoint that any registered
|
|
harness's ``create_app()`` is served through.
|
|
|
|
The package directory is intentionally small. Behavior lives in the
|
|
sibling modules; this ``__init__.py`` is just the registry.
|
|
"""
|
|
|
|
from __future__ import annotations
|
|
|
|
from omnigent.harness_plugins import harness_modules
|
|
|
|
# Harness-name -> fully-qualified module path, sourced from the harness
|
|
# registry (built-ins + installed community plugins). Each module must
|
|
# export ``create_app() -> FastAPI``; the runner imports the module, calls
|
|
# the factory, and serves the result over a Unix socket. The historical
|
|
# mutable-dict surface is preserved (tests inject fixture entries by dict
|
|
# mutation), but the contents come from the dynamic registry, not a literal.
|
|
|
|
# Keep the historical mutable dict surface while sourcing builtins and
|
|
# community plugins from the dynamic registry.
|
|
_HARNESS_MODULES = harness_modules()
|
|
|
|
__all__ = ["_HARNESS_MODULES"]
|