# TASK-001 — pinned resolver versions
# Salak Spike 0. Recorded 2026-07-28. THROWAWAY WORKSPACE.
#
# Every Spike 0 measurement (TASK-003, TASK-004, TASK-005) must cite this file.
# A throughput or readiness figure taken against an unrecorded server version is
# not reproducible and must not be carried into TASK-006. (Risk K10.)

[language servers]              installed locally in spike/node_modules, exact-pinned
pyright                         1.1.411     provides bin `pyright-langserver`
typescript-language-server      5.3.0       wraps tsserver (decision D8)
typescript                      5.9.3       tsserver host — see CEILING note below

[host toolchain]
node                            v24.13.1
python                          3.11.15
uv                              0.11.28
git                             2.53.0.windows.2
os                              Windows 10 Home Single Language 10.0.19045

[TYPESCRIPT VERSION CEILING — finding of TASK-001]
`npm install typescript` resolves to 7.0.2 (dist-tag `latest`), and TypeScript 7
DOES NOT SHIP `lib/tsserver.js`. Verified directly: node_modules/typescript/lib/
contained only getExePath, tsc.js and version files. typescript-language-server
spawns tsserver, so the 5.3.0 + 7.0.2 pair is broken on arrival — it would have
failed at the first resolution request in TASK-004, several days into the spike.
Pinned to 5.9.3, the newest release still shipping tsserver.js. This also matches
the resolution target: jeruk-ai declares `typescript: ^5`.
6.0.x was not evaluated. If a later task wants to move up, re-run the
`ls node_modules/typescript/lib/tsserver.js` check first — that one command is the
whole compatibility test.

[SPAWN PATH — finding of TASK-001]
Both servers must be spawned as `node <entry.js> --stdio`, never through the
node_modules/.bin shim:
  pyright-langserver          node_modules/pyright/langserver.index.js
  typescript-language-server  node_modules/typescript-language-server/lib/cli.mjs
On Windows the shim is a .cmd and Node refuses to spawn it without shell:true
(EINVAL). shell:true is precisely what TASK-100 forbids in the real client, since
repository-controlled paths cross that boundary. Spawning the JS entry point keeps
the path shell-free on every platform, so this is the permanent shape, not a
Windows workaround.

[VERIFIED — launch-probe.mjs, exit 0]
pyright-langserver           PASS   alive after 2000ms in --stdio mode
typescript-language-server   PASS   alive after 2000ms in --stdio mode
Handshake and capability negotiation are NOT verified here — that is TASK-002.

[NOTE] `pyright-langserver --version` does not work: it is a pure LSP server and
exits demanding --stdio/--node-ipc/--socket. The version above comes from
`pyright --version` (same package, 1.1.411) and from package.json.

[TARGET REPOSITORIES]
jeruk-ai   310e48efe6e6f2868cc1a71cc9b7f37b1f10fc14  branch main  CLEAN
           <local checkout>/jeruk-ai   (absolute path stripped, G3)
           255 tracked .ts/.tsx, 0 .py   -> TypeScript target (TASK-004)
mangga-pa  16ac5c2ee25adf0f4fd09dfddbc7d35e57ce0251  branch main  21 DIRTY FILES
           <local checkout>/mangga-pa  (absolute path stripped, G3)
           57 tracked .py, 21 tracked .ts/.tsx  -> Python target (TASK-003)

[LIMITATION] mangga-pa has 21 uncommitted files, so its SHA does not fully
describe what gets scanned. The working tree was deliberately NOT modified — it is
the owner's active workspace. Any TASK-003 measurement must record the dirty count
alongside the SHA, or the owner must park the changes first. jeruk-ai is clean and
needs no such caveat.

[SCALE] Tracked source is far smaller than the on-disk file count (mangga-pa: 57
tracked .py against 5779 .py files on disk — .venv and friends). Sizing for
TASK-005 must be driven by tracked files, since .gitignore is honoured by default
(SDD 4.3). Note also that 57 files is a thin base for the "~200 Python symbols"
TASK-003 asks for; confirm symbol density before assuming the sample is reachable.
