feat: unify source and skills for Dever 0.1.2 installation

sdk/native-release.md

@@ -92,16 +92,33 @@ Use a separate author root, not a Dever application's configuration. Place its e
 
 ## Versioned AI skill and public release assets
 
-`skill` is required. Copy the complete standalone `dever-main-skills` checkout into the author inputs, excluding `.git` and temporary files, and list every skill file as `{source,path,sha256}`. Paths are relative to its skill root; the maker publishes them under `skills/dever-language/` in the signed manifest. The two entries above illustrate the shape, not the complete file list. `SKILL.md` is mandatory; at most 256 files, 1 MiB per file and 8 MiB total are allowed.
+`skill` is required. Copy the complete `skills/` directory from the same main-repository revision as the compiler into the author inputs, excluding Git metadata and temporary files, and list every skill file as `{source,path,sha256}`. It is an ordinary repository directory, not a separate checkout or submodule. Paths are relative to its skill root; the maker publishes them under `skills/dever-language/` in the signed manifest. The two entries above illustrate the shape, not the complete file list. `SKILL.md` is mandatory; at most 256 files, 1 MiB per file and 8 MiB total are allowed.
 
 `dever skill path [project-root]` validates and returns the skill belonging to the selected compiler. `dever skill install <new-directory>` installs a small AI entry that resolves the active signed skill on each task. It refuses existing directories. `dever update` and `dever use` change the one active-version journal used by both core and skill; they do not rewrite every user's AI directory. Ordinary users can read the signed skill without the install lock or administrator permissions.
 
-Publish official versions to `shemic/dever-main` GitHub Releases with tag `v<version>`. The v2 signed root catalog separates base `artifacts` from `extensions`. Base includes core/private libraries, bootstrap, host native profiles/sandbox and skill. Each extension declares `{kind,target,artifacts}`; `kind` is `{"type":"runtime","ecosystem":"pip|npm|go"}`, `{"type":"build","ecosystem":"pip|npm"}` or `{"type":"target"}`. Target combines that target's native profiles/CRT and sandbox. Paths and identities cannot overlap. No extension has an independent unsigned manifest or can override base files.
+Publish official assets under `https://git.dever.cc/shemic/dever/dist/<version>/`, independently of Git source access. Git tags may remain `v<version>`; HTTP asset directories use the exact numeric version without `v`. The v2 signed root catalog separates base `artifacts` from `extensions`. Base includes core/private libraries, bootstrap, host native profiles/sandbox and skill. Each extension declares `{kind,target,artifacts}`; `kind` is `{"type":"runtime","ecosystem":"pip|npm|go"}`, `{"type":"build","ecosystem":"pip|npm"}` or `{"type":"target"}`. Target combines that target's native profiles/CRT and sandbox. Paths and identities cannot overlap. No extension has an independent unsigned manifest or can override base files.
 
 `python3 sdk/release-assets.py <release> --output <new-assets> --zstd /absolute/author/zstd` writes `dever-<platform>.manifest.json`, `.manifest.sig`, `.tar.zst`, plus `.ext-<runtime-pip|runtime-npm|runtime-go|build-pip|build-npm|target>-<target>.tar.zst`. Each USTAR contains exactly its signed ordinary artifact files, no directory headers or embedded root metadata. Zstandard uses a checksummed single frame with a maximum 128 MiB window. The publisher also emits `.blob-<sha256>` for bootstrap/dever and every bootstrap/lib dependency. First installation authenticates these raw helpers before executing the launcher's bounded extractor; end users do not need a system zstd executable. Report helper bytes separately from base archive size.
 
 Only explicit install/update, target add and dependency preparation download official resources. The source address is compiled into the toolchain, not application configuration or environment variables. Extension preparation uses closed typed IPC and the existing machine service, storing immutable version/catalog-bound resources under `cache/extensions`. Multiple projects/users share one verified tree. `run/build` and resource reads never download. `update` prepares the new core/skill and the active version's already installed extension selection before publishing the active-version journal; failure keeps the old selection usable. The stable machine launcher/daemon are provisioned by bootstrap, so changes to that protocol require a matching trusted bootstrap installation.
 
+## Public installer and static distribution
+
+`python3 sdk/install-entry.py` generates the root `install` from the canonical `skills/scripts/install.py` and the independently provisioned `skills/assets/release.pub`. `--check` verifies that the committed entry is current. The generated Bash contains the complete installer, so `curl -fsSL https://git.dever.cc/shemic/dever/install | bash` does not need a Git checkout or a separate skill download. Keep download, authentication and bootstrap behavior in the Python/Rust owners; do not maintain a second implementation inside the generated file.
+
+Configure the web server to serve these anonymous HTTPS paths:
+
+```text
+/shemic/dever/install                          generated plain Bash script
+/shemic/dever/dist/latest/dever-<platform>.manifest.json
+/shemic/dever/dist/latest/dever-<platform>.manifest.sig
+/shemic/dever/dist/<version>/dever-<platform>.*  all matching immutable assets
+```
+
+These are explicit static routes, not assumed Git web UI or GitHub-compatible release URLs. Do not return a login page or HTML file viewer. Source repositories can retain their existing access restrictions. Publish the complete immutable version directory first, then switch the latest catalog selection together. Installers authenticate the latest catalog and download payloads only from its signed exact version. Keep old version directories for pinned installations; do not replace a published version's bytes. Release assets are outside Git source history.
+
+For the GitHub-to-new-origin migration, rebuild the core, launcher and daemon with the new compiled origin and a new version before publishing. Already installed old launchers still contain GitHub addresses, and ordinary update does not replace the stable bootstrap pair. Run the new `install` once to provision that pair through the existing bootstrap transaction, then use normal `dever update`. A successful test using older signed bytes proves installation behavior only; it does not prove a newly built release or online migration.
+
 ## Linux first installation
 
 Include the stable launcher and daemon in the same signed release by adding this author field: