nsaspy/hackmode

Fork 0

Embed Prolog-RLM inside Hackpert as the generative/escalation reasoning tier #48

New issue

Open

opened 2026-09-02 17:24:37 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-02 17:24:37 +00:00

Owner

Current reconciliation — 2026-09-05

Upstream integration epic: lost-rob0t/prolog-rlm#389.

This issue remains the Hackmode-side integration counterpart. The old wording below that suggests :llm / :rlm as an authority-like Hackpert mode is superseded by the current two-axis architecture in #29 and prolog-rlm#335:

Hackmode authority: passive | active
Prolog-RLM reasoning: direct | symbolic | symbolic-recursive | auto

Reasoning strategy never grants or widens Hackmode authority. Prolog-RLM #389 owns the generic host/session/capability/expert/verification contract; Hackmode owns operation scope, cyber tools/providers, Tek9/KB state, active-effect admission, StarLang composition, and LISH/Emacs product surfaces.

Implementation should consume #389 rather than create a private Hackmode-only RLM protocol or second expert/runtime stack.

Outcome

Eventually embed prolog-rlm into Hackpert itself as a generative reasoning tier layered on top of Hackpert's direct symbolic passive/active engines.

This is intentionally later work. The direct Hackpert graph/KB/active-effect boundary from #24/#27 should stabilize first so the LLM/RLM tier consumes and produces the same typed structures instead of creating a parallel agent runtime.

Parent architecture: #24
Active engine: #27

Intended uses

1. Rule generation for iPhone/mobile targets

Use Prolog-RLM to synthesize candidate expert rules from observed device/application/version/recon facts, with provenance and validation before promotion.

Generated rules are candidates, not immediately trusted production rules. They should be testable against recorded graph/KB evidence and carry model/prompt/rule-generation provenance.

2. Attack-pattern generation

When the static rule base lacks a useful next pattern, Prolog-RLM may generate candidate attack/recon patterns expressed in Hackpert's typed plan/playbook/action representation.

The model should generate structured symbolic candidates, not raw shell command blobs. Active execution still goes through Hackpert -> Common Lisp -> capability/provider runtime.

3. KB generation

Use RLM over operation graph/history/evidence to generate candidate:

operational-KB facts/hypotheses;
long-term KB entries;
reusable constraints;
playbook/rule fragments;
summaries or abstractions over large execution histories.

Operational candidates may be accepted by the active engine under its normal policy. Long-term/global promotion retains explicit lifecycle/provenance controls.

4. Escalation after normal Hackpert reasoning

Hackpert should have an explicit escalation path when deterministic/symbolic reasoning stalls, exhausts known rules, or reaches a state requiring synthesis.

Example control flow:

recon / direct Hackpert rules
        -> known symbolic plan
        -> active execution + evidence
        -> no useful deterministic continuation
        -> Prolog-RLM escalation
        -> candidate rules/patterns/KB/plan delta
        -> Hackpert validation
        -> continue direct/active engine

RLM is therefore a reasoning escalation tier, not the owner of canonical state or effects.

5. Optional LLM mode after recon

Support a mode transition where normal recon runs first, graph + KB are populated, and then an LLM/RLM-backed Hackpert mode may be entered for deeper synthesis.

Possible high-level modes eventually become:

:passive — symbolic observation/reasoning only;
:active — symbolic orchestration + canonical mutation through Hackmode;
:llm / :rlm — generative reasoning over the same graph/KB, capable of emitting typed candidate rules, plans, KB deltas, and active actions subject to the same validation/effect boundary.

The exact public mode names can be decided later; the important property is that recon can complete before invoking expensive/generative reasoning.

Architectural requirements

Prolog-RLM is embedded/reused inside Hackpert, not exposed as a disconnected second agent system.
Same canonical operation graph, execution graph, provider registry, plan/playbook structures, and KB tiers are reused.
RLM outputs typed symbolic structures that Hackpert can inspect/validate.
No direct model shell execution and no direct model/Tek9 writes.
Generated rules/patterns/KB carry model, prompt/compiler, source-evidence, and generation-version provenance.
Direct symbolic Hackpert remains usable with no LLM configured.
Recon and known-rule execution should not require an LLM call.
Generation/escalation should be budgetable and observable in LISH.

LISH integration eventually

LISH should expose enough state to understand when Hackpert:

stayed in direct symbolic reasoning;
escalated into RLM/LLM mode;
generated a rule/pattern/KB candidate;
accepted/rejected that candidate;
returned from LLM mode to deterministic active execution.

Sequencing

Do not implement before these are stable enough to serve as the substrate:

execution graph;
passive/active mode model;
typed action/state-delta protocol;
operational + long-term KB;
plan/playbook graph primitives;
LISH run inspection;
at least one direct expert (recon) proving the substrate.

Acceptance direction

RLM receives bounded graph/KB/recon context from Hackpert;
RLM can emit a typed candidate rule;
RLM can emit a typed attack/recon pattern or plan delta;
RLM can emit KB candidates with provenance;
Hackpert can escalate to RLM after direct rules stall and then resume deterministic execution;
optional post-recon LLM mode works without changing canonical authority;
LISH makes the escalation/generation path inspectable;
Hackpert still works entirely without Prolog-RLM/LLM configuration.

## Current reconciliation — 2026-09-05 Upstream integration epic: `lost-rob0t/prolog-rlm#389`. This issue remains the **Hackmode-side integration counterpart**. The old wording below that suggests `:llm` / `:rlm` as an authority-like Hackpert mode is superseded by the current two-axis architecture in #29 and `prolog-rlm#335`: ```text Hackmode authority: passive | active Prolog-RLM reasoning: direct | symbolic | symbolic-recursive | auto ``` Reasoning strategy never grants or widens Hackmode authority. Prolog-RLM #389 owns the generic host/session/capability/expert/verification contract; Hackmode owns operation scope, cyber tools/providers, Tek9/KB state, active-effect admission, StarLang composition, and LISH/Emacs product surfaces. Implementation should consume #389 rather than create a private Hackmode-only RLM protocol or second expert/runtime stack. --- ## Outcome Eventually embed **prolog-rlm into Hackpert itself** as a generative reasoning tier layered on top of Hackpert's direct symbolic passive/active engines. This is intentionally **later work**. The direct Hackpert graph/KB/active-effect boundary from #24/#27 should stabilize first so the LLM/RLM tier consumes and produces the same typed structures instead of creating a parallel agent runtime. Parent architecture: #24 Active engine: #27 ## Intended uses ### 1. Rule generation for iPhone/mobile targets Use Prolog-RLM to synthesize candidate expert rules from observed device/application/version/recon facts, with provenance and validation before promotion. Generated rules are candidates, not immediately trusted production rules. They should be testable against recorded graph/KB evidence and carry model/prompt/rule-generation provenance. ### 2. Attack-pattern generation When the static rule base lacks a useful next pattern, Prolog-RLM may generate candidate attack/recon patterns expressed in Hackpert's typed plan/playbook/action representation. The model should generate **structured symbolic candidates**, not raw shell command blobs. Active execution still goes through Hackpert -> Common Lisp -> capability/provider runtime. ### 3. KB generation Use RLM over operation graph/history/evidence to generate candidate: - operational-KB facts/hypotheses; - long-term KB entries; - reusable constraints; - playbook/rule fragments; - summaries or abstractions over large execution histories. Operational candidates may be accepted by the active engine under its normal policy. Long-term/global promotion retains explicit lifecycle/provenance controls. ### 4. Escalation after normal Hackpert reasoning Hackpert should have an explicit escalation path when deterministic/symbolic reasoning stalls, exhausts known rules, or reaches a state requiring synthesis. Example control flow: ```text recon / direct Hackpert rules -> known symbolic plan -> active execution + evidence -> no useful deterministic continuation -> Prolog-RLM escalation -> candidate rules/patterns/KB/plan delta -> Hackpert validation -> continue direct/active engine ``` RLM is therefore a **reasoning escalation tier**, not the owner of canonical state or effects. ### 5. Optional LLM mode after recon Support a mode transition where normal recon runs first, graph + KB are populated, and then an LLM/RLM-backed Hackpert mode may be entered for deeper synthesis. Possible high-level modes eventually become: - `:passive` — symbolic observation/reasoning only; - `:active` — symbolic orchestration + canonical mutation through Hackmode; - `:llm` / `:rlm` — generative reasoning over the same graph/KB, capable of emitting typed candidate rules, plans, KB deltas, and active actions subject to the same validation/effect boundary. The exact public mode names can be decided later; the important property is that recon can complete before invoking expensive/generative reasoning. ## Architectural requirements - Prolog-RLM is embedded/reused **inside Hackpert**, not exposed as a disconnected second agent system. - Same canonical operation graph, execution graph, provider registry, plan/playbook structures, and KB tiers are reused. - RLM outputs typed symbolic structures that Hackpert can inspect/validate. - No direct model shell execution and no direct model/Tek9 writes. - Generated rules/patterns/KB carry model, prompt/compiler, source-evidence, and generation-version provenance. - Direct symbolic Hackpert remains usable with no LLM configured. - Recon and known-rule execution should not require an LLM call. - Generation/escalation should be budgetable and observable in LISH. ## LISH integration eventually LISH should expose enough state to understand when Hackpert: - stayed in direct symbolic reasoning; - escalated into RLM/LLM mode; - generated a rule/pattern/KB candidate; - accepted/rejected that candidate; - returned from LLM mode to deterministic active execution. ## Sequencing Do not implement before these are stable enough to serve as the substrate: 1. execution graph; 2. passive/active mode model; 3. typed action/state-delta protocol; 4. operational + long-term KB; 5. plan/playbook graph primitives; 6. LISH run inspection; 7. at least one direct expert (recon) proving the substrate. ## Acceptance direction - [ ] RLM receives bounded graph/KB/recon context from Hackpert; - [ ] RLM can emit a typed candidate rule; - [ ] RLM can emit a typed attack/recon pattern or plan delta; - [ ] RLM can emit KB candidates with provenance; - [ ] Hackpert can escalate to RLM after direct rules stall and then resume deterministic execution; - [ ] optional post-recon LLM mode works without changing canonical authority; - [ ] LISH makes the escalation/generation path inspectable; - [ ] Hackpert still works entirely without Prolog-RLM/LLM configuration.

nsaspy referenced this issue

2026-09-02 17:24:45 +00:00

Implement Hackpert active engine orchestration and canonical state mutation #49

nsaspy referenced this issue

2026-09-04 20:37:18 +00:00

Hackpert: forward-reconcile concrete recon providers #123

nsaspy referenced this issue

2026-09-04 20:37:18 +00:00

Hackpert: reconcile typed provider orchestration onto current master #125