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.