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
The miner's local queue needs a deterministic, pure data-structure layer before any enforcement logic can sit on top of it. This issue is foundation-only: types + pure functions for a bucketed, WIP-capped, cross-repo-diversified queue — no I/O, no SQLite, no wiring into a real run loop yet.
Mirror the shape of src/services/plan-dag.ts (pure PlanDag/PlanStep types + buildPlanDag/validatePlanDag/nextReadySteps free functions, no class, no side effects) for a new PortfolioQueue concept: items bucketed by repo, a per-bucket and global WIP cap, and a pure nextEligibleItems(queue, caps) selector that respects both caps and prefers under-represented repos (cross-repo diversification) using the same kind of stable-sort/min-based tie-breaking src/signals/duplicate-winner.ts already uses for cluster elections.
Deliverables
New packages/gittensory-engine/src/portfolio/queue.ts (or equivalent path under the new shared engine package) exporting PortfolioQueueItem, PortfolioQueue, PortfolioCaps types
Pure enqueueItem(queue, item), dequeueItem(queue, itemId), nextEligibleItems(queue, caps) functions — no Date.now(), no randomness, deterministic given the same input
Cross-repo diversification: nextEligibleItems never returns two consecutive items from the same repo bucket while another repo bucket has eligible items waiting
Unit tests covering: empty queue, single-repo queue at WIP cap, multi-repo diversification ordering, and a full/blocked-queue edge case
JSDoc header explaining this is pure bookkeeping — no enforcement decision, no write action — consistent with how plan-dag.ts documents itself as stateless
References
src/services/plan-dag.ts (134 lines) — the pure DAG/type pattern to mirror
src/signals/duplicate-winner.ts (60 lines) — the min-based deterministic election pattern to reuse for tie-breaking
packages/gittensory-engine/ (new shared engine package per the miner architecture skeleton)
The miner's local queue needs a deterministic, pure data-structure layer before any enforcement logic can sit on top of it. This issue is foundation-only: types + pure functions for a bucketed, WIP-capped, cross-repo-diversified queue — no I/O, no SQLite, no wiring into a real run loop yet.
Mirror the shape of
src/services/plan-dag.ts(purePlanDag/PlanSteptypes +buildPlanDag/validatePlanDag/nextReadyStepsfree functions, no class, no side effects) for a newPortfolioQueueconcept: items bucketed by repo, a per-bucket and global WIP cap, and a purenextEligibleItems(queue, caps)selector that respects both caps and prefers under-represented repos (cross-repo diversification) using the same kind of stable-sort/min-based tie-breakingsrc/signals/duplicate-winner.tsalready uses for cluster elections.Deliverables
packages/gittensory-engine/src/portfolio/queue.ts(or equivalent path under the new shared engine package) exportingPortfolioQueueItem,PortfolioQueue,PortfolioCapstypesenqueueItem(queue, item),dequeueItem(queue, itemId),nextEligibleItems(queue, caps)functions — no Date.now(), no randomness, deterministic given the same inputnextEligibleItemsnever returns two consecutive items from the same repo bucket while another repo bucket has eligible items waitingplan-dag.tsdocuments itself as statelessReferences
src/services/plan-dag.ts(134 lines) — the pure DAG/type pattern to mirrorsrc/signals/duplicate-winner.ts(60 lines) — the min-based deterministic election pattern to reuse for tie-breakingpackages/gittensory-engine/(new shared engine package per the miner architecture skeleton)