nsaspy/hackmode
1
0
Fork 0
Code Issues 46 Pull requests 55 Projects Releases Packages Wiki Activity Actions

Integrate Hackpert as a Prolog expert layer over canonical Hackmode state #51

New issue
Open
opened 2026-09-02 17:24:37 +00:00 by nsaspy · 16 comments
nsaspy commented 2026-09-02 17:24:37 +00:00
Owner
Copy link

Outcome

Fold Hackpert into the canonical Hackmode monorepo as a SWI-Prolog expert/orchestration layer with two explicit engine modes: passive and active.

Hackpert must not become a second operation database or parallel source of truth. Hackmode/Tek9 remains canonical for operations, typed assets, graph persistence, KB lifecycle, and StarIntel synchronization. However, Hackpert does orchestrate tool runs, and in active mode it may intentionally drive canonical state changes through Hackmode's normal mutation APIs.

Source inspiration: https://github.com/lost-rob0t/hackpert

Engine modes

Passive mode

Passive Hackpert observes canonical Hackmode state, typed tool calls/results, and passive evidence such as IPX traffic.

Passive mode may:

  • classify, correlate, constrain, rank, infer, and recommend;
  • build derived reasoning/graph output;
  • propose plans, KB promotions, or next actions;
  • analyze already-produced tool output and traffic evidence.

Passive mode must not:

  • dispatch tools;
  • alter operation state;
  • persist new canonical assets/findings/KB entries by itself;
  • replay or actively probe targets.

Active mode

Active Hackpert is an orchestrating expert engine. It is required for fuzzing, SQLi, OOB, XSS/blind-XSS, and other experts whose reasoning loop must take an action, inspect the result, update knowledge, and continue.

Active mode may:

  • choose and dispatch registered Hackmode capabilities/providers;
  • create/update canonical graph state through typed Hackmode APIs;
  • persist discovered assets/findings and execution evidence;
  • mutate the operational KB as part of the reasoning loop;
  • advance attack/recon plans and playbook state;
  • request long-term KB promotion candidates when supported.

Active mode does not get arbitrary mutation authority. Prolog emits typed actions/state deltas; the Common Lisp active-engine wrapper validates them and executes them through canonical Hackmode interfaces. No direct Prolog writes into Tek9 and no arbitrary shell primitive.

                     +----------------------+
                     | canonical Hackmode   |
                     | state + graph + KB   |
                     +----------+-----------+
                                |
                                v
                     deterministic snapshot
                                |
                                v
                          SWI-Prolog
                          Hackpert engine
                          /             \
                         /               \
                  passive mode        active mode
                      |                   |
               graph/advice       typed actions +
                                  graph/state delta
                                          |
                                          v
                                Common Lisp active
                                  engine boundary
                                          |
                       +------------------+------------------+
                       |                  |                  |
                       v                  v                  v
                 provider dispatch   Tek9/KB writes    discover/findings

Tool orchestration

Hackpert already conceptually runs/orchestrates tools; the Hackmode adaptation must preserve that capability instead of reducing Hackpert to a recommendation service.

All active execution still uses Hackmode's registered provider/capability runtime so:

  • provider typing remains authoritative;
  • execution is observable in the tool-call/result graph;
  • failures and retries become reasoning evidence;
  • provider lifecycle/concurrency controls remain intact;
  • arbitrary Prolog shell execution is unnecessary.

The active loop is roughly:

reason -> select typed capability -> dispatch -> observe result
      -> persist execution/result graph -> update operational KB
      -> reason again

Graph model

Hackpert consumes canonical operation state plus typed tool calls/results. Its durable reasoning output/state transition is graph-shaped.

The graph covers:

  • expert/engine mode;
  • plans/playbooks and steps;
  • capability/tool calls;
  • inputs and outputs;
  • discovered assets and findings;
  • success/failure/negative evidence;
  • hypotheses and constraints;
  • KB provenance/promotion links;
  • passive IPX observations.

Passive mode returns graph/advice deltas only. Active mode may return graph + typed action/state deltas for Common Lisp to accept and apply.

Knowledge-base model

Hackmode should have three explicit KB scopes:

  1. Operational KB — per-operation working knowledge: current hypotheses, failed paths, observations, temporary fuzz/word candidates, active plans/playbooks, and recent execution graph context. Active Hackpert may mutate this through the canonical wrapper.
  2. Long-term KB — reusable learned knowledge: validated working paths, useful payload/fuzz/wordlist knowledge, stable constraints, reusable plan fragments, and repeated failure conditions. Promotion should be evidence/provenance carrying.
  3. Global KB / looting — optional explicit export of selected long-term knowledge for reuse across operations. Global export is never implicit.

Hackpert may propose promotions/exports. Common Lisp validates and persists them. Active mode may mutate operational state directly through the wrapper; long-term/global promotion remains an explicit lifecycle operation.

Learning requirements

  • wordlists/fuzz lists can be imported as provenance-carrying KB data;
  • working attacks/recon paths can be promoted into long-term KB candidates;
  • failed attack paths remain graph evidence so orchestration can avoid blind repetition;
  • useful operation-local knowledge can be explicitly exported/"looted" to global KBs;
  • all promotion/export paths preserve evidence/provenance and rule/expert version.

Expert families / goals

Shared graph + KB substrate should support specialized experts rather than separate state silos:

  • recon expert;
  • expert-level web fuzzing;
  • SQL injection expert;
  • out-of-band testing expert;
  • XSS expert;
  • blind-XSS expert.

Attack plans and playbooks are first-class graph structures with prerequisites, candidate capabilities, expected evidence, success/failure branches, and stop conditions.

SQLi/fuzzing-class experts are expected to run in active mode because they require iterative action -> evidence -> state mutation -> next action loops.

Possible Prolog-RLM integration comes later once stable and must reuse Hackmode's graph/KB/active-engine boundary.

LISH integration

Hackpert needs first-class LISH integration rather than a separate Hackpert REPL.

