Rehearsal scheduling that keeps 14 of 15 scene assignments unchanged.
Cuesheet is a deployed web product for small theater troupes. It collects cast conflicts, builds a conflict-free rehearsal plan, and re-solves changes while preserving as much of the published schedule as possible.
The image shows a six-scene synthetic product walkthrough. The 14-of-15 headline is measured separately on the canonical benchmark below.
Stage managers commonly collect conflicts from the cast, cross-reference those conflicts against scene and character requirements, and assemble a rehearsal schedule by hand. One new conflict can force another round of checking and communication.
Finding another valid schedule is only half the problem. A fresh solve may move many rehearsals that were already workable, creating avoidable disruption for the cast. Cuesheet treats stability as an optimization goal: after a change, it finds a valid candidate that moves as few existing calls as possible. The stage manager reviews the difference before publishing it.
- Set up the production, scenes, characters, castings, cast, and rehearsal blocks.
- Invite cast members and collect the times when they cannot rehearse.
- Build and publish the first conflict-free schedule.
- Detect a changed conflict and create a minimal-disruption candidate.
- Review what moved, what stayed unchanged, and who is affected.
- Publish the candidate so each cast member sees an updated personal schedule.
Rehearsal work cannot always wait for perfect input. Cuesheet keeps scheduling available, but turns incomplete availability into an explicit operational decision rather than a hidden solver assumption.
When a response is missing or stale after rehearsal blocks change, the stage manager sees that state before building. They can inspect submitted detail, remind cast, or proceed; if they proceed, missing submissions count as available. This preserves continuity while keeping uncertainty, assumptions, and operator authority visible.
The canonical benchmark contains 12 actors, 15 scenes, and 42 possible rehearsal blocks. After one actor loses all Thursday availability, a 500-run repeatability check produced:
| Measurement | Result |
|---|---|
| Initial solve p50 / p95 / p99 | 9.80 / 11.05 / 12.42 ms |
| Minimal-disruption re-solve p50 / p95 / p99 | 5.51 / 6.58 / 7.57 ms |
| Scenes moved by minimal-disruption re-solve | 1 in every run |
| Scenes moved by a fresh solve | 8–12; median 10 |
| Minimal / fresh movement ratio, median | 10.0% |
| Optimal initial / minimal / fresh results | 500 / 500 / 500 |
These are local solver-core measurements recorded on 2026-07-16. They exclude HTTP, database, browser, and network time. See Engineering evidence for the method and limits.
The following screens were captured from the real local service stack with synthetic production and account data.
The workspace keeps scenes, characters, cast, rehearsal blocks, conflicts, and scheduling in one production context.
The stage manager can see who has responded, inspect submitted detail, and spot responses that became stale after rehearsal blocks changed. Day mode supports bright rehearsal rooms; this capture uses the terracotta accent while dark mode remains the product default.
A re-solve creates a candidate rather than silently replacing the published schedule. The review shows moved and unchanged calls before publication.
Cast members see only their own calls and can create a calendar subscription.
The responsive web product keeps each side of the rehearsal workflow focused on the next useful action. These screens were captured at a 390 × 844 browser viewport from the same synthetic product flow as the desktop evidence.
| Production hub | Conflict response status | Day call sheet |
|---|---|---|
| Readiness and workspace navigation | Response progress since publication | Time, room, scene, and cast at a glance |
 |
 |
 |
Together, these screens cover the member journey from invitation acceptance to the next call and a personal schedule. The production home keeps the two primary member actions visible without exposing the stage manager's full workspace.
| Invitation handoff | Production home | Personal schedule |
|---|---|---|
| Production context, identity match, and the joining decision | Next call and primary member actions | Published calls, roles, rooms, and times |
 |
 |
 |
- OR-Tools CP-SAT constraints prevent actor and rehearsal-block conflicts.
- Minimal disruption is a first-class optimization objective, not a comparison applied after solving.
- Immutable schedule versions support candidate review, diffs, and explicit publish.
- A public product API owns identity, tenancy, theater data, and authorization; an internal solver service owns schedule versions and assignments.
- Each service owns an independent PostgreSQL database.
- Real datetimes are converted to stable solver indices at the API boundary, so the optimization engine remains domain-independent.
- Production-scoped access controls, signed calendar feeds, deletion workflows, security headers, rate limits, and secret scanning protect the public surface.
| Area | Technology |
|---|---|
| Optimization | Python, Google OR-Tools CP-SAT |
| Product API | FastAPI, Pydantic, SQLAlchemy, Alembic |
| Data | PostgreSQL, Neon |
| Web | Next.js, React, TypeScript, Tailwind CSS, shadcn/ui |
| Identity and access | Amazon Cognito, RS256/JWKS, scoped RBAC |
| Verification | pytest, Hypothesis, Playwright, coverage gates, Ruff, mypy |
| Delivery | Docker, GitHub Actions, Fly.io, deployment smoke checks |
| Security and operations | Gitleaks, Sentry, Prometheus, uptime monitoring |
The responsive web MVP is deployed and preparing for private-pilot validation. Current evidence covers verified product behavior and engineering results.
The production source is private. This repository contains selected product documentation, measured engineering evidence, and synthetic screenshots. It is not an open-source distribution.
This public repository separates portfolio evidence from the private production source. The showcase workflow validates the evidence package, serves it from a disposable local process, checks the packaged files over HTTP, and uploads a run report with the workflow result.
The workflow never calls production, deploys a billable service, or requires credentials. The CI/CD evidence guide explains the boundary, while the edge-case flow shows how stale availability becomes an explicit operator decision before a candidate is published.
The release receipt is a sanitized record of a private production release. It contains no URL, hostname, credential, token, or private source reference.
Further detail: