Screeps AI Roadmap

"Build an autonomous colony, not a collection of scripts."

Vision

The long-term goal of this project is to create an AI that behaves like a real colony.

Each subsystem should have a clear responsibility:

Economy Manager
Room Manager
Maintenance Manager
Intelligence Manager
Operations Manager

Managers make decisions.

Creeps simply execute those decisions.

Guiding Principles

Managers own strategy.
Creeps own execution.
Knowledge is persistent.
Everything measurable should be observable.
Every important decision should be explainable.
Human intervention should continuously decrease over time.

0.2 — Intelligent Single Room (Current)

Goal: Create a completely autonomous single-room colony.

✅ Foundation

Actions
Workflows
Spawn Manager
Role Manager
Room Manager
Economy Manager
Maintenance Manager

✅ Observability

Grafana
Economy telemetry
Harvesting telemetry
Tick speed
Live API
Debug commands
Strategic metrics

✅ Launch Control

The bucket governor now admits major optional subsystems through bounded, inspectable applications rather than posture checks alone.

[x] Urgency-bearing lease applications with bounded fixed Memory
[x] One moderate-horizon lease and six extended-horizon leases
[x] Local logistics and infrastructure priority above remote development
[x] Scouting → CIA assessment → remote-development readiness chain
[x] CIA strategic-assessment and owned-room refresh admission
[x] Separate local and remote InfrastructureManager permissions
[x] Logistics-network evaluation admission
[x] Lifetime-evidence and lease gates for haulers above the local floor
[x] Two-evaluation hauler commitments with colony-wide launch pacing
[x] Priority/rotation lease fairness and recovery-safe deferral cleanup
[x] Infrastructure lease gate for ordinary builders, preserving only critical-defense repair and colony-bootstrap continuity
[x] Mineral-development policy and population admission
[x] Dynamic governor diagnostics and deterministic verification
[x] Separate binary enhancement leases for useful bounded analysis from all six existing Launch Control owners, with at most two concurrent enhancements

Market planning is intentionally omitted until a market subsystem can publish real work; an unused class must not win and waste a lease. Telemetry publication remains a separate policy discussion.

✅ Resource Governor Foundation

CPU and Memory are sibling resource signals beneath a lightweight Resource Governor coordinator. The CPU branch and six-slot Launch Control experiment retain their existing behavior. The Memory branch adds slow-cadence pressure and growth evidence, global telemetry, and one bounded CIA-owned reclamation consumer. Governors describe capacity and pressure; Launch Control still allocates optional work, and domain managers remain the only authorities that may classify their state as reconstructible. The first compute-only enhancement leases now consume both signals for all existing work classes: elevated Memory remains eligible for their bounded compute and fixed-size conclusions, while critical Memory prevents enhancement.

🚧 Logistics

[x] Storage transition
[x] Human-approved link infrastructure planning
[x] Link-assisted runtime logistics
[x] Link integration live validation and tuning
[ ] Terminal integration (future)

Terminal integration remains open for a future live RCL5 colony.

0.3 — Autonomous Expansion

Goal: Teach the colony to understand the outside world.

The colony should never expand simply because it can.

It expands because intelligence recommends it.

✅ 0.3.0 — CIA

(Creeps Intelligence Agency)

Create the intelligence backbone.

Responsible for:

Scout reports
Room dossiers
Persistent observations
Hostile tracking
Ownership history
Resource surveys
Confidence scoring

The CIA never makes decisions.

It provides intelligence.

Status: implemented as of project version 0.3.0. The CIA owns persistent room dossiers, visible-room observation ingestion, hostile records, ownership history, resource surveys, confidence metadata, query helpers, debug output, and numeric observed-room telemetry.

✅ 0.3.1 — Strategic Assessment

Every known room receives a continuously updated score.

Categories:

Economy
Threat
Logistics
Expansion
Remote Harvest
Military Value

Output:

Overall score Recommendation Confidence

Status: implemented as of project version 0.3.1. The assessment is advisory: it scores known rooms, records compact CIA events, exposes debug and stats visibility, and does not alter scout, spawn, economy, logistics, expansion, or military behavior.

✅ 0.3.2 — Autonomous Link Infrastructure Planning

Introduce the first colony-authored infrastructure plan.

Responsible for:

Link-only autonomous need detection
Source-side and storage-side link candidate scoring
Persistent room infrastructure memory
Human-approved build orders
Revision-specific approval safety
Construction-site placement after revalidation
Bounded infrastructure events
Infrastructure stats and debug commands
Link route-readiness data for future logistics

Status: implemented as of project version 0.3.2. The planner derives link coordinates from visible room topology and stores them in room memory rather than source configuration. It proposes RCL5 source-to-storage link infrastructure, waits for explicit console approval, places approved legal link sites on a later room tick, and tracks completion. Operational link transfers and hauler-demand reduction remain separate follow-up work.

✅ 0.3.3 — Link-Assisted Runtime Logistics

Completed links become part of energy logistics without replacing conventional hauling.

Responsible for:

Completed source/storage link route discovery
Hauler load-source-link and unload-receiver-link jobs
Urgent conventional delivery preemption
Mixed source-by-source link and conventional hauling
Link route pressure telemetry
Debug output for routes, jobs, assigned haulers, and fallback state

Status: implemented as of project version 0.3.3. Haulers can service usable completed source-to-storage link routes while preserving source-container to spawn/extension/tower/storage/controller hauling as the fallback and emergency path. Completed source-link paths are now serviced directly by the planted harvester; conventional source hauling remains the topology-loss fallback. Hauler body specialization, richer per-route pressure history, and a separate logistics role were originally deferred until live telemetry proved the workload split. Receiver-link service now has one narrow specialization: living general haulers absorb work pressure first, sustained unresolved pressure can authorize one bounded short-distance hauler body, and that creep retains its home-duty identity without introducing a separate role. Richer route history and a parallel logistics role remain deferred.

✅ 0.3.4 — Infrastructure Autonomy

Capture the first major step from hand-configured construction toward colony-authored infrastructure.

Implemented:

Room-owned infrastructure memory
Link need detection from visible topology
Source-side and storage-side candidate scoring
Human approval boundary for build orders
Revision-specific safety checks before placement
Build-order lifecycle debug commands
Infrastructure event history
Infrastructure stats in Memory.stats
Link network readiness data for logistics consumers
General room-scoped infrastructure planning across legal structure types, with deterministic doctrine, conservative proposal caps, and multi-room-ready build-order identity

Status: implemented as of project version 0.3.4. Infrastructure planning is now an explicit colony subsystem instead of scattered configuration. The approved build-order planner has expanded from link-only proposals to general, room-scoped infrastructure planning across legal structure types while retaining explicit operator approval before construction execution.

Follow-up implementation: infrastructure planning now behaves as persistent infrastructure intelligence rather than a periodic full-room rediscovery loop. Meaningful room changes mark affected planning domains dirty, and the manager refreshes a bounded number of dirty domains per tick. This preserves the recommendation/approval/execution split while reducing worst-case CPU from synchronized planning sweeps.

2026-07-27 follow-up: local route roads and currently unlocked extension capacity now use revisioned aggregate work packages. One approval covers one exact coordinate set, while construction-site placement remains progressive and revalidated. Legacy individual orders continue under their original approvals.

2026-08-08 follow-up: normal construction endorsement is now controlled by a persistent manual/autonomous operator policy, defaulting to autonomous. Autonomous build orders and local aggregate packages omit console-ticket metadata but retain the existing plan/execution split and all live placement revalidation. Mode changes release pending records in place without duplicating intent. Remote roads remain manually approved as a separate cross-room safety boundary.

2026-08-14 follow-up: one-at-a-time colony-layout Extension migration now uses the same global infrastructure authority. Manual mode preserves exact operator approval; autonomous mode selects and authorizes the next exact one-for-one pair only after replacement recovery completes. Existing rollout, topology, economy, workforce, hostile, and immediate-replacement checks remain mandatory.

This milestone still does not define a permanent bunker or base layout.

2026-08-12 follow-up: the first colony-layout patch adds a persistent advisory RCL8 reservation above the existing construction authority. It adopts Storage or the deterministic primary spawn as an anchor, scores the agreed logistics/buildability/defense balance, and stores exact core and Lab slots, hybrid five-Extension pods, RCL activation phases, and shared lanes. Bounded validation reports blockers without changing established geometry. No layout slot is yet converted into an infrastructure package or construction site; extension and road execution remain a separately reviewed Patch 2.

2026-08-21 migration-planning follow-up: the current source now includes colony-layout Extension and road work packages plus assisted Extension migration, while generic infrastructure plans/build orders remain authoritative for most fixed structures and construction execution. The responsibility and Memory audit in docs/COLONY_LAYOUT_INFRASTRUCTURE_MIGRATION.md defines the staged path to fixed-layout authority, logistics-owned arterial road intent, a replacement construction executor, and final removal of legacy and temporary migration machinery. This entry records planning only; no cutover is implemented.

2026-08-21 Milestone 2 follow-up: colony layout is now the sole geometry authority for fixed local structures. Core, Lab, Extension, local Container, Extractor, and Link coordinates flow into retained build orders/work packages as execution copies only; unbuilt competing fixed-local legacy coordinates are invalidated without removing live structures or sites. Roads, Ramparts/Walls, remote source Containers, remote Roads, build-order replacement, and migration cleanup remain explicitly deferred.

2026-08-21 Milestone 3A follow-up: desired local Roads now have one typed, deterministic read boundary. It derives a coordinate-deduplicated view from colony-layout lanes and current cached local arterial route intent, retaining a layout-support flag and sorted supporting route IDs without persisting another road map. Arterial pathfinding ownership, road packages/execution, and all remote-road behavior remain unchanged for Milestones 3B and 3C.

2026-08-21 Milestone 3B follow-up: logistics now owns persistent local arterial route selection, scoring/evidence, endpoint and topology fingerprints, cache invalidation/reuse, and bounded Room.findPath geometry refresh through logistics/localRoadPlanning. The cache intentionally remains at the single transitional infrastructure.routeRoadIntents path. InfrastructureManager only orchestrates at its established cadence and adapts authored intent into retained road packages. Milestone 3C still owns package/consumer cutover; remote roads, construction replacement, and Memory cleanup remain deferred.

2026-08-21 Milestone 3C follow-up: local construction, logistics support, maintenance/performance evidence, strict road retention, debug inspection, and verification now use unified local-road authority or its single route-specific arterial input. local-road-route and colony-layout-road packages, local road plans/orders, package route serialization, and road package telemetry are removed. The one arterial cache moved to RoomMemory.logisticsRoadPlanning.routeRoadIntents with a one-way migration and no dual write. InfrastructureManager retains only cadence orchestration and a small direct unified-intent placement adapter; generic construction approval and executor replacement remain Milestone 4. Remote roads and local path policy are unchanged.

2026-08-22 Milestone 4 follow-up: managers/localConstruction now consumes colony-layout fixed slots and unified local-road intent through one typed, live-safe placement boundary. Generic build orders and Extension/Lab packages no longer execute migrated local structures; they remain only as temporary manual-approval/debug compatibility. Exact fingerprint approvals are available through debug.localConstruction, autonomous policy remains direct, and the existing RCL, structure/site limit, validation, retry, and pacing gates remain bounded. Remote construction and Roads, Walls/Ramparts, demolition, migration cleanup, and deployment remain deferred to their explicit checkpoints.

2026-08-22 Milestone 5 follow-up: the colony-layout infrastructure migration is complete. Fixed-local plans/orders, all infrastructure work packages, legacy local approval tokens, rollout controls, and assisted Extension migration were removed. A version-1 surgical cleanup filters mixed legacy dictionaries while preserving remote source Containers, remote Roads, Walls/Ramparts, colony layout, focused local-construction state, and logistics road-planning state. The generic infrastructure lifecycle now exists only for its named remote/defense owners; migrated local state cannot regenerate.

✅ 0.3.5 — Remote Operations

First foundation:

[x] Passive remote-operation assessment
[x] Home-room economy readiness gate
[x] CIA-backed adjacent candidate evaluation
[x] Room-owned remote-operation memory
[x] Debug and numeric telemetry
[x] Deterministic verification scenarios

Next pilot:

[x] Operator-reviewed first remote-harvest policy
[x] Remote miner role
[x] Container planning
[x] Approved remote source-container construction execution
[x] Remote source-container construction can bootstrap from its associated local source
[x] First remote hauling pilot
[x] One ordinary home-room hauler assigned through active remote-operation authority
[x] Exact approved remote-container withdrawal validation
[x] Safe return-home and normal home logistics delivery
[x] Remote hauling demand, debug visibility, telemetry, and verification
[x] Remote-operation economy, throughput, and CPU telemetry
[x] Remote road planning and construction
[x] Controller reservation behavior
[x] Distance-aware remote hauling fleet sizing
[x] Specialized remote logistics bodies or roles

Status: implemented as of project version 0.3.5. The first home-room-owned remote operation can activate an approved adjacent remote, harvest one assigned source, request and build the exact remote source container, haul from that container through normal home logistics, reserve the remote controller, plan and build the remote road, suspend and automatically resume around hostile safety state, size the remote hauling fleet from route distance and production throughput, select workload-aware remote logistics hauler bodies, and expose debug plus numeric telemetry for the full pilot.

This is deliberately home-room-owned and remote-operation-scoped. It does not enable arbitrary multi-room infrastructure autonomy, combat doctrine, or general remote construction execution.

0.3.6 — Logistics Network

Introduce a shared colony logistics model describing how resources move between producers, buffers, transport routes, and consumers across rooms.

Existing haulers, links, roads, remote operations, and future terminals should become executors or infrastructure for the same route model rather than independent logistics systems.

The milestone should preserve the existing ownership boundaries:

Economy policy decides whether resource movement is economically permitted.
Logistics planning decides what needs to move, over which route, and with what capacity.
Infrastructure planning decides what structures should support those routes.
Creeps and owned structures execute transport.
Telemetry records whether routes are performing as expected.
Terminal execution remains disabled until separately approved.

✅ 0.3.6.1 — Logistics Network Foundation

Define the shared contracts needed to represent colony logistics without significantly changing existing behavior.

Define typed logistics nodes for producers, buffers, consumers, and transport endpoints.
Define typed logistics routes between nodes.
Define route transport methods:
creep
link
terminal
hybrid
Define route lifecycle states:
planned
incomplete
operational
degraded
blocked
suspended
retired
Define compact route identifiers that remain stable across ticks.
Represent local-room, remote-room, and link-assisted routes through the same shared model.
Add adapters around existing hauling, link, and remote-operation behavior rather than rewriting those systems.
Preserve existing economic reserve and emergency-mode restrictions.
Persist compact route summaries in room-owned memory.
Add bounded route events or reasons for operator inspection.
Add read-only debug output for known logistics nodes, known logistics routes, route state, transport method, source and destination, current blockers, and fallback route.
Add numeric telemetry for known routes, operational routes, degraded routes, blocked routes, route demand, and available transport capacity.
Avoid introducing a global graph solver or centralized logistics super-manager.
Preserve current runtime behavior unless a route adapter exposes an existing bug or inconsistency.

Status: implemented as of project version 0.3.6.1. The bot now has typed logistics node and route contracts, deterministic compact route identifiers, room-owned route summaries and bounded events, adapters for local hauling, link-assisted logistics, and remote-operation hauling, read-only debug inspection, deterministic offline verification, and room-scoped numeric telemetry. Existing hauler selection, link transfers, remote-operation policy, economy reserve gates, infrastructure approval, terminal behavior, bodies, and roles remain authoritative in their existing systems.

Deferred follow-up: avoid replacing room logistics-network Memory when the materially relevant route content has not changed. Materially relevant content includes route IDs, route lifecycle state, demand, available transport capacity, blockers, and fallback route.

✅ 0.3.6.2 — Route-Driven Transport

Convert local and remote hauling pressure into explicit route demand and route-backed transport jobs.

Derive route demand from source production, source-container backlog, destination demand, storage reserve policy, spawn and extension demand, tower operating demand, controller supply permissions, and remote-operation production.
Estimate expected resource throughput for each active route.
Estimate route cycle time using path distance and transport method.
Calculate required hauling capacity from expected production, route distance, round-trip duration, creep carry capacity, and expected downtime.
Compare required transport capacity with assigned transport capacity.
Allow remote hauling fleet sizing to consume route demand directly.
Allow local hauling demand to consume route backlog and capacity.
Associate persistent logistics jobs with route IDs.
Preserve valid route assignments across ticks.
Clear or reassign jobs when the source disappears, destination disappears, route becomes blocked, route is suspended, destination becomes full, source no longer has qualifying resources, or economic policy revokes permission.
Represent existing link service jobs as route-backed jobs.
Continue allowing urgent spawn, extension, and tower work to preempt optional logistics.
Preserve mixed operation:
conventional hauling when no link route exists
link-assisted hauling when topology is usable
fallback hauling when link routes are blocked
Track route-level backlog and unserved demand.
Track assigned carry capacity by route.
Track idle or excess hauling capacity.
Add debug output showing required carry capacity, assigned carry capacity, estimated cycle time, source backlog, destination demand, and assigned creeps.
Add telemetry for demand energy, moved energy, required carry capacity, assigned carry capacity, backlog, jobs created, jobs completed, jobs abandoned, and fallback activations.

Status: implemented as of project version 0.3.6.2. Route summaries now own explicit demand semantics for backlog, destination demand, movable energy, expected production, expected throughput, unserved demand, service class, and policy permission. Route capacity summaries estimate cycle time, required carry capacity, assigned/effective/idle/excess carry capacity, and an undersupplied/balanced/oversupplied interpretation without pathfinding in routine evaluation. Room-owned logistics memory now keeps bounded route-backed jobs with stable route IDs and lifecycle states, and remote hauling fleet pressure consumes the persisted route capacity summary before falling back to the older workload calculator. Existing local hauling and link service execution remain progressive adapters: urgent spawn, extension, and tower delivery still preempt optional logistics, and link-service creep jobs now use the same semantic route IDs exposed by logistics-network debug output.

CPU boundary: route demand and job refresh runs only during the existing cadence-bounded logistics-network evaluation. It reuses room context, link classification, remote-operation workload memory, and current store/carry values. It does not call PathFinder.search, rebuild all jobs every tick, or publish telemetry by recomputing logistics decisions.

