phg/iodd-tool
0
0
Fork 0
Code Issues 5 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Validate the native analysis and VHD creation workflows #5

New issue
Closed
opened 2026-10-11 19:10:05 +00:00 by phg · 3 comments
phg commented 2026-10-11 19:10:05 +00:00
Owner
Copy link

Parent

IODD Tool specification

Context

The confirmed scope is a native Swift app for macOS 15+ on Apple Silicon, all external FAT32/exFAT disks including fixed media, and IODD mini/newer image-capable devices. Fixed VHD creation requires a valid container and verified complete-file contiguous allocation. Current work is planning and ticket publication only; implementation is a later effort. The public volume-operation API against disposable images is the confirmed main testing boundary.

Type: prototype
Mode: HITL

Presentation requirements

Follow Apple’s macOS Human Interface Guidelines and the accepted operation specifications. Redesign the interface against those guidelines before requesting workflow approval. Use platform-appropriate window, sidebar, toolbar, table, inspector, sheet, progress, keyboard and accessibility conventions. The agreed macOS 15 minimum remains in place; native controls follow the running system’s appearance.

Question

Does a concrete native macOS workflow make analysis, IODD eligibility, defrag/compaction, and fixed VHD creation understandable without concealing authorization or allocation failures?

Use the prototype skill to make a disposable, fixture-driven SwiftUI/AppKit sketch or an appropriately low-fidelity artifact. Include external drive selection, real extent counts, an accessible allocation map/table, operation preview, largest-free-run versus total-free-space explanation, VHD capacity input, and authorization/progress/cancellation/recovery/remount states. Test a fragmented-but-eligible ISO, an ineligible VHD, a stale plan, insufficient contiguous space, and a recovery-required outcome.

Use the resolved Define fixed VHD creation and allocation failure behavior as the capacity, guest-content, destination, free-run failure, progress, and creation-outcome contract. Obtain feedback on exact MiB/GiB input versus complete host allocation, a footer requiring another cluster, an uninitialized guest disk, destination collisions, separately requested compaction and renewed creation preview, measured estimates, and safe-stop outcomes. These are presentation checks of the agreed creation policy, not a replacement for its resolution.

Use the resolved Choose the filesystem engine and recoverable mutation contract as the access/cancellation/recovery contract. Obtain feedback on full-device offline analysis, renewed stale previews, Stop before/after commit, declared versus verified IODD detachment, recovery-bundle import and ambiguous evidence, partial batch outcomes, and remount failure separate from file success. These now-specific presentation questions graduate the retained map's recovery-presentation fog into this existing ticket.

Use the resolved Define analysis, defrag, and compaction success criteria as the analysis, Defrag All, compaction, preview and outcome contract. Obtain feedback on the default fragmented-file filter versus full-volume batch scope, proportional mixed map cells and complete textual extent detail, partial/stale analysis, adjustable Compact thresholds and count/allocated-byte caps, a VHD-derived target free run, per-operation backup acknowledgement, and staged/capped/cancelled work with verified file moves but no free-run growth. Show a small logical file on a large host cluster and preserved read-only file attributes. These are presentation checks of the accepted policy, not a replacement for its resolution.

Link the artifact rather than pasting it into the issue. Obtain live user feedback; a prototype ticket cannot be resolved by an agent approving its own sketch. This is a decision aid, not the production application.

Blocked by

Record ownership

This Forgejo issue governs the live implementation prerequisite. The original local planning question and its history are retained; the implementation publication index links both records. This HITL decision remains open until the user resolves it. Publication does not resolve the original decision or approve production disk writes.

