PROBLEM / REVISION / SOURCES / AUTHORIZED SCOPE
  Problem: captjohn-advisor (Captain John and the Wasp: placement + route).
  Revision: 2, 2026-10-11 (consolidated; analysis agreed).
  Sources: user's prose description in dialogue (clues 1-8, movement rules).
  Record: doc/problems/captjohn-advisor/problem-analysis.txt
  Scope: problem analysis only. No spec writing, staging, or searches authorized.
  The existing spec (if any) has not been read; comparison awaits approval.

AGREED PROBLEM DESCRIPTION
  Phase 1 (placement): put John, the Wasp (ship), 2 crew mates, 2 guards on a
  3x3 grid, one token per cell; every remaining cell is grass (no blank cells).
  All eight clues must hold:
    1. Ship not in John's row or column.
    2. John not in the row or column of either guard.
    3. No guard in column 3.
    4. Each guard has grass directly above or below it.
    5. Ship shares a row with one guard and a column with the other.
    6. Some grass cell is diagonally adjacent (corner-touching) to both crew.
    7. Row 1, column 2 is grass.
    8. The two guards share no row or column.
  Phase 2 (route): from John's cell, John moves one cell at a time in any of the
  8 directions; never revisits a cell (start included); never steps onto a guard
  cell ("passing" = stepping onto, per user, tentatively). He must visit both
  crew cells, then end on the ship.
  Scope: this instance is a stand-in for larger instances (bigger grid, more
  tokens) using the same clue kinds; design targets the larger family.
  Agreement: user agreed in dialogue 2026-10-11.
  Tentative: "passing" might later also forbid diagonal squeezes past a guard;
  that would only remove route moves (see CORRECTIONS policy).

USER OBJECTIVE AND ANSWER IDENTITY
  Placement: all layouts satisfying the clues; exactly one expected; flag an
    issue if more than one (or none). A layout is the assignment of token
    kinds to cells; identical tokens (guards, crew) are interchangeable.
  Route: any one shortest route, length in moves. Ties: any one is acceptable.

INTENDED RULES AND EXAMPLES
  Given: grid size, token counts per kind, clue list (data).
  Ship-last consequence: entering the ship early ends the trip (no revisit),
    so ship entry before all crew are visited can never reach the goal.
  Allowed move example: diagonal step onto unvisited grass.
  Forbidden: stepping onto a guard; stepping onto a visited cell; entering
    ship before both crew cells are visited (pruned as hopeless, not illegal
    in the story).
  Grass semantics: "X is grass" == "X is unoccupied after placement".

CURRENT IMPLEMENTATION
  Not read (description-first evaluation).

STRUCTURE AND GROWTH
  Growth: grid NxN, counts of crew/guards (grass = remainder), number of
  clues of the same kinds.
  Placement: choices = cells per placed token; identical tokens ordered by
    cell index; depth = number of placed tokens; finite, no recurrence.
  Route: state = John's cell + visited set; visited-set count grows
    exponentially with free-cell count; more crew add visit-order choices.
  Termination: route length bounded by free cells - 1 (no revisits).

JUSTIFIED DESIGN
  D1 Two searches with handoff (agreed). Placement exhaustive (uniqueness),
     route shortest. Alternative: one combined search -> rejected: turns the
     objective into best route over all layouts and hides uniqueness.
  D2 Place only named tokens; grass = unoccupied (agreed). Fixed grass cells
     (clue 7 kind) excluded from all placements from the start.
  D3 Identical tokens placed in increasing cell order (agreed). Coverage:
     every layout produced exactly once. Alternative: engine object
     symmetry pruning (B) - acceptable if source confirms it covers the
     placement action; ordering rule is simpler and explicit.
  D4 Placement order guards -> John -> ship -> crew (provisional performance
     choice; any order gives the same layouts).
  D5 Clues checked as soon as their tokens are placed; "next to grass" clues
     (4, 6 kinds) checked only when placement is complete. Soundness: only
     partial layouts already violating a clue are dropped.
  D6 Clues as data over a reusable relation set: same-row, same-column,
     vertically-adjacent, diagonally-adjacent, fixed-cell, plus negations
     and "one of / both" quantification as needed.
  D7 Route state = John's cell + visited set; crew collection derived from
     visited set. Merge identical (cell, visited) states: same futures, same
     depth -> sound for shortest route.
  D8 Route move: to unvisited, non-guard neighbour; ship only after all crew.
  D9 Dead-end cut: drop a partial route when an uncollected crew cell or the
     ship is unreachable through unvisited non-guard cells (sound
     impossibility test). Value on larger grids: deferred measurement.
  D10 Lower bound: max over uncollected crew c of
     kingdist(John,c) + kingdist(c,ship); with none left, kingdist(John,ship).
     Admissible. Benefit: deferred measurement.
  D11 Algorithm (revised 2026-10-11, see CORRECTIONS): backtracking for
     placement, depth-first graph for the route, switching algorithm between
     the two runs. Premises: placement has no repeated states and is the
     exhaustive phase, so backtracking's cheap in-place choice/undo suits it;
     the route needs graph merging (D7), available only in depth-first
     (backtracking forces tree, ww-initialize.lisp init). Handoff across the
     reload: save the layout as a symbolic fact list,
       (list-database (problem-state.idb (solution.goal (first *solution-paths*))))
     (ww-structures.lisp list-database), in a defvar declared in the spec
     (defvar keeps its value on reload); then (ww-set *algorithm* depth-first)
     (reloads), set graph + min-length, and (solve-subgoal <fact list> <route
     goal>) (ww-goal-chaining.lisp make-start-state-from-facts checks each
     fact). Do not carry the problem-state itself across the reload: idb keys
     are integer codes (convert-to-proposition) rebuilt at load.
     BT uniqueness: record-solution-bt maintains *unique-solution-states*
     (ww-backtracker.lisp); the parallel registration path was not inspected.
     Alternative: depth-first for both (one algorithm, no reload). Reconsider
     if placement cost is negligible relative to the route.
  Agreement: D1-D11 agreed by user 2026-10-11.

WOULDWORK MAPPING (source-checked 2026-10-11)
  Both phases in one spec, problem-type PLANNING, algorithm depth-first;
  a phase fluent gates placement actions vs move actions.  [S]
  D1 handoff: run placement with *solution-type* EVERY under backtracking
    (tree); save the layout as a fact list; switch to depth-first; then
    (solve-subgoal <fact list> <route goal>) with *solution-type* MIN-LENGTH,
    *tree-or-graph* graph (details in D11).  [B]
    - ww-goal-chaining.lisp solve-subgoal / solve-subgoal-from-form: two-arg
      form is a one-off search from a problem-state, "serial or parallel".
    - Placement goal state: solution.goal of the single entry in
      *solution-paths* (ww-structures.lisp, solution struct).
    - Chained (one-arg) goal chaining requires *threads* 0
      (validate-continuation-preconditions); not recommended here.
    - ww-set *solution-type* and *tree-or-graph* change without reload
      (ww-set.lisp); ww-set *problem-type* and *algorithm* reload the
      system; keep PLANNING for both phases; the *algorithm* reload is
      bridged by the saved fact list (D11).
  Uniqueness check: *unique-solution-states* (ww-searcher.lisp
    register-solution) holds distinct goal states; length must be 1.  [B]
    COUNT mode does not populate *solution-paths*, so EVERY is required.
  CSP problem-type not recommended: generate-children (ww-planner.lisp)
    schedules action N at depth N, so the spec would need one action per
    token - does not scale with token counts.  Use a single generic place
    action selecting the next token kind by a "next to place" fluent.  [S]
  D5/D6 clues: preconditions of the place action and the placement goal;
    relations as defined queries over cell coordinates.  [S]
  D7 merging: graph mode closed table (ww-searcher.lisp *closed*). [B]
  D9: prune-state? hook (ww-planner.lisp expand).  [B hook + S logic]
  D10: min-steps-remaining? hook (ww-searcher.lisp
    min-steps-remaining-prunes-node-p).  [B hook + S formula]
  Evidence status: source-read only; no runtime checks.

INITIAL SETTINGS AND DEFERRED MEASUREMENTS
  Semantic: placement EVERY (exhaustive); route MIN-LENGTH.
  Depth cutoffs: user supplies; placement depth = number of placed tokens.
  Parallel: (ww-set *threads* 16) proposed for both runs; solve-subgoal
    two-arg form supports it. No known incompatibility (no happenings,
    no chaining, no ALL-PATHS). Parallel EVERY/graph behaviour unmeasured.
  Deferred: placement order (D4); value of D9 and D10 on larger grids.

EVIDENCE
  Intended rules: user dialogue 2026-10-11.
  Source behaviour: files/symbols above, read 2026-10-11.
  Deductions: soundness of D3, D5, D7-D10 (arguments above).
  Measurements: none.

OPEN ISSUES AND CAPABILITY GAPS
  - "passing" interpretation tentative (non-blocking; affects D8 only).
  - Parallel BT solution registration path not inspected for
    *unique-solution-states* (spec advisor: confirm before relying on the
    16-thread uniqueness check).
  - Deferred to search advisor: placement order (D4); benefit of D9, D10;
    graph memory on larger grids.
  No analysis blockers. No capability gaps identified.

VALIDATION PLAN (for spec advisor)
  - Placement yields exactly one layout on this instance; a deliberately
    weakened clue set yields >1 and triggers the flag.
  - Swapping the two guards does not produce a second layout.
  - Route: compare MIN-LENGTH result with/without D9, D10 (same length).
  - Instance family: 4x4, 5x5 with proportionally more crew/guards.

AGREEMENT AND HANDOFF
  Status: Analysis complete and ready for the spec advisor (2026-10-11).
  Covered scope: both phases, larger-instance family (same clue kinds).
  Spec obligations:
    - One planning spec; phase fluent gates a generic place action vs a
      move action; grid size, token counts and clue list as data.
    - Place action: next-token-kind fluent; identical tokens in increasing
      cell order; fixed-grass cells excluded; clues tested as soon as their
      tokens are placed; next-to-grass clues in the placement goal.
    - Placement goal: all tokens placed and all clues hold.
    - Route: state = John cell + visited set; move to unvisited non-guard
      neighbour (8 directions); ship only after all crew visited; goal =
      John on ship with all crew cells visited.
    - Hooks: prune-state? dead-end test (D9); min-steps-remaining? bound (D10).
    - Defvar holding the saved layout fact list; documented REPL sequence:
      backtracking + EVERY placement -> uniqueness check -> save facts ->
      (ww-set *algorithm* depth-first) -> graph + MIN-LENGTH ->
      (solve-subgoal <facts> <route goal>).
  Acceptance criteria: see VALIDATION PLAN.
  Snapshot: deleted at the spec advisor's wrap-up (2026-10-12).
  Next step (not yet authorized): spec advisor writes the spec, or
  comparison with any existing captjohn spec.

DIALOGUE EVALUATION
  Friction: none notable; user preferred designing for larger family from
  the start (now explicit in problem description).

CORRECTIONS
  2026-10-11 Superseded D11 "depth-first for both phases". Premise "both
  phases must share one algorithm because the reload discards the placement
  result" was too strong: the result can be saved as a symbolic fact list in
  a defvar and replayed after the reload (user suggestion). Reopened: D11
  only; D1-D10 unaffected.
