Commit Graph
2 Commits
Author SHA1 Message Date
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