feat(release): Add Stable 1.0 maintenance path

.agents/skills/cryptad-architecture/SKILL.md

@@ -240,6 +240,25 @@ Use this skill when you need to:
   platform, FCP, and HTTP boundary suites also require `package-info.java` in the production
   packages they own.
 
+## Release-tooling boundary
+
+- `tools/release-certification/cryptad_certification/engines/` owns side-effect-free policy and
+  evidence evaluation. Stable 1.0 GA remains in `stable_1_0_ga*`; later routine maintenance and
+  security hotfixes share the `stable_1_0_maintenance*` engine family and one closed policy.
+- `tools/release-certification/protected/stable_maintenance_publication.py` owns protected-boundary
+  materialization, exact-state revalidation, publication receipt verification, and successor
+  activation. Do not import a publication client into the certification engine.
+- `tools/release-certification/publication-backend/` is the separately built, attested provider
+  wheel. Hosted publication jobs load it only from the authenticated installation directory; the
+  candidate checkout is not a provider source.
+- `.github/workflows/stable-1.0-maintenance-*.yml` owns the protected input, Windows package,
+  backend-wheel, candidate-freeze, authorization, publication, independent-verification, and
+  activation orchestration. These workflows validate refs and exact artifacts but never create or
+  merge release/hotfix branches.
+- `build-logic/src/main/kotlin/cryptad/PortableArchiveNormalizer.kt` and the distribution/runtime
+  convention plugins own deterministic portable archive construction. The independent Python
+  archive gate verifies those bytes; neither layer is a substitute for the other.
+
 ## Architecture overview (by package)
 ### Core network layer (`network.crypta.node`)
 - Node coordination: `Node.java`

.agents/skills/cryptad-core-updater/SKILL.md

@@ -94,3 +94,34 @@ Use this skill when working on:
 - UOM wire compatibility keeps legacy field/type strings where required:
   - field payload names such as `"mainJarKey"`, `"mainJarVersion"`, `"mainJarFileLength"`
   - message type strings `"CryptadUOMRequestMainJar"` / `"CryptadUOMSendingMainJar"`
+
+## Stable 1.0 maintenance descriptor publication
+
+For a Stable 1.0 maintenance or security-hotfix candidate, `stable-maintenance` generates
+deterministic `core-info.json` bytes bound to the exact frozen packages. Require the canonical
+integer `version`, public release page, sorted supported `<arch>.<ext>` package keys, public CHK or
+store URLs, and authenticated package sizes. Every required candidate package must appear exactly
+once; do not add a misleading local SHA-256 field, placeholder, private insert URI, or local path.
+
+Include the descriptor digest in checksums, provenance, authorization, and the publication plan.
+The update USK private insert URI/key is a protected secret supplied only at the publication
+boundary. After insertion, fetch through the public request URI, compare exact descriptor bytes and
+referenced package identities, and record a separate updater publication receipt. Conflict or an
+unavailable public observation is not idempotent success and must not be overwritten.
+Bind the plan and receipt to the exact public fetch URI and USK edition, not only to the descriptor
+and package-map digests. The published descriptor's CHK/store references must use canonical public
+destinations whose resolved addresses are global. A receipt for a different URI, edition, package
+target, or fetched byte sequence cannot activate a successor baseline.
+The protected workflow loads the reviewed provider named by
+`CRYPTAD_STABLE_MAINTENANCE_PUBLICATION_BACKEND` and exposes
+`CRYPTAD_CORE_UPDATE_PUBLICATION_INPUT` only to the CoreUpdater target operation. Never reuse the
+catalog or maintenance-state protected input for update insertion, and never serialize the private
+input into the descriptor, plan, receipt, logs, or uploaded artifacts.
+The provider's public deployment-service verification receives the authenticated CoreUpdater plan
+and descriptor inside its closed `verificationInputs` set. It must construct a complete updater
+receipt from those exact records; it must not rely on an undocumented service-side copy. The
+protected adapter independently validates `verificationStatus`, public fetch URI, edition,
+descriptor bytes, and every referenced package before accepting that receipt.
+
+Use `AppEnv` for platform/package-key mapping and follow
+`docs/stable-1.0-maintenance-release-and-hotfix-path.md`.

.agents/skills/cryptad-git-workflow/SKILL.md