LISH should be able to:

  • inspect current Hackpert mode/status;
  • switch/select passive vs active mode where policy allows;
  • ask the expert for reasoning/recommendations;
  • start/stop/inspect active expert runs;
  • inspect plans/playbooks and tool-call/result graph nodes;
  • inspect operational/long-term KB state and promotion candidates;
  • inspect IPX-derived passive evidence;
  • surface provider/tool execution initiated by active Hackpert.

Authority boundary

  • Hackmode/Tek9 owns canonical persisted state.
  • capability-provider registry + provider actors own executable tools/capabilities.
  • Passive Hackpert has no mutation/dispatch authority.
  • Active Hackpert may orchestrate tools and request canonical mutations through a typed Common Lisp active-engine interface.
  • Common Lisp validates active-engine actions/deltas before execution/persistence.
  • Prolog does not directly write Tek9 or receive an unrestricted shell primitive.
  • no targets.txt, inscope.txt, outscope.txt, expert-state.prolog, or environment-variable operation authority.

First slice in PR #25

  • optional hackmode-expert bridge using SWI-Prolog when installed
  • deterministic projection of current operation/assets/providers into temporary Prolog facts
  • target classification: URL/domain/IPv4/IPv6/unknown
  • capability recommendation from target/asset type + registered provider metadata
  • fixed-goal query boundary; user data is serialized as facts, never concatenated into executable Prolog source
  • structured Common Lisp results
  • tests for target classification, recommendation ordering, missing swipl, quoting/injection safety, and no canonical-state mutation in the passive foundation
  • architecture records graph/KB direction and IPX passive evidence path

PR #25 implemented the passive foundation only. Its "no mutation" property is not the final Hackpert architecture; active mode is the next major execution layer.

Next implementation slices

  • typed execution graph for tool calls/results, persisted by Common Lisp/Tek9
  • explicit Hackpert engine mode model (:passive / :active)
  • active-engine typed action/state-delta protocol
  • active provider orchestration loop using Hackmode capabilities
  • operational KB storage + active mutation API
  • long-term KB storage and promotion lifecycle
  • explicit global-KB export/looting API
  • graph + KB snapshot facts into Prolog and typed graph/state deltas back
  • attack-plan/playbook graph primitives
  • LISH Hackpert mode/run/graph/KB integration
  • recon expert on shared substrate
  • wordlist/fuzz-list KB import with provenance
  • success/failure promotion candidates from execution evidence
  • specialized fuzzing/SQLi/OOB/XSS/blind-XSS experts incrementally in active mode
  • Emacs graph/plan/KB inspection
  • evaluate Prolog-RLM integration after the direct boundary is stable

Invariants

  • local-first operation still works with Prolog absent;
  • expert failure cannot corrupt canonical Hackmode state;
  • passive mode causes zero tool dispatches and zero canonical mutations;
  • active mode mutations are explicit, typed, validated, graph-recorded, and auditable;
  • active tool execution goes through the provider runtime;
  • no duplicate target/operation authority;
  • same canonical input + same rule/KB version produces deterministic reasoning output where practical;
  • global KB mutation/export is explicit and auditable.

Acceptance proof for active mode

  1. select an operation and start Hackpert in active mode;
  2. Hackpert receives canonical graph/KB/provider facts;
  3. Prolog emits a typed capability action rather than shell code;
  4. Common Lisp validates and dispatches it through the normal provider actor path;
  5. tool call + result are persisted as execution graph nodes/edges;
  6. discovered assets/findings are persisted through canonical Hackmode APIs;
  7. operational KB state may be updated by the active loop;
  8. the next reasoning iteration sees those mutations and can choose a different action;
  9. switching to passive mode makes the same expert unable to dispatch or mutate;
  10. LISH can inspect mode, run state, plan, graph, and resulting KB changes.
