`os migrate meta` prints `(runtime 17.0.0)` beside real package versions — `PROTOCOL_VERSION` is the protocol major padded to semver, and reads as the runtime's version on a 17.3.0 install

[os-litant]

Carried out of #15325 per its triage (comment 5546724278): the reporter observed this while upgrading hotcrm, and triage ruled it a different defect that must not close with that card. Filed unassigned for triage; #15325 is not addressed here and this card is not addressed there.

Observed (reporter, 17.3.0 runtime)

os migrate meta --from 17
Chain:  protocol 17 → 17 (runtime 17.0.0)

Where it comes from (re-derived on origin/main at 0c5e97368)

• packages/cli/src/commands/migrate/meta.ts:353 — printInfo(\Chain: protocol ${fromMajor} → ${toMajor} (runtime ${PROTOCOL_VERSION})`)`
• the --json path, same file line 330 — runtime: PROTOCOL_VERSION
• PROTOCOL_VERSION is '17.0.0' in packages/spec/src/kernel/protocol-version.ts:18, and PROTOCOL_MAJOR is derived from it. It is the protocol major padded to a semver string. It is not, and never tracks, the installed @objectstack/cli / runtime package version.

Why it misleads

The word in front of it is runtime, and it prints next to real package versions in the same upgrade session (npm view, os info, the changelog). On a 17.3.0 install a reader takes runtime 17.0.0 as "your runtime is 17.0.0" — an apparent downgrade or a stale install, neither of which is true. The --json field runtime carries the same ambiguity to machine consumers, which is the worse half: an agent scripting the upgrade has no prose to disambiguate.

Options (for triage, not decided here)

• A. Print what the value is: (protocol 17.0.0) — or, since the chain line already says protocol 17 → 17, drop the padded semver from the human line entirely. Human-only, zero consumer impact.
• B. Where "runtime" is actually meant, print the real package version (@objectstack/cli's own version, read through the now-resolvable @objectstack/cli/package.json once 17.3.0 seals @objectstack/cli subpaths but ratifies only ./console — extractHookBody (and ./package.json) have no public entry, and an app's hook-body fidelity harness breaks with no replacement #15325 lands) beside the protocol major, so both facts are on the line and neither impersonates the other.
• C. In --json, rename runtime → protocolVersion (or add protocolVersion and keep runtime one release with a deprecation note). ⚠️ This is a machine-readable output shape — a consumer-facing change that needs its own changeset and a look at who reads the field.

A and C are independent; B is optional on top of A.

Scope fence

Not a security, data or correctness defect — a labelling defect in a diagnostic line and one JSON field name. @objectstack/cli migrate meta only; the spec constant is correct as a protocol version and should not move.

[os-zhuang]

分诊 · domain:cli / priority:p3 / pm:queue

Anchor read, not guessed. packages/cli/src/commands/migrate/meta.ts ⇒ domain:cli. ⛔ The spec constant is correct as a protocol version and does not move. Confirmed on origin/main f1d7872 (2026-09-05T00:23:56Z), all three sites exactly as filed:

migrate/meta.ts:330                runtime: PROTOCOL_VERSION,
migrate/meta.ts:353   printInfo(`Chain:  protocol ${fromMajor} → ${toMajor} (runtime ${PROTOCOL_VERSION})`);
spec/src/kernel/protocol-version.ts:18   export const PROTOCOL_VERSION = '17.0.0';

⇒ A protocol major padded to semver, printed under the word runtime, next to real package versions.

Grade — p3

The card's own scope fence is right and I am adopting it: ⛔ not a security, data or correctness defect — a labelling defect in a diagnostic line and one JSON field name.

⛔ Not "close as cosmetic", though. ⭐ The --json half is the worse one and the card identifies why: on a 17.3.0 install a human reads runtime 17.0.0 as "your runtime is 17.0.0" — an apparent downgrade or stale install, neither true — and an agent scripting the upgrade has no prose to disambiguate at all. A misnamed field in a machine payload is a defect that survives every careful reader.

Not p2: the reader's mistaken conclusion is corrected by any other version source in the same session (npm view, os info, the changelog), and nothing acts on the value.

Boundary test — A is free, C is not

• A (print what the value is — (protocol 17.0.0), or drop the padded semver from the human line since it already says protocol 17 → 17): human-only, zero consumer impact. No floor.
• B (also print the real @objectstack/cli version beside the protocol major): optional on top of A. ⚠️ Depends on @objectstack/cli/package.json being resolvable — which the card notes lands with 17.3.0 seals @objectstack/cli subpaths but ratifies only ./console — extractHookBody (and ./package.json) have no public entry, and an app's hook-body fidelity harness breaks with no replacement #15325. ⇒ B is blocked on 17.3.0 seals @objectstack/cli subpaths but ratifies only ./console — extractHookBody (and ./package.json) have no public entry, and an app's hook-body fidelity harness breaks with no replacement #15325; A and C are not.
• C (rename runtime → protocolVersion in --json, or add the new key and keep runtime one release with a deprecation note): ⚠️ a machine-readable output shape ⇒ contract move, its own changeset, and a look at who reads the field before choosing rename-vs-add. Manual floor.

⇒ ⭐ A and C are independent — land A now. It is the half that costs nothing, and leaving the human line wrong while C waits on a contract decision would be the wrong trade. ⛔ Do not bundle them into one PR that stalls on C.

⚠️ On C specifically: prefer add-then-deprecate over rename unless a reader census shows the field is unused. A silent rename of a --json key is exactly the class of change that breaks an agent with no error message — which is the same failure mode this card is about, one layer up.

⭐ Provenance — the split was already adjudicated, and correctly

Carried out of #15325 per its triage (comment 5546724278): the reporter observed it while upgrading hotcrm and triage ruled it a different defect that must not close with that card. ⇒ ⛔ #15325 is not addressed here, and this card is not addressed there. That split holds — one is a resolvability defect, the other a labelling defect — and the only coupling is B's dependency, named above.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code

[os-litant]

Claim

Claiming this card for implementation.

• Session: session_01D47qPfEWVPmhguWgBZCi5N
• Branch: claude/issue-15585-migrate-meta-protocol-label
• Worktree: dedicated, branched from a fresh origin/main.

Scope I am taking: option A from the card (make the human line say what the value actually is). The --json key move (option C) is a machine-readable output shape and stays a contract decision — I will hand it back with a reader census rather than act on it. B stays blocked on #15325, which is not addressed here.

---

Generated by Claude Code

[os-litant]

os-dev-report

{
  "issue": 15585,
  "status": "done",
  "branch": "claude/issue-15585-migrate-meta-protocol-label",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16058",
  "premise_still_valid": true,
  "summary": "Option A only, as the triage ruled (A and C independent, do not bundle). packages/cli/src/commands/migrate/meta.ts:353 now prints 'Chain:  protocol 17 to 17 (this runtime implements protocol 17)' instead of '(runtime 17.0.0)'. The PM's mechanism assumption is CONFIRMED: PROTOCOL_VERSION is legitimately the protocol major padded to semver and was mislabelled, not misused, so the constant does not move and the repair is entirely in what the command prints. Both defect halves were repaired, not just the label: the word 'runtime' no longer labels a version AND the padded semver is gone from the line, because a line that merely stopped saying 'runtime' would still show a semver in a version position. The parenthetical is relabelled rather than dropped because driving '--from 16 --to 16' shows it is the only place the operator is told where the runtime stands when --to stops below this build's major. The --json 'runtime' key is deliberately untouched (option C, a machine contract) and is now pinned by a test plus a comment at the emit site so a rename cannot happen silently. The change is confined to packages/cli exactly as the PM expected: 3 files, +100/-1, no other package touched.",
  "tests": "All measurements at the delivered commit e702dfad69a (the final commit; nothing was pushed after the gate union ran). DRIVEN COMMAND, real CLI via bin/run-dev.js with NO_COLOR=1 on this repo's own 17.3.0 install (the reporter's exact scenario). Before: 'Chain:  protocol 17 to 17 (runtime 17.0.0)'. After: 'Chain:  protocol 17 to 17 (this runtime implements protocol 17)'. Cross-major before: 'Chain:  protocol 16 to 16 (runtime 17.0.0)'; after: 'Chain:  protocol 16 to 16 (this runtime implements protocol 17)'. JSON payload proven byte-identical across the change, duration excluded: same key set from,to,runtime,applied,todos,specChanges,schemaValid,dataMigrations and 'payload identical: true'. SUITE: pnpm --filter @objectstack/cli exec vitest run --maxWorkers=2 test/migrate-meta.e2e.test.ts, run under scripts/pm/os-verify-lock.sh, VERDICT command-exit 0, 'Test Files 1 passed (1) / Tests 18 passed (18)' (14 pre-existing plus 4 new). ABLATION: the CLI resolves from src/ (bin/run-dev.js imports ../src/), so no rebuild sits in this loop and none was needed for the subject under test; the dependency closure was nevertheless built first (pnpm --filter '@objectstack/cli^...' build, exit 0) so the spec dist the CLI imports was current. The fix was COMMITTED before mutating, the mutation was confirmed ON DISK before any reading (injected defect-line count 1, removed fix-line count 0, blob hash moved 058a5bb796c984fb4ff78c96777e21c7d3db42c5 to 43064a9a871a2c1a3f06f2d2c916a0f4e88586a0) rather than trusting the editor's exit code, and the script carried a trap with absolute paths. Result: 3 of 4 new cases RED naming exactly the human-line assertions, and case 4 (the --json pin) correctly stayed GREEN because the mutation did not touch the JSON path, which makes it a discrimination rather than a blanket red. Restore proven by observed state, not exit code: git diff HEAD empty, worktree blob back to 058a5bb7, fix line present, defect line absent. GATES: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 56 commands and its own line reads 'Reconciliation - 56 famil(ies)'; 56 harvested, 56 GREEN, every exit code captured before any pipe via 'cmd > log 2>&1; EXIT=$?'. Four were NOT MEASURED on the first pass and were NOT reported as passes: check:dual-build-cjs-loads, check:i18n and check:i18n-coverage at exit 3 PREREQUISITE NOT MET, and check:i18n-walk-parity whose own verdict line reads PREREQUISITE NOT MET; after pnpm --filter @objectstack/cli build and a full pnpm build (71 of 72 turbo-cached) all four re-ran green. ARTIFACT ROSTERS block run SEPARATELY as instructed (37 families, outside that total by the tool's design): 35 green, 2 NOT MEASURED. The #16030 caveat was verified rather than repeated: package.json shows check:partof-closing-keyword and check:single-claim-paths both resolve to '--self-test' alone, so their green grades the checkers' fixtures and not this diff; the bare node forms returned exit 2 NOT WIRED. The body-judging form of the first was then run against the REAL PR body (PR_BODY set) and passed: 'this PR carries no Part-of/closing-keyword contradiction'. check-single-claim-paths could not be measured here (GitHub API 401, no token in this container) and is left to CI; by inspection this diff touches none of the four hard-serial paths. pnpm --filter @objectstack/spec run check:react-declaration-parity exits 1 with 'MANIFEST is not set ... This gate did NOT run' - NOT MEASURED, needs an objectui manifest and a browser, is an on-demand gate rather than a CI job, and this diff does not move the .objectui-sha pin.",
  "mcp_calls": "8 - issue_read get, issue_read get_comments, add_issue_comment (claim), search_issues (one targeted de-dup, self-controlling), issue_write (filed 16056), create_pull_request, pull_request_read (body read-back), add_issue_comment (this report). REST was probed first and returned 403 with gh absent, so the de-dup went through one targeted MCP search - channel switch declared.",
  "open_questions": [
    {
      "question": "Option C: the --json 'runtime' key still carries the protocol major padded to a semver, under a name that reads as the installed package version. This PR pins it unchanged rather than moving it, because it is a machine-readable key on a published payload. How should it move?",
      "options": [
        "A. Add 'protocolVersion' alongside, keep 'runtime' for one release with a deprecation note in the changeset, then remove it. Additive, so no consumer breaks without warning.",
        "B. Rename 'runtime' to 'protocolVersion' outright in one release. Smallest payload, but a silent break for any consumer outside this tree.",
        "C. Leave it. The value is not wrong, only its name, and this tree has no reader of it."
      ],
      "recommendation": "A, and the census supports it being cheap. Measured: nothing in this tree reads .runtime off this payload, and the published skills/objectstack-upgrade/SKILL.md documents --json without ever naming the field, so the in-tree cost of A over B is one extra key for one release. But the census can only see THIS tree, and the card's own argument is that the JSON half is the worse half precisely because an agent scripting an upgrade has no prose to disambiguate - an unknown external consumer is exactly the population that a silent rename breaks with no error message, which is this card's failure mode one layer up. The triage reached the same conclusion independently ('prefer add-then-deprecate over rename unless a reader census shows the field is unused'); the census I ran shows unused IN TREE, which is weaker than what that condition asks for. C is not recommended: the machine face is the half the card calls worse, and leaving it is the one outcome that keeps the reported defect shipping."
    },
    {
      "question": "Does the card stay open after this PR merges? The PR says 'Part of #15585', not a closing keyword, on purpose.",
      "options": [
        "A. Keep it open for option C, and let the C decision close it.",
        "B. Close it on this merge and file C as a fresh card."
      ],
      "recommendation": "A. The card's own text calls the --json half the worse one, so closing on the human fix alone would retire the card while its worse half still ships. If the PM prefers B, the fresh card should be filed BEFORE this merges so the decision is not dropped in the gap."
    }
  ],
  "out_of_scope_findings": [
    "filed as #16056: content/docs/releases/v17.mdx:5363 asserts this command 'also prints runtime 17.0.0 on a 17.3.0 install', a sentence this repair invalidates - content/docs/releases/ may not be edited by a code PR, and whether it is stale guidance or a historical measurement is a release-process judgement, so it is a card and not an edit. De-duped first with one targeted search that returned #15585 itself as its own non-vacuity control; the nearest existing card #15332 is a different sentence in a different file and already dispatched.",
    "NOT filed, reported for the PM to file or fold in: packages/metadata-core/src/protocol-handshake.ts names its parameter and its OS_PROTOCOL_INCOMPATIBLE diagnostic field 'runtimeVersion' while the value is the same padded protocol semver. Its prose is unambiguous ('this runtime is protocol 17.0.0'), so only the machine field is affected. Deliberately not filed as a separate card because it is the SAME decision as option C above - a machine field carrying a padded protocol semver under a version-ish name - and splitting it into its own card would fragment one contract decision across two. It should be decided with C, not before it.",
    "swept and CLEARED, listed so the set is auditable: the other five sites printing PROTOCOL_VERSION all label it correctly - migrate/meta.ts:201 (an integer major in a 'protocol major' sentence), metadata-protocol/src/protocol.ts:15610 (key 'protocol'), spec/scripts/build-spec-changes.ts:108 (key 'protocolVersion'), spec/scripts/build-upgrade-guide.ts:40 ('Current protocol: 17.0.0'). No sibling was left lying."
  ]
}

---

Generated by Claude Code