Problem
A concurrency-model re-evaluation for AMS is already seeded in this milestone (mirroring ORB's #4942), but that design work needs an accurate, citation-backed baseline of exactly which AMS modules currently assume single-machine, single-process execution. No such inventory exists today, which means the re-evaluation would otherwise have to rediscover this ground truth from scratch, or worse, proceed on assumptions.
Area
AMS / Scaling & capacity
Proposal
Document, module by module, every place AMS's core logic currently assumes single-machine concurrency - in-process locks, local file paths, unguarded shared mutable state - across iterate-loop.ts, submission-gate.ts, portfolio-queue.js, and lint-guard.ts. This is a pure inventory: describe what exists today and cite the exact code, without proposing any redesign or fix.
Deliverables
- An inventory document listing each module, its current concurrency assumption (in-process lock / local file path / unguarded shared state / etc.), and a citation to the relevant code (file + line range or function name)
- No proposed fix of any kind - purely descriptive, intended to seed the separate concurrency-model re-evaluation design issue already tracked in this milestone
Resources
- packages/gittensory-engine/src/miner/iterate-loop.ts
- packages/gittensory-engine/src/miner/submission-gate.ts
- packages/gittensory-engine/src/miner/lint-guard.ts
- packages/gittensory-miner/lib/portfolio-queue.js
Boundaries
- Documentation only - this issue must not change any code behavior, refactor any of the listed modules, or propose a concurrency-model redesign. The actual redesign is a separate, maintainer-owned design issue already seeded in this milestone; this inventory only feeds it.
- Keep the inventory strictly descriptive (what the code does today), not prescriptive (what it should do) - that judgment call belongs to the design issue, not this one.
Problem
A concurrency-model re-evaluation for AMS is already seeded in this milestone (mirroring ORB's #4942), but that design work needs an accurate, citation-backed baseline of exactly which AMS modules currently assume single-machine, single-process execution. No such inventory exists today, which means the re-evaluation would otherwise have to rediscover this ground truth from scratch, or worse, proceed on assumptions.
Area
AMS / Scaling & capacity
Proposal
Document, module by module, every place AMS's core logic currently assumes single-machine concurrency - in-process locks, local file paths, unguarded shared mutable state - across iterate-loop.ts, submission-gate.ts, portfolio-queue.js, and lint-guard.ts. This is a pure inventory: describe what exists today and cite the exact code, without proposing any redesign or fix.
Deliverables
Resources
Boundaries