Migrate StarIntel RAGE/ARDR workers into Hackmode cyber/BBP workers #46

New issue

Closed

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

nsaspy commented

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

Owner

Outcome

Move the existing StarIntel-scoped autonomous worker roles into Hackmode RAGE workers.

These workers no longer own ordinary StarIntel product research, design, implementation, infrastructure, or issue-queue work. StarIntel may be touched only in the authorized cyber / BBP (bug-bounty-program) sense: as a target, security corpus, evidence sink, or security integration surface.

Supersedes worker-control-plane roles in:

lost-rob0t/starintel-auto-research#170
starintel-labs/RAGE#3

Related Hackpert/Hackmode architecture:

#24 Hackpert graph/KB engine
#27 Hackpert active orchestration
#28 later Prolog-RLM reasoning/escalation

Ownership correction

Hackmode owns the workers

RAGE workers for offensive/security work live under Hackmode and use Hackmode's operation, provider, graph, KB, Hackpert, LISH, and later Prolog-RLM substrate.

They discover and execute cyber work, not StarIntel software-development work.

StarIntel's role

StarIntel is allowed only as one or more of:

an explicitly authorized BBP/security target;
a source-code corpus for security review and attack-surface reasoning;
an asset/application/API surface to recon/test under operation scope;
a destination for accepted security findings/evidence/graph projections;
an integration endpoint whose security behavior is being tested;
a source of cyber-relevant telemetry/evidence such as IPX-derived traffic where authorized.

StarIntel is not the worker's engineering backlog.

Hard scope gate

A Hackmode RAGE worker MUST reject ordinary StarIntel tasks such as:

implementing StarIntel feature issues;
architecture/design work for StarIntel product capabilities;
runtime refactors, actor/domain-server development, transport redesign, observability, deployment, UI/product work, or general bug fixing;
selecting starintel-server, StarLang, Quasar, Auto-Research, infra, or other StarIntel repo issues merely because they are approved/high-priority;
opening implementation PRs that realize ordinary StarIntel product work.

Allowed StarIntel work is security/BBP work such as:

recon and attack-surface enumeration;
passive traffic analysis;
source-assisted security review;
vulnerability hypothesis generation and validation within scope;
CVE/version/component correlation;
authentication/authorization/session/security-control testing;
fuzzing and protocol/API security testing;
SQLi/XSS/OOB and other expert-driven testing where authorized;
exploitability/foothold/escalation reasoning inside the operation's stated objective;
producing findings, evidence, reproduction graphs, remediation notes, and security reports;
ingesting accepted cyber evidence/findings into StarIntel through its normal APIs.

If a security finding implies a StarIntel code fix, the Hackmode worker records/hands off the finding. It does not silently become a StarIntel implementation worker.

Worker model

Run multiple RAGE workers over a shared Hackmode substrate without stepping on each other.

Each worker must have:

distinct worker/run identity;
operation scope/authorization;
explicit target set;
isolated active plan/run state;
shared read access to operation graph/KB as policy permits;
conflict-safe writes through canonical Hackmode state APIs;
durable tool-call/result graph evidence;
budget, cancellation, and stop conditions;
exact provenance for every finding and mutation.

Initial worker split may include, for example:

recon / attack-surface worker;
active validation / fuzzing worker;
source-assisted vulnerability-research worker;
passive IPX evidence worker.

The exact worker count/profile is configurable rather than hard-coded.

RAGE loop

scope + objective
  -> gather canonical graph/KB/assets
  -> choose cyber task
  -> passive or active Hackpert reasoning
  -> tool/provider execution when active
  -> observe result
  -> graph + operational-KB update
  -> evaluate objective/stop/escalation
  -> continue or emit finding/report

Workers use Hackmode's provider/tool runtime and active mutation boundary. No separate StarIntel engineering scheduler is retained.

Objectives / SPEC direction

The worker loop must be open/extensible enough for operation-specific success conditions, e.g.:

foothold required;
target user identity / privilege objective such as UID 0/root;
retrieve and correlate relevant CVEs;
prove/reject a vulnerability hypothesis;
reach a graph state satisfying an expert-system rule;
hand off to a later escalation engine when deterministic reasoning stalls.

Future extensions may include ZeroForge integration and Prolog-RLM-generated rules/patterns/KB, but they must plug into the same objective/action/evidence loop rather than create a second worker scheduler.

StarIntel integration boundary

When security results are projected into StarIntel:

use typed canonical StarIntel APIs/contracts;
preserve operation, target, source, evidence, and tool provenance;
do not grant the Hackmode worker general StarIntel mutation/admin authority;
only security/BBP documents/findings/relations explicitly allowed by policy are emitted;
StarIntel availability must not be required for local Hackmode execution; failed projection can be retried from durable Hackmode evidence.

Migration steps

mark starintel-auto-research#170 worker contract superseded/non-executable
mark starintel-labs/RAGE#3 StarIntel implementor superseded/non-executable
inventory any scheduled/daemon worker entrypoints referencing those contracts
move worker configuration/state ownership into Hackmode
implement worker identity + operation-scope gate
implement cyber-only candidate/task classifier
prove ordinary StarIntel engineering issue is rejected
prove StarIntel BBP/security target is accepted when operation scope permits
route active execution through Hackpert/provider runtime
persist RAGE execution/evidence into Hackmode graph/operational KB
add optional StarIntel security finding/evidence projection
add LISH worker start/stop/status/assignment/graph inspection

Acceptance

no autonomous RAGE/ARDR worker selects ordinary StarIntel product implementation work;
worker ownership lives in Hackmode;
StarIntel is touched only for authorized BBP/cyber operations or security-result projection;
source-assisted StarIntel review cannot mutate product code as part of the cyber worker loop;
security findings can be handed off without converting the worker into a dev agent;
multiple Hackmode RAGE workers can operate concurrently with isolated run state and canonical conflict-safe writes;
Hackpert passive/active modes and future Prolog-RLM/ZeroForge extensions reuse the same worker loop.

## Outcome Move the existing StarIntel-scoped autonomous worker roles into **Hackmode RAGE workers**. These workers no longer own ordinary StarIntel product research, design, implementation, infrastructure, or issue-queue work. StarIntel may be touched only in the **authorized cyber / BBP (bug-bounty-program) sense**: as a target, security corpus, evidence sink, or security integration surface. Supersedes worker-control-plane roles in: - `lost-rob0t/starintel-auto-research#170` - `starintel-labs/RAGE#3` Related Hackpert/Hackmode architecture: - #24 Hackpert graph/KB engine - #27 Hackpert active orchestration - #28 later Prolog-RLM reasoning/escalation ## Ownership correction ### Hackmode owns the workers RAGE workers for offensive/security work live under Hackmode and use Hackmode's operation, provider, graph, KB, Hackpert, LISH, and later Prolog-RLM substrate. They discover and execute **cyber work**, not StarIntel software-development work. ### StarIntel's role StarIntel is allowed only as one or more of: - an explicitly authorized BBP/security target; - a source-code corpus for security review and attack-surface reasoning; - an asset/application/API surface to recon/test under operation scope; - a destination for accepted security findings/evidence/graph projections; - an integration endpoint whose security behavior is being tested; - a source of cyber-relevant telemetry/evidence such as IPX-derived traffic where authorized. StarIntel is **not** the worker's engineering backlog. ## Hard scope gate A Hackmode RAGE worker MUST reject ordinary StarIntel tasks such as: - implementing StarIntel feature issues; - architecture/design work for StarIntel product capabilities; - runtime refactors, actor/domain-server development, transport redesign, observability, deployment, UI/product work, or general bug fixing; - selecting `starintel-server`, StarLang, Quasar, Auto-Research, infra, or other StarIntel repo issues merely because they are approved/high-priority; - opening implementation PRs that realize ordinary StarIntel product work. Allowed StarIntel work is security/BBP work such as: - recon and attack-surface enumeration; - passive traffic analysis; - source-assisted security review; - vulnerability hypothesis generation and validation within scope; - CVE/version/component correlation; - authentication/authorization/session/security-control testing; - fuzzing and protocol/API security testing; - SQLi/XSS/OOB and other expert-driven testing where authorized; - exploitability/foothold/escalation reasoning inside the operation's stated objective; - producing findings, evidence, reproduction graphs, remediation notes, and security reports; - ingesting accepted cyber evidence/findings into StarIntel through its normal APIs. If a security finding implies a StarIntel code fix, the Hackmode worker records/hands off the finding. It does **not** silently become a StarIntel implementation worker. ## Worker model Run multiple RAGE workers over a shared Hackmode substrate without stepping on each other. Each worker must have: - distinct worker/run identity; - operation scope/authorization; - explicit target set; - isolated active plan/run state; - shared read access to operation graph/KB as policy permits; - conflict-safe writes through canonical Hackmode state APIs; - durable tool-call/result graph evidence; - budget, cancellation, and stop conditions; - exact provenance for every finding and mutation. Initial worker split may include, for example: 1. recon / attack-surface worker; 2. active validation / fuzzing worker; 3. source-assisted vulnerability-research worker; 4. passive IPX evidence worker. The exact worker count/profile is configurable rather than hard-coded. ## RAGE loop ```text scope + objective -> gather canonical graph/KB/assets -> choose cyber task -> passive or active Hackpert reasoning -> tool/provider execution when active -> observe result -> graph + operational-KB update -> evaluate objective/stop/escalation -> continue or emit finding/report ``` Workers use Hackmode's provider/tool runtime and active mutation boundary. No separate StarIntel engineering scheduler is retained. ## Objectives / SPEC direction The worker loop must be open/extensible enough for operation-specific success conditions, e.g.: - foothold required; - target user identity / privilege objective such as UID 0/root; - retrieve and correlate relevant CVEs; - prove/reject a vulnerability hypothesis; - reach a graph state satisfying an expert-system rule; - hand off to a later escalation engine when deterministic reasoning stalls. Future extensions may include ZeroForge integration and Prolog-RLM-generated rules/patterns/KB, but they must plug into the same objective/action/evidence loop rather than create a second worker scheduler. ## StarIntel integration boundary When security results are projected into StarIntel: - use typed canonical StarIntel APIs/contracts; - preserve operation, target, source, evidence, and tool provenance; - do not grant the Hackmode worker general StarIntel mutation/admin authority; - only security/BBP documents/findings/relations explicitly allowed by policy are emitted; - StarIntel availability must not be required for local Hackmode execution; failed projection can be retried from durable Hackmode evidence. ## Migration steps - [ ] mark `starintel-auto-research#170` worker contract superseded/non-executable - [ ] mark `starintel-labs/RAGE#3` StarIntel implementor superseded/non-executable - [ ] inventory any scheduled/daemon worker entrypoints referencing those contracts - [ ] move worker configuration/state ownership into Hackmode - [ ] implement worker identity + operation-scope gate - [ ] implement cyber-only candidate/task classifier - [ ] prove ordinary StarIntel engineering issue is rejected - [ ] prove StarIntel BBP/security target is accepted when operation scope permits - [ ] route active execution through Hackpert/provider runtime - [ ] persist RAGE execution/evidence into Hackmode graph/operational KB - [ ] add optional StarIntel security finding/evidence projection - [ ] add LISH worker start/stop/status/assignment/graph inspection ## Acceptance - no autonomous RAGE/ARDR worker selects ordinary StarIntel product implementation work; - worker ownership lives in Hackmode; - StarIntel is touched only for authorized BBP/cyber operations or security-result projection; - source-assisted StarIntel review cannot mutate product code as part of the cyber worker loop; - security findings can be handed off without converting the worker into a dev agent; - multiple Hackmode RAGE workers can operate concurrently with isolated run state and canonical conflict-safe writes; - Hackpert passive/active modes and future Prolog-RLM/ZeroForge extensions reuse the same worker loop.

nsaspy closed this issue

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