Deploy pages call the Community image's exact version tag immutable, but a manual rebuild re-pushes the same X.Y.Z

Filing gate ① (a public page asserts something the product's own release pipeline contradicts). Class a; reach: /docs/deploy/docker, /docs/deploy, and /docs/reference/security once PR #358 lands. Source: the dev report on #356 (PR #358, out_of_scope_findings). Filed by the repo:docs.objectos.ai seat (objectstack-ai/objectstack#9831), session_01QsR2jTaZ2GeyfjANMwstiw. Dedupe: open issues here searched for "immutable tag", "digest pin community", "workflow_dispatch rebuild": none.

What is wrong

content/docs/deploy/docker.mdx:19-20 (§ Pin the image): "Only the exact tag is immutable — the rolling ones move with the next release".
content/docs/deploy/index.mdx:38: "A rolling tag such as latest can be re-pointed under you; an exact version, or a digest, cannot."
reference/security.mdx § Supply chain, after PR docs(reference): say where each image comes from and how to pin it in Supply chain #358: "Pin one exact image … the exact version tag (X.Y.Z) on Community".

objectstack's .github/workflows/docker-publish.yml:12-14 declares a workflow_dispatch entry for "manual backfill / rebuild of an already-published version, e.g. to pick up node:22-slim base-image CVE patches", and :39-40 and the metadata step push the same X.Y.Z tag again. So an exact version tag can be re-pointed at new bytes. Only a digest is immutable.

Done looks like

All three pages say the same true thing. For example: the exact X.Y.Z tag changes only when the maintainers rebuild that version (for base-image patches), and a digest never changes, so production that needs byte-for-byte reproducibility pins the Community image by digest too (ghcr.io/objectstack-ai/objectstack@sha256:…), which docker pull reports. The wording is grounded in the workflow file and cites it. English only. Since this reverses a capability claim ("cannot be re-pointed"), the locale siblings of the changed pages are deleted in the same PR (AGENTS.md rule 3).

维护者速读

部署页说 Community 镜像的精确版本标签（X.Y.Z）不可变，但 objectstack 的发布流水线允许手动重建已发布版本（为打基础镜像补丁），会重新推同一个 X.Y.Z。真正不可变的只有 digest。本卡把 docker、部署总览、安全三页的说法统一改正。

Claim: PM loop round 3 · 2026-10-27T23:05Z
Session: session_01QsR2jTaZ2GeyfjANMwstiw (seat thread; the dev is card thread session_01QsR2jRTkwFHGAqbE7ZnPtt, identity by branch)
Account: zhuangjianguo
Branch: claude/project-thread-0npumh (platform-assigned; a card thread can push only this branch)
Worktree: the card thread's own docs.objectos.ai checkout
Domain: domain:docs (single-lane repository)
Seat: repo:docs.objectos.ai#1
File surface: content/docs/deploy/docker.mdx, content/docs/deploy/index.mdx, content/docs/reference/security.mdx (English), plus deletion of those pages' locale siblings under AGENTS.md rule 3 (the claim "an exact version cannot be re-pointed" is reversed) — stop on breach; explain in the report
Container & model: S, mode:thread, model: default tier (TIER_DEFAULT — sister repository, hand-derived: no packages/spec, no protocol-semantic surface), effort: project default
Clause-②: no
Metadata-protocol: none
Responsibility: n/a — documentation wording, filed by this seat
Thread-read: none
Premise: confirmed — objectstack .github/workflows/docker-publish.yml:12-14 declares a workflow_dispatch rebuild of an already-published version, and its metadata step re-tags X.Y.Z. Enterprise claims (digest pinning) are unchanged.
Tier: none.
Serial constraints cleared: security.mdx is written by PR #358 (#356, in landing), and this card starts from main only after #358 merges. PR #355 (#340, Tier H, waiting on approval) changes one link in security.mdx and merges main when it lands. The #347 translation pass writes deploy/*.zh-Hans.mdx siblings in a later batch, and any sibling this card deletes is re-derived from the corrected English.

os-dev-report

{
  "issue": 359,
  "status": "done",
  "branch": "claude/project-thread-0npumh",
  "pr": "https://github.com/objectstack-ai/docs.objectos.ai/pull/361",
  "session": "session_01QsR2jRTkwFHGAqbE7ZnPtt",
  "premise_still_valid": true,
  "summary": "Docker, Deployment and Security now say the same thing: the exact X.Y.Z tag fixes the version, not the bytes. A maintainer rebuild of a published version (docker-publish.yml workflow_dispatch) re-pushes the same X.Y.Z onto a new image, and only a digest is fixed. docker.mdx section Pin the image shows how to read the index digest with docker buildx imagetools inspect (measured), says to pin the first Digest line (both architectures), shows the repo@sha256 reference with the version kept beside it, and upgrade steps 3 and 5 say tag or digest. deploy/index.mdx: the Pin it by cell and the Which bytes run row. security.mdx: the Supply chain pinning bullet and the hardening checklist item. Enterprise claims unchanged. One commit, head d990503, branched from main 8d02849 after #358. No locale siblings exist for the three pages, so rule 3 deletes nothing.",
  "tests": "Content-only diff, no test files. Measured: docker buildx imagetools inspect ghcr.io/objectstack-ai/objectstack:latest exit 0, MediaType application/vnd.oci.image.index.v1+json, Digest sha256:3d14ddf5..., Manifests linux/amd64, linux/arm64 and two attestation manifests; 18.2.0, 18.2, 18 and latest all answer the same index digest. docker pull NOT MEASURED (no Docker daemon in the container), so the page cites only imagetools. Playwright on next start of the build: 7 shots, every section HTTP 200 with its anchor and its new sentence present and no horizontal scroll: docker#pin-the-image (1440x900 and 390x844), docker#upgrade-and-rollback, deploy#the-two-images, deploy#every-deployment-decides-three-things, security#supply-chain, security#suggested-hardening-checklist. Screenshots in /mnt/project-files/docs-359/.",
  "gates": "local at d990503, exit captured before any pipe: pnpm install --frozen-lockfile 0; gen-zh-hant --check 0; check-doc-samples 0; turbo type-check --force 0; turbo build --force 0 (NEXT_PRIVATE_STANDALONE=true, 56 s under the verify lock, VERDICT command-exit 0); check-locale-surface 0; check-positioning 0; check-search-locales 0; check-translations 0; check-translation-ownership --files 0 (3 files, 0 translation artifacts); turbo test 0; smoke-docs.mjs --base http://localhost:3459 0 (4 pages, negative control red, search in 8 locales). PR CI at report time: Node floor success, Ownership & freshness success, build in_progress.",
  "dogfood_battery": "n/a - sister repository, no ! in the title, Clause-2 no",
  "mcp_calls": "0",
  "api_writes": "2 - fleet-write relay pr_create (run 40601292937, PR #361, 7406/7406 bytes read back identical, assignee zhuangjianguo); this os-dev-report comment via post-stamped.mjs. git push is not a REST write. Reads only: public REST (card, claim, PR #358, check-runs, Actions runs list), ghcr anonymous token plus tags/list, imagetools inspect.",
  "line_budget": "3 files, +48 -18",
  "deviations": [
    "Card cited docker-publish.yml:39-40 for the re-push; on e4ba846f those lines are the job-wall comment that records the two dispatch runs. The tag computation and push are :143-154 and :156-165, cited instead.",
    "docker.mdx upgrade steps 3 and 5 also changed (tag -> tag or digest): same file, not an immutability sentence, kept so the steps match the new pinning advice."
  ],
  "open_questions": [
    {
      "question": "docker.mdx:4 (frontmatter description) and :284 (Enterprise adds intro) still list digest pinning as something the Enterprise image adds, while the page now tells Community users to pin a digest too. Reword?",
      "options": [
        "A: leave as is; Enterprise's difference is that the release notes name the digest and it is the only pin",
        "B: a follow-up card rewords both to 'a release-named digest' (Enterprise wording, needs the seat's call)"
      ],
      "recommendation": "B as a small docs card, because a reader comparing editions may read digest pinning as Enterprise-only."
    }
  ],
  "out_of_scope_findings": [
    "class: a - reach: public page /docs/deploy/kubernetes section The image is pinned exactly (kubernetes.mdx:63-65) says an exact version is enough and that only 'a moving tag means two pods ... can run different builds'; a rebuilt exact tag can do the same (docker-publish.yml:12-14, :143-165) - same defect class as #359, outside this claim's file surface - dedupe words: kubernetes exact version, pod different builds, digest pin",
    "class: a (source reading, NOT MEASURED) - reach: exception: maintainer (a manual workflow_dispatch) - objectstack docker-publish.yml:150-154 computes X.Y, X and latest on every non-prerelease version with no check that it is the newest, so a dispatch rebuild of an older version (the entry point at :12-14 offers it) would re-point latest and the rolling tags back to that older version - carrier: objectstack seat for docker-publish.yml - dedupe words: rebuild moves latest, backfill rolling tags, docker-publish latest older"
  ]
}

Generated by Claude Code

Landing · 2026-10-27T23:45Z · session_01QsR2jTaZ2GeyfjANMwstiw · seat repo:docs.objectos.ai#1

Reading	Value
PR #361	MERGED through the merge queue as `b92d915`: squash, under the maintainer's standing go-ahead, on head `c38e806`, the ACCEPTed head of seat record 6456171038
`main` CI run 40603771422 on `b92d915`	`build` success · `Deploy docs / Publish the tested Worker` success, with "Assert a new version is serving" success · `Deploy docs / Smoke-check the live site` success · rollback and failure-card jobs skipped

State change: this card closed itself through Fixes #359, and pm:dispatched comes off here. The rolling-tag behaviour found along the way is objectstack-ai/objectstack#26961.

Navigation Menu

Repository navigation

Deploy pages call the Community image's exact version tag immutable, but a manual rebuild re-pushes the same X.Y.Z #359

What is wrong

Done looks like

维护者速读

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deploy pages call the Community image's exact version tag immutable, but a manual rebuild re-pushes the same X.Y.Z #359

Description

What is wrong

Done looks like

维护者速读

Activity

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions