PPN 4C: top-level form processing on-network — retire `process-command` sequential orchestrator

[hierophantos]

Summary

The PPN 4C charter (D.3 §1, audit §1) commits to bringing elaboration completely on-network with "no sequential orchestrators alongside the BSP scheduler." The addendum's Phase 2 (orchestration unification, supersedes parent §6.7) delivers the in-form orchestrator retirements but does NOT address the between-form orchestrator (process-command in driver.rkt).

This gap is the structural fix path for mutual recursion and other top-level form ordering concerns currently scaffolded via imperative pre-passes (#14).

This issue tracks the gap as a future sub-phase of the addendum (docs/tracking/2026-04-21_PPN_4C_PHASE_9_DESIGN.md), to be designed when the current Phase 1 (tropical fuel) and Phase 2 (in-form strata) close.

The orchestrator landscape

Orchestrator	Location	Layer	Status in PPN 4C
S(-1) retraction	metavar-store.rkt:1336	In-form	✅ Phase 2 retires
L1 readiness	metavar-store.rkt:904	In-form	✅ Phase 2 retires
L2 resolution	metavar-store.rkt:984	In-form	✅ Phase 2 retires
run-stratified-resolution-pure	metavar-store.rkt:1915	In-form	✅ Phase 2 retires
run-stratified-resolution! (dead)	metavar-store.rkt:1863	In-form	✅ Phase 2 retires
process-command loop	driver.rkt	Between-form	GAP — this issue

The thesis covers all sequential orchestrators conceptually; the explicit phase breakdown delivers strictly less.

Motivating use case (PR #14, pitfall #4)

Mutual recursion between top-level defns currently fails:

spec even? Nat -> Bool
defn even?
  | zero  -> true
  | suc n -> [odd? n]    ;; Unbound: odd? not yet in env (process-command sequential)
spec odd? Nat -> Bool
defn odd?
  | zero  -> false
  | suc n -> [even? n]

#14 patches this with a pre-register-defn-types! pass — a topology-phase scaffolded onto the sequential model with three call sites, defensive error handlers, and reliance on the legacy parameter path (Layer 2 fallback). Per the review on #14, this is exactly the "imperative bridge / sequential orchestrator" pattern PPN 4C exists to retire.

The structural fix is process-command becoming BSP-orchestrated. Top-level forms enter a topology phase where names register into cells; bodies elaborate when their dependencies are visible; mutual recursion falls out of cell architecture (no order needed).

Why the gap exists

process-command predates the orchestrator-retirement framing in the audit. When Phases 9, 10, 11 (now addendum Phases 1, 2, 3) were enumerated, the focus was on in-form strata that were the active source of pain. The between-form loop wasn't surfaced.

This is a real gap, not a deliberate deferral — addendum §1.3 (Out of scope) doesn't currently mention process-command either.

Scope (when designed)

When this sub-phase is designed, it will likely cover:

• Audit process-command and its three callers (process-string-inner, process-surfs, process-file-inner)
• Identify per-form-type behavior (def, defn, ns, use, require, type, instance, ...) — each becomes a propagator or BSP stratum handler
• Decide topology-phase shape (cell-write of names + types before any body elaborates, vs. propagator-driven readiness)
• Coordinate with PM Track 12 (parameter → cell migration) for env state
• Coordinate with PM Track 10 (module loading on network) for cross-module visibility
• Define BSP scheduler integration (register-stratum-handler approach, similar to addendum Phase 2)
• Parity test: every existing process-string / process-file test must produce identical results
• Acceptance: mutual recursion repro from Pre-register top-level defn types for mutual recursion (eigentrust pitfall #4) #14 works without the pre-pass scaffolding

Slot proposal

Add as a new sub-phase to the addendum (2026-04-21_PPN_4C_PHASE_9_DESIGN.md):

• Phase 4 — Top-level orchestration unification (or Phase 2b if framed as sibling to Phase 2's in-form retirement)

Specific slot points:

• §1.2 Phase scope — add Phase 4 description
• §3 Progress Tracker — add Phase 4 row, status ⬜, references this issue
• §1.3 Out of scope — note that detailed design is deferred to phase-time mini-design (matches the precedent of other addendum phases)
• §4 NTT Model — optionally add §4.4 "Top-level orchestration post-unification (Phase 4 delivery)" when designed

Designed when current Phase 1 (tropical fuel) and Phase 2 (in-form strata) close.

Out of scope for this issue

• Detailed design of the sub-phase — happens at phase-time mini-design per addendum methodology
• Implementation timing — gates on PPN 4C Phase 1, Phase 2, possibly Phase 3
• PR Pre-register top-level defn types for mutual recursion (eigentrust pitfall #4) #14's specific revision shape — kumavis chooses; if structural fix lands first, Pre-register top-level defn types for mutual recursion (eigentrust pitfall #4) #14's pre-pass scaffolding can be retired entirely

References

• Parent design: docs/tracking/2026-04-17_PPN_TRACK4C_DESIGN.md (PPN 4C D.3) — thesis statement audit §1
• Addendum (active): docs/tracking/2026-04-21_PPN_4C_PHASE_9_DESIGN.md — Phase 9+10+11 supersession, §1.4
• Tropical addendum (current work): docs/tracking/2026-04-26_PPN_4C_TROPICAL_QUANTALE_ADDENDUM_DESIGN.md
• Audit: docs/tracking/2026-04-17_PPN_TRACK4C_AUDIT.md — thesis "no sequential orchestrators"
• Motivating use case: PR Pre-register top-level defn types for mutual recursion (eigentrust pitfall #4) #14 (mutual recursion via pre-pass scaffolding)
• Contributor tracking: Tracking issue for "eigentrust pitfall doc" PRs #19 (kumavis's pitfall PR tracking, lists Pre-register top-level defn types for mutual recursion (eigentrust pitfall #4) #14 as "pending revisit after elaboration refactor")
• Related cleanup work: Improved implicit inference: implement Directions 1 + 2 (both, additive) from the 2026-02-22 design #20 (improved implicit inference), Document the four working WS-mode let binding variants #21 (let variants documentation)