Refactor: Replace dict-based workflow dependency bags with typed context objects #86
Description
Summary
The runtime no longer assembles workflow context directly in app.py; that part was improved by the refactor. The remaining problem is now centralized in nmapui/workflow_context.py, which still builds large plain dict objects that nmapui/workflows.py unpacks by string key.
That leaves the workflow contract brittle: missing or misnamed dependencies still fail late with KeyError during scan/report execution instead of failing early at construction time.
Current Evidence
build_scan_workflow_context() and build_report_workflow_context() create dict-based dependency bags with many required keys.
Examples:
nmapui/workflow_context.pybuilds the scan/report context with string-keyed dependency injectionnmapui/workflows.pyimmediately unpacks those dependencies with repeatedcontext["..."]lookups- a few fields are treated as optional with
.get(...), which makes the contract less explicit and harder to validate automatically
Why It Matters
- Dependency mismatches still surface at runtime, not when the app starts.
- The workflow contract is hard to understand because there is no single typed object describing required vs optional fields.
- Tests and future refactors remain harder than necessary because the workflow API is still a large mutable mapping rather than a stable dependency object.
Proposed Fix
Replace the dict contract with typed workflow dependency objects, for example:
- a
ScanWorkflowContextdataclass or lightweight dependency container - a
ReportWorkflowContextdataclass or lightweight dependency container - explicit optional fields for the few truly optional hooks
- one validation point in the builder layer so missing dependencies fail immediately and predictably
This would make the current architecture more durable without pulling the workflow logic back into app.py.
Severity
Medium — now a focused maintainability and correctness-contract issue rather than a broad architecture problem.