You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
src/app/features/studio/core/presentation/pages/studio-page/studio-page.component.ts line 75
Code
`subscription: Subscription
🔍 Evidence
NOT dead code — internal lifecycle management. Not referenced in the template but required.
⚠️ Confidence
NOT DEAD — do not remove
✅ Validated
N/A
Last updated: 2026-04-20 — Remove dead saveUser login flow
4. AppComponent — saveUser() + submitted signal (removed login flow)
📍 Source
src/app/app.component.ts lines 134-145 (saveUser), line 57 (submitted)
Code
saveUser() method referencing this.form, this.userService, this.userDialog — none of which existed on the component. submitted signal only used inside saveUser().
🔍 Evidence
Build errors (TS2339). Test at line 165 confirmed: "should not have userDialog or saveUser (login flow removed)". No references in template.
⚠️ Confidence
HIGH
Removal impact
Removed method, signal, and related dead tests (user dialog, email validation, saveUser calls).
Reason: loadForms.service.ts now imports recheckSpanLoads from @shared/domain/helpers/span-loads.helpers (the improved, immutable version). The local helpers.ts export is never imported anywhere. Note: emptySpanLoad from the same file IS still used by load-marking.component.ts.
Stale copy after migration to features/studio/field-measuring/presentation/components/field-measuring/. Missing .html and .scss template files. Not imported by any file.
⚠️ Confidence
HIGH
Removal impact
Delete file — the real component lives in features/
Stale copy after migration to features/studio/field-measuring/presentation/components/init/. Missing .html and .scss template files. Not imported by any file.
⚠️ Confidence
HIGH
Removal impact
Delete file — the real component lives in features/
import { ToolbarDialogService } and import { ToolbarDialogComponent } from @features/studio/toolbar/
🔍 Reason
ToolbarDialogService has hard dependencies on 5 studio-specific components (FieldMeasuringComponent, InitComponent, L0SumComponent, VhlAndGuyingComponent, LoadsTableComponent). Moving to core/ or shared/ would create core → features violations.
⚠️ Status
⏳ ACCEPTED DEBT — 2 violations remaining out of 71 original
Resolution
Requires decoupling ToolbarDialogService from concrete components via InjectionToken or a registry pattern.
Detected on
2026-03-16
10. jest.config.ts — root file
📍 Source
jest.config.ts (project root)
Code
Full Jest configuration file (JestConfigWithTsJest)
🔍 Evidence
Project uses Vitest as test runner (vitest.config.ts, npm run test → vitest run). Jest config is unused.
⚠️ Confidence
HIGH
Removal impact
Delete jest.config.ts and fileTransformer.js (Jest-specific transform)
Reason: No-op placeholder with no body. Called by CableLengthChangeComponent.deleteForm() but has no observable side effects. Component-level tests already verify the call sites; no meaningful unit test can be written for the service method itself until a real implementation is added.
| Code | Public loadObstacle(uuid) + private helpers patchFormFromObstacle and findObstacle |
| 🔍 Evidence | loadObstacle is never called from any component or service — only referenced in its own spec file. Its logic partially duplicates setExistingObstacle. The two private helpers are only reachable via loadObstacle. |
| ⚠️ Confidence | HIGH |
| Removal impact | Remove loadObstacle, patchFormFromObstacle, findSupportForObstacle, and findObstacle (~30 lines) and their spec coverage |
| Status | ⏳ PENDING REVIEW |
| Detected on | 2026-03-26 |
Exported function never called in production code. Only referenced in service-worker.spec.ts. Was part of V1 activate logic. In V2, the update check is driven by UpdateService.checkForUpdateOnce() which reads cache directly via getCurrentVersion().
⚠️ Confidence
HIGH
Removal impact
Remove ~5 lines + update spec to remove corresponding tests.
handleMessage() already sends install_complete to event.source after installApp() returns. The internal broadcast in installApp() caused duplicate messages to the triggering client.
⚠️ Confidence
HIGH
Removal impact
Removed ~8 lines of duplicate client notification from installApp(). handleMessage() is now the single source of client notification.
import { isEqual } from 'lodash' used for comparing two AppVersion objects (3 string fields)
🔍 Evidence
Deep equality via lodash is unnecessary for a flat object with 3 string properties. Replaced with a dedicated areVersionsEqual() method. Reduces bundle size by removing the lodash dependency from this service.
⚠️ Confidence
HIGH
Removal impact
Replaced with inline areVersionsEqual() — 3 string comparisons.
✅ Validated
🔧 REPLACED — 2026-04-02
21. isFirstUseOffline signal — core/services/auth/auth.service.ts
📍 Source
src/app/core/services/auth/auth.service.ts
Code
readonly isFirstUseOffline = signal(false);
🔍 Evidence
Signal defined in AuthService but never consumed by any component, template, or other service. Only referenced in auth.service.spec.ts. No UI ever reads this signal.
⚠️ Confidence
HIGH
Removal impact
Removed signal and simplified initialize() (no longer sets the flag on first-use offline). Simplified OIDC+PKCE auth simplification.
✅ Validated
🗑️ REMOVED — 2026-04-03
22. OidcClaims type alias — core/services/auth/auth.service.ts (CLEANUP)
Overly complex type-level gymnastics (Required<Pick<>>) for what is a simple flat interface with 5 fields. Replaced with a plain interface OidcClaims { email: string; sub?: string; ... } — clearer and self-contained.
⚠️ Confidence
HIGH
Removal impact
Replaced type alias with explicit interface — no behavioral change.
async function checkIfAppInstalled() — checks for app_version entry in cache
🔍 Evidence
Was previously exported, internalized in Phase 6 but kept "for testability". No runtime caller, no test references it. Dead code with no justification to keep.
⚠️ Confidence
HIGH
Removal impact
Removed function entirely. No callers affected.
✅ Validated
🗑️ REMOVED — 2026-04-03
24. noCacheHeaders function — core/services/worker_update/service-worker.ts (CLEANUP)
const noCacheHeaders = () => { ... } — arrow function recreating Headers object on every call
🔍 Evidence
Unnecessary allocation per fetch call. Replaced with immutable NO_CACHE_INIT constant — same semantics, zero overhead.
⚠️ Confidence
HIGH
Removal impact
Replaced with const NO_CACHE_INIT: RequestInit constant.
✅ Validated
🔧 REPLACED — 2026-04-03
25. export type { AppVersion } re-export — core/services/worker_update/worker_update.service.ts (CLEANUP)
📍 Source
src/app/core/services/worker_update/worker_update.service.ts line 8
Code
export type { AppVersion } from './service-worker.interfaces';
🔍 Evidence
AppVersion is only used internally within worker_update.service.ts (local type annotations). No other file in the codebase imports AppVersion from this service.
⚠️ Confidence
HIGH
Removal impact
Changed to a plain import type — no external consumers affected.
createUser() had no runtime callers (only in tests). user$ was consumed only by TopbarComponent, which now reads AuthService.currentUser signal directly. validateEmail was only used inside createUser. The ready$ subscription in the constructor was an unmanaged leak. AuthService is the canonical write path for the users table.
⚠️ Confidence
HIGH
Removal impact
Removed createUser, validateEmail, userSubject, user$, constructor subscription, and BehaviorSubject/Observable imports. UserService simplified to read-only getUser(). TopbarComponent now uses AuthService.currentUser signal.
✅ Validated
🗑️ REMOVED — 2026-04-03
27. mockCurrentVersion + mockLatestVersion dev constants — core/services/worker_update/worker_update.service.ts
const mockCurrentVersion and const mockLatestVersion used to initialize signals in isDevMode()
🔍 Evidence
Dev-only mock versions with hardcoded hashes (0000..., 1111...) always caused needUpdate=true in dev mode. This created confusing false-positive update prompts during development. Signals now start as null in all modes, consistent with production behavior.
⚠️ Confidence
HIGH
Removal impact
Removed both constants, removed isDevMode and environment imports. Signals initialized to null.
getUniqueSortedSupportNamesFromAttachments() and buildSupportNameFilterTables()
🔍 Evidence
Replaced by AttachmentService.distinctSupportNames$ which uses Dexie uniqueKeys() index-level query instead of loading all entities. No remaining consumers after refactor.
⚠️ Confidence
HIGH
Removal impact
Removed both functions + CatalogAttachment import. Perf improvement: ~3s → ~100ms for support name dropdown.
✅ Validated
🗑️ REMOVED — 2026-05-19
29. Legacy attachments flat-table API — AttachmentService + catAttachments
getAttachments() + allAttachments$ exposed by AttachmentService, along with the parseCsvAndStore + replaceTableData(catAttachments) pipeline. The mapAttachmentCsvToEntities helper (flat shape) is still exported temporarily for backward compatibility. The Dexie catAttachments table is removed in V6 (replaced by catSupportAttachments grouped by support_name). The CATALOG_ATTACHMENT_SCHEMA schema is now only referenced by the historical V1–V5 versions of AppDatabase.
🔍 Evidence
No external consumer references getAttachments()/allAttachments$ anymore after switching to streaming via Web Worker (attachment-import.worker.ts). The flat mapping is only used by legacy tests (compat helper). The Papa.parse complete + flat bulkAdd pipeline caused a ~278 MB memory peak for a 25 MB CSV.
⚠️ Confidence
MEDIUM (getAttachments/allAttachments$ ⇒ HIGH; full removal of the CATALOG_ATTACHMENT_SCHEMA symbol and of the catAttachments!: Table<...> declaration is not possible while V1–V5 versions remain in AppDatabase)
Removal impact
Remove getAttachments(), allAttachments$, and the mapAttachmentCsvToEntities helper (and its spec) after a release without regression. Keep CATALOG_ATTACHMENT_SCHEMA and the catAttachments declaration for the Dexie migration.
✅ Validated
⏳ PENDING — proposed on 2026-06-02
30. Legacy attachment-import.worker (attachment-only Web Worker)
Worker dedicated solely to attachments.csv (request/response types AttachmentImportWorkerRequest/AttachmentImportWorkerResponse, function runImport).
🔍 Evidence
Replaced by the generic pipeline src/app/shared/catalog/csv-import/ (engine + worker + client + 6 configs) that shares PapaParse + IndexedDB streaming across all 6 catalog CSVs. AttachmentService.importFromFile() now delegates to CsvImportClientService.importCsv('attachments'). No remaining consumers.
⚠️ Confidence
HIGH
Removal impact
3 files removed. Code shared across the 6 catalogs (cables/chains/lines/maintenance/obstacles/attachments).
3-column CSV (obstacle_type;obstacle_type_name;details) historically imported by ObstaclesService.importFromFile().
🔍 Evidence
Superseded by public/data/obstacle_configuration.json which carries the same 3 fields plus per-obstacle redZone/conformity, regulatory rules, conformity distances, wind zones and scalar config. The CSV file is no longer fetched by any worker config (obstacles.config.ts now points at obstacle_configuration.json).
⚠️ Confidence
HIGH
Removal impact
Delete the CSV file. The Python asset-hash script ignores extensions other than .csv/.json automatically.
✅ Validated
⏳ PENDING — proposed on 2026-06-05
32. ObstacleTypeCsvDto interface
📍 Source
src/app/infrastructure/dto/obstacle-type-csv.dto.ts, re-export in src/app/infrastructure/dto/index.ts line 14
Only consumed by the legacy CSV-based obstacles.config.ts and its spec file. After the JSON pivot, the obstacle import path uses ObstacleConfigurationJsonDto (co-located in configs/obstacles.config.interfaces.ts). The DTO and its re-export become orphan. The spec file obstacles.config.spec.ts is rewritten in Phase 5 to drop the import.
⚠️ Confidence
HIGH
Removal impact
Delete obstacle-type-csv.dto.ts and remove the re-export line in infrastructure/dto/index.ts.
✅ Validated
⏳ PENDING — proposed on 2026-06-05
33. applyObstacleOutputToLitData + obstacle rendering from registration tasks
applyObstacleOutputToLitData(obstacleOutput) — merged ObstacleOutput.obstacles into litData after addBulkObstacles/addSingleObstacle/syncObstacles calls
🔍 Evidence
Obstacle registration tasks (addBulkObstacles, addSingleObstacle, deleteObstacle, clearObstacles) now return undefined — they only register in the engine. Obstacle 3D rendering coordinates are obtained via refreshProjection instead.
⚠️ Confidence
HIGH
Removal impact
Already removed. ObstacleOutput interface kept for refreshProjection output.