THE ORGAN SYSTEM: LIMITS AND NEXT STEPS ======================================= NITETIME ORGAN SYSTEM // HONEST STATUS REPORT The organ system is working, but a useful technical guide should document the unfinished parts too. These are known boundaries, not mysterious future features. CURRENT LIMITS ============== READY-MADE MIDI INTAKE ---------------------- The direct MIDI importer and the automatic sheet-music watcher are separate paths. Ready-made MIDI is not assumed to be processed merely because it was dropped into the score inbox. A unified dispatcher or dedicated command is needed before that behavior can be described as automatic. CONCURRENT CONVERSION --------------------- The watcher and periodic sweep can notice one source at nearly the same time. The content-addressed work area reduces confusion, but source archiving can still race. Conversion should eventually be serialized behind one lock or one trigger mechanism. QUEUE ADMINISTRATION -------------------- Playback honors queued requests, but a public request line is intentionally not available yet. Adding one safely requires authentication, moderation, rate limits, known-song lookup and an audit trail. DISABLING CONTENT ----------------- Parse-error status can exclude a bad file from rotation, but using a parse error as a permanent editorial disable flag is not ideal. A durable disabled state with a reason would make quarantine and re-enabling clearer. COMPOSITION DUPLICATES ---------------------- Hash identity protects file content, not musical identity. Different arrangements can still play close together. A composition/work identifier would allow anti-repeat logic to operate at both levels. VISUAL CACHE VERSIONING ----------------------- Overlay scripts use manual cache versioning. Every visual script change must receive a new version marker until content-hashed asset names replace that manual step. THE SAFE PUBLIC REQUEST LINE ============================ If Nitetime eventually accepts remote requests, the flow should be narrow: requester -> authenticated and rate-limited request interface -> known catalog lookup -> moderation or allowlist -> append-only queue record -> controller consumes request -> overlay shows a safe request label The requester should submit a catalog identity, not a filesystem path or command string. Uploading a new MIDI should be a separate, moderated path. The request line should enforce size, duration, note-count and event-count limits. It should record who requested what, the moderation result and the eventual playback outcome. It should never expose service restart, arbitrary correction, filesystem access, database access or shell execution. THE SAFE DESIGN =============== The public overlay is read-only. The catalog is content-addressed. Manual credits outrank model guesses. New material is validated before rotation. The physical player is kept behind the controller. The web presentation is kept separate from the operator boundary. These constraints are not obstacles to the creative system. They are what allow the creative system to keep running. SOURCE-OF-TRUTH RULE ==================== This public series describes behavior, design and current boundaries. It is not a substitute for private operator documentation. When implementation details change, the running application and its maintained private records must be updated first; this public tour should then be revised to match. The organ is not finished. That is part of the project.