wanjakrah/landscape
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

S19: establish landscape repository

Browse Source
This commit is contained in:
Wanja Krah
2026-11-08 15:15:53 +01:00
commit c30897ec94
30 changed files with 2947 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
onboarding.md Normal file
View File

@@ -0,0 +1,33 @@
# Start and maintain a project
1. Read applicable approved ADRs and specifications. Add the intended system and
its responsibilities to systems.md; identify affected repositories in its
specifications. Decide data ownership and deployment boundaries explicitly.
2. Create a Gitea repository under the appropriate owner. Choose visibility
deliberately. Configure Actions and an available host runner with JDK 25,
Maven, Git, Python 3, Docker/Compose and Node/npm when a frontend is selected.
3. Clone [engineering](http://192.168.2.28:3000/wanjakrah/engineering) and check out
a released version. Follow its README to run create-project.py with a project
name, destination, backend/frontend/both selection, release tag and runner label.
4. Review generated project-owned files, module paths, Compose project and image
namespace. Configure deployment targets, readiness and any required dependency
services. Keep secrets outside Git. Follow engineering's Gitea setup and
deployment instructions for registry, release and SSH credentials.
5. Verify the engineering lock records both tag and full commit. Commit generated/
with the local bootstrap and Maven profile. Confirm a fresh checkout builds
and that the bootstrap can reconstruct an absent generated/ directory.
6. Initialize and push the application repository, run its build workflow, and
inspect diagnostics. Validate deployment/rollback in an isolated environment
before a separate manual production deployment.
7. Keep implementation and operational instructions in the application's README.
Link README and AGENTS to this landscape and pinned local engineering guidance.
Keep executable tests, fixtures and implementation validation evidence there.
For engineering upgrades, choose a released tag, record its commit, follow that
release's UPGRADING.md, regenerate and review the diff before committing. Only
generated/ is replaced automatically; templates do not overwrite project-owned
files on upgrades. CI checks that generated content matches the chosen release.
Local checkouts conventionally live under `~/Projecten/git/`; consumers do not
depend on those sibling directories. Landscape documentation is consulted at its
current revision. Source attribution and licenses must accompany copied resources.