Build deterministic capacity planning and infrastructure alternatives workspace

[recklessnode]

Objective

Build the ATOS capacity-planning layer that uses scenario, dispatch, simulation, power, and Issue #15 operations data to identify bottlenecks, measure remaining headroom, and compare advisory fleet or infrastructure changes.

Part of #2. Implementation is gated on Issue #15 being merged.

The Capacity workspace is currently a placeholder. This issue should make it answer:

• What resource is constraining service?
• How much demand growth can the system absorb?
• Which change improves service most?
• What becomes the next bottleneck?

Required work

React-free package

Create packages/capacity for deterministic analysis. Reuse canonical scenario, mission, reservation, event, deficiency, incident, metric, and power types rather than creating parallel models.

Inputs

Consume:

• guideway, stations, platforms, service zones, chargers, maintenance and power resources;
• fleet and module inventory;
• dispatch plans, reservations, unsatisfied chits and deficiencies;
• simulation occupancy, delays, energy, failures and event history;
• Issue Build closed-loop operations, replanning orchestration, and deployment freshness metadata #15 operations generations, incidents, recurring deficiencies and metrics.

Historical inputs remain immutable.

Demand profiles

Support deterministic baseline, passenger peak, cargo surge, growth multiplier, reduced fleet, resource outage, and operator-defined profiles. Record profile ID, seed, horizon and assumptions.

Utilization and headroom

Calculate utilization, queueing, saturation and remaining headroom for:

• guideway links and conflict zones;
• platforms and station dwell;
• loading/unloading, cranes and forklifts;
• charging and maintenance;
• fleet and module classes;
• battery-support assets;
• source and branch power headroom through @atos/power.

Bottleneck attribution

Distinguish fleet shortage, guideway saturation, station dwell limits, cargo handling, charging, maintenance, energy/power, schedule conflicts, and compound bottlenecks. Findings must cite stable resource, mission, chit, deficiency, incident and event IDs.

Advisory alternatives

Generate bounded proposals such as adding or repositioning vehicles/modules, service resources, chargers, maintenance bays, guideway capacity, alternate connections, power injection, conductor capacity or storage.

Capacity analysis must not silently mutate the scenario. Each proposal must state assumptions, expected benefit, tradeoffs and unresolved constraints.

Before/after comparison

Run the same deterministic demand profile against a proposal and compare throughput, completion, lateness, queue delay, deficiencies, utilization, reservation conflicts, replans, energy delays, fleet utilization and the next dominant bottleneck.

Do not invent monetary ROI. Optional user-entered weights may produce clearly labeled relative scores.

Capacity findings

Emit serializable findings with stable IDs, demand profile, planning generation, constrained resource, evidence, limitations, alternatives and status. Recurring Issue #15 deficiencies should link to persistent capacity findings.

Capacity workspace

Replace the placeholder with a mobile-usable workspace showing demand profile, utilization, headroom, ranked bottlenecks, supporting evidence, alternatives and before/after comparison. Highlight affected map entities by stable ID.

Allow a proposal to be sent to the existing layout-editor preview workflow, but require explicit user commit there.

Fixtures and tests

Cover platform-limited passengers, cargo handling, guideway saturation, charger limits, maintenance shortage, fleet shortage, power-constrained launch, and a compound case where the dominant bottleneck changes after an improvement.

Test determinism, serialization, package boundaries, phone-width rendering, map highlighting, proposal preview and no React imports in packages/capacity.

Acceptance criteria

• Implementation begins only after Build closed-loop operations, replanning orchestration, and deployment freshness metadata #15 is merged.
• A React-free packages/capacity exists.
• Canonical scenario, dispatch, simulation, operations and power data are reused.
• Deterministic demand profiles and stress cases are supported.
• Guideway, station, service, charging, maintenance, fleet and power headroom are exposed.
• Bottlenecks are linked to stable resources and affected work.
• Alternatives are advisory and never silently mutate the scenario.
• Before/after comparison identifies both benefit and the next bottleneck.
• Persistent findings link to recurring deficiencies and incidents.
• The Capacity workspace replaces the placeholder and works at phone width.
• Proposal handoff respects the layout-editor preview/commit boundary.
• Identical inputs produce identical findings and rankings.
• Tests, lint, normal build and /ATOS/ Pages build pass.
• Provenance is truthful and complete.

Non-goals

No certified engineering, fabricated construction ROI, global optimization claims, automatic layout mutation, hidden replanning, backend persistence, authentication, multiplayer, physical telemetry or hardware control.

Open a focused PR referencing this issue, #15 and #2. Do not merge automatically.

END CAPACITY ISSUE