Runtime Image Delivery - wongyiuming/FrontierCloud-Gin GitHub Wiki

Public Native Image Delivery

当前运维入口(2026-10-14)

当前 updater 清理交付见 PR #15,公开版本为 fc6adc75c7cdb9064163f938a31f176add843e0a。源码、Updater 镜像发布、fc 的 Updater 校验与旧 CD 入口已移除。保留证书 certificate-agent,它只负责 TLS 生命周期,不承担项目升级。

当前发布只编译、发布 Web/Nginx 两种镜像;证书 agent 使用 Web 镜像中的证书命令。升级由每台主机显式执行 fc upgrade plan/apply/open,无自动整群发布、后台 Docker socket 升级或现场源码编译。数据库代际为 7,本次没有 DDL 变化。

现行命令、备份和恢复边界见 fc 手动升级与边界,源码契约以 main 的 运维手册 和 升级契约 为准。RN 预生产和外部 CD 已退役,不能声称完成 live staging 验收。

本次生产执行状态见 fc 手动升级与边界;公开发布成功不等于生产更新完成。

2026-10-11 及此前的历史记录(旧命令及版本不用于当前部署)

当前正式镜像:785af2d2c459

2026-10-11,按所有者生产更新指令审查并合并 PR #9 与 PR #10。main/dev 均为 785af2d2c4595d210bf3bf2de8d39ef6f0b42983。

修复提交 dev CI、main CI、同步后的 dev CI 均通过。正式发布 与 重入发布 全部成功,包含 main/latest 晋升。独立匿名 GHCR 校验确认 latest 与以下精确镜像 digest 一致;生产节点实际拉取、标签和运行版本检查通过。

镜像 不可变 digest
web sha256:391bef76c2f2a9ae8757cb1afb717075995453d7296e7a48cde241d450fb88b5
updater sha256:bed6f455baee30f6097dd26be572ad36831c08a764e7a072fb4f5a794a7c4cab
nginx sha256:c3bcd2f326eb253357272b6798e0a00ac35caa96d06a37baf9608ca84b94d7ae

生产三节点都已运行此版本并由 Go 获得正式 Let’s Encrypt 证书。RN 预发布/CD 仍退役;未把缺失的 live staging 门禁报告为通过。

2026-10-11 自动 TLS 开发阶段镜像(历史证据)

候选 e2b060aa2c8b2b14856a3f4697fb67114bfdb2c6 的 dev CI 通过。受信任发布 的三项编译和三项发布均成功;最后的旧 main 预发布通知失败,latest 推进跳过。这是 PR #9 合并前的开发阶段证据;当前正式 main/latest 为上方 785af2d2c459 镜像。

匿名 GHCR 证明和实际 Docker 拉取通过(linux/amd64、schema 3、源 SHA、release manifest;Web/Nginx 自动 TLS 标记正确):

镜像 不可变 digest
web sha256:6ee7417190a76380aaa7292f755019808407429ca7a25927a7d40fbbcb67d76b
updater sha256:b3b86ccbc8b6ff73c87d5a4300c429390b2d807d69c0196da1c5faff7227986d
nginx sha256:d12557de61a9396ce647b5287dc122c9c8baa71581dd25ebe4d880256bd05557

退役通知器重新创建的空 staging-cd-main Environment 已单独核实无 secrets/variables 后移除。没有恢复 RN CD 或运行预发布业务。

RN preproduction and its external CD were retired by the owner on 2026-10-11. Production storage and other applications were preserved. STAGING_CD_ENABLED=false; no current preproduction acceptance can be claimed. See Staging-CD for the retirement boundary and historical evidence.

Automatic TLS fresh startup (released main/latest)

The automatic TLS source requires only TLS_ENABLED=true and SERVER_NAME for a fresh Business deployment, followed by docker compose up -d --wait. Certificate paths and HTTP_PORT/HTTPS_PORT are retired. All images remain public GHCR images; a dev push does not promote main/latest. The reviewed change is now merged and published at main 785af2d2c459; the two-value startup is available from its verified main/latest images.

Only successful current-main publication promotes fresh-install aliases. All three exact-SHA publisher jobs, anonymous provenance and manifest bytes are verified before alias writes. A global lock serializes promotions; current HEAD/attempt and exact digest are checked again immediately before each write. Candidate code never executes with package credentials. Updates still validate exact SHA/digest. Tags are not atomic across packages; retry an install overlapping publication or pin one verified SHA.

Current main contains the retired-staging notification switch. Its two final publication runs completed successfully with STAGING_CD_ENABLED=false; the retired notifier is skipped. This is publication success, not live staging acceptance. See Deployment-and-Configuration and the source image-delivery contract.

The earlier five-parameter baseline and RN/EVOXT CD results below are historical release evidence. They do not prove the new automatic certificate lifecycle or Python application-source removal.

Historical release checkpoints

The current candidate is a02b7533ed75c5b13c8ddd2cd86779f8518b9b67. Its own complete development-host chain exited zero: source/policy, real OCI, Nginx UA, TLS/browser, real MySQL/Redis business, full Go race, maintenance and security headers, Gin SQLite/MySQL black-box APIs and Linux fairness race ten times. All 451 copied SDK files matched; the last race took 17.474 seconds and peaked at 1.278 GiB, with zero OOM/resource-limit events. It has been pushed to dev and passed source CI #24. Owner-triggered image-only bootstrap #2 completed all seven jobs successfully. Independent anonymous proof verified all three image digests. EVOXT native CD then completed in 24 seconds; current, target and updater runtime matched the candidate. Database stable-table hashes, all secret hashes and mount paths matched the pre-upgrade snapshot; production storage remained unchanged. Actual staging API acceptance uploaded one UUID 32,044-byte WAV, verified Range bytes, renamed its directory, verified Admin and public catalog identity and complete bytes, then deleted only that fixture. HTTP/2, unique CSP nonces, security/error headers, discovery documents, relative Admin redirect and database/Redis readiness passed. This is not a claim of browser queue, WebRTC, TTL expiry or peer-storage end-to-end acceptance. PR #5 was merged only after staging acceptance. Actual main is 3a74a4e51aa25bb9e4aee53b6c81536d32a66e33, whose tree equals the accepted dev source. Its source CI, runtime conformance and normal workflow_run publication #4 passed. The first final-main updater fixture stopped during source validation, before replacement: its shared local clone referenced a host object directory not mounted into the controller. Old HTTPS Admin CI authorization had passed. The failed journal and evidence are retained unchanged. A second fixture had an overlong private test hostname and also stopped without reaching release. A new self-contained, short-hostname fixture then passed the actual complete A-to-B-to-C chain in 42.04 seconds: verified old Admin authorization, public image installation, controller handoff and maintenance release. Installed image digests matched; identity, all secrets and synthetic media hashes and managed catalog identity remained intact. All six fixture containers were stopped, with no OOM or manual journal edits. At that fixture checkpoint no production controller or application had changed. The later production outcome is recorded below; development fixture success alone was not production acceptance. It changes only the REST publication helper, regression tests and delivery documentation, not the Go runtime, database schema, Dockerfiles or frontend. Local unittest discovery now ran 185 cases: 183 passed and two fixture-dependent classes skipped. Twenty publication regressions passed, including singular GHCR upload locations and rejection of foreign origins, traversal and duplicate digest.

The preceding 1041d537f0f7a7dbe1fe3884e7380e4e149b4db8 completed its own development-host chain with exit zero, including real Gin SQLite/MySQL APIs, TLS/browser tests, full Go race, Nginx maintenance/security headers and Linux scheduler/fairness race ten times. All 451 SDK source files matched; the last race took 16.674 seconds, peaked at 1.278 GiB and recorded zero OOM or resource-limit events under two CPUs/3 GiB/no swap. It has been pushed to dev and passed source CI #23. The owner-authorized image-only bootstrap #1 completed all three compilation jobs, but all publishers failed closed with Foreign upload location. The REST helper had assumed only the plural /blobs/uploads/ form; GHCR also uses /blobs/upload/. The follow-up candidate accepts both inside the same repository and verified origin; real publication confirmation passed in bootstrap #2. No staging wakeup or deployment was performed for the failed preceding revision. Preceding local unittest discovery ran 184 cases: 182 passed, two fixture-dependent classes skipped. Real Gin/SQLite/MySQL and Nginx fixtures run separately on the development host; these skips are not platform exclusions or backend passes. Lightweight policy and six frontend smoke drivers passed. The new source uses automatic job-scoped GitHub tokens, not a personal PAT. Tests verify that an old PAT is ignored and cannot substitute for a missing automatic token. The candidate also adds 17 first-bootstrap regressions and nine CI-budget checks. Development-host gates for preceding af859df remain separate evidence; they are not acceptance of this newer fixed candidate.

The preceding 5d24ddeaa8d084807755a4c81fc00569a83f9740 passed full development gates, source CI #22 and image publication #3. Independent anonymous registry proofs verified all three exact-SHA images. Automatic GitHub Codex review then identified a P1 dev-workflow package-writer boundary and a P2 independent-runner queue deadline. The operator subsequently accepted a repository-workflow-writer trust model instead of maintaining a separate personal publication token. This does not grant anonymous public readers push access or claim to isolate every authorized workflow writer from package writes. The newer source addresses the completed-event queue race. The preceding revision is not authorized for promotion. Its successful builds are not staging acceptance.

PR #5 is merged. PR titles/bodies use Chinese; code comments, Markdown and commit messages use English. Review uses configured GitHub automation within existing quota. The operator has authorized a one-time controlled staging bootstrap, lossless storage-container updates and an updater-only production bridge, subject to their exact-source acceptance and rollback gates. Production Master is still 8a6e30975c109d6f59763dbc5f43e33935e71bd6; EVOXT preproduction is the accepted a02b753 installation. The two production storage appliances were separately updated to fixed main 3a74a4e with operator approval; see the scoped storage protocol update below. This is not a preproduction Master deployment or a production Master upgrade.

Compilation stays on GitHub

Normal delivery is:

  1. Bounded development-host acceptance of a fixed source commit.
  2. Push dev; lightweight source CI retains its three-minute hard limit.
  3. A completed successful source CI event invokes immutable default-main publication code. A trusted read-only plan verifies exact source CI, original attempt, current HEAD and existing anonymous image digests.
  4. Parallel GitHub jobs without package-write credentials compile Go and export OCI image data. Each compilation job has its separate ten-minute deadline. No fleet, real databases, browsers or business acceptance runs there.
  5. Isolated main publication jobs use automatic GITHUB_TOKEN with packages: write, validate bounded OCI data and publish only that source SHA tag. Each publisher has a three-minute limit. They never execute candidate scripts, Dockerfiles, extracted executables or containers while holding package credentials.
  6. A separate main-only signing job verifies the trusted plan, all three completed publisher jobs and anonymous manifests, then wakes staging.
  7. RN pulls and installs the images, then passes real live acceptance.
  8. Normal dev-to-main promotion, exact main CI/images and a separate production AdminGUI upgrade follow. Production never auto-upgrades with staging.

The new event chain replaces a 195-second polling deadline that failed to account for separately queued source runners. Test CI budgets are unchanged. Runtime layers contain binaries, static files and runtime dependencies, not Go, Python or test sources. The first historical GitHub compilation measured 63 seconds for Web and 18 seconds for updater.

External permission prerequisites

Only the CD signing Environment staging-cd-main requires the exact Branch main deployment rule. Its STAGING_CD_SECRET must match the separate RN trigger service, not the Web container; never log it. Remove dev-accessible repository/organization copies of this signing key.

Publication no longer requires GHCR_PUBLISH_TOKEN or a publisher Environment. GitHub automatically provides the isolated publisher's short-lived token. Plan, compile and notify jobs do not receive package-write permission. Each public Web/Updater/Nginx package must allow FrontierCloud-Gin Actions Write; do not remove this grant. Public pulls remain anonymous. If the old procedure removed package Actions access, restore this repository's Write grant first. An already created PAT or native-image-publish-main Environment may remain unreferenced; neither is consumed by the new workflow nor triggers deployment. Do not delete an existing IDE credential as part of this change.

Repository workflow writers are trusted to request writes in another workflow. Default read permissions and our publisher's SHA checks are not an ACL against such authorized writers. Source tests cannot configure or certify these external settings, nor prove an authenticated upload works before a real run.

The new workflow must exist on default main before normal workflow_run activation. The owner has explicitly authorized one image-only CI entry for existing PR #5. After development acceptance and exact successful source CI, only an owner-applied bootstrap:<full dev SHA> label starts its proof. Owner actor/sender, current PR/head/base/merge refs, latest source run/attempt and the first matching authorization run remain bound. Only that run's newest owner attempt can recover; relabel-triggered duplicate runs and future PRs cannot. Read-only parallel compilation exports OCI data; only an isolated REST publisher gets automatic package write. Its PR workflow snapshot is explicitly authorized candidate code, not immutable-main code. The entry has no signing secret, Environment, PAT or deployment job, and cannot upgrade production.

Actual source-head metadata and the workflow's PR merge snapshot are separate SHAs. Source tests do not prove the first real GitHub context or public images; record the completed run and three anonymous digests first. A separately authorized operator wakeup must preserve staging HMAC/replay/image/current-CI gates, and live staging acceptance must still precede merging PR #5. No fake GitHub environment, premature merge, direct main write or re-enabled historical source-only notifier is acceptable. Closing/merging PR #5 retires this exception. See activation details. The normal event chain is active after default-main promotion. External configuration must remain correct; actual first bootstrap publication, staging acceptance and the subsequent main workflow_run publication have passed. Future successful dev source CI events use this event chain, not a five-minute timer.

The repository access audit found zero collaborators and no deploy keys; only the human owner can contribute. The owner explicitly retains ChatGPT Codex Connector as an authorized application exception. Its access was not changed, and no new rule blocking it was installed. Public read access is not public push access. Main-only signing Environment setup is reported complete by the operator, not certified by source tests.

Public images and safe fallback

The public packages are frontiercloud-gin-web, frontiercloud-gin-updater and frontiercloud-gin-nginx under wongyiuming GHCR. Tags use full source SHAs; actual deployments pin verified manifest digests. Trusted writers serialize by source SHA/component and reuse accepted bytes. This is workflow write-once discipline, not registry atomic CAS; external package administrators can still mutate tags. Observed disappearance, drift or invalid provenance fails closed.

Anonymous proof validates manifest/configuration bytes, source revision, component, runtime, schema and platform. Network/authentication/5xx/proof errors are not absence. Only confirmed missing versions/platforms permit bounded immutable-source local compilation. Compose prepares images then uses up --no-build; updater keeps current/previous, not global prune or data deletion.

Historical 5d24dde publicly verified runtime digests, never installed:

Component Digest
Web sha256:d1f5cf7cfbd0f00626123f9cdf9c96e390e1f75e2c49cdfb0d9517d9ab71ee1e
updater sha256:9416eb10686444e3b448487b4372e53f6015b9d41e70ec5e4e1af42fc95c402f
Nginx sha256:1f34c9e3f1342bfd5f358063c6c96168680aad8a4e266263e58afd330a1d7f60

Historical staging acceptance, not current-candidate proof

5719d243876ce235747a61571c794d2cd956e724 completed real EVOXT CD from 01:13:22 to 01:13:46 Beijing time on 2026-10-10 (24 seconds). Installed image IDs matched anonymous public manifests. Public HTTP/2, unique nonce CSP, security/error headers, robots/sitemap, relative Admin redirects, database/Redis readiness and maintenance release passed. The CD service returned inactive/ success, the polling timer stayed disabled, and production storage stayed 8a. Its subsequent automatic-review findings prevented production promotion.

Historical 5719d24 component Installed runtime digest
Web sha256:73519641ffc4125cd2c6bddb53ed99c4996c23f8baa47e74685f305964db7308
updater sha256:c416d770f87d3ff7b62704eeec80c2e7c65a48d098372cdc3f8aeaf943eb9b41
Nginx sha256:8112e5e96b0c577d53c7b4a40f77b6821d56f90e8ea63d95edce62b20757965c

Its source CI #21, contract #27 and publication #2 passed. Development SQLite/MySQL/release-handoff-rollback rounds measured 840.63/844.49/837.03 seconds, never moved to hosted test CI.

The initial 0561762 publication/source evidence remains in source CI #20 and publication #1. Its updater-only bridge digest is sha256:6f0edad01b75449b73a387a3d9bb21ee5d042b460db91da9d5a7b08f8916f624; that tool does not authorize deploying its historical Web application. The initial staging updater bootstrap performed a bounded one-CPU/one-GiB local build; it was not reported as an image-pull-only deployment.

Production and acceptance boundary

Old production 8a forces source builds, so preloading images does not solve its one-core/RAM risk. A real development inspect-clone updater-only A-to-B bridge passed without changing Web/Nginx/Redis, identities, keys or fixture media. The final real-main A-to-B-to-C fixture passed. A new 20,983,808-byte consistent SQLite production snapshot passed integrity and identity checks without media copying; its offsite copy and full readback SHA256 matched 5ea4d2a3fb8c88f6ed26ab2df30f10422594a10e0d8b5ffda1a9ea1762a34452, and both were fsynced. Production source is canonical, tracked-clean and has no external Git alternates. At the initial production checkpoint the controller remained unchanged and the actual AdminGUI upgrade was pending. The operator opened the authenticated AdminGUI successfully. Its genuine GitHub verification showed zero of sixty anonymous API requests remaining, with a reported reset at 09:27:57 Beijing time on 2026-10-10. The controller bridge stopped in public preflight before any container change. No safety barrier, rate-limit backoff or release provenance check was bypassed. Never fake an idle journal.

