Aetheria/docs/locomotion-cut.md

# Locomotion: Control Allocation and Capability-Aware AI

Date: 2026-09-22

Superseded on 2026-10-09 for its body facts, consumer audit and Cuts 2-3 by `docs/aetheria-release-map.md`,
section "Flight control allocates thrust": the aether drive was deleted and `Ship.Turn` replaced `LookDirection`
as the facing command after this was written. Cuts 4 and 5 remain design input only.

Status: target and cut map, from an Imagination pass revised on 2026-09-22. Cut 1 (the Longinus and Djinni hulls,
five thruster designs, and tutorial entrance station rule) landed on `codex/locomotion-cut1` and was merged into
`codex/fire-control-12` at `e160bbe5` on 2026-09-26. Cuts 2 to 5 remain target work. The operator's Q1, Q2,
Q3 and Q5 rulings below still govern that work. **The cuts were renumbered by the 2026-09-22 revision**: the
content restore became Cut 1, and what the first committed version called Cuts 1 to 4 became Cuts 2 to 5.
Historical anchors below are against `origin/codex/item-provenance` at `cd846916`; the then-current working tree
on `codex/fire-control-10` (`e8fbb6a6`) had an identical tree for every file named below. The first half of this
document is the **target** (the ends). The second half is the **cut map** (the means). When the campaign closes,
split the target out as
`docs/locomotion-target.md` and keep this file as history.

Claims marked **(probe)** come from running code: scratch builds of `Aetheria.Shared` from `cd846916` against
CultLib `45c2f40`, run in the session scratchpad. That covers catalog dumps, a legacy-msgpack decode, base-commit
flight measurements and a solver comparison. None of the probe sources are kept. Each result below says what was
run. The base suite passes 244/244 in that scratch copy.

## Rulings

Operator, 2026-09-22:

- **Problem statement.** "We're gonna need much smarter locomotion AI if they're to survive getting a thruster
  shot out. Longinus (non X) had one big thruster in the back and two attitude thrusters in the front. Losing an
  attitude thruster means you can't rotate that way anymore. Losing a thruster on the Djinn usually means some form
  of crab walking just became optimal. Naively trying to use a thruster that's been shot out makes them real easy
  to cheese."
- **R1, two layers.** (1) **Control allocation owns which thrusters fire.** Each live actuator contributes a
  body-frame wrench (Fx, Fy, τ) per unit throttle, with throttle in [0,1]. A bounded least-squares solve finds the
  throttles for the desired wrench (Johansen & Fossen 2013 control-allocation survey). This replaces the rotation
  buckets and the strafe torque compensation. Thrusters that are destroyed, unpowered, disabled or degraded drop
  out of the matrix or scale down in it. (2) **The AI plans with the allocator's achievable set.** For a desired
  Δv it scores candidate headings by achievable acceleration along Δv plus turn time in the directions the ship can
  still rotate. Crab walking and the long way round emerge from that scoring; neither is special-cased.
- **R2, the same-inputs invariant.** "Player and AI are controlling the same ship with the same inputs, this is an
  Aetheria invariant." The player's controls go through the same allocator, through the same input surface the AI
  writes. Any second path that bypasses it is a forbidden writer.
- **R3.** A capability-aware **combat facing/tactics** layer is wanted as its own later cut. Example: a one-way
  turner keeps its target drifting the way it can turn and leans on its turret arcs. This document maps it at
  target-shape level only.
- **R4.** If CultMath lacks a bounded least-squares solver, CultMath gets one, as a CultLib cut. Aetheria does not
  grow a local helper. CultMath has none (probe: `packages/cultmath/src/CultMath` at `45c2f40` holds vector types,
  `math`, `BatchMath`, `Voronoi` and `Random`, with no linear solver of any kind).

Self, relaying an operator answer, 2026-09-22. This is the layer split, stated precisely:

- **Below the inputs**, shared by player and AI, is the ship's own controller plus the allocator. It turns toward
  `LookDirection` and realises `MovementDirection` with whatever actuators are live. **Choosing a feasible turn
  direction belongs here**, including the long way round when one rotation direction is dead. If it lived in the
  AI planner, a player ship with a dead attitude thruster would still stick when looking toward its dead side.
  Holding heading against torque coupling (strafing with an off-centre thruster) also belongs here.
- **Above the inputs**, AI only, is the heading planner. It decides what to write into
  `LookDirection`/`MovementDirection`, for example to turn sideways and crab-walk. The player makes that choice by
  hand.
- The long-way test therefore belongs to the shared-controller cut and drives `LookDirection` directly, as the
  player would. The crab-walk test belongs to the planner cut.

Operator rulings on this map, 2026-09-22, relayed by Self:

- **Q1 = A, the divergence is accepted.** "The divergence is fine." A small divergence from base behaviour on
  intact thruster ships is accepted: the Longinus's forward creep of about 10.7 m/s² while turning in place, and
  the Djinn's roughly 9% faster strafe. Base is pinned exactly only where the old mixer and the allocator agree,
  and the accepted divergences are named with their measured magnitudes in Cut 3's verification, so Soul can tell
  an accepted divergence from a regression. **No per-thruster role rules are reintroduced to match base.**
- **Q2 = B, differential main thrust is allowed.** "That's absolutely viable and can be a better decision than
  turning around the long way, I wouldn't introduce a thruster exclusion for this." Any live actuator's torque may
  be spent on rotation, mains included. A damaged ship turning toward its dead side lurches forward, and the
  planner may prefer that to the long way round when it is faster.
- **Q3, fixtures follow the data.** "Good catch on the Longinus main thrusters, I was misremembering." Two aft 2×2
  mains, as both legacy catalogs author them.
- **Restore the legacy thruster hulls.** Asked whether the lost layouts could come back: "can we restore these
  layouts?" They become Cut 1, the campaign's first cut, ahead of the solver.

Second round, same day:

- **Cut 1 is approved as inventoried, optional gear included.** "Yes and yes": the Longinus and Djinni hulls,
  Medium Drive, and Small Drive, Victoire, Talaria and RevvITup 2.0 as well.
- **The second hull behaviour is not `VelocityConversion`.** "I don't think VelocityConversion was on either
  hull." The decode agrees: it is `VelocityLimitData`. See Cut 1.
- **Q5 is dissolved, not answered: the rotation demand is not sized at all.** "It should only do that if the
  ship's controller also *wants* to accelerate forwards that much, but I'm not sure how to encode that while
  allowing the lurch. Like, lurch burn to compensate for a missing attitude thruster is also only a good move when
  you both need to turn a bit and don't mind being all the way over there after. It doesn't help when, say,
  there's a guy to port and your aft thruster is out, because you'd just end up turning in a great big circle
  without changing your bearing at all." On the shape that replaced it: "Yeah, that's better."
  - **Cut 3** now runs one weighted least-squares solve over the whole desired wrench (Fx, Fy, yaw) at once,
    under throttle bounds. No separate rotation demand, no `TorqueFloor`-sized demand, no piecewise fall-back, and
    no branch anywhere on whether a ship can turn a given way. The weights are the design knob, and both error
    terms share a currency because each axis is normalized by what that ship can actually achieve on it.
  - **Cut 4** chooses manoeuvres by predicted outcome over a short horizon, simulating each candidate, never by a
    rule. The operator's case above is its test.

---

# Part I: Target

## Objective

A ship that loses actuators keeps flying as well as its remaining actuators allow, whether a player or an AI is
flying it. The AI picks headings and thrust directions from what the ship can still do, so shooting out a thruster
creates a real handicap and not an exploit.

## Invariants

1. **Same inputs.** A ship is commanded only through `Ship.MovementDirection` (body frame, each component a
   fraction of the ship's capacity along that half-axis) and `Entity.LookDirection` (world-frame heading command;
   the controller reads only its `xz`). The player writes both (`Gameplay/ActionGameManager.cs:1254`, `:1263`). The
   AI writes the same two fields. Nothing else commands a ship's actuators. Identical inputs to identical ships give
   identical actuator throttles, whoever wrote them.
2. **One owner for actuator commands.** The ship controller (new, `ShipControl`, below) is the only writer of
   `Thruster` and `AetherDrive` throttles. `Ship.cs`'s mixer, its rotation buckets and its strafe compensation stop
   existing, and do not survive as a mode or a fallback.
