Decision-tree leaf outcomes are now cached on the main thread keyed by
their full 12-course assignment. Pin operations filter the cache and
re-derive top-K + per-set ceilings instantly with no worker spawn. Unpin
operations show the cached subset immediately and stream improvements as
a background worker fills in the missing leaves. Cache survives pin,
unpin, and adopt-plan; only ranking or mode changes invalidate it.
Solver / worker:
- searchDecisionTree accepts skipKeys (Set<string>) and pinnedAssignments
(Record<setId,courseId>). Leaves are emitted with their full 12-set
assignment so cache keys are stable across pin/unpin operations.
- evaluateLeaf short-circuits when the leaf's assignmentKey is in
skipKeys: increments iterations + emits progress, but skips the
optimizer call and all callbacks. Keeps progress percentage honest
(counts whole tree, not just delta).
- New deriveFromLeaves pure helper produces {topK, setAnalyses} from a
leaf collection; used by the main-thread cache filter and gives a
reusable derivation primitive for tests.
- Worker request gains skipKeys and pinnedAssignments fields. Worker
response gains a leafEvaluated event so the main thread can populate
its cache as the search streams.
App state:
- leafCacheRef holds Map<assignmentKey, PlanOutcome> scoped to the
current (ranking, mode) pair. The search effect now: invalidates on
ranking/mode change; computes the orderedCourses + expectedTotal;
filters the cache against the current pinned/excluded state; calls
deriveFromLeaves to render immediately; spawns the worker only when
filtered.length < expectedTotal, passing skipKeys.
- Cache cap of 500,000 leaves with full clear on overflow. Bounds
worst-case memory at ~150 MB.
UI (TopPlans):
- Course blocks in the per-plan row are now interactive buttons. Click
pins (or unpins, if the course is currently pinned) the course in
that set. Pinned blocks render in a selected blue color.
- Each plan row now shows the FULL 12-set sequence including pinned
courses (interleaved with the search's recommended choices for the
remaining open sets) so the displayed plan is always complete.
- Spec qualification tags removed from per-block display (kept the
set-label + course-name treatment for clarity).
Tests:
- New app/src/solver/__tests__/leafCache.test.ts with 4 tests:
skipKeys parity (second-pass run with skipKeys evaluates zero
leaves), deriveFromLeaves parity (matches a fresh search), cache
filter on pinned assignments, cache filter on excluded courses.
- All 78 prior tests continue to pass; 82 total.
Browser-verified: pin click on a Top Plans block from the cached
8-open-set scenario completes instantly with no spinner; unpin restores
the original cached subset (also instant when the prior space was
already cached); mode toggle correctly invalidates and re-runs the
search.
EMBA Specialization Solver
A client-side web application that helps EMBA students optimize their elective course selections to maximize the number of specializations they can earn.
The Problem
The J27 EMBA program offers 46 elective courses across 12 elective sets (Spring, Summer, Fall terms). Students select one course per set — 12 electives total, 30 credits. The program defines 14 specializations, each requiring 9+ credits (at least 4 qualifying courses). The catch: course credits do not duplicate across specializations. When a course qualifies for multiple specializations, its 2.5 credits must be allocated (potentially split) among them. This makes course selection a non-trivial credit allocation optimization problem.
Key constraints:
- Credit sharing: Each course's 2.5 credits are split across qualifying specializations — no double-counting
- Maximum 3 specializations: 12 courses × 2.5 credits = 30 total, and 3 × 9 = 27, so 3 is the theoretical max
- Required courses: 4 specializations require a specific course to be selected
- Strategy S1/S2 tiers: The Strategy specialization limits S2-marked courses to at most 1 contributing
Features
- Two optimization modes:
- Maximize Count — finds the largest set of achievable specializations, using ranking as a tiebreaker
- Priority Order — processes specializations in your ranked order, greedily adding each if feasible
- Drag-and-drop ranking — reorder specializations by priority
- Live optimization — results update instantly as you select courses
- Decision tree analysis — a Web Worker enumerates remaining course combinations to show ceiling outcomes per choice (how many specializations each option can lead to)
- Status tracking — each specialization is classified as achieved, achievable, missing a required course, or unreachable
- Mode comparison — shows what the alternative mode would produce so you can pick the better result
- Responsive — mobile layout with floating status banners
- State persistence — selections and rankings saved to localStorage
Tech Stack
- React 19 + TypeScript
- Vite 7 (dev server, bundler)
- javascript-lp-solver — linear programming for credit allocation feasibility checks
- @dnd-kit — drag-and-drop for specialization ranking
- Vitest — test runner
- Nginx — production static file server (Docker)
Prerequisites
- Node.js >= 22
- npm
- Docker and Docker Compose (for containerized deployment)
Development
All commands run from the app/ directory:
cd app
Install dependencies
npm install
Start the dev server
npm run dev
The app will be available at http://localhost:5173 with hot module replacement.
Run tests
npm test
Or in watch mode:
npm run test:watch
Lint
npm run lint
Build for production
npm run build
Output goes to app/dist/.
Preview production build locally
npm run preview
Deployment
Docker Compose (recommended)
From the project root:
docker compose up -d
This builds a multi-stage Docker image:
- Build stage — installs dependencies and runs
vite buildin a Node 22 Alpine container - Serve stage — copies the built static files into an Nginx Alpine container
The app is served on port 8080 by default. Override with the PORT environment variable:
PORT=3000 docker compose up -d
Docker (standalone)
docker build -t emba-solver .
docker run -p 8080:80 emba-solver
Static hosting
Run npm run build in app/ and deploy the app/dist/ directory to any static file host (Netlify, Vercel, S3, GitHub Pages, etc.). The app is fully client-side with no backend dependencies.
Project Structure
├── Dockerfile # Multi-stage build (Node → Nginx)
├── docker-compose.yml # Single-service compose config
├── nginx.conf # Nginx config with gzip, caching, SPA fallback
└── app/ # Vite + React application
├── src/
│ ├── main.tsx # Entry point
│ ├── App.tsx # Root component
│ ├── data/ # Static course/specialization data
│ │ ├── types.ts # TypeScript interfaces
│ │ ├── courses.ts # 46 courses with qualifications
│ │ ├── electiveSets.ts # 12 elective sets
│ │ ├── specializations.ts # 14 specializations
│ │ └── lookups.ts # Derived indexes
│ ├── solver/ # Optimization engine
│ │ ├── optimizer.ts # Maximize-count & priority-order modes
│ │ ├── feasibility.ts # LP-based feasibility checks
│ │ └── decisionTree.ts # Exhaustive ceiling analysis
│ ├── components/ # UI components
│ ├── state/ # App state (useReducer + localStorage)
│ ├── hooks/ # Custom hooks (useMediaQuery)
│ └── workers/ # Web Worker for decision tree
└── vite.config.ts
How the Solver Works
- Feasibility checking — uses a linear program (LP) to determine whether a target set of specializations can each reach 9 credits given the selected courses, respecting per-course capacity (2.5 max) and the Strategy S2 constraint
- Maximize Count — tries all combinations of candidate specializations from size 3 down to 1, checking LP feasibility for each; among equal-size feasible sets, picks the one with the highest priority score based on ranking
- Priority Order — iterates specializations in rank order, greedily adding each to the achieved set if the combined set remains LP-feasible
- Decision tree — for each open (unselected) elective set, enumerates all possible remaining course combinations to compute the best-case outcome per choice, helping users identify which selections matter most