Makerflow is the internal modular management system of the Brandeis Design & Innovation Lab. It replaces a collection of spreadsheets, Google Forms, and manual processes with a single modular Flutter app that staff and student workers use every day.
This repo is the source of truth for the shared foundation: design tokens, global components, platform core (auth, API client, routing), and the module registry. Every module is developed independently (in its own repo or package) and registered here when ready.
Every row below is a module. An owner is the person responsible for delivering it end-to-end (backend handlers, Dart screens, tests). Modules marked Unassigned need an owner.
Physical presence and the state of the lab environment. Modules here answer: who is in the lab right now, which rooms and stations are occupied, what is scheduled to happen in the space, and whether the space itself is in good condition. If a module's primary subject is a room, workstation, or the lab floor — not the object in it or the person using it — it belongs here. Equipment-specific tracking (borrowing a tool, running a print job) lives in Equipment even if it happens in the lab.
| Module | Description | Owner | Replaces | Status |
|---|---|---|---|---|
| MF:CheckIn | Room check-in kiosk, swipe access | Greg | bdi-check-in-form (gsheets) | Live — needs rework |
| MF:Calendar | Space calendar display screens, workshop sync | Unassigned | Multiple GCal calendars | Unstarted |
| MF:Scheduling | Remote desktop and AI workstation booking | Unassigned | Manual GCal entries | Unstarted |
| MF:Maintenance | CV-based space monitoring + cleaning reminders | Tim | Manual | Proposed — open questions |
Out of scope: General space booking still requires a human in the approval loop. Not in Makerflow this summer.
Lifecycle of physical objects in the lab — borrow, use, track, and authorize. Modules here answer: what supplies and equipment do we have, who has what checked out, what is the status of a 3D print job, and who is cleared to use a specific machine. If a module tracks a physical object (tool, material, printer, smart-plug device) or an agreement tied to one (safety contract, access permission), it belongs here. Scheduling a room or workstation belongs in Space; a person's training record independent of a specific machine belongs in Community.
| Module | Description | Owner | Replaces | Status |
|---|---|---|---|---|
| MF:Inventory | Supplies, locker spaces, equipment rentals — build plan | Tim · G | Spreadsheets | In dev |
| MF:Prints | 3D print job queue and status tracking | Unassigned | Google Form + email | Works (gform today) |
| MF:Contracts | High-value equipment contracts and safety sign-offs | Tim | Local HTML generator + gsheets | Works (partial) |
| MF:Access | Smart plug machine access control | Tim | None — new capability | Proposed — open questions |
The people who use the lab and the work they produce. Modules here answer: what are lab members building, how do their projects get tracked and showcased, and what training or certifications do they hold. If a module's primary subject is a person — their projects, portfolio, skills, or compliance record — it belongs here. Equipment authorization tied to a specific machine belongs in Equipment; shift-level tasks for staff belong in Operations.
| Module | Description | Owner | Replaces | Status |
|---|---|---|---|---|
| MF:PM | Project management across BDI | Ian | makerflowPM | In dev |
| MF:Gallery | Student project stories and portfolio showcase | Natalie | Manual (Natalie chasing people) | In dev |
| MF:Safety | Safety training records, equipment sign-off tracking | Unassigned | Moodle + gsheets | Unstarted |
Staff-facing tools for running the lab as a workplace. Modules here answer: what does a student worker need to do this shift, where are the key links and resources staff need, and how does the lab maintain its own internal processes. If a module primarily serves staff doing their job (not serving lab members using the lab), it belongs here. Member-facing features belong in their subject-area group: Space, Equipment, or Community.
| Module | Description | Owner | Replaces | Status |
|---|---|---|---|---|
| MF:Shifts | Meeting agendas, open-hours checklist, per-shift task list | Unassigned | Google Doc + manual | Unstarted |
| MF:Links | Link aggregation hub (makerlab.fyi) | Greg | — | Live ✅ |
| Module | Description | Owner | Status |
|---|---|---|---|
| Design System | Token/component catalog | Core | Live ✅ |
We currently maintain one calendar per lab space, managed manually. Makerflow will:
- Read calendar events for display in MF:Calendar (room screens, student-facing view)
- Write booking events from MF:Scheduling (remote desktop, AI workstation reservations)
- Consolidate multiple space calendars into one unified view
Integration path: Google Calendar API v3 via a service account.
Scopes needed: calendar.readonly (display) + calendar.events (booking write).
We use LibCal for library workshop sign-ups. Makerflow will:
- Pull workshop registrations into MF:PM and MF:Gallery context
- Display upcoming workshops in MF:Calendar room screens
Integration path: LibCal API v1.1 (read-only).
Auth: client credentials (client_id + client_secret from Springshare dashboard).
Key endpoints: GET /hours, GET /events, GET /space/bookings.
Safety training lives in a Moodle community. MF:Safety will:
- Check completion status of required training courses before allowing equipment sign-off
- Display outstanding training requirements per user
Integration path: Moodle Web Services API (REST).
Required: Moodle admin creates a web service token with core_user_get_users_by_field
and core_completion_get_activities_completion_status permissions.
All Makerflow modules must comply with:
- Federal ADA Title II and Section 504 — accessible technology for all users
- ATAC review — all software goes through Brandeis IT Accessibility & Technology Advisory Committee review before deployment: brandeis.edu/its/governance-policies/atac
Developer checklist per module:
- Touch targets ≥ 48px (
MFLayout.minTouchTarget) - Semantic labels on all interactive elements (
Semanticswidget) - Color contrast meets WCAG AA (4.5:1 for text, 3:1 for UI elements)
- Screen reader tested on iOS VoiceOver and Android TalkBack
- All form fields have visible labels (not just placeholders)
Note: Only HR and the Accessibility Office can define a "Reasonable Accommodation." If a student worker or lab member requests an accommodation, refer them there — do not attempt to implement ad-hoc accommodations in software.
- Log in at the lab's Makerflow URL with the credentials a staff member creates for them
- MF:Shifts — their shift starts here: today's checklist, open-hours tasks, and the staff agenda
- MF:Swipe — the software behind the check-in/ check-out kiosk
- MF:Prints — log 3D print jobs for material usage tracking
- MF:Inventory — check out equipment and update stock when supplies are used
- MF:Contracts — staff handles equipment sign-offs
- MF:Safety — staff reviews and approves training records
- MF:Calendar — read-only for student workers, managed by staff
- MF:Scheduling — books remote desktop and AI workstation slots
| Role | What they can do |
|---|---|
member |
Check in via Swipe, submit print jobs, view gallery |
staff (student worker) |
All of the above + Shifts, Prints management, Inventory updates |
admin |
Full access including Contracts, Safety, Scheduling, user management |
Student workers are assigned the staff role. The admin role is for full-time staff only.
- Check the Maintenance module for known issues
- Slack the staff channel — do not try to edit production data directly
- The backend logs are at
server/logs/(staff access only)
All visual values live in lib/theme/tokens.dart.
Nothing is hardcoded — every color, spacing value, radius, and type style references a token.
Run the app and go to Design System in the sidebar to browse everything visually.
| Token class | Contains |
|---|---|
MFColors |
brandBlue, skyBlue, crimson, teal, deepTeal, amber, coral, bg, cardBg, text hierarchy |
MFType |
DM Sans — displayLarge/Medium, labelLarge, bodyLarge/Medium, caption |
MFSpacing |
xs(4) sm(8) md(16) lg(24) xl(32) xxl(48) |
MFRadius |
sm(4) md(10) lg(20) pill(999) |
MFLayout |
minTouchTarget(48) navBreakpoint(600) sidebarWidth(220) |
Module accent colors: Managing → crimson, Tracking → teal, Booking → deepTeal, Operations → amber.
lib/config/client.dart — MakerflowClient sends all commands as
POST /api/<group>/<module>/<action> with a Bearer token. Provide via Riverpod:
final r = await ref.read(clientProvider).command('tracking.inventory.list', {});
if (!r.ok) throw Exception(r.error);lib/auth/ — authProvider is an AsyncNotifier<User?>.
null = unauthenticated. GoRouter redirects automatically; modules don't handle redirect logic.
final user = ref.watch(authProvider).valueOrNull;
if (user?.isStaff ?? false) { /* show staff controls */ }--dart-define=SERVER_URL=https://your-backend.com at build time. Defaults to http://localhost:3000.
Until monorepo consolidation, each module is its own Flutter project. Reference the core as a git dependency:
dependencies:
makerflow:
git:
url: https://github.com/BrandeisMakerLab/makerflow.git
ref: mainSee docs/MODULE_GUIDE.md for the full step-by-step.
To register your module when it's ready: edit one file — lib/config/modules.dart.
Your module's entry is already there with enabled: false. Import your screen, swap _stub
for your builder, and flip enabled: true.
When the team consolidates, all module repos move under packages/:
packages/
├── makerflow_core/ ← current lib/
├── makerflow_inventory/
├── makerflow_pm/
├── makerflow_gallery/
├── makerflow_swipe/
└── ...
See Monorepo Migration in BUILD_PLAN for steps.
Prerequisites: Flutter 3.22+, Node.js 20+, Docker (optional)
# Backend
cd server && cp ../.env.example .env && npm install && npm run dev
# Flutter (web)
flutter pub get
flutter run -d web-server --web-port 8080 --dart-define=SERVER_URL=http://localhost:3000- Branch off
main, open a PR when ready flutter analyze --no-pubmust pass with 0 issues- No hardcoded values — everything from tokens
- All interactive elements need semantic labels
- New commands must be added to
contracts/envelope.md
| File | Purpose |
|---|---|
lib/theme/tokens.dart |
Design tokens — start here |
lib/config/modules.dart |
Module registry — all 12 modules listed with owners |
lib/config/client.dart |
HTTP client |
lib/auth/ |
Platform auth |
contracts/envelope.md |
REST API contract |
docs/MODULE_GUIDE.md |
How to build a module |
docs/BUILD_PLAN.md |
Roadmap and decisions |