feat: sector schema endpoints, plugin-absence warning, and shared test scaffolding

[LKSNDRTMLKV]

Three issues from the open-issue audit, the duplication work they surfaced, and the 0.12.0 release.

Closes #175. Closes #144. Closes #85.

Six commits, one concern each.

feat(node) — name catalogued sectors with no plugin (#175)

One line at boot listing them, at warn. Passthrough is a legitimate
configuration so this does not refuse to boot — but a sector with no plugin and
a sector whose plugin found nothing wrong both produce a determination with no
findings, so from the outside they were indistinguishable, and "no violations"
read as "checked and clean" when it could mean "never checked".

warn rather than info because a production node loads a full signed set from
the release pipeline, so a gap there is a misconfiguration, and info is where
it would be missed.

feat(integrator) — serve sector JSON Schemas (#144)

Three unauthenticated routes: list, current, pinned-by-version (a leading v is
accepted). Resolved through the same VersionedSchemaRegistry the publish gate
validates against — never a copy, which would drift in the direction where a
body passes here and fails at publish.

Descriptions are stripped, deliberately and temporarily. #144 is blocked on
the schema prose being audited: those fields make regulatory assertions never
checked against primary text, and two electronics descriptions once asserted an
adoption date, an effective date, three named priority product classes and a
phase-two date for an act that does not exist. Inside a library those are
developer comments; on a public endpoint they become a product surface a
consumer reads, caches and relies on.

So the machine-readable contract ships and the prose does not. Everything that
decides accept or reject — types, enum, required, pattern, bounds,
additionalProperties — is served in full, which is what an SDK actually needs
to pre-validate. This is a holding position and is marked as one in the module
docs: restore the descriptions once the audit verifies them. strip_descriptions
and its single call site are the only things to remove.

The stripper is schema-aware rather than a blanket key removal: under
properties, $defs/definitions and patternProperties the keys are
author-chosen names, so a property legitimately called description would be
deleted by a naive walk, taking a real field out of the contract. No schema
declares one today; the test pins it so the first one to do so is safe.

title is kept — short labels, not assertions.

Spec updated: three path files, a Problem component schema (RFC 7807, which
these routes actually return), and the three unauthenticated routes added to the
lint baseline alongside the existing ones.

test: — one Postgres harness, and tempfile for keystores (#85)

start_pg had reached eight copies that had drifted into six distinct
implementations, each with its own hardcoded 1500ms readiness sleep. It now
lives once in dpp_dal::test_harness (start_pg, start_pg_raw,
start_pg_before) behind a dev-only test-harness feature.

Nine keystore sites moved from a hand-built std::env::temp_dir() path to
tempfile::tempdir(). Severity was low and stays stated plainly — throwaway
keys, literal passphrases, nothing production-adjacent reads those paths — but
they hold Ed25519 private keys, get no restrictive permissions, and every run
left the file behind. #85 suggests routing these through the harness; they are
inline instead, because coupling a crypto concern to a Postgres helper buys
nothing.

test: — the in-memory repository double, and a gate

impl PassportRepository for InMemoryPassportRepo was copied into three suites.
The impl blocks were byte-identical; the structs had already diverged, one
having grown Arc + Clone the other two lacked. Now one home in
dpp_dal::in_memory_repo, behind the same feature, cloneable so it serves all
three.

just harness-check is the signal that was missing, wired into just check
alongside subjects-check and mod-rs-check. It fails when either shared
helper is defined outside its home, and names what to use instead. Verified to
fail before being wired in — both rules were tripped deliberately and reverted;
the diff carries no trace.

The eight copies existed with a comment above them explaining the problem, so
the rule without the gate would have decayed the same way.

No new crate

The first attempt at #85 added a dpp-test-support crate, which #85 itself
proposes. It was discarded: every consumer already depends on dpp-dal, and a
crate holding one function for callers who could already see it earns nothing
against the no-fission-before-1.0 rule. dpp-dal is publish = false, so the
feature ships nowhere.

The wider duplication was measured rather than assumed, and most of it is not
duplication: the three serde_json::Value passport builders are wire-shaped for
HTTP tests, a different thing from the typed builders, and the TestAuthProvider
/ AlwaysFail doubles hash differently per suite — small, purpose-built, and
merging them would couple unrelated tests to one double's behaviour. The three
typed passport builders are a real candidate, deferred with a written trigger
rather than rejected. All of that is recorded in CLAUDE.md so it is not
re-litigated.

chore(release) — 0.12.0

MINOR under the pre-1.0 convention: new endpoints, no breaking change in this
batch. The [Unreleased] section carried an earlier breaking entry
(publishValid → sectorDataValid), which a minor bump may contain.

#161 is not in this release. The GS1 Digital Link route still answers 404
for a suspended passport; it needs find_by_gtin_any_status, which is on
dpp-core's main but not in the published 0.18.0 this engine pins. Deferred to
the next patch by decision, not oversight.

Verification

just check green: fmt, clippy, the debug/subject/mod-rs/harness/spec-version/
outbound/grants/migrations gates, 841 tests, integration-suite compile, and
cargo audit. spec-version-check confirms api/openapi.yaml and Cargo.toml
agree on 0.12.0. The OpenAPI bundle is regenerated and lints clean (1 pre-existing
warning class, 37 baselined).

Noted, not fixed

api/components/responses/NotAcceptable.yaml declares application/problem+json
but references the {error, message} ApiError schema. The resolver emits
RFC 7807 there. Pre-existing and out of scope for this branch.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics -7 complexity · -5 duplication

Metric	Results
Complexity	-7
Duplication	-5

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}