Files
ng-eventually/.tasks/doing/T01.i-two-leftovers-from-the-removal.md
T

37 lines
2.9 KiB
Markdown

---
id: T01.i
title: Clear two mechanical leftovers from the removal
parent: T01
depends_on: [T01.h]
created: 2026-09-21
claimed_by: worker-agent
claimed_at: 2026-09-21
blocked: false
---
## Description
Two small, independent leftovers reported by T01.f. Neither carries a design question; if one turns out to, stop and report rather than deciding it here.
### 1. Remove `ensureReposOpen`, now dead
T01.f removed its last caller. VERIFY that with a grep across `packages/`, `examples/` and `e2e/` before deleting - if a caller survives, leave it and say so. `ensureRepoOpen` (SINGULAR) is NOT dead, it is on the live path, and must stay.
### 2. Make the example typecheck
`examples/notebook/tsconfig.json` fails typecheck. T01.f reports this as pre-existing and verified as such. The owner has asked for the example to be repaired.
**A strong lead on the cause, found by T01.h and VERIFIED independently: `examples/notebook` is outside pnpm entirely.** The root `package.json` `workspaces` field lists `packages/*` AND `examples/*`, but `pnpm-workspace.yaml` lists only `packages/*`. So pnpm never installs the example's dependencies, and that is the likely reason its single `error TS2345` stands. Check this FIRST. If adding `examples/*` to `pnpm-workspace.yaml` is the repair, make it and re-run the whole gate - bringing a package into the workspace can move resolutions for everyone, which is exactly the single-instance hazard this repo watches for, so verify no `@ng-org` package ends up duplicated.
Make it typecheck WITHOUT weakening the configuration. If the only way through is to loosen a compiler option, disable a check, or annotate a real type error away, STOP and report - that is a finding, not a repair. The example exists to be the honest demonstration of what an application writes, so an example that only compiles because the rules were relaxed for it is worse than one that does not compile.
### 3. Remove the dead bun store
`node_modules/.bun` is still on disk, holding OLD versions of `@ng-org/web`, `@ng-org/shex-orm` and `@ng-org/alien-deepsignals` beside the current ones. It is inert right now - T01.h re-installed with pnpm and every symlink resolves correctly - but a future `bun install` in this tree would re-point symlinks back into that stale store, which is the single-instance hazard arriving silently. Delete the directory, and if there is a cheap way to keep it from coming back (a note in the README's setup section, a package manager declaration), do the cheap thing and say what you did. Do NOT build tooling for it.
**Hard gate:** `bun test` -> 0 fail; `bunx tsc --noEmit -p packages/polyfill/tsconfig.json` -> exit 0; `bunx tsc --noEmit -p packages/polyfill/e2e/tsconfig.json` -> exit 0; the example's own typecheck -> exit 0; `python3 ~/.claude/skills/concept/lint.py` -> 0 ERROR. Anti-cheat: no `any`, no `@ts-ignore`, no `as unknown as`, no deleted or skipped test, no weakened assertion, no loosened compiler option.
## Progress
## Result