Timmy_Foundation/compounding-intelligence
15
0
Fork 0
Code Issues 173 Pull Requests 59 Actions Packages Projects Releases Wiki Activity

[Bug] Orchestrator not collecting proposals from engines #204

New Issue
Open
opened 2026-04-15 15:38:56 +00:00 by Rockachopa · 1 comment
Rockachopa commented 2026-04-15 15:38:56 +00:00
Owner
Copy Link

Problem

The orchestrator runs engines successfully but reports 0 proposals collected.

Expected Behavior

When running python3 scripts/improvement_orchestrator.py --run-all, each engine should:

  1. Generate proposals
  2. Write to proposals directory
  3. Orchestrator should find and count proposals

Actual Behavior

Engines run successfully and create files, but orchestrator reports:

Total proposals: 0

Root Cause

The orchestrator's run_engine method is not finding the proposal files that engines create. The engines write to proposals/{engine_id}.json but the orchestrator is not reading them.

Steps to Reproduce

# Clean proposals directory
rm -rf proposals/*

# Run orchestrator
python3 scripts/improvement_orchestrator.py --run-all

# Check proposals directory
ls -la proposals/

Expected Output

proposals/10_1.json
proposals/10_2.json
...
proposals/10_9.json

Actual Output

No files created in proposals directory.

Workaround

Run engines manually:

python3 scripts/insight_to_issue_converter.py --output proposals/10_1.json

Impact

  • Orchestrator cannot collect proposals
  • Cannot file issues automatically
  • Progress tracking incomplete

Priority

High - blocks core functionality of Pipeline 10

## Problem The orchestrator runs engines successfully but reports 0 proposals collected. ## Expected Behavior When running `python3 scripts/improvement_orchestrator.py --run-all`, each engine should: 1. Generate proposals 2. Write to proposals directory 3. Orchestrator should find and count proposals ## Actual Behavior Engines run successfully and create files, but orchestrator reports: ``` Total proposals: 0 ``` ## Root Cause The orchestrator's `run_engine` method is not finding the proposal files that engines create. The engines write to `proposals/{engine_id}.json` but the orchestrator is not reading them. ## Steps to Reproduce ```bash # Clean proposals directory rm -rf proposals/* # Run orchestrator python3 scripts/improvement_orchestrator.py --run-all # Check proposals directory ls -la proposals/ ``` ## Expected Output ``` proposals/10_1.json proposals/10_2.json ... proposals/10_9.json ``` ## Actual Output No files created in proposals directory. ## Workaround Run engines manually: ```bash python3 scripts/insight_to_issue_converter.py --output proposals/10_1.json ``` ## Impact - Orchestrator cannot collect proposals - Cannot file issues automatically - Progress tracking incomplete ## Priority High - blocks core functionality of Pipeline 10
codex-agent was assigned by Rockachopa 2026-04-17 01:34:50 +00:00
Rockachopa commented 2026-04-30 01:30:08 +00:00
Author
Owner
Copy Link

STEP35 FREE BURN — BLOCKED (assignment gate)

Issue #204: [Bug] Orchestrator not collecting proposals from engines

Status: ❌ Blocked — issue assigned to another agent

Gate check results:

  • Issue state: open ✅
  • Existing open PRs referencing #204 (pages 1–3): none found ✅
  • Assignee: codex-agent ❌ (authenticated user: Rockachopa)

Why blocked:
The agent-claim-gate requires the issue to be unassigned or assigned to the currently executing agent. This prevents two agents from working the same issue in parallel. Here, the issue is assigned to codex-agent but this session runs as Rockachopa.

Closed PR history (pages 1–3 scanned):
No prior PRs found for this issue.

Recommended resolution (maintainer action required):

Option A — Reassign to current agent (preferred for continuity):

  1. Maintainer reassigns issue #204 from codex-agent to Rockachopa
  2. Re-run STEP35 FREE BURN — gate will pass

Option B — Unassign and allow any agent:

  1. Maintainer removes all assignees from #204
  2. Re-run STEP35 — gate passes

Option C — Let the assigned agent handle it:
If codex-agent is an autonomous agent (e.g., codex-agent) that should process this, let that agent run its own burn cycle instead of dispatching a human-mode agent.

No implementation performed at this time.

Links:

**STEP35 FREE BURN — BLOCKED (assignment gate)** **Issue #204:** *[Bug] Orchestrator not collecting proposals from engines* **Status:** ❌ Blocked — issue assigned to another agent **Gate check results:** - Issue state: open ✅ - Existing open PRs referencing #204 (pages 1–3): none found ✅ - Assignee: **codex-agent** ❌ (authenticated user: Rockachopa) **Why blocked:** The `agent-claim-gate` requires the issue to be unassigned or assigned to the currently executing agent. This prevents two agents from working the same issue in parallel. Here, the issue is assigned to `codex-agent` but this session runs as `Rockachopa`. **Closed PR history (pages 1–3 scanned):** No prior PRs found for this issue. **Recommended resolution (maintainer action required):** **Option A — Reassign to current agent (preferred for continuity):** 1. Maintainer reassigns issue #204 from `codex-agent` to `Rockachopa` 2. Re-run STEP35 FREE BURN — gate will pass **Option B — Unassign and allow any agent:** 1. Maintainer removes all assignees from #204 2. Re-run STEP35 — gate passes **Option C — Let the assigned agent handle it:** If `codex-agent` is an autonomous agent (e.g., `codex-agent`) that should process this, let that agent run its own burn cycle instead of dispatching a human-mode agent. --- **No implementation performed at this time.** Links: - Issue: https://forge.alexanderwhitestone.com/Timmy_Foundation/compounding-intelligence/issues/204
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acceptance-criteria
batch-pipeline
Token masterplan batch pipeline
 bootstrapper
Pre-session context injection
 epic
Epic-level issue
 harvester
Session knowledge extraction
 measurer
Compounding metrics
 milestone:1
Milestone 1: Foundation
 milestone:2
Milestone 2: Integration
 milestone:3
Milestone 3: Measurement
 milestone:4
Milestone 4: Retroactive
 pipeline
Pipeline/integration work
 pipeline
priority:high
priority:medium
retroactive
Processing existing sessions
 throughput-10x
throughput-10x label
 token-masterplan
token-masterplan label
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Rockachopa Timmy allegro antigravity bezalel claude codex-agent ezra gemini google grok hermes kimi manus perplexity
No Assignees codex-agent
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/compounding-intelligence#204
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?