fix(desktop): stop polling unavailable collaboration authority

.asf.yaml

@@ -62,11 +62,18 @@ github:
         required_approving_review_count: 1
       required_status_checks:
         strict: false
-        # test is the single job in .github/workflows/ci.yml, covering lint,
-        # format, build, tsc, knip, the selected workspace suites, e2e and
-        # Storybook. Renaming it there, or adding a paths filter that stops
-        # ci.yml from running, freezes every pull request: the check never
-        # reports and no committer can override it.
+        # test is the single unconditional job in .github/workflows/ci.yml. It
+        # runs the install-free contract checks on every change and installs the
+        # toolchain only for the validation its own planning step selects, so a
+        # documentation-only change still reports without paying for a build.
+        # Renaming the job there, adding a paths filter that stops ci.yml from
+        # running, or splitting the work back across jobs so this context comes
+        # from an aggregator that can be skipped, freezes every pull request:
+        # the check never reports and no committer can override it.
+        # A required context must report on every pull request, so a lane
+        # behind a paths filter cannot be listed here: the filter would keep
+        # the workflow from starting and the check would stay pending forever.
+        # windows_recovery is filtered and therefore deliberately absent.
         contexts:
           - test
 
@@ -81,9 +88,11 @@ github:
       restrict_force_push: true
 
   environments:
-    # These environments are the external human gates around signing secrets
-    # and npm OIDC. Naming an environment here replaces its settings wholesale,
-    # so keep every protection rule in this declarative authority.
+    # These environments are the deployment boundaries around signing secrets
+    # and npm OIDC. Release publication adds human review; scheduled npm
+    # Nightly relies on exact ref admission instead. Naming an environment here
+    # replaces its settings wholesale, so keep every protection rule in this
+    # declarative authority.
     release:
       required_reviewers:
         - id: M4n5ter
@@ -95,7 +104,25 @@ github:
         policies:
           - name: "v*-incubating-rc*"
             type: tag
-    npm-release:
+    npm-publication:
+      required_reviewers: []
+      wait_timer: 0
+      prevent_self_review: false
+      deployment_branch_policy:
+        protected_branches: false
+        policies:
+          - name: main
+            type: branch
+    nightly:
+      required_reviewers: []
+      wait_timer: 0
+      prevent_self_review: false
+      deployment_branch_policy:
+        protected_branches: false
+        policies:
+          - name: main
+            type: branch
+    product-release:
       required_reviewers:
         - id: M4n5ter
           type: User
@@ -104,8 +131,8 @@ github:
       deployment_branch_policy:
         protected_branches: false
         policies:
-          - name: "v*"
-            type: tag
+          - name: main
+            type: branch
 
 notifications:
   commits:      commits@maka.apache.org

.gitattributes

@@ -10,3 +10,8 @@
 /.claude export-ignore
 /.maka-shots export-ignore
 /maka-proposal-zh-review.txt export-ignore
+
+# DeepSeek Harness remains available to repository development and benchmarks,
+# but its external runtime dependency closure is not an ASF source-release input.
+/packages/eval/harbor/deepseek-harness-toolchain/package.json export-ignore
+/packages/eval/harbor/deepseek-harness-toolchain/package-lock.json export-ignore

.github/ASF_NPM_RELEASE.md

@@ -72,9 +72,9 @@ registry side effects.
 
 After both source-release votes approve the candidate, the product Release
 workflow creates `v<version>` at that approved commit. The npm Stage workflow
-then builds and validates one tarball from that final tag, submits those exact
-bytes to npm staging through the protected `npm-release` Environment and OIDC,
-and records the stage identity. Human approval with npm 2FA makes the package
+then builds and validates one tarball from that final tag in jobs without OIDC. The OIDC job runs
+only reviewed `main` publisher code, submits those exact bytes through the main-restricted
+`npm-publication` Environment, and records both product-source and publisher identities. Human approval with npm 2FA makes the package
 public; Finalize verifies the registry bytes, integrity, signature, provenance,
 and dist-tag.
 

.github/ASF_SOURCE_RELEASE.md

@@ -19,14 +19,9 @@
 
 # Apache Maka source release runbook
 