Follow-up logistics-driven hauler demand now models sustained controller consumption from active and policy-authorized desired upgraders. Population planning reads the cadence-bounded persisted route summaries and current hauler carry capacities, derives one endpoint-deduplicated shared-fleet requirement, and combines it with the existing local-essential and remote hauling requirements by maximum rather than adding overlapping requests. SpawnManager remains the owner of spawn execution.

✅ 0.3.6.3 — Infrastructure and Road Integration

Allow logistics routes to consume infrastructure-plan data and allow infrastructure planning to understand which routes structures support.

Extend infrastructure plans with route-supporting metadata.
Associate planned structures with logistics route IDs.
Allow route infrastructure to include source containers, destination containers, road segments, source links, receiver links, storage links, controller links, and terminal endpoints.
Treat infrastructure plans as route intent rather than runtime truth.
Revalidate all completed structures before runtime route use.
Distinguish between planned infrastructure, approved infrastructure, construction sites, completed infrastructure, missing infrastructure, and damaged infrastructure.
Calculate route infrastructure completeness.
Expose whether a route is fully supported, partially supported, degraded, or blocked by missing infrastructure.
Allow road planning to use active logistics routes as candidate paths.
Prioritize road proposals by route throughput, route importance, source production, assigned traffic, economic value, and route permanence.
Prioritize road maintenance by operational route value.
Give remote harvesting roads higher value when they support active production.
Avoid giving temporary scout or incidental movement paths the same weight as permanent logistics routes.
Detect missing road segments along active routes.
Detect road segments that no longer support any known route.
Do not automatically destroy, relocate, or remove existing roads.
Preserve the infrastructure approval gate for all new construction.
Preserve build-order revision and revalidation behavior.
Allow link routes to consume infrastructure-authored endpoint intent.
Continue validating actual completed link topology at runtime.
Add debug output showing route infrastructure completeness, planned road segments, completed road segments, missing road segments, planned link endpoints, completed link endpoints, and unsupported or stale route infrastructure.
Add telemetry for route road coverage, route infrastructure completeness, missing road segments, damaged route segments, and operational routes lacking full support.

Status: implemented as of project version 0.3.6.3. Logistics routes now carry a compact infrastructure-support summary that keeps infrastructure lifecycle separate from route lifecycle. Planned, pending, approved, construction-site, completed, missing, damaged, invalid, and currently unverified components are revalidated against live visible world facts. A route can therefore remain operational through its conventional fallback while preferred link or road support is partial or degraded. Legacy route summaries without the new field load as safely unvalidated and refresh naturally on the normal network cadence.

Infrastructure planning associates retained fixed endpoints with stable route IDs. Persistent active local hauling routes produce logistics-owned cached arterial intent, while remote hauling reuses the existing approved remote-road geometry and approval lifecycle. Unified local-road intent deduplicates shared tiles while preserving every supporting route ID, and the focused shared executor places that view without plan/package copies. Road priority consumes service class, production, throughput, backlog, movable demand, required and deficit carry capacity, active route jobs, route state, fallback use, and active remote-production state. Existing roads, construction sites, and approved remote-road coordinates suppress duplicate placement. Site limits, visibility, and safety gates remain unchanged; exact local manual approval is available through debug.localConstruction.

Extension capacity now executes directly from unlocked colony-layout pods. Retained deterministic RCL-phase packages remain only as transitional manual approval/debug compatibility and do not place children. The focused executor revalidates ownership, terrain, duplicates, site limits, access, and RCL capacity before every placement. Local Roads use the same executor boundary.

Maintenance builds one room-scoped route-road value index from persisted route and path summaries. Roads supporting operational or degraded logistics routes are important maintenance work with a bounded score bonus; they never displace existing critical-container handling and still obey construction ordering plus economy and emergency budget gates. Suspended, blocked, retired, policy-denied, or inactive-remote routes do not retain elevated road value.

CPU boundary: infrastructure support is derived during the existing cadence-bounded logisticsNetwork pass using collected room context and one indexed view of relevant live structures/sites. Local route pathfinding occurs only after route or meaningful endpoint/topology invalidation, is cached by fingerprints, is limited to one path calculation per infrastructure evaluation, and uses a bounded operation limit. Remote routes reuse their approved cached paths; their path-planning clock is separate from cheap validation. Planning and association work remains visible in the existing infrastructure CPU profile section, support derivation in logisticsNetwork, and maintenance classification in maintenance.

Room-transition migration follow-up

The scout is the first consumer of the low-level, fixed-size room-transition workflow. Migrate remaining cross-room movement incrementally after live scout validation: remote haulers and hostile retreat/flee paths first, then remote harvesters and reservers, remote construction builders, and colonization creeps. Each migration should preserve role policy, verify runtime module names, and avoid adding a global edge-pushing rule.

✅ 0.3.6.4 — Performance and Traffic Feedback

Measure whether logistics routes are performing as expected and use persistent movement evidence to guide later optimization.

Add compact rolling performance summaries per route.
Track expected versus actual throughput.
Track average job completion duration.
Track estimated versus actual route cycle time.
Track source blockage.
Track destination blockage.
Track route-unavailable ticks.
Track fallback activations.
Track jobs abandoned because of invalid or blocked routes.
Track unused assigned capacity.
Track backlog growth or reduction over time.
Track repeated creep congestion where it materially affects route performance.
Track excessive fatigue or movement delay on active routes.
Track repeated path recalculation where it materially affects CPU or throughput.
Identify route chokepoints from persistent traffic evidence.
Prefer stable road-backed routes where practical.
Add narrow path reuse or route caching where live evidence shows value.
Avoid permanent caching that can survive invalid topology changes without revalidation.
Feed meaningful traffic evidence back into road planning.
Allow frequently traveled unroaded tiles to become road-planning candidates.
Allow low-value or unused route segments to lose planning priority.
Preserve creep role ownership of action execution.
Avoid moving traffic-control policy into the infrastructure planner.
Evaluate whether current link-route telemetry is sufficient.
Compare the value of compact rolling summaries against richer per-route history.
Add richer route history only when current telemetry cannot explain recurring throughput loss, repeated receiver blockage, persistent fallback hauling, missed transfer opportunities, or unexplained idle link capacity.
Do not add tick-by-tick permanent route ledgers by default.
Add debug output showing expected throughput, actual throughput, average cycle time, blockage ratios, fallback rate, congestion indicators, and route health.
Add telemetry for throughput efficiency, average cycle duration, source blocked ticks, destination blocked ticks, route unavailable ticks, congestion ticks, fallback rate, and idle capacity.

Status: implemented as of project version 0.3.6.4. Stable local, link, and remote routes now retain compact 25-tick counters plus EWMA throughput/timing, blockage, fallback, idle-capacity, backlog, job-abandonment, and explainable health summaries. Legacy schema-v2 Memory normalizes additively to schema v3. Traffic is assigned-route-only, limited to 24 tiles per route, decays each window, and requires repeated non-fatigue delay with nearby traffic before declaring a chokepoint. Eight material health changes are retained.

Existing road priority consumes bounded unroaded, fatigue, congestion, backlog, and route-health evidence. Thresholded tiles must belong to current route geometry; proposal, approval, revision, safety, economy, and site-placement gates remain authoritative. Geometry recalculation stays in infrastructure.

Custom serialized path reuse remains disabled. Persistent routes can report eligible-telemetry-only after stable endpoint, traversal, throughput, and recalculation thresholds; fingerprint changes invalidate eligibility. Compact link summaries were sufficient, so no richer permanent ledger was added.

Deterministic verification is available through npm run verify:logistics-performance. Proposed Screeps Lab scenarios and tolerances are documented in docs/LOGISTICS_PERFORMANCE_VALIDATION.md, but they are intentionally not claimed passing.

Narrow Local Mineral Pilot

The first mineral-production step is now implemented for visible owned RCL 6+ rooms: one optional mineralMiner operates an already approved and completed extractor plus adjacent container. The fixed 10 WORK / 1 CARRY / 5 MOVE miner is requested only while the economy permits optional work, essential workforce recovery is inactive, emergency CPU austerity is off, and CPU population mode is healthy or abundant. It avoids harvest calls during extractor cooldown and stops for depletion or container capacity.

The next narrow step now carries the native resource from that exact approved container to completed primary Storage through ordinary local haulers. Once the extractor, container, and Storage are usable, the room protects one current density-derived deposit cycle (15k/35k/70k/100k) from energy occupancy. Economy and strategic-surplus pressure use the resulting effective energy capacity; mineral jobs remain optional, incremental, and bounded by actual Storage free capacity and remaining target inventory. Depletion records a regeneration deadline and density is verified once when that deadline arrives.

Terminal staging, terminal.send(), markets, labs, factories, broad resource logistics, dedicated mineral haulers, and remote mineral extraction remain deferred. Existing infrastructure proposal, approval, revision, revalidation, construction authority, CPU population caps, and emergency gates remain unchanged.

Future Terminal Compatibility

Terminals should be represented by the logistics network without enabling autonomous sends in this milestone.

Represent owned terminals as logistics nodes.
Represent possible terminal transfers as inter-room route edges.
Include transaction energy cost in route cost estimates.
Expose terminal readiness through the shared route model.
Expose send capacity, receive capacity, terminal cooldown, terminal energy reserve, transaction cost, source-room permissions, and destination-room readiness.
Allow future terminal routes to coexist with creep and link routes.
Do not call terminal.send() in 0.3.6 unless separately approved.
Defer automated room balancing.
Defer mineral and commodity distribution.
Defer market integration.
Defer terminal resource policy beyond route modeling and readiness.

Explicitly Deferred

The following are outside the intended scope of 0.3.6:

Automatic road destruction or relocation.
Global minimum-cost-flow optimization.
A universal all-resource logistics solver.
Autonomous terminal sends.
Market orders and market trading.
Lab supply chains.
Factory supply chains.
Mineral distribution.
Traffic lanes or one-way roads.
Full creep swapping or advanced movement coordination.
Permanent tick-by-tick route event history.
Replacing existing creep role state machines.
Moving economy, infrastructure, links, terminals, and remote operations into one centralized manager.

Definition of Done

0.3.6 is complete when the colony can represent and inspect local, remote, and link-assisted resource movement as explicit routes.

For an active remote route, operator inspection should expose information similar to:

Route: E48N14/source/abc -> E48N13/storage
State: operational
Transport: creep
Distance: 47 tiles
Estimated round trip: 102 ticks
Expected production: 10 energy/tick
Required carry capacity: 1,020
Assigned carry capacity: 1,100
Backlog: 384
Expected throughput: 10 energy/tick
Actual throughput: 9.7 energy/tick
Infrastructure:
  container: completed
  roads: 41/47 completed
  missing road segments: 6
Source blockage: 0.8%
Destination blockage: 0%
Fallback activations: 0

For an active link-assisted route, operator inspection should expose information similar to:

Route: source container -> source link -> storage link -> storage
State: degraded
Transport: hybrid
Reason: receiver link frequently full
Fallback: conventional hauling
Expected throughput: 6.4 energy/tick
Actual throughput: 4.9 energy/tick
Assigned hauler service capacity: sufficient
Receiver blockage: 18%
Fallback activations: 12

At completion:

Local hauling can be described through route demand.
Remote hauling fleet sizing can consume route capacity requirements.
Link-assisted logistics can be represented through the same route contract.
Infrastructure plans can identify which logistics routes roads and links support.
Road construction and maintenance can use route value.
Route performance can be measured against expected throughput.
Traffic evidence can inform future road and movement optimization.
Terminals can fit into the model later without redesigning the network.

0.3.7 — Colony Continuity

Purpose: turn temporary remote execution into durable colony intent, then use that foundation to establish and operate additional owned rooms.

0.3.7.1 — Durable Remote Intent

Separate operator approval from temporary execution state.

Preserve approved container and road intent across hostile interruptions, visibility loss, creep deaths, missing sites, and infrastructure damage.
Recover the same approved topology automatically when it remains legal.
Request new approval only when the proposed room, source, position, route, or purpose materially changes.
Introduce explicit disrupted, suspended, recovering, and operational semantics.
Prevent short-lived degradation from resetting an operation to its initial proposal state.
Replace the current recovery behavior where a lost completed container deliberately returns to the normal proposal and approval workflow.

0.3.7.2 — Colony Isolation and Multi-Room Verification

Status: Complete (2026-07-25)

Owned rooms are independent colony roots. Each room owns its economy, population demand, spawning, infrastructure, maintenance, logistics, local creeps, and remote operations. Operational creep ownership follows memory.homeRoom, with bounded legacy inference only when a creep is in an unambiguous owned room.

The main loop discovers every visible owned room and runs one independent RoomManager for each; global role dispatch, intelligence assessment, Lab publication, and stats collection remain once-per-tick.
Spawn names and memory include home-room identity, preventing same-role, same-tick collisions and cross-room population suppression.
Remote operations remain under home-room memory, use home-scoped workforce caps, and decline to adopt a target already owned by another home.
Existing room-qualified infrastructure, route, build-order, operation, and telemetry identities remain the isolation boundary.
verify:colony-isolation covers empty-memory tick-1 startup and two-owned-room ownership, demand, spawn, remote-operation, ID, telemetry, and global-dispatch boundaries.

No new scheduler or cadence was added; existing per-room cadence and CPU profile sections remain the operational budget surface. Expansion selection, claiming, pioneers, bootstrap transfers, and inter-colony policy remain deferred to 0.3.7.3 and later.

0.3.7.3 — Colony Bootstrap

Status: Complete (2026-07-26; beta operation confirmed)

Execute a durable colonization operation explicitly authorized by the operator through debug.colonize(target, bootstrapper). The bootstrapper owns the record until a completed first spawn and ordinary target RoomManager execution allow a single handoff.

A narrow bootstrap manager persists explicit lifecycle phases, blockers, assignments, controller facts, first-spawn intent, milestones, and bounded events under the bootstrapper room.
A small CLAIM/MOVE colonizer attacks foreign ownership or reservation before claiming a neutral controller. Expected deaths and temporary legal blockers produce automatic replacement or retry rather than cancellation.
Parent-owned builders receive explicit pioneer assignments, harvest locally, protect the controller from downgrade, selectively dismantle only a recorded spawn-tile blocker, and construct the stable first-spawn plan.
Spawn-site creation is deduplicated and recovers the same intended position if the site disappears. Completion stops parent demand and releases surviving pioneers as target-owned ordinary builders.
Spawnless active targets defer the normal mature-room manager stack until an owned spawn exists. Pioneer energy targets and sources are cached, with broad opportunistic-energy discovery bounded to a 25-tick retry cadence; costs remain visible in the existing room and remote-construction CPU profile sections.
debug.colonization(target) exposes the durable state; debug.cancelColonization(target) is terminal, idempotent, and retains bounded history without killing creeps. No resume command exists.

Autonomous expansion candidate selection, petitions, approval envelopes, player dormancy inference, strategic expansion timing, and generalized Operations or military planning remain deliberately deferred. CIA remains advisory and does not initiate colonization.

0.3.7.4 — Multi-Room Autonomy

Status: Complete (2026-07-26)

Each spawned owned room is an independently managed colony root while the main loop retains only tick orchestration, failure isolation, and summary reduction.

A single tick-local creep index feeds home-room contexts and global role dispatch, replacing repeated whole-empire creep scans in normal orchestration.
Explicit autonomy states distinguish operational, workforce recovery, economy recovery, and physically blocked rooms. An empty colony with an idle local spawn and 200 available energy immediately selects the existing [WORK, CARRY, MOVE] emergency harvester; below 200 energy it reports a blocker and does not request cross-colony help.
One room-manager exception records a bounded tick/reason and does not prevent later rooms or global creep roles from running.
Bootstrap completion continues to convert surviving pioneers into ordinary target-owned builders. Remote operations, participants, logistics, and infrastructure remain explicitly owned by their original home colony.
Economy pressure reuses the prior persisted maintenance summary, so the current MaintenanceManager plan is the only full classification pass. Workforce recovery skips optional terminal, infrastructure, assignment, logistics recalculation, and dashboard work while retaining economy, spawning, towers, creep execution, remote safety reconciliation, and stats.
Stable terminal transaction-cost samples are cached until the terminal-room set changes or 1,000 ticks elapse.
debug.colonies(), debug.colony(roomName), Memory.stats.rooms.<room>.autonomy, and Memory.stats.colony expose the resulting state. verify:multi-room-autonomy covers the pure projections, ownership index, physical recovery boundary, summary reduction, and structural CPU invariants.

Automated terminal balancing, rescue creeps, remote migration, shared spawn queues, and every other inter-colony support policy remain deferred to 0.3.7.5.

0.3.7.5 — Inter-Colony Support

Status: Narrow energy-assistance MVP complete (2026-08-28)

The first bounded support slice lets one adjacent healthy owned colony use one explicit ordinary-hauler assignment to raise a struggling owned colony toward a hysteretic reserve recovery threshold. Recipient EconomyManager reserve deficit is the request authority; donor EconomyManager surplus permission and surplus energy, local workforce coverage, defense posture, and emergency state are hard gates. One grant is capped at 10,000 energy, one donor and recipient pair is active at a time, normal recipient delivery priorities remain authoritative, and invalid or suspended assignments return cargo safely.

Implemented:

[x] Adjacent owned-room creep energy assistance
[x] Recipient reserve-deficit admission and recovery hysteresis
[x] Donor surplus, workforce, defense, and emergency safety gates
[x] One additive ordinary-hauler assignment above local/remote demand
[x] Compact debug, stats, CPU profile, and deterministic verification

Still deferred:

Terminal energy and resource balancing.
Emergency reinforcement requests.
Cross-room bootstrap assistance.
Strategic resource routing.
Colony-wide expansion capacity assessment.

0.3.8 — Defensive Readiness

Build the colony's pre-military survival layer before novice-area protection ends. This milestone consumes CIA hostile facts and keeps execution inside the existing tower, spawn, economy/logistics, maintenance, and role boundaries.

[x] Room-scoped defensive assessment with peace, alert, engaged, and critical postures and inspectable transition reasons
[x] Capability-aware live threat assessment with a CPU-cheap peaceful path
[x] Deterministic coordinated tower targeting and combat repair suppression
[x] Emergency tower logistics and optional-work suppression
[x] Absolute-hit critical-rampart readiness and urgent active-defense repair
[x] One bounded owned-room defender role and combat-aware population demand
[x] Conservative safe-mode recommendation/automatic-policy gates
[x] Debug, dashboard, numeric telemetry, and deterministic verification

This milestone is about survival. It does not introduce offensive pursuit, squads, patrols, escorts, raids, siege, conquest, or a general Operations architecture.

0.3.9 — Operator-Directed Industry

Purpose: introduce production mechanics under explicit operator intent first, so live operational experience can inform later autonomy while CPU cost, resource spending, and logistics remain bounded.

0.3.9.1 — Operator-Directed Factory Production

[x] Operator explicitly selects one Factory product and requested batch size
[x] Normalize output upward to whole recipe cycles and explain the target
[x] Narrow room-scoped FactoryManager executes compact persistent orders
[x] Existing ordinary haulers stage one input cycle and evacuate output
[x] Economy optional-spending permissions and CPU bucket governance remain authoritative without discarding paused orders
[x] Start, inspect, and safe-cancel console workflow with useful blockers
[x] Deterministic verification and Screeps runtime-module validation

This milestone executes any recipe compatible with the room's current Factory; it does not select recipes. It introduces no market integration, Terminal or inter-room sourcing, prerequisite-chain production, profitability model, stock-target policy, general resource solver, or IndustryManager.

0.3.9.2 — Operator-Directed Lab Reactions and Bounded Deals

[x] Let the operator select the enabled UO product and bounded quantity
[x] Establish and validate a functional reaction-lab topology, including resolving the current infrastructure doctrine so the minimum usable cluster can exist instead of treating one Lab as the whole cluster
[x] Stage both reagents, run bounded reactions, and evacuate product with existing creeps
[x] Import only the active UO order's O shortfall from E48N14 to E48N13
[x] Add bounded immediate Market buys/sales with explicit price, Terminal energy, capacity, and credit-reserve controls
[x] Bypass optional-work recovery for explicit directives while respecting economy emergency and CPU governor emergency
[x] Add inspectable start/status/cancel operations

This sibling milestone remains operator-first. It enables only UO reactions, one configured O supply lane, and immediate deals against existing orders. It does not introduce boost lifecycle behavior, persistent Market orders, autonomous selling, generalized mineral distribution, or autonomous chemistry selection. Six Labs use stable per-order input/output assignments; generalized dynamic assignment, boost-Lab reservation, compound contention, and throughput optimization were deferred. Patch 2 adds one stable serialized boost-Lab reservation; generalized assignment and throughput optimization remain later evidence-driven work.

0.3.9.3 — Operator-Directed Boosted Workforce

[x] Add duration-bound builder and harvester boosted-count intent without changing final setSpawnCount semantics
[x] Reject cross-intent collisions and validate harvester counts against exact visible source-service slots
[x] Represent E48N13 through a capability list and map role intent to UO/LH
[x] Reuse bounded UO/LH reactions when raw inputs are ready and stored Market buy policy otherwise
[x] Assign one stable output/boost Lab and reuse protected ordinary hauling for exact compound and Lab-energy staging
[x] Provision ordinary-role creeps through temporary spawn, boost, deploy, and target ownership handoff lifecycle state
[x] Count incoming builder capacity without local duplicate spawning
[x] Reserve boosted harvester replacements conservatively while preserving an immediate ordinary local recovery escape for uncovered sources
[x] Use a three-WORK UO source-saturating body and reconcile delayed handoffs away from fresh safety replacements to the oldest eligible source incumbent
[x] Let expiration/cancellation stop only uncommitted work; committed workers finish and surviving boosted creeps live out ordinary roles
[x] Bound preparation to a five-tick cadence, skip global creep discovery when inactive, expose a dedicated CPU profile section, and add deterministic checks

The MVP deliberately serializes active boost preparation even though six Labs could support more physical concurrency. Stable per-slot assignment prevents reaction/boost collisions now; generalized simultaneous lab allocation, throughput optimization, higher-tier compounds, combat boosts, and autonomous ROI decisions remain deferred until live evidence justifies them.

0.3.9.4 — Bounded Industry Autonomy

[x] Detect raw-mineral surplus only when native inventory is effectively full, the deposit has regenerated meaningful supply, and strategic/committed stock remains protected
[x] Compare executable raw sales with enabled Factory compression on an exact recipe-normalized raw-input basis
[x] Compare compatible U/O and L/H independent paths with the enabled Lab compound path, requiring a configurable gross-value premium for processing
[x] Reuse Factory, Lab, protected hauling, Terminal, and immediate-deal executors through one compact bounded plan
[x] Preserve manual/autonomous operator authority, emergency gates, explainability, deterministic verification, and numeric Market telemetry

The first autonomy slice liquidates demonstrable extraction-blocking surplus; it is not general trading intelligence. It uses current executable Market buy orders, values gross credits without energy shadow pricing, and stores no price history. Evaluation is capped at two compatible raw minerals and the existing enabled compression/reaction capabilities.

The remaining progression is still informed by live evidence:

operator-directed execution
bot recommendations
operator-approved recommendations
configurable stock targets and bounded policies
broader selective autonomous production only after operational evidence supports it

Any later autonomy must account for economy health, resource reserves, logistics capacity, CPU-governor state, actual demand, and eventually explicit market and empire resource policy. It should grow systematically rather than become one general autonomous industry solver.

0.4 — Remote Resource Operations

Goal: Expand the first remote-harvesting pilot into a bounded external-resource operations system capable of identifying, evaluating, provisioning, executing, and retiring multiple kinds of opportunities outside owned rooms.

Scaling does not mean only increasing the number of remote rooms.

A single external room may contain multiple useful energy sources, while highway rooms can contain transient resource deposits and other strategic opportunities. The colony should learn to reason about these opportunities individually, compare their value against their cost, and allocate limited economic, logistical, CPU, and defensive capacity deliberately.

The existing 0.3.5 remote-harvest implementation remains the starting point. 0.4 should generalize that proven pilot incrementally rather than replace it with a universal operations solver.

Existing ownership boundaries remain authoritative:

The CIA owns persistent observations, hostile facts, resource surveys, confidence, and advisory strategic information.
Economy policy decides whether external investment is affordable.
Remote operations decide what external objectives should be active.
Logistics decides how resources move and how much transport capacity is required.
Infrastructure decides what persistent structures and roads should support qualifying routes.
Spawn planning allocates creep population and body investment.
Defensive readiness decides whether external activity is safe to continue.
Creeps and structures execute assigned work.
Industry and Market systems may expose strategic demand or executable value but do not directly command remote operations.
CPU governance remains authoritative over optional and periodic work.

0.4 must not become a centralized manager that absorbs economy, logistics, spawning, infrastructure, defense, industry, or CIA responsibilities.

✅ 0.4.0 — External Resource Operations Foundation

Generalize the existing single-source remote-energy pilot into a reusable external-operation contract without significantly changing live behavior.

The first milestone should make an operation represent an objective rather than merely a room.

An external operation may eventually be persistent, such as remote energy harvesting, or transient, such as exploiting a highway deposit before it decays.

Completed Foundation

[x] Define typed external-operation identities independent of room identity
[x] Represent the home room, target room, operation kind, resource type, and objective targets explicitly
[x] Distinguish persistent and transient external opportunities in the contract
[x] Define bounded operation lifecycle states such as:
candidate
eligible
preparing
active
suspended
winding-down
completed
retired
[x] Preserve compatibility with the existing 0.3.5 remote-energy operation through read-only normalization
[x] Preserve RemoteOperationsManager as the runtime authority for the current remote-energy pilot
[x] Avoid rewriting existing remote harvesting, reservation, remote construction, remote roads, or hauling execution merely to satisfy the new representation

Logistics Integration

[x] Associate active external operations with existing logistics route IDs
[x] Allow one operation contract to expose multiple logistics route IDs
[x] Avoid creating a second transport model inside external operations
[x] Preserve conventional fallback behavior when preferred infrastructure is unavailable

Observability

[x] Add read-only debug output for known external opportunities
[x] Add read-only debug output for active external operations
[x] Explain operation identity, kind, persistence, lifecycle mapping, home and target rooms, resource, objective details, associated logistics route IDs, and runtime authority
[x] Add deterministic verification for operation lifecycle and ownership boundaries

CPU Boundary

[x] Avoid every-tick global room or creep discovery when external operations are inactive
[x] Avoid pathfinding in the external-operation representation

Status: implemented and live-validated. 0.4.0 introduces a typed, read-only external-operation and objective representation over the existing remote-energy pilot. RemoteOperationsManager remains authoritative for activation and runtime behavior; the new layer deterministically derives operation identity, lifecycle, resource and objective information, and existing logistics route IDs without persisting a second operation model or changing harvesting, hauling, reservation, construction, roads, or safety behavior. Live equivalence inspection confirmed that the generalized view matches the active remote pilot. Multi-source execution, deposit intelligence, allocation, and broader autonomy remain later milestones.

0.4.1 — Multi-Source Remote Energy ✅

Expand the proven remote-energy pilot from one source per operation to multiple economically independent sources within the same remote room.

A remote room should not be treated as a single indivisible resource target.

The bot should be able to conclude that both sources are worthwhile, only one source is worthwhile, or neither source is worthwhile.

Source Objectives

[x] Represent each remote source as an independently inspectable objective
[x] Preserve one shared room-level safety and reservation context
[x] Allow one remote room to contain multiple individually valuable source objectives within one operation
[x] Preserve the association between each source objective and its existing logistics routes
[x] Keep logistics authoritative for each route's demand, capacity, backlog, performance, and infrastructure support
[x] Allow source objectives to activate and suspend independently where safe
[x] Preserve exact source assignment for harvesters
[x] Preserve exact remote-container validation

Infrastructure

[x] Support one approved source-container lifecycle per active source
[x] Support source-specific remote-road intent
[x] Reuse shared room-path geometry where that is demonstrably useful without conflating source routes
[x] Preserve existing construction approval and revalidation boundaries
[x] Avoid constructing infrastructure for sources that are not economically admitted

Workforce

[x] Allow more than one remote harvester when justified by active source objectives
[x] Size remote harvester demand per active source
[x] Preserve source replacement coverage
[x] Prevent one source's failure or blockage from silently stripping another source of required workforce

Remote Logistics

[x] Calculate route demand independently per remote source
[x] Calculate required carry capacity independently per route
[x] Allow shared hauler capacity where existing logistics assignment semantics support it
[x] Prevent duplicated or conflicting hauling assignments across source routes
[x] Preserve urgent home-room logistics preemption
[x] Preserve safe return-home behavior when a source objective suspends

Economics

[x] Estimate source-specific production value
[x] Estimate source-specific spawn and logistics cost
[x] Allow marginal sources to remain inactive when their expected return does not justify their cost
[x] Preserve home-room reserve and emergency policy
[x] Avoid assuming that every visible remote source should be exploited

Observability

[x] Show remote-room operation state separately from individual source-objective state
[x] Expose production, expected throughput, actual throughput, carry requirement, backlog, allocated workforce, infrastructure completeness, and suspension reasons per source
[x] Add deterministic verification for one-source, two-source, partial-source, blocked-source, and suspended-source cases

This milestone proves that remote scaling is based on resource objectives rather than room count.

0.4.2 — Highway Deposit Intelligence ✅

Teach the CIA and external-operation assessment layer to recognize temporary highway deposits as first-class economic opportunities.

Deposits are fundamentally different from normal remote energy sources.

They require no room ownership or permanent extractor, but their usefulness is transient and degrades as harvesting raises cooldown. Their value therefore depends on time, distance, logistics, resource demand, risk, and expected remaining yield.

Bounded Scouting Frontier and Highway Exception

The current scout baseline deliberately selects only the deduplicated union of rooms directly adjacent to every currently owned room. This replaced adjacency-from-current-room targeting, which allowed scouts to walk outward indefinitely and created an unbounded set of intelligence-only room dossiers. Ordinary remote-energy scouting should keep that one-room limit because the colony is not expected to support routine remote workforces at arbitrary range.

Highway intelligence needs a separate, explicit range allowance. It must extend the frontier far enough to find plausible deposit rooms without restoring open-ended exploration:

[x] Preserve the owned-room adjacency union as the default scout frontier
[x] Add a separately configurable highway frontier with a maximum route distance, candidate-room cap, and per-home-room work budget
[x] Classify highway rooms deterministically from room coordinates so candidate discovery does not depend on already having intelligence for the room
[x] Generate highway candidates with a bounded breadth-first traversal of the room-exit graph from each eligible owned room, visiting each room at most once and stopping at the configured distance and candidate caps
[x] Retain the transit-room chain needed to reach each candidate, but do not allow a scout's current room to become a new unbounded exploration origin
[x] Rank the nearest reachable unobserved or stale highway rooms ahead of farther candidates, while accounting for known hostile rooms, closed room status, temporary avoidance, and route length
[x] Cache the compact frontier or waypoint plan and refresh it on a bounded cadence or when ownership, avoidance, route viability, or intelligence freshness invalidates it; do not rebuild routes every tick
[x] Keep intelligence retention bounded to the configured frontier, active waypoint routes, live external opportunities, and existing operational references
[x] Add deterministic verification that highway exceptions reach the intended radius but cannot chain outward beyond their authorized frontier

CIA Observation

[x] Record visible highway deposits in CIA resource surveys
[x] Record:
deposit type
position
observation tick
current cooldown
last cooldown
ticks to decay
[x] Preserve confidence and freshness semantics
[x] Remove or expire stale deposit opportunities safely after their useful lifetime
[x] Avoid retaining unbounded historical deposit records

Opportunity Assessment

[x] Create advisory deposit opportunities from CIA observations without independently rescanning external rooms
[x] Carry intelligence freshness and confidence into deposit evaluation
[x] Estimate expected yield under rising cooldown and the useful harvesting window before expiration
[x] Estimate travel burden from potential home rooms
[x] Estimate spawn and workforce investment
[x] Estimate logistics burden and transport requirement using existing logistics summaries
[x] Include economic affordability using existing economy summaries
[x] Include defensive and route risk
[x] Produce an explainable eligibility and value assessment with explicit blockers
[x] Reject opportunities that cannot repay travel and spawn overhead before expiration
[x] Reject opportunities whose remaining lifetime is insufficient for useful harvesting and evacuation
[x] Allow opportunity value to decay as cooldown rises
[x] Keep assessment advisory until a later milestone explicitly grants activation authority
[x] Keep evaluation cadence-bounded and avoid duplicate discovery or business-logic recomputation
[x] Expose a meaningful periodic evaluator through an inspectable CPU profile section

Resource Value

[x] Distinguish Metal, Silicon, Biomass, and Mist
[x] Allow strategic inventory demand to influence opportunity value
[x] Allow existing bounded Industry autonomy to expose whether a deposit resource has useful downstream demand
[x] Allow current executable Market value to contribute to advisory opportunity scoring where appropriate
[x] Preserve strategic or committed stock protections
[x] Avoid introducing permanent price history or a general Market forecasting system

Scouting

[x] Ensure highway observation cadence can discover deposits with enough useful lifetime remaining
[x] Let scouts consume an assigned highway waypoint chain one room transition at a time, preserving forward progress toward the highway instead of opportunistically retargeting to ordinary stale rooms along the route
[x] Prioritize completion of an admitted highway route over routine adjacent refresh, while reserving enough scout capacity or cadence that ordinary CIA coverage is not starved
[x] Score highway observation targets using route distance, observation age, known risk, and expected discovery value; once a deposit is known, allow its remaining useful lifetime and advisory value to raise revisit priority
[x] Reuse cached highway waypoints and the shared room-transition workflow; retreat, blocked-room avoidance, and destination-edge settlement remain authoritative over forward path priority
[x] Allow deposit opportunities to influence scouting priority without starving ordinary CIA refresh
[x] Keep deposit scouting bounded by CPU governance
[x] Avoid permanent high-frequency highway scanning by default

Observability

[x] Add debug output for known deposit opportunities
[x] Explain deposit type, age, freshness, confidence, remaining lifetime, cooldown, estimated yield, travel burden, spawn and logistics burden, affordability, risk, eligibility, value, blockers, resource demand, and recommendation
[x] Add numeric telemetry for visible deposits, viable opportunities, rejected opportunities, and opportunity value
[x] Add deterministic verification for fresh, stale, high-cooldown, short-lifetime, high-risk, and attractive deposit cases

This milestone is intelligence and recommendation only. It should not yet spawn deposit harvesters.

Status: implemented. Highway candidates are generated from owned-room roots by a deterministic, capped breadth-first traversal and consumed as compact one-room waypoint missions. CIA deposit observations feed a cadence-bounded, advisory-only external-opportunity assessment with no spawn, logistics, construction, Market-execution, or activation authority. Deposit age, confidence, lifetime, cooldown, travel, economics, logistics, risk, Industry demand, cached executable Market value, blockers, telemetry, and debug output are all inspectable. Runtime exploitation remains exclusively 0.4.3 scope.

0.4.3 — Bounded Deposit Harvesting ✅

Execute the first transient highway-deposit operation using the external-operation framework.

The first implementation should remain deliberately narrow:

one home room
one active deposit operation
one deposit objective
bounded workforce
existing logistics and spawn authority
no permanent highway infrastructure requirement

Activation

[x] Allow an eligible deposit opportunity to become an operator-approved active operation
[x] Preserve explicit home-room ownership
[x] Revalidate deposit existence, lifetime, cooldown, safety, and economy state before commitment
[x] Prevent duplicate operations targeting the same deposit
[x] Record the economic assumptions used when the operation is admitted

Deposit Workforce

[x] Add the minimum creep behavior required to harvest a deposit safely
[x] Prefer reuse of existing role/workflow architecture where cleanly possible
[x] Size WORK, CARRY, and MOVE investment according to travel, cooldown, and expected throughput
[x] Preserve home-room essential workforce before optional deposit investment
[x] Account for replacement lead time only when replacement can reasonably repay itself before deposit expiration

Transport

[x] Route harvested deposit resources back through the existing logistics architecture
[x] Deliver resources to an appropriate owned Storage or Terminal endpoint
[x] Preserve resource type throughout route demand and hauling execution
[x] Avoid adding an energy-only shortcut that would require another rewrite later
[x] Allow harvesting and hauling responsibilities to remain separate when useful
[x] Preserve evacuation of already-harvested cargo after the operation becomes uneconomic

Winding Down

