nsaspy/starintel-auto-research

Fork 0

P0: ARDR Auto-Research — StarIntel-scoped research → design → operator approval queue #170

New issue

Closed

opened 2026-08-29 10:28:06 +00:00 by nsaspy · 2 comments

nsaspy commented

2026-08-29 10:28:06 +00:00

Owner

Authority correction

ARDR/ADARD does not approve implementation. Implementation approval is operator-only.

This worker may autonomously move qualifying StarIntel research through research and design, including adversarial review, but its terminal state is design ready for operator review, never implementation-approved.

Mission

Continuously research only concrete StarIntel features/problems and directly relevant new work: actors/domain servers, datasources, scraping/acquisition, services, plugins/adapters, expert systems, agentic researcher actors, StarLang/runtime gaps, search/ingest/document/graph/provenance capabilities, Quasar surfaces required by those capabilities, and directly attached security/durability/resource/deployment concerns.

Reject generic technology research unless the worker can name the concrete StarIntel problem/capability and owning repository/issue/design surface.

Discovery and ranking

Discover candidates from StarIntel GitHub issues, implementation failures, canonical research/design indexes, explicit backlogs, repository gaps, referenced upstream projects, and newly discovered datasources with a stated StarIntel use case.

Rank by GitHub priority and dependency readiness:

P0 / blocker / security / release-blocking
P1
P2
P3
unlabelled dependency-unblocking
unlabelled standalone

Within a tier, prerequisites and ready work beat blocked dependents.

ARDR loop

Analyze

resolve owning problem/repo/issues
inspect current implementation before proposing architecture
inventory existing research/design
state exact StarIntel capability gap and ownership

Research

use current primary/upstream sources where needed
deeply enumerate relevant behavior
map every finding to a StarIntel requirement, design choice, rejection, or non-requirement
preserve provenance/contradictions and negative findings

Design

When research evidence is sufficient, skip human research validation, mark research READY_FOR_DESIGN, and immediately produce/update the canonical design.

Design must include architecture/ownership, typed contracts, StarLang/compiler/runtime gaps, actor/domain-server/service/plugin boundaries, local/remote behavior where relevant, security/resource/durability/cancellation/deadline/idempotency semantics, migration/compatibility, dependency-ordered implementation slices, explicit YAGNI/non-goals, and a falsifiable RED-first test target for each coding slice.

Adversarial review

Attack duplicate functionality, wrong ownership, hidden second control planes, Python-first leakage, authorization/confused-deputy risk, SSRF/resource issues, unbounded queues/retries/pagination/browser sessions/fan-out, stale writes/replay, provenance loss, private-data leakage, local/remote divergence, and unverifiable acceptance criteria.

Terminal decision state

After research/design/adversarial review, ARDR may mark the work only as:

READY_FOR_DESIGN during transition
DESIGN_READY_FOR_OPERATOR_REVIEW when the design is complete enough
blocked/researching/designing when unresolved issues remain

It MUST NOT emit or set APPROVED_FOR_IMPLEMENTATION, IMPLEMENTATION_APPROVED, or any equivalent state.

Implementation approval remains exclusively an explicit operator decision.

Proposed implementation handoff

For a design ready for operator review, ARDR may create/update proposed implementation issues in the owning repository containing:

canonical research/design links
priority and dependencies
bounded implementation slices
acceptance criteria
required first RED test/fixture
explicit state AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL

These issues must not enter the executable RAGE queue until the operator explicitly approves implementation.

RAGE boundary

Expected pipeline:

StarIntel problem
  -> ARDR analyze/research
  -> READY_FOR_DESIGN
  -> design
  -> adversarial review
  -> DESIGN_READY_FOR_OPERATOR_REVIEW
  -> OPERATOR APPROVAL
  -> RAGE implementor
  -> RED
  -> implementation
  -> GREEN + verification
  -> focused PR

StarLang preference

StarLang if expressible now
extend StarLang when semantics belong in the language/runtime
Common Lisp adapter/library beneath StarLang
isolated external process only when technically justified

Acceptance

research may autonomously become design without a human research-validation pause
ARDR can produce complete design-ready proposals for actors, datasources, scrapers, services and plugins
unrelated generic research is rejected
every proposed implementation slice has priority, dependencies and a RED-first target
ARDR can never approve implementation
proposed work remains AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL until the operator acts
RAGE cannot execute machine-only design readiness

Initial seed

Use lost-rob0t/starintel-auto-research#169 as an initial research/design candidate without duplicating its scope.

