feat: establish standalone Argand Site Registry

docs/superpowers/specs/2026-09-12-standalone-design.md

@@ -0,0 +1,37 @@
+# Standalone Site Registry design
+
+The user approved continuing standalone packaging, release CI and public governance
+on 2026-09-12. Preserve the existing AGPL-3.0-or-later license and all data terms.
+
+Create a separate two-crate workspace containing the current registry and atomic
+file helper. Preserve Rust module boundaries and the existing source adapters,
+SQLite schema, receipt contracts, explicit reviews and regional resolution.
+Record the exact signed Argand baseline and original file hashes in UPSTREAM.json.
+Do not copy Argand history, deployment configuration, datasets or signing keys.
+The existing Argand checkout and shared build caches remain owned by the beta agent.
+
+A separate package is preferable to a permanent second implementation or a new
+hosted service: it reuses the existing contracts and runs locally. Extracting only
+the CLI would lose the reusable Rust API. Preserve both CLI and library, and prove
+non-Rust consumption through the JSON CLI without creating a second resolver.
+
+Ship a focused Cargo.lock, complete code license, beginner quickstart, native Rust
+and Python examples, contribution requirements, trust policy and incident/revocation
+procedure. Source releases come from an exact committed tree, with deterministic
+archives and hash receipts; signing is an explicit local release action. CI checks
+formatting, all targets, strict lints, tests, documentation and a native all-source
+fixture, and exercises the archive outside its Git checkout. No CI signing key,
+provider credentials, production runner or automatic dataset promotion is included.
+
+Keep Argand's current consumer operational. Until an independently hosted release
+is accepted into Argand, its embedded copy remains the active consumer; document
+the cutover and verify baseline parity. The initial standalone package has no
+runtime behavior changes. Each dataset publisher chooses its own external trust
+roots; review policy is public and cannot be replaced by popularity or hostname
+similarity. An authenticated release is not proof of source accuracy or malware safety.
+
+Acceptance: preserve upstream Rust/schema bytes; build with only this workspace;
+run the complete two-crate offline gates plus fresh CLI and Rust/Python examples;
+produce the same source archive twice; reject modified releases, unsafe paths and
+release overwrites; inspect the initial Git inventory for private/unrelated content.
+Remote publication and runner activation are separate from local package readiness.