3. **The allocator reads live actuator state every tick.** An actuator's column is derived each tick from its live
   stats and liveness: `EquippedItem.Active` (enabled, thermally online, durability online), a power grant above the
   same epsilon `Thruster.Execute` uses, and the current resolved `Thrust` (or the drive's own stats) with its
   durability, heat and power curves applied. No bucket, cache or event-pruned set decides whether an actuator
   counts. A repaired or re-powered actuator rejoins by the same read that dropped it.
4. **Manual and programmatic inputs share one commit path.** A player keypress, an AI state write, and any future
   scripted or network input all land in the same two fields, and they reach the actuators by the same
   `ShipControl` step inside `Ship.Update`. No input source writes `Thruster.Axis`, `AetherDrive.Axis` or
   `Entity.Direction` directly.
5. **Heading changes only through actuators.** `Entity.Direction` is written by actuator execution
   (`Thruster.Execute`, `AetherDrive.Execute`), by wormhole scripting (`Ship.ExitWormhole`), by spawn placement
   (`ActionGameManager.cs:848`) and by save unpack (`EntitySerializer.cs:66`). The controller does not write it.
   Today's snap-to-look lerp (`Ship.cs:280-284`) is a free, thrusterless rotation, and it goes.
6. **Kinematic rotation is retained.** Rotation stays kinematic: yaw rate is proportional to live throttle
   (`Thruster.cs:106-107`, `AetherDrive.cs:154-155`), with no angular momentum. Nothing found here argues for
   raising it. It keeps turn time exact (angle divided by rate), which is what lets the planner compare a long
   way round against a slow lurching turn without simulating either.
7. **A dead actuator never receives throttle.** A destroyed, disabled or unpowered actuator gets zero throttle,
   not a saturated request it cannot honour.
8. **Capability is one model.** What a ship can do is computed in one place (`ShipControl`), from the same live
   column matrix the allocator solves with: the achievable extremes, the turn-direction comparison, and the solve
   itself. The AI reads those and predicts with the controller's own step; it never keeps a private estimate of
   what the ship can do, and never branches on which actuators are missing.

## Canonical implementations

- **Solver:** CultMath (`F:\Projects\CultLib\packages\cultmath`), a box-constrained linear least-squares solver,
  added by Cut 2. It is the only numerical authority. Aetheria composes the problem and calls it.
- **Allocation reference:** T. A. Johansen and T. I. Fossen, "Control allocation: A survey," *Automatica* 49(5),
  2013. Its weighted-least-squares form with priorities is what `ShipControl` states. The active-set method follows
  O. Härkegård, "Efficient active set algorithms for solving constrained least squares problems in aircraft control
  allocation," CDC 2002, which is bounded-variable least squares in Stark and Parker's sense.

## Out of scope

- **Fire-control Cut 12** (edge-on hit placement in `FireControl.cs`, `Entity.ApplyHit`, `DamageSchematic`) is
  being mapped concurrently by another Imagination pass. Cuts 2 to 4 here touch none of those files. The allocator
  is a read-only downstream consumer of item destruction (`ItemDamage`, `Entity.cs:488`). **Overlap:** Cut 5 (combat
  facing) will rewrite `Agents/States/Combat.cs:88-127`, and presenting armour edge-on is exactly what Cut 12's hit
  placement rewards. Cut 5 must be mapped after Cut 12 lands. Cut 1 restores catalog content, and the only file it
  and Cut 12 could both touch is `GameData/Aetheria.cc`; Cut 1 must not be in flight while another cut writes the
  catalog.
- **The old AetheriaEve/CultMesh/daemon rebuild** is taxidermy. It is not precedent and not a consumer.
- Thruster geometry (the normalized moment-arm `Thruster.Torque`, `Thruster.cs:64-69`, which ignores lever length
  and uses unweighted shape cells for centre of mass) is the game's model and stays as authored. Arrival braking in
  `MoveToState`, docking approach and formation flight are also out.

## Not consumers

- `Assets/Scripts/Gameplay/*` presentation (`ShipInstance` particles, audio parameters) reads throttles and never
  writes them.
- `TurretController` writes `Entity.LookDirection` for turret entities. That is the AI above the inputs for a
  non-ship, and it does not drive ship actuators. See the audit.

## 0b: identity, lifecycle, authority

Nothing persistent changes. Actuator wrench columns, capacities, the chosen turn direction and planner state are
runtime-derived per tick, or per planner cadence, and are never saved.

| Kind | Named by | Lifecycle | Decides |
|---|---|---|---|
| Actuator column (runtime) | the `Thruster`/`AetherDrive` behaviour instance on an `EquippedItem` | rebuilt every tick from live stats; appears and disappears with liveness | `ShipControl` derives; item state (durability, heat, power, `Enabled`) is owned by `EquippedItem`/`PowerBus` as today |
| `MovementDirection`, `LookDirection` (runtime) | fields on `Ship`/`Entity` | overwritten each frame by whoever flies the ship | player (`ActionGameManager`) or AI (`Agent` layer), never both on one ship (`Zone.cs:111` gives agents only to `!IsPlayerShip`) |
| Committed turn direction, planner plan (runtime) | fields on `ShipControl` / `Agent` | reset on wormhole, dock, spawn | `ShipControl` / `Agent` |
| `ThrusterData`, `AetherDriveData`, `HullData.Hardpoints/Shape` (persisted, catalog) | catalog record key | authored | unchanged; read only |
| `GameplaySettings.TorqueMultiplier`, `AetherTorqueMultiplier` (authored, `Settings.cs:206-207`; values in `Assets/Resources/Settings.asset`: 0.1, 0.1) | field name | authored | unchanged. `TorqueFloor` (`:205`, authored 0.5) loses its last consumer in Cut 3 and is deleted with its authored value |

This campaign adds no authored **field**. Cut 1 adds authored **records** (hulls, thruster designs and their
products) to `GameData/Aetheria.cc` using the schema as it stands. If Hands finds it needs a tunable, that is an
operator question, and any new field on a persisted CultCache document must be nullable (MessagePack nil rule).

---

# Part II: Body map (what the probes established)

## The mixer today

`Ship.Update` (`Ship.cs:251-292`) runs before `base.Update` executes behaviours. The agents' writes come earlier
still, because `Zone.cs:170-173` updates agents before entities. The steps:

1. `RecalculateThrust` (`Ship.cs:147-247`) sums per-bucket thrust over thrusters whose item is `Active`.
2. It zeroes every thruster's `Axis` (`:256`).
3. Strafe: the right and left buckets get `±MovementDirection.x`, minus a torque compensation for the thrusters
   whose torque sign matches the bucket total (`:257-274`).
4. Forward and reverse buckets add `±MovementDirection.y` (`:275-276`).
5. Rotation: `deltaRot = sqrt(|dot(look, right)|)·sign` (`:278-285`) is added to the clockwise bucket and subtracted
   from the counter-clockwise bucket (`:287-288`).
6. `AetherDrive.Axis = (MovementDirection.y, MovementDirection.x, deltaRot)` (`:291`). There is no allocation for
   drives at all.

Buckets are built once in `Activate` from mount rotation and from `Thruster.Torque` against
`TorqueFloor` (`:102-118`). `RemoveThruster` prunes them permanently on `ItemDestroyed` (`:123`, `:133-143`).

`Thruster.Axis` saturates to [0,1] (`Thruster.cs:45-49`). `Execute` (`:94-115`) applies `Velocity -= facing·input·
Thrust/Mass·dt`, then rotates `Direction` kinematically by `input·Torque·Thrust·TorqueMultiplier/Mass·dt`. Its gate
is `input > .01 && PowerSupply > 1e-4`.

## Findings (probe)

Fixtures here are built from the legacy catalog (next section): hull shape, hardpoints, thruster items with
constant `Thrust` (Large Drive 250000, Medium Drive 200000; mass 100 each), `TorqueFloor` 0.5, `TorqueMultiplier`
0.1. Each ship sits at (37, −12) facing `normalize(0.8, 0.6)`, runs 3 warm-up ticks, is reset, and is measured over
one tick at dt 0.02. Body-frame acceleration is (r, f) in m/s². Heading rate is compass degrees per second,
clockwise positive.

**Torque factors** (`Thruster.Torque`, the sine of the moment arm): Longinus mains ±0.159 (below the floor, so
never used for rotation), attitude thrusters ±0.998. Djinni stern 0 / ±0.161, laterals ±0.727 (aft) and ±0.867
(fore), bow 0.

**Base flight table** (`cd846916`, after warm-up). These are the Cut 3 pins:

| Input | Longinus (r, f, °/s) | Djinni (r, f, °/s) |
|---|---|---|
| forward `(0,1)` | 2.37, 172.38, 0 | 0.11, 55.56, 0 |
| reverse `(0,−1)` | 0, 0, 0 | 0, −18.52, 0 |
| strafe right `(1,0)` | 0, 0, 0 (compensation zeroes the lone attitude thruster) | 34.03, 0.42, 0 (axes 1.00 / 0.84) |
| strafe left `(−1,0)` | 0, 0, 0 | −34.03, 0.42, 0 |
| look 90° right | 68.97, 0, +394.33 | 0.01, 0.59, +169.13 |
| look 90° left | −68.97, 0, −394.33 | 0.01, −0.50, −169.13 |
| look 30° right | 48.77, 0, +278.84 | 0, 0.30, +119.59 |
| look directly behind | 0, 0, 0, **and `|Direction|` falls to 0.96** | same |
| forward+strafe `(.707,.707)` | 1.18, 121.89, 0 | 24.12, 39.49, 0 |

The small cross terms (2.37, 0.42) are real. `Execute` rotates `Direction` thruster by thruster within one tick, so
later thrusters push along an already-rotated nose. The allocator cannot see this, so pins need a tolerance for it.

**Defects the table exposes:**

- **Dead-side stick.** On a Longinus with `Th.CCW` destroyed, looking 90° left gives a heading error of 90.0°
  after 30 s. It never turns. Looking right, it reaches within 2° in 0.32 s, the same as intact.
- **Main-thruster cheese.** On a Djinni with all three stern thrusters destroyed, `Agent` plus `MoveToState` toward
  a point 300 m to port leaves the ship at speed 0 after 120 s. `Agent.Accelerate` points at Δv and burns forward
  thrusters only (`Agent.cs:64-68`), and it never reaches the strafe branch. Intact, the same run arrives in
  4.34 s. With only Stern 2 lost it arrives in 4.98 s; with only Port Aft lost, 4.40 s.
- **Snap-to-look.** Inside `|sin error| < .01`, `Ship.cs:283` lerps `Direction` toward the look vector, which is a
  rotation no thruster pays for. When the look is directly behind, the lerp goes through the origin and shrinks
  `|Direction|`, and thruster force scales with that length (`Thruster.cs:105` uses the unnormalized item
  direction). Base also turns *slower* as error passes 90°: `deltaRot` follows `sin`, so it is zero at 180°.
- **First tick.** Items are not yet `Active` on the first `Update` after `Activate`, so the first-tick strafe
  compensation divides by a zero count (NaN, unused) and the strafe fires uncompensated.
- **`TurnTime` is wrong and unused.** `Ship.cs:61-66` divides angle by the sum of torque *factors* over mass, which
  is unitless nonsense: 261535 s for a Longinus 90° turn. It has no consumer.
- **Permanent pruning.** `RemoveThruster` never restores a thruster whose durability comes back, and `Recalculate*`
  reads `Active` while the mixer still commands inactive thrusters.
- **The live catalog's only ship flies on a drive.** `GameData/Aetheria.cc` holds one ship hull, **LonginusX**
  (mass 2500, drag 0.1, 6×17), with an `AetherDrive` hardpoint and **no `Thruster` hardpoint**. It moves on
  "Traction" (rotor mass (30,20,5), λ (0.5,1,1), MaxRpm 40000..80000). Two thruster designs exist ("deep space
  burnout", "Large Drive"), but no live ship can mount them (`docs/content-batch-one.md` §1 says the same).
  **AetherDrive is therefore the load-bearing actuator for the player today**, and the allocator must reproduce its
  base behaviour exactly. Cut 1 restores the thruster hulls, which is what makes any play check on a thruster ship
  possible at all.
- **Existing tests sit on an off-centre thruster.** `BrownoutTests`/`ConditionRatioTests` equip a one-cell thruster
  by `TryFindSpace` onto a 5×5 hull. It lands at (1,1) with `Torque` −0.707, and `MovementDirection (0,−1)` fires it
  while it spins the ship. Under an allocator that holds heading, a lone off-centre thruster cannot fire without
  rotating, so those fixtures must be re-seated (Cut 3).

## Legacy hull layouts (probe)

The live catalog is the post-breach minimal rebuild, so absence there proves nothing. The layouts come from the
git-LFS objects of `GameData/Legacy/AetherDB.2021-03-05.msgpack` (`142998fd…`) and `AetherDB.2021-04-14.msgpack`
(`21ce7bd2…`), both present in `.git/lfs/objects`, decoded with MessagePack `ConvertToJson`. Shape cells are
`bool[w,h]`, flattened as `x*h + y`, with y = 0 at the stern.

**Longinus** (2021-04-14: mass 2500, drag 0.1, 6×17; the 2021-03-05 copy has mass 5000). The shape matches the
live LonginusX's. Rows from y = 0: `.####.` ×4, `######` ×5, `.####.` ×2, `..##..` ×6.

| Hardpoint | Pos | Shape | Rotation |
|---|---|---|---|
| Th.L | (1,0) | 2×2 | Reversed (pushes forward) |
| Th.R | (3,0) | 2×2 | Reversed |
| Th.CW | (2,14) | 1×2 | CounterClockwise (pushes starboard, nose right) |
| Th.CCW | (3,14) | 1×2 | Clockwise (pushes port, nose left) |

**The data has two aft 2×2 thrusters, not one.** The operator remembered "one big thruster" and ruled on it,
2026-09-22: "Good catch on the Longinus main thrusters, I was misremembering." Fixtures follow the data.

**Djinni** (mass 10000, drag 0.2, 14×17). Rows from y = 0: `....######....`, `...########...`,
`..##########..`, `.############.` ×2, `##############` ×5, `.############.`, `...########...` ×3,
`....######....`, `.....####.....`, `......##......`.

| Hardpoint | Pos | Shape | Rotation |
|---|---|---|---|
| Stern 1 | (6,0) | 2×1 | Reversed |
| Stern 2 | (5,1) | 2×1 | Reversed |
| Stern 3 | (7,1) | 2×1 | Reversed |
| Port Aft | (4,4) | 1×2 | CounterClockwise |
| Port Fore | (4,11) | 1×2 | CounterClockwise |
| Starboard Aft | (9,4) | 1×2 | Clockwise |
| Starboard Fore | (9,11) | 1×2 | Clockwise |
| Bow | (6,14) | 2×1 | None (pushes aft) |

Legacy thruster items used for the fixtures: Large Drive 2×2, 250000 thrust, mass 100. Medium Drive 2×1, thrust
100000..300000 (fixtures use a constant 200000), mass 100. Small Drive 1×1, 75000.

## Solver choice (probe)

The comparison ran on the fixtures' own normalized columns, plus a 16-column doubled Djinni: 2000 random wrench
demands each, cost measured against a 20000-iteration projected-gradient reference, double precision,
allocation-heavy scratch C#, Release build.

| Method | Worst excess cost | Suboptimal cases | Mean time |
|---|---|---|---|
| Primal active set (bounded-variable LS, Härkegård WLS form) | ≤ 7e-15 | 0 in every case | 1.8–9.5 µs (n 3–8), 32–38 µs (n 15–16); ≤ 30 iterations cold |
| Redistributed pseudo-inverse | up to 4e3 | 270–1564 of 2000 (n ≤ 8) | about half the active set's time |

**Pick the active set.** It is exact, its cold-start cost is bounded, and it warm-starts from last tick's solution.
The redistributed pseudo-inverse saves about half the time and is wrong in up to 78% of cases on these very
matrices. A production float implementation without allocations will be faster than the scratch numbers.

## Consumer audit

`cd846916`, every `*.cs` outside `Assets/Plugins`. "Dies" means deleted, not deprecated.

| Surface | Readers / writers | Fate |
|---|---|---|
| `Ship.MovementDirection` (`Ship.cs:27`) | W: `ActionGameManager.cs:1263` (player), `Agent.cs:67,73,77` (AI); tests `BrownoutTests.cs:143,402`, `ConditionRatioTests.cs:184,193,243,258`. R: `Ship.cs:261-291` | **Survives** as the translation input. Its meaning is defined by `ShipControl` (fraction of capacity per half-axis) |
| `Entity.LookDirection` (`Entity.cs:55`) | W: `ActionGameManager.cs:1254` (player), `Agent.cs:66`, `MoveTo.cs:26`, `Combat.cs:126`, `TurretController.cs:72,75` (turret entities; no `EntityTypeRestriction`, `TurretController.cs:14-15`). R (as heading): `Ship.cs:278`. R (as aim): `LockWeapon.cs:94`, `GuidedProjectileManager.cs:56`, `EntityInstance.cs:404`, `ShipInstance.cs:117` (tractor), `ZoneRenderer.cs:432`, `ActionGameManager.cs:376` (reticle target pick) | **Survives** as heading command *and* aim. `MoveTo.cs:26` dies in Cut 4 (a double writer: `Accelerate` overwrites it when Δv > 20). The heading/aim conflation is Cut 5's question (Q4) |
| `Thruster.Axis` (`Thruster.cs:45-49`) | W: `Ship.cs:256-288` only. R: `ShipInstance.cs:139` (particles), `Thruster.cs:88` (power request), `:96` (audio), `:102-111` | Getter **survives**. The public setter **dies**; only `ShipControl` commands throttle |
| `AetherDrive.Axis` (`AetherDrive.cs:81-85`) | W: `Ship.cs:291` only. R: drive internals, audio `:170` | Same as `Thruster.Axis` |
| `IAnalogBehavior` (`Behaviors.cs:96-99`) | implemented by `Thruster.cs:40`; consumer only a comment, `Entity.cs:2007` | **Dies** (Cut 3 deletes first) |
| Bucket sets `_forward/_reverse/_right/_left/_clockwise/_counterClockwiseThrusters`, `_thrusterItems`, `_aetherDrives`, `_aetherDriveItems` (`Ship.cs:30-39`) | `Ship.cs` only | **Die** |
| `ForwardThrust`, `ReverseThrust`, `LeftStrafeThrust`, `RightStrafeThrust`, `ClockwiseTorque`, `CounterClockwiseTorque`, `Left/RightStrafeTotalTorque`, `Left/RightStrafeTorqueThrusters` (`Ship.cs:50-59`) | written by `RecalculateThrust`, read by the mixer; **no reader outside `Ship.cs`** (grep, including Unity side and tests) | **Die** |
| `Ship.TurnTime` (`Ship.cs:61-66`) | no consumer | **Dies**; replaced by `ShipControl.TurnTime` (Cut 3), consumed in Cut 4 |
| `RemoveThruster`, `RemoveAetherDrive`, their `ItemDestroyed` subscriptions (`Ship.cs:123-143`) | internal | **Die**; liveness is read live (invariant 3) |
| `Agent.Accelerate` (`Agent.cs:58-79`), `FORWARD_DELTA_THRESHOLD`/`THRUST_DELTA_THRESHOLD` (`:16-17`) | called by `MoveTo.cs:27`, `Combat.cs:127` | **Rewritten** in Cut 4 (planner). Signature kept |
| `Agent.TopSpeed` (`Agent.cs:26`) | `MoveTo.cs:25`, `Combat.cs:127`. No live catalog item carries `VelocityLimit` or `VelocityConversion` (probe), so it is 100 everywhere | Survives |
| `GameplaySettings.TorqueFloor` (`Settings.cs:205`) | `Ship.cs:115,118` only | **Dies** in Cut 3. The full-wrench solve has no threshold to apply it to, and nothing else reads it |
| `TorqueMultiplier`, `AetherTorqueMultiplier` | `Thruster.cs:107`, `AetherDrive.cs:155` | Survive; also enter the yaw-rate row of each column |
| `Entity.Direction` writers | `Thruster.cs:106`, `AetherDrive.cs:154`, `Ship.cs:79` (wormhole), `Ship.cs:283` (snap), `ActionGameManager.cs:848` (spawn), `EntitySerializer.cs:66` | `Ship.cs:283` **dies** (invariant 5); the others survive |
| `Entity.Velocity` external writers | `HullCollider.cs:15` (collision impulse), `ShieldManager.cs:79` (bounce), `VelocityConversion.cs:41`, `VelocityLimit.cs:48` | Not control; these are external forces and constraints. Untouched |
| Undock capability check (`ActionGameManager.cs:913`) | `GetBehavior<Thruster/AetherDrive>() == null` | Survives. It could later read the capability model; not this campaign |
| Mining, Survey, HaulingTask, StationTowing (`Agents/Tasks/*.cs`) | data-only task classes; no movement code (grep) | Not consumers. `PatrolOrbitsState` drives `MoveToOrbitState`, which Cut 4 covers |
| Player input path | `Input.Player.Look` → `_entityYawPitch` → `LookDirection` (`:1250-1254`); `Input.Player.Move` → `MovementDirection` (`:1261-1264`). No other action writes motion (grep of `Input.Player.*`: targeting, heat, shield, stance, tractor, ping, UI) | **Already on the shared surface**. The only bypasses are the ones `Ship.cs` itself holds (the snap, direct `Axis` writes), and both die in Cut 3 |

Out-of-scope note: the working tree has an uncommitted change to `Assets/Scripts/AetheriaInput.cs` (a "Cycle Target
Item" action). That is fire-control work, and it does not touch motion.

---

# Part III: Cut map

## Status header

Status: cut map. Ends are owned by Part I above; this section owns the means.

Cut 1 landed and is merged into `codex/fire-control-12` at `e160bbe5`. Cuts 2 to 5 have not landed.

Rulings (operator, 2026-09-22): **Q1 A** ("The divergence is fine"), **Q2 B** ("that's absolutely viable and can
be a better decision than turning around the long way, I wouldn't introduce a thruster exclusion for this"), **Q3**
fixtures follow the data ("Good catch on the Longinus main thrusters, I was misremembering"), and Cut 1 exists
because of "can we restore these layouts?". The Q2 text below is marked as history; the live design is in Cut 3.

Second-round rulings (operator, 2026-09-22): Cut 1 approved as inventoried, optional gear included ("Yes and
yes"); the second hull behaviour is not `VelocityConversion` ("I don't think VelocityConversion was on either
hull") and the decode names it `VelocityLimitData`; **Q5 is dissolved** by the full-wrench solve ("Yeah, that's
better"), so the Q5 text below and every "sized demand" design it belonged to are history.

Open: **Q4** (heading versus aim) blocks only Cut 5. **Q6** (the one weight in Cut 3's solve) does not block
Hands, who starts at the recommended default; the operator settles it by feel in the Cut 1 play check.

**Tutorial station (operator, 2026-09-25):** "What we're testing is going to be the tutorial level, right? Let's drop a station in there." The live catalog already has a station hull: Zenith, sold by Aeronautics Unlimited. The story-station path is dead because `StoryProcessor` has been commented out at `Galaxy.cs:242` since `ce1a0a46` (2021). Ruled: **faction station now**. The tutorial's entrance zone (`Galaxy.Entrance`) always gets a generated faction station with a docking bay. That is deterministic, not merely likely, and the test pins it on the real tutorial construction path. Reviving the Ink story stations belongs to a later narrative campaign, which must first find out why they were switched off.

Legacy hazard, recorded 2026-09-26 (Soul, Cut 1 fix batch 2): `VelocityLimit` is a hull behaviour gated by the hull's `Active` (`Entity.cs:1624`, `:1636`, `VelocityLimit.cs:45-49`). Thrusters are items with their own gating. Any path that takes the hull offline while the thrusters keep firing removes the cap. Under frozen fixture physics, with the player's override on the thrusters, speed reached 1237. On the shipped settings the hull did not go offline in 300 s. The behaviour dates from 2020-04 and 2021-03. Cut 3 and Cut 4 measure arrival times under this cap, so they must not assume it always holds.

Follow-ups outside this campaign:
- `TurretController` has no `EntityTypeRestriction`, so equipping it on a ship would create a third
  `LookDirection` writer racing the player or agent. Restrict it to non-ship hulls when turret work next opens
  (`TurretController.cs:14`).
- `Thruster.Execute` applies rotation per thruster inside the tick, which couples later thrusters' force to earlier
  thrusters' rotation. It is a small artefact, and it is `Thruster.cs`'s to fix, not the allocator's.
- `AetherDrive.Execute` logs "FUCK FUCK FUCK FUCK" on NaN velocity (`AetherDrive.cs:157-158`), a leftover probe.

## Cut 1. Restore the legacy thruster ship hulls to the live catalog

A pure content cut, separable from every code cut, so Soul can falsify it on its own. Operator, 2026-09-22: "can
we restore these layouts?", and on the inventory below, optional gear included: "Yes and yes". **The list is
approved**; what is left for review is anything Hands finds that this map did not name.

- **Repo/branch:** Aetheria, implemented on `codex/locomotion-cut1` and merged into `codex/fire-control-12` at
  `e160bbe5`. The restored hulls are now the real fixtures for Cuts 3 and 4. The catalog mutation is complete.
- **Standing rule** (memory: `aetheria-content-audits-pre-breach`): `GameData/Aetheria.cc` is the post-breach
  bare-minimum rebuild, so absence there is not evidence of absence, and **the operator's word is the authority**
  on what the pre-breach content was. The list below is therefore an **operator review item before Hands writes
  anything into the catalog**.

### What the legacy record actually holds (probe)

Sources, all decoded in the scratchpad: the git-LFS objects behind `GameData/Legacy/AetherDB.2021-04-14.msgpack`
(`21ce7bd2…`, 76 KB) and `AetherDB.2021-03-05.msgpack` (`142998fd…`, 59 KB), and the last
`GameData/AetherDB.msgpack` before the Cut 9 import (`8963a686…`, 46 KB, the commit's own parent at `70fbaca1^`).
All three are present in `.git/lfs/objects`; nothing had to be fetched.

The comparison explains the loss. The 2021-04-14 record carries 5 ship-class hulls and 45 gear designs. The import
source carries 3 hulls (LonginusX, Zenith, Turret) and 25 gear. **Longinus, Djinni and every thruster below the
2×2 class were already gone from the file Cut 9 imported**, which is why the live catalog has no thruster ship.

**Recoverable in full from 2021-04-14** (name, shape, mass, price, hardpoint list with position, shape, rotation
and armour, behaviours, temperature band, manufacturer, prefab and schematic paths):

| Record | Kind | Legacy detail | Notes |
|---|---|---|---|
| **Longinus** | ship hull | 6×17, mass 2500, drag 0.1, price 7,500,000, maker Alakrita | The shape is byte-identical to the live LonginusX's. 4 thruster hardpoints (`Th.L`/`Th.R` 2×2 aft, `Th.CW`/`Th.CCW` 1×2 in the nose) plus control module, 2 energy, 2 launcher, 2 radiator, reactor, sensors |
| **Djinni** | ship hull | 14×17, mass 10000, drag 0.2, price 10,000,000, maker Rossum & Douglas | 8 thruster hardpoints (3 stern, 4 lateral, 1 bow) plus 4 launcher, 2 ballistic, reactor, control module, 4 radiator, sensors, and a shield hardpoint |
| **Medium Drive** | thruster gear | 2×1, mass 100, thrust 100000..300000, price 50,000, no maker | **The one item both restored hulls need.** Fits the 2×1 stern/bow hardpoints and, rotated, the 1×2 lateral and nose ones |
| **Small Drive** | thruster gear | 1×1, mass 50, thrust 75000, price 25,000, no maker | Optional; the cheap end of the line |
| **Victoire** | thruster gear | 2×1, mass 25, thrust 200000..1500000, maker Alakrita | Optional; the racing thruster, and a natural Longinus fit |
| **Talaria** | thruster gear | 2×1, mass 150, thrust 75000..250000, maker Aeronautics Unlimited | Optional |
| **RevvITup 2.0** | thruster gear | 2×2, mass 150, thrust 250000..1000000, maker NiteLife Energy | Optional; a second 2×2 beside the two the catalog already ships |

Everything those records depend on is **already in the live catalog**: all 12 factions (Alakrita and Rossum &
Douglas included), both existing 2×2 thrusters, and the Unity presentation. The prefabs still carry the hardpoint
transforms by their legacy names — `Th.L`, `Th.R`, `Th.CW`, `Th.CCW` in `Assets/Content/Prefabs/Ships/
Longinus.prefab` (GUID `4a3db609…`, already the hull the live LonginusX points at) and `Thruster Stern 1..3`,
`Thruster Port/Starboard Fore/Aft` and `Thruster Bow` in `Djinni.prefab` (GUID `79024f63…`). The schematics exist
too (`schema_Longinus.png` `51702555…`, already referenced; `djinni_schematic_transparent.png` `66f3acdd…`, unused
today). So no art, no prefab work and no faction work is needed.

**Not recoverable, because it post-dates the breach and has to be authored:**

- `HardpointData.FiringArc` (Key 6) for the Djinni's weapon hardpoints. The legacy hardpoint record stops at
  armour. 0 means "use `GameplaySettings.FiringArc`"; the `firing-arc-migrate` command in `tools/AetherDb` is the
  precedent for deriving one from mount rotation.
- `ItemRole` lists on the restored designs, and `ProductRole` qualities on their products.
  `RoleAuthoringTests` refuses a stat naming a role its design lacks, and `docs/content-batch-one.md` fixes the
  nomenclature (`injector`/`nozzle` for thrusters, `plating` for hulls). The live "deep space burnout" carries
  `injector, nozzle`; "Large Drive" carries none.
- A `FactionProductData` per restored design. `LoadoutGenerator` picks products, not designs, so a design without
  one exists but is never generated or sold. The catalog holds 47 products today.
- Any `PowerSupply` term on the restored thrusters' stats (the stats-and-power cut's brownout curve). The shipped
  thrusters request zero energy, so matching them is the safe default and is a content decision.
- Provenance is runtime, not authored: `ItemManager` mints the `Lot` (`docs/item-provenance-target.md`).

**The second hull behaviour, identified** (probe; the operator was right that it is not `VelocityConversion`).
Both legacy hulls carry a behaviour LonginusX does not, union tag 11 in the legacy record. The union table is in
`Assets/Scripts/ServerShared/Behaviors/Behaviors.cs` at the legacy-project commit `7006a6b0` and unchanged at
`b4c06b50`: **tag 11 is `VelocityLimitData`**; `VelocityConversionData` is tag 10, and it is on neither hull. The
table cross-checks against the live catalog on every record that survived: tag 6 `ReflectorData` (live LonginusX
has exactly that and nothing else), 8 `ThrusterData` and 9 `WearData` ("deep space burnout" carries both), 3
`RadiatorData` (Arctica), 7 `ShieldData` (legacy "Shield"), 31 `CapacitorData` (legacy "Capacitor").

The payload is a single `PerformanceStat` in `Key(1)`, `VelocityLimitData.TopSpeed`, authored `50..50` with the
legacy exponents `1, 0, 1.5` on both hulls. (Corrected 2026-09-26: the decode behind the restore gives Longinus
`100..100` with exponents `1, 0, 0` and Djinni `50..50` with `1, 0, 1.5`. The catalog carries those values.) So **both restored hulls are capped**, where a hull
without the behaviour leaves `Agent.TopSpeed` at its 100 default (`Agent.cs:26`) and leaves the player uncapped.
`VelocityLimit.Execute` clamps `Entity.Velocity` (`VelocityLimit.cs:48`), so this is a real handling difference on
the restored hulls and Cut 4's arrival times are measured with it.

**The legacy stat shape differs from today's.** A legacy `PerformanceStat` is
`[Min, Max, HeatExponentMultiplier, DurabilityExponentMultiplier, QualityExponent]`; today it is `Min`, `Max` and
a `Terms` list of `StatTerm` (`ItemData.cs:632-643`, keys 2 to 4 retired). Every restored stat has to be
translated, not copied. `docs/stats-power-cut1-migration.md` is the precedent for that mapping and the authority
on what each legacy exponent becomes.

### The cut

- **Deletes first:** nothing. This is content restoration.
- **Adds:** the two hull records and all five thruster designs (`Medium Drive`, `Small Drive`, `Victoire`,
  `Talaria`, `RevvITup 2.0`), approved 2026-09-22; a `FactionProductData` for each; roles for each; firing arcs on
  the Djinni's weapon hardpoints; each hull's `VelocityLimit` behaviour with its translated stat.
- **Mechanism:** a one-shot command in `tools/AetherDb` (`restore-hulls [apply]`), in the shape of the existing
  `*-migrate [apply]` commands: dry run by default, opens the catalog through `AetheriaStores.Open(catalogWritable:
  true)` only when applying, writes every record in one `Commit`, and refuses to run twice. The Cut 9 importer
  (`tools/AetherDb/Import.cs`, added in `70fbaca1` and deleted by Cut 10) is the precedent for reading the legacy
  `[tag, payload]` records and rewriting them by the target type's `[Key]` shape; read it out of git history rather
  than re-deriving the mapping. **Delete the command in the same campaign, as Cut 10 deleted the importer**, so the
  carrying cost of the restore is zero once it has run.
- **Authority map:**
  - Owner: the catalog (`GameData/Aetheria.cc`) owns authored content; the operator owns what the content *is*.
  - Inputs: the legacy LFS records, the existing factions and assets, the operator's review of the list above.
  - Outputs: new `HullData`, `GearData` and `FactionProductData` records.
  - Derived state: none. Runtime `Lot`s and provenance are minted as for any other design.
  - Forbidden writers: nothing else may write the catalog while this cut is in flight; the one-shot command must
    refuse a second apply rather than upsert twice.
  - Deletion line: the command goes once the records are in.
- **Verification:**
  - `FireControlCut7Tests.ShippedCatalogOpensAndGeneratesAnArmedHull` still passes unchanged: the real catalog
    opens, every `EquippableItemData` deserializes, and LonginusX still generates an armed loadout.
  - New `RestoredHullsTests` against the real catalog, read-only: each restored hull exists, has the expected
    thruster hardpoint count (Longinus 4, Djinni 8), every thruster hardpoint accepts a catalog thruster design
    through `TryEquip` at that hardpoint's own position, and the ship then moves and turns under
    `MovementDirection`/`LookDirection` for a few ticks. Before Cut 3 this runs on the old mixer, which is the
    point: it proves the content, not the controller.
  - `LoadoutGenerator` generates each restored hull when filtered to it, which is the check that the products and
    roles are authored correctly.
  - `dotnet run --project tools/AetherDb -- census` names the two hulls with their makers, and `dangling` reports
    no new dangling reference.
  - Operator: the Studio click-through, then a play check flying a restored hull. That play check is what
    unblocks the rest of this campaign, and it is where Q6's weight gets settled by feel.
- **Operator questions:** none open. The list is approved and tag 11 is identified.
- **Ledger estimate:** no source removed. About 3 to 7 catalog records added, plus their products, plus a one-shot
  command of roughly 150 lines that is deleted again in this campaign. Net carrying cost: the content, and nothing
  else.

## Cut 2. CultMath: bounded least squares (CultLib)

- **Repo/branch:** `F:\Projects\CultLib`, a branch from `45c2f40` (Aetheria's pinned `CultLibRevision`,
  `Directory.Build.props`). Depends on nothing.
- **First:** run `dotnet test packages/cultmath/tests/CultMath.Tests` green at base and record the count.
- **Deletes first:** none. This is a pure addition, and it is the ruled owner fill (R4).
- **Adds:** one C# file in `packages/cultmath/src/CultMath/` with a static solver for
  `min ||A x − b||²` subject to `lo ≤ x ≤ hi`. It serves a dense, small problem (m ≤ ~24 rows, n ≤ ~24 columns).
  Rules:
  - The method is a primal active set (bounded-variable LS). Each iteration solves the free set by Cholesky on the
    normal equations, or by QR if Hands prefers conditioning. It terminates on KKT: at each bound the gradient sign
    must be consistent with that bound.
  - `float` in, `Span`/`ReadOnlySpan` arguments, caller-supplied workspace. No allocation per call.
  - `x` is both warm start and result. The solver clamps it to the box first.
  - It returns an iteration count or status, has a bounded iteration cap, is deterministic, and keeps its
    last feasible iterate on a cap hit. A rank-deficient free set is handled (the caller adds a small ridge row,
    and the solver must not throw on a singular pivot).
  - Naming stays boring and HLSL-adjacent per `docs/design.md` Rules, for example a
    `CultMath.BoundedLeastSquares` static class. It is C#-only like the intercept helpers (`math.cs`). No Rust or
    HLSL mirror, because it is not a batch kernel and no shader needs it.
- **Tests** in `packages/cultmath/tests/CultMath.Tests`:
  - `InteriorOptimumEqualsNormalEquations`: a problem whose unconstrained optimum lies inside the box returns it.
    Pins the free-set solve.
  - `KktHoldsOnRandomBoxedProblems`: randomized problems up to 24×16 are checked against a projected-gradient
    reference to 1e-4 relative cost, and each active bound's gradient sign is checked. Pins optimality and the
    multiplier test.
  - `AllBoundsActive`, `ZeroColumn`, `DuplicateColumns`: degenerate columns return without throwing and are
    optimal. Pins rank handling.
  - `WarmStartMatchesColdStart`: a solution from a perturbed warm start equals the cold solution. Pins
    that the start does not bias the result.
  - `AsymmetricBounds`: `lo = −1, hi = 1` on some columns and `[0,1]` on others. Pins bidirectional actuators.
  - Fixtures must not be degenerate: non-square, non-identity A, and b not in A's range.
- **Release:** build the Unity package (`packages/cultmath/scripts/build-unity-package.ps1`), bump
  `unity/org.gamecult.cultmath/package.json` to 0.2.4, and tag `cultmath-unity-v0.2.4` by CultLib's own release
  path. In Aetheria, bump `Packages/manifest.json`'s `org.gamecult.cultmath` tag and `Directory.Build.props`
  `CultLibRevision` in one commit.
- **Authority map:** Owner: CultMath. Inputs: A, b, bounds, warm start. Outputs: x and status. Forbidden writers:
  no least-squares or linear-solve code in `Aetheria/Assets/Scripts/**` (negative grep in Cut 3).
- **Verification:** `dotnet build packages/cultmath/src/CultMath/CultMath.csproj`; `dotnet test` of CultMath.Tests.
  Aetheria's `dotnet test tests/Aetheria.Shared.Tests` still passes 244 after the bump. Unity compiles the new
  package, and only the operator can check that.
- **Ledger estimate:** +150..220 lines of source and +150 lines of test in CultLib; Aetheria gets a 2-line bump.

## Cut 3. `ShipControl`: shared controller and allocator replace the mixer

- **Repo/branch:** Aetheria, a branch from the Cut 2 bump commit. Depends on Cut 2. Cut 1 is not a
  prerequisite for the code, but its restored hulls are what the operator's play check needs.
- **First:** before editing, commit the base flight numbers above as test constants, reproduced by the fixture spec
  in "Findings". They are computed at `cd846916`, never captured from new code. Also run a LonginusX-with-Traction
  pin at base: `AetherDrive.Axis` for each probe input is `(my, mx, sqrt(|sin e|)·sign)`, including e = 30°, which
  gives `Axis.z = 0.7071`.
- **Deletes first** (separate commit, build and tests green, no behaviour change):
  - `Ship.cs:61-66` `TurnTime` (6 lines).
  - `Behaviors.cs:96-99` `IAnalogBehavior` (4 lines) and its mention in the `Thruster` declaration (`Thruster.cs:40`).
  - `Entity.cs:2007`, the commented `IAnalogBehavior` line.
- **Deletes (behaviour commit):**
  - `Ship.cs:30-39` (bucket and item sets, 10 lines).
  - `:50-59` (capacity properties and strafe lists, 10 lines).
  - `:96-118` (bucket construction; `Activate` keeps `base.Activate()` and gathers actuators, about 20 lines).
  - `:123-124` (subscriptions) and `:127-143` (`RemoveAetherDrive`, `RemoveThruster`, 17 lines).
  - `:145-249` (the `ThrustCalculation` region, 105 lines).
  - `:255-291` (mixer and snap, 37 lines).
  - The public `Axis` setters: `Thruster.cs:45-49` and `AetherDrive.cs:81-85` become getters plus a command method
    only `ShipControl` calls.
  - Total is about 200 lines out of `Ship.cs`.
- **Keeps:** `Ship.cs:253` gate (active, not in a wormhole); `:294-310` drag, position, gravity and rotation
  quaternion; wormhole code; `Thruster.Execute`/`AetherDrive.Execute` physics unchanged. The throttle is still
  `_input`/`_axis`, so power requests, audio and particles read what they read today.
- **Adds:** `ShipControl` in `Assets/Scripts/ServerShared/ShipControl.cs`, owned by `Ship` and stepped from
  `Ship.Update` where the mixer was. It is one file and one owner. Types and rules:
  - **Actuator columns.** A narrow interface implemented by `Thruster` and `AetherDrive`. There are two
    implementers and one consumer; this replaces `IAnalogBehavior`.
    - Each actuator reports its columns every tick: body-frame (Fx, Fy) in m/s² and yaw rate in rad/s
      (clockwise positive) per unit throttle, plus bounds. It then accepts its throttles back.
    - **Thruster:** one column, [0,1]. F is the negative item facing (`Rotate` of (0,1) by mount rotation) times
      live `Evaluate(Thrust)/Mass`. Yaw is `Torque·Thrust·TorqueMultiplier/Mass`.
    - **Zeroing:** the column is zero when `!Item.Active.Value` or `Item.PowerSupply ≤ 1e-4`, which is the same
      predicate `Execute` gates on. `Thruster.Thrust` (stale, updated only in `Execute`) is not the source.
    - **AetherDrive:** three axes. Translation is split into ± columns, [0,1] each, because the drive's efficiency
      depends on sign and speed (`AetherDrive.cs:138`). Torque is one column, [−1,1].
    - **Drive authority is nominal.** Effectiveness is the drive's force at `MaximumRpm` from its own stats (rotor
      mass, λ, λ multiplier, coupling efficiency, `AetherTorqueMultiplier`), scaled by the same liveness and by its
      condition. It is not the instantaneous `Rpm`. Rotor spin-up is the drive's internal dynamics, not an
      allocation decision. This choice is what keeps LonginusX exact: for a lone drive, self-consistent capacity
      cancels the scale, so throttle equals input.
  - **One solve over the whole wrench.** There is no rotation stage and no translation stage. Each tick
    `ShipControl` builds a desired wrench `v = (Fx_d, Fy_d, ω_d)` and solves, once,

        min over u in [lo, hi] of  Σ_axis ( w_axis · (B_axis · u − v_axis) / cap_axis )² + ridge · |u|²

    where `B` is the live column matrix, `cap_axis` is that axis's achievable extreme, and `ridge` is about 1e-3.
    The normalization is what lets a rotation error and a translation error be compared: each residual reads as a
    fraction of what this ship can do on that axis.
  - **Achievable extremes.** `cap` for an axis is the largest value that axis can take inside the throttle box,
    which for a box constraint is just the sum of the positive entries of that row (the negative ones for the
    other half-axis). Six numbers, no solve: `+x`, `−x`, `+y`, `−y`, clockwise, counter-clockwise. They are also
    what `MovementDirection` is a fraction of. Probe values: Longinus `+y` 172.41, `±x` 68.97, yaw 8.25 rad/s
    (472.9°/s); Djinni `+y` 55.56, `−y` 18.52, `±x` 37.04, yaw 3.25 rad/s (186.2°/s).
  - **Demand.** `F_d = (mx · cap(±x), my · cap(±y))` from `MovementDirection`. `ω_d = min(profile(e) · cap(dir),
    e / dt)` toward the `LookDirection` heading, `profile(e) = sqrt(sin e)` for e ≤ 90° (base's own curve) and 1
    beyond, with the `e/dt` term landing the heading without overshoot in place of the deleted snap. A zero
    `LookDirection` means hold heading: no demand, no NaN.
  - **Direction choice** stays a time comparison, `angle_in_that_direction / cap(dir)`, infinite where `cap` is
    zero, with the committed direction held unless the other is faster by a margin. It is not a branch on whether
    the ship "can" turn: under Q2 = B `cap(dir)` is almost always non-zero, and the comparison is what makes the
    long way round appear.
  - **Weights.** Translation rows weigh 1. The yaw row weighs `w`, the single knob (Q6), default **3**. There is
    no other tuning constant in the objective.
  - **The three regimes fall out of that solve; none of them is a rule** (closed-loop probe, below):
    - (a) *Turning while forward thrust is also wanted.* The mains are already firing for `F_d`, so their torque
      costs nothing extra, and the ship turns with them.
    - (b) *Turning in place.* `F_d` is zero, so every newton of main thrust is pure error, and the solver spends it
      only to the extent the remaining yaw residual is worth more. The intact Longinus is no longer forced into
      the 84 m/s² burn the earlier sized-demand design produced.
    - (c) *No attitude authority in that direction.* The only way to cut the yaw residual at all is the mains, so
      the solver takes the lurch, and the direction comparison decides whether that beats the long way round.
  - **`TorqueFloor` has no consumer left.** It was read only at `Ship.cs:115,118`. The field goes from
    `GameplaySettings` (`Settings.cs:205`) along with its authored value in `Assets/Resources/Settings.asset`;
    `TorqueMultiplier` and `AetherTorqueMultiplier` stay, because they are physics.
  - **Budget.** One solve per ship per tick, plus six sums. The earlier design's four extra capacity solves are
    gone. The fix for cost is solver efficiency, not a cache, because a cache would be a second truth for liveness
    (invariant 3).

### Closed-loop probe behind Cut 3

The single-tick table in Part II is measured against the real engine at `cd846916`. The numbers in this section
come from a **separate scratch model**: the fixture columns above, kinematic rotation, `dt` 0.02, the objective as
stated, and the base mixer re-implemented against the same integrator so the two are compared like for like. They
are design evidence and test targets, not engine pins; Hands reproduces them against the real engine and reports
the differences.

| Manoeuvre (Longinus fixture) | base mixer | solve at w = 3 |
|---|---|---|
| Turn 90° in place | 0.32 s, 13.9 m/s of drift | 0.30 s, 16.9 m/s of drift, main peaks at 0.73 throttle |
| Turn 90° at full forward | 0.32 s | 0.30 s |
| Strafe right, 1 s, look held | no strafe at all | 10.7 m/s gained, heading holds within 1.1° |
| Djinni turn 90° in place | 0.68 s, no drift | 0.68 s, no drift, no stern throttle |

The drift in a turn is dominated by the nose thruster, which pushes sideways whatever the controller does: base
pays 13.9 m/s for a 90° turn and the solve pays 16.9 m/s, in about the same time. That is the honest shape of
regime (b): the main does contribute torque, but the turn does not become a forward burn.

The yaw weight trades heading-holding against how hard the mains are spent, and on this hull both come from the
same pair of actuators:

| w | strafe gained in 1 s | heading deviation while strafing | 90° turn in place | main peak |
|---|---|---|---|---|
| 0.5 | 0.1 m/s | 179° (heading lost) | 1.62 s | 0.14 |
| 1 | 46.4 m/s | 59° | 0.60 s | 0.37 |
| 2 | 13.7 m/s | 3.8° | 0.36 s | 0.63 |
| **3** | **10.7 m/s** | **1.1°** | **0.30 s** | **0.73** |
| 5 | 9.9 m/s | 0.4° | 0.28 s | 0.79 |

Damaged cases at w = 3: a Longinus with `Th.CCW` destroyed reaches a heading 90° to port **the long way round**
(0.74 s, sweeping +269°) and a heading 20° to port **the short way, on differential main thrust** (1.18 s, sweeping
−18°, gaining 19.7 m/s). A hull whose single main sits on the centre line has no counter-clockwise authority at
all and always takes the long way (0.86 s). A Longinus with both nose thrusters gone still turns 20° in 0.60 s on
its mains alone, and does it while gaining 83 m/s if forward thrust was also asked for against 20 m/s if it was
not — regime (a) against regime (b) on one fixture.

- **Per-file changes** (against `cd846916`):
  - `Ship.cs:251-292`: `Update` calls `ShipControl.Step(dt)` inside the existing `:253` gate. The drag and position
    code below stays.
  - `Ship.cs:92-119`: `Activate` collects actuators into `ShipControl` (all `Thruster` and `AetherDrive`
    behaviours). No classification.
  - `Ship.cs:121-125`: the constructor drops both `ItemDestroyed` subscriptions.
  - `Thruster.cs:40`: implement the actuator interface, drop `IAnalogBehavior`. `:45-49`: public getter, internal
    command. `:61-71`: `Torque` stays as the geometry factor.
  - `AetherDrive.cs:81-85`: same pattern. Add the nominal-authority read next to its stats.
  - `tests/Aetheria.Shared.Tests/BrownoutTests.cs:111-131` and `ConditionRatioTests.cs:94-95`: equip the consumer
    thruster on the hull's centre column, using `TryEquip(item, int2(2, y))` with a free y, so `Torque == 0`. These
    tests pin brownout and condition, not flight. Their asserted values (for example `.1f` at
    `BrownoutTests.cs:162`) must not change. Fix the fixture, never the assertion. `PowerCurveTests.cs:52-62`'s
    comment about the `Axis` being clobbered becomes true for a different reason; update the wording only.
- **Authority map:**
  - Owner: `ShipControl` decides every actuator throttle and the feasible turn direction.
  - Inputs: `MovementDirection`, `LookDirection.xz`, current `Direction`, `Mass`, `dt`, each actuator's live
    column, `TorqueMultiplier`/`AetherTorqueMultiplier`.
  - Outputs: per-actuator throttle (`Thruster._input`, `AetherDrive._axis`); the achievable extremes, the
    movement-command mapping, `TurnTime(heading)`, and the step itself, which Cut 4 uses as its prediction model.
  - Derived state: columns, extremes and the demand are per-tick derived, never stored across ticks except the
    warm start and the committed turn direction, which are command state and not truth. `Thruster.Axis` and
    `AetherDrive.Axis` are display and command readbacks.
  - Forbidden writers: `Ship.Update`'s mixer (gone); any assignment to `Thruster.Axis`/`AetherDrive.Axis` outside
    `ShipControl`; `Ship.cs:283`'s direct `Direction` write; bucket pruning on `ItemDestroyed`; any Unity-side
    write of throttles. Also forbidden inside `ShipControl`: any test of whether an actuator is "for" rotation or
    translation, any per-direction special case, and any second solve that re-decides part of the wrench.
  - Shared paths: player writes (`ActionGameManager.cs:1254,1263`) and AI writes (`Agent`, `MoveTo`, `Combat`) both
    reach actuators only through `ShipControl.Step`. Wormhole exit leaves the gate closed until the animation
    ends, as today.
  - Deletion line: the delete commits above land before `ShipControl` gains behaviour.
- **Verification:**
  - Builds: `dotnet build Aetheria.Shared`; `dotnet test tests/Aetheria.Shared.Tests -m:1 -p:CultLibRoot=…`.
    Unity batchmode compile (operator, or Self when the editor is closed).
  - Tests (new file `LocomotionControlTests.cs`, fixtures exactly as in "Findings": off-origin, off-axis nose with
    `|fx| > |fy|`, nonzero dt, asymmetric damage):
    - `IntactLonginusMatchesBase` and `IntactDjinniMatchesBase`: every row of the base table within tolerance
      (2% of that ship's full-scale acceleration or turn rate), except the four accepted divergences below, which
      are pinned at their own probed values. Pins the allocator against base.
    - **Accepted divergences** (operator, 2026-09-22, "The divergence is fine"). Soul reads these as pinned
      behaviour, not as regressions, and anything outside them is a regression:
      1. Longinus turning in place spends its mains for torque, peaking near 0.73 throttle at w = 3. The
         manoeuvre costs 16.9 m/s of drift against base's 13.9 and finishes in 0.30 s against base's 0.32.
      2. Longinus strafing gains a weak strafe it never had: about 10.7 m/s in a held second, heading holding
         within about 1°, where base produced exactly nothing.
      3. Djinni strafe reaches 37.0 m/s² against base's 34.0 (+9%), by balancing torque with Stern 3 and Bow.
      4. Djinni turning in place may run a stern thruster and the bow thruster against each other at low throttle;
         net force stays zero, but their exhaust is visible.
      Plus two intended fixes, which are not divergences to tolerate but behaviour this cut is buying: turns past
      90° run at full rate instead of decaying to zero at 180°, and `|Direction|` no longer shrinks when the look
      is directly aft.
    - `LonginusXDriveAxisEqualsBaseFormula`: a drive-only hull; for every probe input, `AetherDrive.Axis` equals
      `(my, mx, sqrt(|sin e|)·sign)` to 1e-3. Pins the live player ship's feel exactly.
    - `CentreMainHullTakesTheLongWayRound`: the long-way fixture, built so the long way is the *only* way. One
      centred main (torque 0, so no differential authority) and one clockwise attitude thruster, the
      counter-clockwise one destroyed through the real `ItemDamage` path. Write `LookDirection` directly, as the
      player would, to 90° left. Heading changes clockwise every tick (never counter-clockwise), and the ship
      arrives within 2° in under 1.2 s (model: 0.86 s). Base comparison: a ship of that shape never turns at all.
      Pins the shared feasible-direction choice.
    - `LonginusMissingCcwPrefersTheLongWayAtNinetyDegrees`: the two-main Longinus with `Th.CCW` destroyed, looking
      90° left. It sweeps clockwise through about +270° and arrives (model: 0.74 s). Pins that the comparison is by
      time, not by a rule about which actuators are "for" turning.
    - `LonginusMissingCcwLurchesRoundTheShortWayAtTwentyDegrees`: the same ship looking 20° left. It sweeps
      counter-clockwise through about −20° on differential main thrust, arrives within 2°, and its speed rises
      while it does (model: 1.18 s, 19.7 m/s). Pins that the lurching turn is available and is chosen when it is
      faster.
    - `IntactShipTurningInPlaceDoesNotBurnForward`: the intact Djinni, looking 90° right with
      `MovementDirection` zero. Its speed at the end of the turn is under 1 m/s and no stern or bow thruster
      exceeds a low throttle. Pins regime (b) on a hull that has the actuators to keep translation clean. The
      intact Longinus, which does not, is covered by accepted divergence 1 instead, with its own bound: drift no
      worse than 1.3× base's 13.9 m/s and turn time no worse than base's 0.32 s.
    - `NoAttitudeAuthorityStillTurns`: a Longinus with both nose thrusters destroyed, looking 20° right. It
      arrives, on differential main thrust, and it gains speed doing so (model: 0.60 s). Pins regime (c).
    - `TurningIsCheaperWhenForwardThrustIsAlsoWanted`: the same mains-only ship, 20° right, run twice with
      `MovementDirection` zero and at full forward. Both arrive in the same time; the second gains much more
      speed because the burn was wanted anyway (model: 20 m/s against 83 m/s). Pins regime (a) as a consequence of
      one solve rather than a special case.
    - `StrafeHoldsHeading`: the intact Longinus, full strafe held for 1 s with `LookDirection` fixed. Heading
      deviation stays under 2° (model at w = 3: 1.1°). Pins the weight's other half, which is what stops the nose
      swinging when a ship strafes with a thruster that also yaws.
    - `LonginusMissingCcwTurnsRightAsBefore`: looking 90° right reaches within 2° in 0.32 s ± one tick (base
      value). Pins that damage on one side leaves the other side alone.
    - `LookDirectlyBehindTurns`: intact, look exactly aft. The ship turns, `|Direction|` stays 1 ± 1e-4, and there
      is no NaN. Pins the snap's deletion and the >90° profile.
    - `ZeroLookHoldsHeading`: default `LookDirection` gives no NaN in `Direction` or any throttle.
    - `DestroyedThrusterNeverReceivesThrottle`: for each Djinni thruster in turn, destroy it, then drive 50
      ticks of mixed inputs (forward, strafe, turn both ways, diagonal). Its `Axis` is 0 on every tick. Repeat for
      `Enabled = false` and for a zero power grant. Pins invariant 7.
    - `RepairedThrusterRejoins`: destroy, restore durability, `UpdatePerformance`. The next tick's strafe uses it.
      Pins the live read (invariant 3) against the old permanent pruning.
    - `PlayerAndAiInputsGiveIdenticalThrottles`: two identical Djinni hulls with the same damage. One gets inputs
      the way `ActionGameManager` writes them (`LookDirection` with nonzero pitch from yaw/pitch Euler,
      `MovementDirection` from a stick value). The other gets them through an `Agent` state writing the same yaw,
      flat. After `Update`, every actuator throttle is identical. Pins R2.
    - `LonginusMissingMainHoldsHeadingUnderThrust`: `Th.L` destroyed, forward input. Heading drift stays under 1°
      over 2 s, and forward acceleration is at least 70 m/s² (probe: 78 with 12 lateral slip). Pins torque-coupling
      compensation in the shared layer.
  - Negative greps, verified against `cd846916` to hit only the lines this cut deletes:
    - `\.Axis\s*[-+]?=` in `Assets/Scripts` should match nothing outside `ShipControl.cs`. At base it matches
      exactly `Ship.cs:256,264,273,275,276,287,288,291`. `FieldDriver.cs`'s `RectTransform.Axis` does not match;
      checked.
    - `_forwardThrusters|_clockwiseThrusters|StrafeTorqueThrusters|RecalculateThrust|TurnTime\(` should match only
      `ShipControl.cs`'s new `TurnTime`.
    - `TorqueFloor` should match nothing in `Assets/Scripts`, and nothing in `Assets/Resources/Settings.asset`
      once Unity rewrites it.
    - `IAnalogBehavior` should match nothing.
    - `lerp\(Direction` in `Ship.cs` should match nothing.
    - No least-squares code outside CultMath: `Cholesky|pseudo.?inverse|ActiveSet` in `Assets/Scripts` should
      match nothing.
  - Stryker: `dotnet stryker --since:<Cut 3 base>` from `tests/Aetheria.Shared.Tests`. Every non-equivalent
    survivor in `ShipControl.cs`, `Thruster.cs` and `AetherDrive.cs` is killed or triaged by name. Float boundary
    flips are equivalent, per the fire-control Cut 11 ruling.
  - Operator: fly LonginusX and confirm it feels unchanged (strafe, turn, look behind now turns). Then fly a
    restored Longinus or Djinni from Cut 1, shoot a thruster off it, and confirm the damaged handling and the
    lurching turn. Without Cut 1 this half of the check cannot be done at all.
- **Operator questions:** Q6, below, which does not block the cut. Q1, Q2, Q3 are ruled and Q5 is dissolved.
- **Ledger estimate:** −200 lines in `Ship.cs`, −12 elsewhere (`IAnalogBehavior`, `TorqueFloor` and its authored
  value). `ShipControl.cs` adds about 250–350 lines, tests about 500. Net source roughly +100. That buys
  actuator-loss capability, which is the explicit ask, and removes seven parallel role sets, the snap, permanent
  pruning, one authored setting and four capacity solves a tick.

## Cut 4. Heading planner in the AI

- **Repo/branch:** Aetheria, after Cut 3.
- **First:** pin base AI results as constants. On base, a Djinni with all stern thrusters destroyed never reaches
  the target (speed 0 at 120 s). Intact, it reaches it in 4.34 s. Both come from the probe (Agent plus MoveTo, dt
  0.02, target 300 m to port from (37,−12), nose `normalize(0.8,0.6)`).
- **Deletes first:** `Agent.cs:16-17` (the two thresholds) and `Agent.cs:60-78` (the body of `Accelerate`, 19
  lines). `MoveTo.cs:26` (the duplicate `LookDirection` write). The signature `Accelerate(float2, bool noTurn)`
  stays, since `Combat.cs:127` and `MoveTo.cs:27` call it.
- **Adds:** in `Agent` (above the inputs, AI only). **The planner chooses by predicted outcome, never by a
  rule.** It simulates each candidate and compares where the ship actually ends up.
  - **Candidate manoeuvre:** a pair (heading command, movement command) held for the horizon. The set is the
    headings the ship might fly with the translation that points the demand along Δv at each: 16 evenly spaced
    headings (Hands default; 8 to 32 is the sensible range), plus the Δv direction and the current heading.
  - **Prediction:** roll each candidate forward over a horizon of 1.0 s (Hands default; 0.5 to 2.0 s is the
    sensible range) in 5 substeps (3 to 10), stepping the *same* `ShipControl` solve and the same kinematics the
    ship will actually fly. There is no second physics model and no closed-form estimate: one owner for what the
    ship does, which is invariant 8 applied to prediction.
  - **Score:** the predicted outcome at the horizon — remaining distance to the objective, and the closing speed
    that ends the horizon (so a manoeuvre that arrives pointing the wrong way with no closing speed loses to one
    that is simply nearer and still closing). Infinite where the candidate ends further away than it started.
  - **This is what answers the operator's case.** A ship whose rotation has to be bought with main thrust turns in
    a great circle: the prediction shows the heading improving while the range opens, so a lateral burn that keeps
    the bearing and closes wins on its own numbers. Nothing in the planner tests whether the ship is a one-way
    turner, whether a thruster is missing, or which actuator would be used.
  - Pick the argmin with hysteresis: replan when a candidate beats the current plan by a margin, on a cadence
    (0.25 s default) or when the actuator set changes. The cadence exists for cost: 18 candidates × 5 substeps is
    about 90 solves per replan, roughly 1 ms per replan per ship at the scratch timings, so a 0.25 s cadence over
    20 AI ships is a few percent of a core. Hands measures and reports; if it is too slow the answer is fewer
    candidates or a shorter horizon, both of which are stated ranges, not a cache.
  - Write `LookDirection = θ*` unless `noTurn`. Write `MovementDirection` as the per-half-axis fractions that point
    the translation demand along Δv, inverting `ShipControl`'s own mapping (a `ShipControl` helper, so the AI never
    re-derives it), with a deadband near zero Δv.
  - `noTurn` (combat) skips the heading half of the candidate but still predicts the translation. A Djinni with no
    stern facing its target strafes or backs off on its own.
- **Authority map:**
  - Owner: `Agent` decides what the AI writes to the two inputs.
  - Inputs: target velocity and objective position, the `ShipControl` step used as the prediction model, current
    velocity and heading.
  - Outputs: `LookDirection` (unless `noTurn`) and `MovementDirection`.
  - Derived: the plan (heading, time of last replan) is command state only.
  - Forbidden writers: `MoveToState` writing `LookDirection`; any AI code writing throttles or `Direction`; any
    second model of what the ship will do, whether a closed-form estimate, a capability table of its own, or a
    branch on which actuators are missing.
  - Shared paths: `MoveToOrbitState` (patrol) and `CombatState` both go through `Accelerate`.
- **Verification:**
  - `DjinniWithoutSternReachesTargetByCrabbing`: stern cluster destroyed, target 300 m at a bearing 30° right of
    the nose, driven through `Agent` plus a fixed-target `MoveToState`. The ship arrives within 10 m in under 8 s.
    Base never arrives (speed 0 at 120 s). Pins R1(2) and the stuck-forever cheese.
  - `CrabBeatsTheBigCircle`: **the operator's case, and the reason Cut 4 predicts instead of deciding.** The
    fixture is a hull that can strafe cleanly but can only rotate by spending a main: two off-centre mains aft and
    one amidships lateral pair whose torque cancels, no attitude thrusters, with an objective abeam to port at
    300 m. A turn-to-face policy run in the same harness spends the manoeuvre sweeping a wide arc that barely
    improves the bearing and opens the range; the planner's choice closes it. Pinned as time to reach the
    objective, and as range at the horizon, never as "the planner chose to strafe".
  - `CrabBeatsPointAndBurnWhenMainIsWeak`: Djinni with Stern 1 and Stern 2 destroyed (asymmetric; Stern 3's torque
    is balanced by the laterals), target 300 m at 60° left. The planner arrives strictly sooner than a naive
    point-and-burn agent run in the same harness through the same Cut 3 controller. A relation, not a captured
    number.
  - `IntactShipsStillPointAndBurn`: an intact Djinni arrives no later than base's 4.34 s + 10%, with the restored
    hull's own `VelocityLimit` in force. Pins no regression.
  - `LonginusWithoutReverseFlipsToBrake`: target velocity opposite the current velocity; the predicted-outcome
    score puts the ship round, because a Longinus has no reverse thrust.
  - `PlannerTakesTheLurchWhenItPays`: the Longinus with `Th.CCW` destroyed and a Δv 20° to port, where the
    lurching turn is genuinely faster. The ship gets there sooner than a fixed-heading strafe would in the same
    harness. Pins that the planner inherits the controller's comparison rather than avoiding the lurch on
    principle.
  - `PlannerPredictionMatchesFlight`: run a candidate's prediction, then fly the same commands for the same
    horizon, and compare the end states. They agree within a small tolerance. Pins that the prediction uses the
    real controller and that nobody has grown a second model.
  - Negative grep: `LookDirection` in `Agents/States/MoveTo.cs` should match nothing.
  - Stryker `--since:<Cut 4 base>` over `Agent.cs`, `MoveTo.cs` and `ShipControl.cs` queries.
  - Operator: watch a patrol Djinni with a stern thruster shot out crab to its next orbit.
- **Ledger estimate:** −22 lines, +140 lines of source (the prediction loop replaces the closed-form score),
  +300 lines of test. No new type beyond the plan and the candidate.

## Cut 5. Combat facing and tactics (target shape only)

This cut gets mapped after fire-control Cut 12 lands, because that cut decides what presenting a side is worth.

- **Owner:** `CombatState` (`Combat.cs:88-127`), above the inputs.
- **Shape:** extend Cut 4's predicted-outcome scoring with what the weapons want — arcs, ranges and the aim the
  fire-control path will take — so the facing a ship holds is the one its predicted damage favours, not a rule
  about its turn asymmetry. A ship that turns one way fast and the other way slowly will, under that scoring, tend
  to keep its target drifting toward its fast side, because that is what predicts better. A ship with good turret arcs and poor rotation holds a heading and lets the
  turrets work. Weapons with fixed arcs pull the heading onto the target. It uses the Cut 4 planner for thrust.
- **Fork:** Q4 (heading versus aim), which must be ruled before mapping.

## Operator questions

Each question gives options and a recommendation. Self paces these one at a time. Q1, Q2 and Q3 were ruled on
2026-09-22; their text is kept as history, and the live design is in the cuts above.

- **Q6: the yaw weight in Cut 3's solve (does not block Hands).** The solve has exactly one knob, the weight on
  the yaw residual against the translation residuals, after each axis is normalized by that ship's achievable
  extreme. On a Longinus both the strafe and the turn come from the same nose thrusters, so the knob trades
  heading-holding against how hard the mains are spent for torque (closed-loop model, table in Cut 3):

  | w | strafe gained in a held second | heading deviation while strafing | 90° turn in place | main peak |
  |---|---|---|---|---|
  | 1 | 46.4 m/s | 59° | 0.60 s | 0.37 |
  | 2 | 13.7 m/s | 3.8° | 0.36 s | 0.63 |
  | 3 | 10.7 m/s | 1.1° | 0.30 s | 0.73 |
  | 5 | 9.9 m/s | 0.4° | 0.28 s | 0.79 |

  The Djinni is unaffected at every value: it has the actuators to do both cleanly. Base, for reference, does not
  strafe at all and turns 90° in 0.32 s.
  - **A: w = 3.** Heading holds while strafing, turns match base's speed, and the mains carry a real share of the
    torque in a turn.
  - **B: w ≈ 1.** The mains stay nearly out of turns, but a Longinus asked to strafe swings its nose most of the
    way round, because strafing and turning are the same thrusters.
  - **C: w = 5.** Heading holding is near-exact and the mains are spent hardest.

  **Recommended: A.** Hands starts there and the Cut 3 pins are written against it. This is a feel question, so
  the honest place to settle it is the Cut 1 play check; changing it afterwards moves numbers in pins, not
  structure.
- **Q4: heading versus aim (blocks Cut 5 only).** `LookDirection` is both the heading command and the aim, read by
  `LockWeapon.cs:94`'s lock cone, guided projectiles, reticle targeting and the tractor beam. Capability-aware
  facing wants the AI to hold a heading that is not its aim, and under R2 any split applies to the player too.
  - **A.** Add a heading input beside the aim on the shared surface. The player's heading follows the view unless a
    player control is added later.
  - **B.** Keep one input, and the AI accepts degraded lock cones and missile aim while it manoeuvres.

  **Recommended: A**, decided when Cut 5 is mapped.

### Ruled or dissolved (history)

- **Q1: intact-ship divergence from base.** **Ruled A, 2026-09-22: "The divergence is fine."** The four accepted
  divergences and their magnitudes are listed in Cut 3's verification. The rejected option was to require exact
  base behaviour, which would have meant reintroducing per-thruster role rules into the objective.
- **Q2: rotation from translation thrusters.** **Ruled B, 2026-09-22: "that's absolutely viable and can be a
  better decision than turning around the long way, I wouldn't introduce a thruster exclusion for this."** The
  option this map recommended (A: rotation authority only from thrusters above `TorqueFloor`, so a lost attitude
  thruster means that direction is gone) was rejected. Cut 3 and Cut 4 are written to B.
- **Q3: Longinus fixture layout.** **Ruled, 2026-09-22: "Good catch on the Longinus main thrusters, I was
  misremembering."** Fixtures follow the data: two aft 2×2 mains.
- **Q5: how the rotation demand is sized.** **Dissolved, 2026-09-22.** The question assumed a separate rotation
  demand that something had to size. The operator refused the premise — "it should only do that if the ship's
  controller also *wants* to accelerate forwards that much" — and the answer is one solve over the whole wrench
  with both residuals in the same currency, which makes the three regimes consequences rather than rules. Neither
  of the options this map offered (size from attitude authority with a fall-back; size from everything) survives,
  and `TorqueFloor` loses its last consumer. What is left of the question is Q6, the single weight.

## Subtraction ledger (estimates)

| Cut | Removed | Added | Dependencies / targets |
|---|---|---|---|
| 1 | 0 source; the one-shot command is deleted again in this campaign | 3–7 catalog records + products; ~150 lines of throwaway tool + ~120 test | No new package, target, asset or authored field. Existing prefabs, schematics and factions are reused |
| 2 | 0 | ~200 src + ~150 test (CultLib) | CultMath gains one file; cultmath-unity 0.2.4; Aetheria pin bump |
| 3 | ~212 (`Ship.cs` ~200, `Behaviors.cs` 4, `Entity.cs` 1, setters, `TorqueFloor` and its authored value) | ~300 src + ~500 test | `IAnalogBehavior` and one authored setting removed; four capacity solves a tick removed; no new package, target or authored field |
| 4 | ~22 | ~140 src + ~300 test | none |
| 5 | not mapped | not mapped | not mapped |