-This runbook prepares the official Apache Incubator source-release component.
-The first Maka release also requires npm and Desktop convenience artifacts, but
-those artifacts have separate build, licensing, signing, and acceptance gates.
-They must be built from the exact IPMC-approved source release produced here.
-
-The workflow implements release mechanics; it does not establish that a commit
-is legally ready to release. Before starting a vote, the PPMC and mentors must
-confirm the candidate's provenance and release documents.
+This runbook prepares the official Apache Incubator source release. npm, Desktop, and other convenience artifacts use separate build, licensing, signing, and acceptance processes; they are not part of this source candidate or its release vote. Stable convenience artifacts, when provided, are built from the approved source release and tag.
+
+The workflow implements release mechanics; it does not replace the human review of candidate provenance and release documents performed through the project's release vote.
 
 ## Candidate contract
 

.github/DESKTOP_NIGHTLY.md

@@ -0,0 +1,41 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Desktop Nightly
+
+Desktop Nightly is an ephemeral developer snapshot, not an Apache release. It builds the current `main` commit every day so contributors can try recent Desktop changes and report problems without waiting for an ASF source-release vote.
+
+The npm publication workflow gives each snapshot an immutable version such as `0.2.0-dev.42.20260829`. The run number is the sole ordering authority. After that exact npm version is public, it triggers Desktop Nightly with a version-only artifact; the authenticated workflow event supplies the exact source commit and upstream run. Each fresh Desktop Nightly creates a `v<version>` tag protected by the checked-in `Immutable release tags` ruleset and one GitHub draft prerelease containing the macOS and Windows packages, blockmaps, `dev-mac.yml`, `dev.yml`, and one offline Sigstore bundle. The workflow verifies every remote asset before it publishes the prerelease as non-Latest. Packaged Nightlies use the GitHub `dev` channel and verify that downloaded bytes were attested by `.github/workflows/desktop-nightly.yml` on `main`. A formal Desktop build uses the separate stable GitHub Release channel and formal product-release attestation identity.
+
+Nightly currently uses the same application identity as the formal Desktop. Installing it replaces the existing Maka installation rather than creating a second side-by-side app. Its user data remains in the same location. Testers who need the formal build should reinstall that build before returning to the formal channel. Builds previously downloaded from `nightlies.apache.org` do not migrate automatically; testers must install the newest GitHub prerelease once, after which GitHub Nightlies update automatically.
+
+## One-time setup
+
+1. After the checked-in `.asf.yaml` reaches `main`, verify that ASF reconciliation created the `nightly` GitHub Environment with only `main` permitted and no approval gate. Do not maintain that policy manually in GitHub. Configure its macOS signing and notarization secrets: `CSC_LINK`, `CSC_KEY_PASSWORD`, `APPLE_API_KEY`, `APPLE_API_KEY_ID`, and `APPLE_API_ISSUER`. Do not expose these secrets to repository-wide or pull-request workflows.
+2. Configure npm Trusted Publishing for `apache/maka` and `.github/workflows/npm-publication.yml`, restricted to the `npm-publication` Environment and with both `npm publish` and `npm stage publish` allowed. Do not create or store a long-lived npm token.
+3. After npm Trusted Publishing is ready, set `NPM_NIGHTLY_ENABLED` to `true`, run `npm publication` from `main` with `channel=nightly`, and verify the exact npm version and `nightly` dist-tag.
+4. Set `DESKTOP_NIGHTLY_ENABLED` to `true` and manually dispatch a fresh npm Nightly. Confirm that its successful run triggers `Desktop Nightly`. Do not rerun a failed attempt in place.
+5. Verify that `v<version>` points to the exact source SHA and that its GitHub Release is published with Draft off, Prerelease on, Latest off, and exactly the nine expected assets. Install that prerelease on both platforms.
+6. Publish one later fresh Nightly and confirm a GitHub-to-GitHub automatic and differential update on both platforms before sharing the channel with testers.
+
+The npm schedule starts at 18:17 UTC. Before changing the npm tag, the workflow requires its run number to exceed the current `nightly` version. Desktop assembles and verifies a draft before one publish mutation; a packaging, attestation, tag, upload, or digest failure leaves no partially published GitHub Release. Never rerun a failed workflow attempt in place; dispatch a fresh npm Nightly with a newer version.
+
+GitHub Release retention is intentionally outside this workflow. Do not delete an old Nightly prerelease or its tag while any installed client may need its payload or blockmap. One Nightly is additionally pinned by tag, asset name, and SHA-256 in `scripts/windows-upgrade-baseline.json` as the Windows upgrade gate's baseline: deleting that prerelease fails the gate on every pull request that touches the Windows release path until the pin moves to another published build. Disabling `DESKTOP_NIGHTLY_ENABLED` stops new Desktop publication without mutating tags or releases.
+
+Remote Runtime Host setup uses the exact `maka-agent@<nightly-version>` package embedded in the Desktop manifest. The npm package is verified before Desktop artifacts become visible, so clean remote setup never depends on an unpublished Runtime Host version.

