3.5 Repository Baseline [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.
====== 3.5 Repository Baseline ======

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

[[fxdemo:05-part:03-phase-0-baseline:start | Return to Phase 0 Baseline ]]

The [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] defines the initial structure, naming discipline, generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifact]] locations, script locations, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] locations, source locations, test locations, and documentation locations for Phase 0.

The team uses the Repository Baseline to ensure that every developer works from the same structure. Developers should not create new top-level directories, naming patterns, generated file locations, or script conventions without an explicit reason and a corresponding update to the handbook or Repository documentation.

The Repository Baseline should separate handwritten source files from generated Artifacts. It should also separate architecture-facing documentation, developer-facing documentation, Configuration, [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] definitions, build scripts, test Artifacts, logs, and runtime outputs. This separation protects reviewability and prevents generated or temporary Artifacts from becoming confused with [[dido:99_annexes:annex-b-terms-and-definitions:g:governed|Governed]] source material.

The Repository Baseline also defines what [[dido:99_annexes:annex-b-terms-and-definitions:g:git|Git]] should track and what Git should ignore. Source definitions, scripts, Configuration templates, documentation, tests, and reproducible generation inputs should normally enter [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]]. Local environment files, transient logs, build outputs, generated temporary files, and machine-specific settings should normally remain outside Version Control unless the team explicitly decides otherwise.

----

<WRAP centeralign>

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

</WRAP>