## Parent [IODD Tool specification](https://git.s1q.dev/phg/iodd-tool/issues/7) ## Context The confirmed scope is a native Swift app for macOS 15+ on Apple Silicon, all external FAT32/exFAT disks including fixed media, and IODD mini/newer image-capable devices. Fixed VHD creation requires a valid container and verified complete-file contiguous allocation. Current work is planning and ticket publication only; implementation is a later effort. The public volume-operation API against disposable images is the confirmed main testing boundary. Type: prototype Mode: HITL ## Presentation requirements Follow [Apple’s macOS Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines) and the accepted operation specifications. Redesign the interface against those guidelines before requesting workflow approval. Use platform-appropriate window, sidebar, toolbar, table, inspector, sheet, progress, keyboard and accessibility conventions. The agreed macOS 15 minimum remains in place; native controls follow the running system’s appearance. ## Question Does a concrete native macOS workflow make analysis, IODD eligibility, defrag/compaction, and fixed VHD creation understandable without concealing authorization or allocation failures? Use the prototype skill to make a disposable, fixture-driven SwiftUI/AppKit sketch or an appropriately low-fidelity artifact. Include external drive selection, real extent counts, an accessible allocation map/table, operation preview, largest-free-run versus total-free-space explanation, VHD capacity input, and authorization/progress/cancellation/recovery/remount states. Test a fragmented-but-eligible ISO, an ineligible VHD, a stale plan, insufficient contiguous space, and a recovery-required outcome. Use the resolved [Define fixed VHD creation and allocation failure behavior](https://git.s1q.dev/phg/iodd-tool/issues/3) as the capacity, guest-content, destination, free-run failure, progress, and creation-outcome contract. Obtain feedback on exact MiB/GiB input versus complete host allocation, a footer requiring another cluster, an uninitialized guest disk, destination collisions, separately requested compaction and renewed creation preview, measured estimates, and safe-stop outcomes. These are presentation checks of the agreed creation policy, not a replacement for its resolution. Use the resolved [Choose the filesystem engine and recoverable mutation contract](https://git.s1q.dev/phg/iodd-tool/issues/2) as the access/cancellation/recovery contract. Obtain feedback on full-device offline analysis, renewed stale previews, Stop before/after commit, declared versus verified IODD detachment, recovery-bundle import and ambiguous evidence, partial batch outcomes, and remount failure separate from file success. These now-specific presentation questions graduate the retained map's recovery-presentation fog into this existing ticket. Use the resolved [Define analysis, defrag, and compaction success criteria](https://git.s1q.dev/phg/iodd-tool/issues/4) as the analysis, Defrag All, compaction, preview and outcome contract. Obtain feedback on the default fragmented-file filter versus full-volume batch scope, proportional mixed map cells and complete textual extent detail, partial/stale analysis, adjustable Compact thresholds and count/allocated-byte caps, a VHD-derived target free run, per-operation backup acknowledgement, and staged/capped/cancelled work with verified file moves but no free-run growth. Show a small logical file on a large host cluster and preserved read-only file attributes. These are presentation checks of the accepted policy, not a replacement for its resolution. Link the artifact rather than pasting it into the issue. Obtain live user feedback; a prototype ticket cannot be resolved by an agent approving its own sketch. This is a decision aid, not the production application. ## Blocked by - [Define fixed VHD creation and allocation failure behavior](https://git.s1q.dev/phg/iodd-tool/issues/3) - [Define analysis, defrag, and compaction success criteria](https://git.s1q.dev/phg/iodd-tool/issues/4) ## Record ownership This Forgejo issue governs the live implementation prerequisite. The original local planning question and its history are retained; the implementation publication index links both records. This HITL decision remains open until the user resolves it. Publication does not resolve the original decision or approve production disk writes.
phg self-assigned this 2026-10-12 14:32:24 +00:00
phg commented 2026-10-12 15:01:45 +00:00
Author
Owner
Copy link

Prototype checkpoint — awaiting live workflow feedback

Claimed by phg for the current wayfinder session. The presentation question remains open.

Review evidence: Interactive native workflow prototype, captured on prototype/native-workflow, commit 48f5e4a1c8bfdd68a7a22b734c11e9f934cb3afd. Download the standalone HTML and open it in a browser; it has no installation or server requirement. The T3 thread also displays it interactively.

The artifact is a disposable HTML state/workflow sketch for the native Swift application. All storage, authorization, progress, timing and verification outcomes are synthetic in-memory fixtures. The artifact uses the accepted engine, creation and analysis/compaction resolutions as its policy inputs. Actual native controls, filesystem/worker implementation and hardware qualification belong to later work.

The ten guided cases cover:

  • Read-only full-device offline Analyze, explicit IODD detachment declaration, partial coverage and a renewed complete scan.
  • A fragmented but allocation-eligible two-extent ISO; a structurally valid fixture VHD whose separately allocated footer fails complete-file contiguity; a filtered file table with full-volume Defrag All scope.
  • Exact VHD capacity, complete guest write/readback phases, publication/commit and the uninitialized guest result.
  • The 1 GiB virtual-capacity / 32 KiB cluster footer boundary, separately requested Compact, and a renewed creation preview after verified compaction.
  • 100 GiB total free versus a 40 GiB largest run for a 64 GiB VHD; no beneficial small-file plan within the declared bounds.
  • A stale preview rejected before work and renewed through fresh preparation and read-only analysis.
  • Stop before commit with verified rollback and no created VHD; Stop after commit retaining verified output; remount failure separate from the file result.
  • A two-move Compact plan whose first staging move succeeds without free-run growth; a one-move cap rejects the plan; safe cancellation preserves the verified first move and reports target not reached.
  • Partial batch success followed by recovery required, recovery-bundle import and ambiguous evidence refusing replay.
  • A 512-byte logical file occupying a 32 MiB exFAT cluster, with its read-only file attribute preserved and distinguished from host-volume write eligibility.

Review verification used T3's HTML preview to exercise the guided buttons and inspect rendered state at desktop/light and narrow/dark widths. Additional fixture checks covered exact 1.5 GiB → 1536 MiB conversion, rejection of 1.1 GiB and FAT32 4 GiB requests, destination collision, authorization denial, known active hardware drives blocking access despite a declaration, intact-bundle recovery with renewed preparation/authorization, and a read-only host volume. The narrow page stayed within its 360 px width. These checks concern this sketch's presentation and transitions, and provide no filesystem or hardware qualification evidence.

Presentation frontier for user feedback

  1. Analysis: do fragmentation versus IODD allocation eligibility, the full-volume batch scope, proportional cells/textual ranges and partial/stale results read clearly?
  2. Creation: is the exact virtual-capacity / host-length / cluster-allocation breakdown understandable, including the footer, create-only collision, uninitialized guest and separate Compact/retry flow?
  3. Access: are sibling-volume disruption, read versus write access, declaration versus verified hardware state, refreshed previews and per-operation backup acknowledgement clear?
  4. Outcomes: do phase/estimate handling, both Stop boundaries, partial batch success, zero-growth compaction and separate remount results communicate what actually happened?
  5. Recovery: does bundle import/matching and refusal of ambiguous evidence provide an understandable next action without an unsafe override?

Recommendation: retain the proposed presentation in each area, subject to phg's actual review. Resolution and the map's Decisions so far await that live exchange and the final shared-understanding check.

