slicefsm-omp

The omp build of the slicefsm harness. Same harness as slicefsm, plus a native omp/pi extension so the enforcement (block illegal tools, hide off-phase tools, log edits, inject the affordance) runs in omp — which has no Claude-style command hooks.

A deterministic slice harness for AI coding agents. It turns the workflow into a finite state machine. Hooks gate which tools run in each state and inject only the current state's prompt. The result: the AI cannot skip steps, cannot edit outside the current slice, and cannot read the whole codebase — and each session loads far fewer tokens.

Why

Typical AI agents read too many files, change too much at once, push past unapproved directions, and call it done without tests. slicefsm bounds all four:

• Vertical slices. A feature is split into small, user-visible slices. The human approves them before any code is written.
• Bounded context. get_slice_context serves the slice's own module in full, dependencies as signatures only, and siblings as names. Dependency bodies come one at a time via expand_symbol.
• Hook-enforced FSM. A PreToolUse hook denies tools that are illegal in the current state. This is a real block, not a prompt request.
• Human owns approval and scale. Approval is an out-of-band terminal command the AI cannot run.

See DESIGN - Deterministic Slice Harness.md for the full model.

Install

curl -fsSL https://raw.githubusercontent.com/hionpu/slicefsm-omp/master/install.sh | bash --cli omp

This installs the python package + MCP server, registers MCP in .omp/mcp.json, and installs the omp extension that enforces the FSM.

omp (manual)

Two commands — the python package and the omp plugin:

pip install git+https://github.com/hionpu/slicefsm-omp.git   # the python harness
omp plugin install slicefsm-omp@0.2.0                        # the omp plugin (npm)

The plugin ships a root mcp.json, which omp auto-discovers for any installed plugin. So that one omp plugin install registers both layers at once: the MCP server (the slicefsm tools) and the enforcement extension. No .omp/mcp.json editing needed.

There is no always-on rules doc by design: the workflow is driven by the visible toolset (only legal tools are shown per phase), the per-turn [slicefsm] affordance line, the tool descriptions, and deny reasons. That keeps per-turn tokens minimal — an always-on doc would also be useless when the hook is down, since the MCP tools share the same python and would be down too.

Use the npm name@version form. Do not use omp plugin install github:hionpu/slicefsm-omp: current omp mis-parses non-npm specifiers (github:/file:) in extractPackageName, reads the wrong node_modules path, and fails with "Failed to parse JSON". The name@version form parses correctly.

The extension spawns python -m slicefsm.hook, so the python package must be on the same python omp runs (set SLICEFSM_PYTHON to override). It fails OPEN: if python or the package is missing, omp keeps working without enforcement.

Verify it works

The extension adds no tools — it blocks/hides/logs/injects. So you verify it by signal, not by a new tool in the list:

• Loaded: omp plugin doctor shows plugin:slicefsm-omp with no warnings.
• Active: run /slicefsm in omp. In a slicefsm project (one with a .harness/ dir) it reports active — <phase>; elsewhere inactive; if the python hook can't be reached it warns (fix SLICEFSM_PYTHON).
• Footer: in a slicefsm project the footer shows slicefsm: <phase> and updates as the phase changes.
• Enforcement: in a slicefsm project at NO_ACTIVE_FEATURE, an edit is blocked with a reason; edit/write are hidden until IN_PROGRESS.

Outside a slicefsm project (no .harness/) the extension is inert — it never spawns python, blocks, or hides anything. The slicefsm tools themselves (submit_feature, get_slice_context, expand_symbol, …) come from the MCP server, which the plugin's bundled mcp.json registers automatically on install — they show up in omp's tool list once the python package is importable. tree-sitter is used inside those tools to parse C#/C++/Python; it is not a tool.

Other clients (Claude Code, Pi, opencode) still work via the original command-hook path — pass --cli claude,pi,opencode.

Update/uninstall: .../slicefsm-omp/master/update.sh / uninstall.sh.

State machine

A repo holds several features; one is active. The active feature's phase:

NO_FEATURE → [DISCOVERY] → SLICING → AWAITING_APPROVAL → IN_PROGRESS → FEATURE_DONE

IN_PROGRESS holds N slices, implemented one at a time (sequential):
  proposed → implement ⇄ (run_verify) → done
  implement → stuck (N fails) → (harness unstick) → implement

harness pause / resume <id> / switch <id> move between features (clean git tree required).

Components

Module	Role
state.py	the FSM + atomic state IO (.harness/state.json)
policy.py	scale triage, read-policy derivation, thresholds
context_engine.py + backends/	repo-map, 3-bucket slice context, expand (Python, C#, C++ via tree-sitter)
ops.py / server.py	the 8 MCP tools
hook.py	the slicefsm-hook dispatcher (5 events incl. activetools)
cli.py	the human-only harness CLI
omp-extension/	omp/pi extension bridging tool events to hook.py

Develop

pip install -e ".[dev]"
pytest

Apache-2.0.