feat: 自动更新

2026-07-15 19:43:06 +08:00
parent f64eb0831f
commit f3b14b7945
54 changed files with 3207 additions and 589 deletions
@@ -31,6 +31,10 @@ Platform stores generated run and client-manager packages as artifacts with a di

 Alternative considered: ship one global run binary and ask users to hand-edit config files. Rejected because it causes copy/paste key exposure, weak auditability, and poor operator experience.

+Distribution generation is asynchronous. Platform creates a bounded `distribution.build` job on the assigned run endpoint and returns a `building` distribution with the real job ID. The run worker obtains the secret-bearing build input only through its authenticated leased-job channel, builds in an isolated workspace, and uploads the resulting archive through the artifact channel. Platform marks a distribution `available` only after the job succeeds and the referenced artifact is present and available. A JSON build plan, generated config, or synthetic build log is never a downloadable distribution artifact.
+
+Run packages are built from the trusted run worker checkout. Plugin-declared client managers are checked out from the approved HTTPS Git repository and revision carried by the build job. Build execution uses a fixed build-system adapter and target tuple; repository content cannot supply arbitrary platform-side commands.
+
 ### Decision 2: Run and client-manager credentials are separate singleton keys

 Each server/component has exactly one active run key and, when needed, exactly one active client-manager key. Run and client-manager keys remain different secrets, but platform does not keep multiple simultaneously valid keys for the same component. Resetting a key replaces the encrypted database value, increments the key generation, invalidates every older run or client package for that component, and requires regenerating and redeploying the affected package.
@@ -5,7 +5,11 @@ The platform SHALL let an authorized operator generate a run package for a selec

 #### Scenario: Operator generates run from server actions
 - **WHEN** an authorized operator selects generate executor for a server instance and chooses a supported OS/architecture
- **THEN** platform MUST create or reuse the server's current encrypted run key, write that key into the generated package config, create a distribution record with key generation, build/download artifact, checksum metadata, and audit event, and MUST NOT return the raw key in the API response
+- **THEN** platform MUST create or reuse the server's current encrypted run key, queue a real run-worker build job, return a building distribution with its job ID, compile the target executable, package it with the generated config, publish the completed binary archive and checksum through the artifact channel, record an audit event, and MUST NOT return the raw key in the API response
+
+#### Scenario: Run generation has not completed
+- **WHEN** the run-worker build job is queued, running, failed, or cancelled
+- **THEN** platform MUST keep the distribution unavailable for download, expose the real job state and progress, and MUST NOT substitute generated configuration JSON or a synthetic build log as the downloadable run package

 #### Scenario: Operator downloads generated run package
 - **WHEN** an authorized operator downloads a generated run artifact
@@ -75,7 +79,11 @@ The platform SHALL support plugin-declared client-manager build profiles for com

 #### Scenario: SCUM-style client manager is generated
 - **WHEN** a plugin declares a client-manager build profile with repository, revision policy, supported target platform, build system, config template, and output artifact paths
- **THEN** platform MUST create a build job that checks out the approved source, injects redacted configuration from secret refs, produces a downloadable artifact, and redacts secrets from build logs
+- **THEN** platform MUST create a run-worker build job that checks out the approved source and revision, injects configuration obtained through the authenticated job-input channel, compiles the target executable, uploads the downloadable artifact through the artifact channel, and redacts secrets and workspace paths from progress and build results
+
+#### Scenario: Client-manager build is still running
+- **WHEN** the source checkout, environment check, dependency download, compile, or artifact upload stage is incomplete
+- **THEN** platform_web MUST display the corresponding real job progress and MUST NOT mark later stages complete on a local timer

 #### Scenario: Unsupported client-manager target is requested
 - **WHEN** an operator requests a client-manager build for an OS/architecture not declared by the plugin profile
@@ -53,6 +53,14 @@
 - [x] 7.4 Complete a browser walkthrough for touched server-list and server-detail workflows before marking UI acceptance complete.
 - [x] 7.5 Record verification evidence in this task file before completion.

+## 8. Real Distribution Build Repair
+
+- [ ] 8.1 Replace synchronous synthetic run/client artifacts with queued `distribution.build` jobs, building distribution records, authenticated build-input retrieval, and terminal job projection.
+- [ ] 8.2 Implement the independent run worker build adapter for trusted run source and approved HTTPS client-manager repositories, including fixed Go builds, isolated workspaces, config packaging, checksums, and chunked artifact upload.
+- [ ] 8.3 Drive the platform_web generation dialog from real job progress and terminal state instead of timer-completed stages.
+- [ ] 8.4 Add regression coverage proving generation queues a backend job, does not publish JSON plans as artifacts, publishes only uploaded build output, and reports actual progress/failure.
+- [ ] 8.5 Run focused platform, run, frontend, OpenSpec, and structure verification and record the evidence below.
+
 ## Verification Evidence

 - `cd plugins && npm run validate:manifest`: passed. First sandbox attempt failed with `listen EPERM` on the local `tsx` IPC pipe, then the same command passed with approved escalation.