fix: restore block-tools publish/mark-stable scripts

[blackcat]

Why

block/package.json lost two scripts in d60844a ("PyTorch added, matrix size selection added", Apr 30) — the diff shows block/package.json | 2 -- with no mention in the commit body, so it looks accidental. Without prepublishOnly, pnpm -r publish no longer runs block-tools publish, so the block-pack stopped reaching the registry S3 bucket from v0.6.0 onward.

Verified state of https://blocks.pl-open.science/v2/milaboratories/gpu-test/<version>/manifest.json:

version	status
0.3.7 – 0.5.2	200
0.6.0, 0.7.0, 0.7.1	404

That's why Desktop's block picker still shows 0.5.2 even though pnpm publish happily pushes new versions to npm and the software-package registry every release.

Sibling repo platforma-open/titeseq-analysis still carries both scripts. Restored copy matches that template verbatim.

What

block/package.json — +2 lines:

```json
"mark-stable": "block-tools mark-stable -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",
"prepublishOnly":"block-tools pack && block-tools publish -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",
```

Changeset: patch bump on @platforma-open/milaboratories.gpu-test.

After merge

CI on main cuts a new patch (0.7.2) and the changeset → release flow runs prepublishOnly again → block lands at …/v2/milaboratories/gpu-test/0.7.2/manifest.json → Desktop picker shows it.

Greptile Summary

This PR restores two block/package.json scripts (prepublishOnly and mark-stable) that were accidentally dropped in commit d60844a, causing versions 0.6.0–0.7.1 to be silently skipped by the block registry S3 upload even though npm publishes succeeded.

• block/package.json: adds back prepublishOnly (block-tools pack && block-tools publish …) and mark-stable (block-tools mark-stable …) to restore the block-pack-to-S3 upload path on every pnpm publish.
• .changeset/restore-block-publish.md: adds a correct patch-level changeset entry that will cut version 0.7.2 and trigger the restored flow on the next CI release.

Confidence Score: 4/5

The change is a targeted two-line restore that re-enables block-pack uploads to S3 on publish; no logic is altered beyond adding back the missing scripts.

The fix is straightforward and well-evidenced. The one thing worth a second look is that prepublishOnly omits the shx rm -rf ./block-pack clean step that the build script performs, which could let stale artifacts slip into a publish if ./block-pack is left over from an earlier run.

block/package.json — specifically whether prepublishOnly should also clean ./block-pack before packing.

Important Files Changed

Filename	Overview
block/package.json	Restores two accidentally-dropped scripts (mark-stable, prepublishOnly); note that prepublishOnly does not clean ./block-pack before packing, unlike the build script.
.changeset/restore-block-publish.md	Correct patch-level changeset for the restored scripts with a clear description of the regression.

Sequence Diagram

sequenceDiagram
    participant CI as CI (release)
    participant pnpm as pnpm -r publish
    participant npm as npm registry
    participant bt as block-tools
    participant s3 as S3 block registry

    CI->>pnpm: trigger release
    pnpm->>bt: prepublishOnly → block-tools pack
    bt-->>pnpm: block-pack built
    pnpm->>bt: block-tools publish -r s3://…
    bt->>s3: upload block-pack
    s3-->>bt: 200 OK (manifest.json visible)
    pnpm->>npm: "publish @platforma-open/milaboratories.gpu-test"
    npm-->>pnpm: published

    note over bt,s3: This path was broken from v0.6.0–v0.7.1 (missing prepublishOnly)

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
block/package.json:7
The `prepublishOnly` script calls `block-tools pack` without first removing `./block-pack`, whereas the `build` script explicitly does `shx rm -rf ./block-pack` before packing. If a stale `./block-pack` directory is present from a previous run, old artifacts could be included in the published block-pack. Consider adding the clean step here for consistency with `build` and to guarantee a fresh pack on every publish.

```suggestion
    "prepublishOnly": "shx rm -rf ./block-pack && block-tools pack && block-tools publish -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",
```

_{Reviews (1): Last reviewed commit: "fix: restore block-tools publish/mark-st..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[gemini-code-assist]

Code Review

This pull request restores the prepublishOnly and mark-stable scripts in block/package.json that were previously dropped, and adds a corresponding changeset file to document the patch. I have no feedback to provide as the changes are correct and there are no review comments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[greptile-apps]

The prepublishOnly script calls block-tools pack without first removing ./block-pack, whereas the build script explicitly does shx rm -rf ./block-pack before packing. If a stale ./block-pack directory is present from a previous run, old artifacts could be included in the published block-pack. Consider adding the clean step here for consistency with build and to guarantee a fresh pack on every publish.

Suggested change

	"prepublishOnly": "block-tools pack && block-tools publish -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",
	"prepublishOnly": "shx rm -rf ./block-pack && block-tools pack && block-tools publish -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",

Prompt To Fix With AI

This is a comment left during a code review.
Path: block/package.json
Line: 7

Comment:
The `prepublishOnly` script calls `block-tools pack` without first removing `./block-pack`, whereas the `build` script explicitly does `shx rm -rf ./block-pack` before packing. If a stale `./block-pack` directory is present from a previous run, old artifacts could be included in the published block-pack. Consider adding the clean step here for consistency with `build` and to guarantee a fresh pack on every publish.

```suggestion
    "prepublishOnly": "shx rm -rf ./block-pack && block-tools pack && block-tools publish -r 's3://milab-euce1-prod-pkgs-s3-block-registry/pub/releases/?region=eu-central-1'",
```

How can I resolve this? If you propose a fix, please make it concise.