6.7 Tool Baseline Checklist [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 6.7 Tool Baseline Checklist ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:06-prerequisites-and-tooling:start | Return to Prerequisites and Tooling ]]

The handbook defines a static tool [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] checklist that the team uses to record and verify the tools required for a particular phase, build, release candidate, test run, demonstration Baseline, or deployment Baseline. The checklist structure should remain stable across phases so that the team can compare tool Baselines without rewriting the handbook for every implementation cycle.

The checklist should identify each tool category that may affect [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] access, source generation, build execution, [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] execution, validation, review, acceptance [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], or deployment. The checklist should treat each tool category as a required capability, not necessarily as a single product selection. This allows the team to support one approved tool, several approved tools, or several interoperable implementations for the same capability.

Each checklist item should capture:

  - Tool category.
  - Approved product, platform, or implementation.
  - Vendor, project, or source.
  - Required version or acceptable version range.
  - Product status.
  - Required, recommended, optional, experimental, not applicable, or to-be-decided classification.
  - Applicable role or environment.
  - Phase, build, test, demonstration, or deployment purpose.
  - Installation or setup reference.
  - Verification command or validation method.
  - Observed version, where the checklist instance records a completed verification.
  - Verification result in which the checklist instance records a completed verification.
  - Evidence reference, where the checklist instance links to supporting logs, command output, screenshots, reports, or review notes.
  - Owner or responsible role.
  - Related implementation decision record, where applicable.
  - Exceptions, constraints, or open risks.

The checklist should use a consistent version-range convention. Version expressions should support exact versions, bounded ranges, open-ended ranges, exclusions, and not-applicable values.

Representative version expressions include:

  - Exact version: ''21.0.2''
  - Minimum version: ''>= 21''
  - Compatible range: ''>= 21, < 22''
  - Open-ended range: ''>= 3.12''
  - Excluded version: ''>= 3.12, != 3.12.1, < 3.13''
  - Not applicable: ''N/A''
  - To be decided: ''TBD''

The team should prefer bounded ranges when tool behaviour, generated output, runtime compatibility, or acceptance Evidence may change across major versions. The team may use open-ended ranges when the tool has stable backward compatibility or when the phase-specific checklist identifies the risk.

The static checklist should cover at least the following tool categories:

  - Repository platform.
  - Version control.
  - Shell environment.
  - Editor or IDE.
  - Java environment.
  - Python environment.
  - [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] vendor and toolset.
  - [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] compiler or type generator.
  - Container runtime.
  - Build tool.
  - Package manager.
  - Test and validation tools.
  - Documentation generation tools.
  - Diagram or model export tools, where applicable.
  - Security, signing, credential, or secret-management tools, where applicable.
  - Operating-system assumptions.
  - CI/CD or automation runner environment, where applicable.

The checklist should also distinguish applicable roles and environments. A tool may apply to developers, testers, technical reviewers, CI automation, demonstration operators, release managers, documentation maintainers, or deployment environments.

Representative role and environment categories include:

  - Developer workstation.
  - Tester workstation.
  - Technical reviewer workstation.
  - Demonstration operator workstation.
  - CI runner.
  - Local container runtime.
  - Demonstration runtime environment.
  - Deployment runtime environment.
  - Documentation build environment.
  - Release or Evidence-collection environment.

Role classification prevents the team from requiring every participant to install every tool. A developer may need Git, Java, Python, DDS tooling, a container runtime, build tools, and validation tools. A tester may need Git, a container runtime, test-execution tools, and log-inspection tools. A technical reviewer may need Git, documentation tools, and enough runtime tooling to reproduce acceptance Evidence. A deployment environment may need only runtime [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]], container runtime support, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]], credentials, and monitoring tools.

The checklist structure should support later automation. A completed checklist instance should contain enough information to help the team create setup scripts, such as Homebrew commands for macOS, package manager commands for Linux, Windows installation notes, container build prerequisites, CI runner images, or deployment environment preparation scripts. The checklist should not require those setup scripts to exist immediately; it should capture tool names, version ranges, installation references, and verification commands in a format that automation can later use.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>