fix: include prompt assets in standalone output

.project-docs/30-worklog/tasks/20260818-learning-lockfile-9d2a.md

@@ -12,18 +12,21 @@
 
 ## Scope
 
-- Regenerate `OpenMAIC/pnpm-lock.yaml` from the current workspace manifests so
+- Synchronize `OpenMAIC/pnpm-lock.yaml` with the current workspace manifests so
   `packages/@makelore/learning-contracts` is represented and Docker's frozen
   install can pass.
-- Verify the regenerated lockfile with pnpm `10.28.0` and the same frozen
-  install command used by the Dockerfile.
-- Do not change application code or weaken the Dockerfile's frozen-lockfile
-  policy.
+- Make the CPU ACK image resilient to `onnxruntime-node`'s unnecessary CUDA
+  postinstall download while keeping the frozen-lockfile policy.
+- Verify the lockfile and the supported CPU install-script path with pnpm
+  `10.28.0` and the repository's pinned Node runtime.
 
 ## Intent And Constraints
 
-- The current failure is a dependency metadata mismatch: the learning
-  contracts package was added after the lockfile was last generated.
+- The first failure was a dependency metadata mismatch: the learning contracts
+  package was added after the lockfile was last generated.
+- The follow-up failure is an `onnxruntime-node@1.23.2` postinstall request for
+  CUDA 12 metadata; the Jenkins proxy returned HTTP 302 while the script only
+  accepts HTTP 200.
 - Use the package-manager version pinned by the Dockerfile (`pnpm@10.28.0`)
   when regenerating the lockfile.
 - Preserve the user's known `.project-docs/` adoption and avoid unrelated
@@ -37,6 +40,9 @@
 - The original Dockerfile policy remains `pnpm install --frozen-lockfile`.
 - Committed locally on `main` as `e1a0a14` (`fix: sync learning contracts
   lockfile`).
+- Updated `OpenMAIC/Dockerfile` to set `ONNXRUNTIME_NODE_INSTALL=skip` in the
+  dependency stage. The package's CPU runtime remains bundled; CUDA download is
+  now an explicit opt-in and requires a CUDA-capable runner image.
 
 ## Verification
 
@@ -46,15 +52,19 @@
 - Read-only final review returned `PASS`; the importer matches the manifest and
   existing lockfile peer snapshot, with no Dockerfile or application-code
   changes.
+- The `onnxruntime-node` install script exited 0 with
+  `ONNXRUNTIME_NODE_INSTALL=skip`; bundled Windows and Linux CPU binding files
+  were present.
 - Full Windows `pnpm install --frozen-lockfile` reached the existing postinstall
   chain and failed because `rm` is unavailable on Windows; the Dockerfile runs
   this chain inside Linux Alpine, so this is not the reported Jenkins failure.
-- Local Docker `deps` validation was not run because the Docker Desktop Linux
-  engine was unavailable (`dockerDesktopLinuxEngine` pipe missing).
+- Local Docker `deps` validation remains unavailable because the Docker Desktop
+  Linux engine is not running (`dockerDesktopLinuxEngine` pipe missing).
 
 ## Follow-ups
 
-- Commit and push `OpenMAIC/pnpm-lock.yaml`, then rerun the Jenkins Docker build.
+- Commit and push the lockfile and Dockerfile changes, then rerun the Jenkins
+  Docker build.
 - Local push to `origin/main` was blocked because this environment has no
   authenticated Git credential/TTY; rerun `git push origin main` from an
   authenticated terminal.
@@ -64,6 +74,18 @@
   untracked `.project-docs/` template tree; no task-specific shared-doc writes
   were made.
 
+## Follow-up: ONNX Runtime postinstall
+
+- The Linux Docker build reached `onnxruntime-node@1.23.2` postinstall, which
+  assumed CUDA 12 and rejected an HTTP 302 from the NuGet feed.
+- `OpenMAIC/Dockerfile` now defaults `ONNXRUNTIME_NODE_INSTALL=skip` in the
+  dependency stage. The package ships the CPU runtime; GPU builds can opt in
+  with `--build-arg ONNXRUNTIME_NODE_INSTALL=cuda12` after fixing NuGet access.
+- The install script exited 0 with `ONNXRUNTIME_NODE_INSTALL=skip` locally and
+  both bundled CPU runtime paths were present.
+- The CUDA override was not exercised end to end. Use it only with a working
+  NuGet/proxy path and a runner image that supplies the CUDA runtime.
+
 ## Promotion Candidates
 
 - None recorded.

.project-docs/30-worklog/tasks/20260818-next-build-7f3a.md

@@ -0,0 +1,94 @@
+# Task: Diagnose Next.js production image build failure
+
+## Identity
+
+- Task ID: 20260818-next-build-7f3a
+- Mode: Feature
+- Branch: main
+- Worktree: D:\Datas\OthersProjects\openmaic
+- Base commit: a76c8d2613c6ab6e0c661fbfd574803c2b09fc44
+- Owner: developer
+- Status: Ready for integration
+
+## Scope
+
+- Diagnose the Jenkins/Docker failure at `OpenMAIC/Dockerfile:64` (`RUN pnpm build`).
+- Reproduce the repository's production webpack build where the local environment permits,
+  and distinguish a source/build regression from a runner resource or timeout failure.
+- Do not change application or Docker build behavior without the missing Jenkins/Docker
+  termination evidence.
+
+## Intent And Constraints
+
+- The supplied log stops after `Creating an optimized production build ...` and only shows
+  a bare `ELIFECYCLE Command failed`; it does not contain the terminating signal or compiler
+  diagnostic.
+- The repository's `pnpm build` first requires the generated
+  `public/vendor/maic-importer/index.js`; the Docker dependency stage normally creates it via
+  postinstall, so a missing local copy must not be confused with the reported Docker failure.
+- Preserve the clean source worktree; generated package dist files and `.next` output are
+  diagnostic artifacts only.
+
+## Outcome
+
+- The local Windows `pnpm build` initially stopped at the expected vendor guard because the
+  ignored postinstall artifact was absent. After generating ignored workspace dist outputs and
+  syncing the vendor bundle, the equivalent direct Next command completed successfully:
+  `node --max-old-space-size=8192 node_modules/next/dist/bin/next build --webpack`.
+- The successful build compiled webpack in about 4.8 minutes, used roughly 5.7 GB working set
+  at peak sampling, then finished TypeScript, 56 static pages, traces, and standalone output.
+- A second direct build with a 4096 MB V8 heap also completed successfully, but webpack took
+  about 5.4 minutes and the process used roughly 3.8–4.1 GB working set.
+- The generated Next trace from the successful run records `run-webpack` at 326.806 seconds
+  and total `next-build` at 397.158 seconds; the trace and generated outputs were removed after
+  verification because they are ignored build artifacts.
+- The middleware deprecation warning appeared in both successful builds and is not the failure.
+- A subsequent Jenkins run again stopped at `#22 308.2` immediately after
+  `Creating an optimized production build ...`, with the same bare `ELIFECYCLE` and no
+  compiler/OOM diagnostic. The repeatable ~5-minute cutoff strengthens the external build-step
+  timeout hypothesis; it still does not identify the signal without Jenkins/Docker metadata.
+- The evidence is consistent with a Jenkins/Docker memory ceiling or build-step timeout killing
+  webpack before it emits a compiler error. The exact external cause remains unverified because
+  the Docker daemon and Jenkins host logs are unavailable in this workspace.
+- The build script in `OpenMAIC/package.json` now caps the V8 heap at 4096 MB instead of
+  8192 MB. This is a mitigation for the observed host-level memory pressure, not proof that
+  the external 5-minute termination was the sole cause.
+
+## Verification
+
+- `check_project_docs.py` passed.
+- `task_context.py status --json` confirmed this task owns the clean main worktree.
+- Direct Next webpack build with 8192 MB heap: passed, full route output and exit code 0.
+- Direct Next webpack build with 4096 MB heap: passed, full route output and exit code 0.
+- Read-only final diagnosis review: PASS; the reviewer agrees the evidence supports an
+  external timeout/resource termination hypothesis but cannot distinguish timeout from OOM.
+- `git status --short --untracked-files=all`: only this task record remains untracked; temporary
+  generated source changes were restored.
+- Docker daemon/engine is unavailable locally, so an end-to-end image build was not reproduced.
+- Follow-up Jenkins log: same failure signature at approximately 308 seconds.
+- The later diagnostic-script run ended with `ERROR: failed to solve: Canceled: context canceled`
+  and script exit code `124`; this is the script's own `timeout 900s`, not a compiler exit.
+  Its cgroup reported an effectively unlimited `memory.max` and `oom_kill 0`. The kernel output
+  contained a historical BuildKit Node OOM at 21:46:05 (about 6.3 GiB RSS), which proves the
+  7.3 GiB host has previously exhausted memory but is not timestamped to the 22:38 run.
+- `OpenMAIC/package.json` parses successfully after the heap-cap change; `git diff --check`
+  reports no whitespace errors.
+- Read-only implementation review: PASS; the reviewer found the one-line heap reduction and
+  proposed Jenkins observability/timeout wrapper consistent with the available evidence.
+
+## Follow-ups
+
+- Re-run Jenkins with untruncated output (`docker build --progress=plain`) and capture the final
+  30 lines plus the shell/Docker exit code.
+- Check the build node/container memory limit (`/sys/fs/cgroup/memory.max`, `docker stats`, or
+  Jenkins host metrics) and whether the job has a five-minute command timeout. The repeated
+  ~308-second cutoff makes that timeout the first check. Budget at least
+  6–8 GiB for this webpack build and a timeout above the observed ~6-minute end-to-end duration.
+- Run the updated Jenkins command with `--progress=plain`, a 900-second per-image timeout, and
+  failure diagnostics for cgroup memory and kernel OOM evidence. Jenkins' own job timeout must
+  also exceed 15 minutes; a shell-level timeout cannot override a shorter Pipeline/plugin limit.
+
+## Promotion Candidates
+
+- None. This investigation does not establish a source or Docker configuration change without
+  the external termination signal.

