omp packages

@awebai/oats-pi0.65.0

OATS pi runtime bridge — memory session events and pre-workspace bootstrap over the runtime-neutral @awebai/oats kernel

juanre Published 16 hours ago MIT ~15.6K downloads/mo

Untested on omp

This is a pi package. No one has reported whether it works on omp yet. If you try it, add your result below.

Did it work for you?

Result

One report per person. A new report replaces your old one.

Reports 0

No reports yet.

Readme

@awebai/oats-pi

Pi harness bridge for OATS.

The runtime-neutral kernel and universal oats CLI live in @awebai/oats. Publishes in lockstep with the kernel (same version from the same release tag). This bridge registers no operational tools. It only:

  • exposes oats-getting-started before an OATS workspace exists (the acquisition funnel);
  • contributes the instance-local .agents/skills set inside a spawned instance;
  • holds an instance's opening task (@TASK.md) on pi's own path until no turn another extension started is active, so pi runs it exactly once, as its input processing made it, instead of refusing it. It never waits for the task's own run: pi 1.2 and later count that run as active from before its before_agent_start, and queue a message sent meanwhile into it, after the task. It never sends, re-sends or alters a message. The exception: an extension loaded behind the bridge that starts a turn (or awaits I/O while one starts) inside its own input handling of the opening prompt, or on a pi before 1.2 in its before_agent_start, can still make pi refuse it, because pi's interactive mode sends the initial message with no streamingBehavior. @awebai/pi has no such handler. A session that shuts down (a reload, say) releases the hold, and pi then runs or refuses the task by its own rules;
  • journals compaction summaries and sends resume nudges when the active knowledge capability created STATE.md/log.md. A startup gets the nudge only when pi kept an earlier session of the home (pi files a session once it holds a message), so a fresh home's first turn is its opening task. What STATE.md says decides nothing, and the bridge writes nothing to tell. Knowledge ownership, read/capture instructions, judgment and delivery remain capability-owned.

Skill resolution itself is owned by the kernel: spawn materializes the exact kernel + soul + active-capability set into each instance's .agents/skills and launches pi with that directory as an explicit skill path. Ambient skills (user-level, packages, work tree) coexist with the OATS-composed set.

npm install -g @awebai/oats
pi install npm:@awebai/oats-pi

OATS publishes both packages from the same version tag. Reload pi after an adapter install or upgrade.

All lifecycle/config/package operations use the shell-visible CLI: oats status, oats spawn, oats doctor, oats install, oats trust, oats use, and oats retire.

With OKF v2, state/log/notes stay episodic while accepted expertise lives in external bases exposed as immutable reader views. The Pi bridge is not a harvester or knowledge store. Independent workers select their own harness/model; source retirement relies on durable evidence custody, not this adapter's presence. V0.23.1 integration is prepared, not yet a publication claim.