# 000001 GitHub Infrastructure GitBook

**Date:** May 2026\
**Status:** Active — Phase 0\
**Owner:** NikiDigitals\
**Version:** GitBook — Thinking Layer

***

## Overview

Before any module of LES is built, before a single line of infrastructure code is written, the GitHub architecture must be correct. Repository structure is the skeleton of the project. It determines how work is organised, how documentation is found, how modules relate to each other, and how a technical audience experiences the project when they encounter it for the first time.

This document describes the GitHub infrastructure architecture established at the founding of LES — the repository structure, internal folder conventions, naming standards, and the reasoning behind each decision.

## The Repository Set

Fifteen repositories sit under github.com/NikiDigitals. They divide into four categories:

* **Master repository** — `LES` — the public face of the project on GitHub. Contains architecture documentation, governance frameworks, decision records, research, and the project journal. This is the repository a technical visitor opens first. It is public.
* **Operational repositories** — `LES-INFRASTRUCTURE`, `LES-API`, `LES-CORE`, `LES-PORT` , `LES-DASH` , `LES-DEMO`  —  components that serve all modules. Infrastructure holds all Azure resource definitions. API holds the central gateway layer. Core holds shared libraries and utilities used across modules. Portfolio holds the NikiDigitals website documentation.
* **Module repositories** — one per functional module of LES. Each module is independently versioned and documented. A change in one module does not affect any other.
* **Security repository** — `LES-SEC` — simultaneously a functional module and a cross-cutting concern. The security architecture defined here is referenced and implemented across all other repositories.

## The Universal Folder Structure

Every repository follows the same internal structure without exception:

```
LES-[MODULE]/
├── README.md
├── docs/
│   ├── architecture/
│   │   └── diagrams/
│   ├── decisions/
│   ├── governance/
│   ├── research/
│   └── roadmap/
├── journal/
└── TEMPLATE.md
```

Each folder in `docs/` contains a `TEMPLATE.md` showing the expected format for documents in that folder. This is not documentation about documentation — it is a practical tool that makes writing the next document faster and more consistent.

## Why Consistency Is the Design Principle

The universal structure is not aesthetic preference. It is an architectural decision with a specific consequence: anyone opening any LES repository — whether they last worked in it yesterday or six months ago — knows exactly where to look for everything. No orientation time. No searching. No inconsistency that accumulates into confusion.

Over five years, repositories multiply. Contributors may join. The project owner's own memory of where something was put will fade. The structure is the answer to all of those problems, and it costs nothing to maintain once it is established — as long as it is established correctly from the start.

## The Naming Convention

All repositories follow `LES-[UPPERCASE]`. All documents follow the six-digit taxonomy: `ADR-000001`, `LES-ARCH-000001`, `LES-JOUR-000001`. Six digits because the project runs for five years and generates significant documentation volume. A numbering scheme that runs out is worse than one that seems excessive at the start.

## What Comes Next

This architecture is established at Phase 0 and maintained without modification unless a new ADR supersedes it. The folder structure is built across all fifteen repositories as part of the Phase 0 setup. The templates are written once and applied everywhere. From that point, the architecture is invisible — it simply supports the work.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://nikidigitals.gitbook.io/les/03-architecture/architecture-overview/000001-github-infrastructure-gitbook.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.