No CI job ever builds docs/ — the `documentation` branch this repo triggers on does not exist

[rubenvdlinde]

Symptom

docs/ was unbuildable on development and nothing reported it for as long as it has been broken. Found while verifying dependabot #4; fixed in #63.

npm error `npm ci` can only install packages when your package.json and
npm error package-lock.json are in sync.
npm error Invalid: lock file's @conduction/docusaurus-preset@3.10.0
npm error          does not satisfy @conduction/docusaurus-preset@3.12.0

npm ci exit 1 → npm run build exit 127 (docusaurus: not found).

Cause

.github/workflows/documentation.yml is the only job that touches docs/, and it fires only on a branch named documentation:

on:
  push:
    branches: [documentation]
  pull_request:
    branches: [documentation]

That branch does not exist in this repo.

$ git ls-remote origin refs/heads/documentation
(no output)

A workflow whose only trigger is a non-existent branch never runs. So docs/ has no build coverage on development, beta, main, or any PR — a docs change here can be merged in any state.

This repo is the outlier

Same workflow, same trigger, in five sibling repos — all of which do have the branch:

repo	trigger	documentation branch exists
openregister	branches: [documentation]	yes
opencatalogi	branches: [documentation]	yes
procest	branches: [documentation]	yes
pipelinq	branches: [documentation]	yes
docudesk	branches: [documentation]	yes
portaliq	branches: [documentation]	no

So the fleet convention is sound; portaliq simply never got the branch, and the workflow has been inert since it was added.

Options

1. Create the documentation branch, matching the other five. Restores the convention, but note it still means docs/ is only built on that branch — a docs/ change merged to development is unverified until it reaches documentation.
2. Add docs/ to the PR-time trigger (e.g. pull_request: paths: [docs/**]), so a lockfile or content change is built where it is proposed. This is what would actually have caught the defect above at the time it was introduced.

Worth checking whether the other five are meaningfully covered either: if documentation is a long-lived branch that rarely receives merges, they may be nearly as blind as portaliq — the branch existing is not the same as the job running on the changes that matter.

⚠️ Whatever is chosen, verify it by making the build fail on purpose once and confirming the job goes red. A docs job that has never run looks exactly like one that always passes — which is precisely how this defect survived.