Actions
Local composite actions under .gitea/actions/ capture reusable orchestration steps, while the logic they orchestrate stays in the build system.
.gitea/actions/
3Trait
A minimal layer of wiring that composes behaviour defined elsewhere.
Local composite actions under .gitea/actions/ capture reusable orchestration steps, while the logic they orchestrate stays in the build system.
.gitea/actions/
3.gitea/ is the repository’s automation control folder: event-driven workflows and local actions that orchestrate the repository’s own commands.
.gitea/
2A 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
2An identical root Makefile in every repository, with the repository’s own components declared once in scripts/build/repository.mk.
Makefile
4Thin, canonical deployable roots under env/ that compose reusable modules for a concrete deployment target and run without ad hoc parameters.
env/
4Host-side hooks that run before the container is built or created, preparing only the files and directories the container definition expects.
.devcontainer/lifecycle/initialize.d/
2One aggregate lint command runs every linter that is installed, skips the rest with a clear message, and fails only on real findings.
scripts/lint.sh
4Every deployable root composes the same published module at the same pinned version, so roots differ only in backend, domain, and credentials.
env/
3Human-facing hooks that run each time a developer or editor attaches — short guidance, actionable warnings, and pointers to interactive sign-in.
.devcontainer/lifecycle/post-attach.d/
3Each fact is stated once, where it is maintained, and every other place that needs it points there instead of keeping a copy.
./
2One small runner turns each lifecycle event into a directory of .sh hooks, run in lexical order and stopped by the first failure.
.devcontainer/lifecycle/
1Narrow, deterministic command helpers for make modules, CI, and local tooling — glue that takes its inputs from the caller and leaves orchestration to it.
scripts/
4Workflow YAML decides when automation runs and in what order, and hands the work itself to stable repository commands and reusable actions.
.gitea/workflows/
4No specification matches every filter.