File discovery — recursive scan, file name, path, size, last-modified date (FR-001) Format detection — extension + content inspection (XML namespace, root element, magic bytes) (FR-002) Format mismatch detection — file claims to be one format but content says otherwise (FR-003) Well-formedness validation — is the XML parseable at all? Malformed = blocker (FR-007) Internal cross-reference resolution — follow href/xref links within the repository, classify as valid / relocated / ambiguous / broken (FR-008, FR-032/033) Metadata inventory — extract and list all elements/attributes found, grouped by name with unique values (FR-009) Analysis depth labelling — report explicitly states "structural baseline" was applied so the user knows the limits (FR-005)
XML Input Cleaning Accepts raw customer XML exports — DITA, DocBook, S1000D, or generic XML — and normalises them to a clean, well-formed, platform-compliant DITA 1.3 baseline. Responsibilities include resolving vendor-specific constructs and proprietary namespaces, correcting NCName-invalid element and topic IDs, detecting and repairing encoding inconsistencies (UTF-8, UTF-16, ISO-8859-1), and flagging or stripping any constructs that have no DITA 1.3 equivalent. Output is a structurally valid repository that can enter the Migration Analyser without pre-processing failures. Operates before analysis; its success gate is the analyser's well-formedness check (FR-007).
This feature delivers repository graphics auditing and a browser-based dashboard for viewing, filtering, and comparing migration analysis runs. It solves the operational problem of turning raw migration findings into reusable assessment outputs suitable for migration planning, customer discussions, and iterative remediation tracking. The implementation adds image analysis capabilities that inspect repository graphics, detect issues such as low DPI and orphaned assets, and connect image usage metadata back to content references discovered during analysis. It also builds a Flask-based dashboard with HTML templates, lightweight JavaScript interactions, comparison views, and CLI integration so stored reports can be explored without additional tooling. The dashboard must support grouped work package views, verdict summaries, finding filtering, pagination, graphics summaries, and comparison deltas while remaining dependency-light and reproducible. Graphics analysis acceptance depends on correctly building referenced-by relationships across DITA, HTML, and Markdown content so orphan detection and audit reporting remain accurate.
This feature delivers the migration readiness analysers for DITA repositories and unstructured source formats, covering the primary migration assessment workflows described in the specification. It solves the business problem of rapidly identifying migration blockers, reuse complexity, topic structure, and remediation effort across both structured and document-centric repositories. The implementation builds dedicated DITA analysis services for map traversal, key resolution, specialization handling, and repository-wide orchestration, then extends the pipeline with Markdown, HTML, Word, and PDF analysers. The CLI routing layer dispatches files to the correct analyser while shared scoring and reporting aggregate findings into a unified readiness report. Supporting fixtures and integration tests validate realistic repositories with planted issues and ensure machine-readable reports remain consumable. Special attention is required for DITA-specific acceptance criteria including circular map detection, undefined keys, conref validation, ID collisions, reuse metrics, profiling attributes, orphaned topics, and relocated references. Unstructured analysers must also surface topic candidates and manual-splitting indicators because these metrics directly influence migration complexity scoring and proposal estimates.
All tasks from /home/axelbender/platform/Platform/specs/065-migration-analyser
This feature delivers the reusable repository analysis engine that discovers content, indexes repositories, resolves references, computes migration readiness scoring, and produces normalized reports. It solves the core technical problem of analyzing heterogeneous repositories consistently before format-specific logic is applied. The implementation introduces engine-layer services for file discovery, repository indexing, reference resolution, scoring, and report generation together with analyser abstractions and universal baseline XML analysis. These components are wired into the analyse command so format analysers can share repository metadata, findings, and scoring behavior. The work also includes engine-level tests validating relocated references, broken targets, malformed XML handling, and scoring thresholds. Acceptance depends heavily on edge-case handling defined in the specification, especially distinguishing relocated references from broken references and preserving source path information for findings. The scoring pipeline must map blocker and warning findings into deterministic readiness verdicts because downstream proposal generation and dashboard summaries rely on stable classification behavior.
This feature establishes the base package structure, shared data models, configuration system, work package persistence, and developer tooling needed for all analyser capabilities. It solves the foundational problem of creating a reproducible, scriptable migration analysis tool with stable report contracts and CLI entry points. The implementation builds the Python package layout, dependency management, CLI scaffolding, serialization-safe report dataclasses, enums, configuration loading, and persistent work package registry. It also introduces baseline tests, repository fixtures, README documentation, and coverage enforcement so later analysers and dashboard components can integrate against stable interfaces. The work spans packaging, models, persistence, test infrastructure, and command-line orchestration. Implementers must preserve JSON round-trip compatibility for machine-readable output and ensure enum serialization remains stable because downstream Platform Bulk Import tooling depends on predictable schemas. Memory efficiency matters for large repositories, so the dataclass slot usage and persistence semantics are part of the acceptance boundary.