@@ -48,6 +48,12 @@ Use this skill whenever you:
   GitHub Release only after exact-RC validation and environment approval. It never merges the
   release branch. Continue to use explicit release-manager-approved `--no-ff` merges into `main`
   and `develop`.
+- The protected Stable 1.0 maintenance workflow applies the same boundary to later routine
+  `release/<build-number>` and security `hotfix/<build-number>` candidates: it may create or verify
+  the annotated tag and exact public state, but it never creates or merges branches.
+  Follow `docs/stable-1.0-maintenance-release-and-hotfix-path.md` for the protected sequence and
+  verify that the eventual `main` merge contains the tagged shipped commit; a `--no-ff` merge gives
+  `main` a distinct merge-commit tip.
 - PR policy: require green CI and at least one approval.
 - **Always ask before creating a GitHub pull request.** Do not open PRs without explicit approval.
 
@@ -70,6 +76,9 @@ For Stable 1.0, also verify:
       `publication-verification-failed` without recovery code mutating it.
 - [ ] No test, local default, pull-request workflow, or validate-only run can create a tag, Release,
       branch, public catalog update, update descriptor, or network insert.
+- [ ] For a later Stable 1.0 release, `stable-maintenance` authenticated the immutable GA root and
+      latest published predecessor, and the protected receipt verifies exact candidate bytes before
+      the manual no-squash, `--no-ff` merge-back.
 
 ## Git identity policy (must follow)
 ### GitHub operation identity

.agents/skills/cryptad-hotfix-workflow/SKILL.md

@@ -24,7 +24,9 @@ Build: 3
 ## Rules
 - Hotfix branches are `hotfix/<build-number>` and must be based on `main`.
 - If the hotfix changes the shipped build, bump the integer `version` in `build.gradle.kts` to the next build number.
-- Tag the hotfix as `v<build-number>` on the hotfix branch.
+- Tag an ordinary hotfix as `v<build-number>` on the hotfix branch. For a Stable 1.0 security
+  hotfix, the protected maintenance workflow creates or verifies the annotated tag after
+  authorization; do not tag it manually.
 - Merge `hotfix/*` into `main` and back-merge into `develop` using **no squash** and `--no-ff`.
 - Do not rebase/squash hotfix merges.
 
@@ -41,11 +43,15 @@ git checkout -b hotfix/<build-number>
 2) Apply the fix, run tests/CI per repo conventions.
 - If the hotfix changes the shipped build, set `version = <build-number>` in `build.gradle.kts`.
 
-3) Tag the hotfix on the hotfix branch:
+3) For an ordinary hotfix, tag the hotfix on the hotfix branch:
 ```sh
 git tag v<build-number>
 ```
 
+For a Stable 1.0 security hotfix, do not run that command. Validate the exact candidate with
+`stable-maintenance` and let the protected maintenance workflow create or idempotently verify the
+annotated tag. The workflow never merges the hotfix branch.
+
 4) Merge to `main` (no squash; preserve branch context):
 ```sh
 git checkout main
@@ -60,7 +66,7 @@ git pull
 git merge --no-ff hotfix/<build-number>
 ```
 
-6) Push branches and tag:
+6) Push branches and tag for an ordinary hotfix:
 ```sh
 git push origin main develop hotfix/<build-number>
 git push origin v<build-number>
@@ -71,6 +77,49 @@ git push origin v<build-number>
 ## Checklist
 - [ ] `build.gradle.kts` version is the intended integer build number (if shipped).
 - [ ] CI green on `hotfix/<build-number>`.
-- [ ] Tag `v<build-number>` created.
+- [ ] Ordinary hotfix: tag `v<build-number>` created. Stable 1.0 security hotfix: protected
+      publication receipt verifies the annotated tag.
 - [ ] Merged to `main` with `--no-ff` (no squash), then back-merged to `develop` with `--no-ff`.
 - [ ] Branches and tag pushed.
+
+## Stable 1.0 security hotfix path
+
+A Stable 1.0 hotfix uses `policies.releaseClass=security-hotfix` on
+`hotfix/<build-number>` based on the currently published `main` state. Run the side-effect-free
+command against a copied, completed maintenance manifest:
+
+```bash
+python3 tools/release-certification/certify.py stable-maintenance \
+  --manifest build/stable-1.0-maintenance.json
+```
+
+The critical-security policy requires an incident/advisory id, qualified severity and affected
+scope, release-manager authorization, exact candidate identity, full non-waivable compatibility,
+packaging, updater, upgrade, rollback, migration, backup, signing, and redaction gates, and a
+deadline-bound follow-up obligation for any shortened observation window. It is not a generic skip
+or waiver. Declare a nonempty `affectedPackageKeys` subset even when publishing the complete
+package matrix. A narrowed matrix requires a passing unaffected-target proof and must equal that
+affected set exactly; a complete matrix uses `unaffectedPackageProofStatus=not-applicable`. Close
+the obligation later with the side-effect-free `close-hotfix-follow-up` mode; do not rebuild or
+mutate the published hotfix. The aggregate interval and every obligated row must independently
+meet the normal duration and freshness policy, must have completed by the validation time, and must
+bind both the original hotfix predecessor and the immutable GA identity where the scenario is a
+direct-GA upgrade. When another authorized hotfix carries an open or overdue
+obligation, closure evidence and authorization remain bound to the originally obligated build and
+bytes. The latest activated baseline, receipt, and pointer separately authenticate where that
+obligation is currently carried; do not substitute the superseding hotfix's evidence or
+authorization. Authenticate the original candidate freeze against the predecessor observation
+recorded in that freeze, not against a later baseline carrying the obligation. Protected pointer
+activation uses a fresh activation-only authorization after environment approval; it does not alter
+the published hotfix authorization or bytes.
+
+Follow `docs/stable-1.0-maintenance-release-and-hotfix-path.md`. The protected workflow publishes
+but never merges; explicit no-squash, `--no-ff` merges into `main` and `develop` remain required.
+Before approval, confirm the protected environment has exact producer identities in
+`CRYPTAD_STABLE_MAINTENANCE_INPUT_SIGNER_WORKFLOW` and
+`CRYPTAD_STABLE_MAINTENANCE_WINDOWS_SIGNER_WORKFLOW` and a reviewed
+`CRYPTAD_STABLE_MAINTENANCE_PUBLICATION_BACKEND`. A hotfix does not weaken those provenance or
+publication-boundary requirements. Pin the two producer identities to the checked-in
+`.github/workflows/stable-1.0-maintenance-input-producer.yml` and
+`.github/workflows/stable-1.0-maintenance-windows-package-producer.yml` workflows at the exact
+candidate commit; do not substitute a generic artifact upload or a URL-only producer.

.agents/skills/cryptad-interop-performance-gates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cryptad-interop-performance-gates
-description: "Maintain Cryptad's Hyphanet interop, performance regression, release-certification evidence gates, production beta pipeline, Stable 1.0 RC freeze, and exact-byte GA promotion under tools/interop, tools/perf, tools/release-certification, CI, and release-readiness documentation."
+description: "Maintain Cryptad's Hyphanet interop, performance regression, release-certification evidence gates, production beta pipeline, Stable 1.0 RC/GA flow, and later exact-byte maintenance or security-hotfix path under tools/interop, tools/perf, tools/release-certification, CI, and release-readiness documentation."
 ---
 
 # Cryptad interop and performance gates
@@ -19,6 +19,10 @@ related CI jobs, or release-gate documentation.
 - Stable 1.0 RC execution and freeze: `docs/stable-1.0-rc-execution-and-release-freeze.md`
 - Stable 1.0 RC validation and GA promotion:
   `docs/stable-1.0-rc-validation-and-ga-promotion.md`
+- Stable 1.0 maintenance and security hotfix path:
+  `docs/stable-1.0-maintenance-release-and-hotfix-path.md`
+- Stable maintenance publication provider protocol:
+  `tools/release-certification/publication-backend/README.md`
 - Multi-node beta soak and upgrade drill: `docs/multi-node-beta-soak-and-upgrade-drill.md`
 - Ecosystem RC certification gate: `docs/ecosystem-rc-certification-gate.md`
 - Release certification tooling: `tools/release-certification/README.md`
@@ -423,3 +427,64 @@ python3 tools/release-certification/certify.py stable-ga \
   idempotent only after the same checks pass; mismatches produce a verified failure receipt.
 - Release notes should mention interop, performance, or certification gate changes only when they
   affect release readiness, operator confidence, app/platform behavior, or packager workflows.
+
+## Stable 1.0 maintenance evidence
+
+After GA, `python3 tools/release-certification/certify.py stable-maintenance` is the canonical
+routine-maintenance and security-hotfix gate. It authenticates the GA root and latest predecessor,
+then requires candidate-bound, fresh production live-network, Hyphanet interop, performance,
+multi-node, sandbox, security, upgrade/recovery, and support evidence under the current policy
+windows. Fixture, simulated-only, skipped, stale, dirty, test-signing, or wrong-candidate evidence
+cannot satisfy production gates.
+
+Routine maintenance uses the complete production windows and target matrix. A policy-qualified
+critical security hotfix may shorten only the named prepublication observation windows; it still
+passes every non-waivable gate and emits a deadline-bound full-window follow-up obligation. Closing
+that obligation is side-effect-free and cannot change the published bytes. Follow
+`docs/stable-1.0-maintenance-release-and-hotfix-path.md` and keep protected publication separate
+from evidence production. Configure `STABLE_CATALOG_TRUSTED_KEYS_BASE64` on
+`stable-1.0-maintenance-evidence` with the public-key-only production catalog registry. The freeze
+must verify the exact catalog and detached signature under the declared key id, record the registry
+SHA-256, and delete the decoded registry without publishing public-key bytes or embedding raw
+signature content in JSON. The exact detached signature sidecar remains a frozen public asset.
+Keep the publication provider's immutable source, wheel, signer, and
+entry-point identity pins in repository-level Actions variables so the evidence-scoped independent
+verifier and both publication environments authenticate the same backend without exposing any
+publication-only target secret to the verifier.
+Materialize target credentials before backend construction, then permanently remove their names
+from both the adapter's environment snapshot and ambient process environment. Backend imports,
+observations, and untargeted publication calls must see no catalog, CoreUpdater, or maintenance
+state secret; deliver each opaque input only to its closed target operation.
+Before authorization, expand and canonicalize every concrete publication-object URI—including
+artifact-base children and the detached catalog-signature sibling—and reject aliases across
+GitHub Release, artifacts, catalog primary/mirrors/rollback/signature, and CoreUpdater roles.
+The canonical maintenance provider verifies but does not populate the public artifact base.
+Pre-stage every planned object independently, then require an exact matching artifact-base prefix
+before the tag is the first permitted mutation. An absent, partial, or mismatched artifact base
+must fail protected preflight; it is not a resumable empty publication state.
+Supplied maintenance publication receipts must bind the nested GitHub Release identity—including
+release id, integer-build tag, and canonical public page URI—to the exact authorized target; a
+passing operation, notes digest, and aggregate public observation are not sufficient.
+Before authorization, require the GitHub Release page to be exactly
+`https://github.com/crypta-network/cryptad/releases/tag/v<build>`. The protected provider owns that
+fixed repository and must compare the deterministic `Cryptad v<build>` title as well as the tag,
+commit, page, notes, draft/prerelease state, and assets when verifying exact existing state.
+Protected phase-ZIP intake must allowlist the complete extracted file tree, not only the
+`protected-inputs/` subtree: the canonical phase manifest and files beneath explicitly referenced
+directory inputs are the only survivors, and unrelated root-level or sibling files are blockers.
+The latest-baseline activation job must retain its pre-adapter mutation-boundary marker on every
+outcome. Its workflow audit conservatively reports that side effects may have occurred once that
+marker exists and carries the observed pointer digest from an activation receipt when available;
+never describe a missing receipt after that boundary as proof that the pointer was unchanged.
+The deployment provider's `verify-publication` call must remain self-contained: send every closed,
+digest-bound candidate, lineage, baseline, evidence, provenance, CoreUpdater, and nullable follow-up
+record needed to construct the receipt, successor baseline, and history entry. Do not introduce an
+undocumented service-side candidate store or treat service construction as producer
+authentication; the protected adapter must independently validate every returned record.
+
+Use this focused offline check while changing the maintenance engine, schemas, workflows, or
+provider, followed by the broader suites appropriate to the touched integration:
+
+```bash
+python3 tools/release-certification/certify.py stable-maintenance --self-test
+```