review/adversary

Free catalog · v0.0.44

Reviews TypeScript adversaries for SDK usage, rule design, finding quality, tests, packaging, and publish readiness.

Adversary authoring adversary

Reviews TypeScript adversaries for SDK usage, rule design, finding quality, tests, packaging, and publish readiness.

Goals

The adversary is designed to produce a small number of high-confidence, actionable findings grounded in concrete repository evidence. Its review should be deterministic where possible, explicit about impact, and quiet when the available evidence does not justify a finding.

Scope

It evaluates TypeScript adversary packages: manifest identity, SDK usage, permissions, tests, packaging, evidence quality, and publish readiness.

The complete detector or review inventory is maintained in CHECKS.md.

Boundaries

It reviews adversary packages, not arbitrary TypeScript applications or the repositories those adversaries will eventually scan.

SDK source coverage

The SDK dependency follows the published SDK version pinned in package.json. Model review retains evidence-backed findings when repository source coverage is partial, records the limitation, and does not grant a whole-change clean opinion. Provider and output-validation failures are not coverage gaps: they retain failure or model-unavailable reporting and cannot grant a whole-change clean opinion.

Bounded model output repair

Model stages use the SDK output-validation loop with at most two final-generation requests (initial output plus one repair), unless a stage already supplies its own bounded validator. Broker and client schema failures provide specific feedback to final generation; gathered evidence and the original deadline are retained. Rejected completion usage is included in returned totals and terminal or interrupted ModelReviewError failures. Unexpected exceptions from custom model implementations propagate unchanged and do not expose SDK usage totals; custom models should report request failures with ModelReviewError. Exhausted validation remains incomplete and cannot grant a whole-change clean opinion.

Maintainer contract tests also require Go (see test/broker-schema/go.mod) to exercise the production broker schema compiler.

This release uses SDK 0.1.43, including schema repair and interrupted-repair usage preservation.

Provider transport retries and format corrections have their own existing bounds; the two-attempt limit applies to SDK final-generation requests.

npm test downloads the pinned Go broker-schema modules before running the offline contract checks. Go 1.26.6 or newer must be installed: the contract adapter uses GOTOOLCHAIN=local, so it does not download a newer compiler during the checks. CI and release workflows install the Go version declared in test/broker-schema/go.mod and also prepare the modules explicitly.

SDK 0.1.43

This release rebuilds with SDK 0.1.43. SDK PR #73 adds a tested neutral fallback to formatOpinionAsync when concern wording validation is exhausted, preserving completed findings and the ship decision. Reviewers that do not call this API retain their existing opinion behavior. Provider and transport failures remain errors. Domain rules and evidence requirements are unchanged.

More from the registry