AP-034: govern the Auths public naming migration

docs/plans/AUTHS_PUBLIC_NAMING_MIGRATION.md

@@ -0,0 +1,144 @@
+# Auths public naming migration
+
+## Status
+
+Execution plan and human-readable interpretation of
+[AP-SPEC-034](../specs/0034-auths-public-naming-consolidation.md). The sole
+machine-readable naming authority is
+[`release/public-naming.toml`](../../release/public-naming.toml).
+
+This plan does not authorize publication, package deletion or yanking, owner
+changes, an RC tag, a repository rename or archive, deployment, or DNS work.
+
+## Outcome
+
+Users should encounter one product:
+
+```text
+Auths
+├── Rust core: auths
+│   └── proof component: auths-proof
+├── Rust SDK: auths-sdk
+├── JavaScript/TypeScript SDK: @auths-dev/sdk
+├── Python SDK: auths
+├── website: auths.dev
+└── first RC: auths-v1.0.0-rc.1
+```
+
+“Proof” remains useful vocabulary. It describes the portable proof format,
+deterministic verifier boundary, proof exchange, and their implementation
+packages. It no longer competes with Auths as the product name.
+
+## Registry snapshot
+
+The registry snapshot was taken on 2026-07-31 from the official crates.io,
+npm, and PyPI APIs.
+
+- The crates.io owner index for user ID `345389` contains 33 `auths` or
+  `auths-*` packages attributable to `auths-dev/auths`, including
+  repository-less `auths-utils`.
+- Every one of those crates lists `bordumb` as its named owner.
+- `auths`, `auths-sdk`, and `auths-verifier` are already owned coordinates at
+  version `0.1.16`.
+- `@auths-dev/sdk` exists on npm at version `0.1.16` and points to the
+  predecessor repository. `@auths-dev/proof` returns 404.
+- `auths` exists on PyPI at version `0.1.16` and points to the predecessor
+  repository. `auths-proof` returns 404.
+- All visible reverse dependencies of the predecessor crates are other
+  predecessor `auths-*` packages. No non-predecessor registry reverse
+  dependency was observed.
+
+That last observation narrows migration risk; it does not prove there are no
+external users. Registry download totals are nonzero and can include CI,
+mirrors, dependency builds, and direct downloads. Git, path, vendored, copied,
+or unpublished use is not visible in the reverse-dependency API.
+
+## Disposition summary
+
+| Disposition | Count | Coordinates |
+| --- | ---: | --- |
+| Continue | 4 | `auths`, `auths-sdk`, `auths-verifier`, `auths-receipts` |
+| Replace | 10 | `auths-core`, `auths-crypto`, `auths-evidence`, `auths-id`, `auths-index`, `auths-keri`, `auths-mcp-core`, `auths-policy`, `auths-rp`, `auths-storage` |
+| Retire | 19 | All other predecessor coordinates in the authoritative inventory |
+| Delete and reclaim | 0 | None |
+
+Continue does not mean source compatibility. Each continued coordinate crosses
+from the experimental `0.1.x` predecessor to the current architecture through
+an intentional `1.0.0-rc` major transition.
+
+Replace means the old package encoded a boundary the current architecture
+intentionally split. Examples include:
+
+- `auths-crypto` becoming suite and adapter boundaries such as
+  `auths-signature`, `auths-multikey`, and `auths-raw-key`;
+- `auths-id` becoming identity-method adapters and custody boundaries;
+- `auths-keri` becoming the optional `auths-did-keri` adapter;
+- `auths-policy` becoming the pure authority/composition packages plus the
+  separately bounded policy layer; and
+- `auths-storage` becoming custody and explicitly stateful store boundaries.
+
+Retire means no first-RC package adopts the old coordinate. It does not release
+the name or authorize a deprecation upload.
+
+## Why deletion is off the table
+
+Every predecessor coordinate has published bytes. The official Cargo
+publishing documentation states that publication is permanent: versions
+cannot be overwritten and code cannot be deleted. Yanking only prevents new
+resolution in some circumstances; it does not delete the archive or free the
+crate name.
+
+The safe policy is therefore to retain custody. There is no deletion/reclaim
+sequence to approve, and issue 54 authorizes no yank.
+
+## New Rust publication order
+
+The new core facade increases the expected crates.io closure from 27 to 28
+packages. The inventory records nine topological tiers:
+
+1. leaf model/algebra/multikey/exchange-model packages;
+2. assurance, codec, composition, ports, and exchange port;
+3. authority, identity adapters, raw key, receipts, registries, and signature;
+4. author and verifier;
+5. custody, proof component, and base profile API;
+6. configuration and composed profiles;
+7. operations;
+8. runtime; and
+9. the public `auths` and `auths-sdk` roots.
+
+Hosted CI must derive the edges from the candidate manifests. The checked-in
+tiers are a contract, not a substitute for dependency validation. An edge from
+a lower-numbered tier to a higher-numbered tier is a terminal error.
+
+## Migration sequence
+
+| Unit | Repository effect | External effect |
+| --- | --- | --- |
+| `AP34-PR1` | Naming authority, registry evidence, spec and governing amendments | None |
+| `AP34-PR2` | `auths` facade, `auths-sdk`, Cargo graph and Rust examples | None |
+| `AP34-PR3` | npm/Python metadata, imports, current docs and canonical links | None |
+| `AP34-PR4` | Release identity, semantic freeze and adversarial stale-name CI | None |
+| `AP34-PR5` | Accurate predecessor notice and migration/deferral ledger | No archive, rename, yank, or publication |
+| `AP34-PR6` | Align the repository that owns `auths.dev` content | No DNS or deployment without separate approval |
+
+AP-SPEC-032 release-evidence work resumes only after all six units and their
+hosted gates are complete. Its preserved draft must be rebased onto the new
+package catalogue and must regenerate every artifact identity rather than
+editing previously generated evidence by hand.
+
+## Remaining external facts
+
+The following are real gates, not repository-local checkboxes:
+
+- `auths.dev` currently contains predecessor-era package and GitHub links. Its
+  content owner must adopt this inventory before the site can be release
+  evidence for the current implementation.
+- The old repository needs an accurate notice. Calling it wholly unpublished
+  would be false because its `0.1.x` registry packages exist.
+- Registry publication permission for the target `1.0.0-rc` packages is not
+  granted. Custody evidence is not publication authorization.
+- Repository rename and archive decisions remain open and must not be smuggled
+  into naming cleanup.
+
+Until those facts change with evidence, the first-RC naming gate remains
+closed.

