# ADR 000007 Repository Architecture GitBook **Date:** May 2026\ **Status:** Accepted\ **Decider:** NikiDigitals\ **Version:** GitBook — Thinking Layer *** ## The Question A project spanning five years, fifteen repositories, thirteen functional modules, and a full portfolio layer requires a clear answer to a foundational question before a single file is committed: how is the codebase structured, and why? This is not a trivial decision. The repository architecture is the skeleton of the entire project. Get it wrong and every subsequent build session fights the structure. Get it right and the architecture becomes invisible — it simply works, at every scale, for as long as the project runs. ## The Decision All repositories sit directly under the NikiDigitals personal GitHub account at github.com/NikiDigitals. No GitHub Organisation is used. Fifteen repositories are established — one per functional module, plus master, infrastructure, portfolio, API, and core components. Every repository follows the same internal folder structure. Every repository uses the same naming convention: `LES-[UPPERCASE]`. Every repository is private by default, with one exception — the LES master repository is public, serving as the project's public face on GitHub. ## Why One Account, Not an Organisation A GitHub Organisation adds a layer of administrative overhead that is not justified at this stage. The project has one owner, one identity, and one professional brand. NikiDigitals is that identity. Splitting the repositories into an Organisation beneath it creates navigation complexity without adding capability. If the project scales to involve collaborators or becomes a multi-team effort, migrating to an Organisation is straightforward — the repository names and structures do not change. ## Why Fifteen Repositories The principle is separation of concerns — the same principle that governs how real enterprise systems are architected. Each module of LES has a distinct data model, distinct business logic, and a distinct lifecycle. Keeping them in separate repositories means each one can be versioned, documented, and developed independently. A change to LES-FIN does not touch LES-HLT. A problem in LES-AGT does not contaminate LES-SEC. The operational repositories — INFRASTRUCTURE, API, CORE — are separated from modules because they serve all modules. They have no single owner. They belong to the system as a whole. ## Why Consistent Structure Matters Over five years, repositories accumulate. Documents multiply. Contributors may join. The only thing that scales reliably is consistency. A developer — or a future version of the project owner — opening any LES repository for the first time should know exactly where to find the architecture documents, the decision records, the governance frameworks, and the working drafts. Not because they read a guide, but because every repository is the same. That consistency is enforced from day one, in the founding session, before a single module is built. Retrofitting structure onto a system already in motion is exponentially harder than building it correctly from the start. --- # 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/decision-log/phase-0-foundation/adr-000007-repository-architecture-gitbook.md?ask= ``` 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.