.github/RELEASE_CHECKLIST.md

@@ -19,9 +19,10 @@
 
 # Product release checklist
 
-The `Release` workflow is Maka's convenience-artifact release entry point. Desktop and CLI/TUI are
+The IPMC-approved source archive on ASF distribution infrastructure is the Apache release. The
+`Release` workflow is Maka's convenience-artifact distribution entry point. Desktop and CLI/TUI are
 built from the exact IPMC-approved ASF source candidate commit. They share that source commit, the
-root product version, one convenience tag, one GitHub Release, one Draft decision, and one release
+root product version, one convenience tag, one GitHub Release, one Draft decision, and one distribution
 gate. The workflow creates no Draft until every required artifact job succeeds.
 
 Phase 1 requires:
@@ -31,9 +32,9 @@ Phase 1 requires:
 - the signed, notarized, relocatable Apple Silicon CLI/TUI ZIP;
 - checksums generated after each artifact reaches its final form.
 
-The ASF Desktop artifacts must not contain a Git runtime, a bundled-Git manifest, or Git/Dugite
-redistribution notices. Managed-workspace execution remains unavailable until a separately reviewed,
-ASF-compatible verified runtime is connected before admission/T1.
+The convenience Desktop artifacts must not contain a Git runtime, a bundled-Git manifest, or Git/Dugite
+redistribution notices. The retired Git executable-backed managed-workspace path must not be restored;
+future workspace execution requires a separately reviewed Gitoxide production composition before admission/T1.
 
 The first product release also requires the exact `maka-agent@<version>` npm package. The product
 tag and Draft must exist before npm staging, but the Draft must remain unpublished until npm is
@@ -60,10 +61,17 @@ must never be exposed to fork or ordinary pull-request jobs.
 Before the first product release, confirm the checked-in `.asf.yaml` has reconciled the live repository:
 
 - the `Immutable release tags` ruleset blocks updates, force-pushes, and deletions of `v*` tags;
-- the `release` and `npm-release` Environments accept only their declared tag patterns and require a reviewer other than the triggering user;
-- enable immutable releases so assets and the associated tag cannot change after publication.
-
-These controls close the check-to-upload and check-to-stage windows. Keep the Release in Draft while assets and acceptance are incomplete; publishing early must make subsequent mutation fail closed.
+- the `release` Environment accepts only its declared source-candidate tag pattern and requires a
+  reviewer other than the triggering user;
+- `npm-publication`, `nightly`, and `product-release` accept only `main`; `product-release` requires
+  a reviewer other than the triggering user. `npm-publication` and `nightly` have no GitHub approval
+  gate because scheduled npm and Desktop Nightly publication is automatic; formal npm publication
+  still requires human 2FA approval after staging.
+
+These controls close the check-to-upload and check-to-stage windows. Finalize uses GitHub Actions
+OIDC rather than a stored signing key to attest every convenience artifact. Keep the Release in
+Draft while assets and acceptance are incomplete; Desktop rejects downloaded updates whose exact
+bytes and expected filename are not covered by that protected workflow identity.
 
 ## Create the complete Draft
 
@@ -79,8 +87,8 @@ These controls close the check-to-upload and check-to-stage windows. Keep the Re
 5. Confirm `release-identity`, both Desktop matrix entries, `cli-macos-arm64`, and
    `publish` pass. A skipped or failed required job must prevent Draft creation.
 6. Confirm one Draft named `v<version>` targets the approved source SHA, identifies the ASF source
-   reference in its notes, is marked as a GitHub prerelease exactly when the product version is a
-   prerelease, is not marked Latest while it remains a Draft, and contains exactly the manifest
+   reference in its notes, is not marked as a GitHub prerelease or Latest while it remains a Draft,
+   and contains exactly the manifest
    reported by `node scripts/product-release-artifacts.mjs list`. The manifest covers both Desktop
    platforms and update metadata, the standalone CLI/TUI, and their required checksums.
 7. Inspect the CLI ZIP. It must contain `bin/maka`, `RELEASE.json`, `DISCLAIMER-WIP`, `LICENSE`, `NOTICE`,
@@ -106,17 +114,22 @@ then rerun. If only the tag exists, the retry creates the missing Draft.
 
 Follow [the npm release runbook](../docs/cli-npm-release.md) against the exact product tag and Draft:
 
-1. Run **Stage CLI npm release** from `v<version>` and record its successful run ID and attempt.
+1. Record the successful **Release** workflow run ID and attempt that built the Draft assets. Run
+   **npm publication** with `channel=formal` from `main` and record its successful run ID and
+   attempt.
 2. Inspect the staged tarball and provenance, then approve that exact stage with npm 2FA.
-3. Run **Finalize CLI npm channel** from `main` and confirm it verifies the public package bytes,
-   provenance, signature, and release dist-tag.
+3. Run **Finalize product release** from `main`. Its first job verifies the public package
+   bytes, provenance, signature, and release dist-tag.
 4. Install the exact public version on each release platform and complete the npm acceptance steps.
 
-Keep the GitHub Release in Draft throughout this sequence. A failed or rejected npm candidate
-requires a new product version; never publish the Draft to work around npm state.
-
-When every npm and cross-machine acceptance check has passed, publish the Draft. Mark a stable
-release as Latest at that final publication boundary; prereleases must remain non-Latest.
+Keep the GitHub Release in Draft throughout this sequence. The final workflow job waits at the
+`product-release` Environment. Approve it only after every npm and cross-machine acceptance check
+has passed. It verifies the live Draft digests against the immutable publication record from the
+exact successful Release run, creates Sigstore provenance and an offline
+`Maka-<version>-attestation.sigstore.json` bundle, then publishes the convenience Release and makes a
+stable release Latest in the same GitHub operation. Do not publish or
+change the Latest designation manually. A failed or rejected npm candidate requires a new product
+version; never publish the Draft to work around npm state.
 
 ## Acceptance on another Apple Silicon Mac
 
@@ -155,8 +168,20 @@ Download the installer, Windows Desktop ZIP, and both checksum files through a b
 7. Add a clean remote Runtime Host from the packaged Desktop app. Confirm setup installs the exact
    public `maka-agent@<version>` package and the remote session completes one model turn.
 
-Immediately before publication, reverify that the approved ASF candidate tag and convenience
-`v<version>` tag still resolve to the same recorded commit. Publish only after npm Finalize and both
-independent-machine acceptance passes. If any required artifact, npm step, or
+Immediately before approving the `product-release` Environment, reverify that the approved ASF
+candidate tag and convenience `v<version>` tag still resolve to the same recorded commit. Approve
+only after npm verification and both independent-machine acceptance passes. If any required artifact, npm step, or
 acceptance step fails, keep the Draft unpublished, fix the issue, increment the root product
 version, and run the full workflow again. Never replace an existing release identity.
+
+After Finalize publishes the convenience Release, download its attestation bundle and verify each
+installer or archive independently:
+
+```sh
+gh attestation verify path/to/Maka-<version>-mac-arm64.zip \
+  --bundle path/to/Maka-<version>-attestation.sigstore.json \
+  --repo apache/maka \
+  --signer-workflow apache/maka/.github/workflows/release-cli-finalize.yml
+```
+
+Desktop performs the same trust decision before exposing a downloaded update for installation.