.project-docs/30-worklog/tasks/20260818-onnx-cuda-postinstall-a7c4.md

@@ -0,0 +1,58 @@
+# Task: Stabilize ONNX Runtime Docker install
+
+## Identity
+
+- Task ID: 20260818-onnx-cuda-postinstall-a7c4
+- Mode: Feature
+- Branch: main
+- Worktree: D:\Datas\OthersProjects\openmaic
+- Base commit: 22dd55625fa5f855c6aa733ab6dd52bf2b878c96
+- Owner: developer
+- Status: Ready for integration
+
+## Scope
+
+- Record and verify the CPU ACK Docker fix for the `onnxruntime-node`
+  postinstall failure reported by Jenkins.
+- Keep CUDA provider download opt-in; do not claim a GPU image is supported
+  without a CUDA-capable runner and a verified NuGet/proxy path.
+
+## Intent And Constraints
+
+- Linux/x64 `onnxruntime-node@1.23.2` assumes CUDA 12 when no install mode is
+  provided and rejects the Jenkins proxy's HTTP 302 response from NuGet.
+- The CPU runtime and binding are bundled in the npm package, so the ACK image
+  should skip the unnecessary CUDA provider download.
+- Preserve `pnpm install --frozen-lockfile`; avoid unrelated application changes.
+
+## Outcome
+
+- `OpenMAIC/Dockerfile` in base commit `22dd556` sets
+  `ONNXRUNTIME_NODE_INSTALL=skip` before the dependency-stage install.
+- CUDA installation remains an explicit `cuda12` build-arg override and is
+  documented as requiring a CUDA-capable runner; it is outside this acceptance
+  scope.
+- The lockfile correction is in `e1a0a14`, and the adopted `.project-docs/` tree
+  is tracked in `469f72b`.
+
+## Verification
+
+- The upstream install script exited 0 with `ONNXRUNTIME_NODE_INSTALL=skip`.
+- Bundled Linux and Windows CPU runtime binding files were present.
+- `git diff --check` passed.
+- `check_project_docs.py` passed.
+- Local Linux Docker validation is unavailable because the Docker Desktop Linux
+  engine pipe is not running; Jenkins must perform the end-to-end build.
+- Final read-only reviewer returned `PASS`.
+
+## Follow-ups
+
+- Push `e1a0a14`, `469f72b`, and `22dd556` from an authenticated terminal, then
+  rerun the Jenkins CPU image build.
+- If GPU deployment is required, provide a CUDA-capable runner image and verify
+  the `ONNXRUNTIME_NODE_INSTALL=cuda12` path against the organization's NuGet
+  proxy before enabling it.
+
+## Promotion Candidates
+
+- None recorded.

