nsaspy/prolog-rlm

Fork 0

[EPIC][cyber-harness] Generic Prolog-RLM cyber reasoning harness for Hackmode/Hackpert #409

New issue

Open

opened 2026-09-08 01:29:20 +00:00 by nsaspy · 2 comments

nsaspy commented

2026-09-08 01:29:20 +00:00

Owner

Mission

Build the generic Prolog-RLM harness contract needed by Hackmode/Hackpert for cyber reasoning, while preserving the canonical repository boundary in #141.

This is the upstream half of lost-rob0t/hackmode#28.

The target is not to move Hackmode, Hackpert, cyber tools, target state, Tek9, LISH, or operation authority into prolog-rlm. The target is to make prolog-rlm expose a complete reusable reasoning/expert/session interface that Hackmode can consume as its symbolic / recursive / generative reasoning tier.

lost-rob0t/hackmode
  Hackmode operation + scope + target/assets
  Hackpert objective / graph / KB
  passive|active authority
  cyber tools/providers/effects
  LISH / Emacs / hackmoded
          |
          | bounded typed host contract
          v
lost-rob0t/prolog-rlm
  reasoning modes
  expert registry/routing
  Spec / Plan / Verify / Repair
  context + retrieval
  agents/subagents/recursion
  provider/model fallback
  capability/authority/effect abstractions
  traces/usage/structured outcomes

Dependency direction remains:

Hackmode/Hackpert -> public prolog-rlm APIs

prolog-rlm must not import or depend on Hackmode product code.

Existing authorities to reuse

#141 — canonical downstream-product / reusable-core boundary.
#335 — canonical reasoning modes: direct, symbolic, symbolic-recursive, auto.
#376 — first-class Prolog expert registry/routing/invocation and closed-loop expert architecture.
#387 — Requirement -> Knowledge -> Plan -> Experts -> VERIFY -> Repair -> Review integration loop.
#367 — completed first-class host-bridge lesson: downstream harnesses must use the canonical machine/runtime interface rather than hand-wire a tiny incompatible subset.
lost-rob0t/hackmode#24 — Hackpert expert layer over canonical Hackmode state.
lost-rob0t/hackmode#27 — Hackpert active typed action/state-delta orchestration.
lost-rob0t/hackmode#29 — open objective loop; authority mode is orthogonal to reasoning strategy.
lost-rob0t/hackmode#28 — downstream Prolog-RLM generative/escalation integration.

Do not create another scheduler, provider runtime, capability model, authority plane, effect ledger, verifier stack, or model history.

Critical semantic split

Hackmode already has two independent axes. Preserve them exactly.

Host authority — owned by Hackmode

passive
active

passive means reasoning/inspection only. active means Hackmode may admit typed effects through its own scope/capability/provider/state boundary.

Reasoning strategy — owned by Prolog-RLM

direct
symbolic
symbolic-recursive
auto

A strategy switch is never an authority change.

Examples:

passive + symbolic
passive + symbolic-recursive
active  + symbolic
active  + direct
active  + auto

Moving from symbolic to direct or recursive reasoning must not grant a tool, widen target scope, mutate Hackmode state, or bypass Hackmode's active-effect admission.

Canonical flow

Hackmode operation scope + Frozen objective/SPEC
        ↓
bounded graph / KB / evidence projection
        ↓
Prolog-RLM session + requested reasoning strategy
        ↓
expert applicability / routing (#376)
        ↓
typed plan / subgoals / recursive expert or RLM work
        ↓
need external observation or action?
        ↓
host capability request
        ↓
Hackmode validates operation scope + authority + capability + budget
        ↓
Hackmode provider/effect execution OR structured denial
        ↓
typed observation/evidence returned to Prolog-RLM
        ↓
update reasoning state
        ↓
VERIFY exact unchanged objective/SPEC
        ↓
satisfied -> structured result
otherwise -> diagnose / repair / replan / bounded continuation

The model never directly owns the Hackmode effect path.

Track A — first-class host harness/session contract

Expose a reusable host-facing boundary sufficient for a non-Prolog product such as Common Lisp Hackmode to create and drive a Prolog-RLM run without reimplementing runtime semantics.

The boundary should support semantics equivalent to:

open/attach session or run
supply bounded context/facts/references
supply Frozen Spec/objective reference
select/inspect reasoning mode
register/project host capabilities as closed schemas
step/run/continue
answer host capability requests
cancel
inspect status/trace/usage/evidence
close/release

Exact API/transport follows current repository conventions. Prefer the canonical machine/runtime protocol and public library APIs; do not add a Hackmode-only wire protocol if the generic one can be extended.

Stable run/session/correlation identities are required.

Track B — host capability adapter contract

A downstream host must be able to expose typed capabilities to Prolog-RLM while keeping concrete implementations downstream.

Required invariants:

registration/visibility != capability possession != host authorization != effect admission;
closed argument/result schemas;
stable capability IDs + versions;
bounded output/time/cancellation semantics;
structured deny/blocked/error/uncertain outcomes;
request/result correlation and provenance;
no ambient shell, network, filesystem, database, browser, or target authority in core;
no executable callback/closure serialized into model-visible data;
a host may expose read-only observations in passive mode while rejecting all effectful requests.

Hackmode owns concrete recon, browser, fuzzing, capture, network, provider, mutation, and persistence implementations.

Track C — cyber expert/profile composition without cyber authority in core

The core should support a host-defined cyber expert/profile catalog using #376's generic expert contract rather than hard-coding exploit logic into the runtime.

A downstream profile should be able to register expert roles such as:

recon / attack-surface reasoning
source-assisted analysis
vulnerability-intelligence correlation
evidence/corroboration
objective verification
strategy/plan synthesis
repair/recovery
review/critic

Those names are examples of downstream registrations, not a fixed core ontology.

Core owns selection/invocation/explanation mechanics. Hackmode owns the actual cyber facts, expert rule packs, target semantics, operation policies, and executable cyber capabilities.

Track D — Hackpert reasoning-mode convergence

Make lost-rob0t/hackmode#29/#28 able to adapt cleanly to #335 instead of maintaining a second incompatible reasoning-mode enum.

Required mapping direction:

Hackpert reasoning strategy -> canonical Prolog-RLM reasoning mode
Hackpert authority mode      -> remains separate Hackmode host state

The integration must expose requested/effective mode and selection reason to Hackmode so LISH can explain transitions.

Symbolic-first / direct-fallback policy may be a Hackmode policy over the generic core modes; it must not require a forked Prolog-RLM runtime.

Track E — bounded graph/KB/context projection

Hackmode must be able to provide operation knowledge without giving Prolog-RLM direct Tek9 authority.

Support reusable typed projections/references for:

current objective/Frozen Spec;
operation/target identity and allowed scope;
current assets/relations/findings;
execution/tool evidence;
operational KB facts/hypotheses;
long-term knowledge references where explicitly allowed;
prior negative evidence / failed paths;
budget/status information.

Large context should use existing external-context/retrieval mechanisms rather than flattening the entire Hackmode graph into one model prompt.

Prolog-derived conclusions must remain distinguishable from host-observed evidence.

Track F — explicit generative fallback

Support Hackmode's intended escalation use from hackmode#28:

known deterministic experts/rules stall
  -> explicit Prolog-RLM generative fallback
  -> candidate rule / plan / pattern / KB delta
  -> schema validation + provenance
  -> Hackpert/Common Lisp accepts, rejects, or constrains candidate
  -> canonical execution remains downstream

Requirements:

deterministic/expert operation works with zero model calls where possible;
model usage occurs only through the canonical provider runtime and is traced/metered;
generated content is candidate data, never trusted executable Prolog or raw host command authority;
generated actions cannot bypass Hackmode's typed capability/effect boundary;
returned candidates retain model/prompt/compiler/source-evidence provenance.

Track G — verification and objective preservation

Hackmode's objective/SPEC is the definition of success. Reasoning mode changes, recursion, model fallback, or repair cannot rewrite it to manufacture completion.

The harness must allow downstream domain-specific verification while using the generic Spec/Verify/evidence contract.

Final success requires fresh evidence satisfying the unchanged Frozen Spec/objective. Model prose is not proof.

Track H — deterministic cyber-harness conformance fixture

Add a synthetic/local fixture, not a real-world target, proving the host contract end to end.

Fixture should model a tiny operation with:

a frozen objective;
a bounded asset/evidence graph;
one read-only observation capability;
one effectful host capability;
a deterministic expert path;
an initial evidence gap;
one denied passive-mode effect request;
an admitted active-mode equivalent under explicit host policy;
fresh evidence after the effect;
trusted verification;
cancellation / budget / replay assertions.

No Internet access or external target is required for the core conformance test.

Acceptance

prolog-rlm has one generic host harness/session surface sufficient for Hackmode without importing Hackmode code.
Hackmode can supply bounded typed graph/KB/evidence context and keep Tek9/canonical state downstream.
Hackmode can expose host capabilities through closed schemas while retaining concrete execution and authorization downstream.
passive|active authority remains orthogonal to direct|symbolic|symbolic-recursive|auto reasoning.
Passive mode can run useful expert reasoning with zero effect dispatch.
An effectful request in passive mode is structurally denied before execution.
The equivalent active-mode request still crosses Hackmode's own scope/capability/effect gate.
Expert routing composes with #376 rather than creating a cyber-only expert runtime.
Recursive work uses existing RLM/subagent/global budget/cancellation semantics.
Explicit model fallback is separately traced/metered and cannot widen authority.
Generated rules/plans/KB deltas are validated candidate data with provenance, not executable authority.
Final success is evidence-backed against the unchanged Frozen objective/SPEC.
Synthetic deterministic conformance fixture passes with provider disabled on the pure-expert path.
Cancellation terminates pending nested reasoning/host requests without later effects.
Replay/trace can explain mode selection, expert selection, capability request, host admission/denial, evidence, fallback usage, and stop reason.
Existing direct library callers and other downstream harnesses remain supported; no Hackmode-specific dependency leaks into core.

Downstream integration acceptance (`lost-rob0t/hackmode`)

This upstream epic is complete only when Hackmode can consume the public contract to advance hackmode#28 without a private duplicate Prolog runtime protocol.

At minimum the downstream proof should show:

Hackpert starts from its canonical operation/objective/graph state;
calls Prolog-RLM through the public harness surface;
symbolic reasoning runs without a model when applicable;
a host capability request is validated by Hackmode;
returned observation becomes reasoning evidence;
an explicit generative fallback can produce a typed candidate when deterministic reasoning stalls;
Hackmode validates the candidate before any action/state mutation;
LISH can inspect requested/effective reasoning mode, fallback transition, result/evidence and usage;
Hackmode remains usable with Prolog-RLM/model support disabled.

Product UI, concrete cyber providers/tools, Tek9 mutation, StarLang actor topology, operation storage, and LISH command implementation remain downstream Hackmode work.

Migration / issue reconciliation

lost-rob0t/hackmode#24, #27, and #29 remain current downstream architecture and should not be replaced by this epic.
lost-rob0t/hackmode#28 becomes the downstream integration counterpart and should be updated/cross-linked to this epic.
#141 remains the canonical repository boundary.
#367 is completed precedent for a full host bridge; do not reopen it or duplicate its old narrow-shim problem.
#350 is closed/superseded and is not an architectural dependency.
#184/#186/#351 are already closed historical migration/cleanup tracks; do not revive them.

Non-goals

No Hackmode product code in prolog-rlm.
No concrete pentest/exploit tool catalog in core.
No target/scope database in core.
No Tek9 writes from Prolog-RLM.
No unrestricted shell/network/browser primitive.
No second cyber scheduler/agent runtime.
No authority change caused by reasoning-mode selection.
No model-generated arbitrary executable Prolog.
No real-world target required by core CI.

First implementation slice

Before coding, inspect current public machine/library interfaces and #335/#376/#387 exact-head implementation state. Then TDD the smallest generic host-run + capability request/result round trip needed by Hackmode, using a deterministic in-process or fixture host adapter.

Do not start by adding cyber-specific tools.

## Mission Build the **generic Prolog-RLM harness contract needed by Hackmode/Hackpert for cyber reasoning**, while preserving the canonical repository boundary in #141. This is the upstream half of `lost-rob0t/hackmode#28`. The target is **not** to move Hackmode, Hackpert, cyber tools, target state, Tek9, LISH, or operation authority into `prolog-rlm`. The target is to make `prolog-rlm` expose a complete reusable reasoning/expert/session interface that Hackmode can consume as its symbolic / recursive / generative reasoning tier. ```text lost-rob0t/hackmode Hackmode operation + scope + target/assets Hackpert objective / graph / KB passive|active authority cyber tools/providers/effects LISH / Emacs / hackmoded | | bounded typed host contract v lost-rob0t/prolog-rlm reasoning modes expert registry/routing Spec / Plan / Verify / Repair context + retrieval agents/subagents/recursion provider/model fallback capability/authority/effect abstractions traces/usage/structured outcomes ``` Dependency direction remains: ```text Hackmode/Hackpert -> public prolog-rlm APIs ``` `prolog-rlm` must not import or depend on Hackmode product code. ## Existing authorities to reuse - #141 — canonical downstream-product / reusable-core boundary. - #335 — canonical reasoning modes: `direct`, `symbolic`, `symbolic-recursive`, `auto`. - #376 — first-class Prolog expert registry/routing/invocation and closed-loop expert architecture. - #387 — Requirement -> Knowledge -> Plan -> Experts -> VERIFY -> Repair -> Review integration loop. - #367 — completed first-class host-bridge lesson: downstream harnesses must use the canonical machine/runtime interface rather than hand-wire a tiny incompatible subset. - `lost-rob0t/hackmode#24` — Hackpert expert layer over canonical Hackmode state. - `lost-rob0t/hackmode#27` — Hackpert active typed action/state-delta orchestration. - `lost-rob0t/hackmode#29` — open objective loop; authority mode is orthogonal to reasoning strategy. - `lost-rob0t/hackmode#28` — downstream Prolog-RLM generative/escalation integration. Do not create another scheduler, provider runtime, capability model, authority plane, effect ledger, verifier stack, or model history. ## Critical semantic split Hackmode already has two independent axes. Preserve them exactly. ### Host authority — owned by Hackmode ```text passive active ``` `passive` means reasoning/inspection only. `active` means Hackmode may admit typed effects through its own scope/capability/provider/state boundary. ### Reasoning strategy — owned by Prolog-RLM ```text direct symbolic symbolic-recursive auto ``` A strategy switch is **never** an authority change. Examples: ```text passive + symbolic passive + symbolic-recursive active + symbolic active + direct active + auto ``` Moving from symbolic to direct or recursive reasoning must not grant a tool, widen target scope, mutate Hackmode state, or bypass Hackmode's active-effect admission. ## Canonical flow ```text Hackmode operation scope + Frozen objective/SPEC ↓ bounded graph / KB / evidence projection ↓ Prolog-RLM session + requested reasoning strategy ↓ expert applicability / routing (#376) ↓ typed plan / subgoals / recursive expert or RLM work ↓ need external observation or action? ↓ host capability request ↓ Hackmode validates operation scope + authority + capability + budget ↓ Hackmode provider/effect execution OR structured denial ↓ typed observation/evidence returned to Prolog-RLM ↓ update reasoning state ↓ VERIFY exact unchanged objective/SPEC ↓ satisfied -> structured result otherwise -> diagnose / repair / replan / bounded continuation ``` The model never directly owns the Hackmode effect path. ## Track A — first-class host harness/session contract Expose a reusable host-facing boundary sufficient for a non-Prolog product such as Common Lisp Hackmode to create and drive a Prolog-RLM run without reimplementing runtime semantics. The boundary should support semantics equivalent to: ```text open/attach session or run supply bounded context/facts/references supply Frozen Spec/objective reference select/inspect reasoning mode register/project host capabilities as closed schemas step/run/continue answer host capability requests cancel inspect status/trace/usage/evidence close/release ``` Exact API/transport follows current repository conventions. Prefer the canonical machine/runtime protocol and public library APIs; do not add a Hackmode-only wire protocol if the generic one can be extended. Stable run/session/correlation identities are required. ## Track B — host capability adapter contract A downstream host must be able to expose typed capabilities to Prolog-RLM while keeping concrete implementations downstream. Required invariants: - registration/visibility != capability possession != host authorization != effect admission; - closed argument/result schemas; - stable capability IDs + versions; - bounded output/time/cancellation semantics; - structured deny/blocked/error/uncertain outcomes; - request/result correlation and provenance; - no ambient shell, network, filesystem, database, browser, or target authority in core; - no executable callback/closure serialized into model-visible data; - a host may expose read-only observations in passive mode while rejecting all effectful requests. Hackmode owns concrete recon, browser, fuzzing, capture, network, provider, mutation, and persistence implementations. ## Track C — cyber expert/profile composition without cyber authority in core The core should support a **host-defined cyber expert/profile catalog** using #376's generic expert contract rather than hard-coding exploit logic into the runtime. A downstream profile should be able to register expert roles such as: ```text recon / attack-surface reasoning source-assisted analysis vulnerability-intelligence correlation evidence/corroboration objective verification strategy/plan synthesis repair/recovery review/critic ``` Those names are examples of downstream registrations, not a fixed core ontology. Core owns selection/invocation/explanation mechanics. Hackmode owns the actual cyber facts, expert rule packs, target semantics, operation policies, and executable cyber capabilities. ## Track D — Hackpert reasoning-mode convergence Make `lost-rob0t/hackmode#29/#28` able to adapt cleanly to #335 instead of maintaining a second incompatible reasoning-mode enum. Required mapping direction: ```text Hackpert reasoning strategy -> canonical Prolog-RLM reasoning mode Hackpert authority mode -> remains separate Hackmode host state ``` The integration must expose requested/effective mode and selection reason to Hackmode so LISH can explain transitions. Symbolic-first / direct-fallback policy may be a Hackmode policy over the generic core modes; it must not require a forked Prolog-RLM runtime. ## Track E — bounded graph/KB/context projection Hackmode must be able to provide operation knowledge without giving Prolog-RLM direct Tek9 authority. Support reusable typed projections/references for: - current objective/Frozen Spec; - operation/target identity and allowed scope; - current assets/relations/findings; - execution/tool evidence; - operational KB facts/hypotheses; - long-term knowledge references where explicitly allowed; - prior negative evidence / failed paths; - budget/status information. Large context should use existing external-context/retrieval mechanisms rather than flattening the entire Hackmode graph into one model prompt. Prolog-derived conclusions must remain distinguishable from host-observed evidence. ## Track F — explicit generative fallback Support Hackmode's intended escalation use from `hackmode#28`: ```text known deterministic experts/rules stall -> explicit Prolog-RLM generative fallback -> candidate rule / plan / pattern / KB delta -> schema validation + provenance -> Hackpert/Common Lisp accepts, rejects, or constrains candidate -> canonical execution remains downstream ``` Requirements: - deterministic/expert operation works with zero model calls where possible; - model usage occurs only through the canonical provider runtime and is traced/metered; - generated content is candidate data, never trusted executable Prolog or raw host command authority; - generated actions cannot bypass Hackmode's typed capability/effect boundary; - returned candidates retain model/prompt/compiler/source-evidence provenance. ## Track G — verification and objective preservation Hackmode's objective/SPEC is the definition of success. Reasoning mode changes, recursion, model fallback, or repair cannot rewrite it to manufacture completion. The harness must allow downstream domain-specific verification while using the generic Spec/Verify/evidence contract. Final success requires fresh evidence satisfying the unchanged Frozen Spec/objective. Model prose is not proof. ## Track H — deterministic cyber-harness conformance fixture Add a **synthetic/local fixture**, not a real-world target, proving the host contract end to end. Fixture should model a tiny operation with: - a frozen objective; - a bounded asset/evidence graph; - one read-only observation capability; - one effectful host capability; - a deterministic expert path; - an initial evidence gap; - one denied passive-mode effect request; - an admitted active-mode equivalent under explicit host policy; - fresh evidence after the effect; - trusted verification; - cancellation / budget / replay assertions. No Internet access or external target is required for the core conformance test. ## Acceptance - [ ] `prolog-rlm` has one generic host harness/session surface sufficient for Hackmode without importing Hackmode code. - [ ] Hackmode can supply bounded typed graph/KB/evidence context and keep Tek9/canonical state downstream. - [ ] Hackmode can expose host capabilities through closed schemas while retaining concrete execution and authorization downstream. - [ ] `passive|active` authority remains orthogonal to `direct|symbolic|symbolic-recursive|auto` reasoning. - [ ] Passive mode can run useful expert reasoning with zero effect dispatch. - [ ] An effectful request in passive mode is structurally denied before execution. - [ ] The equivalent active-mode request still crosses Hackmode's own scope/capability/effect gate. - [ ] Expert routing composes with #376 rather than creating a cyber-only expert runtime. - [ ] Recursive work uses existing RLM/subagent/global budget/cancellation semantics. - [ ] Explicit model fallback is separately traced/metered and cannot widen authority. - [ ] Generated rules/plans/KB deltas are validated candidate data with provenance, not executable authority. - [ ] Final success is evidence-backed against the unchanged Frozen objective/SPEC. - [ ] Synthetic deterministic conformance fixture passes with provider disabled on the pure-expert path. - [ ] Cancellation terminates pending nested reasoning/host requests without later effects. - [ ] Replay/trace can explain mode selection, expert selection, capability request, host admission/denial, evidence, fallback usage, and stop reason. - [ ] Existing direct library callers and other downstream harnesses remain supported; no Hackmode-specific dependency leaks into core. ## Downstream integration acceptance (`lost-rob0t/hackmode`) This upstream epic is complete only when Hackmode can consume the public contract to advance `hackmode#28` without a private duplicate Prolog runtime protocol. At minimum the downstream proof should show: 1. Hackpert starts from its canonical operation/objective/graph state; 2. calls Prolog-RLM through the public harness surface; 3. symbolic reasoning runs without a model when applicable; 4. a host capability request is validated by Hackmode; 5. returned observation becomes reasoning evidence; 6. an explicit generative fallback can produce a typed candidate when deterministic reasoning stalls; 7. Hackmode validates the candidate before any action/state mutation; 8. LISH can inspect requested/effective reasoning mode, fallback transition, result/evidence and usage; 9. Hackmode remains usable with Prolog-RLM/model support disabled. Product UI, concrete cyber providers/tools, Tek9 mutation, StarLang actor topology, operation storage, and LISH command implementation remain downstream Hackmode work. ## Migration / issue reconciliation - `lost-rob0t/hackmode#24`, `#27`, and `#29` remain current downstream architecture and should **not** be replaced by this epic. - `lost-rob0t/hackmode#28` becomes the downstream integration counterpart and should be updated/cross-linked to this epic. - #141 remains the canonical repository boundary. - #367 is completed precedent for a full host bridge; do not reopen it or duplicate its old narrow-shim problem. - #350 is closed/superseded and is **not** an architectural dependency. - #184/#186/#351 are already closed historical migration/cleanup tracks; do not revive them. ## Non-goals - No Hackmode product code in `prolog-rlm`. - No concrete pentest/exploit tool catalog in core. - No target/scope database in core. - No Tek9 writes from Prolog-RLM. - No unrestricted shell/network/browser primitive. - No second cyber scheduler/agent runtime. - No authority change caused by reasoning-mode selection. - No model-generated arbitrary executable Prolog. - No real-world target required by core CI. ## First implementation slice Before coding, inspect current public machine/library interfaces and #335/#376/#387 exact-head implementation state. Then TDD the **smallest generic host-run + capability request/result round trip** needed by Hackmode, using a deterministic in-process or fixture host adapter. Do not start by adding cyber-specific tools.

nsaspy commented

2026-09-08 01:46:59 +00:00

Author

Owner

No harness will live in hackmode.
No hackmode front-end code will live here.
Prog rlm is simply a langraph, rlm, langchain in prolog with symbolic reasoning provided for consumers of this flake.

No harness will live in hackmode. No hackmode front-end code will live here. Prog rlm is simply a langraph, rlm, langchain in prolog with symbolic reasoning provided for consumers of this flake.

nsaspy commented

2026-09-08 01:46:59 +00:00

Author

Owner

ZeroForge public symbolic-port track

lost-rob0t/hackmode#190 now explicitly authorizes the public symbolic reimplementation of useful ZeroForge behavior inside Hackmode/Hackpert.

Reusable private/reference-semantics -> public symbolic artifact machinery is tracked in #390.

#389 remains the generic cyber host/session/capability harness. Do not add a ZeroForge-specific runtime protocol here; ZeroForge-derived behavior should arrive as ordinary expert/rule/plan/verification artifacts composed through #376/#390 and consumed by Hackmode through this harness.

## ZeroForge public symbolic-port track `lost-rob0t/hackmode#190` now explicitly authorizes the public symbolic reimplementation of useful ZeroForge behavior inside Hackmode/Hackpert. Reusable private/reference-semantics -> public symbolic artifact machinery is tracked in #390. #389 remains the generic cyber host/session/capability harness. Do not add a ZeroForge-specific runtime protocol here; ZeroForge-derived behavior should arrive as ordinary expert/rule/plan/verification artifacts composed through #376/#390 and consumed by Hackmode through this harness.