## Prototype checkpoint — awaiting live workflow feedback Claimed by phg for the current wayfinder session. The presentation question remains open. Review evidence: [Interactive native workflow prototype](https://git.s1q.dev/phg/iodd-tool/src/commit/48f5e4a1c8bfdd68a7a22b734c11e9f934cb3afd/.scratch/native-iodd/prototype/native-workflow.html), captured on [prototype/native-workflow](https://git.s1q.dev/phg/iodd-tool/src/branch/prototype/native-workflow), commit `48f5e4a1c8bfdd68a7a22b734c11e9f934cb3afd`. [Download the standalone HTML](https://git.s1q.dev/phg/iodd-tool/raw/commit/48f5e4a1c8bfdd68a7a22b734c11e9f934cb3afd/.scratch/native-iodd/prototype/native-workflow.html) and open it in a browser; it has no installation or server requirement. The T3 thread also displays it interactively. The artifact is a disposable HTML state/workflow sketch for the native Swift application. All storage, authorization, progress, timing and verification outcomes are synthetic in-memory fixtures. The artifact uses the accepted engine, creation and analysis/compaction resolutions as its policy inputs. Actual native controls, filesystem/worker implementation and hardware qualification belong to later work. The ten guided cases cover: - Read-only full-device offline Analyze, explicit IODD detachment declaration, partial coverage and a renewed complete scan. - A fragmented but allocation-eligible two-extent ISO; a structurally valid fixture VHD whose separately allocated footer fails complete-file contiguity; a filtered file table with full-volume Defrag All scope. - Exact VHD capacity, complete guest write/readback phases, publication/commit and the uninitialized guest result. - The 1 GiB virtual-capacity / 32 KiB cluster footer boundary, separately requested Compact, and a renewed creation preview after verified compaction. - 100 GiB total free versus a 40 GiB largest run for a 64 GiB VHD; no beneficial small-file plan within the declared bounds. - A stale preview rejected before work and renewed through fresh preparation and read-only analysis. - Stop before commit with verified rollback and no created VHD; Stop after commit retaining verified output; remount failure separate from the file result. - A two-move Compact plan whose first staging move succeeds without free-run growth; a one-move cap rejects the plan; safe cancellation preserves the verified first move and reports target not reached. - Partial batch success followed by recovery required, recovery-bundle import and ambiguous evidence refusing replay. - A 512-byte logical file occupying a 32 MiB exFAT cluster, with its read-only file attribute preserved and distinguished from host-volume write eligibility. Review verification used T3's HTML preview to exercise the guided buttons and inspect rendered state at desktop/light and narrow/dark widths. Additional fixture checks covered exact 1.5 GiB → 1536 MiB conversion, rejection of 1.1 GiB and FAT32 4 GiB requests, destination collision, authorization denial, known active hardware drives blocking access despite a declaration, intact-bundle recovery with renewed preparation/authorization, and a read-only host volume. The narrow page stayed within its 360 px width. These checks concern this sketch's presentation and transitions, and provide no filesystem or hardware qualification evidence. ## Presentation frontier for user feedback 1. Analysis: do fragmentation versus IODD allocation eligibility, the full-volume batch scope, proportional cells/textual ranges and partial/stale results read clearly? 2. Creation: is the exact virtual-capacity / host-length / cluster-allocation breakdown understandable, including the footer, create-only collision, uninitialized guest and separate Compact/retry flow? 3. Access: are sibling-volume disruption, read versus write access, declaration versus verified hardware state, refreshed previews and per-operation backup acknowledgement clear? 4. Outcomes: do phase/estimate handling, both Stop boundaries, partial batch success, zero-growth compaction and separate remount results communicate what actually happened? 5. Recovery: does bundle import/matching and refusal of ambiguous evidence provide an understandable next action without an unsafe override? Recommendation: retain the proposed presentation in each area, subject to phg's actual review. Resolution and the map's Decisions so far await that live exchange and the final shared-understanding check.
phg commented 2026-10-12 20:44:46 +00:00
Author
Owner
Copy link

HIG redesign checkpoint — current review artifact

The user required a macOS Human Interface Guidelines redesign before answering the workflow questions. That requirement is now recorded in this ticket and the parent map's Notes. The earlier sketch is retained as history; the revised artifact is the current presentation proposal.

Captured on prototype/native-workflow, commit 4e3e88b0b4f1ce175bda6e7a6e54e49db3452215; the published branch was verified against that commit. The T3 thread also shows the interactive redesign.

