# Architecture summary

## Project architecture

```text
All_Serv_InstallUpdater.exe (independent repository / updater)
  -> starts local All_Serv_Install.exe

All_Serv_Install.exe (independent repository / visible installer and synchronizer)
  -> starts configured P_Serv_Starter.exe

P_Serv_Starter.exe (separate repository / Plant bootstrap)
  -> generates local _app_netload.lsp
  -> copies launcher_starter.lsp
  -> starts configured local start_plant_3d.bat

All_Serv_Load.exe (independent repository)
  -> separate historical/alternate loader; no source dependency edge to the above
```

There are no ProjectReference edges between the three projects beneath `C:\dev\launcher\git`; each is its own one-project solution. `P_Serv_Starter` is a fourth independent repository selected by configuration, not a project reference. This explains why a user can experience one product despite multiple executables: the updater can hand off to the visible installer, which synchronizes selected applications and delegates Plant startup to a hidden bootstrap. Actual deployed shortcut/entrypoint evidence was not present, so the updater's use in a specific installation remains `INFERRED`.

## Roles and status

| Project | Output | Role | Status | Evidence |
|---|---|---|---|---|
| All_Serv_Install | WinExe | visible catalog UI, synchronizer and configured process launcher | ACTIVE_PRIMARY | Form1 startup and copy/Process.Start code |
| All_Serv_InstallUpdater | WinExe | installer self-updater then handoff | ACTIVE_UPDATER | Form1_Load MD5/copy/start code |
| All_Serv_Load | WinExe | independent alternate/historical loader | UNKNOWN | independent Form1 and 2019 batch script; no current deployment proof |
| P_Serv_Starter | Exe | Plant session bootstrap | ACTIVE_BOOTSTRAP | selected in installer XML; writes loader and starts batch |

## Runtime chain

The confirmed chain ends at execution of the local Plant start batch. The gap between that batch and `launcher_starter.lsp` automatic loading is `UNKNOWN`: no local batch, `acaddoc.lsp`, or Applications files were found. Once `launcher_starter.lsp` runs, all following load steps are source-confirmed.

## Answers to the requested questions

1. The three launcher projects are independent WinForms executables: installer, updater and alternate loader.
2. `All_Serv_Install` creates the confirmed visible catalog UI.
3. Three EXE artifacts are declared by the launcher repositories; P_Serv_Starter adds one external bootstrap EXE.
4. No launcher project is a class library; `launcher_starter.lsp` is a copied runtime content artifact.
5. Updater/helper/bootstrap behavior is confirmed in source; actual installed-process count is unknown.
6. Plant launch is delegated by `All_Serv_Install` to configured `P_Serv_Starter.exe`; the bootstrap starts a local batch. A current Plant executable/profile/argument string is not proven.
7. `app_netload.lsp` and `OrthoLoader.dll` are connected through P_Serv_Starter generated LISP and installer plugin metadata.
8. The installer synchronizes corporate application folders to a local Applications cache; it does not load P_Rec_Annot directly.
9. No source proof warrants modifying LAUNCHER for the new plugin yet. First validate one local entry assembly through the established catalog/bootstrap contract in a non-production pilot.