Stopping should be a normal successful lifecycle transition.

[x] Continuously reevaluate whether additional harvesting remains worthwhile
[x] Wind down when cooldown becomes uneconomic
[x] Wind down when remaining lifetime becomes too short
[x] Wind down when expected future yield falls below configurable value thresholds
[x] Wind down when home economy enters emergency conditions
[x] Wind down when defensive risk exceeds accepted policy
[x] Wind down when CPU emergency policy forbids optional external work
[x] Wind down when strategic demand disappears and no acceptable liquidation path remains
[x] Stop committing replacement creeps once the remaining opportunity cannot repay them
[x] Allow already-committed creeps to evacuate useful cargo before retirement
[x] Retire the operation cleanly after the deposit disappears or final cargo returns home

Infrastructure Policy

[x] Do not require permanent roads for the MVP
[x] Reuse existing roads when convenient
[x] Record movement/performance evidence for later evaluation
[x] Do not automatically litter highways with roads for temporary deposit locations
[x] Allow later evidence to justify targeted infrastructure support if economics prove it worthwhile

Observability

[x] Expose expected versus actual deposit yield
[x] Expose harvest cooldown progression
[x] Expose time remaining
[x] Expose spawn investment
[x] Expose transport investment
[x] Expose cargo returned
[x] Expose operation age
[x] Expose winding-down reason
[x] Expose completed-operation outcome
[x] Add bounded operation events and transition reasons for generalized runtime lifecycle changes
[x] Add bounded numeric telemetry for deposit-operation lifecycle states once runtime transitions exist
[x] Add deterministic verification for activation, abandonment, profitable completion, hostile suspension, short lifetime, rising cooldown, and safe cargo evacuation

The first deposit pilot should prove that the colony can deliberately abandon a still-existing resource when continuing to exploit it is no longer worthwhile.

Status: implemented. One exact advisory opportunity may be operator-approved into a home-owned DepositOperationsManager pilot. Admission and replacement use the actual selected self-hauling body, live/CIA facts, economy, essential workforce, CPU, route, risk, lifetime, cooldown, yield, and value evidence. Economic abandonment is a successful winding-down path: replacement and new harvesting stop, useful typed cargo returns to Storage or Terminal, and the operation completes without waiting for the deposit to disappear. Multi-operation allocation remains exclusively 0.4.4 scope.

0.4.4 — Multi-Operation Allocation ✅

Allow a home room to support multiple simultaneous external operations without blindly satisfying every eligible opportunity.

This milestone introduces actual competition for colony capacity.

Potential competing objectives may include:

multiple sources within one remote energy room
energy sources across multiple remote rooms
one or more transient deposit opportunities

Home-Room External Budget

[x] Define bounded operation-level accounting within a home-room external-operations budget
[x] Account for:
expected spawn-time and creep-body energy investment
estimated and active external workforce
estimated and allocated hauling capacity
reserve health
defensive readiness
CPU classification, cadence requirements, and allowance
persistent infrastructure burden
[x] Preserve essential local workforce before external allocations
[x] Preserve emergency recovery authority
[x] Prevent external expansion from consuming the final local logistics capacity needed for colony survival

Operation Ranking

[x] Rank eligible external objectives using comparable bounded value semantics
[x] Include expected resource yield
[x] Include expected strategic or economic value
[x] Include travel cost
[x] Include spawn investment
[x] Include logistics burden
[x] Include infrastructure burden
[x] Include threat and uncertainty
[x] Include opportunity duration
[x] Include existing sunk investment
[x] Include switching cost and hysteresis
[x] Prefer preserving healthy established operations over constantly replacing them with marginally higher-scoring candidates

Allocation

[x] Admit only operations that fit within current home-room budgets
[x] Let operation types compete through shared allocation semantics without sharing execution code
[x] Allow explicit concurrency caps
[x] Allow different caps for persistent and transient operations
[x] Allow one room to host multiple active source objectives
[x] Allow multiple external rooms simultaneously
[x] Allocate remote harvesting workforce deliberately
[x] Allocate hauling capacity deliberately
[x] Allocate reservation burden deliberately
[x] Allocate infrastructure planning pressure deliberately
[x] Prevent one large operation from monopolizing all optional remote investment by accident

Suspension and Preemption

[x] Allow lower-value optional operations to suspend when higher-priority needs emerge
[x] Prefer suspension over destructive reset when conditions are likely temporary
[x] Preserve compact operation state across suspension
[x] Avoid abandoning already-carried resources
[x] Avoid repeated start/stop thrashing
[x] Use explicit hysteresis and cooldowns around admission changes

Observability

[x] Add a home-room external allocation summary
[x] Show budget used versus available
[x] Show ranked candidate operations
[x] Show admitted operations
[x] Show rejected or deferred operations with reasons
[x] Show resource and workforce allocation per operation
[x] Add telemetry for available external budget, allocated budget, candidate count, admitted count, deferred count, and preemptions
[x] Add deterministic verification for competing energy remotes, energy-versus-deposit competition, budget exhaustion, suspension, and hysteresis

This milestone should make multiple operations possible without requiring a colony-wide global optimizer.

Status: implemented. Each owned home room now runs a cadence-bounded, deterministic greedy allocator over independently ranked remote-source and highway-deposit objectives. Spawn energy, workforce, hauling capacity, CPU, infrastructure pressure, and reservation-room support remain separate budget dimensions; minimum requests are admitted atomically, and reservation support is charged once per target room. Local workforce recovery, local hauling, reserve, defense, and CPU authority remain hard gates. Explicit concurrency caps, incumbent bias, decisive-preemption margin, admission cooldown, compact suspension state, debug output, numeric telemetry, and deterministic verification bound the policy without moving execution out of existing managers.

0.4.5 — External Resource Portfolio ✅

Teach the colony to compare different kinds of external economic work rather than optimizing each operation type independently.

The colony should ask:

What external objective is the best use of my next unit of optional capacity?

Persistent energy and transient commodity resources have different properties, but they compete for many of the same scarce inputs.

Portfolio Semantics

[x] Define comparable marginal-value semantics across supported external operation types
[x] Preserve operation-specific scoring internally
[x] Normalize only the dimensions required for bounded ranking
[x] Avoid pretending all resource value can be reduced to one perfectly accurate credit number
[x] Preserve strategic-value overrides where stock or operational demand matters more than immediate Market price

Persistent Energy Value

[x] Account for stable long-term production
[x] Account for route efficiency
[x] Account for reservation cost
[x] Account for maintenance and infrastructure burden
[x] Account for actual measured throughput
[x] Penalize persistently underperforming routes
[x] Recognize sunk infrastructure investment without making bad operations permanent

Deposit Value

[x] Account for transient opportunity lifetime
[x] Account for rising cooldown
[x] Account for expected remaining yield
[x] Account for commodity stock need
[x] Account for executable Market value where appropriate
[x] Account for the absence of long-term reservation and infrastructure obligations

Industry Integration

[x] Allow Industry autonomy to expose bounded resource demand signals
[x] Prefer deposit resources that unlock useful Factory production when strategically valuable
[x] Avoid allowing Factory or Market logic to directly spawn external workers
[x] Preserve operation allocation as the authority deciding whether external acquisition is worth pursuing

Market Integration

[x] Allow immediate executable prices to inform external-resource valuation
[x] Preserve credit reserve controls
[x] Preserve existing bounded-deal authority
[x] Avoid adding speculative trading
[x] Avoid adding permanent price-history storage by default
[x] Avoid assuming gross Market value is the only strategic resource value

Performance Feedback

[x] Compare expected operation value with actual delivered value
[x] Track recurring underperformance
[x] Track repeated logistical overcommitment
[x] Track repeated early abandonment
[x] Track unexpectedly successful opportunities
[x] Allow measured results to adjust later admission policy conservatively
[x] Keep performance memory bounded

Observability

[x] Add an external portfolio debug view
[x] Explain why active operations outrank deferred alternatives
[x] Show estimated and actual resource return
[x] Show marginal capacity usage
[x] Show strategic-demand contribution
[x] Add numeric telemetry for portfolio value, operation-class allocation, external resource yield, and measured efficiency
[x] Add deterministic verification for cross-resource ranking and policy-boundary preservation

This milestone should remain a bounded ranking system rather than a global minimum-cost-flow or universal economic optimizer.

Status: implemented. A cadence-aligned portfolio translator now derives one bounded, explainable rank from native opportunity evidence for persistent remote energy and transient highway deposits. Industry stock/Factory demand, cached executable Market evidence, logistics-route performance, bounded sunk infrastructure continuity, and compact per-resource deposit outcome feedback inform ranking without creating execution authority. The existing per-home allocator remains the sole capacity, admission, hysteresis, preemption, and suspension owner; hard native blockers still allocate zero capacity.

0.4.6 — Broader Remote Autonomy ✅

Use the operational evidence collected throughout 0.4 to allow the colony to start, suspend, wind down, and replace external operations autonomously within explicit policy limits.

This is the culmination of the 0.4 chapter, not the starting point.

Configurable Policy

[x] Define explicit external-operation authority modes
[x] Preserve manual operation control
[x] Allow recommendation-only mode
[x] Allow operator-approved recommendation mode
[x] Allow bounded autonomous admission
[x] Allow independent policy limits for persistent energy and transient deposit operations
[x] Allow configurable concurrency caps
[x] Allow configurable external-investment budgets
[x] Allow configurable minimum opportunity scores
[x] Allow configurable minimum expected deposit return
[x] Allow configurable risk limits