The presentation now uses a macOS volume sidebar, unified title/toolbar, app menus, sortable/resizable file columns, optional inspector, scoped modal sheets and a consistent bottom progress/status area. System typography, light/dark appearance, active/inactive selection, keyboard navigation, sheet focus, Escape, meaningful button titles and trailing primary actions replace the earlier custom presentation. Walkthrough and simulation controls are outside the app window.

Apple guidance consulted: Designing for macOS, Sidebars, Toolbars, Lists and tables, Sheets, Modality, Alerts, Progress indicators, Accessibility, and System fonts.

The agreed macOS 15 minimum remains the baseline. Production uses native SwiftUI/AppKit controls, system authorization and file choosers, adopting the running system's appearance. The browser sketch's menu/window chrome, SVG icons and authorization transition are design aids rather than production implementations.

All ten guided cases were exercised after the redesign. Additional checks covered actual keyboard row selection, column sorting/resizing, menu focus and Escape, modal parent isolation and focus, preparation gating, complete VHD footer extent detail, actual destination collisions, failed-but-verified rollback outcomes, light/dark appearance and narrow rendering. Inventory, statistics and map retain one labelled before-operation snapshot while a job runs; final results use the fresh verified fixture state. No production filesystem or hardware qualification was performed.

Live workflow feedback and the final shared-understanding check remain pending. This is review evidence, not a resolution comment; the ticket and map remain open.

## HIG redesign checkpoint — current review artifact The user required a macOS Human Interface Guidelines redesign before answering the workflow questions. That requirement is now recorded in this ticket and the parent map's Notes. The earlier sketch is retained as history; the revised artifact is the current presentation proposal. - [Redesigned interactive native workflow prototype](https://git.s1q.dev/phg/iodd-tool/src/commit/4e3e88b0b4f1ce175bda6e7a6e54e49db3452215/.scratch/native-iodd/prototype/native-workflow.html) - [Download the self-contained HTML](https://git.s1q.dev/phg/iodd-tool/raw/commit/4e3e88b0b4f1ce175bda6e7a6e54e49db3452215/.scratch/native-iodd/prototype/native-workflow.html) - [macOS HIG design references, preserved contracts and native-control handoff](https://git.s1q.dev/phg/iodd-tool/src/commit/4e3e88b0b4f1ce175bda6e7a6e54e49db3452215/.scratch/native-iodd/prototype/hig-design-notes.md) Captured on prototype/native-workflow, commit `4e3e88b0b4f1ce175bda6e7a6e54e49db3452215`; the published branch was verified against that commit. The T3 thread also shows the interactive redesign. The presentation now uses a macOS volume sidebar, unified title/toolbar, app menus, sortable/resizable file columns, optional inspector, scoped modal sheets and a consistent bottom progress/status area. System typography, light/dark appearance, active/inactive selection, keyboard navigation, sheet focus, Escape, meaningful button titles and trailing primary actions replace the earlier custom presentation. Walkthrough and simulation controls are outside the app window. Apple guidance consulted: [Designing for macOS](https://developer.apple.com/design/human-interface-guidelines/designing-for-macos/), [Sidebars](https://developer.apple.com/design/human-interface-guidelines/sidebars), [Toolbars](https://developer.apple.com/design/human-interface-guidelines/toolbars), [Lists and tables](https://developer.apple.com/design/human-interface-guidelines/lists-and-tables), [Sheets](https://developer.apple.com/design/human-interface-guidelines/sheets), [Modality](https://developer.apple.com/design/human-interface-guidelines/modality), [Alerts](https://developer.apple.com/design/human-interface-guidelines/alerts), [Progress indicators](https://developer.apple.com/design/human-interface-guidelines/progress-indicators), [Accessibility](https://developer.apple.com/design/human-interface-guidelines/accessibility), and [System fonts](https://developer.apple.com/documentation/technologyoverviews/fonts). The agreed macOS 15 minimum remains the baseline. Production uses native SwiftUI/AppKit controls, system authorization and file choosers, adopting the running system's appearance. The browser sketch's menu/window chrome, SVG icons and authorization transition are design aids rather than production implementations. All ten guided cases were exercised after the redesign. Additional checks covered actual keyboard row selection, column sorting/resizing, menu focus and Escape, modal parent isolation and focus, preparation gating, complete VHD footer extent detail, actual destination collisions, failed-but-verified rollback outcomes, light/dark appearance and narrow rendering. Inventory, statistics and map retain one labelled before-operation snapshot while a job runs; final results use the fresh verified fixture state. No production filesystem or hardware qualification was performed. Live workflow feedback and the final shared-understanding check remain pending. This is review evidence, not a resolution comment; the ticket and map remain open.
phg commented 2026-10-13 07:23:24 +00:00
Author
Owner
Copy link

Resolution — native workflows accepted

On 13 October 2026, phg answered “accept all” to the five remaining workflow questions after requiring and reviewing the macOS Human Interface Guidelines redesign. This is the live human feedback resolving this prototype decision.

Accepted evidence: HIG workflow prototype, commit 4e3e88b0b4f1ce175bda6e7a6e54e49db3452215 on prototype/native-workflow. Download the standalone HTML. Design notes and acceptance verdict are captured in commit 17d962a0f46dc49669d7314bb94d4525756dbf19; the reviewed HTML is unchanged.

Accepted presentation decisions

  1. Analysis: retain the distinction between fragmentation and IODD allocation eligibility, the display filter with full-volume Defrag All scope, the complete proportional allocation map and exact extent/range detail, and explicit partial/stale results that cannot authorize writes.
  2. VHD creation: retain separate virtual-capacity, complete-file-length and cluster-allocation values, including the footer-bearing cluster; create-only collision handling; the uninitialized guest result; and separately requested Compact followed by a renewed creation preview/retry.
  3. Access and preparation: retain explicit sibling-volume disruption, read versus write access, hardware-detachment declaration distinct from verified state, refreshed previews, authorization and per-operation current-backup acknowledgement. A macOS-unmounted volume does not prove detached hardware virtual drives.
  4. Progress and outcomes: retain phase-specific progress and time estimates, Stop before versus after commit, verified earlier batch results, zero-growth compaction outcomes and separate remount reporting. Existing accepted operation and error policies remain the behavior inputs.
  5. Recovery: retain bundle import and evidence matching before replay, refusal of ambiguous evidence without an override, and the clear recovery-required next action.

Native interface direction

Follow Apple’s macOS Human Interface Guidelines using a volume sidebar, unified title/toolbar and app menus, a sortable/resizable file table, optional inspector, scoped modal sheets, inline validation and stable progress/Stop/outcome presentation. Preserve keyboard operation, accessible textual allocation detail and system appearance. Review harness controls remain outside the product interface.

The eventual native Swift app uses SwiftUI/AppKit system controls, SF Symbols, system authorization and file choosers. The agreed macOS 15 minimum remains; the running system supplies its native appearance. The HTML is disposable, synthetic in-memory workflow evidence, not production control code or filesystem/hardware qualification evidence. Existing supported-volume, engine/recovery, creation and analysis/compaction resolutions remain authoritative for operation semantics.

Handoff

This ticket is resolved. No new planning question emerged from the acceptance. Set validation gates and the implementation handoff is the remaining decision and becomes unblocked when this ticket closes. It will set the final independent verification, fault/hardware matrix, release prerequisites, performance expectations and staged implementation plan. IODD Tool specification remains open until that decision is resolved; the current authorization remains planning and specification only.

