From ece3222d3a085e6a3ea4d06c3f425d28a46ac07a Mon Sep 17 00:00:00 2001 From: OC-5070 Date: Fri, 27 Mar 2026 20:02:36 -0700 Subject: [PATCH] Add AD1 session data, memory entries for datasheet pipeline and security incident - Imported AD1 Claude session files to clients/dataforth/session-logs/ - Created memory: project_datasheet_pipeline.md (full pipeline architecture) - Created memory: project_dataforth_incident_2026-03-27.md (security incident + MFA) - Updated MEMORY.md index - Updated session log with AD1 pipeline rebuild findings Co-Authored-By: Claude Opus 4.6 (1M context) --- .claude/memory/MEMORY.md | 2 + .../project_dataforth_incident_2026-03-27.md | 37 +++++++ .claude/memory/project_datasheet_pipeline.md | 73 +++++++++++++ ...-03-27-security-incident-mfa-datasheets.md | 23 +++- clients/dataforth/session-logs/MEMORY.md | 9 ++ .../dataforth/session-logs/SESSION-SUMMARY.md | 60 +++++++++++ .../session-logs/email-draft-morning.md | 98 +++++++++++++++++ .../session-logs/email-draft-updated.md | 102 ++++++++++++++++++ .../session-logs/feedback_sn_from_data.md | 11 ++ .../session-logs/project_ad2_context.md | 11 ++ .../session-logs/project_ctonwtxt_gap.md | 38 +++++++ .../project_engr_share_exploration.md | 83 ++++++++++++++ .../session-logs/project_new_product_lines.md | 37 +++++++ .../session-logs/project_pipeline_rebuilt.md | 47 ++++++++ .../project_test_datasheet_pipeline.md | 75 +++++++++++++ .../session-logs/reference_haubner_backup.md | 11 ++ .../session-logs/user_mike_swanson.md | 10 ++ 17 files changed, 723 insertions(+), 4 deletions(-) create mode 100644 .claude/memory/project_dataforth_incident_2026-03-27.md create mode 100644 .claude/memory/project_datasheet_pipeline.md create mode 100644 clients/dataforth/session-logs/MEMORY.md create mode 100644 clients/dataforth/session-logs/SESSION-SUMMARY.md create mode 100644 clients/dataforth/session-logs/email-draft-morning.md create mode 100644 clients/dataforth/session-logs/email-draft-updated.md create mode 100644 clients/dataforth/session-logs/feedback_sn_from_data.md create mode 100644 clients/dataforth/session-logs/project_ad2_context.md create mode 100644 clients/dataforth/session-logs/project_ctonwtxt_gap.md create mode 100644 clients/dataforth/session-logs/project_engr_share_exploration.md create mode 100644 clients/dataforth/session-logs/project_new_product_lines.md create mode 100644 clients/dataforth/session-logs/project_pipeline_rebuilt.md create mode 100644 clients/dataforth/session-logs/project_test_datasheet_pipeline.md create mode 100644 clients/dataforth/session-logs/reference_haubner_backup.md create mode 100644 clients/dataforth/session-logs/user_mike_swanson.md diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index 3a61fee..1e48742 100644 --- a/.claude/memory/MEMORY.md +++ b/.claude/memory/MEMORY.md @@ -21,3 +21,5 @@ - [Audio Processor Architecture](project_audio_processor_architecture.md) - Segment-first pipeline: detect breaks before transcription for complete content capture - [Neptune Email Routing Issues](project_email_routing_neptune.md) - Multiple clients (devcon, Sorensen/rieussetcorp) have email not routing properly from Neptune - [Neptune SBR Email Routing Setup](project_neptune_sbr_email_routing.md) - Full SBR routing chain, config file locations, MailProtector integration, access methods +- [Dataforth Test Datasheet Pipeline](project_datasheet_pipeline.md) - Full pipeline rebuilt 2026-03-27. Server-side generation replaces DFWDS/Uploader. Website upload still broken. +- [Dataforth Security Incident](project_dataforth_incident_2026-03-27.md) - DF-JOEL2 compromised, MFA deployed, IC3 filed. CA policies enforce April 4. diff --git a/.claude/memory/project_dataforth_incident_2026-03-27.md b/.claude/memory/project_dataforth_incident_2026-03-27.md new file mode 100644 index 0000000..1ccf0f0 --- /dev/null +++ b/.claude/memory/project_dataforth_incident_2026-03-27.md @@ -0,0 +1,37 @@ +--- +name: Dataforth Security Incident 2026-03-27 +description: DF-JOEL2 compromised via ScreenConnect social engineering. MFA deployed. IC3 filed. C2 IPs blocked. Full remediation completed. +type: project +--- + +## Incident +Joel Lohr's workstation (DF-JOEL2, 192.168.0.143) compromised via phishing email to personal Yahoo account. Attacker "Angel Raya" deployed ScreenConnect C2 backdoors. M365 account also compromised from Turkey/UK/Germany. + +## Attacker +- C2: 80.76.49.18 and 45.88.91.99 (AS399486, Virtuo, Montreal QC) - SUSPENDED by host +- Cloud relay: instance-wlb9ga-relay.screenconnect.com +- ConnectWise case: 03464184 +- IC3 complaint: 1c32ade367084be9acd548f23705736f + +## Remediation +- C2 IPs blocked at UDM firewall (iptables - need permanent rules in UniFi UI) +- 3 rogue ScreenConnect clients uninstalled +- jlohr AD password reset, M365 sessions revoked +- 32 machines scanned clean, 28 unreachable (offline) +- No lateral movement detected + +## MFA Rollout +- 3 CA policies deployed (report-only until April 4, 2026): + - Require MFA (skip from office IP 67.206.163.122) + - Block foreign sign-ins (US only, MFA-Travel-Bypass group for exceptions) + - Block legacy auth +- 19/38 users MFA-ready, 19 need to register +- MFA notice sent to all users, deadline April 4 + +## Joel Lohr +- Retiring March 31, 2026 +- Auto-reply directs contacts to Dan Center (dcenter@dataforth.com) +- Account should be disabled after retirement + +**Why:** Active security incident requiring immediate response. +**How to apply:** Monitor CA policies in report-only mode, enforce April 4. Check 28 offline machines when available. Add C2 IPs to permanent UDM block list. diff --git a/.claude/memory/project_datasheet_pipeline.md b/.claude/memory/project_datasheet_pipeline.md new file mode 100644 index 0000000..bf685af --- /dev/null +++ b/.claude/memory/project_datasheet_pipeline.md @@ -0,0 +1,73 @@ +--- +name: Dataforth Test Datasheet Pipeline - Rebuilt 2026-03-27 +description: Full pipeline from DOS test stations to website. New server-side generation replaces DFWDS/Uploader. 72/73 Quatronix datasheets generated. AD2 crypto wipe recovery. +type: project +--- + +## Background +AD2 (192.168.0.6) was wiped in a crypto/ransomware attack months ago. The test datasheet pipeline was broken. Customer Quatronix (China) blocking shipment of 328 modules (whittled to 54) without datasheets. + +## Pipeline (5 stages, rebuilt 2026-03-27) + +### Stage 1: DOS Test Stations (64 stations) +- QuickBASIC programs generate test data -> C:\STAGE on each DOS PC +- DAT files (raw test data) + TXT files (formatted datasheets) +- CTONW.BAT copies DAT files to NAS (working) +- CTONWTXT.BAT copies TXT files (NOT called in current AUTOEXEC v4.1 since 2026-03-12) +- TXT files piling up in C:\STAGE since Sept 2025 + +### Stage 2: NAS <-> AD2 Sync +- Script: C:\Shares\test\scripts\Sync-FromNAS-rsync.ps1 (every 15 min, WORKING) +- Rsync daemon on NAS: port 873, module "test", user rsync / IQ203s32119 +- PULL: DAT files from NAS -> AD2, triggers database import +- PUSH: Software updates from AD2 -> NAS for DOS machines + +### Stage 3: TestDataDB (Node.js/SQLite, WORKING) +- App: C:\Shares\testdatadb\ (Windows service "testdatadb", auto-start) +- API: http://192.168.0.6:3000 +- Database: C:\Shares\testdatadb\database\testdata.db (2.27M records) +- Import: database/import.js (post-import hook calls export) +- **NEW: Spec parser** (parsers/spec-reader.js) - reads binary spec DATs, 1470 models +- **NEW: Exact-match formatter** (templates/datasheet-exact.js) - reverse-engineered from QB +- **NEW: Auto-export** (database/export-datasheets.js) - generates TXT to X:\For_Web + +### Stage 4: WebShare (X: = \\ad2\webshare = C:\Shares\webshare) +- X:\Test_Datasheets - incoming (staging for old DFWDS) +- X:\For_Web - validated datasheets (501K+ files, pre-2026 archived to year subfolders) +- X:\For_Web_PDF - PDF versions (4.7K files) +- X:\Bad_Datasheets - invalid files (18K) +- X:\Datasheets_Log - DFWDS logs + +### Stage 5: Website Upload (BROKEN) +- Old endpoints: dataforth.com/Services/{Uploader,DirectoryManifest,DeleteFile}.aspx - ALL 404 +- Credentials: DataforthWebShare / Data6277 +- TestDataSheetUploader (VB.NET, Hoffman) - not running, config pointed to dev paths +- Legacy site: legacy.dataforth.com/TestDataReport_Print.aspx (still works, no auth) +- New site: dataforth.com/TestDataReport (requires OIDC login) + +## What Was Eliminated by Rebuild +- CTONWTXT.BAT (DOS TXT transfer) - no longer needed, server generates from DAT data +- DFWDS.exe (VB6 filename decoder) - no longer needed +- TestDataSheetUploader (VB.NET web uploader) - endpoints dead anyway + +## Key File Encoding +H-prefix decode: A=10, B=11, C=12, D=13, E=14, F=15, G=16, H=17, I=18, J=19 +Example: H8601-6.TXT -> serial 178601-6 +New pipeline extracts SN from DAT record data directly, not filenames. + +## Open Items +1. Website upload replacement (old ASP.NET endpoints dead) +2. 7B datasheet formatting (specs loaded, needs 7B-specific layout, ~830K records) +3. SCM5B49 spec file empty - need from John Lehman +4. Service permissions (runs as SYSTEM, causes SHM/WAL conflicts) +5. New product lines: MAQ20/PWRM (XLS), 10D (JSON, ~May 2026), DSCMHV + +## Key Contacts +- John Lehman (jlehman@dataforth.com) - Engineering, QB code, specs +- Peter Iliya (pIliya@dataforth.com) - Applications Engineer, manual datasheet retrieval +- Ken Hoffman - TestDataSheetUploader author (VB.NET), DFWDS author, unresponsive +- Georg Haubner (ghaubner@dataforth.com) - D: drive has pre-crypto backup of network shares +- Ginger (gy@quatronix-cn.com) - Quatronix China, customer requesting datasheets + +**Why:** Critical business issue - customer refusing shipments without datasheets. +**How to apply:** Pipeline is mostly rebuilt. Priority: website upload replacement, then 7B support. diff --git a/clients/dataforth/session-logs/2026-03-27-security-incident-mfa-datasheets.md b/clients/dataforth/session-logs/2026-03-27-security-incident-mfa-datasheets.md index aaa54ae..b8d8ff3 100644 --- a/clients/dataforth/session-logs/2026-03-27-security-incident-mfa-datasheets.md +++ b/clients/dataforth/session-logs/2026-03-27-security-incident-mfa-datasheets.md @@ -161,11 +161,26 @@ Of the missing Quatronix serials checked, **22 out of 22 that responded are IN t A=10, B=11, C=12, D=13, E=14, F=15, G=16, H=17, I=18, J=19 Example: H8601-6.TXT -> 178601-6.TXT +### AD1 Claude Instance Results (same day) +A Claude instance running on AD1/AD2 rebuilt the entire pipeline: +- **Spec Parser built** (parsers/spec-reader.js) - reads 8 binary spec DATs, 1470 models +- **Exact-match TXT formatter** (templates/datasheet-exact.js) - reverse-engineered from QB source +- **Auto-export system** (database/export-datasheets.js) - generates TXT to X:\For_Web after import +- **72 of 73 Quatronix datasheets generated** - in ComputerGuruConnectv2/Files/Quatronix-Datasheets.zip +- **1.4M records reconciled** with existing For_Web files, 500K archived to year subfolders +- **Root cause: CTONWTXT.BAT not called** in AUTOEXEC v4.1 since 2026-03-12. TXT piling up in C:\STAGE since Sept 2025. +- **New pipeline eliminates** CTONWTXT.BAT, DFWDS.exe, and TestDataSheetUploader +- **1 missing datasheet**: 177000-15 (SCM5B49-05) needs empty spec file from John Lehman +- **Website upload still broken**: old ASP.NET endpoints return 404, need replacement +- **7B series**: ~830K records need 7B-specific formatter (specs loaded but layout not implemented) +- All session files saved to clients/dataforth/session-logs/ (from ClaudeSession-2026-03-27.zip) + ### Next Steps for Datasheets -- Need to build export mechanism to generate TXT datasheets from database records -- TXT format matches the H8601-6.TXT sample (standard Dataforth test data sheet format) -- Files need to land in C:\Shares\webshare\Test_Datasheets on AD2 -- Then need mechanism to get them to the website (either fix TestDataSheetUploader or replace it) +- Website upload replacement (old endpoints dead, need new mechanism) +- Fix CTONWTXT.BAT in AUTOEXEC or accept server-side generation as sufficient +- 7B datasheet formatting +- SCM5B49 spec file from John +- New product lines: MAQ20/PWRM (XLS), 10D (JSON, ~May 2026) --- diff --git a/clients/dataforth/session-logs/MEMORY.md b/clients/dataforth/session-logs/MEMORY.md new file mode 100644 index 0000000..854c77a --- /dev/null +++ b/clients/dataforth/session-logs/MEMORY.md @@ -0,0 +1,9 @@ +- [AD2 crypto wipe context](project_ad2_context.md) — This machine is AD2, wiped due to crypto attack, many files missing +- [ENGR share exploration](project_engr_share_exploration.md) — Progress exploring \\AD1\Engineering\ENGR for test datasheet pipeline +- [Test datasheet pipeline map](project_test_datasheet_pipeline.md) — Full 5-stage pipeline: DOS stations -> NAS -> AD2 sync -> DFWDS -> web upload +- [Pipeline rebuilt 2026-03-27](project_pipeline_rebuilt.md) — New server-side pipeline replaces CTONWTXT/DFWDS/Uploader; 1470 model specs; exact-match TXT generation +- [CTONWTXT.BAT gap](project_ctonwtxt_gap.md) — Current AUTOEXEC doesn't call CTONWTXT.BAT; now bypassed by server-side generation +- [New product lines](project_new_product_lines.md) — MAQ20 (XLS), PWRM10 (XLS), 10D (JSON, ~May 2026), DSCMHV — different formats from legacy QB pipeline +- [Haubner machine backup](reference_haubner_backup.md) — D: drive on HGHAUBNER (192.168.0.148) has pre-crypto backups; firewall was blocking, fixed +- [SN from data not filenames](feedback_sn_from_data.md) — Always extract serial numbers from DAT record data, never from 8.3 encoded filenames +- [Mike Swanson - user profile](user_mike_swanson.md) — External IT consultant (azcomputerguru.com) managing Dataforth recovery; contacts: John Lehman, Peter Iliya diff --git a/clients/dataforth/session-logs/SESSION-SUMMARY.md b/clients/dataforth/session-logs/SESSION-SUMMARY.md new file mode 100644 index 0000000..0116583 --- /dev/null +++ b/clients/dataforth/session-logs/SESSION-SUMMARY.md @@ -0,0 +1,60 @@ +# Claude Session Summary — 2026-03-27 + +## Objective +Reconstruct the Dataforth test datasheet pipeline after AD2 crypto wipe. Unblock customer shipment (Quatronix/China, 73 datasheets needed urgently). + +## Key Accomplishments + +### Pipeline Analysis +- Mapped complete 5-stage pipeline: DOS test stations → NAS → AD2 sync → DFWDS → website +- Identified CTONWTXT.BAT gap (TXT files stuck on DOS machines since Sept 2025) +- Confirmed DFWDS.exe config lost in wipe, old website upload endpoints dead (404) +- Found production config + VB6 source on ENGR share + +### New Pipeline Built (C:\Shares\testdatadb\) +- **Spec Parser** (parsers/spec-reader.js): Reads 8 binary spec DAT files, 1470 models +- **Exact-Match Formatter** (templates/datasheet-exact.js): Reverse-engineered from QuickBASIC source +- **Export System** (database/export-datasheets.js): Auto-generates TXT to X:\For_Web after import +- **PDF On-Demand** (routes/api.js): /api/datasheet/:id/pdf endpoint +- **UI Improvements**: ALL filter, auto-search, PDF download button, export status display + +### Data Reconciliation +- 1,436,007 DB records matched to existing For_Web files and marked as exported +- 500,419 pre-2026 files archived into year subfolders (X:\For_Web\2013\, etc.) +- Added forweb_exported_at and datasheet_exported_at tracking columns + +### Customer Issue Resolved +- Generated 72 of 73 requested datasheets (TXT + PDF) for Quatronix +- Located on Desktop\Quatronix-Datasheets\ +- 1 remaining (177000-15, SCM5B49-05) needs empty spec file from John + +### Infrastructure Fixes +- Opened firewall on HGHAUBNER for SMB access +- Fixed TestDataDB search defaulting to today's date +- Identified testdatadb Windows service permission issues (SYSTEM vs sysadmin) + +## Files Created/Modified +See project_pipeline_rebuilt.md for full list. + +## Open Items +1. Website upload replacement (old ASP.NET endpoints dead) +2. 7B datasheet formatting (specs loaded, formatter needs 7B-specific layout) +3. SCM5B49 spec file empty — need from John +4. MAQ20/PWRM10 integration (XLS format, different pipeline) +5. 10D integration (JSON format, ~2 months out) +6. Service permissions cleanup (runs as SYSTEM) +7. Serial numbering standards discussion with John + +## Key Contacts +- John Lehman (jlehman@dataforth.com) — Engineering, QB code, specs +- Peter Iliya (pIliya@dataforth.com) — Applications Engineer, manual datasheet retrieval +- Ken Hoffman — TestDataSheetUploader author (VB.NET) +- Ginger (gy@quatronix-cn.com) — Quatronix China, customer requesting datasheets + +## Key Paths +- Test DB app: C:\Shares\testdatadb\ +- Spec data: C:\Shares\testdatadb\specdata\ +- For_Web: X:\For_Web\ (\ad2\webshare) +- ENGR share: \AD1\Engineering\ENGR\ATE\ +- NAS: 192.168.0.9 (D2TESTNAS, rsync daemon port 873) +- Sync script: C:\Shares\test\scripts\Sync-FromNAS-rsync.ps1 diff --git a/clients/dataforth/session-logs/email-draft-morning.md b/clients/dataforth/session-logs/email-draft-morning.md new file mode 100644 index 0000000..9ed4085 --- /dev/null +++ b/clients/dataforth/session-logs/email-draft-morning.md @@ -0,0 +1,98 @@ +Subject: RE: Test Datasheets to Website - Full Pipeline Analysis & Recovery Plan + +John, Ken, + +Following up on John's email - I've done a thorough trace of the entire test datasheet pipeline from the DOS test stations through to dataforth.com. Here's what I've found and what needs to be fixed. + +## Current Pipeline (5 Stages) + +### Stage 1 - QuickBASIC Test Programs (WORKING) +Test programs (e.g., TEST5B2E.BAS) write results two ways: +- LOGIT: binary .DAT files → C:\ATE\{5BLOG,8BLOG,...}\ +- DATASHEETWRITE: .TXT datasheets → C:\STAGE\ + +Filename encoding via GETDSFNAME: +- 5-digit WO#: {WO#}-{dash#}.TXT (e.g., 12345-1.TXT) +- 6-digit WO# (10xxxx-19xxxx): alpha-encoded (e.g., 123456 → C3456-1.TXT) +- Invalid WO#: BAD-{dash#}.TXT + +### Stage 2 - Network Transfer on Boot (BROKEN) +AUTOEXEC.BAT v4.1 (deployed 2026-03-12) calls: +1. STARTNET.BAT → maps T: = \\D2TESTNAS\test, X: = \\D2TESTNAS\datasheets +2. NWTOC.BAT → software updates (working) +3. CTONW.BAT → copies .DAT files to T:\TS-XX\LOGS\ (working) +4. menux → test menu (working) + +**PROBLEM: CTONWTXT.BAT is never called.** This is the batch file that copies C:\STAGE\*.txt to X: (the datasheets share). It exists on the machines (1,504 bytes, dated 03-12-26) but nothing invokes it. The old ARCHBAT.BAT called it, but ARCHBAT is not called in the current AUTOEXEC either. + +**Result: .TXT datasheets have been accumulating in C:\STAGE on the test stations since approximately September 2025.** Peter confirmed finding old files there. + +**Fix:** Add the following line to CTONW.BAT (or AUTOEXEC.BAT), after the existing .DAT transfer: + CALL C:\BAT\CTONWTXT.BAT %MACHINE% X: + +This can be deployed to all 64 stations via the existing NAS software push (Sync-FromNAS pushes updated ProdSW and BAT files to the NAS, and NWTOC pulls them to each station on boot). + +### Stage 3 - DFWDS.exe Processing (BROKEN) +DFWDS.exe (Dataforth Website Datasheet program, version 2015-06-08) processes files that arrive in X:\Test_Datasheets: +- Validates filenames and content +- Renames DOS-encoded filenames to serial number format +- Moves valid files → X:\For_Web (currently ~501,000 files) +- Moves invalid files → X:\Bad_Datasheets (~18,800 files) +- Logs to X:\Datasheets_Log + +**PROBLEM: The config file C:\DFWDS\DFWDS_NAMES.TXT was lost in the crypto wipe.** The exe is hardcoded to read from that path. The ENGR share has a copy of the exe and the config template at \\AD1\Engineering\ENGR\ATE\Test Datasheets\DFWDS\. We also don't have a scheduled task for it on AD2. + +DFWDS last ran successfully on 2026-03-11 (processed 978 files, 0 bad). Before that, there's a gap back to September 2025. The X:\Test_Datasheets folder currently has 338 files waiting to be processed. + +**Fix:** +1. Create C:\DFWDS\ on AD2 and restore DFWDS_NAMES.TXT with the correct paths +2. Copy DFWDS.exe from the ENGR share +3. Create a scheduled task to run it (daily? on a schedule that matches production?) + +**Question for John/Ken:** How often was DFWDS.exe previously run, and was it on a schedule or triggered manually? + +### Stage 4 - TestDataSheetUploader to Website (BROKEN) +Ken's VB.NET app (TestDataSheetUploader) syncs X:\For_Web to dataforth.com via three web services: +- Uploader.aspx - uploads new/changed files +- DirectoryManifest.aspx - gets server file list for comparison +- DeleteFile.aspx - removes obsolete files from server + +The app compares local files against the server manifest by filename, size, and last-write-time, and only uploads files modified in the current year. + +Source is on the ENGR share at: \\AD1\Engineering\ENGR\ATE\Test Datasheets\TestDataSheetUploader\ +Last built: November 2, 2022 + +**PROBLEM: Not deployed or scheduled on AD2. The app.config still has dev paths (C:\Users\hoffm\...) instead of production paths.** + +**Fix:** +1. Update app.config TestDataSheetPath to point to X:\For_Web +2. Deploy the built exe to AD2 +3. Create a scheduled task + +**Question for Ken:** What was the production config for TestDataSheetPath? Was it X:\For_Web or something else? Was this run on a schedule or manually? Are the web service credentials (DataforthWebShare) still valid? + +### Stage 5 - PDF Generation (UNKNOWN) +X:\For_Web_PDF contains ~4,773 PDF versions of datasheets. I haven't identified what generates these. + +**Question:** What creates the PDFs? Is this a separate process we need to restore? + +## What's Currently Working +- Test programs are generating data (files from today in X:\Test_Datasheets) +- NAS sync (Sync-FromNAS-rsync.ps1) runs every 15 min, pulling .DAT files and pushing software updates +- TestDataDB server is running on AD2 (port 3000), importing .DAT files +- X: drive (\\AD2\webshare) is accessible with all folders intact +- 501K+ historical datasheets in X:\For_Web are preserved + +## What's Broken (in pipeline order) +1. CTONWTXT.BAT not called → TXT files stuck on DOS machines +2. DFWDS.exe config missing → files in Test_Datasheets not processed +3. TestDataSheetUploader not deployed → files in For_Web not synced to website + +## Proposed Fix Order +1. Fix CTONW.BAT to call CTONWTXT.BAT → deploy via NAS push +2. Restore DFWDS on AD2 (config + exe + scheduled task) +3. Deploy TestDataSheetUploader with production config + scheduled task + +Let me know your thoughts and answers to the questions above so we can start restoring this. + +Mike diff --git a/clients/dataforth/session-logs/email-draft-updated.md b/clients/dataforth/session-logs/email-draft-updated.md new file mode 100644 index 0000000..8a9475c --- /dev/null +++ b/clients/dataforth/session-logs/email-draft-updated.md @@ -0,0 +1,102 @@ +Subject: Test Datasheets to Website - Pipeline Rebuilt, Status Update & Open Questions + +John, Ken, + +Following up on John's email from this morning — I've completed a full analysis and rebuild of the test datasheet pipeline. Here's where things stand. + +## What We Found + +### The Complete Original Pipeline (5 stages) +1. QuickBASIC test programs write .TXT datasheets to C:\STAGE on each DOS machine +2. CTONWTXT.BAT copies C:\STAGE\*.txt to X:\Test_Datasheets on boot +3. DFWDS.exe validates/renames files, moves valid ones to X:\For_Web +4. TestDataSheetUploader syncs X:\For_Web to dataforth.com via HTTP web services +5. Website serves datasheets at dataforth.com/TestDataReport + +### What Was Broken +- **CTONWTXT.BAT** is never called in the current AUTOEXEC.BAT v4.1 (deployed 2026-03-12). ARCHBAT.BAT isn't called either. TXT datasheets have been accumulating in C:\STAGE on test stations since ~Sept 2025. +- **DFWDS.exe** config (C:\DFWDS\DFWDS_NAMES.TXT) was lost in the crypto wipe. No scheduled task. We found the production config and VB6 source on the ENGR share at \\AD1\Engineering\ENGR\ATE\Test Datasheets\DFWDS\Program\. +- **TestDataSheetUploader** was not deployed/scheduled on AD2. The app.config still had dev paths. +- **Website upload endpoints** (dataforth.com/Services/Uploader.aspx, DirectoryManifest.aspx, DeleteFile.aspx) all return 404. These old ASP.NET services no longer exist on the current website. + +## What We Rebuilt (New Approach) + +Rather than restoring the old DFWDS + TestDataSheetUploader chain, we built a new pipeline that generates datasheets directly from the DAT file data that's already being imported into the test database. This eliminates the need for CTONWTXT.BAT, DFWDS.exe, and the old VB.NET uploader entirely. + +### New Pipeline +1. Sync-FromNAS pulls .DAT files from the NAS every 15 minutes (already working) +2. import.js parses DAT files into the database (already working) +3. **NEW: After import, the system automatically generates exact-match TXT datasheets and writes them to X:\For_Web** + +### What Was Built (all integrated into the TestDataDB app on AD2) + +**Spec Parser (parsers/spec-reader.js)** +- Reads the QuickBASIC binary spec files (5BMAIN.DAT, 8BMAIN.DAT, DSCOUT.DAT, SCTMAIN.DAT) +- Decodes all 4 product family TYPE structures (SCM5B, 8B, DSCA, DSCT) +- 751 model specifications loaded and available for lookup + +**Exact-Match Datasheet Formatter (templates/datasheet-exact.js)** +- Reverse-engineered from the QuickBASIC DATASHEETWRITE subroutine source code +- Produces TXT output identical to the original format: header, accuracy test table, final test results with spec limits, footer with checklist, NIST certification +- Handles all 4 product families with correct column headers per sensor type (Vin, Temp, Iin, Rin), conditional parameters, and family-specific footers +- Spec limits displayed using the same TSPECS logic as the original QuickBASIC code + +**Export System (database/export-datasheets.js)** +- Generates {serial_number}.TXT files in X:\For_Web +- Tracks export status via datasheet_exported_at field in the database (prevents duplicates) +- Can run standalone for batch export or automatically after each import +- Integrated into import.js as a post-import hook + +**On-Demand PDF Generation** +- Added /api/datasheet/:id/pdf endpoint to the web app +- Users can download a PDF of any test record from the database UI +- Uses the exact-match formatter so PDFs match the original TXT layout + +**Database/UI Improvements** +- Added datasheet_exported_at column for tracking export status +- Search now defaults to showing all records (was previously empty on load) +- Added "ALL" quick filter button +- Added "DOWNLOAD PDF" button in the record detail view + +### Data Reconciliation +- Cross-referenced 2.27M database records against the 501K existing files in X:\For_Web +- 1,436,006 records matched existing files and were marked as already exported +- ~830K records remain unexported (many are 7B series which we don't have spec files for yet) + +### For_Web Archive +- X:\For_Web had 501K files, making directory scans very slow +- Archiving pre-2026 files into year subfolders (X:\For_Web\2013\, X:\For_Web\2014\, etc.) +- This reduces the active folder from 501K to ~1,058 current-year files +- Archived files remain accessible but won't interfere with the upload process + +## What Still Needs To Be Done + +### 1. Website Upload Replacement (NEEDS INPUT) +The old TestDataSheetUploader's web service endpoints (Uploader.aspx, DirectoryManifest.aspx, DeleteFile.aspx) are all dead — they return 404 on the current dataforth.com website. + +**Questions for Ken:** +- When did the website change? Was the uploader working before the crypto attack? +- What does the current website use for test data lookup? The legacy site (legacy.dataforth.com/TestDataReport_Print.aspx) still works without authentication. The new site (dataforth.com/TestDataReport) requires OIDC login. +- Do we need to build a new upload mechanism, or does the website team need to provide new endpoints? +- Are the old credentials (DataforthWebShare / Data6277) still valid for anything? + +### 2. CTONWTXT.BAT Fix on DOS Machines (NEEDS INPUT from John) +The current AUTOEXEC.BAT calls CTONW.BAT (DAT files only) but not CTONWTXT.BAT (TXT datasheets). Peter confirmed TXT files piling up in C:\STAGE since Sept 2025. + +**However**, with the new pipeline, we may not need CTONWTXT.BAT at all — the datasheets are now generated from DAT data on the server side. The TXT files in C:\STAGE are redundant. + +**Question for John:** Should we still fix CTONWTXT.BAT for redundancy/local backup purposes, or is the server-side generation sufficient? If we do fix it, the change is simple: add `CALL C:\BAT\CTONWTXT.BAT %MACHINE% X:` to CTONW.BAT and deploy via the NAS push. + +### 3. SCM7B Spec File (OPTIONAL) +We have spec files for SCM5B, 8B, DSCA, and DSCT. The 7B series (~830K records) can't generate datasheets without a 7BMAIN.DAT or equivalent. + +**Question for John:** Is there a 7B spec DAT file on the ENGR share? Where are the 7B test programs located? + +### 4. TestDataDB Service Permissions +The Windows service (testdatadb) runs as SYSTEM, which creates file permission conflicts with maintenance operations. We should either: +- Change the service to run as INTRANET\sysadmin +- Or set proper inherited permissions on the testdatadb directory + +Let me know your thoughts on the open questions, especially the website upload situation. + +Mike diff --git a/clients/dataforth/session-logs/feedback_sn_from_data.md b/clients/dataforth/session-logs/feedback_sn_from_data.md new file mode 100644 index 0000000..34ef1a2 --- /dev/null +++ b/clients/dataforth/session-logs/feedback_sn_from_data.md @@ -0,0 +1,11 @@ +--- +name: Serial numbers from DAT data, not filenames +description: Design decision - always extract real serial numbers from DAT record data, never rely on 8.3 encoded filenames. Discussed with John Lehman 2026-03-27. +type: feedback +--- + +Always pull serial numbers from the DAT record data (e.g., "178439-1","02-09-2026"), not from filenames. DOS machines use 8.3 filename encoding (GETDSFNAME compresses 6-digit WOs via A-J prefix), but that's irrelevant to the server-side pipeline. + +**Why:** DOS 8.3 filenames are lossy encodings of the real SN. The old DFWDS.exe existed solely to reverse this encoding. By reading the SN from the data, we eliminate the rename step entirely and decouple the pipeline from DOS filesystem limitations. + +**How to apply:** Any new import/export code should use `serial_number` from the parsed record, never derive SNs from filenames. This applies to all product families including future ones. diff --git a/clients/dataforth/session-logs/project_ad2_context.md b/clients/dataforth/session-logs/project_ad2_context.md new file mode 100644 index 0000000..837fdab --- /dev/null +++ b/clients/dataforth/session-logs/project_ad2_context.md @@ -0,0 +1,11 @@ +--- +name: AD2 crypto wipe context +description: This machine is AD2 (not AD1), wiped months ago due to crypto attack. Many files may be missing. Investigation is about reconstructing test datasheet pipeline from surviving files. +type: project +--- + +This machine (192.168.0.6) is AD2, which was wiped several months ago due to a cryptocurrency/ransomware attack. Some files are completely missing. + +**Why:** Need to reconstruct understanding of the test datasheet data path from whatever surviving files and context clues remain, particularly on the \\AD1\ENGR share. + +**How to apply:** Don't assume files exist locally on AD2. Look at \\AD1\ENGR\ and other network shares for clues. Be thorough in searching since evidence may be scattered. diff --git a/clients/dataforth/session-logs/project_ctonwtxt_gap.md b/clients/dataforth/session-logs/project_ctonwtxt_gap.md new file mode 100644 index 0000000..2b203d0 --- /dev/null +++ b/clients/dataforth/session-logs/project_ctonwtxt_gap.md @@ -0,0 +1,38 @@ +--- +name: CTONWTXT.BAT not called in current AUTOEXEC +description: Current AUTOEXEC.BAT v4.1 on DOS test stations calls CTONW.BAT (DAT files only) but NOT CTONWTXT.BAT (TXT datasheets). TXT files piling up in C:\STAGE on DOS machines. +type: project +--- + +## The Gap (confirmed 2026-03-27 via John Lehman email) + +Current AUTOEXEC.BAT v4.1 (deployed 2026-03-12) boot sequence on DOS test stations: +1. STARTNET.BAT — maps T: = \\D2TESTNAS\test, X: = \\D2TESTNAS\datasheets +2. NWTOC.BAT — checks for software updates from network +3. CTONW.BAT — uploads .DAT log files to T:\TS-XX\LOGS\ (only .DAT, NOT .TXT) +4. menux — launches the test menu system + +Missing: CTONWTXT.BAT (copies C:\STAGE\*.txt to X: drive) is NOT called. +ARCHBAT.BAT (which called NWtoC, CtoNW, AND CtoNWtxt) is also NOT called. +John Lehman is still investigating where/if ARCHBAT was previously called. + +Peter Iliya found many .TXT files in C:\STAGE dating back to Sept 2025 on test machines. + +## CTONWTXT.BAT Logic (from email screenshots) +- Checks if C:\STAGE\*.txt exists +- Verifies network via %2\serve.sys +- copy C:\STAGE\*.txt %2 (X: drive = \\D2TESTNAS\datasheets\Test_Datasheets) +- DEL C:\STAGE\*.txt +- Logs to C:\ATE\CtoNWtxt.log + +## Fix Options +1. Add `CALL C:\BAT\CTONWTXT.BAT %MACHINE% X:` to AUTOEXEC.BAT (or to CTONW.BAT) +2. Or integrate TXT transfer into the existing CTONW.BAT + +## Filename Encoding (from John's email) +- 5-digit WO#: {WO#}-{dash#}.TXT (e.g., 12345-1.TXT) +- 6-digit WO# (10xxxx-19xxxx): first 2 digits encoded A-J, then 4 digits + dash# (e.g., 123456 -> C3456-1.TXT) +- Invalid WO#s get filename "BAD-{dash#}.TXT" with search name "BAD" + +**Why:** This is why X:\Test_Datasheets has a backlog and DFWDS hasn't been processing new files. +**How to apply:** Need to fix CTONW.BAT or AUTOEXEC.BAT to include TXT transfer, then deploy to all 64 stations. diff --git a/clients/dataforth/session-logs/project_engr_share_exploration.md b/clients/dataforth/session-logs/project_engr_share_exploration.md new file mode 100644 index 0000000..bbb9a95 --- /dev/null +++ b/clients/dataforth/session-logs/project_engr_share_exploration.md @@ -0,0 +1,83 @@ +--- +name: ENGR share exploration progress +description: Progress exploring \\AD1\Engineering\ENGR for test datasheet pipeline clues. Key directories identified, ATE/Test Datasheets found. +type: project +--- + +## Share Access +- Share name is `Engineering` (not `ENGR`): `\\AD1\Engineering\ENGR\` +- Access via bash: `//ad1/Engineering/ENGR/` +- AD1 IP: 192.168.0.27 + +## AD1 Shares (from Get-SmbShare) +- Engineering -> C:\Engineering +- ITSvc -> C:\Shares\ITSvc +- Plus default admin shares (ADMIN$, C$, IPC$, NETLOGON, SYSVOL) + +## Current Network Mappings on AD2 +- B: -> \\ad1\itsvc +- Q: -> \\ad2\c-drive +- S: -> \\SAGE-SQL\sage +- T: -> \\ad2\e-drive +- W: -> \\files-d1\sales +- X: -> \\ad2\webshare +- Y: -> \\files-d1\archive + +## ENGR Top-Level Structure +``` +ATE/ <-- Automated Test Equipment - KEY AREA +Custom Products/ +DESIGN/ +LABEL/ +MTBF Calculations/ +Project Reports/ +Software/ +Staff Directories/ +Test Equipment/ +``` + +## ATE Folder Contents (MOST RELEVANT) +``` +0 D2TESTNAS, 8B, 8B isoLynx SLX300, 8BGangTester, 8BPWR, +8Bdatabase-changes, ADDR, ATE Networking, All_Model_Specs, +Application Notes, BACKPANEL TEST FIXTURE PROJECT, Book4.xls, +CM-3-101, DSCA, DSCP, DSCT, FLUKE 8845A development, +File Utilities, Fluke Calibration Management, +High Voltage Input Module Test, KEPCO ABC software, LDM, MENU, +MS-DOS 6.22, Perforce-Extracted Files-5B&8B isL, Polynomials, +Print, ProdSW, Python, QB45, RML, RMSIN, SCM5B, SCM5B isoLynx, +SCM5B_Gang_Tester, SCM7B, SCM7B_Gang_Tester, SCMD, SCMVAS_SCMHVAS, +TESTLOGS, TPR List, **Test Datasheets**, Test Equipment, +Tester Notebooks, Toshiba (7-day burn-in), Trouble Shooting, +Troubleshooting Tools +``` + +**KEY FIND: `ATE/Test Datasheets/` exists — not yet explored.** + +Also notable in ATE: +- `QB45/` — QuickBASIC 4.5 source likely here +- `D2TESTNAS/` — config/docs for the NAS +- `MS-DOS 6.22/` — DOS setup files +- `TESTLOGS/` — test log output +- `ProdSW/` — production software +- `MENU/` — likely the DOS menu system +- Various product family folders (8B, SCM5B, SCM7B, DSCA, DSCT, etc.) + +## Software Folder Contents +Mostly installer/tool archives. Notable: QB64, ReDAQ, FieldTalk, Modbus Poll, Visual Studio 2008 + +## DESIGN Folder Contents +Product design folders by family. Notable: `Test Equipment Design/` subfolder. + +## Next Steps +1. **Explore ATE/Test Datasheets/** — this is the primary target +2. Explore ATE/QB45/ — QuickBASIC source that runs on DOS machines +3. Explore ATE/TESTLOGS/ — test output logs +4. Explore ATE/ProdSW/ — production software +5. Explore ATE/D2TESTNAS/ — NAS configuration +6. Explore ATE/MENU/ — DOS menu system +7. Look for any upload/sync scripts or scheduled task configs + +**Why:** Reconstructing test datasheet pipeline from context clues since AD2 was wiped. + +**How to apply:** Continue systematic exploration of \\AD1\Engineering\ENGR\ATE\ subtree, prioritizing Test Datasheets, QB45, TESTLOGS, and any sync/upload related files. diff --git a/clients/dataforth/session-logs/project_new_product_lines.md b/clients/dataforth/session-logs/project_new_product_lines.md new file mode 100644 index 0000000..ee5266e --- /dev/null +++ b/clients/dataforth/session-logs/project_new_product_lines.md @@ -0,0 +1,37 @@ +--- +name: New product line datasheet formats (MAQ20, PWRM, 10D, DSCMHV) +description: MAQ20/PWRM use XLS multi-sheet format, 10D will use JSON. Different paths and naming conventions from legacy QuickBASIC pipeline. Details from John Lehman 2026-03-27. +type: project +--- + +## MAQ20 Product Line +- Location: T:\ENGR\DESIGN\MAQ20 Design\Test Data (T: = old ENGR share) +- **Needs to move** from T: to K: (TEST share), then update programs to save to K: +- Format: .xls with multiple sheets: + - Sheet 1: list of test steps used by test program + - Sheet 2: test results + - Some have customer-ready datasheet on another tab + - Some have .pdfs +- First pass AND final pass data saved regardless of pass/fail +- Uses naming standard implemented ~2021 + +## PWRM10 (Energy Measurement Module) +- Location: U:\DESIGN\PWRM10 Energy Measurement Module\Test Data\Final Pass Test +- Format: .xls with numerical data + semi customer-ready datasheet on another tab +- First pass AND final pass data saved regardless of pass/fail + +## 10D (Not yet released — ~2 months out as of 2026-03-27) +- Location: K:\10D\first_pass and K:\10D\second_pass\pass +- Data segregated by directory: first/second pass, pass/fail subdirectories +- Will use **JSON format** per John's earlier email + +## DSCMHV +- New product line, uses same naming standard as MAQ20/PWRM/10D + +## Standards Discussion +- User (Mike) and John discussing better serial numbering that encodes more product detail +- Current convention: sequential S/N can be all different products (confusing) +- Naming standard from ~2021 used for MAQ20+ lines but could be improved + +**Why:** These are the next product lines to integrate after the legacy QB pipeline is restored. +**How to apply:** The current TXT pipeline (spec-reader + exact formatter) won't work for these. Need XLS parser for MAQ20/PWRM, JSON parser for 10D. John says customer-ready datasheets need improvement for all three. diff --git a/clients/dataforth/session-logs/project_pipeline_rebuilt.md b/clients/dataforth/session-logs/project_pipeline_rebuilt.md new file mode 100644 index 0000000..7ab6126 --- /dev/null +++ b/clients/dataforth/session-logs/project_pipeline_rebuilt.md @@ -0,0 +1,47 @@ +--- +name: Test datasheet pipeline rebuilt 2026-03-27 +description: New server-side pipeline replaces CTONWTXT/DFWDS/TestDataSheetUploader. Generates exact-match TXT from DAT imports. 1470 model specs loaded. +type: project +--- + +## What Was Built (2026-03-27) + +All files in C:\Shares\testdatadb\: + +### New Files +- `parsers/spec-reader.js` — Reads 8 binary spec DAT files, 1470 models across 6 families (SCM5B, 8B, DSCA, DSCT, SCM7B, plus sub-families 5B45, 5B48) +- `templates/datasheet-exact.js` — Exact-match TXT formatter reverse-engineered from QuickBASIC DATASHEETWRITE +- `database/export-datasheets.js` — Standalone/library export script, writes {SN}.TXT to X:\For_Web +- `database/archive-for-web.js` — Archives old For_Web files into year subfolders +- `database/generate-customer-pdfs.js` — One-off script for Quatronix customer order (72/73 generated) +- `specdata/` — Binary spec DAT files (5BMAIN, 8BMAIN, DSCOUT, SCTMAIN, DSCMAIN4, 7BMAIN, 5B45DATA, DB5B48) + +### Modified Files +- `database/import.js` — Post-import hook calls export-datasheets after incremental imports +- `database/schema.sql` — Added datasheet_exported_at and forweb_exported_at columns +- `routes/api.js` — Added /api/datasheet/:id/pdf endpoint (pdfkit) +- `public/index.html` — Added ALL filter, auto-search on load, PDF download button, export status in detail view +- `package.json` — Added pdfkit dependency + +### Database Changes +- `datasheet_exported_at` — When TXT was generated +- `forweb_exported_at` — When file was confirmed in X:\For_Web +- 1,436,007 records pre-marked as exported (matched existing For_Web files) + +### Pipeline Flow +DAT file arrives via NAS sync → import.js parses to DB → export-datasheets generates {SN}.TXT → X:\For_Web + +### What's Eliminated +- CTONWTXT.BAT (DOS-side TXT transfer) — no longer needed +- DFWDS.exe (filename decoder/validator) — no longer needed +- TestDataSheetUploader (VB.NET web uploader) — endpoints are 404, needs replacement + +### Remaining Gaps +- Website upload: old ASP.NET endpoints dead (404), need new upload mechanism +- SCM5B49 spec file empty (0 bytes) — need John's help +- 7B datasheet formatting not yet added to datasheet-exact.js (7B has 30+ unique parameters) +- Service runs as SYSTEM causing permission issues with SHM/WAL files +- 500K files archived into year subfolders in X:\For_Web + +**Why:** Rebuilt to recover from crypto wipe and unblock customer shipments (Quatronix/China blocking on missing datasheets). +**How to apply:** For new test data, the pipeline is automatic via Sync-FromNAS. For the 830K backlog of unexported records, run `node database/export-datasheets.js --limit N`. diff --git a/clients/dataforth/session-logs/project_test_datasheet_pipeline.md b/clients/dataforth/session-logs/project_test_datasheet_pipeline.md new file mode 100644 index 0000000..c605404 --- /dev/null +++ b/clients/dataforth/session-logs/project_test_datasheet_pipeline.md @@ -0,0 +1,75 @@ +--- +name: Test datasheet pipeline map +description: Full pipeline from DOS test stations through NAS sync, DFWDS processing, to web upload at dataforth.com. Includes current status of each stage. +type: project +--- + +## Complete Pipeline (5 stages) + +### Stage 1: Test Stations (QuickBASIC on DOS) +- 64 test stations (TS-1 through TS-30, plus L/R variants, TS-GURU, TS-TOM) +- QuickBASIC programs generate test data -> local C:\STAGE on each DOS PC +- Data flows to D2TESTNAS (NAS at 192.168.0.9, rsync daemon port 873, module "test" -> /data/test) + +### Stage 2: NAS <-> AD2 Sync (Sync-FromNAS-rsync.ps1) +- Runs every 15 min via scheduled task on AD2 +- PULL: .DAT files + .TXT reports from NAS -> C:\Shares\test\TS-XX\LOGS\\ and \Reports\ +- Imports .DAT files into TestDataDB via C:\Shares\testdatadb\database\import.js +- PUSH: Software updates (ProdSW, UPDATE.BAT, DEPLOY.BAT) from AD2 -> NAS for DOS machines +- Log types: 5BLOG, 7BLOG, 8BLOG, DSCLOG, SCTLOG, VASLOG, PWRLOG, HVLOG +- Script: C:\Shares\test\scripts\Sync-FromNAS-rsync.ps1 +- Log: C:\Shares\test\scripts\sync-from-nas.log (rotated at 10MB, 5 archives) + +### Stage 3: DFWDS.exe (Dataforth Website Datasheet program, v2015) +- Source exe: \\AD1\Engineering\ENGR\ATE\Test Datasheets\DFWDS\DFWDS.exe +- Config: C:\DFWDS\DFWDS_NAMES.TXT (hardcoded path in exe) +- Reads X:\Test_Datasheets (X: = \\ad2\webshare) +- Validates files, renames DOS-encoded filenames to serial number format +- Valid -> X:\For_Web (~501K files), Invalid -> X:\Bad_Datasheets (~18K files) +- Logs -> X:\Datasheets_Log (daily logs since 2014) +- Operations: COUNT, LISTALL, LISTBAD, LISTRENAME, INPLACE, WEBMOVE + +### Stage 4: TestDataSheetUploader (VB.NET, .NET 4.7.2) +- Source: \\AD1\Engineering\ENGR\ATE\Test Datasheets\TestDataSheetUploader\ +- Syncs files to www.dataforth.com via 3 HTTP services: + - Uploader.aspx, DirectoryManifest.aspx, DeleteFile.aspx +- Credentials: DataforthWebShare / Data6277 +- Only uploads files modified in current year +- Compares local vs server manifest (filename, size, last-write-time) +- Deletes server files that no longer exist locally +- Author: "hoffm" (Hoffman) + +### Stage 5: PDF generation +- X:\For_Web_PDF has ~4,773 PDFs (separate process, origin unclear) + +## X: Drive Layout (\\ad2\webshare) +- X:\Test_Datasheets — incoming datasheets (staging for DFWDS) +- X:\For_Web — validated/renamed datasheets (501K+ files) +- X:\For_Web_PDF — PDF versions (4.7K files) +- X:\Bad_Datasheets — invalid files (18K files) +- X:\Datasheets_Log — DFWDS operation logs + +## Datasheet Format +- Plain text, ~50 lines +- Header: Dataforth Corporation address/phone +- Fields: Date, Model (e.g. SCM5B41-03), SN (e.g. 178439-1) +- Accuracy test table (Vin, Calculated Vout, Measured Vout, Error%, Status) +- Final test results (Supply Current, Output Resistance, Linearity, Accuracy, etc.) +- Filename format: {SN}.txt (e.g. 178439-1.txt) + +## TestDataDB +- Node.js/SQLite app at C:\Shares\testdatadb\ +- PM2-managed via start-server.bat +- Scheduled task "TestDataDB Server" runs at system startup (currently DISABLED) +- Provides web UI and API for querying test data +- Import script: C:\Shares\testdatadb\database\import.js + +## Known Gaps (as of 2026-03-27) +1. MISSING LINK: How do .TXT reports get from C:\Shares\test\TS-XX\Reports\ to X:\Test_Datasheets? May need to build this. Clues may exist in Engineering share. +2. DFWDS config (C:\DFWDS\DFWDS_NAMES.TXT) missing — wiped in crypto attack. Check Haubner machine D: drive for backup of visible shares. +3. TestDataSheetUploader not deployed/scheduled on AD2 — needs production config +4. TestDataDB Server task disabled — should be operational + +**Why:** Reconstructing this pipeline after AD2 crypto wipe. Manufacturing is actively producing test data (files arriving daily) but downstream processing (DFWDS, web upload) is broken. + +**How to apply:** Priority is restoring the full pipeline end-to-end. Check Haubner D: for DFWDS config backup. Look in ENGR share for clues about the Reports->Test_Datasheets transfer mechanism. diff --git a/clients/dataforth/session-logs/reference_haubner_backup.md b/clients/dataforth/session-logs/reference_haubner_backup.md new file mode 100644 index 0000000..8e73e50 --- /dev/null +++ b/clients/dataforth/session-logs/reference_haubner_backup.md @@ -0,0 +1,11 @@ +--- +name: Haubner machine backup location +description: D: drive on Haubner's machine has backup of all visible network shares from before the crypto attack. Key resource for recovering lost configs. +type: reference +--- + +Haubner's machine D: drive contains a backup of all visible network shares from before the crypto attack on AD2. + +**Why:** AD2 was wiped; configs like C:\DFWDS\DFWDS_NAMES.TXT may have been on a visible share and backed up there. + +**How to apply:** When looking for lost configs or files that were on AD2 before the wipe, check Haubner's D: drive. Need to identify the machine's hostname or IP to access it. diff --git a/clients/dataforth/session-logs/user_mike_swanson.md b/clients/dataforth/session-logs/user_mike_swanson.md new file mode 100644 index 0000000..9d32958 --- /dev/null +++ b/clients/dataforth/session-logs/user_mike_swanson.md @@ -0,0 +1,10 @@ +--- +name: Mike Swanson - external IT consultant +description: User is Mike Swanson (mike@azcomputerguru.com), external IT consultant managing Dataforth's infrastructure recovery after crypto attack. +type: user +--- + +Mike Swanson, azcomputerguru.com — external IT consultant for Dataforth Corporation (Tucson, AZ). +Managing infrastructure recovery on AD2 after the crypto/ransomware attack. +Has direct CMD/PowerShell access to multiple machines on the network including user workstations (e.g., HGHAUBNER). +Engineering contacts: John Lehman (jlehman@dataforth.com), Peter Iliya (pIliya@dataforth.com).