.project-docs/30-worklog/tasks/20260819-openmaic-prompt-template-8b4d.md

@@ -0,0 +1,56 @@
+# Task: Diagnose missing interactive outline prompt template
+
+## Identity
+
+- Task ID: 20260819-openmaic-prompt-template-8b4d
+- Mode: Feature
+- Branch: codex/20260819-openmaic-prompt-template-8b4d-openmaic-prompt-template
+- Worktree: D:\w\omprompt-8b4d
+- Base commit: 58d1ddc2644f4c8631d62eb0e5423365af95ef66
+- Owner: codex
+- Status: Ready-for-integration
+
+## Scope
+
+- Trace the production error `Interactive outline prompt template not found` from the classroom job runner to its runtime file dependency.
+- Compare the runtime file path with the standalone Docker and learning-artifact packaging configuration.
+- Provide a read-only Kubernetes check, implement the durable standalone packaging fix requested after diagnosis, and add a regression test.
+
+## Intent And Constraints
+
+- The user requested direct analysis without subagents.
+- Preserve the existing dirty main worktree owned by `20260818-next-build-7f3a`; diagnosis ran in this isolated worktree at the same base commit.
+- Distinguish source-level facts from the still-unverified contents of the deployed image.
+- Keep the code change surgical: configure Next.js file tracing rather than duplicating copy rules across the Dockerfile and artifact builder.
+
+## Outcome
+
+- Confirmed that `lib/server/classroom-outline-mode.ts` raises the reported error only when the app prompt loader returns `null` for `interactive-outlines`.
+- Confirmed that the loader reads Markdown dynamically from `<cwd>/lib/prompts/templates/<promptId>` and that both interactive-outline source files exist. Its broad catch also converts snippet-loading failures into the same outer error, while logging the original cause under `PromptLoader`.
+- Confirmed that `interactive-outlines/system.md` includes three package-owned snippets (`image-instructions`, `video-instructions`, and `media-safety-guidelines`) that are dynamically read from `@openmaic/generation`.
+- Confirmed that standalone output is enabled but `next.config.ts` has no `outputFileTracingIncludes`, while both the Docker runner and `build-learning-artifact.mjs` copy only standalone output, static assets, and public assets.
+- Production root cause confirmed: the deployed Pod reports `ENOENT` for `/app/lib/prompts/templates/interactive-outlines/system.md`, and both `system.md` and `user.md` are absent while `cwd` is correctly `/app`. The standalone image omitted the app-owned prompt Markdown.
+- A direct eval import of `@openmaic/generation` from `/app` also returned `ERR_MODULE_NOT_FOUND`. This is not the current first failure because template loading stops at the missing `system.md`; package snippet availability must be verified after the app templates are packaged, preferably through the built application or by inspecting the standalone trace/layout rather than assuming root-level package resolution.
+- Added global standalone file-tracing includes for app-owned prompts, app PBL prompts, and the three package-owned generation prompt directories.
+- Added `tests/config/standalone-prompt-assets.test.ts` to lock the runtime prompt asset contract.
+
+## Verification
+
+- Source template presence check: PASS (`system.md` and `user.md` exist).
+- Packaging contract check: RED by design; source assets exist while neither file tracing includes nor an explicit runner copy is configured.
+- Runtime path inspection: PASS (`WORKDIR /app` plus `process.cwd()/lib/prompts` resolves to `/app/lib/prompts`).
+- Production Pod filesystem check: FAIL as expected; both interactive-outline files are missing from `/app` and the `PromptLoader` log records the exact `ENOENT` path.
+- Targeted Vitest regression: PASS (1 test).
+- ESLint on both changed product/test files: PASS.
+- Prettier check on both changed product/test files: PASS.
+- Learning-engine production build: webpack compilation PASS; final Next.js build FAILS on the pre-existing unrelated missing `@xmldom/xmldom` type declaration in `packages/@openmaic/importer/src/parser/XmlParser.ts`, before standalone output is emitted.
+
+## Follow-ups
+
+- Rebuild the image in an environment with the importer dependency installed, verify the prompt assets in the emitted standalone artifact, deploy, and rerun generation.
+- Verify the package-owned snippets through a generation request; the root-level eval import is not a reliable proxy for bundled route resolution.
+- Audit the other dynamically read app prompt directory `lib/pbl/v2/prompts` as part of the same packaging fix.
+
+## Promotion Candidates
+
+- None recorded.