## Resolution — native workflows accepted On 13 October 2026, phg answered **“accept all”** to the five remaining workflow questions after requiring and reviewing the macOS Human Interface Guidelines redesign. This is the live human feedback resolving this prototype decision. Accepted evidence: [HIG workflow prototype](https://git.s1q.dev/phg/iodd-tool/src/commit/4e3e88b0b4f1ce175bda6e7a6e54e49db3452215/.scratch/native-iodd/prototype/native-workflow.html), commit `4e3e88b0b4f1ce175bda6e7a6e54e49db3452215` on [prototype/native-workflow](https://git.s1q.dev/phg/iodd-tool/src/branch/prototype/native-workflow). [Download the standalone HTML](https://git.s1q.dev/phg/iodd-tool/raw/commit/4e3e88b0b4f1ce175bda6e7a6e54e49db3452215/.scratch/native-iodd/prototype/native-workflow.html). [Design notes and acceptance verdict](https://git.s1q.dev/phg/iodd-tool/src/commit/17d962a0f46dc49669d7314bb94d4525756dbf19/.scratch/native-iodd/prototype/hig-design-notes.md) are captured in commit `17d962a0f46dc49669d7314bb94d4525756dbf19`; the reviewed HTML is unchanged. ### Accepted presentation decisions 1. **Analysis:** retain the distinction between fragmentation and IODD allocation eligibility, the display filter with full-volume Defrag All scope, the complete proportional allocation map and exact extent/range detail, and explicit partial/stale results that cannot authorize writes. 2. **VHD creation:** retain separate virtual-capacity, complete-file-length and cluster-allocation values, including the footer-bearing cluster; create-only collision handling; the uninitialized guest result; and separately requested Compact followed by a renewed creation preview/retry. 3. **Access and preparation:** retain explicit sibling-volume disruption, read versus write access, hardware-detachment declaration distinct from verified state, refreshed previews, authorization and per-operation current-backup acknowledgement. A macOS-unmounted volume does not prove detached hardware virtual drives. 4. **Progress and outcomes:** retain phase-specific progress and time estimates, Stop before versus after commit, verified earlier batch results, zero-growth compaction outcomes and separate remount reporting. Existing accepted operation and error policies remain the behavior inputs. 5. **Recovery:** retain bundle import and evidence matching before replay, refusal of ambiguous evidence without an override, and the clear recovery-required next action. ### Native interface direction Follow [Apple’s macOS Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines) using a volume sidebar, unified title/toolbar and app menus, a sortable/resizable file table, optional inspector, scoped modal sheets, inline validation and stable progress/Stop/outcome presentation. Preserve keyboard operation, accessible textual allocation detail and system appearance. Review harness controls remain outside the product interface. The eventual native Swift app uses SwiftUI/AppKit system controls, SF Symbols, system authorization and file choosers. The agreed macOS 15 minimum remains; the running system supplies its native appearance. The HTML is disposable, synthetic in-memory workflow evidence, not production control code or filesystem/hardware qualification evidence. Existing supported-volume, engine/recovery, creation and analysis/compaction resolutions remain authoritative for operation semantics. ### Handoff This ticket is resolved. No new planning question emerged from the acceptance. [Set validation gates and the implementation handoff](https://git.s1q.dev/phg/iodd-tool/issues/6) is the remaining decision and becomes unblocked when this ticket closes. It will set the final independent verification, fault/hardware matrix, release prerequisites, performance expectations and staged implementation plan. [IODD Tool specification](https://git.s1q.dev/phg/iodd-tool/issues/7) remains open until that decision is resolved; the current authorization remains planning and specification only.
phg closed this issue 2026-10-13 07:23:25 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
implement/iodd-tool-spec-7
prototype/native-workflow
research/engine-recovery-constraints
research/supported-volume-geometry
No results found.
Labels
Clear labels   
needs-info

   
needs-triage

   
ready-for-agent
Ready for an agent; explicit blockers and scope still apply

  
ready-for-human

   
wayfinder:grilling

   
wayfinder:map

   
wayfinder:prototype

   
wayfinder:research

   
wontfix
No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
phg
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
phg/iodd-tool#5
No description provided.