docs: sharpen TECH-TS-PORTAL-TSC + TECH-APP-VITEST priority and scope

Both items currently sit at default priority. Foundation-tooling
commit 3 (ts-reset install) surfaced them but didn't constrain
when they need to close.

Adds explicit S3b-trigger rationale: launching the form-builder
organizer UI in apps/app on top of:
  - 22 unverified pre-existing TypeScript errors in apps/portal,
    AND
  - zero Vitest setup in apps/app
is asymmetric quality, exactly the discipline gap that bites in
post-launch debugging. Both items now flagged "high before S3b
lands" with concrete close-criteria.

TECH-TS-PORTAL-TSC additionally clarifies tiptap node_modules
handling. Phase A check confirmed `skipLibCheck: true` is already
set in both SPAs' single tsconfig.json (no `tsconfig.app.json` /
`tsconfig.node.json` variants exist). Despite that, the 4 tiptap
errors persist because tiptap ships uncompiled `.ts` source files
in `node_modules/.../@tiptap/core/src/`, not `.d.ts` — and
`skipLibCheck` only suppresses checking of `.d.ts` files. Real
fix paths are upstream `@tiptap/*` upgrade (newer majors may ship
`.d.ts` only) or a focused `exclude` glob; flipping skipLibCheck
is a non-fix because it is already on.

TECH-APP-VITEST adds a 6-step setup outline scoped to "harness
exists + one test passes", explicitly excluding comprehensive
test-writing for existing apps/app code. `useImpersonationStore.ts`
called out as a natural early target — it has no runtime test
today and the pending TECH-TS-IMPERSONATION shape-validation work
benefits from coverage.

CLAUDE.md quality-gates list adds a Vitest entry that surfaces
the apps/portal / apps/app asymmetry, with a pointer to
TECH-APP-VITEST.

No code changes. Documentation only.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-04-25 04:11:16 +02:00
parent f38c7ece97
commit e5d86776b2
2 changed files with 80 additions and 18 deletions

View File

