feat: add single app deployment packaging

Author: Pluze

CHANGELOG.md

@@ -19,6 +19,35 @@ maintainer intent and user impact that are easy to lose in commit subjects.
 
 ## Unreleased
 
+### Pending - Single app deployment packages
+
+Affected versions:
+- `labkit_launcher` `1.2.5 -> 1.2.6`
+
+What changed:
+- Added launcher actions and a deployment tool that package one selected LabKit
+  app into a standalone zip, either as source `.m` files or encoded `.p` files.
+- The generated package includes the selected app and its assets, `+labkit/`,
+  `labkit_launcher.m`, the launcher-needed deployment/profiling tool folders,
+  a manifest, and a direct `run_<app_command>.m` entry file.
+- Private apps can be packaged from `private_apps/apps/` or
+  `LABKIT_PRIVATE_APP_ROOTS`; inside the zip they remain under
+  `private_apps/apps/...`.
+
+Why it matters:
+- A single lab workflow can be distributed into a fixed production or offline
+  deployment step without shipping unrelated apps, tests, docs, or repository
+  metadata.
+
+Compatibility:
+- Full LabKit checkout installs are unchanged.
+- Single-app packages can start through either the packaged launcher or the
+  direct run file; P-code packages require MATLAB to run the generated `.p`
+  files.
+
+Evidence:
+- Pending commit.
+
 ### Pending - Private app workspace discovery
 
 Affected versions:
@@ -72,7 +101,7 @@ Audited against `main` UI 5 squash commit on 2026-07-06.
 
 | Component | Current version | Family | Metadata location |
 |---|---:|---|---|
-| `labkit_launcher` | `1.2.5` | Launcher | `labkit_launcher.m` |
+| `labkit_launcher` | `1.2.6` | Launcher | `labkit_launcher.m` |
 | `labkit.ui` | `5.0.0` | Facade | `+labkit/+ui/version.m` |
 | `labkit.dta` | `2.0.0` | Facade | `+labkit/+dta/version.m` |
 | `labkit.image` | `1.1.0` | Facade | `+labkit/+image/version.m` |

docs/apps.md

@@ -45,6 +45,16 @@ artifacts under `artifacts/`.
 The Code Analyzer action writes a native `codeIssues` JSON export to
 `artifacts/code-check/matlab_code_issues.json` for manual maintenance review.
 
+The `Package App` launcher action creates a single-app source zip under
+`artifacts/deployment/`. `Package P-code` creates the same standalone package
+shape with MATLAB code encoded as `.p` files instead of source `.m` files. The
+zip expands to a standalone directory containing the selected app folder and
+its assets, `+labkit/`, the launcher, the launcher-needed deployment/profiling
+tool folders, a `packaged_app_manifest.json`, and a direct
+`run_<app_command>` entry file. Users can run either the direct entry file or
+`labkit_launcher` from the unzipped folder. The package intentionally omits
+unrelated public apps, tests, docs, CI files, and source-checkout metadata.
+
 The launcher sets up the app path before opening an app. App-owned packages are
 reached through their owning app entrypoint and package namespace.
 

docs/architecture.md

@@ -11,7 +11,7 @@ apps/      workflow-specific GUI apps and app-owned helpers
 tests/     behavior tests, project contracts, GUI checks, shared helpers, and runner code
 docs/      human-facing usage, API, architecture, and validation docs
 scripts/   CI helper scripts
-tools/     maintainer-only MATLAB diagnostics and report generators
+tools/     maintainer diagnostics, deployment packagers, and report generators
 ```
 
 Apps should remain independently launchable. The reusable library should grow
@@ -41,15 +41,17 @@ rather than mixing private app files into the public repo history. The public
 structure guide is [private-apps.md](private-apps.md); private app
 documentation belongs in the private workspace.
 
-The launcher is intentionally self-contained: it uses native MATLAB UI and
-local helper functions so users can repair a damaged zip install even if
-packages, apps, docs, or scripts have been deleted. It configures the MATLAB
-path for app entry points. MATLAB desktop project metadata belongs to each
-developer's local workspace.
-
-Tools under `tools/` are source-checkout maintainer diagnostics. They are not
-runtime entry points for launcher users and are not dependencies of
-`labkit_launcher.m`.
+The launcher keeps update, discovery, and repair logic self-contained: it uses
+native MATLAB UI and local helper functions so users can repair a damaged zip
+install even if packages, apps, docs, or scripts have been deleted. It
+configures the MATLAB path for app entry points. MATLAB desktop project
+metadata belongs to each developer's local workspace.
+
+Tools under `tools/` are source-checkout support utilities rather than app
+runtime APIs. The launcher may call a small, explicit subset for maintenance
+and deployment actions, such as profiling a selected app or packaging a single
+app for offline deployment. Single-app deployment packages include the launcher
+and only those launcher-needed tool folders, not the whole source checkout.
 
 ## Ownership Boundaries
 

docs/private-apps.md

@@ -49,6 +49,14 @@ Private entries appear in the app catalog with `Visibility` set to `private`.
 They launch like ordinary LabKit apps after the launcher adds the app folder to
 the MATLAB path.
 
+The launcher can also package a selected private app for offline deployment as
+either source `.m` files or encoded `.p` files. The generated zip preserves the
+private app under `private_apps/apps/...` and includes the packaged launcher
+plus the deployment/profiling tool folders it uses. Private apps discovered
+through `LABKIT_PRIVATE_APP_ROOTS` are copied into that same
+`private_apps/apps/...` package shape so the zip does not depend on the source
+machine's environment variable or private workspace path.
+
 ## Git Ownership
 
 Keep `private_apps/` as a separate private Git repository:
@@ -90,3 +98,12 @@ assumptions into `+labkit`.
 The public repository should contain only this generic private-app structure
 guide. Put private app catalogs, SOPs, validation commands, sample notes,
 deployment notes, and release history in the private app repository.
+
+Private app repositories own their own tests and validation runners. They do
+not need to add app-specific suites, fixtures, build tasks, or sample assets to
+the public LabKit repository. Private app internals may be looser than public
+apps when a local workflow needs it, but the launcher-facing surface should
+remain compatible with LabKit discovery and guardrails: keep launch commands,
+`requirements` and `version` lightweight requests, path setup, and private
+sample hygiene valid when the private workspace is present next to a public
+checkout.