cdiag/MultiPROG-Ultimate-Kit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update.

Browse Source
This commit is contained in:
Vasyl Palamarchuk
2026-09-18 13:33:42 -07:00
parent c2863509e8
commit e4bd04a832
5 changed files with 173 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
17_MultiPROG_SDK/docs/README.md
+5
View File
@@ -4,6 +4,11 @@ This is the structured, per-function reference for the Multi-PROG scripting host
For facts transcribed directly from the supplied User Manual and Script Manual, see [MANUAL_API_REFERENCE.md](MANUAL_API_REFERENCE.md). That reference preserves undocumented fields as explicit gaps and must not be read as validation of other software versions.
Second-pass reports:
- [Knowledge consistency report](../../docs/reports/knowledge-consistency-report.md)
- [Script API coverage analysis](../../docs/reports/api-coverage-analysis.md)
## Status convention
Every function below is labeled with a **Verification status**:
01_Knowledge_Base/Multi-PROG Script Manual (EN).pdf → docs/Multi-PROG Script Manual (EN).pdf
View File
01_Knowledge_Base/Multi-PROG User Manual.pdf → docs/Multi-PROG User Manual.pdf
View File
docs/reports/api-coverage-analysis.md
+79
View File
@@ -0,0 +1,79 @@
# Script API Coverage Analysis
## Scope and status rules
The comparison set is the API list in the supplied Script Manual, consolidated in `17_MultiPROG_SDK/docs/MANUAL_API_REFERENCE.md`. `Documented` means the name/prototype is present in that manual-derived reference. `Example exists` means a manual-derived example or repository example is available; a documentation snippet is not counted as an executable host integration. `Used in repository` means a call-like occurrence in `.mjs` or `.js`, excluding Markdown. Generic offline functions such as repository CRC utilities are not counted as Multi-PROG host API usage.
The results show documentation coverage, not proof that an installed Multi-PROG host exposes every function. Live-host availability remains `NOT VERIFIED` unless tested in the installed Local Script environment.
## Coverage matrix
| Function name | Documented | Example exists | Used in repository | Missing example | Needs explanation |
| --- | --- | --- | --- | --- | --- |
| `ReadFile` | Yes | Manual reference only | No | Yes, executable host example | Yes: host return type is `NOT DOCUMENTED` |
| `WriteFile` | Yes | Manual reference only | No | Yes, executable host example | Yes: host return type is `NOT DOCUMENTED` |
| `ReadAndEmbedFile` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: parameter/return types are `NOT DOCUMENTED` |
| `SelectBuffer` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: buffer-name behavior is only described at prototype level |
| `ReadData` | Yes | Manual reference only | No | Yes | Yes: current-buffer behavior is manual wording; runtime result type is `NOT DOCUMENTED` |
| `WriteData` | Yes | Manual reference only | No | Yes | Yes: current-buffer behavior and result details need host verification |
| `EraseData` | Yes | No executable example | No | Yes | Yes: destructive behavior and return details need a controlled host test |
| `GetBufferData` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: returned data type is not fully specified |
| `GetBufferName` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: return type is not fully specified |
| `Print` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: output destination/visibility is not specified |
| `Message` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: UI behavior and return value are not specified |
| `Question` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: enum values and return semantics need host verification |
| `GetInput` | Yes | Manual reference only | No | Yes | Yes: input-type and return details are incomplete |
| `RequestInput` | Yes | Manual reference only | No | Yes | Yes: input schema and return object details are incomplete |
| `ShowPicture` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: supported path/type behavior is not specified |
| `AddFunctionButton` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: manual prototype uses `text`, `functionName`, `languageId`; callback-style alternatives are `NOT VERIFIED` |
| `SharedMemSetData` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: scope/lifetime is described only as a public buffer |
| `SharedMemGetData` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: return type/details are incomplete |
| `SharedMemGetSize` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: unit/type is not stated beyond “size” |
| `SharedMemClear` | Yes | `MANUAL_SNIPPETS.md` | No | No | No additional explanation required for the documented prototype |
| `MD5` | Yes | `MANUAL_SNIPPETS.md` | Generic offline implementation only | No host example | Yes: host output type is not specified |
| `CRC16` | Yes | `MANUAL_SNIPPETS.md` | Generic offline CRC16 implementations only | No host example | Yes: the manual shows optional `init` syntax but not algorithm parameters |
| `CRC32` | Yes | `MANUAL_SNIPPETS.md` | Generic offline CRC32 implementations only | No host example | Yes: product checksum coverage is `NOT VERIFIED` |
| `SHA1` | Yes | `MANUAL_SNIPPETS.md` | Generic offline implementation only | No host example | Yes: host output type is not specified |
| `SHA256` | Yes | `MANUAL_SNIPPETS.md` | Generic offline implementation only | No host example | Yes: host output type is not specified |
| `AES_*` | Yes | `MANUAL_SNIPPETS.md` | No | Yes, one controlled host example per mode/padding family | Yes: key, IV, block, padding, and return rules are incomplete |
| `DES_*` | Yes | Manual reference only | No | Yes, one controlled host example per mode/padding family | Yes: key, IV, block, padding, and return rules are incomplete |
| `ByteArrayToHexString` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: accepted array types and formatting rules are incomplete |
| `HexStringToByteArray` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: accepted string format and error behavior are incomplete |
| `CurrentDateTime` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: format-token behavior is only shown by example |
| `GetLanguageId` | Yes | `MANUAL_SNIPPETS.md` | No | No | Yes: returned identifier values are not enumerated |
## Coverage summary
- Documented API families: all requested names are represented in the manual-derived reference.
- Executable host-API examples: none were found in the repository's `.mjs`/`.js` files.
- Manual-derived Markdown snippets: present for representative file, buffer, UI, shared-memory, verification, encryption, conversion, language, and date calls.
- Generic offline implementations: CRC16/CRC32, MD5, SHA1, and SHA256 exist, but they are not host API integrations and do not establish Multi-PROG product checksum behavior.
- Device write/erase, file output, dialog input, shared-memory runtime, AES/DES runtime, and toolbar registration remain untested against an installed host.
## Script and example observations
The repository's runnable examples are deliberately dependency-free and generally accept `Uint8Array` inputs or return structured reports. They are useful business-logic components, but their host boundary is represented by placeholders or caller-supplied data. This separation is consistent with the repository's compatibility guidance and should be preserved until exact host signatures are verified.
The five `.mjs` files under `17_MultiPROG_SDK/reference/` that contain binary data rather than parseable JavaScript are not API examples. They should remain classified as reference/binary artifacts until the repository owner decides their governance location.
## Missing implementation knowledge
The following cannot be filled from the supplied manuals:
- Live-host availability and version-specific behavior.
- Complete parameter types and return values for many APIs.
- Error, cancellation, retry, and timeout semantics.
- Exact buffer lifetime and selection behavior.
- Device/adapter selection requirements exposed to scripts.
- Cryptographic key/IV/block constraints beyond the visible prototypes.
- Product-specific checksum algorithms and ECU/TCU coverage.
Each item is `NOT DOCUMENTED` or `NOT VERIFIED`, not an invitation to infer behavior from Node.js or generic libraries.
## Recommended future development sequence
1. Confirm every host signature in the installed Multi-PROG Local Script Help.
2. Add one read-only executable example for file input, buffer selection/read, reporting, and UI output.
3. Add isolated tests for conversion, hashes, CRCs, shared memory, and cryptography only after host return types are observed.
4. Add write/erase examples only with explicit authorization, synthetic fixtures, cancellation handling, and independent validation.
5. Record software version, device selection, input/output types, observed errors, and test results beside each verified API.
docs/reports/knowledge-consistency-report.md
+89
View File
@@ -0,0 +1,89 @@
# Knowledge Consistency Report
## Scope and method
This second-pass review covers the repository's Markdown files, JavaScript files (`.mjs` and `.js`), local Markdown links, and the manual-derived reference already present in `17_MultiPROG_SDK/docs/MANUAL_API_REFERENCE.md`. Script API usage below means a call-like occurrence in executable JavaScript; a name appearing only in Markdown is not counted as an implementation.
The review does not promote a repository statement to fact merely because it is repeated. Claims that cannot be established by the supplied manuals or an explicitly identified repository implementation remain `NOT VERIFIED` or `NOT DOCUMENTED`.
## Relationship map
| Domain | Primary repository surfaces | Related domains | Consistency status |
| --- | --- | --- | --- |
| EEPROM | `01_Knowledge_Base/AUTOMOTIVE_MEMORY_CONCEPTS.md`, `04_Workflows/EEPROM_READ_WRITE_WORKFLOW.md`, `17_MultiPROG_SDK/docs/EEPROM_API.md`, manual reference | MCU, adapters, wiring, checksums | Concepts and workflow are related; exact host API/device support remains `NOT VERIFIED` |
| MCU | `01_Knowledge_Base/AUTOMOTIVE_MEMORY_CONCEPTS.md`, `04_Workflows/MCU_READ_WRITE_WORKFLOW.md`, manual reference | EEPROM, adapters, wiring | Manual memory-area and wiring notes are centralized; complete pinouts are `NOT DOCUMENTED` |
| ECU | `01_Knowledge_Base/ECU_TCU_CLONE_CONCEPTS.md`, ECU workflows, manual reference | EEPROM, FLASH, wiring, checksums, scripts | Manual-supported examples are separated from broader repository concepts; exact coverage outside named examples is `NOT VERIFIED` |
| TCU | `01_Knowledge_Base/ECU_TCU_CLONE_CONCEPTS.md`, `04_Workflows/ECU_TCU_CLONE_WORKFLOW.md`, manual reference | EEPROM, FLASH, wiring, scripts | Manual operations are captured; model-specific procedures beyond VL381 are `NOT DOCUMENTED` |
| Scripts | `01_Knowledge_Base/MULTIPROG_ARCHITECTURE.md`, `18_Documentation`, `17_MultiPROG_SDK`, `03_Script_Starter_Kit` | all domains, tools | Authoring guidance is broad; executable host-API examples are largely absent |
| Checksums | `13_Research_Expansion/COMMON_CHECKSUMS.md`, `18_Documentation/CHECKSUM_GUIDE.md`, `09_Collected_JS/checksums`, SDK CRC utilities | EEPROM, MCU, ECU, TCU, scripts | Generic algorithms are implemented and tested; product/ECU checksum coverage is `NOT VERIFIED` |
| Encryption | `17_MultiPROG_SDK/docs/MANUAL_API_REFERENCE.md`, `13_Research_Expansion`, generic references | scripts, ECU/security topics | Manual API names are documented; key rules and automotive procedures are `NOT DOCUMENTED` |
| Tools | `tools/`, `14_Repository_Review`, test folders | scripts, documentation | Inventory/problem-detection tooling is separate from host APIs; generated reports are snapshots |
| Adapters | user manual reference, workflows, `07_Authorized_Key_Immobilizer_Work` | MCU, EEPROM, ECU, TCU, wiring | Accessory names and limited descriptions are centralized; connector pin maps are `NOT DOCUMENTED` |
| Wiring | MCU/ECU/TCU workflow pages and manual reference | adapters, device operations | The manual says software wiring diagrams exist; repository does not contain the supplied diagrams or complete pinouts |
## Canonical-source map
- Manual facts: `17_MultiPROG_SDK/docs/MANUAL_API_REFERENCE.md`.
- Manual code snippets: `17_MultiPROG_SDK/examples/javascript/MANUAL_SNIPPETS.md`.
- Script host API discovery status: `13_Research_Expansion/API_DISCOVERY_STATUS.md` and `13_Research_Expansion/DISCOVERED_APIS.md`.
- Reusable offline binary logic: `03_Script_Starter_Kit/binary_utils.mjs` and `09_Collected_JS/`.
- Workflow controls: `04_Workflows/`.
- Repository inventory and detector outputs: `14_Repository_Review/`.
The repeated API tables in `13_Research_Expansion/MULTIPROG_API_REFERENCE.md`, per-function SDK pages, and the manual-derived reference should not be treated as equally authoritative. The manual-derived reference is the source for supplied-PDF wording; the other pages retain discovery or implementation-status roles.
## Duplicate and overlapping content
| Overlap | Finding | Actionable interpretation |
| --- | --- | --- |
| `03_Script_Starter_Kit` and `08_Collected_MultiPROG_Scripts/Original` | Several starter examples and utilities are mirrored under `Original` | Preserve provenance, but label one as the maintained/tested copy and link the duplicate to it |
| `03_Script_Starter_Kit/binary_utils.mjs` and `09_Collected_JS/checksums/*` | Generic CRC/hash functionality appears in multiple implementation areas | Keep separate attribution/ownership, but document which implementation tests and which is reference-only |
| `13_Research_Expansion/*API*` and `17_MultiPROG_SDK/docs/*API*` | Host API names and placeholder status are repeated | Use the manual-derived reference for manual facts and retain the other pages as discovery notes until Local Script Help verifies them |
| `01_Knowledge_Base`, `04_Workflows`, and `18_Documentation` | Script lifecycle, validation, and module concepts recur at different detail levels | Add backlinks to the canonical manual/API and workflow pages; do not merge away safety or governance context |
## Conflicting or stale statements
1. `17_MultiPROG_SDK/docs/DIALOG_API.md` says no message, confirmation, or input API names have been discovered, while the manual-derived reference documents `Message`, `Question`, `GetInput`, and `RequestInput` from the supplied Script Manual. The older page is stale relative to the manual extraction and should be revised to say the functions are manual-documented but live-host verification is `NOT VERIFIED`.
2. `13_Research_Expansion/MULTIPROG_API_REFERENCE.md` gives speculative signatures such as `AddFunctionButton(label, callback)` and `GetOpenFileName(prompt, defaultPath)`. The supplied Script Manual shows `AddFunctionButton(text, functionName, languageId)` and zero-argument `GetOpenFileName()`. The speculative signatures must not be used as manual-derived signatures.
3. `17_MultiPROG_SDK/docs/FILE_API.md` and `DEVICE_API.md` include inferred parameter and return types. The manual-derived reference records those fields as `NOT DOCUMENTED` when the PDF does not state them.
4. Several workflow and research pages discuss broad automotive procedures or model coverage that are not established by the supplied manuals. Those pages need `NOT VERIFIED` labels at the claim boundary when presented alongside manual facts.
## Orphan pages and missing backlinks
The link scan found many Markdown pages with no inbound local Markdown link. Some are intentionally standalone catalog entries, prompts, source notes, or generated/reference pages; they are not automatically defects. High-value documentation orphans that should receive an index backlink include:
- `01_Knowledge_Base/API_DISCOVERY_WORKSHEET.md`
- `13_Research_Expansion/API_DISCOVERY_STATUS.md`
- `13_Research_Expansion/MASTER_SCRIPT_CATALOG.md`
- `13_Research_Expansion/MULTIPROG_API_REFERENCE.md`
- `17_MultiPROG_SDK/examples/javascript/MANUAL_SNIPPETS.md`
- `16_Tests/MultiPROG/TEST_GUIDE.md`
The repository has a natural index in `17_MultiPROG_SDK/docs/README.md` and a broader index in `README.md`; these are the appropriate backlink targets. The report does not classify third-party README files or quarantined/reference artifacts as missing navigation merely because they have no inbound link.
## Dead local links
The link scan found 29 missing local targets, concentrated in root-level documents that use parent-relative paths:
- `CONTRIBUTING.md` points to `../03_Script_Starter_Kit/`.
- `LICENSES.md` points to multiple `../...` repository paths, including a `LICENSE` file that is not present.
- `SECURITY.md` points to multiple `../...` repository paths.
From a root-level Markdown file, these targets should normally be repository-relative without the leading `../`. The missing `LICENSE` target is a separate repository gap and must not be silently replaced with an invented license file. External URLs were not classified as dead by this local scan.
## Validation and future knowledge gaps
- No supplied manual or repository file provides a complete wiring/pinout database.
- No supplied manual validates the live host API against a particular installed Multi-PROG version.
- No product-specific checksum coverage was established by the generic CRC tests.
- No executable repository example currently proves a complete host read/write workflow using the documented host functions.
- API names present only in Markdown are documentation coverage, not runtime support.
These remain `NOT DOCUMENTED` or `NOT VERIFIED` until an authoritative source or installed-host test is available.
## Recommended maintenance order
1. Correct root-level relative links and decide whether the missing `LICENSE` target should be created by the repository owner.
2. Update `DIALOG_API.md` and speculative API tables to distinguish manual-documented from live-host-verified.
3. Add backlinks from the SDK and repository indexes to the high-value orphan pages.
4. Add host-adapter examples only after exact signatures are confirmed in the installed Multi-PROG Local Script Help.