Assess IODD image eligibility #11

New issue

Closed

opened 2026-10-11 19:10:42 +00:00 by phg · 1 comment

phg commented

2026-10-11 19:10:42 +00:00

Owner

Parent

IODD Tool specification

What to build

Show model-aware ISO allocation eligibility and fixed VHD format/allocation results beside each image in the analyzed file table.

Acceptance criteria

Documented mini/newer profiles distinguish fragmented files from image allocation eligibility, with unknown firmware or unqualified conditions stated.
ISO fixtures with 1, 24, and 25 extents receive the expected allocation assessment under the agreed profile policy.
A VHD requires valid fixed-container metadata and one complete host extent; dynamic/differencing/VHDX or malformed containers are reported explicitly.
A payload-contiguous VHD whose footer occupies a separate extent fails allocation eligibility.
Virtual capacity, exact EOF, footer fields/checksum/geometry, guest initialization, and bootability are not conflated.
A valid unpartitioned fixed VHD is recognized as a valid container, without claiming it is bootable or hardware-qualified.
The UI explains relevant browser/path/virtual-drive preparation restrictions using model-specific evidence rather than imposing legacy conventions universally.
Independent footer/parser fixtures and allocation manifests verify the public assessment and visible reasons.

Blocked by

Validation contract

Completion requires the applicable independently checked software evidence in Set validation gates and the implementation handoff. A closed policy decision does not establish that implementation tests have passed. Use disposable images/virtual volumes and controlled faults; no hardware-trial or performance gate applies.

Scope

This ticket belongs to the later implementation effort. All planning decisions are resolved; current work covers tracker and documentation updates. The parent specification indexes the authoritative product and software-validation contracts. Forgejo governs live updates; retained local files record the handoff.

## Parent [IODD Tool specification](https://git.s1q.dev/phg/iodd-tool/issues/7) ## What to build Show model-aware ISO allocation eligibility and fixed VHD format/allocation results beside each image in the analyzed file table. ## Acceptance criteria - [ ] Documented mini/newer profiles distinguish fragmented files from image allocation eligibility, with unknown firmware or unqualified conditions stated. - [ ] ISO fixtures with 1, 24, and 25 extents receive the expected allocation assessment under the agreed profile policy. - [ ] A VHD requires valid fixed-container metadata and one complete host extent; dynamic/differencing/VHDX or malformed containers are reported explicitly. - [ ] A payload-contiguous VHD whose footer occupies a separate extent fails allocation eligibility. - [ ] Virtual capacity, exact EOF, footer fields/checksum/geometry, guest initialization, and bootability are not conflated. - [ ] A valid unpartitioned fixed VHD is recognized as a valid container, without claiming it is bootable or hardware-qualified. - [ ] The UI explains relevant browser/path/virtual-drive preparation restrictions using model-specific evidence rather than imposing legacy conventions universally. - [ ] Independent footer/parser fixtures and allocation manifests verify the public assessment and visible reasons. ## Blocked by - [Analyze a FAT32 image](https://git.s1q.dev/phg/iodd-tool/issues/8) - [Define analysis, defrag, and compaction success criteria](https://git.s1q.dev/phg/iodd-tool/issues/4) ## Validation contract Completion requires the applicable independently checked software evidence in [Set validation gates and the implementation handoff](https://git.s1q.dev/phg/iodd-tool/issues/6). A closed policy decision does not establish that implementation tests have passed. Use disposable images/virtual volumes and controlled faults; no hardware-trial or performance gate applies. ## Scope This ticket belongs to the later implementation effort. All planning decisions are resolved; current work covers tracker and documentation updates. The parent specification indexes the authoritative product and software-validation contracts. Forgejo governs live updates; retained local files record the handoff.

phg added the

ready-for-agent

label

2026-10-11 19:10:42 +00:00

phg referenced this issue

2026-10-11 19:10:43 +00:00

Create a contiguous VHD on a FAT32 image #13

phg self-assigned this

2026-10-13 09:45:32 +00:00

phg referenced this issue from a commit

2026-10-13 10:42:04 +00:00

Merge ticket #11: assess IODD image allocation and format eligibility

phg commented

2026-10-13 10:42:21 +00:00

Author

Owner

Resolution — IODD image eligibility implemented

Implemented on implement/iodd-tool-spec-7, implementation 9b33d03, merge a812067, final checked integration 904dd22.

The app assesses documented mini/ST300/ST400/MINI PRO profiles, unknown models and LK100 separately. ISO allocation1/24/25 cases and complete-file VHD1-extent requirements are independent of fixed-container validity. The footer validator checks exact EOF, fields/checksum/capacity/geometry and correctly permits supported existing original/current-size differences. Firmware/path/preparation guidance retains source attribution and does not claim measured device behavior. Partial/stale snapshots cannot authorize an assessment.

Validation:12 public-operation assessment tests plus the prior corpus yield49 passing integrated tests with Xcode27.0/27A266a, Swift6.4. Independent allocation/footer observations, QEMU consumer/generator checks and exFAT ValidDataLength traps agree. Native macOS26.6.2/25G83 keyboard/Accessibility checks exercised model/firmware controls, filters, preparation guidance, complete footer extents, stale clearing and distinct exFAT malformed logical footer. Arm64 release build/plist pass.

Reproducible evidence and window-only screenshots. Guest initialization, bootability and physical IODD qualification remain explicitly unassessed; baseline/current-stable release checks remain in the accepted later gate.

## Resolution — IODD image eligibility implemented Implemented on [implement/iodd-tool-spec-7](https://git.s1q.dev/phg/iodd-tool/src/branch/implement/iodd-tool-spec-7), implementation [9b33d03](https://git.s1q.dev/phg/iodd-tool/commit/9b33d03), merge [a812067](https://git.s1q.dev/phg/iodd-tool/commit/a8120678d43211be09bacb440b0fe8c2a2b7c143), final checked integration [904dd22](https://git.s1q.dev/phg/iodd-tool/commit/904dd2267443afcc6391e92b58b3e70ae98a482c). The app assesses documented mini/ST300/ST400/MINI PRO profiles, unknown models and LK100 separately. ISO allocation1/24/25 cases and complete-file VHD1-extent requirements are independent of fixed-container validity. The footer validator checks exact EOF, fields/checksum/capacity/geometry and correctly permits supported existing original/current-size differences. Firmware/path/preparation guidance retains source attribution and does not claim measured device behavior. Partial/stale snapshots cannot authorize an assessment. Validation:12 public-operation assessment tests plus the prior corpus yield49 passing integrated tests with Xcode27.0/27A266a, Swift6.4. Independent allocation/footer observations, QEMU consumer/generator checks and exFAT ValidDataLength traps agree. Native macOS26.6.2/25G83 keyboard/Accessibility checks exercised model/firmware controls, filters, preparation guidance, complete footer extents, stale clearing and distinct exFAT malformed logical footer. Arm64 release build/plist pass. [Reproducible evidence and window-only screenshots](https://git.s1q.dev/phg/iodd-tool/src/commit/904dd2267443afcc6391e92b58b3e70ae98a482c/docs/validation/image-eligibility.md). Guest initialization, bootability and physical IODD qualification remain explicitly unassessed; baseline/current-stable release checks remain in the accepted later gate.

phg closed this issue

2026-10-13 10:42:21 +00:00

phg referenced this issue

2026-10-13 10:42:23 +00:00

IODD Tool specification #7