Dosu Logo
Home
Documents
tasks
tasks
Type
External
Status
Published
Created
Feb 27, 2026
Updated
Mar 23, 2026
Updated by
Dosu Bot

opnDossier Implementation Tasks#

Release Roadmap#

v1.0 - Essential CLI Tool (Target: Tonight)#

Core Value: Robust OPNsense config.xml to documentation converter

Critical Tasks for v1.0 Release:

  • TASK-030: Refactor CLI command structure (convert, display, validate commands)
  • TASK-031: Comprehensive help system
  • TASK-032: Verbose/quiet output modes
  • TASK-035: YAML configuration file support
  • TASK-036: Environment variable support (OPNDOSSIER_*)
  • TASK-037: CLI flag override system
  • TASK-044: Achieve >60% test coverage (not including internal/audit package)
  • TASK-047: Automated quality checks
  • TASK-049: Update README for v1.0
  • TASK-053: Verify offline operation
  • TASK-060: GoReleaser configuration (ensure release requirements are met and add support to justfile)
  • TASK-063: Automated release process

v1.0 Features:

  • Parse OPNsense config.xml files with validation
  • Convert to markdown, JSON, or YAML formats
  • Display in terminal with syntax highlighting and themes
  • Export to files with overwrite protection
  • Complete offline operation
  • Cross-platform binaries
  • Comprehensive error handling

v1.1 - Advanced Analysis & Audit Reports#

Core Value: Security-focused audit and compliance reporting

Major Features:

  • TASK-023-029: Complete audit report generation system
    • Red team recon reports (attack surfaces, WAN exposure)
    • Blue team defensive reports (findings, recommendations)
  • TASK-027c: Plugin-based compliance architecture
  • Multi-mode reporting (blue/red). Note: standard mode was removed — neutral documentation is handled by the convert command.
  • STIG, SANS, firewall best practice compliance checking
  • Blackhat commentary mode
  • Template-driven report customization
  • TASK-044: Achieve >70% test coverage (applies to all packages)

v1.2 - Performance & Enterprise Features#

Core Value: Production-ready enterprise deployment

Major Features:

  • TASK-039: Concurrent processing for multiple files
  • TASK-040: CLI startup time optimization
  • TASK-041: Memory-efficient processing for large files
  • TASK-033: Progress indicators
  • TASK-034: Tab completion support
  • TASK-042: Performance benchmarking
  • TASK-058: Enhanced container support
  • Advanced plugin ecosystem
  • Batch processing capabilities
  • Configuration diff analysis
  • TASK-044: Achieve >80% test coverage (applies to all packages)

v2.0 - Major Architectural Changes & Breaking Improvements#

Core Value: Modernized architecture with programmatic generation and enhanced performance

Major Features:

  • TASK-068: Implement programmatic markdown generation system
    • Replace template-based generation with Go code-based generation
    • Provide better performance, maintainability, and consistency
    • Maintain backward compatibility with existing functionality
    • Improve testability and separation of concerns
  • TASK-069: Remove deprecated code paths and cleanup technical debt
  • TASK-070: Enhanced configuration analysis and dead rule detection
  • TASK-071: Multi-format output system (JSON, YAML, Markdown)
  • TASK-072: Performance optimization and concurrent processing
  • TASK-044: Achieve >85% test coverage (applies to all packages)

Overview#

This document provides a comprehensive task checklist for implementing the opnDossier CLI tool based on the requirements document and user stories. Each task includes specific references to relevant requirement items and user stories.

Project Status: Basic CLI structure exists with XML parsing capability, but core functionality needs implementation.

Phase 1: Core Infrastructure & Dependencies#

1.1 Dependency Management & Technology Stack Setup#

  • TASK-001: Update Go dependencies to match requirements

    • Context: Current go.mod needs to include all required dependencies
    • Requirement: F001-F008 (Core Features), Technical Specifications section
    • User Story: US-012 (Configuration Management)
    • Action: Add viper for configuration, fang for CLI enhancement, lipgloss, glamour, and charmbracelet/log dependencies
    • Acceptance: go.mod matches requirements specification

  • TASK-002: Implement structured logging with charmbracelet/log

    • Context: Replace current log usage with structured logging
    • Requirement: US-036 (Structured Logging), Technical Specifications
    • User Story: US-036 (Monitoring and Observability)
    • Action: Configure structured logging throughout application using charmbracelet/log
    • Acceptance: All logging uses structured format with proper levels

  • TASK-003: Set up configuration management with viper

    • Context: Implement proper configuration management with viper framework
    • Requirement: US-012, US-013, US-014 (Configuration Management)
    • User Story: US-012-US-014 (Configuration Management)
    • Action: Implement YAML config files, environment variables, CLI overrides using viper
    • Acceptance: Configuration system supports all three methods with standard precedence (CLI flags > env vars > config file > defaults)

  • TASK-003a: Implement CLI enhancement with fang

    • Context: Add fang for enhanced CLI experience with styled help, errors, and automatic features
    • Requirement: User Experience Specifications, CLI Interface Requirements
    • User Story: US-009-US-011 (CLI Interface)
    • Action: Integrate fang.Execute() for enhanced CLI experience with styled help, errors, and automatic version/completion
    • Acceptance: CLI provides enhanced user experience with styled output and automatic features

1.2 Project Structure & Organization#

  • TASK-004: Create internal package structure - internal package structure implemented

    • Context: Current structure only has cmd/ package
    • Requirement: System Architecture section, Go organization standards
    • User Story: US-033 (Development Standards)
    • Action: Create internal/ and pkg/ directories with proper package organization
    • Acceptance: Follows Google Go Style Guide organization

  • TASK-005: Implement proper error handling patterns

    • Context: Current error handling uses log.Fatal
    • Requirement: US-018, US-019 (Error Handling), Development Standards
    • User Story: US-018-US-019 (Error Handling and Recovery)
    • Action: Implement error wrapping with context, graceful error recovery
    • Acceptance: All errors provide actionable messages, no log.Fatal usage
    • Note: Proper error-handling patterns are now in place with context wrapping and graceful recovery mechanisms

Phase 2: Core XML Processing#

2.1 XML Parser Implementation#

  • TASK-006: Create XML parser interface and implementation

    • Context: Current XML parsing is basic, needs proper interface
    • Requirement: F001 (XML parsing), US-001, US-002 (XML Parsing)
    • User Story: US-001-US-002 (XML Parsing and Validation)
    • Action: Create internal/parser/ package with XML parsing interface
    • Acceptance: Parser validates XML structure and provides meaningful errors

  • TASK-007: Implement OPNsense schema validation

    • Context: Current parsing doesn't validate against OPNsense schema
    • Requirement: F008 (XML validation), US-001 (Schema validation)
    • User Story: US-001 (Schema validation)
    • Action: Add schema validation for OPNsense config.xml format
    • Acceptance: Invalid XML files produce specific error messages with line/column info

  • TASK-008: Implement streaming XML processing

    • Context: Current parsing loads entire file into memory
    • Requirement: US-015, US-040 (Memory efficiency), Performance Requirements
    • User Story: US-015-US-017 (Performance Requirements)
    • Action: Use streaming XML decoder for large file support
    • Acceptance: Memory usage scales linearly with file size

2.2 Configuration Data Models#

  • TASK-009: Refactor OPNsense struct for better organization

    • Context: Current struct is auto-generated and not well organized
    • Requirement: Data Requirements section, F001 (Data models)
    • User Story: US-003 (Markdown conversion)
    • Action: Reorganize struct for better hierarchy preservation
    • Acceptance: Configuration hierarchy is preserved for markdown conversion

  • TASK-010: Create configuration processor interface

    • Context: Need interface for processing parsed configurations
    • Requirement: System Architecture section, Component interaction
    • User Story: US-003 (Configuration processing)
    • Action: Create internal/processor/ package with configuration processing
    • Acceptance: Processor can transform XML data into structured format

Phase 3: Markdown Generation & Output#

3.1 In-Memory Markdown Generation#

  • TASK-011: Create markdown generator interface

    • Context: Parse config.xml into opnSense model using Phase 2 functionality, then generate markdown string in memory using templates
    • Requirement: F002 (Markdown conversion), US-003 (Markdown conversion), F011 (Markdown generation)
    • User Story: US-003-US-004 (Markdown Conversion)
    • Action: Create internal/markdown/ package that takes opnSense model and generates structured markdown string using templates in internal/templates and https://pkg.go.dev/github.com/Masterminds/sprig/v3 for template functions
    • Acceptance: Generator produces properly formatted markdown string from opnSense model using templates from internal/templates with sprig template functions

  • TASK-012: Implement calculated fields and model enrichment

    • Context: Need to populate calculated fields in opnSense model for comprehensive reporting
    • Requirement: F002 (Hierarchy preservation), US-003 (Structure preservation), F011 (Markdown generation), F014 (Configuration analysis)
    • User Story: US-003 (Comprehensive configuration representation)
    • Action: Implement model enrichment to calculate derived fields, statistics, and analysis data
    • Acceptance: opnSense model contains all calculated fields needed for comprehensive markdown generation

  • TASK-013: Implement template-based markdown generation

    • Context: Use templates in internal/templates to generate structured markdown with proper formatting
    • Requirement: F002 (Template-based generation), US-004 (Syntax highlighting), F011 (Markdown generation)
    • User Story: US-004 (Structured markdown output)
    • Action: Implement template rendering system using templates in internal/templates for comprehensive and summary formats
    • Acceptance: Generated markdown string is well-formatted, structured, and uses appropriate templates with comprehensive and summary output styles

3.2 Terminal Display Implementation (opndossier display)#

  • TASK-014: Implement terminal display with glamour

    • Context: Take in-memory markdown string and render to terminal with markdown rendering
    • Requirement: F003 (Terminal display), US-004 (Syntax highlighting), F012 (Terminal display), F024 (Display mode)
    • User Story: US-004 (Terminal output), US-043 (Theme support)
    • Action: Create internal/display/ package that renders markdown string to terminal using github.com/charmbracelet/glamour
    • Acceptance: opndossier display command renders markdown string with colored, syntax-highlighted output and handles large configurations gracefully with pagination or scrolling

  • TASK-015: Add theme support (light/dark)

    • Context: Need support for different terminal themes in display output
    • Requirement: US-043 (Theme support), F009 (Theme support), F012 (Terminal display), F024 (Display mode)
    • User Story: US-043 (Light and dark theme support)
    • Action: Implement theme detection and appropriate color schemes for terminal display
    • Acceptance: Terminal display is readable in both light and dark terminal themes

  • TASK-016: Implement theme-aware markdown rendering

    • Context: Configure glamour with theme detection and appropriate styling for light/dark terminals
    • Requirement: Technical Specifications (glamour library), F009 (Theme support), F012 (Terminal display), F024 (Display mode)
    • User Story: US-004 (Markdown rendering), US-043 (Theme support)
    • Action: Configure glamour renderer with theme detection and appropriate color schemes
    • Acceptance: Markdown renders with appropriate colors for both light and dark terminal themes; it should fallback to ascii if the terminal is not color capable and notty if color is disabled, with proper theme detection and fallback behavior

Phase 4: File Export & Input Validation#

4.1 File Export Implementation (opndossier convert)#

  • TASK-017: Implement markdown file export

    • Context: Export opnSense model as markdown string to file using templates
    • Requirement: F004 (File export), US-005, US-006 (File export), F010 (Multiple output formats), F013 (File export), F015 (Valid and parseable files), F023 (Convert mode)
    • User Story: US-005-US-006 (File Export)
    • Action: Create markdown export functionality in internal/export/ package
    • Acceptance: Exports valid markdown file with no terminal control characters, uses templates from internal/templates, passes markdown validation tests, includes error handling, overwrite protection, and smart file naming

  • TASK-018: Implement JSON file export

    • Context: Export opnSense model as JSON file for programmatic access
    • Requirement: F004 (File export), F010 (Multiple output formats), F013 (File export), F015 (Valid and parseable files), F023 (Convert mode)
    • User Story: US-005-US-006 (File Export)
    • Action: Create JSON export functionality in internal/export/ package
    • Acceptance: Exports valid, parsable JSON file with no terminal control characters, passes JSON validation tests, includes error handling and validation features

  • TASK-019: Implement YAML file export

    • Context: Export opnSense model as YAML file for human-readable structured data
    • Requirement: F004 (File export), F010 (Multiple output formats), F013 (File export), F015 (Valid and parseable files), F023 (Convert mode)
    • User Story: US-005-US-006 (File Export)
    • Action: Create YAML export functionality in internal/export/ package
    • Acceptance: Exports valid, parsable YAML file with no terminal control characters, passes YAML validation tests, includes error handling and validation features

  • TASK-020: Implement output file naming and overwrite protection

    • Context: Handle output file naming with smart defaults and overwrite protection
    • Requirement: US-006 (Custom output files), F004 (File export), US-018 (Error handling), F023 (Convert mode)
    • User Story: US-006 (Custom output files), US-018 (Clear error messages)
    • Action: Implement output file naming logic with defaults (config.md, config.json, config.yaml) and overwrite prompts with -f force option
    • Acceptance: Uses input filename with appropriate extension as default, prompts before overwrite unless -f flag provided, no automatic directory creation

  • TASK-021: Add file validation and error handling

    • Context: Need proper file I/O error handling for export operations
    • Requirement: US-018 (Error handling), Data validation rules, F023 (Convert mode)
    • User Story: US-018 (Clear error messages)
    • Action: Implement comprehensive file validation and error handling for export operations
    • Acceptance: Provides clear error messages for file I/O issues during export

  • TASK-021a: Implement exported file validation tests

    • Context: Need to ensure exported files are valid and parseable by standard tools
    • Requirement: F015 (Valid and parseable files), Testing Standards, F023 (Convert mode)
    • User Story: US-020-US-021 (Testing and Validation)
    • Action: Create validation tests that verify exported files can be parsed by standard tools (markdown linters, JSON parsers, YAML parsers)
    • Acceptance: All exported files pass validation tests with standard tools and libraries

4.2 Audit Report Generation#

  • TASK-023: Implement audit finding struct and data model

    • Context: Need consistent internal structure for audit findings across all modes
    • Requirement: F021 (Audit Finding Struct Support), F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-046-US-048 (Audit Report Generation)
    • Action: Create internal/audit/ package with audit finding structs including Title, Severity, Description, Recommendation, Tags, and optional AttackSurface/ExploitNotes for red mode
    • Acceptance: Audit engine uses consistent internal structure for all findings

  • TASK-024: Implement multi-mode report controller

    • Context: Need to support blue and red report modes with different content and tone. Note: standard mode was removed — neutral documentation is handled by the convert command.
    • Requirement: F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-046-US-048 (Audit Report Generation)
    • Action: Create mode-based report generation system that determines content and tone based on --mode flag
    • Acceptance: System generates different report types based on selected mode
    • Status: Deferred to v2.1 (see #174)

  • TASK-025: Implement template-driven markdown generation for audit reports

    • Context: Need to use Go text/template files for generating markdown reports with user-extensible templates
    • Requirement: F017 (Template-Driven Markdown Output), F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-046-US-048 (Audit Report Generation)
    • Action: Create template system using Go text/template with sections for interfaces, firewall rules, NAT rules, DHCP, certificates, VPN config, static routes, and high availability
    • Acceptance: Reports are generated using templates that are user-extensible and include all required sections (interfaces, firewall rules, NAT rules, DHCP, certificates, VPN config, static routes, and high availability)
    • Status: Deferred to v2.1 (see #174)

  • TASK-025a: Support user template overrides

    • Context: Power users should be able to customize markdown templates
    • Requirement: F017 (Template-Driven Markdown Output), F016 (Multiple Modes), User Experience Specifications, F025 (Audit mode)
    • User Story: US-048 (Standard summary reporting)
    • Action: Support --template-dir to override built-in templates with user-defined versions (e.g., ~/.opnDossier/templates)
    • Acceptance: If override exists, user template is rendered instead of bundled default

  • TASK-026: Build red team recon module

    • Context: Need to generate attacker-focused reports highlighting attack surfaces and enumeration data
    • Requirement: F018 (Red Team Recon Reporting), F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-046 (Red Team Recon Reporting)
    • Action: Implement red mode reporting that highlights WAN-exposed services, weak NAT rules, admin portals, attack surfaces, and includes --blackhat-mode for snarky commentary
    • Acceptance: Red mode reports highlight attack surfaces and provide data useful for pivoting/enumeration including pivot data (hostnames, static leases, service ports)

  • TASK-026a: Classify red team findings

    • Context: Enhance red team reporting with attack-surface-specific classification
    • Requirement: F018 (Red Team Recon Reporting), F016 (Multiple Modes), F021 (Audit Finding Struct Support), F025 (Audit mode)
    • User Story: US-046 (Red team recon reporting)
    • Action: Add classification logic for:
      • WAN exposed
      • Interesting ports (22, 80, 443, 3389, etc.)
      • Unfiltered/Shadowed rules
    • Acceptance: Red reports tag findings and NAT rules with targetable characteristics
    • Status: Deferred to v2.1 (see #174)

  • TASK-027: Build blue team audit module

    • Context: Need to generate defensive audit reports with findings and recommendations
    • Requirement: F019 (Blue Team Defensive Reporting), F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-047 (Blue Team Defensive Reporting)
    • Action: Implement blue mode reporting with audit findings, structured configuration tables, and recommendations with severity ratings
    • Acceptance: Blue mode reports include security findings, structured configuration tables, and actionable recommendations with severity ratings

  • TASK-027a: Add compliance tagging to blue team findings

    • Context: Enable future STIG/SANS compliance correlation
    • Requirement: F019 (Blue Team Defensive Reporting), F016 (Multiple Modes), F021 (Audit Finding Struct Support), F025 (Audit mode)
    • User Story: US-047 (Blue team defensive reporting)
    • Action: Allow findings to include optional compliance tags (e.g., STIG-V-206694, FIREWALL-001)
    • Acceptance: Blue team report includes optional compliance mappings per finding
    • Note: Implemented comprehensive STIG and SANS compliance integration with audit engine and enhanced templates

  • TASK-027b: Implement STIG and SANS compliance integration

    • Context: Integrate industry-standard security compliance frameworks for comprehensive blue team reporting
    • Requirement: F019 (Blue Team Defensive Reporting), F016 (Multiple Modes), F021 (Audit Finding Struct Support), F025 (Audit mode)
    • User Story: US-047 (Blue team defensive reporting)
    • Action:
      • Create internal/audit/standards.go with STIG and SANS control definitions
      • Create internal/audit/engine.go with compliance analysis engine
      • Create enhanced blue team template with compliance reporting
      • Add comprehensive documentation for compliance standards
    • Acceptance:
      • Blue team reports include STIG and SANS compliance analysis
      • Audit findings are mapped to specific control references
      • Compliance status is tracked and reported
      • Enhanced templates provide detailed compliance matrices and recommendations

  • TASK-027c: Implement plugin-based compliance architecture

    • Context: Create a flexible, extensible plugin system for compliance standards
    • Requirement: F022 (Plugin-Based Compliance Architecture), F016 (Multiple Modes), F021 (Audit Finding Struct Support), F025 (Audit mode)
    • User Story: US-047 (Blue team defensive reporting), US-048 (Standard summary reporting)
    • Action:
      • Create internal/audit/interfaces.go with CompliancePlugin interface
      • Create internal/audit/plugin.go with PluginRegistry and plugin management
      • Create internal/audit/plugin_manager.go with high-level plugin operations
      • Create internal/audit/plugins/ directory for plugin implementations
      • Migrate existing STIG compliance to plugin architecture
      • Create plugin development documentation
    • Acceptance:
      • Plugin interface is well-defined and extensible
      • Plugin registry supports dynamic plugin registration
      • Plugin manager provides high-level plugin operations
      • STIG compliance is successfully migrated to plugin architecture
      • Plugin development guide is comprehensive and clear

  • TASK-028: Generate standard summary report Removed — neutral documentation is handled by the convert command. Standard audit mode was removed; only blue and red modes are supported.

    • Context: Need neutral, comprehensive documentation reports for general use
    • Requirement: F020 (Standard Summary Report) Removed
    • User Story: US-048 (Standard Summary Reporting) Removed
    • Action: Implement standard mode reporting Superseded by convert command
    • Acceptance: Standard mode produces comprehensive, neutral documentation N/A

  • TASK-029: Add CLI flags for audit report modes

    • Context: Need command-line interface for selecting report modes and options
    • Requirement: F016 (Multiple Modes), F018 (Red Team Recon Reporting), F025 (Audit mode)
    • User Story: US-046-US-048 (Audit Report Generation)
    • Action: Add --mode flag (blue/red) and --blackhat-mode flag for red team reports. Note: standard mode was removed.
    • Acceptance: CLI supports mode selection and blackhat mode option with proper validation

  • TASK-029a: Add CLI support for plugin-based compliance

    • Context: Need command-line interface for plugin selection and management
    • Requirement: F022 (Plugin-Based Compliance Architecture), F016 (Multiple Modes), F025 (Audit mode)
    • User Story: US-047 (Blue team defensive reporting), US-048 (Standard summary reporting)
    • Action:
      • Add --compliance flag for selecting specific compliance plugins
      • Add --list-plugins flag to show available compliance plugins
      • Add --plugin-info flag to show detailed plugin information
      • Add --plugin-config flag for plugin-specific configuration
    • Acceptance:
      • CLI supports selection of specific compliance plugins
      • Users can list and inspect available plugins
      • Plugin configuration can be specified via CLI
      • Plugin selection integrates with existing audit report modes
    • Status: Deferred to v2.1 (see #174)

Phase 5: CLI Interface Enhancement#

5.1 Command Structure#

  • TASK-030: Refactor CLI command structure

    • Context: Current CLI is basic, needs proper command organization
    • Requirement: F007 (CLI interface), US-009-US-011 (CLI Interface)
    • User Story: US-009-US-011 (CLI Interface)
    • Action: Reorganize commands using proper Cobra patterns
    • Acceptance: CLI provides intuitive command structure with proper help
    • Note: CLI structure is fully implemented with proper Cobra patterns, comprehensive help system, and all three commands (convert, display, validate) working correctly

  • TASK-030a: Implement --about CLI flag

    • Context: Users should be able to see version, authorship, and project identity
    • Requirement: F007 (CLI interface), User Experience Specifications
    • User Story: US-009 (Intuitive CLI interface), US-010 (Comprehensive help)
    • Action: Add --about flag to display banner, project info, evil bit tagline, etc.
    • Acceptance: CLI displays a stylized ASCII/banner + basic metadata when invoked with --about

  • TASK-031: Implement comprehensive help system

    • Context: Need detailed help documentation
    • Requirement: US-010 (Help documentation), CLI Interface Requirements
    • User Story: US-010 (Comprehensive help)
    • Action: Add detailed help text, examples, and usage instructions
    • Acceptance: Help system provides clear usage instructions and examples
    • Note: Enhanced root command help with comprehensive workflow examples, error handling guidance, and configuration file examples. Improved flag descriptions across all commands for better user guidance.

  • TASK-032: Add verbose and quiet output modes

    • Context: Need output level control
    • Requirement: US-011 (Output modes), User Experience Specifications
    • User Story: US-011 (Verbose and quiet modes)
    • Action: Implement --verbose and --quiet flags with appropriate output levels
    • Acceptance: Output detail adjusts based on verbosity flags

  • TASK-022: Implement comprehensive input validation

    • Context: Need validation for all user inputs
    • Requirement: US-027 (Input validation), Security Requirements
    • User Story: US-027 (Input validation)
    • Action: Add validation for file paths, configuration options, CLI arguments
    • Acceptance: All inputs are validated comprehensively

5.2 CLI Features#

  • TASK-033: Implement progress indicators

    • Context: Need feedback for long-running operations
    • Requirement: User Experience Specifications, Performance Requirements
    • User Story: US-011 (Progress feedback)
    • Action: Add progress indicators for file processing operations
    • Acceptance: Users get feedback during long-running operations

  • TASK-034: Add tab completion support

    • Context: Need CLI completion for better UX
    • Requirement: US-045 (Tab completion), Usability Stories
    • User Story: US-045 (Tab completion support)
    • Action: Implement Cobra completion for commands and options
    • Acceptance: Tab completion works for supported shells

Phase 6: Configuration Management#

6.1 Configuration System#

  • TASK-035: Implement YAML configuration file support

    • Context: Need persistent configuration storage
    • Requirement: US-012 (YAML config), Configuration Management
    • User Story: US-012 (YAML configuration files)
    • Action: Create configuration file format and loading system
    • Acceptance: Tool loads settings from YAML configuration files
    • Note: Fully implemented with Viper integration, proper precedence handling, comprehensive validation, full test coverage, and complete documentation. All quality checks pass.

  • TASK-036: Add environment variable support

    • Context: Need secure configuration for sensitive options
    • Requirement: US-013 (Environment variables), Security Requirements
    • User Story: US-013 (Environment variables)
    • Action: Implement OPNDOSSIER_ prefixed environment variables
    • Acceptance: Environment variables override configuration file settings (standard precedence)
    • Note: Fully implemented with comprehensive environment variable support for all configuration fields, proper precedence handling (CLI flags > env vars > config file > defaults), extensive test coverage including boolean, integer, and slice value types, and complete documentation throughout the codebase.

  • TASK-037: Implement CLI flag override system

    • Context: Need runtime configuration override capability
    • Requirement: US-014 (CLI overrides), Configuration Management
    • User Story: US-014 (Command-line overrides)
    • Action: Ensure CLI flags take precedence over config file and env vars
    • Acceptance: Command-line flags override all other configuration sources (highest precedence)
    • Note: Fully implemented with proper flag binding using viper.BindPFlags(), comprehensive precedence handling in all commands (buildEffectiveFormat, buildConversionOptions, buildDisplayOptions), extensive test coverage, and complete documentation. All quality checks pass.

6.2 Configuration Validation#

  • TASK-038: Add configuration validation
    • Context: Need to validate configuration settings
    • Requirement: Data validation rules, Security Requirements
    • User Story: US-027 (Input validation)
    • Action: Implement validation for all configuration options
    • Acceptance: Invalid configurations produce clear error messages

Phase 7: Performance & Optimization#

7.1 Performance Implementation#

  • TASK-039: Implement concurrent processing

    • Context: Need efficient processing for multiple files
    • Requirement: US-017 (Concurrent processing), Performance Requirements
    • User Story: US-017 (Concurrent processing)
    • Action: Use goroutines and channels for I/O operations
    • Acceptance: Multiple files can be processed concurrently

  • TASK-040: Optimize CLI startup time

    • Context: Need fast startup for operator efficiency
    • Requirement: US-016 (Fast startup), Performance Requirements
    • User Story: US-016 (Fast CLI startup)
    • Action: Optimize initialization and dependency loading
    • Acceptance: CLI starts quickly for operator efficiency

  • TASK-041: Implement memory-efficient processing

    • Context: Need to handle large configuration files
    • Requirement: US-015, US-040 (Memory efficiency), Performance Constraints
    • User Story: US-015-US-017 (Performance Requirements)
    • Action: Use streaming processing and minimize memory allocations
    • Acceptance: Memory usage scales efficiently with file size

7.2 Benchmarking & Monitoring#

  • TASK-042: Add performance benchmarking

    • Context: Need to measure and optimize performance
    • Requirement: US-037 (Performance profiling), Testing Standards
    • User Story: US-037 (Performance profiling)
    • Action: Implement benchmark tests for critical code paths
    • Acceptance: Performance benchmarks are established and tracked

  • TASK-043: Implement health check functionality

    • Context: Need system health validation
    • Requirement: US-038 (Health checks), Monitoring and Observability
    • User Story: US-038 (Health check capabilities)
    • Action: Add health check command for system validation
    • Acceptance: Health check reports operational status

Phase 8: Testing & Quality Assurance#

8.1 Test Implementation#

  • TASK-044: Implement comprehensive unit tests

    • Context: Need >80% test coverage
    • Requirement: US-020, US-021 (Testing), Testing Standards
    • User Story: US-020-US-021 (Testing and Validation)
    • Action: Create table-driven tests for all components
    • Acceptance: Test coverage exceeds 80%

  • TASK-044a: Implement plugin testing framework

    • Context: Need comprehensive testing for plugin architecture
    • Requirement: F022 (Plugin-Based Compliance Architecture), Testing Standards
    • User Story: US-020-US-021 (Testing and Validation)
    • Action:
      • Create plugin testing utilities and mock interfaces
      • Implement plugin lifecycle testing (registration, validation, execution)
      • Create plugin integration tests with real compliance checks
      • Add plugin performance and memory testing
      • Create plugin compatibility and version testing
    • Acceptance:
      • Plugin testing framework supports comprehensive plugin validation
      • Plugin lifecycle is thoroughly tested
      • Plugin integration tests validate real compliance scenarios
      • Plugin performance meets specified requirements
      • Plugin compatibility is verified across versions

  • TASK-045: Add integration tests

    • Context: Need end-to-end workflow testing
    • Requirement: Testing Standards, Integration Testing Approach
    • User Story: US-021 (Thorough testing)
    • Action: Implement integration tests with build tags
    • Acceptance: Full CLI workflow is tested end-to-end

  • TASK-046: Implement performance tests

    • Context: Need to validate performance requirements
    • Requirement: US-039 (Test performance), Performance Requirements
    • User Story: US-039 (Individual test performance)
    • Action: Add benchmark tests and performance validation
    • Acceptance: Individual tests complete in <100ms

8.2 Quality Assurance#

  • TASK-047: Implement automated quality checks

    • Context: Need automated code quality enforcement
    • Requirement: US-033 (Quality checks), CI/CD Expectations
    • User Story: US-033 (Automated quality checks)
    • Action: Configure pre-commit hooks and CI quality gates
    • Acceptance: All quality checks pass automatically
    • Note: Fully implemented with comprehensive pre-commit hooks, golangci-lint configuration with 50+ linters, security scanning with gosec, modernization checks, automated formatting, commit message validation, GitHub Actions workflow validation, and complete CI/CD pipeline integration. All quality checks pass automatically both locally and in GitHub Actions.

  • TASK-048: Add security scanning

    • Context: Need security validation
    • Requirement: Security Requirements, Code Security
    • User Story: US-041 (No hardcoded secrets)
    • Action: Integrate gosec and dependency scanning
    • Acceptance: No security vulnerabilities detected

Phase 9: Documentation & Help#

9.1 Documentation Implementation#

  • TASK-049: Create comprehensive README

    • Context: Need clear project documentation
    • Requirement: US-022 (Installation instructions), Documentation Standards
    • User Story: US-022-US-024 (Documentation and Help)
    • Action: Write clear installation and usage instructions
    • Acceptance: README provides clear project overview and quick start
    • Note: Updated README for v1.0 release with comprehensive feature documentation, v1.0-specific information, installation instructions, development status, roadmap, and proper formatting. All quality checks pass.

  • TASK-049a: Create plugin development documentation

    • Context: Need comprehensive documentation for plugin development
    • Requirement: F022 (Plugin-Based Compliance Architecture), Documentation Standards
    • User Story: US-022-US-024 (Documentation and Help)
    • Action:
      • Create plugin development guide with examples
      • Document plugin interface and lifecycle
      • Provide plugin testing and debugging guidance
      • Create plugin distribution and packaging documentation
      • Add plugin troubleshooting and FAQ sections
    • Acceptance:
      • Plugin development guide is comprehensive and clear
      • Plugin interface is well-documented with examples
      • Plugin testing and debugging guidance is practical
      • Plugin distribution documentation covers all scenarios
      • Plugin troubleshooting section addresses common issues

  • TASK-050: Implement usage examples

    • Context: Need examples for common workflows
    • Requirement: US-023 (Usage examples), User Experience Specifications
    • User Story: US-023 (Usage examples)
    • Action: Create examples for common use cases and workflows
    • Acceptance: Documentation includes clear examples for common workflows

  • TASK-051: Add API documentation

    • Context: Need documentation for public packages
    • Requirement: US-024 (API documentation), Documentation Standards
    • User Story: US-024 (API documentation)
    • Action: Document all public packages and interfaces
    • Acceptance: API documentation is complete and accurate

9.2 Help System#

  • TASK-052: Implement command help system
    • Context: Need detailed command help
    • Requirement: US-010 (Help documentation), CLI Interface Requirements
    • User Story: US-010 (Comprehensive help)
    • Action: Add detailed help for all commands and subcommands
    • Acceptance: Help system provides detailed usage information

Phase 10: Security & Compliance#

10.1 Security Implementation#

  • TASK-053: Ensure offline operation

    • Context: Need to verify no external dependencies
    • Requirement: F005, US-007, US-008 (Offline operation), Security Requirements
    • User Story: US-007-US-008 (Offline Operation)
    • Action: Remove all external dependencies and network calls
    • Acceptance: Tool operates completely offline without errors
    • Note: Verified complete offline operation through comprehensive testing. All CLI commands, output formats, configuration options, and file I/O operations work without any network dependencies. No external API calls, DNS lookups, or network requests detected. Application is fully airgap-compatible.

  • TASK-054: Implement secure error messages

    • Context: Need to prevent sensitive information exposure
    • Requirement: US-026 (Secure error messages), Security Requirements
    • User Story: US-026 (Secure error messages)
    • Action: Ensure error messages don't expose sensitive configuration details
    • Acceptance: Error messages are secure and don't leak sensitive data

  • TASK-055: Add secure defaults

    • Context: Need security-first default configuration
    • Requirement: US-042 (Secure defaults), Security Requirements
    • User Story: US-042 (Secure defaults)
    • Action: Implement security-first default settings
    • Acceptance: Default configuration is secure without additional setup

10.2 Compliance#

  • TASK-056: Ensure no telemetry
    • Context: Need to verify no data transmission
    • Requirement: US-025 (No telemetry), Security Requirements
    • User Story: US-025 (No telemetry)
    • Action: Remove any telemetry or external communication
    • Acceptance: Tool transmits no data externally

Phase 11: Cross-Platform Support#

11.1 Platform Compatibility#

  • TASK-057: Test cross-platform compatibility

    • Context: Need to support Linux, macOS, Windows
    • Requirement: US-028 (Cross-platform), Technical Specifications
    • User Story: US-028-US-029 (Cross-Platform Support)
    • Action: Test and validate on all supported platforms
    • Acceptance: Tool works consistently across all supported platforms

  • TASK-058: Implement container support

    • Context: Need to work in containerized environments
    • Requirement: US-029 (Container support), Deployment Architecture
    • User Story: US-029 (Container environments)
    • Action: Ensure compatibility with containerized deployments
    • Acceptance: Tool functions properly in containerized environments

11.2 Build System#

  • TASK-059: Configure static compilation
    • Context: Need portable binaries with no runtime dependencies
    • Requirement: US-032 (Static binaries), Build and Distribution
    • User Story: US-032 (Static binaries)
    • Action: Configure CGO_ENABLED=0 for static compilation
    • Acceptance: Binaries are statically compiled with no runtime dependencies

Phase 12: Build & Distribution#

12.1 Build System#

  • TASK-060: Configure GoReleaser for multi-platform builds

    • Context: Need automated cross-platform builds
    • Requirement: Build and Distribution, CI/CD Pipeline Design
    • User Story: US-030-US-031 (Build and Distribution)
    • Action: Configure GoReleaser for Linux, macOS, Windows builds
    • Acceptance: Automated builds work for all target platforms
    • Note: Fully implemented with comprehensive GoReleaser configuration supporting multi-platform builds (Linux, macOS, Windows for amd64 and arm64), version injection via ldflags, macOS notarization, package manager support (deb, rpm, apk, archlinux), SBOM generation, and complete justfile integration. All quality checks pass.

  • TASK-061: Implement package manager support

    • Context: Need easy installation from package managers
    • Requirement: US-030 (Package managers), Build and Distribution
    • User Story: US-030 (Package manager installation)
    • Action: Add support for common package managers (deb, rpm, etc.)
    • Acceptance: Tool can be installed via package managers

  • TASK-062: Add binary signing and verification

    • Context: Need signed and verified binaries
    • Requirement: US-031 (Signed binaries), Security Requirements
    • User Story: US-031 (Signed and verified binaries)
    • Action: Implement code signing and checksum verification
    • Acceptance: Binaries have proper signatures and checksums

12.2 Release Management#

  • TASK-063: Implement automated release process

    • Context: Need automated release management
    • Requirement: US-034 (Release management), CI/CD Pipeline Design
    • User Story: US-034 (Automated release management)
    • Action: Configure automated release pipeline with GoReleaser
    • Acceptance: Releases are automatically built, tested, and distributed
    • Note: Fully implemented with comprehensive GoReleaser configuration, automated GitHub Actions workflow that triggers on git tags (v*), multi-platform builds, Docker images, package manager support, SBOM generation, macOS notarization, and complete justfile integration. Release workflow now automatically triggers on tag pushes and can also be manually triggered via workflow_dispatch.

  • TASK-064: Add SBOM generation

    • Context: Need software bill of materials for security
    • Requirement: Security Requirements, Dependency Security
    • User Story: US-031 (Security verification)
    • Action: Implement SBOM generation for dependency transparency
    • Acceptance: SBOM is generated for each release

Phase 13: Development & Maintenance#

13.1 Development Workflow#

  • TASK-065: Implement contributing guidelines

    • Context: Need clear contribution process
    • Requirement: US-035 (Contributing guidelines), Development Standards
    • User Story: US-035 (Contributing guidelines)
    • Action: Create comprehensive contributing guidelines
    • Acceptance: Contributors can follow clear guidelines for contributions

  • TASK-065a: Create plugin contribution guidelines

    • Context: Need clear guidelines for plugin contributions
    • Requirement: F022 (Plugin-Based Compliance Architecture), Development Standards
    • User Story: US-035 (Contributing guidelines)
    • Action:
      • Create plugin contribution guidelines and standards
      • Define plugin review process and criteria
      • Create plugin quality checklist and requirements
      • Document plugin testing and validation requirements
      • Create plugin documentation standards
    • Acceptance:
      • Plugin contribution guidelines are clear and comprehensive
      • Plugin review process is well-defined and efficient
      • Plugin quality checklist ensures consistent quality
      • Plugin testing requirements are clearly specified
      • Plugin documentation standards ensure maintainability

  • TASK-066: Configure automated CI/CD pipeline

    • Context: Need automated quality enforcement
    • Requirement: CI/CD Expectations, Development Workflow
    • User Story: US-033 (Automated quality checks)
    • Action: Set up GitHub Actions for automated testing and building
    • Acceptance: CI/CD pipeline runs all quality checks automatically

  • TASK-066a: Add plugin CI/CD integration

    • Context: Need automated plugin testing and validation
    • Requirement: F022 (Plugin-Based Compliance Architecture), CI/CD Expectations
    • User Story: US-033 (Automated quality checks)
    • Action:
      • Add plugin testing to CI/CD pipeline
      • Implement plugin validation and compatibility checks
      • Add plugin performance testing to CI/CD
      • Create plugin build and packaging automation
      • Add plugin documentation generation to CI/CD
    • Acceptance:
      • Plugin testing is integrated into CI/CD pipeline
      • Plugin validation runs automatically on changes
      • Plugin performance is monitored and tracked
      • Plugin builds are automated and consistent
      • Plugin documentation is automatically generated

13.2 Maintenance#

  • TASK-067: Implement dependency update automation

    • Context: Need to keep dependencies updated
    • Requirement: Dependency Security, Maintenance Practices
    • User Story: US-033 (Development standards)
    • Action: Set up automated dependency updates and security scanning
    • Acceptance: Dependencies are automatically updated and scanned

  • TASK-067a: Implement plugin maintenance automation

    • Context: Need to maintain plugin ecosystem and compatibility
    • Requirement: F022 (Plugin-Based Compliance Architecture), Maintenance Practices
    • User Story: US-033 (Development standards)
    • Action:
      • Set up automated plugin compatibility testing
      • Implement plugin version management and updates
      • Create plugin ecosystem monitoring and reporting
      • Add plugin deprecation and migration automation
      • Implement plugin security scanning and validation
    • Acceptance:
      • Plugin compatibility is automatically tested and maintained
      • Plugin versions are managed and updated systematically
      • Plugin ecosystem health is monitored and reported
      • Plugin deprecation and migration is automated
      • Plugin security is continuously validated and monitored

Acceptance Criteria Summary#

Core Functionality Acceptance#

  • XML parsing works with valid OPNsense config.xml files (TASK-006, TASK-007)
  • Invalid XML files produce meaningful error messages (TASK-007, TASK-008)
  • Markdown conversion preserves configuration hierarchy (TASK-011, TASK-012)
  • Terminal output includes syntax highlighting (TASK-014, TASK-016)
  • File export creates valid output files (markdown, json, or yaml) (TASK-017, TASK-018, TASK-019)
  • Audit report generation supports multiple modes (blue, red) (TASK-023, TASK-024, TASK-025). Note: standard mode was removed.
  • Red team recon reporting highlights attack surfaces and enumeration data (TASK-026)
  • Blue team defensive reporting includes audit findings and recommendations (TASK-027)
  • Plugin-based compliance architecture supports extensible compliance standards (TASK-027c)
  • CLI supports plugin selection and management (TASK-029a)
  • Standard summary reports provide neutral, comprehensive documentation (TASK-028) Removed — handled by convert command.
  • CLI supports mode selection and blackhat mode options (TASK-029)
  • Tool operates completely offline (TASK-053)
  • CLI provides comprehensive help documentation (TASK-031, TASK-052)
  • Configuration management supports YAML files and environment variables (TASK-035, TASK-036)
  • Command-line flags override configuration file settings (TASK-037)
  • Performance meets specified requirements (TASK-039, TASK-040, TASK-041)

Quality Assurance Acceptance#

  • Test coverage exceeds 80% (TASK-044)
  • Plugin testing framework supports comprehensive validation (TASK-044a)
  • All linting checks pass (TASK-047)
  • Code follows Google Go Style Guide (TASK-004)
  • Documentation is complete and accurate (TASK-049, TASK-050, TASK-051)
  • Plugin development documentation is comprehensive (TASK-049a)
  • Cross-platform compatibility is verified (TASK-057)
  • Security requirements are met (TASK-053, TASK-054, TASK-055, TASK-056)
  • Performance benchmarks are established and met (TASK-042)
  • Error handling is comprehensive and user-friendly (TASK-005, TASK-021, TASK-022)

Deployment Acceptance#

  • Multi-platform binaries are available (TASK-060)
  • Package manager support is implemented (TASK-061)
  • Release process is automated (TASK-063)
  • Binary signatures and checksums are provided (TASK-062)
  • Installation instructions are clear and complete (TASK-049)
  • Container support is verified (TASK-058)
  • Static compilation works correctly (TASK-059)

Task Dependencies#

Critical Path Dependencies#

  • TASK-001 → TASK-002 → TASK-003 (Dependencies must be set up first)
  • TASK-006 → TASK-007 → TASK-008 (XML parsing foundation)
  • TASK-011 → TASK-012 → TASK-013 (In-memory markdown generation foundation)
  • TASK-014 → TASK-015 → TASK-016 (Terminal display foundation)
  • TASK-017 → TASK-018 → TASK-019 → TASK-020 → TASK-021 (File export foundation)
  • TASK-023 → TASK-024 → TASK-025 → TASK-026 → TASK-027 → TASK-029 (Audit report generation foundation)
  • TASK-030 → TASK-031 → TASK-032 (CLI foundation)

Parallel Development Opportunities#

  • Phase 1 (Infrastructure) can be developed in parallel with Phase 2 (XML Processing)
  • Phase 3.1 (Markdown generation) can be developed in parallel with Phase 3.2 (Terminal display)
  • Phase 4.1 (File export) can be developed in parallel with Phase 4.2 (Input validation)
  • Phase 4.3 (Audit report generation) can be developed in parallel with Phase 4.1 and 4.2
  • Phase 5 (CLI interface) can be developed in parallel with Phase 6 (Configuration)
  • Phase 7 (Performance) can be developed in parallel with Phase 8 (Testing)

Risk Mitigation#

High-Risk Tasks#

  • TASK-007: XML schema validation complexity
  • TASK-026: Red team recon module implementation
  • TASK-039: Concurrent processing implementation
  • TASK-057: Cross-platform compatibility challenges
  • TASK-060: Multi-platform build configuration

Mitigation Strategies#

  • Start with simple XML validation and iterate
  • Implement red team reporting with basic attack surface detection first
  • Implement concurrent processing incrementally
  • Test on each platform during development
  • Use GoReleaser's built-in multi-platform support

Phase 14: Programmatic Markdown Generation (v2.0)#

14.1 Core Programmatic Generation Implementation#

  • TASK-068: Implement programmatic markdown generation system

    • Context: Replace template-based generation with Go code-based generation for better performance and maintainability
    • Requirement: F026 (Programmatic markdown generation system), F002 (Markdown conversion), F011 (Markdown generation)
    • User Story: US-003-US-004 (Markdown Conversion), US-015-US-017 (Performance Requirements)
    • Action:
      • Create internal/markdown/programmatic/ package for code-based generation
      • Implement ProgrammaticGenerator struct implementing markdown.Generator interface
      • Create section builders for system, network, firewall, NAT, DHCP, certificates, etc.
      • Implement structured markdown builders using Go code instead of templates
      • Maintain backward compatibility with existing template functionality
      • Add performance benchmarking to compare with template-based approach
      • Create migration utilities for transitioning from templates to programmatic generation
    • Acceptance:
      • Programmatic generation produces identical output to template-based generation
      • Performance improvements are measurable (target: 30-50% faster)
      • Memory usage is reduced compared to template rendering
      • Code is more maintainable and testable than template approach
      • Backward compatibility is maintained for existing functionality
      • Unit tests have better coverage and are easier to write
      • Documentation generation is consistent and structured
    • Dependencies: TASK-011, TASK-012, TASK-013 (existing markdown generation foundation)
    • Breaking Changes: This is a v2.0 feature and may introduce API changes in the markdown generation interface

  • TASK-068a: Implement programmatic section builders

    • Context: Create modular section builders for different configuration areas
    • Requirement: F026 (Programmatic markdown generation), System Architecture (modular components)
    • User Story: US-003 (Structured markdown output)
    • Action:
      • Create SystemSectionBuilder for system configuration sections
      • Create NetworkSectionBuilder for interface and network configuration
      • Create FirewallSectionBuilder for firewall rules and policies
      • Create NATSectionBuilder for NAT rules and configuration
      • Create DHCPSectionBuilder for DHCP scopes and static assignments
      • Create CertificateSectionBuilder for certificate information
      • Create ServiceSectionBuilder for various services (DNS, NTP, SNMP, etc.)
      • Implement consistent interface across all section builders
      • Add section-specific formatting and styling logic
    • Acceptance:
      • Each section builder is self-contained and testable
      • Section builders use consistent interfaces and patterns
      • Generated sections match existing template output format
      • Section builders support both comprehensive and summary modes
      • Code is well-documented and follows Go best practices

  • TASK-068b: Add programmatic generation performance optimization

    • Context: Optimize programmatic generation for better performance than templates
    • Requirement: F026 (Programmatic generation performance), Performance Requirements
    • User Story: US-015-US-017 (Performance Requirements)
    • Action:
      • Implement efficient string building using strings.Builder
      • Add object pooling for frequently allocated structures
      • Optimize memory allocations in section builders
      • Implement concurrent generation for independent sections
      • Add performance benchmarks comparing template vs programmatic approaches
      • Profile memory usage and optimize hot paths
      • Implement caching for expensive calculations
    • Acceptance:
      • Programmatic generation is 30-50% faster than template-based generation
      • Memory usage is reduced by 20-40% compared to templates
      • Large configuration files (>10MB) process efficiently
      • Benchmark tests demonstrate consistent performance improvements
      • Memory profiling shows reduced allocations and garbage collection pressure

  • TASK-068c: Implement backward compatibility layer

    • Context: Ensure existing template functionality continues to work during transition
    • Requirement: F026 (Backward compatibility), System Architecture (non-destructive updates)
    • User Story: US-003 (Existing functionality preservation)
    • Action:
      • Create compatibility wrapper that delegates to template or programmatic generation
      • Add configuration option to select generation method
      • Implement feature flag system for gradual rollout
      • Create migration utilities for custom templates
      • Add validation to ensure output parity between approaches
      • Document migration path for users with custom templates
    • Acceptance:
      • Existing CLI commands work without changes
      • Template-based generation remains available as fallback
      • Configuration option allows selection of generation method
      • Migration utilities successfully convert common template customizations
      • Output validation confirms identical results between approaches
      • Documentation provides clear migration guidance

  • TASK-068d: Enhanced testing for programmatic generation

    • Context: Comprehensive testing framework for programmatic markdown generation
    • Requirement: F026 (Testing), Testing Standards
    • User Story: US-020-US-021 (Testing and Validation)
    • Action:
      • Create comprehensive unit tests for each section builder
      • Implement integration tests comparing template vs programmatic output
      • Add property-based testing for edge cases
      • Create performance regression tests
      • Implement golden file testing for output validation
      • Add memory leak detection tests
      • Create stress tests with large configuration files
    • Acceptance:
      • Test coverage for programmatic generation exceeds 90%
      • Integration tests validate output parity with templates
      • Performance tests catch regressions automatically
      • Golden file tests ensure consistent output format
      • Memory tests detect potential leaks or excessive allocations
      • Stress tests validate performance with realistic workloads

This task checklist should be updated as implementation progresses and new requirements are identified.