## Outcome Fold Hackpert into the canonical Hackmode monorepo as a SWI-Prolog expert/orchestration layer with **two explicit engine modes**: passive and active. Hackpert must not become a second operation database or parallel source of truth. Hackmode/Tek9 remains canonical for operations, typed assets, graph persistence, KB lifecycle, and StarIntel synchronization. However, Hackpert **does orchestrate tool runs**, and in active mode it may intentionally drive canonical state changes through Hackmode's normal mutation APIs. Source inspiration: https://github.com/lost-rob0t/hackpert ## Engine modes ### Passive mode Passive Hackpert observes canonical Hackmode state, typed tool calls/results, and passive evidence such as IPX traffic. Passive mode may: - classify, correlate, constrain, rank, infer, and recommend; - build derived reasoning/graph output; - propose plans, KB promotions, or next actions; - analyze already-produced tool output and traffic evidence. Passive mode must **not**: - dispatch tools; - alter operation state; - persist new canonical assets/findings/KB entries by itself; - replay or actively probe targets. ### Active mode Active Hackpert is an orchestrating expert engine. It is required for fuzzing, SQLi, OOB, XSS/blind-XSS, and other experts whose reasoning loop must take an action, inspect the result, update knowledge, and continue. Active mode may: - choose and dispatch registered Hackmode capabilities/providers; - create/update canonical graph state through typed Hackmode APIs; - persist discovered assets/findings and execution evidence; - mutate the **operational KB** as part of the reasoning loop; - advance attack/recon plans and playbook state; - request long-term KB promotion candidates when supported. Active mode does **not** get arbitrary mutation authority. Prolog emits typed actions/state deltas; the Common Lisp active-engine wrapper validates them and executes them through canonical Hackmode interfaces. No direct Prolog writes into Tek9 and no arbitrary shell primitive. ```text +----------------------+ | canonical Hackmode | | state + graph + KB | +----------+-----------+ | v deterministic snapshot | v SWI-Prolog Hackpert engine / \ / \ passive mode active mode | | graph/advice typed actions + graph/state delta | v Common Lisp active engine boundary | +------------------+------------------+ | | | v v v provider dispatch Tek9/KB writes discover/findings ``` ## Tool orchestration Hackpert already conceptually runs/orchestrates tools; the Hackmode adaptation must preserve that capability instead of reducing Hackpert to a recommendation service. All active execution still uses Hackmode's registered provider/capability runtime so: - provider typing remains authoritative; - execution is observable in the tool-call/result graph; - failures and retries become reasoning evidence; - provider lifecycle/concurrency controls remain intact; - arbitrary Prolog shell execution is unnecessary. The active loop is roughly: ```text reason -> select typed capability -> dispatch -> observe result -> persist execution/result graph -> update operational KB -> reason again ``` ## Graph model Hackpert consumes canonical operation state plus typed tool calls/results. Its durable reasoning output/state transition is graph-shaped. The graph covers: - expert/engine mode; - plans/playbooks and steps; - capability/tool calls; - inputs and outputs; - discovered assets and findings; - success/failure/negative evidence; - hypotheses and constraints; - KB provenance/promotion links; - passive IPX observations. Passive mode returns graph/advice deltas only. Active mode may return graph + typed action/state deltas for Common Lisp to accept and apply. ## Knowledge-base model Hackmode should have three explicit KB scopes: 1. **Operational KB** — per-operation working knowledge: current hypotheses, failed paths, observations, temporary fuzz/word candidates, active plans/playbooks, and recent execution graph context. Active Hackpert may mutate this through the canonical wrapper. 2. **Long-term KB** — reusable learned knowledge: validated working paths, useful payload/fuzz/wordlist knowledge, stable constraints, reusable plan fragments, and repeated failure conditions. Promotion should be evidence/provenance carrying. 3. **Global KB / looting** — optional explicit export of selected long-term knowledge for reuse across operations. Global export is never implicit. Hackpert may propose promotions/exports. Common Lisp validates and persists them. Active mode may mutate operational state directly through the wrapper; long-term/global promotion remains an explicit lifecycle operation. ## Learning requirements - wordlists/fuzz lists can be imported as provenance-carrying KB data; - working attacks/recon paths can be promoted into long-term KB candidates; - failed attack paths remain graph evidence so orchestration can avoid blind repetition; - useful operation-local knowledge can be explicitly exported/"looted" to global KBs; - all promotion/export paths preserve evidence/provenance and rule/expert version. ## Expert families / goals Shared graph + KB substrate should support specialized experts rather than separate state silos: - recon expert; - expert-level web fuzzing; - SQL injection expert; - out-of-band testing expert; - XSS expert; - blind-XSS expert. Attack plans and playbooks are first-class graph structures with prerequisites, candidate capabilities, expected evidence, success/failure branches, and stop conditions. SQLi/fuzzing-class experts are expected to run in **active mode** because they require iterative action -> evidence -> state mutation -> next action loops. Possible Prolog-RLM integration comes later once stable and must reuse Hackmode's graph/KB/active-engine boundary. ## LISH integration Hackpert needs first-class LISH integration rather than a separate Hackpert REPL. LISH should be able to: - inspect current Hackpert mode/status; - switch/select passive vs active mode where policy allows; - ask the expert for reasoning/recommendations; - start/stop/inspect active expert runs; - inspect plans/playbooks and tool-call/result graph nodes; - inspect operational/long-term KB state and promotion candidates; - inspect IPX-derived passive evidence; - surface provider/tool execution initiated by active Hackpert. ## Authority boundary - Hackmode/Tek9 owns canonical persisted state. - capability-provider registry + provider actors own executable tools/capabilities. - Passive Hackpert has no mutation/dispatch authority. - Active Hackpert may orchestrate tools and request canonical mutations through a typed Common Lisp active-engine interface. - Common Lisp validates active-engine actions/deltas before execution/persistence. - Prolog does not directly write Tek9 or receive an unrestricted shell primitive. - no `targets.txt`, `inscope.txt`, `outscope.txt`, `expert-state.prolog`, or environment-variable operation authority. ## First slice in PR #25 - [x] optional `hackmode-expert` bridge using SWI-Prolog when installed - [x] deterministic projection of current operation/assets/providers into temporary Prolog facts - [x] target classification: URL/domain/IPv4/IPv6/unknown - [x] capability recommendation from target/asset type + registered provider metadata - [x] fixed-goal query boundary; user data is serialized as facts, never concatenated into executable Prolog source - [x] structured Common Lisp results - [x] tests for target classification, recommendation ordering, missing `swipl`, quoting/injection safety, and no canonical-state mutation in the passive foundation - [x] architecture records graph/KB direction and IPX passive evidence path PR #25 implemented the **passive foundation only**. Its "no mutation" property is not the final Hackpert architecture; active mode is the next major execution layer. ## Next implementation slices - [ ] typed execution graph for tool calls/results, persisted by Common Lisp/Tek9 - [ ] explicit Hackpert engine mode model (`:passive` / `:active`) - [ ] active-engine typed action/state-delta protocol - [ ] active provider orchestration loop using Hackmode capabilities - [ ] operational KB storage + active mutation API - [ ] long-term KB storage and promotion lifecycle - [ ] explicit global-KB export/looting API - [ ] graph + KB snapshot facts into Prolog and typed graph/state deltas back - [ ] attack-plan/playbook graph primitives - [ ] LISH Hackpert mode/run/graph/KB integration - [ ] recon expert on shared substrate - [ ] wordlist/fuzz-list KB import with provenance - [ ] success/failure promotion candidates from execution evidence - [ ] specialized fuzzing/SQLi/OOB/XSS/blind-XSS experts incrementally in active mode - [ ] Emacs graph/plan/KB inspection - [ ] evaluate Prolog-RLM integration after the direct boundary is stable ## Invariants - local-first operation still works with Prolog absent; - expert failure cannot corrupt canonical Hackmode state; - passive mode causes zero tool dispatches and zero canonical mutations; - active mode mutations are explicit, typed, validated, graph-recorded, and auditable; - active tool execution goes through the provider runtime; - no duplicate target/operation authority; - same canonical input + same rule/KB version produces deterministic reasoning output where practical; - global KB mutation/export is explicit and auditable. ## Acceptance proof for active mode 1. select an operation and start Hackpert in active mode; 2. Hackpert receives canonical graph/KB/provider facts; 3. Prolog emits a typed capability action rather than shell code; 4. Common Lisp validates and dispatches it through the normal provider actor path; 5. tool call + result are persisted as execution graph nodes/edges; 6. discovered assets/findings are persisted through canonical Hackmode APIs; 7. operational KB state may be updated by the active loop; 8. the next reasoning iteration sees those mutations and can choose a different action; 9. switching to passive mode makes the same expert unable to dispatch or mutate; 10. LISH can inspect mode, run state, plan, graph, and resulting KB changes.
nsaspy commented 2026-09-02 17:24:43 +00:00
Author
Owner
Copy link

Common lisp wrapper around it for sure to mutate db
And def dont have expert system mutate db

Goals include:
Expert level fuzzing (web)
SQLI engine (also known as expert)
Out of band tsting (also known as expert)
XSS engine (also know nas expert)
Blind Xss engine (also known as expert)
recon engine (also known as expert)

Abilities to take wordlists/fuzz lists and import as expert KB
Working attacks promoted to expert KB
orchestration expert learns failed attack paths
Possible Prolog RLM integration once its stable

Common lisp wrapper around it for sure to mutate db And def dont have expert system mutate db Goals include: Expert level fuzzing (web) SQLI engine (also known as expert) Out of band tsting (also known as expert) XSS engine (also know nas expert) Blind Xss engine (also known as expert) recon engine (also known as expert) Abilities to take wordlists/fuzz lists and import as expert KB Working attacks promoted to expert KB orchestration expert learns failed attack paths Possible Prolog RLM integration once its stable
nsaspy commented 2026-09-02 17:24:43 +00:00
Author
Owner
Copy link

Also attack plans and playbooks.

Also attack plans and playbooks.
nsaspy commented 2026-09-02 17:24:43 +00:00
Author
Owner
Copy link

IPX is now split into #26 as the passive traffic-intelligence consumer of this expert substrate.

Required dependency direction:

IPX capture proxy -> append-only evidence spool -> typed parser/exchange graph -> Hackpert passive reasoning -> typed graph delta -> Common Lisp acceptance -> Tek9/operational KB -> StarIntel projection/durable outbox

The expert system remains effect-free: it does not mutate the capture, DB, KB, or StarIntel and passive observation does not implicitly trigger active scanning/replay/exploitation. docs/architecture/ipx.org is now on PR #25 so the foundation branch records the contract.

IPX is now split into #26 as the passive traffic-intelligence consumer of this expert substrate. Required dependency direction: `IPX capture proxy -> append-only evidence spool -> typed parser/exchange graph -> Hackpert passive reasoning -> typed graph delta -> Common Lisp acceptance -> Tek9/operational KB -> StarIntel projection/durable outbox` The expert system remains effect-free: it does not mutate the capture, DB, KB, or StarIntel and passive observation does not implicitly trigger active scanning/replay/exploitation. `docs/architecture/ipx.org` is now on PR #25 so the foundation branch records the contract.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/graph worker merged PR #42 at 10fa9855449ea2be8d6ed047f457558bdebd0a4e.

Completed database-owned prerequisite slice:

  • repaired the broken hackmode-database ASDF system (it referenced missing objects.lisp / encoding.lisp and contained incomplete DB wrappers);
  • added typed operation-scoped tool-call/result execution records with run/call identity and mandatory provenance;
  • added call/result identity validation that rejects cross-operation/run/call linkage;
  • maps records to canonical Tek9 graph nodes/edges and persists through Tek9 graph APIs; no shadow graph/database;
  • wired executable database tests into the ordinary core CI gate.

RED: e1190b25dbf720a72cbf02a727f2441ce3215a48 — monorepo green, core failed at the newly required database load/test step.
GREEN exact PR head: 03e649a2c3e535bade7578fb38f5d2840198194c — core + monorepo both green before expected-head squash merge.

Next database-owned dependency is durable/replay-safe execution evidence semantics and the operational-KB mutation boundary. Hackpert consumer/orchestration work remains with the sibling worker.

Database/graph worker merged PR #42 at `10fa9855449ea2be8d6ed047f457558bdebd0a4e`. Completed database-owned prerequisite slice: - repaired the broken `hackmode-database` ASDF system (it referenced missing `objects.lisp` / `encoding.lisp` and contained incomplete DB wrappers); - added typed operation-scoped tool-call/result execution records with run/call identity and mandatory provenance; - added call/result identity validation that rejects cross-operation/run/call linkage; - maps records to canonical Tek9 graph nodes/edges and persists through Tek9 graph APIs; no shadow graph/database; - wired executable database tests into the ordinary core CI gate. RED: `e1190b25dbf720a72cbf02a727f2441ce3215a48` — monorepo green, core failed at the newly required database load/test step. GREEN exact PR head: `03e649a2c3e535bade7578fb38f5d2840198194c` — core + monorepo both green before expected-head squash merge. Next database-owned dependency is durable/replay-safe execution evidence semantics and the operational-KB mutation boundary. Hackpert consumer/orchestration work remains with the sibling worker.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB progress: explicit global-KB export lifecycle merged via #53 at 573b4c93c3f22be145d98734e9313efa9f8d481b.

The original #51 head (6baf48095d915f17add315d5bf785a3aba2463fa) was green but had diverged six commits behind current master after sibling #52, so it was not stale-merged. The same six-file database delta was forward-reconciled onto master 7a9edae29772845f5a916df244cfee23246e5888 as exact head 0b7b74a507218530d8fcae34d7ab7ea752200845; core, monorepo, and agent-framework-boundary all passed with zero review threads before expected-head squash merge.

Completed contract:

  • operational -> long-term -> global remain three explicit lifecycle decisions;
  • only long-term promotion records may become global exports;
  • exported key/value cannot drift from the promoted claim;
  • source operation/assertion/run/expert/source-evidence/promotion-evidence provenance is preserved;
  • export requires its own evidence and exporter identity/version/provenance;
  • deterministic export identity is replay-safe;
  • persistence remains canonical Tek9 graph storage, with no shadow KB.

Next database-owned dependency is conflict-safe replay/idempotency for deterministic graph/KB writes: identical retries should remain idempotent while same-ID/different-content collisions fail closed rather than silently rewriting evidence.

Database/KB progress: explicit global-KB export lifecycle merged via #53 at `573b4c93c3f22be145d98734e9313efa9f8d481b`. The original #51 head (`6baf48095d915f17add315d5bf785a3aba2463fa`) was green but had diverged six commits behind current master after sibling #52, so it was not stale-merged. The same six-file database delta was forward-reconciled onto master `7a9edae29772845f5a916df244cfee23246e5888` as exact head `0b7b74a507218530d8fcae34d7ab7ea752200845`; `core`, `monorepo`, and `agent-framework-boundary` all passed with zero review threads before expected-head squash merge. Completed contract: - operational -> long-term -> global remain three explicit lifecycle decisions; - only long-term promotion records may become global exports; - exported key/value cannot drift from the promoted claim; - source operation/assertion/run/expert/source-evidence/promotion-evidence provenance is preserved; - export requires its own evidence and exporter identity/version/provenance; - deterministic export identity is replay-safe; - persistence remains canonical Tek9 graph storage, with no shadow KB. Next database-owned dependency is conflict-safe replay/idempotency for deterministic graph/KB writes: identical retries should remain idempotent while same-ID/different-content collisions fail closed rather than silently rewriting evidence.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database Auto-RAGE progress: merged #55 (38b270e6b2f3ac2924068983b9d79afe469fc2cc) for conflict-safe deterministic replay across execution graph and KB persistence. Stable-ID first writes insert, identical retries replay idempotently, and same-ID/different-content node/edge writes fail closed without overwriting canonical evidence. The compare/write is serialized by Tek9's composable write transaction; Hackmode's CI Tek9 pin was advanced from the pre-transaction API SHA to a9f5b595f5d965163d2b7c518c72a2efd9be13fe. Exact PR head d0b8c40bff40cd4044138f1fe5ba83dc7a132a36 passed core, monorepo, and agent-framework-boundary with zero review threads before expected-head merge.

Database Auto-RAGE progress: merged #55 (`38b270e6b2f3ac2924068983b9d79afe469fc2cc`) for conflict-safe deterministic replay across execution graph and KB persistence. Stable-ID first writes insert, identical retries replay idempotently, and same-ID/different-content node/edge writes fail closed without overwriting canonical evidence. The compare/write is serialized by Tek9's composable write transaction; Hackmode's CI Tek9 pin was advanced from the pre-transaction API SHA to `a9f5b595f5d965163d2b7c518c72a2efd9be13fe`. Exact PR head `d0b8c40bff40cd4044138f1fe5ba83dc7a132a36` passed core, monorepo, and agent-framework-boundary with zero review threads before expected-head merge.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/graph progress: typed operation snapshot reads merged via #58 as 78d24647b52805bf47f172d17914651fce4e4ef4.

Completed database-owned read contract:

  • enumerate typed execution records from the canonical operation-scoped Tek9 execution graph;
  • optional run/kind filtering with deterministic record ordering;
  • enumerate typed operational-KB assertions and retractions from the canonical operation KB graph;
  • reconstruct validated Common Lisp record types from stored Tek9 nodes;
  • fail closed if stored operation identity disagrees with the logical graph scope;
  • no provider execution, expert behavior, shadow graph, shadow KB, or second persistence authority.

RED: 02a8f98212baceb462f1b45c0f00c6b50ad2788e.
GREEN exact head: 244eff751e366dd8d6e5993fe8cef7f2296d618e; core, monorepo, and agent-framework-boundary passed with zero review threads before expected-head squash merge.

Hackpert consumer-side wiring remains sibling-owned: merged #54 can now consume these typed database reads instead of requiring callers to enumerate Tek9 internals.

Database/graph progress: typed operation snapshot reads merged via #58 as `78d24647b52805bf47f172d17914651fce4e4ef4`. Completed database-owned read contract: - enumerate typed execution records from the canonical operation-scoped Tek9 execution graph; - optional run/kind filtering with deterministic record ordering; - enumerate typed operational-KB assertions and retractions from the canonical operation KB graph; - reconstruct validated Common Lisp record types from stored Tek9 nodes; - fail closed if stored operation identity disagrees with the logical graph scope; - no provider execution, expert behavior, shadow graph, shadow KB, or second persistence authority. RED: `02a8f98212baceb462f1b45c0f00c6b50ad2788e`. GREEN exact head: `244eff751e366dd8d6e5993fe8cef7f2296d618e`; `core`, `monorepo`, and `agent-framework-boundary` passed with zero review threads before expected-head squash merge. Hackpert consumer-side wiring remains sibling-owned: merged #54 can now consume these typed database reads instead of requiring callers to enumerate Tek9 internals.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database Auto-RAGE update: PR #61 merged the reusable-KB read side and fixed the provenance-edge persistence defect exposed by its RED tests.

Completed storage contract:

  • typed validated enumeration for long-term KB promotions and explicit global KB exports;
  • deterministic record-ID ordering plus source-operation filtering;
  • source/promotion/export evidence and provenance survive reconstruction;
  • graph roots and provenance-reference anchors do not leak as KB records;
  • long-term/global provenance edges now persist successfully through Tek9 using immutable graph-local foreign-key anchors, because Tek9 edges cannot target nodes absent from their graph;
  • anchors contain identity/provenance only, not duplicated knowledge values, so Tek9 remains the sole persistence authority and no shadow KB was introduced.

RED head: 4dcdd8d7698cd0d7480942e6a6220e6eef86249c.
First implementation CI exposed the existing cross-graph edge defect at 82b88fa3881b497bc8f11df3108f0ef7eb0e2fe6.
GREEN exact head: 6b3e1fcde997562047f005293b592a8450b5bb7d (core, monorepo, and agent-framework-boundary all passed; zero review threads).
Merged as #61.

