Skip to content

Logistics Network

0.3.6.1 introduced the shared logistics representation. 0.3.6.2 made transport route-driven: logistics routes own demand, capacity summaries, and bounded route-backed jobs while existing hauling, link, and remote-operation executors migrate through adapters. 0.3.6.3 adds a non-owning infrastructure support projection so those same routes can describe endpoint and road support without taking construction or repair authority from their existing managers.

The network layer owns:

  • typed logistics nodes for producers, buffers, consumers, and transport endpoints
  • typed logistics routes with transport method, lifecycle state, demand, capacity, blockers, fallback route, origin, and evaluation tick
  • route demand semantics for backlog, destination demand, movable amount, expected production, expected throughput, unserved demand, service class, and policy permission
  • transport estimates for active method, cycle ticks, throughput, required carry capacity, and confidence
  • route capacity summaries for nominal, effective, available, loaded, idle, and excess carry capacity, plus deficit and capacity status
  • bounded route-backed jobs keyed by stable route id
  • compact infrastructure support state, component counts, bounded diagnostics, fallback usability, and road coverage for each route
  • deterministic compact node and route identifiers
  • room-owned route summaries under Memory.rooms[roomName].logisticsNetwork
  • bounded route events and job status for operator inspection
  • read-only debug output and aggregate numeric telemetry
  • cadence-bounded derivation of the full room-owned network summary

The normal network evaluation remains a 25-tick base cadence with the existing five-tick deterministic room stagger. While the logistics base lease and a separate enhancement lease are both active, persisted degraded/blocked route health or a material backlog change alongside capacity deficit can justify one additional staggered reevaluation opportunity after at least 10 ticks. The request uses the already-stored network summary; it performs no discovery or pathfinding. No useful evidence means no enhancement request and an available slot may remain unused.

The network layer does not own:

  • full hauler target selection
  • creep role execution
  • link transfer execution
  • remote-operation activation, suspension, or hostile response
  • economy reserve or emergency policy
  • infrastructure proposal, approval, or placement
  • maintenance classification, assignment, or repair execution
  • terminal sends
  • route optimization, road optimization, traffic optimization, or global graph solving

Milestone 0.4.3 adds a deposit-operations adapter. It publishes the exact Deposit as a producer, owned Storage or Terminal as the delivery endpoint, the actual deposit ResourceConstant, self-hauler carry capacity, cargo in transit, estimated cycle time, and lifecycle state. The shared route is representation and observability for this MVP; depositHarvester executes both harvest and transport, so the generic energy-hauler job executor does not claim non-energy routes. No permanent endpoint or Road infrastructure is required.

Identifiers

Node identifiers use compact deterministic parts:

n:<node-role>:<room-name>:<object-or-position-or-room-qualifier>

Route identifiers use the route origin, transport method, owning room, source node, and destination node:

r:<origin>:<transport-method>:<owning-room>:<source-node>:<destination-node>

IDs do not contain game ticks or unstable iteration indexes. Node qualifiers use semantic source, controller, storage, or room identity where possible rather than replaceable endpoint structure IDs. A semantic route ID therefore remains stable while infrastructure moves from planned through completed, becomes damaged or missing, and later recovers or uses a fallback.

Older route summaries whose IDs embedded completed structure IDs are not rewritten in place. They retire through the existing bounded lifecycle as the adapter publishes the semantic replacement, and route-backed jobs are revalidated or recreated under the current route ID.

Route Demand

Route demand keeps separate concepts visible. Most fields are resource-generic; older descriptions below use energy because existing local and remote-energy adapters still represent energy routes:

  • backlog: qualifying energy physically waiting at the source or source buffer.
  • destinationDemand: qualifying free capacity or requested energy at the destination.
  • movableAmount: energy that is both available and useful to move now.
  • expectedProductionPerTick: coarse production rate.
  • expectedConsumptionPerTick: sustained consumer workload, including active and policy-authorized planned upgrader work for controller-buffer routes.
  • expectedThroughput: expected route service rate from the current transport method or cached workload.
  • unservedDemand: destination demand that remains even when no source backlog is ready.
  • serviceClass: critical, urgent, normal, or opportunistic.
  • policyAllowed: whether economy or route lifecycle policy permits ordinary service.

Local creep expectedThroughput uses energy per tick, matching actual throughput. It is the minimum of expected production, destination acceptance over one estimated cycle (current demand plus expected consumption), the creep transport estimate, and assigned carry capacity per cycle. Routes without an allowed current service obligation expect zero throughput.

Critical spawn/extension work and urgent tower operating supply still preempt optional logistics in the hauler role. Controller-buffer and optional storage movement continue to respect economy reserve policy.

Visible dropped energy is assigned once to its nearest room source and rounded up in 500-energy quarter-container bands before joining that source buffer's backlog. This pressure is enabled only while owned Storage has effective energy deposit capacity and remains below the existing critical 95% fill threshold. The grade changes only the input signal: route demand, commitment persistence, idle-capacity vetoes, Launch Control, and population limits are unchanged.

Capacity Estimates

Creep transport uses bounded estimates from existing compact facts. Remote routes reuse cached remote workload distance and cycle information when present. Local creep routes continue using coarse stable cycle defaults; the new cached local road geometry informs infrastructure planning and coverage, not routine transport estimation. Routine demand evaluation does not call PathFinder.search.

Link transport is modeled as link throughput with cooldown and transfer loss, not as a creep round trip.

Capacity summaries distinguish required, assigned, available, loaded, idle, excess, and deficit carry capacity. Each route also exposes a plain status: undersupplied, balanced, or oversupplied.

Local hauler population planning consumes one bounded room-level logistics demand signal. Eligible operational or degraded creep and hybrid routes are grouped by source and destination; the strongest requirement per endpoint is summed on each side and the smaller side becomes the source- or destination-limited shared-fleet requirement. This avoids multiplying carry demand when several alternative routes compete for one source's production or one destination's demand. The requirement is converted to a hauler count from current effective carry capacity, using a 400-carry fallback when no hauler exists, and is capped by logisticsHaulerDemandMaximum (8 by default). Launch Control protects one local service hauler when a container economy needs it. During economy recovery, a missing protected hauler may use the stable tier when affordable so the one-creep floor retains useful carry capacity; low energy still falls back immediately to the minimal body. Capacity above that floor is eligible only after a logistics lease observes persistent performance evidence showing a real capacity deficit, low recent idle capacity, a usable destination, and sustained production or consumption across two fresh network evaluations at least 25 ticks apart. One completed commitment authorizes one additional count; colony-wide authorizations are separated by 150 ticks and the highest-urgency ready room wins after one arbitration tick. Committed count supports predictable replacement only while a logistics lease is active. After lease expiry, living optional haulers finish normally but the spawn target returns to the protected floor. A later fresh evaluation can withdraw the stored need. A momentary container backlog or theoretical route estimate cannot fund another hauler for its full lifetime. Remote hauling increments remain governed by remoteDevelopment, so remote demand and the local floor are not counted twice.

Aggregate fields named for energy are intentionally narrower than the generic route fields. aggregates.demandEnergy includes movableAmount only when route.resourceType === RESOURCE_ENERGY. Deposit and mineral amounts still contribute to genuinely resource-independent route, backlog, throughput, and carry-capacity fields, but are never relabeled as energy. movedEnergy remains fed only by energy route jobs; non-energy deposit outcomes are reported under deposit-operation telemetry.

Local source-container routes estimate sustained production from the active WORK parts of living harvesters assigned to that exact source, capped at the source's natural 10 energy per tick. This keeps hauler demand proportional to current harvest capacity in bootstrap or strained rooms instead of assuming every completed source container is already saturated.

Bootstrap rooms then bound the combined result to two haulers at RCL 1 and three at RCL 2. RCL 3 and later retain the normal logistics cap. This prevents small early bodies from turning a carry-capacity deficit into an idle eight-creep fleet.

debug.logisticsNetwork(roomName) includes the bounded commitment state: committed count, qualifying evaluations, candidate start, readiness tick, and last authorization tick. Commitment updates occur only when the cadence-bounded network writes a new evaluation; population planning does not resample routes.

Remote hauling fleet sizing consumes the persisted route capacity summary when available and falls back to the older workload calculator only before a route summary exists.

Infrastructure Support

Every current route summary includes an infrastructure projection derived after the route adapters run. The projection consumes infrastructure intent and live world facts but does not mutate route execution, approve construction, assign maintenance, activate remote work, or run link transfers. Infrastructure plans, approved orders, and construction sites explain expected future support; they are never counted as completed runtime support.

Component lifecycle is represented independently from route lifecycle:

planned
pending-approval
approved
construction-site
completed
missing
damaged
invalid
unverified

The support layer validates exact expected structure type and position, ownership or accessibility, site presence, and health against one indexed view of relevant visible structures and sites. A stored completed plan or object ID does not prove that the structure still exists. Remote components outside visibility are unverified, preserving uncertainty instead of asserting that they are complete or missing.

Component observations roll up to four support states:

  • fully-supported: all known required components and road segments are completed and healthy.
  • partially-supported: support is planned, approved, under construction, or unverified, without a known critical failure.
  • degraded: an optional accelerator or known road segment is missing, invalid, or damaged. The logistics route may still be operational.
  • blocked: a critical source or destination endpoint is missing or invalid. This describes the infrastructure-supported form; route lifecycle and fallback policy remain separate.

The summary exposes required, completed, planned/approved, site, missing, damaged, and unverified component counts; the worst critical endpoint state; bounded blockers and component samples; fallback route ID and current usability; and road required/completed/planned/site/missing/damaged counts, completion ratio, and repair backlog. Damaged structures remain completed physical components while also contributing to the damaged count and degraded support state.

Link-assisted routes represent their source and receiver links as preferred transport accelerators and keep the stable conventional creep route as their fallback. A missing optional link therefore degrades preferred support without inventing a hard failure for conventional transport. Local source-container, storage/controller-buffer, spawn/extension/tower, and remote container routes use the same shared model. Remote road coverage consumes the existing approved or pending remote-road record and cached path while preserving its approval state. Terminal endpoint roles are representable, but this milestone does not create terminal routes or enable terminal sends.

Route-Backed Jobs

Memory.rooms[roomName].logisticsNetwork.jobs stores compact route-backed jobs. Jobs include stable id, route id, job kind, source node id, destination node id, resource type, requested and remaining amount, optional assigned creep, lifecycle state, creation and update ticks, bounded status, and the route evaluation tick that created or refreshed them.

Lifecycle states:

open
assigned
collecting
delivering
completed
abandoned
suspended

Jobs are created only for operational or degraded routes with policy permission and movable demand. Existing jobs are validated cheaply during the same logistics-network evaluation pass. A job is suspended when demand is temporarily unavailable, such as a full destination or empty source. A job is abandoned when its route disappears, retires, blocks, or policy is revoked. Completed and abandoned jobs are retained briefly for inspection and then pruned. The collection is capped and does not store game objects, paths, or unbounded history.

Local Hauler Route Execution

Ordinary room haulers keep a persistent route assignment in creep.memory.localHaulingRoute. The assignment binds a local energy-source node (a source container or completed storage) to one destination node while action-level withdraw and deliver tasks continue to identify the current physical endpoint.

New assignments choose the eligible local creep route with the greatest unmet carry requirement. Existing assigned hauler carry is subtracted first; once all routes are covered, no additional route assignment is created. Empty haulers release excess assignments deterministically by assignment age and creep name, while loaded haulers always finish delivery before release. This bounded live capacity check continues during CPU recovery using the persisted route estimate, so a stale network summary cannot accumulate avoidable route oversupply. Service class and stable route ID provide deterministic tie breakers. Assignments remain stable while the persisted route is operational or degraded, policy-authorized, and still has a service obligation. They are invalidated when those conditions, the route endpoints, or the assigned source no longer validate.

Urgent spawn, extension, and tower-buffer delivery can preempt the assigned destination without deleting valid route ownership. Storage-backed controller routes withdraw from the primary reserve only above the protected operating reserve and deliver to an available controller container through the existing destination resolver. Container withdrawals and delivery structures reserve expected energy using other haulers' current tasks, so multiple haulers can share a high-capacity route without all committing to the same unavailable amount.

Selection runs only when an ordinary hauler needs a collection assignment. It reads cadence-bounded route summaries and the room's small active-hauler set, does not pathfind, and performs no network discovery. Operators can inspect its cost in the existing per-room creeps.hauler CPU profile metric.

The native-mineral pilot adds one narrower resource-typed job outside broad route discovery. At most one local hauler may withdraw the room's native resource from the exact mineral-operation container and deliver it to primary Storage while another active local hauler preserves ordinary energy service. This bounded fairness prevents continuous source/link activity from starving the route and remains allowed in constrained CPU mode without increasing hauler population. Urgent delivery, critical CPU mode, emergency austerity, and economy recovery still block new collection. The requested amount is bounded by source inventory, remaining native target, hauler capacity, and actual Storage free capacity. Zero physical capacity leaves the room-owned route summary capacity-blocked without assigning a collection job. Once mineral is carried, delivery remains coherent even if urgent energy demand appears or the source empties. Receiver-link unload assignments invalidate when effective Storage energy capacity reaches zero, allowing carried energy to return to conventional delivery instead of retrying an impossible Storage transfer. Lifecycle/allocation work remains attributed to the existing per-room mineralOperation and economy CPU sections; assignment and execution remain inside existing creeps.hauler profiling and reuse the room's existing logistics evidence rather than creating a new periodic manager or CPU bucket.

Before completed storage exists, controller-buffer service continues to use source containers. After storage is completed, the adapter replaces those routes with one storage-to-controller-buffer creep route and treats every controller container as one logical buffer. The route is urgent below 40% when storage is at least 85% full or strategic surplus is building/active, normal below 70%, and opportunistic otherwise. A completed storage/controller link pair contributes its currently usable throughput before residual creep carry is calculated; blocked, empty, or cooling link service therefore restores creep-hauling demand automatically. This is cadence-bounded by the logistics network's 25-tick base interval plus a stable per-room phase of up to four ticks, and is visible in the existing per-room logistics CPU profile.

Adapters

Adapters normalize existing facts into route snapshots:

  • local-hauling represents source-buffer energy movement to spawn and extension demand, tower demand, storage, and controller buffers. Source buffers include graded visible loose-energy pressure when Storage eligibility permits it.
  • link-logistics represents completed source-link to storage-link routes and attaches the conventional local-hauling fallback route when available.
  • remote-operations represents the home-owned remote hauling route through the same route contract, including suspended operations.

Adapters reuse room context, existing remote-operation memory, link topology, store capacities, and current assignments. They do not run pathfinding or call target-selection workflows that would mutate creep tasks.

The infrastructure-support pass runs once after all adapters, builds maps only for relevant visible positions, and reuses cached local and existing remote road geometry. It does not call PathFinder.search; InfrastructureManager owns the bounded local path cache and remote-road planning owns inter-room geometry.

Memory

Only compact summaries are persisted:

Memory.rooms[roomName].logisticsNetwork

The memory record includes schema version, last evaluation tick, route summaries keyed by route id, aggregate counts, recent events, route-backed jobs, and bounded job counters. It does not persist full nodes, Screeps objects, paths, verbose debug strings, or unbounded history. Routes that disappear are retained briefly as retired summaries and then pruned.

The whole network uses a backward-readable storage boundary: runtime managers continue using route and job objects keyed by their canonical IDs, while serialization emits versioned tuples and one room-local dictionary for repeated route, node, fallback, and job IDs. The early and late loop compaction hooks hydrate legacy or encoded records and attach the serializer to newly replaced network snapshots before the engine writes Memory.

Infrastructure support adds only compact counts, state, a bounded blocker list, and the two highest-priority diagnostic component samples to each route. Critical components and worse lifecycle states sort first; aggregate component counts and critical blockers still cover the complete evaluated set. Road coordinate arrays stay under room infrastructure memory. Schema version 4 trims older persisted sample lists once on the ordinary room pass. Existing summaries without the optional field normalize defensively as partially-supported with an unverified critical endpoint and refresh naturally on the next full network evaluation. No manual Memory migration is required.

When the compact infrastructure signature changes, the network emits the existing bounded eight-entry route-event envelope with type infrastructureChanged. Repeated stable validation ticks do not create unbounded history.

Full derivation runs when no room logistics-network memory exists or when the persisted lastEvaluatedAt is at least the configured logisticsNetworkEvaluationInterval old and the room's stable five-tick phase is due. The default base interval is 25 ticks, so an established room refreshes after 25 to 29 ticks. The stable room phase prevents multiple rooms from starting expensive derivation on the same tick where their names permit it. Between evaluations, debug route state, route jobs, remote fleet pressure, and aggregate route telemetry reuse the persisted summary and may lag live room state by up to the configured interval plus four ticks.

Performance And Traffic Feedback

Route performance is an additive schema-v3 summary implemented by logistics/performance. Local and remote hauling report their successful physical collection/delivery boundaries. Link-service haulers report staging assignment lifecycle and dedicated service counters, while LinkManager alone reports parent link-route delivered/completed events for the actual link transfer. Logistics interprets those events; it does not execute creep or link actions.

Each route keeps a cheap current window, EWMA throughput/timing summaries, including full-job, cycle, observable collection-leg, and observable delivery-leg duration, plus bounded traffic tiles and eight material health changes. Schema version 6 stores the complete performance summary and its current window in versioned tuples, removing repeated property names from every route while retaining the decoded runtime contract. Persisted traffic tiles use versioned tuples containing one canonical room-position key, four exact numeric weights, the observation tick, and bit flags for road, route-geometry, and chokepoint state. Consumers decode this through the route-performance codec rather than depending on tuple layout. Anomaly history similarly persists a stable reason code and numeric evidence; human-readable reasons are rendered only at operator boundaries. Windows roll up every 25-29 ticks. Traffic is retained only for active assigned creep/hybrid work, is limited to 24 tiles per route, and decays by 0.85 each window. A topology-fingerprint change discards retained tiles rather than allowing obsolete geometry to influence roads. Congestion needs repeated stuck evidence without fatigue plus plausible nearby traffic; fatigue, route unavailability, and geometry recalculation are separate signals.

Health is healthy, watch, degraded, or critical. Fewer than 75 confidence ticks always remains watch. Each demand summary persists a compact serviceObligation flag, derived from current destination demand plus source backlog or a blocked demand. Zero-expected, zero-actual windows without that obligation remain idle watch; they do not fail throughput or accrue blockage from an endpoint merely having no current demand. Positive delivery with zero expected throughput remains useful actual-throughput evidence, but its efficiency is zero so missing expectation telemetry cannot create perfect active-health evidence. Explicit failed delivery events and route-unavailable, topology, infrastructure, congestion, and fatigue evidence remain independently meaningful.

Displayed performance.throughputEfficiency is an EWMA. Health classification and its human-readable EWMA throughput reason use that same persisted metric basis whenever service is obligated. Thresholds live in config/logistics.ts.

A fallback performance event represents a successfully completed correlated alternative delivery. Urgent preemption alone is not a fallback completion. Each window calculates the fallback share as alternative completions divided by alternative plus preferred completions, returning zero with no completed outcomes; its EWMA therefore remains bounded from zero through one.

Traffic evidence adds bounded score modifiers to the existing route-road priority and can add thresholded unroaded positions already proven to belong to current route geometry. Infrastructure still owns candidates, approval, revalidation, and placement.

Path eligibility is diagnostic only. A persistent stable route needs 20 traversals, two meaningful geometry recalculations, useful throughput, active policy, and a valid topology fingerprint covering stable route and endpoint IDs, room endpoints, transport method, relevant infrastructure components, and road coverage. The persisted rt3: fingerprint is a deterministic dual-seeded FNV-1a 64-bit signature of the versioned source fields. This is not cryptographic, but its fixed 64-bit space makes accidental stale-path reuse impractical for the bounded route population. Legacy verbose v2 and unversioned stateful fingerprints normalize to the same compact signature before comparison, so representation migration does not discard otherwise valid traffic evidence. Transient route state remains excluded. Operational, blocked, or suspended state still participates directly in eligibility and health classification. Eligible routes report eligible-telemetry-only; custom path caching remains disabled because current evidence does not justify a second movement system. Existing moveTo reuse and infrastructure/remote-road geometry caches remain in place.

The shared hauler movement boundary uses Screeps' bounded built-in moveTo reuse for stable target/range pairs: 50 ticks for local acquire/deliver targets and remote legs. A target or range change still invalidates the built-in path immediately. It skips calls when the creep is fatigued or already in range, suppresses a second movement intent for the same creep in one tick, and leaves cross-room pathing and obstacle handling to Screeps. Path visualization is disabled in routine production movement. No custom path or serialized route cache is introduced.

Compact link summaries are sufficient to explain expected/actual post-loss delivery, receiver blockage, missed opportunities, fallback rate, and idle capacity. No richer permanent link ledger was added.

Telemetry And Debug

Aggregate numeric telemetry is exported at:

Memory.stats.rooms.<roomName>.logistics.network

The namespace includes route counts, route demand, available transport capacity, evaluation throttle gauges, and route-driven transport fields:

demandEnergy
movedEnergy
requiredCarryCapacity
assignedCarryCapacity
backlog
expectedThroughput
estimatedCycleTicks
unservedDemand
idleCarryCapacity
excessCarryCapacity
capacityDeficit
jobsCreated
jobsCompleted
jobsAbandoned
fallbackActivations
activeRouteJobs
preemptedAssignments
performance.actualThroughput
performance.throughputEfficiency
performance.averageCycleDuration
performance.averageJobDuration
performance.sourceBlockedTicks
performance.destinationBlockedTicks
performance.routeUnavailableTicks
performance.congestionTicks
performance.fatigueDelayTicks
performance.fallbackRate
performance.idleAssignedCapacity
performance.idleCapacityRatio
performance.backlogDelta
performance.abandonedInvalidRouteJobs
performance.pathRecalculations
performance.healthyRoutes
performance.watchRoutes
performance.degradedRoutes
performance.criticalRoutes
infrastructure.fullySupportedRoutes
infrastructure.partiallySupportedRoutes
infrastructure.degradedRoutes
infrastructure.blockedRoutes
infrastructure.requiredComponents
infrastructure.completedComponents
infrastructure.plannedOrApprovedComponents
infrastructure.activeConstructionSites
infrastructure.missingComponents
infrastructure.damagedComponents
infrastructure.unverifiedComponents
infrastructure.routeBackedRoadSegments
infrastructure.completedRoadSegments
infrastructure.plannedOrApprovedRoadSegments
infrastructure.activeRoadConstructionSites
infrastructure.missingRoadSegments
infrastructure.damagedRoadSegments
infrastructure.roadCompletionRatio
infrastructure.routeBackedMaintenanceCandidates
infrastructure.routeBackedRoadRepairBacklog

All infrastructure metrics are room-scoped numeric aggregates projected from the already-derived route summaries. They do not emit route IDs or reasons and do not recompute planning or maintenance policy. No .total property is added.

Read-only console helpers:

debug.logisticsNetwork(roomName?)
debug.logisticsNodes(roomName?)
debug.logisticsRoutes(roomName?)
debug.logisticsRoute(routeId, roomName?)

Route debug output is generated from persisted compact summaries. It does not perform topology discovery or pathfinding. Route lines show the route and transport state, source/destination, infrastructure support and critical endpoint state, component and road counts, completion ratio, blockers, fallback usability, and last infrastructure validation tick. The room network summary adds aggregate support and road coverage.

Offline verification:

npm run verify:logistics-network
npm run verify:local-hauler-routes
npm run verify:logistics-hauler-demand
npm run verify:infrastructure-road-integration
npm run verify:logistics-performance

CPU Boundary

Route demand, capacity, jobs, and infrastructure support refresh on the existing logisticsNetworkEvaluationInterval cadence (a 25-tick base plus up to four ticks of stable room staggering by default). The support pass reuses collected RoomContext, builds a position index once, retains at most two priority-sorted component samples plus four blockers, and reads cached path geometry. Stats and debug output consume persisted summaries and never trigger another validation pass.

Local route-road pathfinding belongs to logistics/localRoadPlanning, invoked through InfrastructureManager's transitional dirty roads cadence. Paths are cached by stable endpoint and meaningful topology fingerprints, invalidated only when those change, limited to one calculation per infrastructure evaluation, and bounded by the configured path operation limit. The temporary local-road adapter consumes unified intent directly; completed Roads and matching sites suppress duplicate placement, and site creation retains its bounded outstanding/new-site limits. Remote roads reuse approved cached paths and maintain separate cheap-validation and path-planning clocks. Approved remote routes that are blocked or already at their outstanding-site cap are rechecked every five ticks; remote routes with immediate placement capacity retain their per-tick bounded placement opportunity. Completed planned structures are also excluded from ordinary completion discovery because their local loss was not actionable in that pass; visible remote-container loss retains its existing dedicated reconciliation path. CPU appears under the existing per-room logisticsNetwork, infrastructure, and maintenance profile sections; no new synchronous all-room phase is introduced.

Before optional link gathering, an empty ordinary hauler checks cached room energy and tower gauges for urgent delivery demand. The gate performs no target pathfinding; actual path selection remains deferred until the hauler has energy to deliver or needs a concrete acquisition target.

Performance recording is event-driven at existing action/movement boundaries. It performs no PathFinder search and no room-wide scan. Rollup cost is visible under logisticsNetwork; traffic scoring and bounded geometry recalculation remain under infrastructure.

Deferred Optimizations

Future optimization: avoid replacing room logistics-network Memory when the materially relevant route content has not changed. Materially relevant content includes route IDs, lifecycle state, demand summary, capacity summary, blockers, fallback route, active route jobs, and compact infrastructure support.

Traffic lanes, creep swapping, removal or relocation of unsupported roads, automatic infrastructure approval, global path solving, and automatic terminal sends remain deferred. Route-road value is planning and maintenance input only; it is not evidence that an incidental movement path should become permanent infrastructure.