Autonomous Admission

[x] Start new persistent energy objectives when capacity and policy permit
[x] Start deposit operations when expected value exceeds configured thresholds
[x] Prefer already-proven healthy operations when marginal alternatives are close
[x] Avoid starting opportunities that cannot complete useful work before expiration
[x] Avoid speculative overcommitment when intelligence confidence is low

Autonomous Suspension

[x] Suspend operations during economy emergency
[x] Suspend operations during unacceptable defensive conditions
[x] Suspend optional operations during severe CPU-governor restrictions
[x] Preserve safe return-home behavior
[x] Preserve already-harvested resource evacuation
[x] Preserve state necessary for later resumption

Autonomous Retirement

[x] Retire persistent operations that remain uneconomic or unsafe over sustained periods
[x] Retire expired transient operations
[x] Retire deposit operations whose remaining yield no longer justifies continued investment
[x] Remove stale operation memory without destroying useful CIA history
[x] Avoid retaining permanent workforce, route, or infrastructure priority for retired objectives

Replacement and Reallocation

[x] Reevaluate the external opportunity portfolio on a bounded cadence
[x] Admit better opportunities when sufficient capacity becomes available
[x] Avoid unnecessary displacement of healthy existing operations
[x] Reallocate freed hauling and spawn capacity
[x] Allow expired deposit operations to be replaced naturally by newly discovered opportunities
[x] Preserve admission hysteresis so rankings do not cause constant operation churn

Operator Control

[x] Provide explicit inspect, approve, suspend, resume, retire, and authority-mode workflows
[x] Preserve safe manual override
[x] Explain every autonomous start, suspension, resumption, and retirement
[x] Keep reasons bounded and inspectable
[x] Never silently escalate authority beyond configured policy

Verification

[x] Add deterministic lifecycle scenarios across all supported operation types
[x] Verify economy-emergency suppression
[x] Verify defensive suspension
[x] Verify CPU-governor suppression
[x] Verify allocation caps
[x] Verify operation replacement
[x] Verify anti-thrashing hysteresis
[x] Verify transient-operation retirement
[x] Verify persistent-operation recovery and resumption
[x] Verify manual authority always overrides autonomous admission

At completion, external-resource activity should be meaningfully autonomous without becoming uncontrolled.

Status: implemented. Persistent remote energy and transient highway deposits now share explicit manual, recommendation-only, operator-approved, and autonomous admission modes while retaining independent policy. The existing per-home allocator remains authoritative for bounded spawn, workforce, hauling, CPU, infrastructure, reservation, concurrency, hysteresis, and preemption. Minimum rank, confidence, expected-return, and risk limits gate new work. Economy, defense, CPU, and operator suspension preserve operation state and evacuate carried resources; sustained hard failure retires persistent work and the existing deposit lifecycle retires transient work. Exact console controls can approve, suspend, resume, or retire a live objective without bypassing native safety or economic revalidation.

Highway Power-Bank Compatibility

Highway Power Banks are intentionally adjacent to 0.4, but their execution crosses into military capability.

The CIA and external-opportunity framework should be designed so Power Banks can later be represented as transient external opportunities with facts such as:

location
power quantity
hits
decay timer
travel distance
hostile risk
expected hauling requirement
expected economic value

0.4 may eventually observe and score Power Banks.

It should not autonomously attack them.

Power-Bank execution requires force estimation, sustained combat damage, healing, coordinated movement, timing, and post-destruction resource recovery. Those capabilities belong to 0.5 — Military / Defense Doctrine.

This creates an intentional architectural bridge:

0.4 identifies valuable external opportunities
0.5 adds the military capability required to exploit hostile or combat-gated opportunities

Normal Minerals and Expansion

Ordinary room minerals should not be treated as equivalent to remote energy or highway deposits.

A mineral extractor requires ownership and sufficient controller level, so a conventional reserved remote room cannot simply add its mineral to the remote-harvesting operation.

CIA resource surveys should continue recording minerals because they matter strategically.

Mineral type and location may influence:

future room-claim value
industry planning
empire resource diversity
expansion ranking

Actual extraction of additional room minerals naturally belongs to owned-room expansion and later multi-colony development rather than ordinary remote-resource harvesting.

Explicitly Deferred

The following are outside the intended scope of 0.4 unless separately approved:

Power-Bank combat execution
Offensive military operations
Escort squads
Patrols
Raids
Siege
Conquest
General squad movement
Combat boosts
Keeper-room exploitation
Source Keeper combat doctrine
Deposits requiring military clearance
Automatic road destruction or relocation
Permanent highway infrastructure by default
A global minimum-cost-flow optimizer
A universal all-resource logistics solver
A universal Operations super-manager
Unbounded simultaneous external operations
Speculative Market trading
Permanent Market price-history storage
Fully autonomous commodity-chain planning
Cross-shard operations
Power Creep operations
Empire-wide resource allocation across multiple independent colonies

Definition of Done

0.4 is complete when the colony can treat external economic activity as a portfolio of bounded operations rather than a single hard-coded remote-harvesting pilot.

For a persistent remote-energy operation, operator inspection should expose information similar to:

Operation: remote-energy E48N14
Home: E48N13
State: active
Objectives: 2 sources
Value: high
Risk: low

Source A:
  state: active
  expected production: 10 energy/tick
  actual throughput: 9.6 energy/tick
  required carry: 1,020
  assigned carry: 1,100
  infrastructure: fully-supported

Source B:
  state: eligible
  expected production: 10 energy/tick
  actual throughput: 0
  reason: external budget exhausted

For a transient deposit operation, operator inspection should expose information similar to:

Operation: deposit-mist highway:E47N10:21,34
Home: E48N13
State: active
Resource: mist
Remaining lifetime: 18,420 ticks
Current cooldown: 23
Expected remaining yield: 1,480
Returned resource: 620
Spawn investment: 2 creeps
Risk: low
Recommendation: continue

Wind-down threshold:
  cooldown: 74
  projected marginal yield: 132
  replacement permitted: no

For home-room allocation, operator inspection should expose information similar to:

External allocation: E48N13

Budget:
  workforce: 7/9
  hauling: 2,900/3,600 carry
  persistent operations: 2/3
  transient operations: 1/1

Active:
  1. E48N14/source-A       remote energy
  2. E48N14/source-B       remote energy
  3. E47N10/mist-deposit   transient deposit

Deferred:
  4. E49N13/source-A
     reason: insufficient hauling capacity

At completion:

A remote room may support multiple independently valued energy sources.
Multiple external rooms may operate simultaneously when affordable.
Highway deposits are discovered, evaluated, harvested, transported, and retired as transient opportunities.
Persistent and transient external objectives compete for bounded colony resources.
Home rooms explicitly allocate spawn, workforce, logistics, economy, risk, and CPU capacity.
Operations are ranked rather than admitted merely because they are technically possible.
Industry and Market demand can influence external-resource value without taking ownership of external operations.
Defensive readiness can suspend unsafe external activity.
Logistics remains the resource-transport authority.
CIA remains the intelligence authority.
Economy remains the spending authority.
Operator control remains available at every stage.
Broader autonomous admission and retirement occur only inside explicit configured policy.
Power Banks can later fit into the same opportunity model without requiring 0.4 to implement military execution.
The bot can answer not merely "Which remote room should I harvest?" but "What external economic opportunity is the best use of my available capacity right now?"

0.5 — Military / Defense Doctrine

Goal: Build advanced military capability on the survival substrate delivered by 0.3.8.

Combat is not the objective.

Winning is.

0.5.0 — Military / Defense Doctrine

[ ] Richer threat intelligence and bounded combat history
[ ] Civilian evacuation, recovery, and re-entry doctrine
[ ] Escorts and patrols
[ ] Multiple combat roles, compositions, and boosts
[ ] Battle-force estimation and battle plans
[ ] Tactical operations and squad movement
[ ] Remote military operations
[ ] Raids, siege, offensive targeting, economic warfare, and conquest

0.5.1 — Threat Intelligence

Track:

hostile players
usernames
alliances
tower strength
safe mode
combat history

0.5.2 — Defensive Doctrine

Emergency spawning

Tower coordination

Civilian evacuation

Safe mode policy

0.5.3 — Combat Planning

Estimate required force.

Do not spawn combat creeps blindly.

Produce battle plans.

0.5.4 — Tactical Operations

Operations such as:

Raid

Escort

Defense

Siege

Recovery

Patrol

0.5.5 — Economic Warfare

Destroy:

Remote mining

Roads

Haulers

Infrastructure

Rather than simply attacking spawns.

0.5.6 — Room Conquest

Capture enemy rooms.

Claim.

Stabilize.

Integrate.

0.6 — Empire

Goal: Multiple autonomous colonies.

Shared intelligence.

Shared logistics.

Shared economy.

Shared military.

Colonies should cooperate without human direction.

Future Ideas

Power Creeps

Commodities

Factories

Season support

Market automation

Cross-shard intelligence

Machine learning experiments

Predictive economy

Replay analysis

Adaptive spawn planning

Enemy behavior prediction

Diplomacy