Database Auto-RAGE update: PR #61 merged the reusable-KB read side and fixed the provenance-edge persistence defect exposed by its RED tests. Completed storage contract: - typed validated enumeration for long-term KB promotions and explicit global KB exports; - deterministic record-ID ordering plus source-operation filtering; - source/promotion/export evidence and provenance survive reconstruction; - graph roots and provenance-reference anchors do not leak as KB records; - long-term/global provenance edges now persist successfully through Tek9 using immutable graph-local foreign-key anchors, because Tek9 edges cannot target nodes absent from their graph; - anchors contain identity/provenance only, not duplicated knowledge values, so Tek9 remains the sole persistence authority and no shadow KB was introduced. RED head: `4dcdd8d7698cd0d7480942e6a6220e6eef86249c`. First implementation CI exposed the existing cross-graph edge defect at `82b88fa3881b497bc8f11df3108f0ef7eb0e2fe6`. GREEN exact head: `6b3e1fcde997562047f005293b592a8450b5bb7d` (`core`, `monorepo`, and `agent-framework-boundary` all passed; zero review threads). Merged as #61.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB worker merged #65 at b939c0bbcb2e9323940f2ae62ac406711a4ed0a8.

Completed database-owned seed-import slice:

  • added bounded :wordlist / :fuzz-list import into the operation-scoped operational KB;
  • imported values become ordinary typed operational-KB assertions, not direct long-term/global knowledge;
  • duplicate strings collapse deterministically and input ordering cannot change logical record identity;
  • operation/run/importer/importer-version/evidence/provenance are preserved;
  • invalid seed kinds, empty values, and oversized imports fail closed;
  • persistence reuses the canonical replay-safe operational-KB boundary; no shadow KB/database;
  • no Hackpert policy or execution changes.

RED exact head: 878b27a10a3e3c9bc3523e85f1814afa641ad961 — core failed on the intentionally absent MAKE-OPERATIONAL-KB-SEED-ASSERTIONS; monorepo + boundary gates passed.
GREEN exact head: c987aab426b5b6090634e517b626f61d546d70ba — core + monorepo + agent-framework-boundary all passed, zero review threads/reviews, mergeable against unchanged master, then expected-head squash merge.

Hackpert handoff: imported seed assertions are available through the existing typed operational-KB read boundary; consumer/selection policy remains sibling-owned.

Database/KB worker merged #65 at `b939c0bbcb2e9323940f2ae62ac406711a4ed0a8`. Completed database-owned seed-import slice: - added bounded `:wordlist` / `:fuzz-list` import into the operation-scoped operational KB; - imported values become ordinary typed operational-KB assertions, not direct long-term/global knowledge; - duplicate strings collapse deterministically and input ordering cannot change logical record identity; - operation/run/importer/importer-version/evidence/provenance are preserved; - invalid seed kinds, empty values, and oversized imports fail closed; - persistence reuses the canonical replay-safe operational-KB boundary; no shadow KB/database; - no Hackpert policy or execution changes. RED exact head: `878b27a10a3e3c9bc3523e85f1814afa641ad961` — core failed on the intentionally absent `MAKE-OPERATIONAL-KB-SEED-ASSERTIONS`; monorepo + boundary gates passed. GREEN exact head: `c987aab426b5b6090634e517b626f61d546d70ba` — core + monorepo + agent-framework-boundary all passed, zero review threads/reviews, mergeable against unchanged master, then expected-head squash merge. Hackpert handoff: imported seed assertions are available through the existing typed operational-KB read boundary; consumer/selection policy remains sibling-owned.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database slice merged via #77 at master c7753a5497.

Completed contract: one validated typed tool call/result pair can now be deterministically projected to one operation-scoped operational-KB assertion carrying capability, terminal status, call identity, exact call/result evidence IDs, expert/version, and provenance. Provider output remains only in the execution graph; long-term/global promotion stays explicit.

Exact PR head 3a557c0d27 passed core, monorepo, and agent-framework-boundary with no reviews or unresolved threads before expected-head squash merge.

Database-side next dependency selected: deterministic effective operational-KB snapshot semantics (assertions minus valid retractions), so Hackpert/RLM consumers can read canonical effective knowledge without reimplementing retraction resolution. Consumer wiring remains sibling-owned.

Database slice merged via #77 at master c7753a5497007caa3b38dd4e2ebe80c53918ddbe. Completed contract: one validated typed tool call/result pair can now be deterministically projected to one operation-scoped operational-KB assertion carrying capability, terminal status, call identity, exact call/result evidence IDs, expert/version, and provenance. Provider output remains only in the execution graph; long-term/global promotion stays explicit. Exact PR head 3a557c0d278905033f7e351f5655dd6247189dc6 passed core, monorepo, and agent-framework-boundary with no reviews or unresolved threads before expected-head squash merge. Database-side next dependency selected: deterministic effective operational-KB snapshot semantics (assertions minus valid retractions), so Hackpert/RLM consumers can read canonical effective knowledge without reimplementing retraction resolution. Consumer wiring remains sibling-owned.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB Auto-RAGE progress: merged #80 as 8b763bcc8c9e679663eb58427b44d3e709f8c108.

Completed database-owned effective operational-KB read contract:

  • added fetch-effective-operational-kb-assertions over the canonical operation-scoped Tek9 KB graph;
  • resolves all valid retractions across the operation before applying optional run-id filtering, so a later-run retraction cannot resurrect stale earlier-run knowledge in a filtered snapshot;
  • returns only live typed assertions in deterministic canonical entry order;
  • fails closed if persisted retraction evidence targets a missing assertion;
  • no Hackpert reasoning/provider behavior, shadow KB, shadow graph, or second persistence authority.

RED exact head: 40c77e55a3131c1c304cc7169fbb35398b48aca6 — core failed specifically because FETCH-EFFECTIVE-OPERATIONAL-KB-ASSERTIONS was absent; monorepo and agent-framework-boundary were green.
GREEN exact implementation head: e427e1372a32b2248504a3579a4c8ec579fbb63a — core, monorepo, and agent-framework-boundary all green; PR mergeable with zero reviews/threads against unchanged master 22d1dd98955990c7145798c939b7afe1230e9768; expected-head squash merge used.

Hackpert/RLM handoff: consumers can now ask the database boundary for canonical effective operational knowledge instead of independently resolving assertion/retraction history. Consumer wiring remains sibling-owned.