After the genuine quota reset, the authorized updater-only bridge completed. Only the controller was recreated with its verified bridge image; the original image and exact private configuration were retained. The application still ran 8a until the operator clicked the enabled production AdminGUI upgrade button. The normal native upgrade completed from 09:32:02 to 09:32:23 Beijing time on 2026-10-10 (21 seconds). GUI progress reached 100% / success. Current, target, Web and updater runtime matched main 3a74a4e51aa2; maintenance was released. Installed Web/updater/Nginx image digests matched the verified public main manifests. Previous 8a6e30975c10 remains the native rollback target.

Before creating acceptance fixtures, read-only transactional fingerprints matched the pre-upgrade baseline exactly: identity, 1,306 managed objects, 2,180 local objects, 1,193 lyric links, 587 preferences, six visibility rows, five retained relationships, three storage policies, three permanent whitelist entries, karaoke tables and schema markers/journal. Every existing secret fingerprint matched, including AdminKey. No existing media payload was copied or hashed; this is metadata preservation evidence, not a new 24 GB byte audit.

Actual production API acceptance uploaded one unique 32,044-byte synthetic WAV to each of Master-local, EVOXT Direct and RN Relay storage. It verified the reserved member and object identity, byte-exact HTTP Range before and after directory rename, the renamed Admin/public catalog identity, and deletion of only each confirmed UUID fixture. Direct requests used a separate cookie-free client and only the approved storage HTTPS origin. All three passed, with unchanged relationship identity. A second stable-table/secret comparison after fixture cleanup again matched the pre-upgrade baseline, with zero reservations.

Bounded public probes confirmed single canonical security headers, fresh nonce CSP without script eval/inline-handler exceptions, no-store HTML, hidden exact Nginx version, four unauthenticated Admin reads denied with 401, retained 404 headers, a relative Admin canonical redirect and public-only robots/sitemap. An initial operator assertion incorrectly expected an explicit Admin robots line; source and live output showed the stricter all-API denial with three landing-page exceptions. Correcting that assertion passed; no source policy was relaxed. This is a limited security regression, not penetration certification.

The source checkout intentionally remains at 8a: the native controller fetches and uses exact immutable commits without changing the working tree. Installed image labels and the native journal, not checkout HEAD, identify the live version. Do not run an old Compose configuration to supersede the native upgrade. At 09:35:16 the host had 3.9 GiB disk available, 584 MiB available RAM, and the Web container used about 76 MiB / 512 MiB. This brief sample is not a sustained load benchmark. New container logs had no matched panic/OOM/error diagnostics; the Nginx configuration passed and included User-Agent logging.

Fresh production DNSPup result

The actual nine-node public check completed at 09:33:09 Beijing time on 2026-10-10, after the GUI upgrade. Its score was 70, not the earlier 71. Report the items rather than substituting a score for evidence:

Item Before upgrade, 09:19:21 After upgrade, 09:33:09
Security response headers 5/6, no CSP 6/6, nonce CSP
HTTP configuration 4/7 6/7
HTTP / ALPN HTTP/1.1 / http/1.1 HTTP/2.0 / h2
Exact server version nginx/1.30.4 nginx
Public standards 0/3 2/3, robots and sitemap
HTTP status / sampled response 200 / 721 ms 200 / 760 ms
Registration lookup Returned registration Lookup unavailable

The changed external registration lookup coincides with the lower aggregate score; the scoring weights were not audited, so no exact causal allocation is claimed. The actual tested application configuration items improved. Nine parallel nodes were scheduled, but the service ended some waiting peers after each winning probe; this is not nine independently complete reports.

Remaining nongreen items have explicit boundaries. HSTS already lasts one year; includeSubDomains is withheld until every subdomain is audited, not because HTTPS on the main site is optional. security.txt remains 404 because no real monitored disclosure contact was supplied. DNSSEC/CAA are external DNS tasks, not changed by this binary update. The owner confirmed no mail business; MX is not needed for playback, but optional Null MX/SPF -all/DMARC reject would reduce domain impersonation regardless of traffic size. CDN/WAF/Anycast are optional architectural defenses, not proof of an application vulnerability. Unavailable registration/archive lookups are third-party evidence gaps, not data loss. The Let's Encrypt OCSP retirement and authoritative references remain in docs/public-security-baseline.md; do not enable a nonexistent responder. No DNS/account changes were made merely to raise the score.

