Renovate runs as a daily Gitea Actions cron (03:00 UTC, on
self-hosted runners) and opens PRs against main for dependency
updates. Picked daily-at-3am specifically so Monday's run sits
inside Renovate's default `lockFileMaintenance.schedule` ("before
4am on Monday") and triggers the weekly lockfile refresh in passing.
The workflow only handles invocation + Gitea-platform plumbing.
Bot behaviour (groupings, labels, Conventional Commits, OSV.dev
vulnerability source) lives in /renovate.json so it can evolve
without redeploying the workflow.
Groups defined: Angular, Nx, NestJS, Prisma (incl. nestjs-prisma),
Vitest, TypeScript tooling, ESLint, SWC, Tailwind. Standalone
packages get individual PRs.
Bot identity: a dedicated `apf-portal-bot` Gitea user authenticates
with a PAT stored as the RENOVATE_TOKEN repo secret. The full
onboarding procedure (user creation, scopes, secret) is documented
in docs/development.md → "Dependency updates (Renovate)".
The roadmap entry for Renovate is removed from §8 since the section
now exists.
Formalise the PR-flow conventions while we install the PR-flow itself.
.gitea/pull_request_template.md auto-populates the PR body in Gitea
with five sections: Summary / Motivation / Implementation notes /
Verification (with CI-gate checkboxes + ADR/diagram update flags) /
Related. Sections can be left blank when irrelevant; the template
guides without adding ceremony. Header HTML comment reminds the
contributor of the PR title format and links to the full convention.
docs/development.md §5 (Conventional commit cycle) gains a 'PR
conventions' subsection that:
- explains why the PR title format matters (squash-merge subject on
main, validated by commitlint in the CI 'commits' job)
- separates feature-branch commit hygiene (exploratory OK) from PR
title hygiene (must conform)
- documents the type vocabulary (feat/fix/docs/style/refactor/perf/
test/build/ci/chore/revert)
- proposes an optional scope vocabulary (apps, libs, cross-cutting
domains like decisions/docs/ci/deps)
- describes the body template
No new ADR. The PR title format is derived from ADR-0007 (Conventional
Commits at the commit-msg layer) plus ADR-0015 (squash-merge means PR
title becomes the commit subject on main). The body template is
tactical guidance, not architectural.
The section was a short bullet list of 'sections to be added' - it
underplayed how broad the future content really is, and gave no
visibility on what triggers each. Replace it with a structured table
that maps every planned section to (a) its ADR phase and (b) the
specific implementation work that unlocks it. A contributor reading
the doc today now sees:
- which dev-loops will exist (auth, sessions, MFA step-up, OTel,
audit, downstream APIs, component patterns, a11y, perf debugging,
Renovate, release, GitLab migration, architecture diagrams)
- under which ADR each lands
- what concrete event in the codebase makes each section real
Plus the explicit policy: each entry stays a subsection of this doc
until we have at least three substantial sub-topics, at which point
the file is split into docs/development/ with an index. Avoids
creating empty placeholder files (per CLAUDE.md: 'documentation when
genuinely useful, not just to tick a box') while signalling the
future structure clearly.
Cross-references each row to its triggering ADR so the table doubles
as a 'what's pending implementation' radar. Foreshadows the §7 → file
split that will happen once content density justifies it.
A new contributor (or returning lead) opening the repo gets:
- the final repo layout, with one-line annotations per top-level dir
- the prerequisite tooling list (Node 24 LTS, pnpm 10, mkcert,
optional local Trivy/gitleaks, Docker for Postgres)
- the fresh-clone setup steps (clone, pnpm install, prisma generate,
sanity check)
- the daily commands organised by intent: serve, test (incl. single
file), lint, build, generate (apps / libs / components), Prisma,
the four ci:* scripts that mirror the CI gates
- the conventional commit cycle end-to-end (branch naming, hook
enforcement, PR gates, squash-merge, release tagging)
- a 'where to look' table cross-linking the project rules
(CLAUDE.md), the ADRs, the setup guides, and the personal notes
- an explicit 'to be added' section listing what the doc will grow
into (local infra Docker Compose, auth dev-loop, component
patterns, debugging tips, release workflow, Renovate policy)
The doc is intentionally non-exhaustive at v1 - it captures what a
contributor needs today and is structured to grow as the workflow
sharpens. Indexed in docs/README.md under a new 'Daily development'
section, separate from the one-off onboarding guides under
docs/setup/.
Julien Gautier