oc_orchestrator
Loading...
Searching...
No Matches
oc_orchestrator Namespace Reference

Namespaces

namespace  agent_instances
namespace  dispatch
namespace  hub
namespace  hub_file
namespace  hub_manage
namespace  plan_inventory
namespace  plan_manage
namespace  plan_status
namespace  plans
namespace  state_observer
namespace  wordgen
namespace  work_queue
namespace  work_queue_file
namespace  work_queue_manage
namespace  worktree_env

Detailed Description

The Option C dispatcher: plans, worktrees, identities, launch briefs.

Purpose
-------
Plan 270. This package is the dispatch layer that used to live inside
``oc_chat`` as eight core modules and two CLIs. It takes a plan file, a
git repository and a runtime instance registry, and produces the four
things a worker needs: a branch, a worktree with its own verified venv,
an ``agent-NNN`` identity, and a rendered launch brief — plus the
``.PLAN_STATUS.md`` lifecycle the worker reports through.

Responsibilities
----------------
- Package marker only. Every module is imported by name
  (``from oc_orchestrator.dispatch import dispatch``) so that asking for
  a plan list never drags the model validator, the YAML reader and the
  SQLite registry in behind it — the import-closure discipline plan 257
  bought and this package inherits.

Diagnostics
-----------
Domain: OC_CHAT.MAIN
Levels:
    L2 - lifecycle events
    L3 - semantic details
    L4 - deep tracing (module load)

Contracts
---------
- This module imports nothing beyond ``oc_diagnostics``: a consumer that
  imports the package name alone pays for no submodule.
- The ``_dbg`` domain stays ``OC_CHAT.MAIN`` across the whole package.
  The log vocabulary is a consumer-visible contract (plan 270 P3): an
  operator grepping their diagnostics for a dispatch reads the same
  domain before and after the split.

Dependencies
------------
- oc_diagnostics (structured debug logging via _dbg)