Governed Execution Runtime

Reference ID: REF-RALPH

Extending the Ralph Wiggum Loop Beyond Persistence

"Ralph is a Bash loop." - read https://awesomeclaude.ai/ralph-wiggum

The Ralph Wiggum technique, coined by Geoffrey Huntley, is fundamentally about persistent execution. In its simplest form, it repeatedly feeds the same prompt to an AI agent until a completion condition is met. Yes. The current document is still a collection of ideas and rules. It is not a design document.

It mixes:

• philosophy
• runtime behavior
• GitLab implementation
• Ralph
• Claude behavior
• Bluefly policy

…without a single architecture.

The document should read like an RFC or engineering standard.

I’d rewrite it completely.

⸻

Bluefly Execution Runtime (BER)

A Deterministic Runtime for Persistent AI Engineering

Version: 1.0 Draft

⸻

Abstract

Modern coding agents fail for a surprisingly simple reason:

They repeatedly rediscover work that has already been classified.

The cost is not model inference.

The cost is context.

Every iteration re-audits repositories, re-proves blockers, re-explains state, and re-emits narration.

The result is an AI that behaves like a consultant instead of an execution engine.

This document defines a deterministic execution runtime that transforms persistent agents into queue processors.

The runtime composes existing GitLab, Claude Code, and Git tooling.

It introduces almost no new software.

Instead it introduces state discipline.

⸻

Design Goals

The runtime exists to maximize one metric:

Reduce unfinished work.

Everything else is secondary.

The runtime must:

• never rediscover completed work
• never narrate execution
• never invent authority
• minimize token usage
• minimize long-term maintenance
• maximize deterministic progress

⸻

Core Principles

1. GitLab is Persistent Memory

GitLab already stores nearly every piece of state the runtime needs.

Repositories.

Merge Requests.

Issues.

Approvals.

Discussions.

Labels.

Pipelines.

Work Item relationships.

The runtime does not duplicate this memory.

It consumes it.

⸻

1. The Agent is Stateless

The agent remembers only one thing:

Current Cursor

Everything else comes from GitLab.

The runtime never reconstructs history.

It reloads it.

⸻

1. Rediscovery is Waste

Every time the runtime re-proves

• runner offline
• approval required
• discussions unresolved
• repository already terminal

it has failed.

State already exists.

Read it once.

Cache it.

Move on.

⸻

Runtime Architecture

                GitLab
  Group Labels
  Work Items
  Merge Requests
  Pipelines
  Discussions
  Approvals
  Blocked-by Links
          ▲
  Execution Cursor
          ▲
   AI Runtime
          ▲
     Ralph Loop

Ralph supplies persistence.

GitLab supplies memory.

The runtime supplies discipline.

⸻

Repository Lifecycle

Every repository exists in exactly one state.

UNSEEN ↓ ACTIVE ↓ TERMINAL

TERMINAL is immutable.

Repositories cannot leave TERMINAL unless

• explicitly reopened by the operator

or

• external evidence changes their state.

⸻

Merge Request Lifecycle

Repository lifecycle and Merge Request lifecycle are independent.

Example:

Repository

ACTIVE

Merge Request

WAITING_FOR_REVIEW

These are different objects.

Never conflate them.

⸻

Execution Cursor

Exactly one repository is active.

Repository: api-schema-registry MR: 40

No queue rediscovery.

No reprioritization.

Finish.

Advance.

⸻

Execution Loop

For every repository:

Enter ↓ Mechanical work ↓ Validate ↓ Assign terminal state ↓ Record ↓ Evict ↓ Advance cursor

Nothing else.

⸻

Terminal States

Exactly one.

FIXED WAITING_FOR_OPERATOR_MERGE BLOCKED_EXTERNAL BLOCKED_POLICY SKIPPED

After assignment:

Leave immediately.

⸻

Mechanical Boundary

Everything is assumed mechanical until proven otherwise.

Mechanical includes:

• merge conflicts
• rebases
• lockfiles
• formatting
• generated files
• CI configuration
• path drift
• dependency synchronization

Continue fixing.

⸻

Semantic Boundary

Execution stops only when work requires:

• architecture
• product decision
• implementation choice
• dependency strategy
• security policy
• supported-version policy
• race-condition redesign

At that point:

Assign ownership.

Exit.

⸻

Ownership Model

Never explain symptoms.

Record ownership.

Bad

9 conflicting files

Good

Owner: Engineering Reason: Implementation conflict Wake: New commit

Ownership drives execution.

⸻

Blocker Objects

Blockers are first-class entities.

One blocker.

Many references.

Example

Issue: oracle-runner-offline Owner: Infrastructure Wake: Runner online Affected: duadp!25 duadp!26 node-agent-marketplace!20

Repositories reference the blocker.

They do not redefine it.

⸻

GitLab Mapping

Runtime Concept Native GitLab Primitive Repository lifecycle Group scoped labels (state::) Terminal outcome result:: labels Blockers Work Items / Issues Dependencies blocked_by relationships Ownership Assignee Wake condition Issue resolution Engineering work Merge Request Runtime health Pipeline Cursor Claude Task + active MR

No custom platform required.

⸻

Recommended Group Labels

Lifecycle

state::active state::terminal

Outcome

result::merged result::blocked result::closed result::skipped

Blocker Type

blocker::approval blocker::discussion blocker::engineering blocker::policy blocker::security blocker::infrastructure

⸻

Output Authority

The runtime may emit output only when:

• repository changes state
• cursor advances
• fatal error occurs

Otherwise:

No output.

Never emit:

• receipts
• summaries
• philosophy
• recaps
• strategy
• progress essays

Silence is correct.

⸻

Workspace Authority

Repositories are authoritative.

The runtime may never create

• clones
• worktrees
• repositories
• directories

inside authoritative project roots unless explicitly instructed.

Scratch work belongs only in designated scratch locations.

Never invent workspace layout.

⸻

Upstream-First Rule

Before writing code prove that it cannot be solved by:

1. upstream project
2. existing repository
3. configuration
4. reusable component
5. framework
6. infrastructure

Only then write code.

Reward:

• delete code
• replace custom with OSS
• replace code with configuration

Penalty:

• wrappers
• duplicate implementations
• unnecessary abstractions

Score = Net reduction in ownership.

⸻

Ralph’s Role

Ralph is not the runtime.

Ralph is only the persistence mechanism.

while unfinished: execute()

Everything else—state management, blocker caching, execution discipline, cursor management, GitLab integration—is the execution runtime layered on top of Ralph.

⸻

Definition of Success

The runtime behaves less like a conversational assistant and more like an operating system scheduler.

Its job is to:

• execute work,
• advance the cursor,
• record state changes,
• and remain silent until something actually changes.

That’s the document I think is worth publishing. It isn’t just a prompt or a collection of heuristics—it defines an execution model, maps it onto existing GitLab primitives, minimizes new ownership, and explains why the architecture exists. It’s the kind of document another engineer could implement or critique without needing the surrounding conversation.