@@ -987,27 +987,86 @@ tamperbaar door lokale users, dus dit is ook een kleine security
verbetering.
**Prioriteit:** Laag — defensive hardening, geen user-impact.
### TECH-TS-PORTAL-TSC — portal tsc --noEmit cleanup
### TECH-TS-PORTAL-TSC — `tsc --noEmit` baseline reduction (apps/portal)
**Aanleiding:** Portal heeft 22 pre-existing tsc errors (+4 in
tiptap node_modules) die niets met ts-reset te maken hebben — meest
TiptapEditor/ProductDescriptionEditor commands en één losse
`@iconify/types` missing, themeConfig type-lowercase issue. CI
checkt tsc niet (build + vitest wel), dus het wordt momenteel
genegeerd. Fix zodra tiptap upgrade beschikbaar komt of per-
component via type-casts.
**Prioriteit:** Laag — niet-blocking, bestaand probleem.
**Priority:** medium → **high before S3b organizer UI lands.**
**Scope:** 22 pre-existing TypeScript errors in `apps/portal/src/`
own code surfaced by foundation-tooling commit 3 (ts-reset install).
### TECH-APP-VITEST — bring Vitest coverage to apps/app
**Trigger to upgrade priority to "must-fix-now":** any S3b
form-builder organizer UI commit. Launching new TypeScript code on
top of an unverified existing-error baseline produces unactionable
compile output ("which errors are mine?"). Reduce to zero before
S3b starts.
**Aanleiding:** ts-reset install (april 2026) onderstreepte dat
`apps/app/` geen test-script of `tests/` directory heeft. Portal
heeft wel Vitest-coverage (113 tests); organizer-SPA heeft alleen
build + typecheck als geautomatiseerde gates.
**Wat:** Vitest setup in `apps/app/`, met eerste coverage op de
kern-stores (waaronder `useImpersonationStore.ts` dat nu zonder
runtime-test leeft).
**Prioriteit:** Middel.
**Triage approach (mirror Larastan reduction pattern):**
1. `cd apps/portal && pnpm exec vue-tsc --noEmit 2>&1 | grep "src/" > /tmp/tsc-errors.txt`
2. Group by error code (TS2339 property-not-found, TS2345 argument
type, TS18047 possibly null, TS2322 not-assignable, etc.) —
typical top categories on a Vue-3 + Pinia codebase. Foundation-
tooling triage already noted clusters in TiptapEditor/
ProductDescriptionEditor commands, a `@iconify/types` missing
import, and a themeConfig `Lowercase<string>` mismatch
3. Fix per-category in scoped commits (mirror Larastan reduction
sprints — one category per PR if >5 occurrences, combine if <=5)
4. Add `pnpm exec vue-tsc --noEmit` to a pre-commit hook or CI as
blocking gate once own-code errors hit zero (CI integration is
tracked separately; the gate enforcement is what closes the
"new code introduces no new errors" discipline gap)
**Tiptap upstream errors (4 in node_modules):**
`skipLibCheck: true` is **already set** in both SPAs' `tsconfig.json`
(only one tsconfig variant exists per SPA; no `tsconfig.app.json`
or `tsconfig.node.json` split). Despite that, the 4 errors persist
because **tiptap ships uncompiled `.ts` source files** in
`node_modules/.../@tiptap/core/src/`, not `.d.ts` declaration
files. `skipLibCheck` only suppresses checking of `.d.ts` files;
it does **not** apply to raw `.ts` files that vue-tsc pulls in
through the import graph. Real options, in order of preference:
(a) upgrade `@tiptap/*` to a release that ships only `.d.ts`
(check upstream — the policy may already have changed in newer
majors); (b) add a focused `exclude` glob for tiptap's
`node_modules/.../src/**/*.ts` if the upgrade is blocked. Avoid
blanket `node_modules` excludes — they can break import resolution
in vue-tsc.
**Out of scope:** runtime fixes for behaviors that surface as type
errors but aren't actually broken at runtime. If a fix requires
reasoning about runtime behavior (not just type narrowing), surface
it as a separate ticket — TypeScript-correctness is this sprint's
remit, runtime-correctness is a different concern.
### TECH-APP-VITEST — apps/app Vitest setup
**Priority:** medium → **high before S3b organizer UI lands.**
**Scope:** install Vitest + config + sample test in `apps/app/`.
Mirror `apps/portal/` setup. Add `test` script to package.json.
**Trigger to upgrade priority to "must-fix-now":** any S3b
form-builder organizer UI commit. apps/portal has 113 Vitest tests
as of foundation-tooling commit 0; apps/app has zero. Launching
new organizer UI uncovered while the portal SPA is well-tested is
asymmetric quality, exactly the discipline gap that bites during
post-launch debugging.
**Setup outline (1-2 hours, isolated commit):**
1. `cd apps/app && pnpm add -D vitest @vue/test-utils @testing-library/vue happy-dom`
2. Mirror `apps/portal/vitest.config.ts` adapted for apps/app paths
3. Mirror `apps/portal/tests/setup.ts` if relevant
4. Add `"test": "vitest"` and `"test:run": "vitest run"` to
`apps/app/package.json` scripts
5. Write one sample test against an existing apps/app component
(any simple Vue component with a clear input → output mapping —
confirm the harness works end-to-end). `useImpersonationStore.ts`
is a natural early target (no runtime test today; the
ts-reset-surfaced TECH-TS-IMPERSONATION runtime-validation work
would benefit from that coverage)
6. Foundation-tooling-style return deliverable: confirm
`pnpm test --run` exits 0 with at least one test passing
**Out of scope:** writing comprehensive tests for existing apps/app
code. This sprint sets up the harness; per-feature test coverage
follows organically as features land or are touched.
---