Skip to content

Add rendered-document link validator for generated architecture outputs #35

Description

@dieterbaier

Problem

The traceability issue in dieterbaier/profile shows that metamodel validation and AsciiDoc generation can succeed while the final rendered architecture document still contains broken links. The deployed page at https://architecture.dieterbaier.eu/ is a single-page HTML document, but its traceability matrix contains relative .html#anchor links to files that are not deployed.

A validator that checks the rendered target document would catch this class of problem after generation/rendering, independent of whether the broken links came from traceability, hand-written xrefs, generated indexes, or includes.

Desired capability

Provide a toolkit validator that can check a rendered architecture target, especially single-page HTML output.

It should detect at least:

  • same-document hash links whose target anchor/id is missing;
  • relative local links to files that do not exist in the rendered output directory;
  • relative local links with fragments where the file exists but the fragment target is missing;
  • generated traceability links that accidentally point back to source-oriented .html#... paths in a single-page output.

External HTTP links can be a later or optional mode; the first useful slice can stay local/offline.

Suggested interface

Examples:

  • CLI/script entry point, e.g. validate-rendered-links --root build/architecture --entry index.html;
  • Gradle task integration in consuming projects;
  • deterministic output suitable for CI.

Acceptance criteria

  • The validator fails on a rendered HTML file containing a link to a missing local file.
  • The validator fails on a hash link whose target id/anchor is missing.
  • The validator passes valid same-page anchor links.
  • The validator can be wired into a consuming project such as dieterbaier/profile after buildArchitecture.
  • Documentation explains the intended scope: rendered-output validation, not source metamodel validation.

Related consuming-project integration should use the same approach once available.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions