Skip to content

Remote Operations

Emergency CPU Austerity

src/config/cpu.ts exports emergencyCpuAusterityMode. While it is true, routine CIA observation and strategic assessment refreshes, scouting, remote operation evaluation and demand, remote construction, remote hauling dispatch, reservation work, and remote-road planning and placement are administratively suspended. Existing intelligence and remote-operation Memory are retained. Assigned remote creeps return home or idle safely; remote haulers deliver their load, clear the remote assignment when home and empty, and then resume local hauler service. Set the constant to false to restore normal behavior.

The automatic bucket governor is a separate, graduated control. Open posture's single and closed stages command healthy and constrained respectively; recovery commands at least constrained, while emergency commands critical. Advisory observed CPU can add extra recovery pressure. constrained stops replacing scouts and remote reservers while leaving the active remote harvester eligible; critical also stops replacing the remote harvester. Existing creeps are not suicided, and persisted operation state is retained, so remote work winds down through normal creep lifetimes and can resume after bucket recovery and gradual reopening.

Remote lifecycle evaluation, reservation, new remote construction/hauling assignments, and remote-backed population growth now also require the global remoteDevelopment CPU work admission. An extended runway grants a 500-tick lease, which remains valid through a normal move into recovery so useful work is not immediately torn up. Remote development cannot apply until adjacent scouting reports are recent and each latest observation has a matching CIA assessment. Missing or stale observations request scouting; newly observed but unassessed dossiers request intelligence; only then can the lower-priority remote class compete for a lease. A remote lease never enables scouting or CIA implicitly. Existing remote harvesters, reservers, haulers, and builders retain their workflow state; an admitted remote builder may continue at full cadence during recovery, while the prior recovery cadence remains the fallback outside a lease. Emergency posture always overrides admission.

Completed remote-container plans remain the durable repair authority after their old terminal build orders age out of Memory. Repair validation uses the retained approved topology, exact source, position, live container identity, and active operation; site placement still requires the live matching plan and build order. debug.remoteConstruction() prioritizes outstanding sites and completed repairs associated with a current operation instead of reporting an unrelated retired compacted plan.

The mixed local/remote InfrastructureManager now accepts separate Launch Control permissions. A local infrastructure lease can consume non-remote dirty domains, place local packages, and process local orders. A remote-development lease can consume the remote domain and process remote containers and roads. Unadmitted dirty domains remain queued. The existing recovery gate, dirty-domain cache, approval state, retry times, and construction records remain authoritative. The admission primitive controls activation and long-lived remote demand while reusing those existing records for continuation rather than duplicating them.

Remote operations provide bounded remote harvesting. They evaluate nearby rooms passively and persist one independently inspectable objective for each known source. The per-home allocator may admit objectives across multiple remote rooms within explicit persistent-operation and reservation-room caps.

When remoteDevelopment has both its base and enhancement leases, a home with at least two existing non-inactive candidates may reconsider them after 25 ticks instead of the ordinary 50. The request reads only persisted candidate state and the normal evaluation remains on the existing five-tick room schedule. Candidate collection remains adjacent and bounded. Enhancement does not change allocator, harvester, or hauler caps, source selection, operation activation, lifecycle, Economy, CIA, Defense, Logistics, Infrastructure, Spawn, or execution gates.

Mineral Development uses the same allocation model but no remote authority. Its rare enhanced pass can summarize changed existing local mineral-extractor and mineral-container planning records: at most 32 entries are inspected and at most four are retained in one fixed-size readiness conclusion. It cannot propose or approve infrastructure, place sites, change inventory policy, or increase miner population.

External Operation View

Milestone 0.4.0 adds an on-demand ExternalOperation representation around the pilot. It is a read-only adapter: it derives operations from existing home-room-owned remote-operation Memory and reads matching persisted logistics route IDs without writing either source. It adds no recurring evaluation pass, room or creep scan, pathfinding, telemetry namespace, or duplicate operation Memory.

Remote-energy identity is remote-energy:<home-room>:<target-room>. Each selected source becomes an objective with identity <operation-id>:source:<source-id> and resource RESOURCE_ENERGY; a candidate an objective array and now exposes every selected source. Existing matching remote-operations logistics route IDs are exposed as references; absent route state produces an empty list and no route is fabricated.

Candidate eligible maps to external eligible; other candidate assessment states map to candidate. Pilot candidate, active, and suspended/unsafe map to preparing, active, and suspended. The wider candidate, eligible, preparing, active, suspended, winding-down, completed, and retired vocabulary is defined for later operation kinds and lifecycle work, but the current state machines are unchanged.

RemoteOperationsManager remains authoritative for the pilot. CIA owns its source facts and intelligence, economy owns spending/readiness, logistics owns route state and transport, infrastructure owns construction support, spawn/population planning owns workforce demand, defense owns safety policy, and existing creep and structure workflows own execution. No external-operation consumer can activate or alter runtime work in this milestone.

Responsibility Boundaries

The CIA owns facts and advisory intelligence: observations, sources, ownership, reservations, hostile records, freshness, confidence, and strategic assessment categories. Remote operations consume CIA dossiers and do not rescan target rooms.

EconomyManager owns home-room economic health. Remote operations consume a narrow readiness summary derived from the existing economy assessment. The readiness gate can explain emergency recovery, reserve deficits, status, trend, strategic surplus state, and local work pressure.

RemoteOperationsManager owns candidate evaluation, one-room pilot activation, source-objective selection, room safety state, source marginal admission, bounded reasons, transition logs, stats, and the narrow decision that each active objective may request its assigned source container. It is also the authority consumed by remote hauling: hauling exists only when the active objective, exact source, target room, and completed approved container still match. It does not run creep behavior, reserve controllers, place construction sites, or approve construction.

SpawnManager owns remote harvester demand and assignment when a persisted source objective lacks effective exact-source coverage. Expiring harvesters are evaluated against their own objective; a healthy sibling cannot hide a missing replacement. It also adds calculated remote hauling demand when a valid remote hauling job exists; this is additional demand and not permission to steal the final local hauler. When the hauler deficit is caused by remote logistics rather than local economy demand, SpawnManager uses the remote logistics body recommendation from the workload model. Eligible unassigned haulers above the ordinary local baseline reduce additional spawn demand, but do not count as remote route capacity until the assignment manager gives them a remote hauling assignment.

roles/remoteHarvester.ts owns execution only: travel to the assigned room and source, harvest, drop or overflow local energy, and retreat when the operation state is not active.

InfrastructureManager owns the remote infrastructure handoff after that narrow request. It validates the visible target room, selects the container tile, creates the operator-reviewable build order, and places the construction site only after debug.approve(id) revalidates the exact revision and position. Approval persists as a semantic topology snapshot covering home room, target room, source, purpose, structure type, and coordinate. If the approved remote container or its site later disappears, the same still-legal coordinate enters recovery under the existing approval and revision. A changed source, room, purpose, structure type, or coordinate returns to proposal and approval.

InfrastructureManager also owns the approved remote-road route for the active operation. The route connects the home room's primary logistics reserve Storage, or the documented spawn fallback before Storage exists, to the active remote source-container endpoint. Planning may persist while the operation is suspended, but road site placement and remote builder assignment require the operation to be active and CIA to have a fresh complete clear observation of the target room.

RemoteConstructionManager owns the temporary builder execution for that one approved site. It revalidates the active operation, build order, source, planned position, construction site, and assigned builder every tick. When the assigned builder is empty and already in the visible remote room, it may withdraw from the exact approved completed remote source container if it has energy, pick up dropped energy adjacent to the exact assigned source, or harvest from that source while the site is still valid. If no local authorized energy is usable, the builder falls back toward home energy. Construction work remains the priority; when the site is gone because the approved container is complete, the same assignment may repair only that exact approved completed container if it is damaged. After that repair reaches its continuation target, the builder may continue directly onto same-operation approved remote road sites without a home-room refill trip. This is a container-decay safeguard, not a generic remote repair system.

RemoteHaulingManager owns hauling assignment and execution. It selects ordinary hauler creeps, validates the active operation and completed infrastructure identity, runs an explicit phase machine, delegates home delivery to haulerDelivery, and derives distance-aware fleet demand from the source workloads. One fleet may serve multiple objectives, but each assignment and capacity contribution belongs to exactly one source route. Larger exact container backlog wins deterministic assignment priority.

Lifecycle

Records live under:

Memory.rooms[homeRoomName].remoteOperations

Candidate assessment states are:

  • discovered: reserved for candidate records before enough assessment exists.
  • evaluating: the room is known but needs fresher or stronger intelligence, or has not reached the eligibility threshold.
  • eligible: the candidate passes hard blockers, home readiness, and the score threshold.
  • blocked: a concrete safety, ownership, intelligence, or home-readiness gate prevents eligibility.
  • inactive: the candidate is retained but low-value or no longer adjacent.

The first implementation evaluates adjacent rooms returned by Game.map.describeExits(homeRoomName). Broader range and route-based discovery are intentionally deferred. Rooms already owned by the player are excluded from candidate discovery and removed from retained candidate records, so one owned colony cannot be assessed as another colony's remote harvest target.

Scoring And Blockers

Scoring is deterministic and configured in src/config/remoteOperations.ts. The normalized score is bounded to 0..100.

Positive inputs include source count, two-source bonus, CIA remote-harvest score, CIA logistics score, intelligence confidence, adjacency, known source containers, known roads, neutral controller state, and ready home economy.

Penalties include CIA threat score, current foreign-creep presence, active hostile combat body parts, hostile spawns, stale hostile intelligence, foreign reservation, strained home readiness, operating reserve deficit, and heavy local work pressure.

Hard blockers are deliberately conservative:

  • current actionable hostile creeps
  • operational hostile tower
  • unknown hostile tower readiness
  • room owned by another player
  • current foreign reservation
  • obsolete or insufficient intelligence
  • missing home economy assessment
  • home economy emergency
  • home operating-reserve deficit
  • candidate no longer adjacent to the home room

Eligible means "worth considering." A separate persisted pilot operation is created only when the best eligible candidate has a deterministic known source.

Hostile towers are classified as none, dormant, operational, or unknown. Dormant towers are allowed only as conditional risk. Operational or unknown-readiness towers suspend or block active harvesting.

Remote economic operations react to actionable hostile capability, not merely foreign creep presence. Active ATTACK, RANGED_ATTACK, or HEAL parts are combat threats, active WORK is an infrastructure threat, and active CLAIM is a controller threat. Creeps with none of those active parts remain recorded by CIA and may keep operation risk conditional, but they do not suspend harvesting, hauling, reservation, construction, or remote-road placement. CIA body summaries count only active parts; the optional remembered claim count is zero for older records that predate it. Existing candidate summaries without an actionable count retain the legacy conservative raw-count behavior until reevaluated.

Source-objective states are:

  • candidate: reserved for future manual staging.
  • active: one exactly assigned remote harvester may operate for this source.
  • inactive: marginal return does not justify this source, or the source is no longer present in current intelligence.
  • suspended: uncertainty or temporary danger blocks replacement spawning and makes an assigned harvester retreat.
  • unsafe: foreign ownership or reservation requires deliberate reevaluation.

Memory

Each candidate record stores compact output only:

  • home and target room names
  • state, score, eligibility, primary reason, bounded reasons, and blockers
  • source count and bounded source summaries
  • ownership, threat, intelligence, home-readiness, and logistics summaries
  • assessment and observation ticks
  • previous state, transition tick, and bounded lifecycle events

The complete CIA dossier is not copied into remote-operation memory.

Each source objective stores the home room, target room, selected source id and position, state, risk, reason, safe/unsafe observation ticks, assigned harvester name, tower readiness, threat code, bounded telemetry counters, reservation state, compact remote logistics workload facts, and an explainable marginal economic assessment. Marginal cost includes the source Container but excludes shared reservation and amortizes only route tiles not already justified by an admitted sibling.

Remote logistics workload memory lives on the operation as operation.logistics. It stores compact numeric and inspectable policy output only: route revision, route distance, route travel cost, route confidence, roaded/fallback flags, estimated cycle ticks, expected production, required carry capacity, desired hauler count, selected body name/cost/carry/move/capacity, estimated throughput capacity, replacement lead ticks, bounded reason, fallback reason, and evaluation tick. It does not store paths or copy CIA dossiers.

Remote hauling assignment memory lives on the ordinary hauler as creep.memory.remoteHauling. It stores the home room, target room, operation id, source id, exact container id and position, plan/build-order identity, route/workload revision when known, assignment tick, current phase, suspension reason when present, last successful withdraw/delivery ticks, and completed trip count.

Remote construction assignment memory lives on the ordinary builder as creep.memory.remoteConstruction. It stores the home room, target room, assigned construction site id when visible, stable planned route or container position, source id, active operation id, plan/build-order identity, assignment tick, update tick, and whether the builder is building or returning home. The assignment does not grant general remote harvesting or construction authority.

An executable recovery job first reuses an eligible ordinary builder. If none is eligible and no remote construction builder is already assigned, population planning requests one builder above the active local builder count. This incremental demand remains while the recovery is executable and unsatisfied, then clears when a builder is assigned or the job becomes blocked, invalid, or complete. Ordinary local builder demand remains the economy baseline.

When an assigned builder is still outside the target room, remote construction travel requires it to enter the target room before accepting build range. This prevents boundary stalls on inter-room road sites that are physically near the builder but cannot be built from the adjacent room.

Completed remote source-container repair uses a maintenance band instead of trying to keep the container at full health. A new repair assignment starts below 60% hits and an already-assigned builder continues until 80%, leaving healthy containers from monopolizing the remote construction slot ahead of approved road work.

Remote source-container plans are owned by the home room, but structure capacity, visibility, terrain, occupancy, completed-structure lookup, and construction-site lookup are evaluated in the target room. A remote container therefore does not consume or wait on the home room's container allowance.

When the target room is visible, current structures and sites override cached blockers and reconsideration cooldowns. If a completed container or tracked site disappears, infrastructure clears its current object id, keeps the prior coordinate as a recovery candidate, revalidates that tile, and returns through the normal proposal, approval, site, builder, and completion lifecycle. When visibility is absent, the last confirmation is retained and destruction is not inferred. Remote roads similarly separate their current remote endpoint from one bounded last-confirmed endpoint.

The phases are:

  • travel-to-remote
  • withdraw-remote
  • return-home
  • deliver-home
  • suspended-return-home

The assignment remains compact and does not duplicate CIA dossiers or complete operation records.

Remote Hauling

Remote hauling allows ordinary home-room haulers to service the completed source container for the active remote operation. The role remains hauler; there is no remoteHauler role. Remote-assigned haulers receive specialized remote logistics bodies when SpawnManager is spawning specifically for remote hauling demand.

Authorization requires:

  • the operation is active and still owned by the same home room
  • the operation still references the same target room and source
  • the remote harvester pilot is assigned
  • the approved remote source-container plan is completed
  • the completed build order points to the same completed structure id
  • the exact container id and position match the approved coordinate
  • the visible container, when the target room is visible, is adjacent to the intended source
  • the home economy is not emergency, has no operating reserve deficit, and still permits optional remote work

Fleet sizing follows this principle:

required hauling capacity per cycle
≈ expected production per tick × estimated round-trip cycle time

The cycle estimate is based on the current traversable route. Completed road tiles lower the estimated route cost, but incomplete roads do not authorize or block hauling; terrain remains a valid transport surface. Only a complete approved road route uses the roaded movement assumption. Incomplete, unroaded, uncertain, missing, or blocked route metrics use terrain/fallback cost and a safer loaded movement ratio. Loading, unloading, replacement lead time, and a bounded safety margin are included so remote containers do not chronically overflow from rounding just below a whole creep.

Spawn demand compares required carry capacity against effective assigned remote hauler capacity, surplus unassigned home haulers beyond the local essential count, and replacement timing. Assignment demand compares against effective assigned capacity only, so an eligible surplus hauler can be assigned instead of incorrectly satisfying the route while still unassigned. Assigned haulers inside the replacement lead window are treated as ineffective for new demand so overlap can start before throughput collapses.

Body selection is a separate policy decision that consumes the same workload. Fully road-operational routes use deterministic remote-road-* bodies near 2 CARRY : 1 MOVE. Unroaded or uncertain routes use remote-balanced-* bodies near 1 CARRY : 1 MOVE. The recommendation is capped by room energy capacity and can choose either one larger hauler or multiple smaller haulers. If the ideal body is not currently affordable, an affordable remote logistics body can still be spawned so recovery does not wait forever.

Road construction may run in parallel through explicit builder assignments; ordinary local builder targeting still scans only the current room and does not globally scan foreign rooms. The manager may allow travel on persisted completed-plan authority when the remote room is not currently visible. Once the hauler reaches the room or visibility exists, source and exact container validation becomes strict. If the source or container is missing, mismatched, or no longer adjacent, the assignment suspends and the hauler returns home. It never retargets to another container, drop, tombstone, ruin, or source.

Remote hauling consumes the existing operation safety decision. Actionable hostile creep capability, operational or unknown-readiness hostile towers, foreign ownership or reservation, obsolete intelligence, or operation-level suspension block new assignments and make active assignments return home. A known dormant tower remains governed by the existing remote operation risk policy; hauling does not hardcode scenario exceptions.

Claiming a remote target decommissions that home room's remote operation. The operation becomes permanently unsafe immediately, so harvesters, reservers, and remote-assigned haulers return home and no replacements spawn. The returning remote harvester is released as a local builder; reservers become available for future assignments and haulers resume local logistics. The operation record is removed after no living creep references it, and an owned visible room cannot be selected again as a remote target.

While outbound or withdrawing, a remote-assigned hauler does not participate in ordinary local acquisition. Once carrying remote energy or back in the home room, it delivers through the normal home hauler delivery workflow so urgent spawn/extension fill, tower buffer, storage reserve, controller buffer, tower top-off, and overflow policy remain authoritative.

Route Infrastructure And Roads

The shared logistics route for remote hauling consumes the existing home-owned RemoteRoadRouteMemory; it does not create a second remote-road representation. Infrastructure associates that approved route and the exact remote source-container plan with the same stable logistics route ID. The compact logistics summary reports critical endpoint state, preferred road coverage, missing and damaged segments, repair backlog, and visibility-limited unverified components separately from the remote operation's own lifecycle.

The source container is a critical endpoint. A visible missing, wrong-type, or wrong-position container blocks the infrastructure-supported route and existing remote hauling authorization still handles suspension/return-home behavior. A planned, approved, or site-present container remains intent rather than runtime support. When the target room is invisible, completed remote intent is reported as unverified until the live object can be checked; it is not silently counted as current completed infrastructure.

Remote-harvester replacement has one conservative stranded-production guard. It suppresses replacement only while the target and source are currently visible, no adjacent container or container site exists, no executable remote container construction job exists, and remote hauling has no valid pickup. The guard is evaluated only for an otherwise spawn-eligible active operation and reverses as soon as a site, executable construction job, or hauling pickup returns.

Remote road coordinates come from the existing remote-road route's cached cross-room path. Pending coordinates remain planned intent; only the exact approved revision authorizes placement. Full path planning records lastPathPlannedAt and remains bounded by the existing remoteRoadRevalidationInterval for pending routes. Approved cached geometry is checked directly and reused while legal, including across visibility loss, suspension, and operation-record recreation. Cheap validation updates lastValidationTick, completion/site/missing counts, damaged-road count, repair backlog, and the next placement without replacing approved geometry. Endpoint changes or confirmed path illegality may trigger a replan; a materially different endpoint pair or coordinate path requires explicit approval.

An active remote-production route receives a meaningful route-road priority from service class, expected production and throughput, backlog, movable demand, required and deficit carry capacity, active jobs, and degraded/fallback state. Suspended, retired, blocked, policy-denied, or inactive operations do not retain elevated road-planning or owned-room maintenance value. Priority never bypasses route approval, CIA safety, visibility, room ownership/reservation, site limits, economy policy, or emergency mode.

Remote road damage is observable even when all coordinates still contain roads. It contributes to route infrastructure degradation and numeric repair backlog. MaintenanceManager can prioritize route-backed roads visible in the owned home room through its normal important-road class and budget gates. It does not gain authority to assign arbitrary repairs in the remote target room; broader remote road repair execution remains deferred.

Cadence

RoomManager invokes the remote-operation lifecycle on a stable five-tick phase per home room. Phases differ from owned-room intelligence and infrastructure, and the same manager is staggered across room names. Within a lifecycle pass, candidate evaluation remains controlled by remoteOperationsAssessmentInterval. It refreshes earlier when candidate adjacency changes, decision-relevant intelligence changes, or no prior assessment exists. A dossier timestamp changing by itself does not force another assessment. The candidate record stores a compact material signature covering ownership, sources and infrastructure, threat capability and tower readiness, freshness/confidence, and CIA remote-harvest/logistics scores.

Home-readiness changes, including energy movement around the operating-reserve threshold, are incorporated at the configured assessment cadence rather than causing every-tick candidate churn. A lightweight every-tick gate checks visible active targets for foreign ownership or creeps and immediately invokes the lifecycle pass when either appears. This bypass prevents the five-tick schedule from delaying retreat, suspension, or decommission decisions. Per-tick operation telemetry is also reset every tick before creep execution, including on ticks where the lifecycle pass is skipped.

The shared route-infrastructure summary refreshes on the separate logisticsNetworkEvaluationInterval (a 25-tick base plus up to four ticks of stable room staggering by default), so it may lag the operation or a newly damaged road until that pass. Remote-road live counts use the infrastructure planning pass, while a full path plan is restricted by remoteRoadRevalidationInterval unless endpoint positions change. Debug and stats read those persisted results; they do not trigger pathfinding.

Remote haulers attribute exact withdrawals, home deliveries, job timing, invalid-route abandonment, movement delay, and bounded weighted traffic tiles to the stable remote logistics route ID. Traffic is sampled only while a creep is executing that known route. The resulting performance can influence the ordering of already-authorized remote-road work, but cannot activate an operation, approve a route revision, relax CIA safety, or place a site. Custom path reuse remains disabled; cache eligibility is diagnostic evidence only.

Transitions are logged only when state changes, for example:

[RemoteOps] W1N1 -> W1N2 blocked -> eligible: home reserve recovered

Debug

Use:

debug.remoteOperations()
debug.remote()
debug.remoteOperations("W1N1")
debug.remoteOperation("W1N2")
debug.remoteOperation("W1N2", "W1N1")
debug.remoteRoads("W1N1", "W1N2")
debug.logisticsRoutes("W1N1")
debug.logisticsRoute("<routeId>", "W1N1")

The summary command lists candidates by home room and includes one line per source objective with its lifecycle, production, expected/actual throughput, carry requirement, backlog, workforce, infrastructure, economics, and reason. The detailed command accepts either a target room or operation id; a target room prints every sibling objective. Active objectives include assigned creep, source, foreign-creep and actionable-threat counts, tower readiness, last safe/unsafe observations, cooldown, remote source-container infrastructure state, build order id, position, reason, hauling authorization, assigned hauler, active/spawning hauler counts, hauling phase, container id/position/visible energy, carried energy, workload route/cycle/production/required capacity, desired count, assigned capacity, deficit, recommended body cost/carry/move, replacement lead, route confidence, fallback reason, last workload evaluation, suspension reason, assigned remote participant counts, remote container visibility and fill, harvest utilization, hauled and delivered-home counters, delivery ratio, in-transit energy, haul activity ticks, last activity/delivery ticks, remote CPU, and telemetry.

Remote-operation helpers are read-only. Use the existing infrastructure helpers for approval:

debug.buildOrders()
debug.buildOrder("E48N13-buildOrder0001")
debug.explainPlan("E48N13:remote-source-container:<operationId>:<sourceId>")
debug.approve("E48N13-buildOrder0001")

Telemetry

Numeric telemetry is projected under:

Memory.stats.rooms.<homeRoomName>.remoteOperations

remoteOperations is the canonical remote telemetry branch. It uses semantic families for candidate counts, pilot lifecycle state, assigned remote workforce counts, per-tick remote energy, in-transit energy, harvest utilization, hauling activity, route and capacity gauges, selected body metrics, reservation state and activity, remote-container planning/live-container gauges, remote CPU, and separated lifetime counters. The previous flattened remoteOperations.* fields and duplicate economy.remote branch were intentionally removed; see docs/STATS.md for the migration table.

Remote hauling withdrawal and delivery counters measure movement of remote energy. They do not change the existing energy.gained.* contract; harvesting is production, while hauling delivery is transport into the home economy. hauled increments only after successful withdrawal from the exact approved remote source container. deliveredHome increments only after successful transfer into an eligible home-room delivery target, and partial transfers count only the amount actually transferred.

The shared logistics-network foundation also represents the active remote hauling path as a room-owned route summary under Memory.rooms[homeRoomName].logisticsNetwork. This is an inspection and telemetry adapter only; remote-operation lifecycle, suspension, hostile response, fleet sizing, body selection, and exact-container authorization remain owned by the remote-operation and hauling systems described above. Full shared-network derivation is cadence-bounded, so debug route state can lag live remote-operation state by up to the configured logistics-network evaluation interval.

The nested logistics-network infrastructure aggregates expose supported, partial, degraded, and blocked route counts; component and road coverage; damaged and missing segments; and route-backed maintenance candidates/backlog. Infrastructure planning also exports Memory.stats.rooms.<homeRoomName>.infrastructure.remoteRoads.damagedRoads and .repairBacklogHits. These are numeric room aggregates only; route IDs, positions, and reasons remain in room Memory and debug output.

Remote CPU uses the existing profiler. It includes the home room's remote operation, remote reservation, remote construction assignment, and remote hauling assignment phases, plus a deterministic equal share of global remote harvester, remote reserver, remote construction builder, and remote hauling hauler execution across home rooms with remote operations or assigned remote participants. It excludes stats collection and unrelated room work.

Remote harvester, reserver, construction-builder, and hauling travel uses Screeps' built-in path cache for up to 50 ticks while the destination and requested range remain stable. This is evaluated only when movement is needed; target or range changes replace the cached path, and no custom serialized path is stored. Use the native profiler movement/path rows and the existing remote CPU sections to inspect the cost.

Reservation is managed by RemoteReservationManager as a first-class remote room subsystem. It uses one representative active source objective per admitted target room for the shared target controller and never creates one reservation charge per source, requires the target room to be visible, refuses foreign-owned or foreign-reserved controllers, and gates spawning on home economy health. The policy is configured in src/config/remoteOperations.ts with target reservation ticks, renewal threshold, safety buffer, and travel-time estimate values. At most one lightweight remoteReserver (CLAIM + MOVE) serves each admitted target room, up to the two-room home cap; each suspends naturally when its room's operations pause, visibility is lost, or the home economy is no longer healthy enough.

The aggregate remains home-room scoped. In a multi-owned-room runtime, each remote operation is stored under and validated against exactly one owning home room. Home-scoped workforce caps prevent one colony from suppressing another, and a home declines to adopt a target already held by another home. Shared or contested remote policy remains intentionally undefined.

Free-form reasons, usernames, source ids, and target room names remain in ordinary Memory/debug output rather than Memory.stats.

Bounded Highway-Deposit Pilot (0.4.3)

DepositOperationsManager owns the first transient deposit execution lifecycle. The operator authorizes one exact current advisory ID with debug.approveDepositOperation(opportunityId). Approval creates preparing state only. Before Spawn Manager spends energy, the runtime revalidates exact identity, CIA freshness or live existence, route and risk, remaining lifetime, cooldown, expected yield/value, home economy, essential workforce, CPU emergency policy, and repayment of the actual selected body.

The allocation bound is one live preparing, active, suspended, or winding-down deposit operation per home room. State is compact and home-owned under Memory.rooms[home].depositOperations; eight lifecycle events and one retired outcome are retained. CIA remains authoritative for observations and the 0.4.2 evaluator remains advisory. A visible assigned worker refreshes the target room through the ordinary CIA ingestion path every 25 ticks.

One depositHarvester executes both responsibilities of the resource-typed route: it travels to the exact Deposit ID, respects cooldown, carries only the approved deposit resource, and returns it to owned Storage or Terminal. Body selection is deterministic:

  • deposit-light: 3 WORK, 5 CARRY, 4 MOVE, 750 energy;
  • deposit-standard: 5 WORK, 8 CARRY, 7 MOVE, 1,250 energy;
  • deposit-long-haul: 5 WORK, 12 CARRY, 9 MOVE, 1,550 energy.

Capacity and route distance choose the bounded template. Actual parts derive cost, spawn ticks, carry capacity, expected yield, evacuation window, and replacement economics. Spawn Manager remains the only spawn executor, and essential local workforce and lower-priority optional suppression remain intact.

Cheap live disappearance, hostile, cargo, economy, workforce, and CPU checks run each managed tick. Full economics run while preparing and then at most every 25 ticks. This work is visible inside the existing per-room remoteOperations CPU profile section; advisory reassessment remains in depositOpportunities. Dangerous hostiles suspend harvesting and send useful cargo home. Resumption requires full revalidation. If cooldown, lifetime, yield, value, safety, economy, or CPU evidence has decayed too far, the operation enters winding-down, stops replacement and new harvesting, evacuates useful cargo, completes successfully, and retires without requiring the deposit to disappear.

The pilot creates no Containers, Roads, builders, escorts, combat doctrine, Market commands, or permanent highway infrastructure. Movement ticks, delivery trips, carry estimate, spawn investment, expected/actual yield, returned cargo, cooldown evidence, reasons, and final outcome are bounded runtime evidence for later policy.

Per-Home External Allocation (0.4.4)

Each managed home room evaluates a compact allocation envelope at most every 25 ticks, or immediately when its economy/recovery/CPU admission signature changes. The allocator consumes cached remote candidate economics, logistics workloads, infrastructure routes, CIA deposit opportunities, economy reserve policy, local hauler readiness, defense posture, and CPU admission. It performs no room scans or pathfinding.

The envelope keeps spawn energy, external workforce, hauling capacity, CPU units, infrastructure tiles, and reservable target-room count separate. Every objective exposes an atomic minimum request. A request that does not fully fit is deferred; capacity is never spread across partially provisioned operations. Remote source objectives sharing one target room charge controller reservation spawn/workforce/CPU overhead once through a stable room key.

Ranking remains distinct from accounting. Remote energy uses its bounded CIA candidate score and marginal net-energy evidence. Deposits normalize their operation-specific return, duration, strategic value, and risk into the same bounded ordering range. Stable IDs break ties. Healthy incumbents receive an explicit continuation bonus; challengers below the configured decisive margin cannot displace them. A 100-tick admission cooldown prevents rapid readmission. This bias is bounded and does not override a clearly higher-value challenger.

Before ranking, each operation-specific subsystem publishes whether its candidate is currently allocatable and why. For deposits this includes the runtime rule that the exact most-recently-retired opportunity cannot be immediately readmitted. The generic allocator does not inspect retained deposit outcomes itself. A published hard blocker overrides incumbent preference, hysteresis, and cooldown, defers the objective with the owning reason, and charges zero capacity in every dimension.

Current explicit caps are three persistent source objectives, one transient deposit objective, and four objectives overall per home room. Recovery, emergency economy, protected reserve, engaged/critical defense, CPU denial, or loss of the final required local hauler closes the optional envelope. Allocation deferral suspends new optional investment while preserving operation memory. Remote and deposit creep behavior continues to own safe carried-resource return.

Inspect the policy with:

debug.externalAllocation()
debug.externalAllocation("W1N1")

Non-Goals

This milestone does not:

  • build arbitrary remote construction sites
  • plan remote links
  • generate arbitrary remote infrastructure plans or build orders
  • let builders harvest unrelated remote sources or use unrelated containers
  • salvage arbitrary remote resources
  • implement combat, sophisticated flee pathing, or dismantling behavior
  • calculate new full inter-room logistics paths every tick
  • automatically repair arbitrary roads in a remote target room
  • destroy or relocate roads that no longer support a known route

External Resource Portfolio (0.4.5)

Each valid remote-source or highway-deposit opportunity is translated into a bounded comparable rank before the unchanged external allocator runs. The translator preserves native score/value evidence for debug output and derives the rank directly from productive benefit, strategic demand, opportunity urgency, confidence, logistics and persistent-support burden, risk, bounded continuity, cached executable Market evidence, and measured performance. It does not add the former allocation score to the portfolio result.

Remote performance comes from the existing matching remote-operations logistics route. Fewer than 250 confidence ticks remain neutral; mature evidence can adjust rank by at most ten points. Completed useful route infrastructure adds at most six continuity points. Deposit outcomes retain one capped EWMA summary for each of the four deposit resource constants, with at most 20 samples and a ten-point maximum ranking influence. No route history, price history, or per-operation outcome ledger is added.

Industry contributes only a three-level read-only signal: zero for no demonstrated need, one for stock below the strategic target, and two when an active Factory recipe depends on the resource. Market value reuses cached surplus-liquidation or active bounded-deal evidence. These signals cannot admit work, create creeps, or execute deals. Native eligibility and the 0.4.4 allocator remain authoritative.

Broader Remote Autonomy (0.4.6)

External admission policy is persistent and independent by operation kind. Both persistent remote energy and transient highway deposits support manual, recommendation-only, operator-approved, and autonomous. The default is autonomous, preserving the authority already exercised before the policy was made explicit. A legacy deposit operator-approved selection migrates without escalation.

New objectives must pass their native intelligence and economics checks plus the policy thresholds in config/externalAllocation: portfolio rank, CIA confidence, expected deposit return, and kind-specific risk. The unchanged 25-tick allocator then applies per-home multidimensional budgets, concurrency caps, incumbent bias, decisive-preemption margin, and admission cooldown. Policy evaluation performs no room scan, pathfinding, or telemetry recalculation.

Allocation loss, economy emergency, defensive danger, severe CPU restriction, or an exact operator suspension stops new optional work while preserving state. Remote harvesters and deposit harvesters use their existing return-home paths, so carried energy or deposit resources are evacuated before retirement. Persistent objectives that remain economically blocked or permanently unsafe for 500 evidence ticks retire; participant-free stale records are removed only after another 1,500 ticks. Deposit expiration, rising cooldown, and uneconomic remaining yield continue through the existing winding-down outcome lifecycle. CIA dossiers are not deleted.

Inspect and control the boundary with:

debug.externalAuthority()
debug.externalAuthority("remote-energy", "recommendation-only")
debug.externalAllocation("W1N1")
debug.externalControl("approve", "W1N1-W2N1-source-id", "W1N1")
debug.externalControl("suspend", "W1N1-W2N1-source-id", "W1N1")
debug.externalControl("resume", "W1N1-W2N1-source-id", "W1N1")
debug.externalControl("retire", "W1N1-W2N1-source-id", "W1N1")

Next Milestone

Remote Operations 0.3.5 and milestones 0.4.0 through 0.4.6 are complete. Escorts, combat spawning, and automated retreat doctrine are deferred to 0.5.0 Military / Defense Doctrine.