Oh-Sheet-Team/oh-sheet

Tracks Q3 of the ml-pipeline publishing RFC. Spun out of #107. What's needed A documented threat model for the oh-sheet-ml-pipeline request handler. The service accepts arbitrary MIDI input and produces MusicXML, which means the attack surface includes (at minimum): MIDI parser bugs. libsmf, mido, or whatever parser the service uses — known CVEs, malformed-input handling, recursion depth, integer overflows. Resource exhaustion. Crafted MIDI inputs that drive the inference pipeline to OOM or peg CPU/GPU. Need documented input-size caps and per-request resource limits. Subprocess shell-out. Any external tool invoked during engraving (LilyPond, music21, ffmpeg, etc.) — argument-injection surface, sandbox boundaries. Output-side surprises. MusicXML is XML — XXE / billion-laughs in output is a downstream-renderer problem, but worth flagging. Deliverable A half-day threat-modeling session whose output is a list of input-validation gaps and mitigations, lived as a doc in the private r

Tracks Q1 of the ml-pipeline publishing RFC. Spun out of #107. What's needed A complete catalogue of the datasets used to train the oh-sheet-ml-pipeline engraver model, with the redistribution license for each. Specifically: Every dataset (or scraped corpus) the model was trained or fine-tuned on. The license / terms-of-use for each dataset, with a primary-source link. Whether those terms permit redistribution of model weights derived from the data (commercial / non-commercial / research-only / unclear). If any dataset blocks redistribution: whether re-training or fine-tuning on a clean corpus is feasible, and what that would cost. Why this gates the publishing decision If the audit surfaces a dataset whose license forbids redistribution of derived weights, then options A (open-source repo + image) and B (image-only) from #107 are blocked until the model is retrained on a clean corpus — regardless of how Q3 (security review) and Q4 (maintenance commitment) shake out. The plugin pro