3 Commits
Author SHA1 Message Date
dtourolleandClaude Opus 5 bddaddac5d docs: CC0 for the system spec and shared tooling
The README asserted "GPLv3, matching the Jellyfin plugin it serves" with no
LICENSE file behind it. That answer conflicts with the architecture the same
README describes forty lines earlier, in two ways.

This repository is vendored *into* the other three, which carry three different
licences (MIT, GPL-3.0, GPL-3.0-or-later). Copyleft here pushes obligations
downstream into repositories that did not choose them, for the sake of a build
script. The dependency also runs inward, so "matching the plugin" had the
direction backwards — this repo does not serve the plugin, the plugin consumes
it. CC0 imposes nothing on any of the three.

A specification also has to be freely implementable. The design assumes third
parties reimplement it: the audio-signature conformance fixture exists so that
"an implementation can be written from that file alone", and federation is
worthless if only one server implementation may exist. A software licence on a
specification invites the question of whether an implementation written from it
is a derivative work; CC0 removes the question rather than answering it.

Same reasoning as the CC0 licence on contributed manifests (JRay-public-server
UR-019): where an artefact's whole purpose is to be copied and reimplemented,
asserting rights over it costs more than it protects.

Text from creativecommons.org, not transcribed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 10:44:14 +02:00
dtourolleandClaude Opus 5 17106f3370 Adopt the config-driven extractor; project overview README
Replaces the copy taken earlier with the newer version from
scene-actor-extraction's traceability-tooling branch, which had moved on: it
takes per-repo settings from a traceability.toml rather than the CLI flags
added here, validates them, and names languages ("rust") rather than making
each repo spell out extensions. That is the better design, so the flags go and
this becomes the single source.

Two fixes on top:

- Config discovery searched from the working directory only, so --root pointed
  at another tree found no traceability.toml and failed with
  "requirement_types is empty" while a perfectly good config sat in the
  directory named. That breaks both intended callers: CI passing --root, and a
  wrapper running the vendored copy. Discovery now starts from --root.
- The test suite had not been migrated with the Config refactor and failed on
  the branch as well as here. All 53 now pass: entry points take a Config,
  ci_executable moved to the Register which owns tier policy, fixtures write a
  real traceability.toml so config discovery is exercised rather than bypassed,
  and the live-register tests take LIVE_REGISTER from the environment since the
  project home holds no component register of its own.

The README becomes a project overview rather than a table of contents: what the
problem is, why a paused-frame answer is the wrong question, why gallery data
never leaves the instance, and why the manifest server can hold no binary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 18:38:59 +02:00
dtourolleandClaude Opus 5 43368cdcdb Project home: system spec, working notes, and setup
Gives the system specification an owner. It defines the PR-nnn project
requirements and SR-nnn cross-component contracts that every component spec
traces up to, and until now it lived in no repository at all.

The three component repositories are linked from the README and gitignored
here rather than added as submodules. A submodule pins a commit, so with
feature branches and worktrees in flight across the components, every
component commit would leave this repository's pointer stale. The dependency
is meant to run the other way: components pull this repository in for the
shared tooling and system spec, both of which change rarely.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 18:15:20 +02:00