starintel-labs/RAGE

Fork 0

P0: Approved-only RAGE Implementor with mandatory RED-first TDD #3

New issue

Closed

opened 2026-08-29 10:29:38 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-08-29 10:29:38 +00:00

Owner

Goal

Create a reusable RAGE Implementor worker that realizes operator-approved StarIntel implementation tasks and nothing else.

It discovers approved work, ranks by GitHub priority/dependency readiness, selects one bounded implementation slice, proves the slice RED first, implements it, verifies exact head, and opens/updates a focused implementation PR.

Hard authority boundary

Implementation approval is operator-only.

The following are not implementation approval:

open GitHub issue
completed research
READY_FOR_DESIGN
DESIGN_READY_FOR_OPERATOR_REVIEW
design completion
adversarial review completion
ARDR/ADAD recommendation
green CI
machine-generated APPROVED_FOR_IMPLEMENTATION
model recommendation
high priority

A candidate is executable only when explicit operator/human implementation approval is recorded in canonical issue/design metadata or durable operator approval evidence.

RAGE cannot grant approval to itself and must not accept machine-only approval from ARDR/ADARD.

Candidate discovery

A candidate must have:

owning repo and GitHub issue
canonical research/design reference where applicable
explicit operator implementation-approval evidence
priority
satisfied dependencies/blockers
bounded implementation slice
acceptance criteria
required RED-first test target

If approval or any required field is unresolved, the candidate is not executable.

Deterministic priority

Among operator-approved and unblocked tasks:

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

Prerequisites beat dependents; at equal priority prefer regressions/blockers, then smaller bounded slices, then older approved work.

Repository preflight

Before mutation:

sync remote state and resolve exact remote default-branch SHA
inspect AGENTS.md/repo instructions and test/branch policy
inspect issue/design discussion and relevant source/tests
inspect conflicting/open implementation work
re-check approval and dependencies
create a dedicated feature branch/worktree from exact remote default head

Never implement directly on main/master.

Mandatory RED-first TDD

No production implementation mutation before valid RED evidence exists.

For each slice:

write the smallest failing unit/integration/property/conformance/regression/config/schema test that captures the approved missing behavior;
run it on the untouched baseline;
record that it fails for the expected reason;
only then modify production code;
make the test GREEN without weakening/skipping it;
run focused regressions;
run the repository-native full deterministic local gate.

If no legitimate RED can be constructed, return redTestUnavailable and send the work back to design/task refinement. Environment failures or malformed tests do not count as RED.

Implementation boundary

Do not redesign the approved architecture during realization. If implementation reveals a material architecture conflict, return designConflict rather than silently widening scope.

For StarIntel runtime/actor work follow the approved language boundary, normally:

StarLang
required StarLang extension
Common Lisp adapter/library
isolated external dependency only when explicitly justified by the approved design

Verify / PR

Before prReady:

new test GREEN
relevant regressions GREEN
full local deterministic gate GREEN
exact-head diff inspected
no unrelated mutations or secret/private-data leakage
acceptance criteria mapped to evidence

Open/update one focused PR linking the implementation issue, canonical design, operator approval evidence, RED evidence, GREEN/regression evidence, and exact-head revision. Do not auto-merge unless explicitly authorized.

Typed outcomes

At minimum:

noApprovedTask
approvalMissing
blockedDependency
designConflict
redTestUnavailable
redTestInvalid
implementationFailed
verificationFailed
prReady

ARDR relationship

lost-rob0t/starintel-auto-research#170 may autonomously research and design work and create proposed implementation issues, but those proposals stop at AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL / DESIGN_READY_FOR_OPERATOR_REVIEW.

Expected pipeline:

ARDR research/design
  -> DESIGN_READY_FOR_OPERATOR_REVIEW
  -> OPERATOR APPROVAL
  -> RAGE selects task
  -> RED
  -> implementation
  -> GREEN + verification
  -> focused PR

Relationship to Task Steward

Reuse/refactor the shared candidate discovery, exact-head preflight, worktree/branch, durable state, and RAGE machinery from #1. Do not create a competing task-selection framework.

Worker regression tests

Prove deterministically:

operator-approved task is eligible
unapproved P0 is refused
ARDR machine readiness/approval is refused
blocked dependency is skipped
priority/dependency ordering works
exact remote base SHA is mandatory
production mutation before RED is refused
malformed RED is rejected
valid RED unlocks realization
test weakening/skip is rejected
design contradiction returns to design
exact-head verification required before PR-ready
restart/resume does not duplicate work

Acceptance

only explicit operator-approved implementation tasks execute
ARDR/ADARD cannot authorize implementation
GitHub priority and dependency readiness are deterministic
every realization proves valid RED before production mutation
inability to produce RED blocks work
local deterministic verification precedes PR-ready
implementation stays inside the operator-approved design boundary
shared Task Steward/RAGE machinery is reused

## Goal Create a reusable **RAGE Implementor** worker that realizes **operator-approved** StarIntel implementation tasks and nothing else. It discovers approved work, ranks by GitHub priority/dependency readiness, selects one bounded implementation slice, proves the slice **RED first**, implements it, verifies exact head, and opens/updates a focused implementation PR. ## Hard authority boundary Implementation approval is **operator-only**. The following are **not** implementation approval: - open GitHub issue - completed research - `READY_FOR_DESIGN` - `DESIGN_READY_FOR_OPERATOR_REVIEW` - design completion - adversarial review completion - ARDR/ADAD recommendation - green CI - machine-generated `APPROVED_FOR_IMPLEMENTATION` - model recommendation - high priority A candidate is executable only when explicit operator/human implementation approval is recorded in canonical issue/design metadata or durable operator approval evidence. RAGE cannot grant approval to itself and must not accept machine-only approval from ARDR/ADARD. ## Candidate discovery A candidate must have: - owning repo and GitHub issue - canonical research/design reference where applicable - explicit operator implementation-approval evidence - priority - satisfied dependencies/blockers - bounded implementation slice - acceptance criteria - required RED-first test target If approval or any required field is unresolved, the candidate is not executable. ## Deterministic priority Among **operator-approved and unblocked** tasks: 1. P0 / blocker / security / release blocker 2. P1 3. P2 4. P3 5. unlabelled dependency-unblocking 6. unlabelled standalone Prerequisites beat dependents; at equal priority prefer regressions/blockers, then smaller bounded slices, then older approved work. ## Repository preflight Before mutation: - sync remote state and resolve exact remote default-branch SHA - inspect `AGENTS.md`/repo instructions and test/branch policy - inspect issue/design discussion and relevant source/tests - inspect conflicting/open implementation work - re-check approval and dependencies - create a dedicated feature branch/worktree from exact remote default head Never implement directly on main/master. ## Mandatory RED-first TDD **No production implementation mutation before valid RED evidence exists.** For each slice: 1. write the smallest failing unit/integration/property/conformance/regression/config/schema test that captures the approved missing behavior; 2. run it on the untouched baseline; 3. record that it fails for the expected reason; 4. only then modify production code; 5. make the test GREEN without weakening/skipping it; 6. run focused regressions; 7. run the repository-native full deterministic local gate. If no legitimate RED can be constructed, return `redTestUnavailable` and send the work back to design/task refinement. Environment failures or malformed tests do not count as RED. ## Implementation boundary Do not redesign the approved architecture during realization. If implementation reveals a material architecture conflict, return `designConflict` rather than silently widening scope. For StarIntel runtime/actor work follow the approved language boundary, normally: 1. StarLang 2. required StarLang extension 3. Common Lisp adapter/library 4. isolated external dependency only when explicitly justified by the approved design ## Verify / PR Before `prReady`: - new test GREEN - relevant regressions GREEN - full local deterministic gate GREEN - exact-head diff inspected - no unrelated mutations or secret/private-data leakage - acceptance criteria mapped to evidence Open/update one focused PR linking the implementation issue, canonical design, **operator approval evidence**, RED evidence, GREEN/regression evidence, and exact-head revision. Do not auto-merge unless explicitly authorized. ## Typed outcomes At minimum: - `noApprovedTask` - `approvalMissing` - `blockedDependency` - `designConflict` - `redTestUnavailable` - `redTestInvalid` - `implementationFailed` - `verificationFailed` - `prReady` ## ARDR relationship `lost-rob0t/starintel-auto-research#170` may autonomously research and design work and create proposed implementation issues, but those proposals stop at `AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` / `DESIGN_READY_FOR_OPERATOR_REVIEW`. Expected pipeline: ```text ARDR research/design -> DESIGN_READY_FOR_OPERATOR_REVIEW -> OPERATOR APPROVAL -> RAGE selects task -> RED -> implementation -> GREEN + verification -> focused PR ``` ## Relationship to Task Steward Reuse/refactor the shared candidate discovery, exact-head preflight, worktree/branch, durable state, and RAGE machinery from #1. Do not create a competing task-selection framework. ## Worker regression tests Prove deterministically: - operator-approved task is eligible - unapproved P0 is refused - ARDR machine readiness/approval is refused - blocked dependency is skipped - priority/dependency ordering works - exact remote base SHA is mandatory - production mutation before RED is refused - malformed RED is rejected - valid RED unlocks realization - test weakening/skip is rejected - design contradiction returns to design - exact-head verification required before PR-ready - restart/resume does not duplicate work ## Acceptance - only explicit operator-approved implementation tasks execute - ARDR/ADARD cannot authorize implementation - GitHub priority and dependency readiness are deterministic - every realization proves valid RED before production mutation - inability to produce RED blocks work - local deterministic verification precedes PR-ready - implementation stays inside the operator-approved design boundary - shared Task Steward/RAGE machinery is reused

nsaspy commented

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

Author

Owner

MIGRATED — StarIntel implementation worker retired

This StarIntel product implementor role is superseded by lost-rob0t/hackmode#30.

Autonomous RAGE workers now live under Hackmode and may touch StarIntel only in an authorized cyber / BBP capacity: recon, security review, attack-surface analysis, vulnerability validation, evidence/findings, or security-result projection.

They must not select approved StarIntel engineering issues, implement ordinary StarIntel features/refactors, or open product implementation PRs as part of the cyber worker loop.

If Hackmode finds a StarIntel security defect, it records and hands off the finding; remediation belongs to the normal StarIntel development workflow.

## MIGRATED — StarIntel implementation worker retired This StarIntel product implementor role is superseded by `lost-rob0t/hackmode#30`. Autonomous RAGE workers now live under **Hackmode** and may touch StarIntel only in an authorized **cyber / BBP** capacity: recon, security review, attack-surface analysis, vulnerability validation, evidence/findings, or security-result projection. They must not select approved StarIntel engineering issues, implement ordinary StarIntel features/refactors, or open product implementation PRs as part of the cyber worker loop. If Hackmode finds a StarIntel security defect, it records and hands off the finding; remediation belongs to the normal StarIntel development workflow.

nsaspy closed this issue

2026-09-04 14:39:07 +00:00