Open Issues -- schema gaps and development needs (all problems)
================================================================
Moved 2026-11-10 from doc/constraint-led-solving/Schema-Gaps.txt.  Keeps
only what is still open; a resolved entry is removed (it remains in git
history).  Gap ids are stable and never reused: a citation of any Gnn
elsewhere refers to that entry in history.  The full G1-G22 register
(1,295 lines) was compacted 2026-10-02 with D's approval.

PURPOSE
-------
Two kinds of entry:
- A schema gap is a question about problem structure the static profile
  failed to ask, found by surprise (M5), stated domain-generally rather
  than as a patch for one problem.
- A NEED is a development need: an engine or technology change, or a
  difference between the game and the engine found in play.
doc/solving-advisor.md (Subgoal dialogue step 5) and
doc/simulation/operations.md file new entries here.  Recording an entry is
not implementation approval; agree new work with D separately.

ENTRY FORM FOR NEW GAPS (NEEDs use Origin, Need, Proposed scope,
Dependencies, Acceptance, Status)
    Gnn -- <title>                                       [OPEN]
    Origin     <problem>, <task or stage>, <date>
    Found      how it was found
    Missed     what the schema missed
    Question   the question that should have been asked
    Fix        a domain-general fix (proposed, not implemented)
    STATUS     OPEN / CLOSED, with dated updates beneath
The next free id is G23.

CLOSED BY THE 2026-10-02 COMPACTION
-----------------------------------
G3, G4 and G10 concerned the prediction-register apparatus (value
predictions, leakage through scoring text, partitioning register section
4).  The register was retired 2026-09-25; D closed them 2026-10-02.
Already closed or resolved before compaction: G1, G2, G5, G6, G7, G11,
G13, G14, G18, G19 (for supplied scenarios), G20, G21, G22.
Resolved since: the continuation-prerequisites note (procedure in
doc/solving-advisor.md, Subgoal dialogue step 2) and the two one-step
predecessor NEEDs of 2026-10-17 (find-state-predecessors).
G9 (a keeper can serve a non-movement passage) was RESOLVED 2026-10-02 at
SD's scope (T43): SD keys services on controlled devices, not traversal
arcs, covering gates, traversal-clause drives and receivers.  Checked on
crelay-topo's profile: gate8 (on the route) needs receiver1 active; every
receiver1 chain needs gate4 open; gate4 open == a body on plate3, which is
G9's original case.  Not claimed by SD, as before: how long the body must
stay (simultaneous availability).

OPEN GAPS
---------

G8 -- No extractor owns the segment axis                    [OPEN]
    Origin     crelay-topo, 2026-09-19.
    Question   Which state bit opens and closes an epoch (e.g. a recorder
               cycle), and across that boundary which objects, facts and
               capabilities are created or destroyed rather than changed?
    Fix        Report, per dynamic relation, updates that delete its
               propositions wholesale and the guarding condition; the
               epoch bits and what does not survive them follow.
    Status     Open.  Segments are still supplied by the caller (RO, CP's
               :reservations, BT's single supplied event); none is
               extracted.

G12 -- Destination and transition premises not supplied by a cut [OPEN]
    Origin     crelay-topo, 2026-09-20.
    Question   What derivation obliges each cargo object to reach a
               particular region, and which concrete transitions are
               covered by the graph used to claim its keeper cannot follow?
    Status     Open, addressed in part.  S4 prints explicit destinations,
               conditional pressure demand and graph-only cut candidates;
               RO and CP (T44) check caller-stated allocations and
               reservations.  Not done: destinations or reservations are
               not derived, their necessity is not established, and reach,
               transport and replacement witnesses are not evaluated.

G15 -- Launch configuration and propagation across a traversal [OPEN]
    Origin     crelay-topo, 2026-09-22.
    Question   Before assigning a realization or budget to a region-graph
               traversal, what launch elevation or support does its
               movement predicate require, and do the controller changes
               needed to clear the barrier preserve that configuration
               through propagation until the crossing?
    Status     Open.  BT (T45) answers the controller-transition and
               propagated-successor part for one supplied event; nothing
               assigns a launch configuration to a traversal.  The
               advisor's Subgoal dialogue (check each transit state apart
               from the final state) is the procedural stopgap.

G16 -- A route arc names a door, not the work of opening it [OPEN]
    Origin     crelay-topo, 2026-09-24.
    Question   For each device a route must cross, where must an actor be
               to operate its controller; is that on the route; and if not,
               what route, keepers and return does the excursion need?
    Status     Open, addressed in part.  SD (T43) joins passage services to
               their providers and premises and flags NEEDS ... FIRST.  Not
               joined: switch and toggle reach sites to the route,
               placement or pickup from outside the site's region, and an
               excursion's return with cargo.

G17 -- A relay chain needs relay-to-relay sightlines and a body cost [OPEN]
    Origin     crelay-topo, 2026-09-24.
    Question   For a receiver-controlled device, which relay chains connect
               a source to the receiver, under which device states, and
               which bodies, risers and pressure supports does each commit?
    Status     Open, addressed in part.  RC (T16) enumerates the chains.
               Not done: feeding RC into S4's receiver row and into the T6
               budget.  Stays open until those joins exist or D decides
               they are not needed.

NEED -- Extending a checkpoint with a validated path (2026-10-15)
-----------------------------------------------------------------
Origin       Solving-advisor revision, 2026-10-15 (routes for realizing a
             subgoal).  Development need, not a schema gap; not approved.
Need         A subgoal realized other than by the checkpoint form of
             solve-subgoal (by hand, by restarts, by the enumerator, or in a
             spec copy) yields a path but no checkpoint.  Recorder problems
             need the checkpoint, whose history the recorder's validators
             judge, to start the next subgoal.
Scope        A function taking a checkpoint and an action list that replays
             the list from the checkpoint's endpoint and returns a new
             checkpoint with the segment as its last phase, refusing a
             failing action as validate-action-sequence does.
Dependencies src/ww-search-checkpoint.lisp (phases built as in
             solve-search-checkpoint), validate-action-sequence.
Acceptance   On a recorder problem, a hand-derived segment added this way
             exports and imports like a searched one, and the next
             checkpoint search from it finds the same result as from a
             searched checkpoint at the same endpoint.

NEED -- Passing a gate held open by the agent's own body (2026-11-09)
--------------------------------------------------------------------
Origin       intersect, solving advisor, SG3 dialogue, 2026-11-09.
Need         Decide, and if necessary enforce, whether an agent may walk
             through a gate whose open state depends on where the agent stands.
             MOVE (tech/-mobility-action.lisp) judges a route's gates in the
             departure state (gate-open-for-object reads (open gate)) and
             propagates only after arrival, so a gate opened because the
             agent's body blocks a beam (intersect: agent1 at location8 blocking
             blue so red reaches receiver2 and gate2 opens) can be passed, and
             closes behind the agent.  Plates differ: stepping off a plate is a
             separate transition, so a gate held by the agent's weight is never
             passed.  D: in the real game a gate closes as soon as its control
             is lost (plate example); for beams D left the engine as is,
             2026-11-09, because intersect's play appears to allow it.
Proposed scope  Check other beam problems for plans that use this move; if the
             game forbids it, a MOVE guard: reject a route through a gate that
             is closed in the state recomputed with the agent removed from its
             departure location.
Dependencies tech/-mobility-action.lisp, tech/-passability.lisp, tech/-gate.lisp;
             recorded solutions that would need re-validation (intersect SG2).
Acceptance   D's ruling per beam problem; with a guard, intersect SG2's
             location8 -> gate2 move is rejected and test-topo/test-talos
             recordings are re-checked.
Status       Open; to check for other problems later (D, 2026-11-09).
             2026-11-10: when D played intersect in the game the move was
             avoided, not tested: connector2 was given a beam to receiver4
             that keeps gate2 open without the body (Briefing, Played in the
             game).  The game's behaviour for this move is still unobserved.


NEED -- More than 999 planning objects (2026-11-10)
--------------------------------------------------
Origin       intersect, solving advisor, spec revision 4, 2026-11-10.
Need         A coordinate-driven Talos spec registers one object per potential
             beam crossing.  intersect with 11 locations exceeded the limit at
             staging (REGISTER-DYNAMIC-OBJECT, src/ww-converter.lisp: "Design
             Limit Error: Total number of planning objects exceeds 999"; the
             failing record was crossing753).  Adding two locations therefore
             forced removing two others (location4, location5).  Crossing
             records grow roughly with the square of the beam endpoints, so
             larger levels, and R7 test-point sweeps on a spec copy, will meet
             the limit again.
Proposed scope  Either raise the object-index limit (the integer encoding of
             propositions allots three digits per object), or register a
             crossing record only when both beams are potentially visible.
Dependencies src/ww-converter.lisp (object indices, convert-to-integer);
             tech/-beam-los-coordinates.lisp (crossing record derivation).
Acceptance   intersect stages with all 11 locations and the accepted 40
             actions still replay to the goal; test-topo and test-talos pass.
Status       Open; not approved for implementation.


NEED -- Two stable beam arrangements; the game keeps the first (2026-11-10)
--------------------------------------------------------------------------
Origin       intersect, play in the game by D with A watching, 2026-11-10.
Need         Where a relay's feed beam and a second beam cross a third beam at
             two points, two arrangements can both be self-consistent: relay
             lit (its own beam cuts the third beam before that beam reaches
             the feed) or relay dark (the third beam cuts the feed, so the
             relay's line is only a pairing and cuts nothing).  In the game the
             arrangement depends on history: a beam that already exists wins,
             and a connector placed into a cut feed stays dark until the
             cutting beam is interrupted (D stood in it).  The engine picks one
             arrangement from the state alone: for intersect it chose lit
             after step 7 (the game showed dark) and dark after step 17 (the
             game stayed lit).  Plans can therefore replay in the engine yet
             need an extra body-block step in the game, or the reverse.
Proposed scope  Decide whether beam state must carry history (which beams
             were live before the action) or whether a rule from the state
             alone can match the game: for example, a newly placed connector
             never wins against an existing beam.
Dependencies tech/beam-relay.lisp, tech/beam-crossing.lisp (settling of
             mutually dependent crossings); recorded solutions.
Acceptance   intersect's step 7 leaves gate2 closed until agent1 interrupts
             blue, and gate2 stays open after agent1 leaves the beam at
             step 17; test-topo and test-talos recordings re-checked.
Status       Open; not approved for implementation.