Database/KB Auto-RAGE progress: merged #80 as `8b763bcc8c9e679663eb58427b44d3e709f8c108`. Completed database-owned effective operational-KB read contract: - added `fetch-effective-operational-kb-assertions` over the canonical operation-scoped Tek9 KB graph; - resolves all valid retractions across the operation before applying optional `run-id` filtering, so a later-run retraction cannot resurrect stale earlier-run knowledge in a filtered snapshot; - returns only live typed assertions in deterministic canonical entry order; - fails closed if persisted retraction evidence targets a missing assertion; - no Hackpert reasoning/provider behavior, shadow KB, shadow graph, or second persistence authority. RED exact head: `40c77e55a3131c1c304cc7169fbb35398b48aca6` — `core` failed specifically because `FETCH-EFFECTIVE-OPERATIONAL-KB-ASSERTIONS` was absent; `monorepo` and `agent-framework-boundary` were green. GREEN exact implementation head: `e427e1372a32b2248504a3579a4c8ec579fbb63a` — `core`, `monorepo`, and `agent-framework-boundary` all green; PR mergeable with zero reviews/threads against unchanged master `22d1dd98955990c7145798c939b7afe1230e9768`; expected-head squash merge used. Hackpert/RLM handoff: consumers can now ask the database boundary for canonical effective operational knowledge instead of independently resolving assertion/retraction history. Consumer wiring remains sibling-owned.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database worker update — PR #108 merged at c51f029415eeb2b653a1b213ae78f14cdeef0a0b.

Long-term KB promotion now fails closed unless the claimed source assertion is the exact canonical assertion persisted in that operation's operational KB and remains live (not retracted). Validation compares the immutable promotion snapshot (operation/run/expert/version/evidence/key/value) against the stored typed assertion and checks operation-wide retractions inside the same Tek9 write transaction as the promotion write.

RED: 9c8050bed75f711b0ce0759dfc365364b92ee84a failed core at non-canonical assertion unexpectedly promoted; monorepo and framework-boundary passed. GREEN: adc4bcf663d3d67f38df1b7969c3b88098262156 passed core, monorepo, and agent-framework-boundary.

Consumer boundary: Hackpert/RLM may request promotion using typed operational assertions, but must not treat a stale in-memory assertion as promotable after retraction. Storage remains canonical authority for admission.

Database worker update — PR #108 merged at `c51f029415eeb2b653a1b213ae78f14cdeef0a0b`. Long-term KB promotion now fails closed unless the claimed source assertion is the exact canonical assertion persisted in that operation's operational KB and remains live (not retracted). Validation compares the immutable promotion snapshot (operation/run/expert/version/evidence/key/value) against the stored typed assertion and checks operation-wide retractions inside the same Tek9 write transaction as the promotion write. RED: `9c8050bed75f711b0ce0759dfc365364b92ee84a` failed `core` at `non-canonical assertion unexpectedly promoted`; monorepo and framework-boundary passed. GREEN: `adc4bcf663d3d67f38df1b7969c3b88098262156` passed core, monorepo, and agent-framework-boundary. Consumer boundary: Hackpert/RLM may request promotion using typed operational assertions, but must not treat a stale in-memory assertion as promotable after retraction. Storage remains canonical authority for admission.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB handoff: merged #111 (8d77cada9b6e38da5c1b3cab1d79fb98f5a06158). Global-KB export can no longer bypass the long-term lifecycle with a caller-constructed promotion. persist-global-kb-export now resolves the referenced promotion from the canonical long-term Tek9 graph and requires the exported source/provenance claim to match it exactly inside the same write transaction used for global persistence. Consumer-side rule: persist/accept a long-term promotion first, then explicitly export that canonical promotion; do not treat an in-memory promotion object as global-KB authority.

Database/KB handoff: merged #111 (`8d77cada9b6e38da5c1b3cab1d79fb98f5a06158`). Global-KB export can no longer bypass the long-term lifecycle with a caller-constructed promotion. `persist-global-kb-export` now resolves the referenced promotion from the canonical long-term Tek9 graph and requires the exported source/provenance claim to match it exactly inside the same write transaction used for global persistence. Consumer-side rule: persist/accept a long-term promotion first, then explicitly export that canonical promotion; do not treat an in-memory promotion object as global-KB authority.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB hardening merged via #113. Operational-KB retractions now fail closed unless the referenced target resolves to a canonical typed :assert entry in the same operation graph. Validation and retraction persistence occur inside the same Tek9 write transaction, so an assertion-shaped ID alone is not mutation authority. RED head 2aaa6365291cbbfe9197a9f351805d973b173229 failed core in the ASDF test step while monorepo/boundary passed; GREEN exact head d0679b03f0689902fc0f9072a9ba12b28c880720 passed core, monorepo, and agent-framework-boundary before expected-head squash merge. Consumer handoff: use canonical persisted operational assertions as retraction targets; storage rejects corrupt/non-assertion targets.

Database/KB hardening merged via #113. Operational-KB retractions now fail closed unless the referenced target resolves to a canonical typed `:assert` entry in the same operation graph. Validation and retraction persistence occur inside the same Tek9 write transaction, so an assertion-shaped ID alone is not mutation authority. RED head `2aaa6365291cbbfe9197a9f351805d973b173229` failed `core` in the ASDF test step while monorepo/boundary passed; GREEN exact head `d0679b03f0689902fc0f9072a9ba12b28c880720` passed core, monorepo, and agent-framework-boundary before expected-head squash merge. Consumer handoff: use canonical persisted operational assertions as retraction targets; storage rejects corrupt/non-assertion targets.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database handoff: #115 merged. persist-operational-kb-seed-values now treats one bounded wordlist/fuzz-list seed import as a single canonical Tek9 write transaction. Hackpert/RLM consumers can rely on all-or-nothing persistence for one logical import: deterministic replay remains valid, while a conflicting assertion aborts the import without leaving earlier seed assertions durably committed.

Database handoff: #115 merged. `persist-operational-kb-seed-values` now treats one bounded wordlist/fuzz-list seed import as a single canonical Tek9 write transaction. Hackpert/RLM consumers can rely on all-or-nothing persistence for one logical import: deterministic replay remains valid, while a conflicting assertion aborts the import without leaving earlier seed assertions durably committed.
nsaspy commented 2026-09-02 17:24:44 +00:00
Author
Owner
Copy link