docs/plans/GO_TO_MARKET_STRATEGY.md

@@ -422,6 +422,15 @@ Restricted integrations:               =========>
 Customer-operated pilots:                            ===========>
 ```
 
+### Phase 7 prerequisite: one Auths identity
+
+[Specification: AP-SPEC-034, Auths public naming
+consolidation](../specs/0034-auths-public-naming-consolidation.md)
+
+Before release artifacts are frozen, align the product, package, documentation,
+predecessor, website, and release identities under Auths. The proof protocol
+remains an explicit component boundary; it is not a competing product name.
+
 ### Phases 7–8: reproducible candidate and exact claim
 
 [Specification: AP-SPEC-032, Reproducible release candidate and exact
@@ -597,11 +606,11 @@ When using this document to plan or implement work:
 11. Stop at each phase gate and record what was learned before widening
     scope.
 
-The immediate execution program is AP-SPEC-032: record its owner decisions,
-produce the reproducible release candidate, and publish the exact claim bundle.
-AP-SPEC-033 independent review follows. AP-SPEC-027 and AP-SPEC-028 remain
-blocked until that review gate permits the explicitly labeled Phase 10
-developer preview.
+The immediate execution program is AP-SPEC-034 followed by the remaining
+AP-SPEC-032 work: establish one Auths identity, produce the reproducible release
+candidate, and publish the exact claim bundle. AP-SPEC-033 independent review
+follows. AP-SPEC-027 and AP-SPEC-028 remain blocked until that review gate
+permits the explicitly labeled Phase 10 developer preview.
 
 ## Related architecture
 

docs/plans/PHASE_7_OWNER_DECISION_GUIDE.md

@@ -1,5 +1,11 @@
 # Phase 7 owner decision guide
 
+> **Historical decision aid:** this guide predates the owner's issue 54 naming
+> decision. Package and tag alternatives recorded here are not current
+> recommendations. `P7-OD-012`, AP-SPEC-034, and
+> [`release/public-naming.toml`](../../release/public-naming.toml) govern the
+> Auths coordinates.
+
 ## Purpose
 
 This guide explains the choices in the

docs/plans/PHASE_7_RELEASE_OWNER_DECISIONS.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-All 11 decisions were approved by the repository owner on 2026-07-31. This
+All 12 decisions were approved by the repository owner on 2026-07-31. This
 document records policy approval only. It does not authorize an artifact
 publication, RC tag, package upload, claim publication, repository-setting
 change, secret upload, or external-review engagement.
@@ -16,6 +16,12 @@ The read-only
 [Phase 7 release readiness audit](PHASE_7_RELEASE_READINESS_AUDIT.md) maps each
 decision to the current repository and the implementation it blocks.
 
+[AP-SPEC-034](../specs/0034-auths-public-naming-consolidation.md) and
+[issue 54](https://github.com/auths-dev/auths-proof/issues/54) supersede the
+public-coordinate portion of `P7-OD-003` and all of `P7-OD-007`. Their original
+text remains below as decision history; `P7-OD-012` is the governing public
+naming record.
+
 The
 [Phase 7 owner decision guide](PHASE_7_OWNER_DECISION_GUIDE.md) explains the
 available choices and their tradeoffs without approving them.
@@ -32,15 +38,16 @@ or represent the Phase 7 entry gate as passed.
 | --- | --- | --- | --- | --- |
 | `P7-OD-001` | Release license | Keep `MIT OR Apache-2.0` through v1 | Exact license expression approved for RC package and release metadata | approved |
 | `P7-OD-002` | Inbound contribution policy | Choose DCO or CLA with counsel | Selected policy, responsible owner, and effective date | approved |
-| `P7-OD-003` | Artifact catalogue | Source archive, publishable crates, maintained bindings, WASM/native artifacts, assurance bundle | Exact in-scope and excluded release subjects | approved |
+| `P7-OD-003` | Artifact catalogue | Source archive, publishable crates, maintained bindings, WASM/native artifacts, assurance bundle | Exact in-scope and excluded release subjects | approved; coordinates amended by `P7-OD-012` |
 | `P7-OD-004` | Registry publication | Prepare all approved subjects; publish only to explicitly approved registries | Registry list and whether the first RC is staged, private, or public in each | approved |
 | `P7-OD-005` | Supply-chain target | SLSA Build L3 for the first RC | Approved target and any explicitly accepted limitation | approved |
 | `P7-OD-006` | SBOM baseline | SPDX JSON; retain CycloneDX only as additional evidence | Required SPDX version/profile and optional secondary formats | approved |
-| `P7-OD-007` | Tag convention | One immutable semver-compatible RC form | Exact tag pattern and initial ordinal policy | approved |
+| `P7-OD-007` | Tag convention | One immutable semver-compatible RC form | Exact tag pattern and initial ordinal policy | superseded by `P7-OD-012` |
 | `P7-OD-008` | Release approvers | At least one named human approver distinct from build identity | Named approver or approver role and protected-environment rule | approved |
 | `P7-OD-009` | Signing identity | GitHub artifact attestation backed by public Sigstore | Exact issuer, subject, workflow identity, and verification policy | approved |
 | `P7-OD-010` | Public claim approver | Named technical owner | Approver identity or role and approval-record location | approved |
 | `P7-OD-011` | Vulnerability and CRA ownership | Name a security contact and obtain counsel review when external EU distribution is in scope | Security contact, disclosure owner, distribution scope, and counsel decision or explicit not-yet-in-scope record | approved interim policy |
+| `P7-OD-012` | Public Auths identity | One Auths product identity across package coordinates, tags, artifacts, documentation, and the predecessor transition | Exact public map and first-RC identity | approved; execution blocked on AP-SPEC-034 |
 
 ## Approved records
 
@@ -73,6 +80,10 @@ conditions:
 
 ### `P7-OD-003`
 
+> **Historical coordinate record:** the catalogue-shape decision remains
+> approved, but the package names in this block were superseded by
+> `P7-OD-012` before publication or RC tagging.
+
 ```yaml
 decision_id: P7-OD-003
 status: approved
@@ -134,6 +145,9 @@ conditions:
 
 ### `P7-OD-007`
 
+> **Superseded:** no tag using this pattern was created. `P7-OD-012` replaces
+> it with `auths-v<semver>-rc.<positive-ordinal>`.
+
 ```yaml
 decision_id: P7-OD-007
 status: approved
@@ -206,6 +220,25 @@ conditions:
   - "The first RC is technical prerelease evidence, not a general-availability product."
 ```
 
+### `P7-OD-012`
+
+```yaml
+decision_id: P7-OD-012
+status: approved
+decision: "Present the product as Auths. Use auths and auths-sdk on crates.io, @auths-dev/sdk on npm, auths on PyPI, and immutable tags matching auths-v<semver>-rc.<positive-ordinal>, beginning with auths-v1.0.0-rc.1. Retain auths-proof only for accurate proof-specific components and temporary repository identity."
+owner: repository-owner
+decided_at: 2026-07-31
+evidence_or_advice:
+  - "https://github.com/auths-dev/auths-proof/issues/54"
+  - "../../release/public-naming.toml"
+conditions:
+  - "AP-SPEC-034 is a hard gate before remaining AP-SPEC-032 release artifact, metadata, provenance, or tag-contract freeze work."
+  - "The auths crate is a thin consumer core facade over the bounded auths-proof component; the facade must not absorb provider or runtime behavior."
+  - "The predecessor 0.1.x coordinates are an intentional major-version transition, not a source-compatibility promise."
+  - "No deletion, yank, publication, owner change, repository rename, repository archive, tag, deployment, or DNS action is authorized by this record."
+  - "Registry custody, publication order, current documentation, predecessor notice, external website content, and hosted stale-name checks must pass before AP-SPEC-032 release evidence resumes."
+```
+
 ## Auths-native release authorization boundary
 
 Auths MAY produce a separate authorization proof and receipt for the exact

docs/plans/PHASE_7_RELEASE_READINESS_AUDIT.md

@@ -6,6 +6,14 @@ Read-only repository audit for AP-SPEC-032. This document records current
 implementation facts and gaps; it does not approve owner decisions or
 authorize release changes.
 
+> **Historical baseline:** this audit predates issue 54 and AP-SPEC-034. Its
+> `auths-proof-sdk`, `@auths-dev/proof`, PyPI `auths-proof`, and
+> `auths-proof-v*` references describe the reviewed baseline and the now-
+> superseded owner decision. The governing targets are in
+> [`release/public-naming.toml`](../../release/public-naming.toml): `auths`,
+> `auths-sdk`, `@auths-dev/sdk`, PyPI `auths`, and
+> `auths-v1.0.0-rc.1`.
+
 The code and workflow baseline reviewed was `main` at `6f8df76`. The audit was
 prepared on the documentation-only specification branch. That branch does not
 change release behavior.

docs/specs/0032-reproducible-release-candidate-and-exact-assurance-claim.md

@@ -1,16 +1,17 @@
 # AP-SPEC-032: Reproducible release candidate and exact assurance claim
 
-**Status:** Specified — owner-decision subgate approved; execution still
-requires the remaining Phase 7 entry evidence and separate Phase 7 and Phase 8
-pull requests
+**Status:** Specified — owner-decision subgate approved; remaining execution is
+blocked on AP-SPEC-034 public naming consolidation, the remaining Phase 7 entry
+evidence, and separate Phase 7 and Phase 8 pull requests
 
 **Governs:** Phase 7 and Phase 8 of the
 [Post-Milestone 6 Productization and Release Plan](../target-state/POST_MILESTONE_6_PRODUCTIZATION_AND_RELEASE_PLAN.md)
 
 **Aligned with:** [Post-Milestone-6 Technical and Go-to-Market
 Alignment](../plans/POST_MILESTONE_6_TECHNICAL_AND_GO_TO_MARKET_ALIGNMENT.md)
 
-**Depends on:** AP-SPEC-0011, AP-SPEC-0025, AP-SPEC-0026, the completed
+**Depends on:** AP-SPEC-0011, AP-SPEC-0025, AP-SPEC-0026,
+[AP-SPEC-034](0034-auths-public-naming-consolidation.md), the completed
 Milestone 6 baseline on `main`, the formal assurance manifest, canonical
 fixtures, conformance inventories, benchmark evidence, and the existing
 release-check machinery
@@ -143,6 +144,13 @@ The current decision state is maintained in the
 [Phase 7 release owner decision register](../plans/PHASE_7_RELEASE_OWNER_DECISIONS.md).
 An unresolved recommendation in that register is not approval.
 
+[AP-SPEC-034](0034-auths-public-naming-consolidation.md) supersedes the public
+coordinates previously selected in `P7-OD-003` and `P7-OD-007`. Remaining
+release implementation MUST use
+[`release/public-naming.toml`](../../release/public-naming.toml) and MUST NOT
+freeze an artifact or metadata graph using `auths-proof-sdk`,
+`@auths-dev/proof`, PyPI `auths-proof`, or an `auths-proof-v*` RC tag.
+
 | Decision | Recommended default | Required before |
 | --- | --- | --- |
 | Release license | Keep `MIT OR Apache-2.0` through v1 | Freezing package and release metadata |
@@ -159,6 +167,9 @@ An unresolved recommendation in that register is not approval.
 
 The entry revision MUST also satisfy:
 
+- AP-SPEC-034's exit gate has passed, including registry custody, package
+  publication order, current documentation, predecessor notice, external
+  website alignment, and hosted stale-name enforcement;
 - Milestones 0 through 6 are complete on `main`;
 - no open branch contains a required semantic or evidence fix;
 - all required checks on the candidate revision are terminal and successful;
@@ -591,6 +602,8 @@ large pull request.
 
 The minimum boundaries are:
 
+0. **AP-SPEC-034 naming PRs.** Complete every bounded naming, predecessor, and
+   external-content unit before release metadata or artifacts are frozen.
 1. **Decision and specification PR.** Record owner decisions, this
    specification, schemas, and the execution plan. No release implementation.
 2. **Semantic-freeze PR.** Add the freeze inventory and drift enforcement.
@@ -620,16 +633,19 @@ behavior. Provider/domain behavior MUST remain profile- or domain-owned.
 ## 15. Delivery order
 
 1. Record the owner decisions in Section 5.
-2. Freeze the semantic and artifact schemas.
-3. Implement and validate the semantic-freeze inventory.
-4. Upgrade release evidence to the approved SBOM and provenance contract.
-5. Implement clean preparation and no-rebuild promotion.
-6. Run two isolated preparations and close reproducibility gaps.
-7. Merge the final candidate revision after all checks pass.
-8. Promote the immutable RC tag and publish its evidence bundle.
-9. Build the exact claim registry against those immutable subjects.
-10. Publish and synchronize the human-readable assurance statement.
-11. Submit the fixed candidate and claim bundle to Phase 9 independent review.
+2. Complete AP-SPEC-034 and reconcile every release input to the Auths naming
+   inventory.
+3. Freeze the semantic and artifact schemas.
+4. Implement and validate the semantic-freeze inventory.
+5. Upgrade release evidence to the approved SBOM and provenance contract.
+6. Implement clean preparation and no-rebuild promotion.
+7. Run two isolated preparations and close reproducibility gaps.
+8. Merge the final candidate revision after all checks pass.
+9. Promote the immutable `auths-v1.0.0-rc.1` tag and publish its evidence
+   bundle only after separate exact-manifest authorization.
+10. Build the exact claim registry against those immutable subjects.
+11. Publish and synchronize the human-readable assurance statement.
+12. Submit the fixed candidate and claim bundle to Phase 9 independent review.
 
 ## 16. Completion and handoff