MILAB-6493: migrate onto the structurer - #68
AStaroverov wants to merge 2 commits into
Conversation
Run the canonical block-tools structure upgrade (refresh --update-deps-only → install → refresh → install → fmt) via pnpm dlx @platforma-sdk/block-tools@latest. Catalog bumps: block-tools 2.10.15→2.11.1, model/ui-vue 1.79.3→1.79.15, workflow-tengo 6.5.1→6.6.3, tengo-builder 4.0.8→4.0.9, test 1.79.4→1.79.16, ts-builder 1.5.0→1.5.2. Structural output: tool-managed tsconfig, oxlint/oxfmt configs (replacing eslint.config.mjs), turbo.json, CI workflows, block index, package.json across all packages, plus the root upgrade-sdk script. Source files reformatted by oxfmt (quote/comma/wrap only, no logic change). Pure tool output — no author-code fixes required (Round-3 failure classes all N/A: helpers already a direct model dep, no block-local PlId brand, no test package or workflow test lane).
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request migrates the block onto the structurer (block-tools 2.11.1) and upgrades the SDK dependencies. It replaces hand-maintained tsconfig and ESLint configurations with tool-managed oxlint and oxfmt configurations, resulting in formatting updates across several files. The review feedback suggests removing leftover eslint dependencies in model/package.json and ui/package.json since the project has transitioned to oxlint.
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.
| "eslint": "catalog:", | ||
| "vitest": "catalog:", | ||
| "typescript": "catalog:" | ||
| "eslint": "catalog:" |
There was a problem hiding this comment.
The eslint dependency appears to be a leftover from the migration to oxlint. As the lint script has been removed and the project is now using oxlint for linting (as mentioned in the pull request description), this dependency can likely be removed to keep the project's dependencies clean.
| "@platforma-sdk/eslint-config": "catalog:", | ||
| "typescript": "catalog:", | ||
| "vitest": "catalog:", | ||
| "eslint": "catalog:" |
There was a problem hiding this comment.
The eslint dependency appears to be a leftover from the migration to oxlint. As the lint script has been removed and the project is now using oxlint for linting (as mentioned in the pull request description), this dependency can likely be removed to keep the project's dependencies clean.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| pnpm-recursive-build: false | ||
| test: false | ||
|
|
||
| test: true |
There was a problem hiding this comment.
The PR description explicitly states "V3 test API / CI readiness race: no test/ dir, no workflow test files → no test lane re-enabled," yet this line changes test: false to test: true. The workflow package now has @platforma-sdk/test in devDependencies but no test script, and the root turbo.json test task depends only on build and check. If no workspace provides a runnable test script, the turbo test run may silently succeed or fail unexpectedly in CI. Confirming which packages actually have tests and whether this is intentional would clarify the intent.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/build.yaml
Line: 31
Comment:
**CI test lane enabled, contradicting PR description**
The PR description explicitly states "V3 test API / CI readiness race: no `test/` dir, no workflow test files → no test lane re-enabled," yet this line changes `test: false` to `test: true`. The workflow package now has `@platforma-sdk/test` in devDependencies but no `test` script, and the root `turbo.json` test task depends only on `build` and `check`. If no workspace provides a runnable `test` script, the turbo test run may silently succeed or fail unexpectedly in CI. Confirming which packages actually have tests and whether this is intentional would clarify the intent.
How can I resolve this? If you propose a fix, please make it concise.
| "do-pack": "shx rm -f *.tgz && block-tools pack && pnpm pack && shx mv *.tgz package.tgz", | ||
| "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'" | ||
| }, |
There was a problem hiding this comment.
--unstable flag removed from block publish
The old prepublishOnly script called block-tools publish --unstable, which marked every CI-published artifact as an unstable/preview release. The new script calls block-tools publish without that flag, meaning artifacts published on every CI run are now treated as stable (or at minimum, no longer explicitly marked unstable). The separate mark-stable workflow still exists for explicit promotion. If block-tools publish without --unstable now publishes to the stable channel, that changes the release semantics for this block — every merge would immediately become a stable release rather than requiring an explicit stability promotion step.
Prompt To Fix With AI
This is a comment left during a code review.
Path: block/package.json
Line: 13
Comment:
**`--unstable` flag removed from block publish**
The old `prepublishOnly` script called `block-tools publish --unstable`, which marked every CI-published artifact as an unstable/preview release. The new script calls `block-tools publish` without that flag, meaning artifacts published on every CI run are now treated as stable (or at minimum, no longer explicitly marked unstable). The separate `mark-stable` workflow still exists for explicit promotion. If `block-tools publish` without `--unstable` now publishes to the stable channel, that changes the release semantics for this block — every merge would immediately become a stable release rather than requiring an explicit stability promotion step.
How can I resolve this? If you propose a fix, please make it concise.
The facade packed twice: `build` already runs `shx rm -rf ./block-pack && block-tools pack`, and CI publishes with build-script-name 'build', so the `block-tools pack &&` prefix on prepublishOnly re-packed the same inputs a second time on every release. Brings the script to the form the structured blocks use (clonotype-space, clonotype-clustering, immune-assay-data, antibody-tcr-lead-selection), quoting included — which also means the structurer will not report it as drift if PR #68 lands. No changeset, matching the same change on clonotype-space (62678e5).
1 participant
Migrates antibody-sequence-liabilities onto the structurer (
block-tools structure) — a full SDK upgrade replacing hand-maintained config with tool-managed output.What ran
Canonical flow via
pnpm dlx @platforma-sdk/block-tools@latest:refresh --update-deps-only → install → refresh → install → fmt.Catalog bumps
Changes
eslint.config.mjs),turbo.json, CI workflows, block index, andpackage.jsonacross all packages; adds the rootupgrade-sdkscript.Clean migration — no author-code fixes
All Round-3 failure classes were N/A (verified):
@milaboratories/helpersalready a direct model dep.test/dir, no workflow test files → no test lane re-enabled.Verification
build:dev8/8 greencheck7/7 green (type + lint + fmt)require-latestCI gate satisfied (block-tools + tengo-builder both latest)Commits
incorporate structurer— pure tool outputadd changeset— patch-bumps model/ui/workflow/software → cascades to root blockGreptile Summary
This PR migrates the antibody-sequence-liabilities block onto the
block-tools structuretoolchain (block-tools2.11.1), replacing hand-maintained tsconfig/eslint config with tool-managed oxfmt/oxlint and updating all SDK catalog versions (model/ui-vue 1.79.15, workflow-tengo 6.6.3, tengo-builder 4.0.9, ts-builder 1.5.2). Source file changes are purely cosmetic reformatting (double quotes, trailing commas, multiline wrapping) with no logic changes.Key touched terms:
BlockModelV3— Fluent builder from@platforma-sdk/modelthat wires together args, outputs, and metadata for the block. Unchanged in logic; quotes and formatting updated by oxfmt.DataModelBuilder— Defines the versioned block state schema and upgrade path. Only formatting changes.Modality— Type union\"antibody\" | \"peptide\"controlling which liability rules and regions are offered. Quote style changed from single to double; no semantic change.CustomLiability— Interface for user-defined liability rules (name, pattern, riskLevel, fixability, regions). Quote style updated; no structural change.liabilityTypes— Exported array of all predefined liability configurations (13 entries). Reformatted from single-line objects to multi-line; no data change.platforma— The exportedBlockModelV3instance; the block's runtime entry point. No logic changes.oxfmt/oxlint— New formatter and linter (from@milaboratories/ts-builder) replacing ESLint. Introduced in this PR via.oxfmtrc.json/.oxlintrc.jsonconfig files in model and ui.ts-builder check— Unifiedcheckscript (type-check + lint in one step) replacing the separatetype-checkandlintturbo tasks.block-tools structure— Tool that auto-generates tsconfig, turbo tasks, CI workflows, and config files from a.structuresentinel. Central to this migration; adds the rootupgrade-sdkscript.runenv-python-3— Python 3.12 execution environment for the liabilities calc script. Moved fromdependenciestodevDependenciesinliabilities-calc-script; the actual runtime reference lives in theblock-softwarefield and is unaffected.Confidence Score: 4/5
The migration is a clean toolchain swap with no logic changes to source code; the two items worth a second look are the --unstable flag removal from block publish and the test-lane enablement that contradicts the PR description.
All source file changes are pure reformatting. The two non-trivial behavioral changes — removing --unstable from block-tools publish and flipping test: false → true in CI — are not clearly explained and one directly contradicts the PR description. The --unstable removal in particular changes when blocks become visible as stable releases, which could surprise consumers if the intent was to keep them preview until explicit promotion.
block/package.json (--unstable removal) and .github/workflows/build.yaml (test: true vs. PR description)
Important Files Changed
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD A[pnpm build:dev] --> B[turbo: build] B --> C[check] C --> D1[ts-builder check\nmodel] C --> D2[ts-builder check\nui] C --> D3[pl-tengo check\nworkflow] B --> E1[ts-builder build\nmodel] B --> E2[ts-builder build\nui] B --> E3[pl-tengo build\nworkflow] B --> E4[pl-pkg build\nliabilities-calc-script] B --> E5[block-tools pack\nblock] F[pnpm test] --> G[turbo: test] G --> H[vitest\nmodel] G --> I[workflow test\n@platforma-sdk/test] J[pnpm fmt] --> K[turbo: fmt] K --> L1[ts-builder format\nmodel] K --> L2[ts-builder format\nui]%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD A[pnpm build:dev] --> B[turbo: build] B --> C[check] C --> D1[ts-builder check\nmodel] C --> D2[ts-builder check\nui] C --> D3[pl-tengo check\nworkflow] B --> E1[ts-builder build\nmodel] B --> E2[ts-builder build\nui] B --> E3[pl-tengo build\nworkflow] B --> E4[pl-pkg build\nliabilities-calc-script] B --> E5[block-tools pack\nblock] F[pnpm test] --> G[turbo: test] G --> H[vitest\nmodel] G --> I[workflow test\n@platforma-sdk/test] J[pnpm fmt] --> K[turbo: fmt] K --> L1[ts-builder format\nmodel] K --> L2[ts-builder format\nui]Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "MILAB-6493: add changeset for structurer..." | Re-trigger Greptile
Context used: