resource-efficient-codinglisted

# Resource-efficient coding Use measured, bounded diagnostics before starting parallel work. Prefer the smallest safe job shape that satisfies the acceptance check, and preserve a recovery path for every artifact. ## Establish the budget 1. Run the read-only resource scan for the target repository. Capture logical CPU count/load, system RAM and pressure, Node/process heap, repository-volume free space, bounded footprint categories, and current concurrency. 2. Record traversal limits and unavailable or blocked probes. Treat missing measurements as uncertainty; choose a conservative profile rather than inventing capacity. 3. Select `low-resource`, `balanced`, `fast`, or `ci` explicitly when the lane needs reproducibility. Let automatic selection choose conservatively only when the request permits it. ## Bound work - Derive worker count from logical CPU, current active lanes, RAM per worker, and disk reserve. A recommendation of zero means wait for capacity; never replace it with an unbounded retry loop. - Keep the public request at 8 unless a user explicitly selects another value; accept at most 24 as a request. The host/runtime ceiling, live measurements, and other-task reservations may only reduce the effective count. - Cap job fan-out and queue depth. Keep CPU-heavy jobs near the measured safe CPU cap; use modest oversubscription only for genuinely I/O-bound work. - Use bounded traversal (`maxDepth` and `maxEntries`) for footprint checks. D