The recurring structures, orchestration patterns, behavioural contracts, lifecycles, and conventions encoded across AureliaSRS repositories — each one a page you can explore, and every page connected to its neighbours.
Each child of www/ is a self-contained site root whose content, layouts, assets, and configuration travel together and whose output is disposable.
www/
3
The home for static and content-driven websites: one directory per site under www/, each holding everything it needs to build, and each rendered into the single shared public/ output.
Repository documentation is staged from docs/ into .cache/docs-site/ and mounted into a Hugo site, so the docs stay where they are owned.
.cache/docs-site/
2
A two-step bridge between plain Markdown documentation and a Hugo site: a preparation script copies docs/ into a disposable staging directory with front matter added, and Hugo module mounts publish that directory beneath the site’s own content.
Thin, canonical deployable roots under env/ that compose reusable modules for a concrete deployment target and run without ad hoc parameters.
env/
4
The directory of canonical deployment targets: one readable root per logical deployed unit and tier, wiring reusable modules to the configuration that a specific continuous-deployment target needs.
Every deployable root composes the same published module at the same pinned version, so roots differ only in backend, domain, and credentials.
env/
3
An arrangement in which the whole infrastructure pattern lives in one published module, and each environment’s root is a thin wrapper that calls it at the same version with only its backend, domain, and credentials changed.
Small, focused infrastructure building blocks with explicit inputs and outputs, consumed by deployable roots in env/ and workspaces/.
modules/
3
The directory of reusable infrastructure local to a repository: composable implementation details that deployable roots wire to concrete targets, with every environment-specific value exposed as an input.
Developer-oriented deployment roots under workspaces/ whose instance identity may come from the current user or branch, kept apart from canonical environments.
workspaces/
3
The directory of non-canonical deployment entry points — local, sandbox, and user-derived systems — that compose the same modules as env/ but may depend on developer context to name the instance.
The authoritative development environment for a repository — reusable features provide the toolchains, and repository-specific lifecycle hooks finish the workspace.
.devcontainer/
4
A container definition, following the Development Containers specification, that provisions every tool, runtime, service, and utility needed to work on the repository, so a fresh rebuild is ready for development without manual bootstrapping.
Six ordered hook phases that take a development container from host-side preparation to an attached, ready workspace.
.devcontainer/lifecycle/
8
The repository-specific provisioning layer of a development container: one hook directory per Dev Container lifecycle command, each run in lexical order by a shared runner.
An identical root Makefile in every repository, with the repository’s own components declared once in scripts/build/repository.mk.
Makefile
4
The repository’s stable set of make commands: a generic, managed root Makefile that loads repository configuration and then a fixed sequence of make modules, so the same verbs work the same way in every repository.
Narrow, deterministic command helpers for make modules, CI, and local tooling — glue that takes its inputs from the caller and leaves orchestration to it.
scripts/
4
The home for repository scripts: behaviour too large or awkward for a make recipe, given a clear entry point while the caller decides when and with what inputs it runs.
Make modules register their targets and requirements into shared lists, and aggregate targets are composed from whatever registered.
scripts/build/
5
How independent make modules contribute to repository-wide commands without editing them: each module appends to a registry variable, and the aggregate targets expand those registries after every module has loaded.
Repository tooling with stable command entry points and documented contracts — small applications that own a workflow, rather than glue around one.
tools/
2
The home for reusable command implementations — local development, CI, validation, generation, and maintenance utilities — that have clear inputs, outputs, execution flows, and a contract documented beside the code.
A single .linter/ directory holds the repository’s own lint configuration and overrides, layered over organisation defaults from the environment.
.linter/
2
The standard location for repository-owned linter configuration: one file per tool, kept out of the repository root and loaded by path from the development container and CI.
.gitea/ is the repository’s automation control folder: event-driven workflows and local actions that orchestrate the repository’s own commands.
.gitea/
2
The control folder for Gitea Actions: workflow definitions that say when automation runs, and local reusable actions that share orchestration steps, with the actual work kept behind stable repository commands.
Workflow YAML decides when automation runs and in what order, and hands the work itself to stable repository commands and reusable actions.
.gitea/workflows/
4
Gitea Actions workflow definitions for CI, packaging, publishing, deployment, and maintenance, written as orchestration over repository commands rather than as an implementation of them.
Local composite actions under .gitea/actions/ capture reusable orchestration steps, while the logic they orchestrate stays in the build system.
.gitea/actions/
3
A consistent, repository-local path for Gitea composite actions: small units of orchestration — inputs, outputs, ordered calls — that several workflows can share without copying steps between files.
docs/pdlc/ holds the durable product context behind a repository — problems, constraints, tradeoffs, and decisions — and nothing short-lived.
docs/pdlc/
2
The repository-specific materials that fit within the Product Development Life Cycle: focused documents that explain why the repository exists and what should guide its future changes.
Architecture decision records are a last resort, written only when the repository’s structure, code, tests, and owner documentation cannot make a choice clear.
docs/pdlc/decisions/
2
When and how a separate decision record is written: a short, numbered ADR copied from a template, whose “Repository Expression” section points back to the files that make the decision visible in practice.
Machine-readable repository identity that tells catalog systems what a repository is and produces, and where the authoritative definitions live.
.descriptor/
2
A dedicated directory of generic, repository-owned metadata files describing a repository and the artifacts and resources it produces, with references to their sources of truth.
A generated CODEMAP.md that says what each area of the repository is for and which local README to open next — a navigation guide, not a reference.
CODEMAP.md
2
A single generated page at the repository root that shows the expected shape of the tree, gives a quick lookup from concern to directory, and points each area at its own owner documentation.
The authoritative development environment for a repository — reusable features provide the toolchains, and repository-specific lifecycle hooks finish the workspace.
Every change moves through the same Build → Test → Publish pipeline locally, on the pull request, and on merge, ending in a deployment only where there is one.