## Authority correction ARDR/ADARD **does not approve implementation**. Implementation approval is operator-only. This worker may autonomously move qualifying StarIntel research through research and design, including adversarial review, but its terminal state is **design ready for operator review**, never implementation-approved. ## Mission Continuously research only concrete StarIntel features/problems and directly relevant new work: actors/domain servers, datasources, scraping/acquisition, services, plugins/adapters, expert systems, agentic researcher actors, StarLang/runtime gaps, search/ingest/document/graph/provenance capabilities, Quasar surfaces required by those capabilities, and directly attached security/durability/resource/deployment concerns. Reject generic technology research unless the worker can name the concrete StarIntel problem/capability and owning repository/issue/design surface. ## Discovery and ranking Discover candidates from StarIntel GitHub issues, implementation failures, canonical research/design indexes, explicit backlogs, repository gaps, referenced upstream projects, and newly discovered datasources with a stated StarIntel use case. Rank by GitHub priority and dependency readiness: 1. P0 / blocker / security / release-blocking 2. P1 3. P2 4. P3 5. unlabelled dependency-unblocking 6. unlabelled standalone Within a tier, prerequisites and ready work beat blocked dependents. ## ARDR loop ### Analyze - resolve owning problem/repo/issues - inspect current implementation before proposing architecture - inventory existing research/design - state exact StarIntel capability gap and ownership ### Research - use current primary/upstream sources where needed - deeply enumerate relevant behavior - map every finding to a StarIntel requirement, design choice, rejection, or non-requirement - preserve provenance/contradictions and negative findings ### Design When research evidence is sufficient, **skip human research validation**, mark research `READY_FOR_DESIGN`, and immediately produce/update the canonical design. Design must include architecture/ownership, typed contracts, StarLang/compiler/runtime gaps, actor/domain-server/service/plugin boundaries, local/remote behavior where relevant, security/resource/durability/cancellation/deadline/idempotency semantics, migration/compatibility, dependency-ordered implementation slices, explicit YAGNI/non-goals, and a falsifiable RED-first test target for each coding slice. ### Adversarial review Attack duplicate functionality, wrong ownership, hidden second control planes, Python-first leakage, authorization/confused-deputy risk, SSRF/resource issues, unbounded queues/retries/pagination/browser sessions/fan-out, stale writes/replay, provenance loss, private-data leakage, local/remote divergence, and unverifiable acceptance criteria. ## Terminal decision state After research/design/adversarial review, ARDR may mark the work only as: - `READY_FOR_DESIGN` during transition - `DESIGN_READY_FOR_OPERATOR_REVIEW` when the design is complete enough - blocked/researching/designing when unresolved issues remain It **MUST NOT** emit or set `APPROVED_FOR_IMPLEMENTATION`, `IMPLEMENTATION_APPROVED`, or any equivalent state. Implementation approval remains exclusively an explicit operator decision. ## Proposed implementation handoff For a design ready for operator review, ARDR may create/update proposed implementation issues in the owning repository containing: - canonical research/design links - priority and dependencies - bounded implementation slices - acceptance criteria - required first RED test/fixture - explicit state `AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` These issues must **not** enter the executable RAGE queue until the operator explicitly approves implementation. ## RAGE boundary Expected pipeline: ```text StarIntel problem -> ARDR analyze/research -> READY_FOR_DESIGN -> design -> adversarial review -> DESIGN_READY_FOR_OPERATOR_REVIEW -> OPERATOR APPROVAL -> RAGE implementor -> RED -> implementation -> GREEN + verification -> focused PR ``` ## StarLang preference 1. StarLang if expressible now 2. extend StarLang when semantics belong in the language/runtime 3. Common Lisp adapter/library beneath StarLang 4. isolated external process only when technically justified ## Acceptance - research may autonomously become design without a human research-validation pause - ARDR can produce complete design-ready proposals for actors, datasources, scrapers, services and plugins - unrelated generic research is rejected - every proposed implementation slice has priority, dependencies and a RED-first target - ARDR can never approve implementation - proposed work remains `AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` until the operator acts - RAGE cannot execute machine-only design readiness ## Initial seed Use `lost-rob0t/starintel-auto-research#169` as an initial research/design candidate without duplicating its scope.

nsaspy referenced this issue

2026-08-29 10:28:16 +00:00

OSINT cluster research: username/account enumeration engines #180

nsaspy referenced this issue

2026-08-29 10:28:16 +00:00

OSINT cluster research: email-account existence and Google identity pivots #179

nsaspy referenced this issue

2026-08-29 10:28:18 +00:00

Research + design: StarLang-defined scraping domain actor and researcher integration #171

nsaspy commented

2026-08-29 10:28:18 +00:00

Author

Owner

Downstream implementation worker is now defined in starintel-labs/RAGE#3 — Approved-only RAGE Implementor with mandatory RED-first TDD. ARDR may emit APPROVED_FOR_IMPLEMENTATION; RAGE #3 must independently re-verify that state, dependency readiness, and the required RED-first test target before mutation.

Downstream implementation worker is now defined in `starintel-labs/RAGE#3` — **Approved-only RAGE Implementor with mandatory RED-first TDD**. ARDR may emit `APPROVED_FOR_IMPLEMENTATION`; RAGE #3 must independently re-verify that state, dependency readiness, and the required RED-first test target before mutation.

nsaspy commented

2026-09-02 17:26:26 +00:00

Author

Owner

MIGRATED — do not run as a StarIntel product worker

This autonomous StarIntel research/design worker role is superseded by lost-rob0t/hackmode#30.

RAGE/ARDR-style autonomous workers now belong to Hackmode. They may touch StarIntel only in an authorized cyber / BBP context: security recon, source-assisted security review, attack-surface analysis, vulnerability validation, evidence/findings, or security-result projection.

They must not select or advance ordinary StarIntel product research/design/implementation work from StarIntel issue queues.

Historical research/design artifacts created under this issue remain valid records; this comment changes the worker ownership/execution model, not the historical artifact record.

## MIGRATED — do not run as a StarIntel product worker This autonomous StarIntel research/design worker role is superseded by `lost-rob0t/hackmode#30`. RAGE/ARDR-style autonomous workers now belong to **Hackmode**. They may touch StarIntel only in an authorized **cyber / BBP** context: security recon, source-assisted security review, attack-surface analysis, vulnerability validation, evidence/findings, or security-result projection. They must not select or advance ordinary StarIntel product research/design/implementation work from StarIntel issue queues. Historical research/design artifacts created under this issue remain valid records; this comment changes the worker ownership/execution model, not the historical artifact record.

nsaspy closed this issue

2026-09-04 14:37:06 +00:00

nsaspy referenced this issue

2026-09-04 22:14:34 +00:00

Retire autonomous StarIntel product worker profiles after Hackmode migration #202