Repository navigation
Local Install
Last Updated: 2026-10-09 | For: Developers and local verification
deploy/hotfix-local.ps1 owns the single localhost application: the native Meteor/Rspack source watcher at http://localhost:3200. Docker Compose supplies MongoDB and replica-set initialization. Source edits rebuild and reload automatically.
- Prerequisites
- Private local configuration
- Start and manage the watcher
- Local HTTPS
- Verification
- Troubleshooting
- Git and the existing MoFaCTS checkout
- Docker Desktop with Compose
- Node.js
24.15.0and npm11.12.1, pinned inmofacts/package.json - The pinned Meteor tool matching
mofacts/.meteor/release, currentlyMETEOR@3.5 - Windows for the supported supervisor, which owns its process tree with Windows Job Objects
From the application's mofacts/ directory, install locked dependencies with npm ci. Meteor UI, persistence, and server integration belong in mofacts/; pedagogical engines and models belong in learning-components/. See Developer Reference for the source map.
From the repository's deploy/ directory, create private files from templates for a new setup:
Copy-Item .env.local.example .env.local
Copy-Item settings.local.example.json settings.local.jsonIf private files already exist, review them in place; do not replace working configuration with templates. Replace placeholders before startup and keep credentials out of commits.
METEOR_SETTINGS_HOST_PATH must identify an existing private settings file with the configured owner for local administrator bootstrap. .env.local must supply MOFACTS_NATIVE_MONGO_URL using the host-accessible MongoDB address and configured replica-set identity. The container address mongodb:27017 is not the native host connection. Keep the canonical database name and replica-set configuration consistent with the launcher.
The private MongoDB member keyfile must exist at MONGO_REPLICA_SET_KEYFILE_HOST_PATH. For initial local setup use:
.\New-MongoReplicaSetKeyfile.ps1Converting an existing standalone database requires the documented maintenance procedure and a restorable backup. Starting from templates is not authorization to reinitialize a database. The launcher validates configuration and database readiness before starting Meteor.
From deploy/:
.\hotfix-local.ps1 -Action start
.\hotfix-local.ps1 -Action statusOpen http://localhost:3200. The launcher owns the supervisor, Meteor process, and Rspack descendants. Use the same owner for lifecycle actions:
.\hotfix-local.ps1 -Action logs -LogTail 120
.\hotfix-local.ps1 -Action restart
.\hotfix-local.ps1 -Action stopOrdinary source edits do not require a restart. Use restart for changes that require a new process or after diagnosing a failed development run. Stop manages the application process tree; it does not delete database volumes or learner data.
Do not start a second native or containerized localhost application, patch generated bundles, or replace source watching with a manual build loop. Failure logs are retained under ignored deploy/local-hotfix/runs/; status reports ownership and readiness.
The HTTPS helper puts Caddy in front of the same watcher. Set MOFACTS_CADDY_EXE to an existing executable:
$env:MOFACTS_CADDY_EXE = 'C:\Path\To\caddy.exe'
.\start-lan-https.ps1The tracked Caddyfile.local serves https://localhost:3000 and proxies to 127.0.0.1:3200. Its configured hostname is localhost. Access from another device requires a deliberately configured hostname or address, suitable certificate trust, and network access; the helper's name does not make localhost a phone-accessible endpoint.
For a configuration using Caddy's internal certificate authority, clients must trust that authority. On Windows its usual root-certificate location is C:\Users\<user>\AppData\Roaming\Caddy\pki\authorities\local\root.crt. On iPhone, install the profile, then enable full trust under Settings → General → About → Certificate Trust Settings. Verify the actual host and certificate when diagnosing microphone access.
Use the paired stop helper when finished:
.\stop-lan-https.ps1The watcher manager owns a durable supervisor and its complete Meteor/Rspack process tree. Status checks validate PID identity and report readiness and the last recognized failure. Previous logs are archived under ignored deploy/local-hotfix/runs/; generated output is rebuilt by the watcher. A bounded startup retry follows repeated database-primary readiness checks, and recurring failures remain visible.
From the application's mofacts/ directory:
npm run typecheck
npm run lintRun the full app typecheck for TypeScript changes and lint for lintable TypeScript, JavaScript, or Svelte changes. Schema changes also require npm run generate:schemas and inspection of generated diffs. Required failures must be resolved or explicitly accepted before staging, committing, or pushing.
Meteor integration tests need CI or another supported Meteor environment. Each npm run test:ci invocation requires fresh, explicit authorization for agent work; it is not a routine local Windows check. The watcher establishes local verification. Release confidence uses the canonical Docker Compose image workflow with separate authorization for builds, pushes, and deployments.
Stay on the current branch unless a branch change is requested. Review intentional files before staging; commits and pushes require explicit instructions. Pre-commit hooks check staged lint and secrets.
| Symptom | Check |
|---|---|
| Missing settings or native MongoDB URL | Review .env.local and its existing private settings path. |
| MongoDB not ready | Inspect authenticated access and the configured replica-set primary; do not substitute another database. |
| Port occupied | Use launcher status to identify ownership and preserve unrelated listeners. |
| Source edits do not rebuild | Inspect watcher and Rspack status/logs; do not patch compiled output. |
| Wrong tool version | Match package.json and .meteor/release. |
| Microphone fails on another device | Verify the HTTPS host, certificate trust, permissions, and network route. |
Process ownership and readiness details live in the repository's deploy/hotfix/README.md. Server operation is covered in Remote Install; runtime configuration is covered in Settings.json Reference.
Getting Started
- Teacher: First Hour
- Quick Start: Content Creation
- Class Setup and Assignment Workflow
- Anki Import Guide
Authoring Reference
- Introduction to TutorScript
- Content Creation Reference Tables
- Stimulus Files (Content)
- Trial Types Reference
- Audio and Speech Settings
Advanced Authoring
Reports and Help
- Researcher Guide
- TDF field tables
- Gaze tracking prototype
- Data Output and Reports
- Data Privacy, IRB, and FERPA Notes
- Experiment Routes
- SPARC Instructional Cycles
- Public Demonstrations
- Learning Algorithms Reference
- Video Units and Adaptive Logic
- AutoTutor Sessions
- Deployment Guide
- Security Audit Operations
- Remote Install
- Runtime Settings Reference
- Admin Features Reference
- Custom Help Page Setup
- Troubleshooting
- Local Install
- Developer Reference Guide
- Learning Algorithms Reference
- Introduction to TutorScript
- AutoTutor Sessions
- Runtime Settings Reference
- Deployment Guide
- Glossary
- FAQ
- Screenshots
- License Guidance
- Implementation Cost Analysis
- GitHub Repository
- GitHub Issues