Consolidate public product and package naming under Auths

[bordumb]

Summary

Present the project publicly as Auths, using auths.dev, instead of treating Auths Proof as the long-term product name.

“Proof” should describe a protocol mechanism or internal package boundary. It should not unnecessarily narrow a system that covers authority, delegation, custody, policy, verification, and multiple transports, identity methods, and cryptographic algorithms.

This work must produce one coherent naming system before the first release candidate.

Target naming

Surface	Target
Product / project	Auths
Website	auths.dev
Core Rust package	auths
Primary Rust SDK	auths-sdk
npm SDK	@auths-dev/sdk
Python SDK	auths
Release tags	auths-v<version>, beginning with auths-v1.0.0-rc.1
Proof-specific internal boundary	auths-proof where the name accurately describes the component

The existing auths-proof repository name may remain temporarily if renaming it would disrupt active work. Repository renaming must be decided and executed as its own bounded migration.

Context

An earlier, unpublished Auths implementation exists in the auths-dev/auths repository and owns several auths-* crates.io coordinates. That implementation was coupled to architectural choices that the current project intentionally replaced.

The project is prelaunch and has no known external users. A clean namespace transition is therefore possible, but registry history must not be changed blindly. Published crates can depend on one another, deletion eligibility varies by crate, and deleting an official-looking name can make it available for third-party reuse.

Required work

1. Create the authoritative naming inventory

Inventory every public name currently used across:

• Cargo packages and Rust import names
• npm and Python packages
• repository and workspace paths
• documentation and examples
• CI and release workflows
• tags, artifacts, attestations, and provenance subjects
• container images and deployment names
• URLs and generated API documentation

Record the current name, target name, compatibility consequence, and owning PR for every change.

2. Classify existing crates.io packages

Classify every crate published by the earlier Auths project as one of:

• Continue: the conceptual responsibility remains stable; publish the current implementation through an intentional major-version transition.
• Retire: the concept is obsolete; retain control and mark it superseded.
• Replace: the meaning changed materially; use a new coordinate.
• Delete and reclaim: allowed only when deletion eligibility is verified, there are no external reverse dependencies, the replacement is package-ready, and the publication sequence prevents losing the name.

Capture current owners, versions, reverse dependencies, downloads, deletion eligibility, and the new package dependency order.

3. Apply the public naming map

Update the selected public surface so that users encounter Auths, not competing Auths/Auths Proof product identities.

At minimum, address:

• package manifests and lockfiles
• Rust examples and integration instructions
• npm and Python metadata
• READMEs, website copy, specifications, and release documentation
• release workflow package lists and provenance subjects
• RC tag conventions
• generated docs and API examples

Historical documents may retain old terminology when changing it would misrepresent the record, but they must be clearly identified as historical.

4. Retire the earlier repository

Prepare auths-dev/auths for archival with a concise notice that:

• it is an unpublished experimental predecessor;
• it has been superseded by the current Auths implementation;
• it is retained as research history and prior art;
• new adopters should use auths.dev and the current repository.

Archive the repository only after useful custody, Secure Enclave, storage, and signing ideas have either been migrated or explicitly deferred.

5. Protect release integrity

Update release specifications and gates so that:

• no first RC contains conflicting public package names;
• all registry coordinates are owned by the intended account or team;
• package dependency order has been verified with packaging/dry-run evidence;
• tags, artifacts, checksums, attestations, and documentation use the same product/version identity;
• no crate deletion, package publication, repository rename, or RC tag creation is implied by a documentation-only PR.

Acceptance criteria

• One checked-in naming inventory is the authoritative source for all public coordinates.
• The supported public product is consistently called Auths.
• The primary SDK coordinates are auths-sdk, @auths-dev/sdk, and auths for Rust, npm, and Python respectively.
• auths-proof remains only where “proof” accurately names a bounded component or temporary repository coordinate.
• All earlier crates.io packages have an evidence-backed Continue/Retire/Replace/Delete classification.
• No registry deletion is performed without verified eligibility and an approved reclaim/publication sequence.
• The old repository has an archival/migration notice and no longer appears to be a competing active product.
• Release documentation uses auths-v1.0.0-rc.1 as the first-RC identity.
• CI checks for stale public naming outside explicitly approved historical locations.
• Package builds, examples, documentation links, and release dry runs pass after the migration.

Exclusions and separate authorization gates

This issue does not by itself authorize:

• deleting or yanking crates.io packages;
• publishing packages to crates.io, npm, or PyPI;
• renaming or archiving either GitHub repository;
• creating or promoting an RC tag;
• changing domain or DNS configuration.

Each destructive or externally visible action requires its own verified execution step and explicit authorization.

[bordumb]

AP-SPEC-034 public naming consolidation is now reconciled across all six bounded units:

• AP34-PR1 naming authority and inventory: AP-034: govern the Auths public naming migration #55
• AP34-PR2 Rust facade and SDK coordinates: AP-034: restore Auths Rust package coordinates #56
• AP34-PR3 npm, Python, and current documentation: AP-034: align Auths language SDKs and current docs #57
• AP34-PR4 release identity and enforcement: AP-034: enforce Auths release identity #58
• AP34-PR5 predecessor notice and archival-readiness ledger: Document the experimental Auths predecessor auths#412
• AP34-PR6 external auths.dev content alignment: AP34-PR6: align auths.dev with the current Auths repository auths-site#36

Evidence:

• the authoritative naming and release-identity checks passed in hosted CI on the merged implementation PRs;
• the predecessor notice accurately records the experimental 0.1.x publication history and directs new adopters to the current implementation;
• on 2026-08-03, the live https://auths.dev navigation, primary source CTA, and shared footer were verified to link to https://github.com/auths-dev/auths-proof rather than the predecessor repository.

This closes the naming blocker for resuming AP-SPEC-032 release-evidence work. It does not authorize or claim package publication, RC-tag creation, repository rename or archival, package deletion/yanking, production release promotion, or any external review gate.