Release and distribution checks

Run release checks from a clean worktree and record the exact source state.

1. Offline code gates

make lint
make typecheck
make test

Confirm public responses still contain:

• classification;
• parse_confidence;
• refs;
• warnings;
• trace.

2. Fixture build and verification

uv run dicom-kb build-fixture \
  --edition 2026b \
  --force

uv run dicom-kb verify \
  --edition 2026b

Review build metrics, gate failures, warnings, manifest digest, artifact checks, and database metadata.

3. Public-surface coverage

Confirm offline tests cover:

• PS3.5 VR, Transfer Syntax, and encoding explanation;
• PS3.10/PS3.18 media and DICOMweb lookup;
• PS3.16 SR template, context-group, and code lookup;
• enumerated and defined terms with deterministic context;
• cited text fallback, including PS3.7/PS3.8 topics;
• contextual effective-type ambiguity;
• CLI, Python, MCP, and JSON-schema consistency;
• agent regression with deterministic expected traces.

4. Local official-edition gates

After fetching and building the full supported part set:

make test-dicom-integration
make test-dicom-release
make test-dicom-current

The strict release gate requires the expected parts and semantic rows rather than passing through skips.

Representative official examples should include the current release checklist’s encoding, media, DICOMweb, template, context-group, code, value-term, and text-retrieval cases.

5. Build-quality review

Inspect:

• per-part parser warnings;
• unresolved include rate;
• unresolved cross-reference rate;
• nonzero expected entity counts;
• source-reference counts;
• build metadata;
• manifest/database digest agreement.

Use explicit threshold gates with a documented edition baseline.

6. Agent regression

Maintain at least the release checklist’s required case count and verify:

• exact tool selection;
• exact arguments;
• expected call order where relevant;
• response evidence retention;
• reference-agent results;
• external-agent adapter compatibility when released.

A model answer cannot compensate for a missing required tool trace.

7. Distribution audit

Release artifacts must not include:

• official XML, PDF, HTML, CHTML, or target databases;
• generated full SQLite or other database;
• generated full-text or vector index;
• bulk parsed JSON;
• standalone PS3.16 terminology;
• bulk context-group or coded-concept export.

PyPI, source, container, and GitHub artifacts contain code and dependencies only. Users fetch and build official editions locally.

Confirm legal notices remain in the README, NOTICE, generated manifest model, and applicable user-facing metadata.

8. Documentation synchronization

Before publishing a stable source release:

1. synchronize the documentation to the exact release commit;
2. update CLI, MCP, Python, configuration, coverage, and limitation references;
3. update docs-source.json in the documentation repository;
4. run documentation format and validation gates;
5. review the preview deployment;
6. publish release notes that record any official-artifact tests that could not run.

Do not publish documentation for unreleased behavior as current stable behavior.