Skip to content

Final transfer and publishing guide

Publisher: hhftechnology. Final repository: hhftechnology/bharat-judgements. Container: docker.io/hhftechnology/bharat-judgements.

All implementation stays in this checkout. The commands below are for the owner to perform after reviewing the local changes. Nothing here has been transferred, pushed, uploaded or submitted automatically. The workspace folder can retain its current name; renaming a OneDrive directory is unnecessary for package branding.

Current release checks: the local container scan previously reported 44 HIGH findings in Debian packages without fixed versions. CI fails on fixable HIGH and CRITICAL findings; recheck the current scan before publishing. The Calcutta certificate chain fails verification; a configured Calcutta-only exception was tested, but verified defaults remain enabled. Claude/Grok application install tests are still pending. See the validation results.

1. Review and validate locally

git status --short
git diff --stat
python -m pip install -e '.[dev,mcp]' build twine
python -m pytest -q
python -m ruff check .
python -m ruff format --check .
python scripts/package_plugins.py --check
python scripts/package_plugins.py --zip
python scripts/mcp_smoke.py
python -m mkdocs build --strict
python -m build
python -m twine check dist/*.whl dist/*.tar.gz
docker build -t hhftechnology/bharat-judgements:0.6.0 .
python scripts/mcp_smoke.py --image hhftechnology/bharat-judgements:0.6.0

Use the project's configured interpreter/virtual environment rather than an unconfigured system Python. The lock can be refreshed intentionally using:

uv pip compile pyproject.toml --extra mcp --python-version 3.12 --universal --generate-hashes --output-file requirements-mcp.lock
pip-audit --disable-pip --no-deps -r requirements-mcp.lock

Before release, run every script listed in tests/integration/README.md and python scripts/live_release_checks.py. A live failure is a release blocker for that advertised workflow; offline tests alone do not prove current portal health.

Review the validation results, remaining limitations and user documentation changes. Stage only reviewed files, including the existing documentation changes you want to ship. Use git add -A only after that review, then commit locally. No commit or tag is created by this guide automatically.

2. Configure registries before creating the release

Create the Docker Hub repository hhftechnology/bharat-judgements. Add a narrowly scoped Docker Hub write token as GitHub Actions secret DOCKERHUB_TOKEN.

Create GitHub environments dockerhub and pypi, with owner review protection. On PyPI, register a pending trusted publisher for project bharat-judgements, owner hhftechnology, repository bharat-judgements, workflow python-publish.yml, environment pypi. A former distribution's publisher configuration does not automatically authorize the renamed distribution.

The documentation deploys to GitHub Pages through Actions. To use Vercel instead or as an additional preview, import this GitHub repository in Vercel. The repository's vercel.json configures the MkDocs install/build commands and publishes the generated site/ directory. It selects Vercel's Other framework preset, and .vercelignore limits the build inputs to documentation, theme overrides and source needed to render API reference pages. It installs the docs toolchain in an isolated virtual environment to avoid modifying Vercel's externally managed Python. Only the generated static site/ is published; the SDK is not deployed as an application. Set the project's production domain as the SITE_URL environment variable in Vercel so generated canonical links point to the deployed site; GitHub Pages continues to use its configured URL by default. Inspect the published privacy, terms and support links before official directory applications.

The release workflow reruns offline validation, container scanning and live checks before publishing. Image builds generate SBOM/provenance. Python wheels, source distribution and plugin ZIPs are stored as release workflow artifacts. PyPI and Docker Hub publication have separate job statuses; one registry's success does not imply the other's success.

3. Tag and publish the reviewed release

After the pushed branch passes CI and the reviewed changes are on the release branch:

git tag -a v0.6.0 -m 'Bharat Judgements 0.6.0: breaking rename and local MCP'
git push origin v0.6.0
gh release create v0.6.0 --title 'Bharat Judgements 0.6.0' --notes-file docs/about/migration.md
gh run list --workflow python-publish.yml

Approve the protected registry jobs only after checking their validation evidence. Confirm the wheel is on PyPI, the 0.6.0 image is on Docker Hub, and its digest matches the workflow output. Pin deployments to that digest. latest updates only through the validated release workflow.

docker pull hhftechnology/bharat-judgements:0.6.0
docker image inspect hhftechnology/bharat-judgements:0.6.0 --format '{{json .RepoDigests}}'
$releaseCommit = git rev-parse 'v0.6.0^{commit}'

Run scripts/prepare_submissions.py --commit with that full public commit and --image-digest with the published sha256:... digest. It prepares Docker/Grok entries, a pinned-marketplace/ and digest-pinned plugin ZIPs without opening PRs or uploading anything. Use those pinned ZIPs for official review uploads. Publish the prepared marketplace in a reviewed follow-up packaging commit and record that full public commit. Register Codex with --ref FULL_PACKAGING_SHA. For Claude/Grok, clone and check out that verified commit and add its local marketplace directory; this avoids floating branch references. Keep the generated release-pins.json with the submission materials. Do not submit the initial tag-based package as a digest-pinned artifact.

4. Make local marketplaces installable

After the repository and Docker image are public:

claude plugin marketplace add hhftechnology/bharat-judgements
claude plugin install bharat-judgements@hhftechnology
codex plugin marketplace add hhftechnology/bharat-judgements
codex plugin add bharat-judgements@hhftechnology
grok plugin marketplace add hhftechnology/bharat-judgements
grok plugin install bharat-judgements --trust

Use Codex's Plugins UI to install the discovered entry; current CLI versions also offer codex plugin add. Validate Claude with claude plugin validate ./plugins/claude --strict, and Grok with grok plugin validate ./plugins/grok. Test each in a fresh session with court discovery and a representative PDF retrieval. Local generation checks do not substitute for each application's install test.

Docker MCP Toolkit v0.43+ can create a local catalog directly from the image:

docker mcp catalog create hhftechnology/bharat-judgements-catalog:0.6.0 --title 'Bharat Judgements' --server docker://hhftechnology/bharat-judgements:0.6.0

Local validation created catalog hhftechnology/bharat-judgements-local:0.6.0 and profile bharat-judgements-validation. The gateway discovered all 30 tools:

docker mcp gateway run --profile bharat-judgements-validation --dry-run --verify-signatures=false

Signature verification is disabled explicitly for the locally built, unsigned image during this test. Published images should use the registry's signing policy.

This creates a local catalog; it does not publish it or add the server to Docker's official catalog. Connect it through your Toolkit profile using that installed version's docker mcp profile and gateway help.

5. Official directory submissions

  • Docker: follow the registry contribution guide, supplying the public release repository, Dockerfile, pinned image and generated server entry. Run the registry's validation and tool-discovery checks before opening your PR.
  • Claude: validate the package and submit through Claude's plugin publication workflow, pointing to the marketplace, published documentation and install instructions.
  • Codex: upload the Codex ZIP under your verified hhftechnology developer identity through the plugin submission workflow. Include MCP from the initial submission. The package targets local Docker; confirm the directory supports that install surface before submission. A hosted connection, if required by the directory, is a separate deployment project.
  • Grok Build: use the xAI contribution guide, pin the full public commit and plugin subdirectory, regenerate its index, validate the catalog, and open the submission PR.

For Codex MCP review, supply five positive and three negative cases from packaging/review-cases.json, a reviewer-accessible demo recording and verified publisher identity. Those external materials cannot be fabricated by local packaging. Directory category choices and current schema requirements must be confirmed in the submission UI.

Track prepared → published artifacts → submitted → accepted separately for each platform. Never describe an open PR or uploaded draft as an accepted listing.