Compare commits

..
6 Commits
43 changed files with 978 additions and 1 deletions

No files matched your search

@@ -0,0 +1,29 @@
# Project Positioning
## One-line Positioning
This project is {one-line project positioning}.
## Primary Goal
The project exists to {primary project goal}.
## Target Users / Consumers
- {primary user or consumer}
## Non-goals
This project does not aim to {non-goal or boundary}.
## Core Constraints
- {core constraint}
## Quality Bar
A good solution should {quality bar}.
## Last Reviewed
{YYYY-MM-DD}
@@ -0,0 +1,17 @@
# Success Criteria
## Project Success
- {observable project-level success condition}
## Task Completion Standard
- {condition that means a task is complete}
## Quality Checks
- {verification command, review expectation, or acceptance check}
## Last Reviewed
{YYYY-MM-DD}
@@ -0,0 +1,30 @@
# Concurrent Task Gate
Complete this gate before the Planning Gate.
## Invariants
- One active task owns one worktree.
- Concurrent tasks use different branches and worktrees.
- Never stash, reset, move, delete, or adopt unknown work automatically.
- Feature tasks write only their own task record and uniquely named supporting records.
- Keep the active task record present until ownership is released.
- Treat `start`, `touch`, `complete`, and `release` as serialized registry transactions; lock timeout or malformed registry state blocks the gate.
- Feature-task write boundaries in this gate supersede legacy instructions to update shared or canonical project documents.
## Required Output
- Task ID:
- Mode: Feature | Integration
- Branch:
- Worktree:
- Base commit:
- Ownership result: Claimed | Resumed | Isolated | Blocked
- Other active local tasks:
## Block Conditions
- The worktree belongs to another active task and isolation did not succeed.
- An unowned worktree contains staged, unstaged, or untracked changes.
- No reliable committed base was selected for a new worktree.
- The runtime cannot keep later Git and file operations rooted in the isolated worktree.
@@ -0,0 +1,15 @@
# Context Checklist
Before planning, confirm:
- I know the task ID, mode, branch, worktree, base commit, and ownership result.
- I read the active task record and know its scope.
- I know what this project is and what it is not.
- I treat current-state as the last integrated snapshot rather than live concurrent state.
- I checked active decisions and the architecture overview.
- I identified task-specific docs that need deeper reading.
- I inspected other local task records through `task_context.py status --json`.
- I assessed code overlap separately from semantic or decision conflict.
- I reported missing peer records as unknown coordination state.
- I can name unknown, stale, or conflicting information.
- I know which updates remain task-scoped and which require Integration Gate.
@@ -0,0 +1,15 @@
# Integration Gate
Use this gate to promote completed task facts into canonical project memory.
## Requirements
- Run in an exclusively owned integration worktree.
- Hold the repository integration lock.
- Verify the task commits being integrated are present.
- Review source task records, task-prefixed supporting records, promotion candidates, and semantic conflicts in read-only mode.
- Write integration notes only to the integration task's own task record or `{task_id}__<slug>.md` supporting records.
- Ask before changing architecture direction, product behavior, or accepted decisions.
- Record source task or merge commits under `Integrated Through` in `current-state.md`.
Do not resolve meaningful document conflicts with `ours`, `theirs`, or union merge rules.
@@ -0,0 +1,23 @@
# Memory Index
Use this as the high-density entry point after the Concurrent Task Gate establishes task identity and worktree ownership.
## Startup Set
- Active task: `.project-docs/30-worklog/tasks/{task_id}.md`
- Project identity: `.project-docs/00-brief/project-positioning.md`
- Integrated state: `.project-docs/30-worklog/current-state.md`
- Decision list: `.project-docs/10-decisions/decision-index.md`
- System shape: `.project-docs/20-architecture/system-overview.md`
## Recall Pointers
- Evidence-heavy bugs, experiments, investigations: `.project-docs/50-evidence/evidence-index.md`
- Workflow lessons and repeated agent mistakes: `.project-docs/60-reflection/reflection-index.md`
- Pending promises, loops, timed follow-ups: `.project-docs/80-commitments/commitments.md`
- Integrated stale items: `.project-docs/90-maintenance/stale-items.md`
- Task-scoped conflicts: `.project-docs/90-maintenance/conflicts/{task_id}__<slug>.md`
## Loading Rule
Keep this file short. Add shared pointers only during Integration Gate. Feature tasks keep their working context and promotion candidates in their own task record.
@@ -0,0 +1,66 @@
# Planning Gate
A coding agent must complete this gate after the Concurrent Task Gate and before writing an implementation plan.
## Peer Scope Check
Run `task_context.py status --json`. For each other owner, read only the peer task record at `Path(owner.worktree) / owner.task_record`. Use its `Scope`, `Intent And Constraints`, and `Promotion Candidates` sections to assess overlap.
Do not inspect or modify arbitrary uncommitted files in another task's worktree. Report a missing or unreadable peer record as unknown coordination state; do not silently treat it as no overlap. Code-path overlap alone is a warning. Block when semantic decisions conflict or unresolved overlap could change the plan.
## Required Output
```md
## Project Context Loaded
Task context:
- Task ID:
- Mode:
- Branch:
- Worktree:
- Base commit:
- Other active local tasks:
- Overlap or semantic-conflict assessment:
Read:
- {file path}
Relevant understanding:
- Project goal:
- Current integrated focus:
- Active task scope:
- Active constraints:
- Decisions affecting this task:
- Evidence, reflections, or commitments affecting this task:
- Files or modules likely involved:
- Unknowns, stale docs, or conflicts:
Gate result:
- Passed or Blocked
```
## Pass Criteria
The gate passes only when:
- task identity and worktree ownership are resolved
- the active task record exists and matches the owner task ID
- required documents were read
- task-relevant decisions were checked
- relevant evidence, reflection, and commitment indexes were checked when applicable
- other active local task scopes were assessed
- stale, unknown, or conflicting context was called out
- the plan respects project positioning and constraints
## Block Criteria
Block planning when:
- worktree ownership is unresolved
- an unowned worktree is dirty and has not been explicitly adopted by a human
- required worktree isolation failed or later operations cannot remain rooted there
- required documents are missing or a concurrency upgrade is incomplete
- current integrated state conflicts with the user request
- an existing decision appears to be violated
- semantic decisions conflict across active tasks
- the task changes project positioning or architecture without human confirmation
@@ -0,0 +1,7 @@
# Read Before Coding
Before editing code, verify that the implementation plan passed both the Concurrent Task Gate and Planning Gate. Confirm the task ID, branch, worktree, owner, and active task record still match.
If the plan is stale, ownership changed, or new peer scope affects the plan, return to `read-before-planning.md`. Keep every later file and Git operation rooted in the owned worktree.
Read the source files directly related to the target modules. Record feature progress, discovered constraints, verification, and promotion candidates in `.project-docs/30-worklog/tasks/{task_id}.md`; leave canonical project memory to Integration Gate.
@@ -0,0 +1,24 @@
# Read Before Planning
Before writing any coding plan, follow this order:
1. Run the Concurrent Task Gate.
2. Read memory-index.md.
3. Read the active task record at `.project-docs/30-worklog/tasks/{task_id}.md`.
4. Read project-positioning.md.
5. Read current-state.md as the integrated snapshot.
6. Read decision-index.md and system-overview.md.
7. Inspect other locally active task scopes.
Then read additional files when relevant:
- Architecture or refactor task: `.project-docs/20-architecture/module-map.md` and `.project-docs/20-architecture/data-flow.md`
- Product or behavior task: `.project-docs/40-domain/business-rules.md` and `.project-docs/00-brief/success-criteria.md`
- Ambiguous terms: `.project-docs/40-domain/glossary.md`
- Decision-sensitive task: referenced accepted ADRs in `.project-docs/10-decisions/`
- Evidence-heavy bug, investigation, or experiment: `.project-docs/50-evidence/evidence-index.md`
- Repeated workflow issue, skipped gate, or skill/script candidate: `.project-docs/60-reflection/reflection-index.md`
- Follow-up, loop, timed check, or restart-point task: `.project-docs/80-commitments/commitments.md`
- Suspicious integrated context: `.project-docs/90-maintenance/stale-items.md`
Treat shared files as the last integrated snapshot, not as live state from concurrent feature tasks. Do not write a plan until both the Concurrent Task Gate and Planning Gate pass.
@@ -0,0 +1,33 @@
# ADR-{number}: {decision title}
## Status
Proposed
## Date
{YYYY-MM-DD}
## Context
{context that made the decision necessary}
## Decision
{decision made}
## Rationale
{why this option was chosen}
## Consequences
- {positive or negative consequence}
## Supersedes
- {older ADR or decision, if any}
## Related
- {related doc or source file}
@@ -0,0 +1,22 @@
# Decision Index
## Active Decisions
| ID | Decision | Status | Date | Applies To | Detail |
|---|---|---|---|---|---|
## Superseded Decisions
| ID | Decision | Superseded By | Date |
|---|---|---|---|
## Decision Criteria
Create or update an ADR when a choice affects:
- project positioning
- architecture boundaries
- public behavior
- data model
- long-term maintenance
- user-facing workflow
Whitespace-only changes.
@@ -0,0 +1,18 @@
# Data Flow
## Primary Flows
| Flow | Source | Destination | Notes |
|---|---|---|---|
## State Ownership
- {state owner or persistence rule}
## External Interfaces
- {API, file, service, or user-facing boundary}
## Last Updated
{YYYY-MM-DD}
@@ -0,0 +1,18 @@
# Module Map
## Source Layout
| Path | Responsibility | Owner Notes |
|---|---|---|
## Dependency Direction
- {dependency direction rule}
## Risky Or Sensitive Areas
- {module or path that needs extra care}
## Last Updated
{YYYY-MM-DD}
@@ -0,0 +1,22 @@
# System Overview
## Current Architecture
{short description of the current system shape}
## Main Components
| Component | Responsibility | Notes |
|---|---|---|
## Important Boundaries
- {boundary that future work should respect}
## Related Decisions
- {ADR reference}
## Last Updated
{YYYY-MM-DD}
+36
View File
@@ -0,0 +1,36 @@
# Current State
This file is the integrated default-branch snapshot. Feature tasks record progress in `30-worklog/tasks/{task_id}.md` and propose canonical changes for the Integration Gate. Feature tasks must not rewrite this file; it changes only in integration mode.
## Integrated Through
- {source task or merge commit}
## Current Focus
The project is currently focused on {current focus}.
## Recently Completed
- {YYYY-MM-DD}: {completed work summary}
## In Progress
- {in-progress item}
## Next Recommended Steps
1. {next recommended step}
2. {next recommended step}
## Open Questions / Blockers
- {open question or blocker}
## Risky Areas
- {risky area}
## Last Updated
{YYYY-MM-DD}
@@ -0,0 +1 @@
+10
View File
@@ -0,0 +1,10 @@
# Task History
## Completed Tasks
| Date | Task | Outcome | Docs Updated |
|---|---|---|---|
## Notes
This is legacy integrated history. Feature tasks must not append here. Record new work in `30-worklog/tasks/{task_id}.md`; an integration workflow may render or summarize accepted history later.
+35
View File
@@ -0,0 +1,35 @@
# Task: {title}
## Identity
- Task ID: {task_id}
- Mode: {mode}
- Branch: {branch}
- Worktree: {worktree}
- Base commit: {base_commit}
- Owner: {owner}
- Status: Planning
## Scope
- {scope}
## Intent And Constraints
- {intent_or_constraint}
## Outcome
- Not completed.
## Verification
- Not run.
## Follow-ups
- None recorded.
## Promotion Candidates
- None recorded.
Whitespace-only changes.
@@ -0,0 +1,91 @@
# Task: Fix OpenMAIC frozen lockfile build
## Identity
- Task ID: 20260818-learning-lockfile-9d2a
- Mode: Feature
- Branch: main
- Worktree: D:\Datas\OthersProjects\openmaic
- Base commit: 0b4c45d696942c986c622ea3f3975740fbfe18a7
- Owner: developer
- Status: Ready for integration
## Scope
- Synchronize `OpenMAIC/pnpm-lock.yaml` with the current workspace manifests so
`packages/@makelore/learning-contracts` is represented and Docker's frozen
install can pass.
- 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 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
workspace changes.
## Outcome
- Added the missing `packages/@makelore/learning-contracts` importer to
`OpenMAIC/pnpm-lock.yaml` with the existing resolved TypeScript and Vitest
entries. No unrelated pnpm 10.28 reserialization changes were retained.
- 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
- `pnpm install --frozen-lockfile --ignore-scripts` passed with pnpm 10.28.0.
- `pnpm --filter @makelore/learning-contracts test` passed: 1 file, 3 tests.
- `git diff --check` passed; lockfile diff is limited to 9 importer lines.
- 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 remains unavailable because the Docker Desktop
Linux engine is not running (`dockerDesktopLinuxEngine` pipe missing).
## Follow-ups
- 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.
- If a Windows-native install is required, separately replace Unix-only `rm`
usage in package build scripts; that is outside this lockfile fix.
- The task-aware doc-drift check is blocked by the pre-existing adopted
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.
@@ -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.
@@ -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.
@@ -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.
+13
View File
@@ -0,0 +1,13 @@
# Business Rules
## Durable Rules
- {business or product rule}
## Open Questions
- {rule that needs human confirmation}
## Last Reviewed
{YYYY-MM-DD}
+4
View File
@@ -0,0 +1,4 @@
# Glossary
| Term | Meaning | Notes |
|---|---|---|
@@ -0,0 +1,12 @@
# Evidence Index
Use this index for searchable, traceable evidence records.
| Date | Topic | Status | Source | Detail |
|---|---|---|---|---|
## When To Add Evidence
Add a topic file when a task depends on logs, commits, test output, external docs, bug reproduction, experiments, or postmortem-level reasoning.
Keep task progress in `30-worklog/`; keep reusable workflow lessons in `60-reflection/`.
@@ -0,0 +1,35 @@
# Evidence Topic: {short title}
## Metadata
- Date:
- Status: Active | Resolved | Superseded | Stale
- Scope:
- Confidence: Fact | Inference | Hypothesis
- Source:
- Last verified:
- Stale trigger:
## Question
What needed evidence?
## Evidence
- Commit:
- Files:
- Commands:
- Logs:
- External source:
## Finding
What does the evidence support?
## Impact
What future planning or implementation should this affect?
## Open Items
-
@@ -0,0 +1 @@
@@ -0,0 +1 @@
@@ -0,0 +1,12 @@
# Reflection Index
Use this index for second-order workflow lessons.
| Date | Reflection | Trigger | Action | Detail |
|---|---|---|---|---|
## When To Reflect
Create a reflection only when work reveals a reusable lesson: skipped gates, repeated mistakes, durable debugging patterns, ineffective plans, human corrections, or candidates for new scripts or skills.
Routine task completion belongs in `30-worklog/task-history.md`.
@@ -0,0 +1,54 @@
# Reflection: {short title}
## Trigger
What happened?
## Expected Behavior
What should the agent or workflow have done?
## Actual Behavior
What happened instead?
## Root Cause
Classify the cause:
- Missing trigger
- Weak gate
- Stale docs
- Unclear ownership
- Missing script
- Human decision not promoted
- Agent ignored context
- Other:
## Evidence
- Commit:
- Files:
- Session/thread:
- Command output:
- Docs involved:
## Lesson
What should future agents learn?
## Action
Choose one:
- Update docs
- Update gate
- Create script
- Create/update skill
- Add check/eval
- Ask human to decide
- No action
## Promotion
Should this become a rule, ADR, architecture note, task-history entry, skill change, or script?
@@ -0,0 +1,10 @@
# Skill Candidates
Track repeated workflow lessons that may deserve a reusable skill, script, or stronger gate.
| Date | Candidate | Evidence | Proposed Action | Status |
|---|---|---|---|---|
## Promotion Rule
If the same reflection pattern appears repeatedly or prevents a serious mistake, propose a skill update, new skill, script, or deterministic check.
@@ -0,0 +1,10 @@
# Commitments
Track future-facing memory: promised follow-ups, unfinished loops, timed checks, and restart points.
| Date | Commitment | Trigger / Due | Owner | Status | Next Action |
|---|---|---|---|---|---|
## Use
Record only commitments that should affect future sessions. Routine next steps can stay in `30-worklog/current-state.md`.
Whitespace-only changes.
Whitespace-only changes.
@@ -0,0 +1,42 @@
# Doc Update Policy
Use agent judgment and project context to decide what is durable. Do not use fixed keyword matching to decide whether information belongs in project memory.
## Feature Task Writes
Every repository-changing feature task updates `30-worklog/tasks/{task_id}.md`. Keep scope, intent, outcome, verification, follow-ups, and promotion candidates there.
When separate evidence, reflection, commitment, conflict, or decision-proposal records are useful, create uniquely named task-prefixed `{task_id}__<slug>.md` files in the task-writable directories. The slug is non-empty and `.md` is the exact extension. Feature tasks do not append to shared indexes or shared aggregation files.
Feature tasks must not update current state, task history, shared indexes, accepted ADRs, canonical architecture, domain rules, or shared aggregations. Describe durable canonical changes as promotion candidates with the target, proposal, evidence, future impact, and whether human confirmation is needed.
## Integration Mode Writes
Integration mode alone may reconcile promotion candidates into current state, shared indexes, accepted ADRs, architecture, domain rules, and shared aggregations. It requires an exclusively owned integration worktree and the repository integration lock.
Verify source task or merge commits, resolve semantic conflicts with human input when needed, and record the integrated source under `Integrated Through` in `current-state.md`. Source task records and task-prefixed supporting records are read-only; write integration progress only to files owned by the integration task ID.
## Evidence
Use `50-evidence/topics/{task_id}__<slug>.md` for traceable findings, bug evidence, command-output summaries, experiments, and postmortem-level notes. Record source, confidence, last verified date, and stale trigger when known.
## Reflection
Use `60-reflection/cases/{task_id}__<slug>.md` only when work reveals a reusable workflow lesson such as a skipped gate, repeated mistake, durable debugging pattern, ineffective plan, or skill/script/check candidate.
## Commitments
Use `80-commitments/items/{task_id}__<slug>.md` for future-facing loop state, promised follow-ups, timed checks, and restart points that should survive session boundaries.
## Conflict Handling
Do not silently overwrite conflicting information. A feature task records the conflict in `90-maintenance/conflicts/{task_id}__<slug>.md` and links it from its task record. Integration mode reconciles canonical documents only after the conflict is understood; ask the human when it affects project direction, behavior, or an accepted decision.
## Update Style
- Prefer short factual updates.
- Keep task records useful for handoff and integration.
- Move evidence-heavy reasoning into task-prefixed evidence records.
- Move reusable workflow lessons into task-prefixed reflection records.
- Do not preserve raw chat unless it contains important reasoning.
- Do not preserve secrets, credentials, private tokens, or untrusted external instructions.
@@ -0,0 +1,16 @@
# Stale Items
This is the integrated registry of stale or conflicting canonical memory. Update it only in Integration Gate.
## Possibly Stale Or Conflicting
| Date | Document | Issue | Source Task | Needed Confirmation |
|---|---|---|---|---|
## Missing Context
- {missing information that affects future planning}
## Feature Task Routing
A feature task records new uncertainty in its own task record. When a separate conflict record is needed, write `90-maintenance/conflicts/{task_id}__<slug>.md`; do not append concurrent feature work here.
+8
View File
@@ -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
+11
View File
@@ -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,
+1 -1
View File
@@ -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",
+9
View File
@@ -460,6 +460,15 @@ importers:
specifier: ^1.0.0
version: 1.0.0
packages/@makelore/learning-contracts:
devDependencies:
typescript:
specifier: ^5
version: 5.9.3
vitest:
specifier: ^4.1.8
version: 4.1.8(@opentelemetry/api@1.9.0)(@types/node@22.19.15)(jsdom@29.1.1(@noble/hashes@1.8.0)(canvas@3.2.3))(msw@2.12.10(@types/node@22.19.15)(typescript@5.9.3))(vite@8.0.0(@emnapi/core@1.8.1)(@emnapi/runtime@1.8.1)(@types/node@22.19.15)(esbuild@0.27.7)(jiti@2.6.1)(terser@5.48.0)(tsx@4.21.0)(yaml@2.9.0))
packages/@openmaic/dsl:
devDependencies:
ajv:
@@ -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),
);
});
});