[ViPPET] docs: refactor visual-pipeline user guide into consolidated structure

[Copilot]

Description

Consolidated 11 documentation files into 4 organized Markdown files with standardized naming, removed architecture diagram and references, and created unified index.rst at tool root.

File Structure

Before: 11 scattered files (Overview.md, disclaimers.md, release-notes.md, get-started.md, system-requirements.md, how-to-build-source.md, how-to-use-video-generator.md, known-issues.md, api-reference.md, docs/user-guide/index.rst, _assets/architecture.png)

After: 4 consolidated files with hyphenated lowercase names:

• getting-started.md - Overview, use cases, features, disclaimers, complete release notes with known issues/limitations
• installation.md - Prerequisites, Docker Compose deployment, building from source, video generator, troubleshooting
• usage.md - Pipeline editing, device selection, DLSOptimizer usage, performance/density testing
• api-reference.md - Enhanced with access instructions

Key Changes

• Split "known issues & limitations" by scope: release-scoped items → getting-started.md, installation/runtime troubleshooting → installation.md
• Removed architecture.png and all references (README.md, Overview.md, index.rst)
• Created index.rst at tool root with reStructuredText content and toctree linking to new docs
• Updated README.md to match getting-started.md structure
• Added acronym definitions on first use (ViPPET, DLSOptimizer)
• Standardized version references to release-2025.2.0

Validation

• All files pass markdownlint with repository config
• Non-code lines within 120 character limit
• index.rst validated as valid reStructuredText
• Internal links functional, no broken references

Any Newly Introduced Dependencies

None.

How Has This Been Tested?

# Markdownlint validation
markdownlint -c .markdownlint.yml README.md docs/user-guide/*.md

# RST syntax validation
python3 -c "from docutils.core import publish_doctree; publish_doctree(open('index.rst').read())"

# Reference validation
grep -r "architecture\.png" tools/visual-pipeline-and-platform-evaluation-tool/
grep -r "system-requirements\|get-started\|Overview\.md" tools/visual-pipeline-and-platform-evaluation-tool/

Checklist:

• I agree to use the APACHE-2.0 license for my code changes.
• I have not introduced any 3rd party components incompatible with APACHE-2.0.
• I have not included any company confidential information, trade secret, password or security token.
• I have performed a self-review of my code.

Original prompt

Create a Pull Request that refactors and reorganizes the documentation located in:
tools/visual-pipeline-and-platform-evaluation-tool/docs/user-guide

Goal

• Reorganize, format, and consolidate the existing documentation into four Markdown files (structure below).
• Remove unnecessary files.
• Rename remaining files to lowercase with hyphens instead of spaces.
• Preserve the original technical content and meaning. Only make minimal edits to fix obvious grammar/typos using simple technical English if strictly necessary.
• Ensure all Markdown follows markdownlint rules defined at:
  /tools/visual-pipeline-and-platform-evaluation-tool/.markdownlint.yml
• Remove architecture.png and all uses/references to it throughout:
  /tools/visual-pipeline-and-platform-evaluation-tool/

Requirements (detailed)

1. Target output: four Markdown files with hyphenated lowercase filenames

   • getting-started.md
     • Sections:
       • Overview
         • Add a "Disclaimers" subsection at the end of Overview
       • Release Notes
         • Include "release known issues & limitations" here (see splitting rule below)
   • installation.md
     • Sections:
       • Prerequisites
       • Option 1: Docker Compose Deployment
       • Option 2: Building from source
       • Optional: Building Video Generator
       • Installation troubleshooting
   • usage.md
     • Sections:
       • Editing pipelines in Pipeline Builder
       • Running performance tests
       • Running density tests
   • api-reference.md

   Note: The existing combined "Known issues, limitations and troubleshooting" must be split:

   • "Known issues & limitations" (release-scoped, or "release-known issues") goes under Release Notes in getting-started.md.
   • "Troubleshooting" (installation/runtime troubleshooting) goes under Installation -> Installation troubleshooting in installation.md.

2. Content handling and formatting

   • Do not change technical meaning. If a change is unavoidable (broken sentences, obvious typos), correct it using simple, direct technical English and keep edits minimal.
   • Convert formatting so markdown is valid: headings, code blocks, lists, inline code, tables, blockquotes must be preserved or converted appropriately.
   • Ensure no Markdown line exceeds 120 characters.
   • Run and fix issues reported by markdownlint configured at:
     /tools/visual-pipeline-and-platform-evaluation-tool/.markdownlint.yml

3. Filenames, links and references

   • Rename files to lowercase-with-hyphens and update all internal relative links accordingly so they continue to resolve.
   • Preserve referenced images and other assets except architecture.png, which must be removed and all references to it deleted.
   • If removing a file breaks references outside this directory, update those references as part of the PR or list the broken references and propose how to fix them in the PR description.

4. index.rst

   • Update /tools/visual-pipeline-and-platform-evaluation-tool/index.rst to contain the same content as the new getting-started.md expressed in reStructuredText (reST).
   • Keep the same structure and prose, converted to valid reST.
   • At the end of index.rst include a toctree that links to all remaining documentation files (converted or referenced appropriately) and include an external link to:
     https://github.com/open-edge-platform/edge-ai-libraries/tree/main/tools/visual-pipeline-and-platform-evaluation-tool

5. README.md

   • Replace the content of /tools/visual-pipeline-and-platform-evaluation-tool/README.md with the same content as the new getting-started, adjusting relative paths/links as appropriate for a repository-root README.

6. Cleanup and removed files

   • Remove architecture.png and delete every reference to it anywhere under:
     /tools/visual-pipeline-and-platform-evaluation-tool/
   • Remove other clearly-unused files from the original user-guide directory if they are truly unused. List all removed files in the PR description with a brief reason for removal.
   • Do NOT remove files that are referenced elsewhere in the repo unless you also update those references in this PR.

7. Quality checks and validation

   • Run markdownlint with the repository config (/tools/visual-pipeline-and-platform-evaluation-tool/.markdownlint.yml) and resolve any issues reported.
   • Ensure no Markdown line exceeds 120 characters.
   • Validate index.rst as valid reStructuredText (run a Sphinx build or reST linter to catch syntax problems).
   • Verify that internal relative links and image paths resolve within the repository.

8. Branch, commits and PR conventions

   • Create a branch named: docs/reformat/visual-pipeline-user-guide (or a similarly clear name).
   • Suggested PR title: "docs: reformat visual-pipeline user guide"
   • PR description must include:
     • Summary of changes (short).
     • Before / after file tree for the docs folder.
     • Full list of removed files with reasons.
     • Commands used to validate (e.g., ...

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.