Parent: #846. Related: #945 (constructor-assigned generic fields; separate path).
On origin/main ed04a5c5b, with TypeScript 5.7.3 and a freshly rebuilt Home home-tsc, this non-generic cross-file fixture differs:
// owner.js
export class Box {
/** @type {string} */
value = /** @type {*} */ (null);
}// consumer.ts
import { Box } from "./owner.js";
const box = new Box();
box.value = 1;
const bad: number = box.value;Under strict, allowJs, checkJs, noEmit, skipLibCheck, target es2022, and node resolution, TypeScript reports two TS2322 diagnostics: number is not assignable to string at (3,1), and string is not assignable to number at (4,7). Home reports two TS2322 diagnostics at the same positions but treats the field as null: literal 1 is not assignable to null, then null is not assignable to number. The source JSDoc annotation is being lost to the initializer type on the source-owned direct class-field path. The same shape with a defaulted JSDoc class template also differs, but the non-generic fixture proves this is independent of template transfer.
Acceptance: retain the declared JSDoc field type across the JS-to-TS Program/CLI import boundary, preserve the separate initializer check, match the positive and negative TypeScript diagnostics, add serial/parallel Program and real CLI regressions, and pass the relevant full guarded suites. Do not treat the field as any, suppress diagnostics, or special-case this fixture.