# 2.0 Package And Capability Topology
This document freezes package boundaries before implementation. All packages
use Rust 1.90.0 as their MSRV and publish in lockstep at 2.0.0. The root
`base64-ng` package remains the stable entry point.
## Capability Graph
The exact core edges are:
```text
std -> alloc
stream -> std
checked-backend -> simd
secrets -> (no implicit feature)
```
High assurance is an attested build/runtime policy, not a Cargo feature.
`cargo test --all-features` remains valid because Cargo feature unification
cannot select high assurance.
`secrets` becomes a functional, dependency-free storage and explicit-exposure
capability at Commit 18. Commit 19 adds bounded constant-time-oriented secret
decoding without changing this feature edge or adding dependencies. Commit 20
adds bounded constant-time-oriented secret encoding under the same edge.
Commit 24 activates `checked-backend` as an allocation-free redundant ordinary
backend verification mode with process-local health and quarantine. Ordinary
type layout and auto traits remain invariant when either name is enabled.
## Published Packages
| `base64-ng` | existing | `no_std`; optional `alloc`, `std` | zero | reviewed isolated core/ISA boundary | yes | scalar capability behind `secrets`; ordinary types unchanged |
| `base64-ng-derive` | existing | compiler-host proc macro | zero | deny | generated fixed-size operations | emits secret code only when explicitly derived |
| `base64-ng-sanitization` | existing | `no_std`; optional `alloc`, `std` | exact reviewed `sanitization` | deny locally | bounded protected fill | explicit protected-memory/assurance integration |
| `base64-ng-serde` | existing | `no_std + alloc`; optional `std` | `serde` | deny | visitor-level where supported | no implicit secret deserialization |
| `base64-ng-bytes` | existing | `no_std + alloc`; optional `std` | `bytes` | deny | `Buf`/`BufMut` progress | secret behavior capability-gated |
| `base64-ng-subtle` | existing | `no_std`; optional `alloc`, `std` | exact `subtle` | deny | not applicable | sealed 2.0 secret comparison boundary; public length and `Choice` result explicit |
| `base64-ng-tokio` | existing | `std` | `tokio` | deny | yes, read and write | bounded secret frames only behind `secrets` |
| `base64-ng-mime` | new | `no_std + alloc`; optional `std` | core only | deny | yes | no secret surface |
| `base64-ng-pem` | new | `no_std + alloc`; optional `std` | core only | deny | yes | bounded frames behind `secrets` |
| `base64-ng-multibase` | new | `no_std`; optional `alloc`, `std` | core only | deny | yes | no secret surface |
| `base64-ng-imap` | new | `no_std`; optional `alloc` | core only | deny | yes | no secret surface |
| `base64-ng-password` | new | `no_std`; optional `alloc` | core only | deny | bounded one-shot record/field transforms | no password or secret input |
| `base64-ng-openpgp` | new | `no_std + alloc`; optional `std` | core only | deny | yes | bounded frames behind `secrets` |
| `@valkyoth/base64-ng-wasm-loader` | new JS/npm companion | JavaScript host | versioned WASM artifacts | no Rust unsafe in loader | loader selection only | ordinary codecs only |
“Core only” means a dependency on the matching `base64-ng` package, not zero
dependencies. Every ecosystem dependency remains isolated to its companion and
must pass its own license, advisory, source, and ownership review.
`@valkyoth/base64-ng-wasm-loader` is published to npm rather than crates.io. Its
JavaScript loader contains no Rust unsafe code; the two private wasm artifact
builds use a separately inventoried fixed-buffer ABI. The package ships only
its ES module, declarations, licenses, README, and immutable scalar/SIMD wasm
artifacts. It has no JavaScript dependencies and no secret API.
## Feature-Unification Contract
The same `base64-ng` package may be enabled transitively by unrelated
dependencies with `simd`, `secrets`, or `checked-backend`. Cargo unifies those
features. Therefore:
- ordinary types keep identical size, alignment, `needs_drop`, methods,
behavior, and auto-trait contracts across all combinations;
- secret types are separate named types and always use scalar
constant-time-oriented computation;
- `checked-backend` may add ordinary verification work but cannot turn an
ordinary value into secret storage;
- `simd` may add ordinary dispatch choices but cannot alter public type layout;
- no-default-features plus `secrets` remains allocator-free; and
- high assurance is selected only through explicit attestation policy.
`scripts/check-2.0-feature-contract.sh` enforces the current ordinary ABI
baseline and downstream alias/unification behavior. Later commits extend the
same test rather than replacing it.