You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Miner Wave 1 (#11), Wave 2 (#12), and Wave 3 (#13) milestones are all closed — every individual issue's PR genuinely merged (spot-checked and cross-referenced with closedByPullRequestsReferences, no false closures found). But a code-level audit (import-graph traced from bin/gittensory-miner.js outward, plus targeted git grep for real call sites vs. definitions/tests) found that the actual discover → analyze → plan → prepare → create → manage → repeat loop this whole system exists to run has zero live entrypoint end-to-end today. The individual pieces are real and wired in isolation:
discover → rank → enqueue: fully wired (opportunity-fanout.js → opportunity-ranker.js → portfolio-discovery.js → portfolio-queue.js, reachable from the discover CLI command).
The coding-agent driver seam (createCodingAgentDriver/runCodingAgentAttempt in packages/gittensory-engine) has zero production caller anywhere — only test and doc references.
attempt-runner.js's injectable runSlopAssessment self-review dependency has no production implementation.
Governor counters (rate-limit buckets, backoff attempts, budget/turn/termination totals, convergence history, reputation/self-plagiarism throttle state) are pure in/out transforms with nothing persisting them between separate CLI invocations — contrast with the ledger above, which does persist.
loop-reentry.js/loop-closure.js (the "automatically re-invoke discovery on a resolved outcome" pieces) are CLI-unreachable; the Dockerfile's own CMD is ["doctor"], a one-shot batch command — nothing autonomously repeats the cycle today.
This milestone closes that gap: wire the 5 pieces below, in dependency order, so the loop this whole system was built for actually runs unattended, end to end.
Context
Miner Wave 1 (#11), Wave 2 (#12), and Wave 3 (#13) milestones are all closed — every individual issue's PR genuinely merged (spot-checked and cross-referenced with
closedByPullRequestsReferences, no false closures found). But a code-level audit (import-graph traced frombin/gittensory-miner.jsoutward, plus targetedgit grepfor real call sites vs. definitions/tests) found that the actual discover → analyze → plan → prepare → create → manage → repeat loop this whole system exists to run has zero live entrypoint end-to-end today. The individual pieces are real and wired in isolation:opportunity-fanout.js→opportunity-ranker.js→portfolio-discovery.js→portfolio-queue.js, reachable from thediscoverCLI command).manage poll: fully wired (ci-poller.js→event-ledger.js→manage-status.js).governor-ledger.js), reachable viagovernor list..gittensory-miner.ymlparsing: real and live (opportunity-ranker.jscallsparseMinerGoalSpecContent).But the create and repeat steps — the actual point of the system — are not reachable from anywhere:
attempt-runner.js'srunMinerAttempt(the create→review→gate→submit orchestrator from maintainer: wire the submission-gate trigger into the harness driving loop #2337) is never dispatched by the CLI.createCodingAgentDriver/runCodingAgentAttemptinpackages/gittensory-engine) has zero production caller anywhere — only test and doc references.attempt-runner.js's injectablerunSlopAssessmentself-review dependency has no production implementation.loop-reentry.js/loop-closure.js(the "automatically re-invoke discovery on a resolved outcome" pieces) are CLI-unreachable; the Dockerfile's own CMD is["doctor"], a one-shot batch command — nothing autonomously repeats the cycle today.This milestone closes that gap: wire the 5 pieces below, in dependency order, so the loop this whole system was built for actually runs unattended, end to end.
Sub-issues
All maintainer-only: this is the core autonomous-write control-flow, same tier as the rest of Wave 3.