Real automatic reservation expiry/live-writer fairness were exercised on the bounded development fixtures. The production API check did not wait the actual 30-minute reservation TTL and must not be described as a production expiry pass. In a separate real production browser tab, the operator selected track 08 (four-minute-two-second Chang Zheng), observed advancing synchronized lyrics and playback through its natural end, and confirmed the normal transition to 09 (Hou Chuang). No console warnings/errors were captured. Only the new acceptance tab was closed; existing user playback tabs were untouched. This proves that one direct-selected 08-to-09 playback on the current network, not natural 07-to-08 or mainland/mobile worst-case behavior. Those conditions and account/captcha paths remain separate from the three-site synthetic API result. Browser encryption is not integrated or included in the installed release.

Scoped storage protocol update, not version synchronization

Storage does not follow every Master release. UI, CI, image-publication and ordinary Master business changes alone are not reasons to update appliances. The difference from deployed 8a6e309 to 3a74a4e includes a real storage protocol change required for interrupted-upload recovery: authenticated POST /internal/v1/storage-control/upload-absence, exclusive-lock absence proof, durable per-upload-generation fences and capability admission checks immediately before storage reservation. Existing files are never deleted by absence proof. Dead storage stages are reconciled during normal service, not only during startup. Older storage remains usable for normal uploads/reads, but cannot safely authorize the new Master's empty expired-upload release; recovery defers instead of falling back to destructive deletion.

The operator explicitly authorized appliance updates. EVOXT Direct and RN Relay now run the independently verified public main Web image at sha256:7f6900b13b1da106b1726cf62246a0d27746d29fdc8e616fd02b70d5b3700c5c. Each update pulled the exact digest and cloned only its existing storage Web container configuration. Original images/configurations and database-only consistent snapshots were retained. Data mounts, TLS, high ports, resource/ security settings, identity, relationship and secret hashes were preserved. Stable media catalogs remained seventeen objects on EVOXT and ten on RN. Public verified HTTPS readiness passed. All other running container IDs and start times remained unchanged, including EVOXT preproduction and Cloudreve. No media was copied or deleted; no Compose init or global prune was run.

For future explicitly needed appliance updates, select an accepted exact main SHA; do not blindly follow every main merge. Fetch that source and check out the fixed SHA. Change only FRONTIERCLOUD_REVISION in the existing .env to the same SHA, preserving endpoint, data paths, credentials and Compose project. Then, from /opt/frontiercloud-storage/repo:

bash scripts/build-native-images.sh <accepted-full-SHA> web-only
docker compose --env-file ../.env -p frontiercloud-storage \
  -f docker-compose.storage.yaml up -d --no-build --wait --wait-timeout 120

The preparation script verifies and pulls public images first. Only confirmed image absence permits immutable-source local compilation; network/auth/proof failure is not a build fallback. Bare git pull and compose up do not update the fixed image SHA. Never use down -v, recreate secrets or re-pair an existing appliance just to change its binary. Verify stable identity, catalog, pairing, mounts, HTTPS readiness and actual image revision after an update.

After actual production upgrade, run business and browser acceptance plus a fresh DNSPup nine-node public baseline scan. That scan is not a penetration-test certification. Fix actual defects; explain nongreen external/optional findings using actual new results rather than a historical score. Browser encryption foundations are not integrated or included in this release candidate.

本次修复: PR #7,dev ba3c9ed25864df04217edc438dbd9fa7d0e0c935。开发机实际五参数 HTTPS、真实 Compose 默认值/空值/精确版本与 SQLite/MySQL 配置回归通过;源码 CI、正常镜像发布与事件 CD 均通过。RN 三份运行镜像及 current/target/updater runtime 已匹配该 dev 提交,就绪检查 200;生产存储容器保持原 ID 且健康。PR #7 现已合并为 main 3c998bc112db2a3ba3f69b360d8a02cf57a0ec37;main 发布及 publish-latest 全部成功,三个默认标签的独立匿名来源和 digest 检查通过。main/dev 已同步该合并提交。

⚠️ **GitHub.com Fallback** ⚠️