OpenMAIC/Dockerfile

@@ -9,6 +9,14 @@ WORKDIR /app
 # ---- Stage 2: Dependencies ----
 FROM base AS deps
 
+# The npm package bundles the CPU runtime. Linux/x64 otherwise assumes CUDA 12
+# and downloads CUDA EP packages from NuGet during postinstall; that download
+# is not needed by the CPU ACK images and is fragile behind redirecting proxies.
+# A CUDA build must explicitly pass --build-arg ONNXRUNTIME_NODE_INSTALL=cuda12
+# and use a CUDA-capable runner image; that path is not enabled by default here.
+ARG ONNXRUNTIME_NODE_INSTALL=skip
+ENV ONNXRUNTIME_NODE_INSTALL=$ONNXRUNTIME_NODE_INSTALL
+
 # Native build tools for sharp, @napi-rs/canvas
 RUN apk add --no-cache python3 build-base g++ cairo-dev pango-dev jpeg-dev giflib-dev librsvg-dev
 

OpenMAIC/next.config.ts

@@ -10,6 +10,17 @@ const nextConfig: NextConfig = {
   // default `.next`.
   distDir: process.env.NEXT_DIST_DIR || '.next',
   output: process.env.VERCEL ? undefined : 'standalone',
+  // Prompt loaders read Markdown dynamically at runtime, so Next.js cannot
+  // discover these assets from static imports when producing standalone output.
+  outputFileTracingIncludes: {
+    '/*': [
+      './lib/prompts/**/*.md',
+      './lib/pbl/v2/prompts/**/*.md',
+      './packages/@openmaic/generation/templates/**/*.md',
+      './packages/@openmaic/generation/snippets/**/*.md',
+      './packages/@openmaic/generation/prompts-pbl/**/*.md',
+    ],
+  },
   ...(basePath ? { basePath } : {}),
   env: {
     NEXT_PUBLIC_OPENMAIC_BASE_PATH: basePath,

OpenMAIC/package.json

@@ -12,7 +12,7 @@
     "gen:video-export-katex": "node scripts/generate-video-export-katex.mjs",
     "gen:video-export-noto-cjk": "node scripts/generate-video-export-noto-cjk.mjs",
     "dev": "next dev",
-    "build": "node scripts/assert-vendor-maic-importer.mjs && node --max-old-space-size=8192 node_modules/next/dist/bin/next build --webpack",
+    "build": "node scripts/assert-vendor-maic-importer.mjs && node --max-old-space-size=4096 node_modules/next/dist/bin/next build --webpack",
     "build:learning-engine": "node scripts/build-learning-artifact.mjs engine",
     "build:learning-ops": "node scripts/build-learning-artifact.mjs ops",
     "build:makelore-player": "node scripts/build-learning-artifact.mjs player",

OpenMAIC/tests/config/standalone-prompt-assets.test.ts

@@ -0,0 +1,19 @@
+import { describe, expect, it } from 'vitest';
+
+import nextConfig from '../../next.config';
+
+const runtimePromptGlobs = [
+  './lib/prompts/**/*.md',
+  './lib/pbl/v2/prompts/**/*.md',
+  './packages/@openmaic/generation/templates/**/*.md',
+  './packages/@openmaic/generation/snippets/**/*.md',
+  './packages/@openmaic/generation/prompts-pbl/**/*.md',
+];
+
+describe('standalone prompt assets', () => {
+  it('includes every dynamically loaded prompt directory in output file tracing', () => {
+    expect(nextConfig.outputFileTracingIncludes?.['/*']).toEqual(
+      expect.arrayContaining(runtimePromptGlobs),
+    );
+  });
+});