jRay had no requirement IDs, so nothing in this repo could be traced to and the CI gate had no denominator to read. The other two components had already moved to registers; this brings the plugin level with them. Adds docs/requirements.md with 46 permanent JR-nnn IDs, each carrying a parent requirement, priority, status and verification tier, plus a per-requirement verification plan. JR is flat rather than split by theme: the plugin is one deployable with one audience, and JRay-public-server already ships UR/DR, so a second repo using those prefixes would make UR-007 ambiguous across registers. Rewrites SPEC.md as requirements prose with Current:/Gap: on every one. It had drifted into a format-plus-API reference that documented schema_version 1 while owning a format whose v2 shape was specified only in the other two repos, said nothing about SR-002's scene-scoped semantics, and carried the manifest exchange as a "planned" aside while its configuration classes were already implemented. Plugin-side exchange obligations move here from the server's spec, where they were an ownership inversion. Adds JR-038..041 for PR-005, which had no software row in any repo -- it was held structurally by SR-004 and GR-005 both being prohibitions, and a goal preserved only by prohibitions is the kind that erodes unnoticed. jRay is the component that actually opens a socket. Tags 18 units with the requirements they satisfy. Tags name what the code satisfies, so FileTransformationRegistration is not tagged JR-021: that requirement is a prohibition and was still violated elsewhere when this was written. Vendors jray-project as a submodule for the system spec and shared gate. TRACES: JR-001, JR-004, JR-005, JR-007, JR-008, JR-009, JR-010, JR-011 TRACES: JR-012, JR-013, JR-014, JR-015, JR-016, JR-017, JR-018, JR-019 TRACES: JR-020, JR-024, JR-025, JR-036, JR-038 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
23 lines
833 B
C#
23 lines
833 B
C#
namespace Jellyfin.Plugin.JRay.Models;
|
|
|
|
/// <summary>
|
|
/// The object handed to JRay's transformation callback by the File
|
|
/// Transformation plugin.
|
|
/// </summary>
|
|
/// <remarks>
|
|
/// That plugin builds a Newtonsoft <c>JObject</c> with a single <c>contents</c>
|
|
/// key and calls <c>JObject.ToObject(parameterType)</c> against this type.
|
|
/// Newtonsoft binds member names case-insensitively, so <see cref="Contents"/>
|
|
/// binds to <c>contents</c> without an attribute — and a System.Text.Json
|
|
/// attribute would have no effect here.
|
|
/// </remarks>
|
|
public class TransformationPayload
|
|
{
|
|
/// <summary>
|
|
/// Gets or sets the current contents of the file being served, including
|
|
/// any transformations applied by other plugins ahead of JRay in the
|
|
/// chain.
|
|
/// </summary>
|
|
public string? Contents { get; set; }
|
|
}
|