Summary
The harness is presented as one of OMA's two reliability axes — a cross-cutting safety guarantee. In practice only ai-infra ships a runtime harness. The other three plugins carry no hooks/, no PreToolUse entry, and no policies: block in their .oma.yaml. A user who installs only agenticops (the autonomous-deploy / cost-governance plugin) gets zero hard enforcement.
Evidence
$ for p in ai-infra agenticops aidlc modernization; do
echo "$p: $(ls plugins/$p/hooks/ 2>/dev/null | tr '\n' ' ' || echo NONE)"; done
ai-infra: enforce.py harness-rules.json hooks.json
agenticops: (none)
aidlc: (none)
modernization: (none)
$ grep -c 'policies:' plugins/*/*.oma.yaml
ai-infra:1 agenticops:0 aidlc:0 modernization:0
plugins/ai-infra/hooks/hooks.json uses matcher: ".*", so while ai-infra is enabled its PreToolUse enforcer does cover all tools session-wide. But the 5 rules it ships are all infra-scoped:
deny-eks-mutating-kubectl, deny-eks-mcp-write, deny-secret-file-write,
deny-secret-file-edit, deny-secret-file-shell-redirect
There is no enforcement for the operations surface that agenticops actually drives — e.g. an autonomous Deployment below approval_state: approved, a retry/cost-budget breach, or an incident auto-rollback. Those are described in harness-engineering.md as ✅ patterns, but they are realized as skill-level prose, not PreToolUse denials.
Impact
- "Install a plugin → get harness safety" only holds if
ai-infra is among the installed plugins.
- The plugin most in need of hard guardrails (
agenticops, which proposes and executes deploys between checkpoints) is the one with none.
- Disabling/uninstalling
ai-infra silently removes all enforcement for the other three.
Proposed fix
- Add a
policies: block + compiled hooks/ to agenticops covering its own risk surface: deny Deployment actions when approval_state != approved, deny destructive rollback without an Incident ref, enforce Budget breach action_on_breach.
- Consider extracting the secret-file deny rules (
deny-secret-file-*) into a shared baseline every plugin compiles in, so secret protection does not depend on ai-infra being installed.
- Update
harness-engineering.md to state explicitly which plugin each ✅ pattern's enforcement ships in (today it reads as if the axis is uniform).
Filed from a full-site/repo re-verification of the "install a plugin → get the dual-axis" UX.
Summary
The harness is presented as one of OMA's two reliability axes — a cross-cutting safety guarantee. In practice only
ai-infraships a runtime harness. The other three plugins carry nohooks/, noPreToolUseentry, and nopolicies:block in their.oma.yaml. A user who installs onlyagenticops(the autonomous-deploy / cost-governance plugin) gets zero hard enforcement.Evidence
plugins/ai-infra/hooks/hooks.jsonusesmatcher: ".*", so whileai-infrais enabled its PreToolUse enforcer does cover all tools session-wide. But the 5 rules it ships are all infra-scoped:There is no enforcement for the operations surface that
agenticopsactually drives — e.g. an autonomousDeploymentbelowapproval_state: approved, a retry/cost-budget breach, or an incident auto-rollback. Those are described inharness-engineering.mdas ✅ patterns, but they are realized as skill-level prose, not PreToolUse denials.Impact
ai-infrais among the installed plugins.agenticops, which proposes and executes deploys between checkpoints) is the one with none.ai-infrasilently removes all enforcement for the other three.Proposed fix
policies:block + compiledhooks/toagenticopscovering its own risk surface: denyDeploymentactions whenapproval_state != approved, deny destructive rollback without anIncidentref, enforceBudgetbreachaction_on_breach.deny-secret-file-*) into a shared baseline every plugin compiles in, so secret protection does not depend onai-infrabeing installed.harness-engineering.mdto state explicitly which plugin each ✅ pattern's enforcement ships in (today it reads as if the axis is uniform).Filed from a full-site/repo re-verification of the "install a plugin → get the dual-axis" UX.