Database/KB handoff: PR #124 merged. fetch-long-term-kb-promotion now validates the stable record ID and returns a typed long-term-kb-promotion (or NIL when absent) from the canonical Tek9 long-term-KB graph instead of leaking a raw Tek9 node. Hackpert/RLM consumers can use the singular read without depending on persistence internals; promotion identity and evidence remain available through the typed boundary.

Database/KB handoff: PR #124 merged. `fetch-long-term-kb-promotion` now validates the stable record ID and returns a typed `long-term-kb-promotion` (or NIL when absent) from the canonical Tek9 long-term-KB graph instead of leaking a raw Tek9 node. Hackpert/RLM consumers can use the singular read without depending on persistence internals; promotion identity and evidence remain available through the typed boundary.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feat/android-operation-bridge
feat/star-bbpd-hackmode-actor-port
starintel/actor-ontology
first-party/starintel-recon-fold
chatgpt/201-starintel-target-receivers-20260917
impl/202-proxy-config
feature/issue-201-tool-actors
fix/core-expert-inspection-duplicate-accessors
feat/hm-cli-entrypoints
ops/restore-hackmode-workers-20260904
gpt/hackpert-objective-value-freeze
feature/retire-rage-workers
hackmode-rage-database/26-ipx-replay-parser-run10
rage-hackpert/29-freeze-selection-identity
rage/29-freeze-selection-identity
rage/15-ingest-by-state
rage/15-ingest-by-state-red-proof
auto-rage-hackpert/29-extension-identity-snapshot
hackmode-db/15-investigation-asset-views
hackpert/issue-29-objective-identity-aliasing
issue-138-http-request-contract
hackmode-rage-hackpert/issue-138-http-requester
db/143-visual-outbox
hackmode-rage-hackpert/137-http-transport-profile-20260901
rage-db/142-visual-scope-order
hackmode-rage-hackpert/136-ipx-addon
hackmode-rage-hackpert/135-capture-supervisor
rage-db/142-visual-evidence
hackmode-rage-hackpert/inspection-last-reason-20260831
hackmode-rage-database/http-header-policy-20260831-1343
hackmode-rage-database/typed-global-fetch-20260831-1102
hackpert/loop-reason-copy
hackmode-rage-hackpert/29-loop-scope-defensive-copy
rage-db/typed-long-term-fetch-11
rage-hackpert/direct-candidate-defensive-access-11
hackmode-rage-hackpert/29-direct-candidate-normalization
hackmode-rage-database/typed-operational-kb-fetch-20260831
rage-hackpert-12-objective-loop-step
rage-db-11-atomic-seed-import
hackmode-rage-hackpert/transition-reason-copy
hackpert/inspection-defensive-string-copies
auto-rage-database/op-kb-retraction-target-run11
hackmode-rage-hackpert/budget-inspection-20260831
auto-rage-database/global-export-canonical-source-20260831
hackmode-rage-database/live-promotion-source-20260831
hackmode-rage-hackpert/29-loop-transition-inspection
rage-database/capture-rotation-fork-20260831
hackmode-rage-hackpert/objective-selection-inspection-forward
hackmode-rage-hackpert/fix-find-apis-core-gate
hackmode-rage-hackpert/objective-selection-inspection
hackmode-rage-database/capture-source-rotation-20260830
hackmode-rage-hackpert/27-action-admission-inspection
hackmode-rage-hackpert/27-action-inspection
hackmode-rage-database/capture-quarantine-20260830-r2
hackmode-rage-hackpert/27-plan-inspection
hackmode-rage-database/capture-quarantine-20260830
hackmode-rage-hackpert/27-run-inspection
hackmode-rage-database/26-capture-checkpoint-20260830-1600
hackmode-rage-hackpert/26-http-exchange-snapshot
hackmode-rage-database/http-exchange-graph-20260830
hackmode-rage-hackpert/29-budget-loop-admission
auto-rage-db-effective-kb-20260830-1357
hackmode-rage-hackpert/29-objective-budget
hackmode-rage-database/24-execution-outcome-kb-candidates-reconcile-3
hackmode-rage-hackpert/29-objective-selection
hackmode-rage-database/24-execution-outcome-kb-candidates-reconcile-2
hackmode-rage-hackpert/29-extension-registry
hackmode-rage-database/24-execution-outcome-kb-candidates-reconcile
hackmode-rage-hackpert/29-objective-spec
hackmode-rage-database/24-execution-outcome-kb-candidates
hackpert/27-loop-stop-escalation
hackmode-rage-database/24-kb-seed-import
hackmode-rage-hackpert/27-recon-expert
hackmode-rage-database/24-reusable-kb-reads
hackmode-rage-hackpert/27-canonical-snapshot-refresh
hackmode-rage-database/24-operation-snapshot-reads
hackmode-rage-hackpert/27-plan-playbook-primitives
hackmode-rage-database/24-replay-conflict
hackmode-hackpert/27-graph-kb-snapshot
hackmode-rage-database/24-global-kb-export-forward
hackmode-rage-hackpert/48-recon-providers-forward
hackmode-rage-database/24-global-kb-export
hackmode-rage-hackpert/27-provider-orchestration-v2
hackmode-rage-database/24-long-term-kb-promotion
feature/hackpert-recon-toolkit
hackmode-rage-hackpert/27-provider-orchestration
fix/forbid-agent-framework-leakage
hackmode-rage-database/24-operational-kb
hackmode-rage-hackpert/27-active-action-protocol
rage-database/24-execution-graph-foundation
fix/agent-zero-only-rage
ci/rage-pr-serialization
rage-hackpert/27-engine-authority-mode
feature/30-auto-rage-profiles
feature/31-rage-worker-scope
feature/24-hackpert-expert-layer
agent/provider-actor-dns-slice
agent/persistent-operation-outbox
agent/starintel-document-projection
agent/reproducible-core-ci
agent/curate-hackmode-scripts
agent/canonical-operation-asset-protocol
agent/hackmode-monorepo-foundation
No results found.
Labels
Clear labels   
bug
Something isn't working

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
feature
New feature or capability

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
refactor
Code cleanup without behavior change

  
wontfix
This will not be worked on

No labels
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
invalid
question
refactor
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/hackmode#51
No description provided.