Document Scope

This document defines the standing CI/CD pipeline standard for repositories in the modular workspace. It explains how the remote Git repository CI/CD pipeline service should be introduced, reviewed, expanded, and maintained as part of normal repository work.

This document is written for human developers, ChatGPT sessions, Codex sessions, AI-assisted development tools, automation workers, future AI agents, and maintainers. It should be read before proposing repository changes, Git commits, pushes, merges, deployment work, validation changes, build changes, test changes, or changes to pipeline configuration.

This document applies across repository classes. The platform includes deployable application repositories, server/infrastructure repositories, personal utility repositories, and context/reference repositories. These repository classes do not need identical pipelines.

This document does not replace the runtime validation standard, Git checkpoint standard, Git commit-message standard, patch/Codex workflow standard, backend tooling standard, technology stack reference, architecture standards, or task-specific handoff. It adds the CI/CD pipeline layer to the normal repository workflow.

---

1. Purpose

The purpose of the CI/CD pipeline standard is to make repository automation part of the normal development workflow from the beginning.

The pipeline should not be treated as a late-stage deployment feature. It should begin with simple, low-risk validation and grow as each repository matures.

The standard progression for deployable repositories is:

local validation
    plus
remote pipeline validation
    then
build automation
    then
artifact handling
    then
staging deployment
    then
manual production deployment gates
    then
release and rollback automation

The standard progression for context/reference repositories is smaller:

local documentation update
    plus
remote documentation validation
    then
optional structure/link checks

The pipeline should evolve with the project. Each meaningful repository change should trigger the question:

Does this change require a CI/CD pipeline update?

The answer may be no, but the question must be considered before commit readiness.

---

2. Layer and Tool Definitions

The following table defines CI/CD terms for durable documentation. Use generic terms in ordinary guidance unless the selected implementation matters.

Generic term	Current selected implementation or meaning	Role
remote Git repository	GitLab currently	Hosted source-of-truth repository
remote Git CI/CD pipeline service	GitLab CI/CD currently	Runs automated jobs after repository events
pipeline configuration file	.gitlab-ci.yml currently	Repository-level pipeline definition
pipeline job	CI/CD job	One automated task such as lint, test, build, package, deploy, validate, or inspect
pipeline stage	CI/CD stage	Ordered group of related jobs
pipeline runner	remote or self-managed runner	Execution environment for CI/CD jobs
protected branch	remote Git host protected branch	Branch with restricted push, merge, or deploy behavior
protected variable	remote Git host protected CI/CD variable	Secret or environment value restricted by branch/environment rules
deployment environment	development, staging, production, or other named environment	Target environment for deploy jobs
pipeline artifact	CI/CD artifact	Generated file retained from a job
manual deployment gate	manual approval job	Human-controlled production or high-risk deployment step
context repository	ctx-* repository	Read-only reference/documentation mirror used by AI tools and development sessions
deployable repository	application, site, admin, or similar repository	Repository that may eventually build and deploy runtime services or websites
infrastructure repository	server/environment repository	Repository that stores server configuration, startup tasks, scheduled-job definitions, tunnel configuration, and future environment automation

Each deployable repository should eventually have a repository-specific pipeline configuration. A context repository should normally have only the simplest useful documentation/reference validation. A server/infrastructure repository may have validation and dry-run checks, but production-mutating automation requires explicit approval.

---

3. Repository Classes

3.0 Repository Classification Source of Truth

Repository classes are defined by the Repository Classification Standard. This CI/CD standard applies those classes to pipeline design. It does not redefine the full classification model.

Before a pipeline is created or changed, identify whether the repository is Class A, Class B, Class C, Class D, Class E, Class F, Class G, or multi-class. A pipeline for a multi-class repository must apply the strictest controls required by every applicable class. The workspace contains different repository classes. Pipeline expectations must follow repository purpose.

3.1 Deployable Application Repositories

Deployable application repositories include repositories that eventually affect the running SaaS platform, customer-facing website, private admin/command-center site, backend services, APIs, dashboards, workers, or runtime delivery systems.

Current examples include:

app
site
admin

These repositories should eventually move toward fuller pipelines that can validate, test, build, package, deploy to staging, and later deploy to production through controlled manual gates.

3.2 Server and Infrastructure Repository

The server repository contains server configuration, startup tasks, service definitions, scheduled-job definitions, tunnel configuration, future Linux service units, bootstrap scripts, and server environment documentation.

The server repository may eventually support staging or environment automation. Its pipeline should begin with validation and dry-run checks. It must not mutate production infrastructure unless a task explicitly authorizes that work.

3.3 Context and Reference Repositories

Context repositories use the ctx-* prefix.

They are read-only or reference-oriented mirrors containing selected official documentation, source material, API schemas, examples, metadata, and related materials for tools and services used by the project.

Context repositories support humans, ChatGPT sessions, Codex sessions, future AI agents, and local retrieval workflows. They do not run the SaaS application. They do not control the public site. They do not control the private admin/command-center site. They do not deploy to production.

Examples include:

ctx-authentik
ctx-better-auth
ctx-brevo
ctx-cloudflare
ctx-obsidian
ctx-resend

Future context repositories may be added for tools such as the Python project manager, linting and formatting layer, testing layer, API layer, model layer, schema migration layer, frontend application layer, dashboard layer, terminal tooling, bot-protection layer, or other selected stack components.

Context repository pipelines should be minimal. They should validate that the reference library remains coherent and safe to use. They should not deploy.

3.4 Personal Utility Repositories

Personal utility repositories, such as backup tooling, should receive pipelines appropriate to their actual behavior. A personal backup utility may need script syntax validation, basic tests, package checks, or documentation checks. It should not be treated like the SaaS application unless it becomes runtime platform infrastructure.

3.5 Future Repository Classes

This repository list is not final. Future repositories may be created as the platform grows. A new repository should be classified before pipeline design begins.

Use the repository class to decide the smallest safe pipeline, not the other way around.

---

4. Core CI/CD Rule

Every repository-related session must consider whether the broader Architectural Impact Review identifies pipeline work that should change before commit.

Before a Git commit is recommended, the session must check:

1. What repository class is this: deployable application, server/infrastructure, context/reference, personal utility, or other?
2. Did the change alter Python dependencies, frontend dependencies, tooling, tests, package layout, scripts, build steps, runtime commands, frontend build behavior, deployment behavior, database migration behavior, validation commands, environment variables, secrets, documentation structure, reference-library structure, or repository structure?
3. If yes, does the repository pipeline need to be created or updated?
4. If no pipeline exists yet, should this task add a minimal validation pipeline or record CI/CD as a follow-up?
5. If a pipeline exists, should any job, stage, variable, artifact, cache, environment, or deployment gate be updated?
6. If pipeline work is out of scope, should the handoff explicitly say that CI/CD was considered but not changed?

This rule does not mean every task must edit the pipeline. It means every task must consider pipeline impact.

4.1 CI/CD Components Are Supply Chain Artifacts

Pipeline components are external artifacts when they come from outside the repository. This includes job images, reusable workflows, templates, includes, third-party actions, downloaded scripts, package-manager bootstraps, security scanners, deployment helpers, SBOM generators, signing tools, and runner images.

The AI must apply the Supply Chain Security Standard before adding or changing external CI/CD components. A pipeline file may look like configuration, but it can execute code, consume secrets, publish artifacts, deploy services, mutate infrastructure, or expose protected variables. It must therefore be treated as a high-impact integration surface.

A pipeline job image used for production validation or release work must be selected from an approved source and pinned appropriately. A remote script downloaded during a job must not be executed unless it has been explicitly approved and verified. A pipeline include from a third-party repository must not be added merely because it is common or convenient.

---

Architectural Impact Review Relationship

CI/CD pipeline review is mandatory, but it is no longer the only pre-commit architecture checkpoint. It is a required subsection of the broader Architectural Impact Review used across repository work.

When a repository task is ready for commit, the assistant or coding agent must first complete the Architectural Impact Review required by the Git checkpoint standard and then complete the CI/CD-specific subsection required by this document. CI/CD should answer whether pipeline configuration, stages, jobs, runner assumptions, variables, protected variables, caches, artifacts, validation commands, build behavior, deployment behavior, or manual gates need to change because of the work.

The CI/CD review must also be action-oriented. If the review reveals that the pipeline file, validation job, build command, protected-variable note, artifact path, or deployment gate is now stale and can be fixed safely inside the current task scope, it should be fixed and validated before commit. If the pipeline issue is outside scope, risky, or requires a separate task, it must be recorded as a generated follow-up task.

Every commit that touches or depends on CI/CD must also record whether the task revealed a weakness, ambiguity, missing safeguard, or repetitive manual step in the repository workflow. That finding belongs in the Workflow Weakness and Safeguard Review section of the commit message, not only in the CI/CD impact section.

5. Starting Standard

CI/CD should start small.

The first pipeline for a repository should normally avoid deployment. It should focus on validation that can safely run after a push.

A minimal starting pipeline may include:

pipeline syntax validation,
Python compile checks,
lint checks,
format checks,
unit tests,
static site build checks,
frontend build checks,
documentation structure checks,
Markdown formatting checks,
link checks where useful,
reference-library manifest checks where useful,
no-secret checks where practical.

The first version does not need to solve deployment. It should establish the habit that the remote repository validates changes.

---

6. Repository-Specific Pipeline Standard

Each repository should have a pipeline appropriate to its purpose.

Do not copy one repository’s pipeline blindly into another repository. Use a shared standard, but keep each pipeline fitted to the repository.

6.1 Application Backend Repository

The application backend repository should eventually validate and build backend runtime systems.

Appropriate pipeline areas may include:

Python dependency setup,
approved Python runner setup,
compile/import checks,
lint/format checks,
pytest tests,
runtime-contract or no-mutation validation,
database access validation,
schema migration checks where applicable,
API contract generation/checks where applicable,
worker command validation,
package/build steps where applicable,
artifact generation where useful,
staging deployment when mature,
manual production deployment gate when mature.

Production deployment must not be introduced until validation and staging behavior are reliable.

6.2 Public Site Repository

The public site repository should eventually validate and build the customer-facing website.

Appropriate pipeline areas may include:

static validation,
frontend dependency setup if applicable,
type checks where applicable,
build checks,
link checks,
asset checks,
public wording checks where practical,
generated documentation checks,
preview or staging deploy when mature,
manual production deployment gate when mature.

The public site pipeline should not access production databases directly.

6.3 Admin Repository

The admin repository should eventually validate and build the private command-center/admin site.

Appropriate pipeline areas may include:

frontend/backend validation,
type checks,
build checks,
API contract checks,
internal access assumptions,
environment labels,
dashboard route checks,
staging deployment when mature,
manual production deployment gate when mature.

The admin pipeline must be careful about secrets, protected variables, internal routes, database access, and production write behavior.

6.4 Server Repository

The server repository should begin with validation and dry-run behavior.

Appropriate pipeline areas may include:

configuration validation,
script syntax checks,
PowerShell syntax checks where applicable,
shell script syntax checks where applicable,
future service-unit validation,
scheduled-job definition validation,
tunnel configuration validation where practical,
dry-run checks,
no-production-mutation default,
manual approval for high-risk actions.

The server repository pipeline should not alter live server state unless the task explicitly authorizes that class of automation.

6.5 Context Repositories

Context repositories should have the simplest useful pipeline.

Appropriate pipeline areas may include:

Markdown/frontmatter checks,
required README or index checks,
manifest or inventory checks where present,
file-size sanity checks where useful,
link checks where useful and not too noisy,
duplicate filename checks where useful,
documentation structure checks,
no-secret checks,
no-deployment guarantee.

Context repositories should not have build, deploy, database migration, production environment, customer-facing runtime, or service-restart jobs unless their purpose changes.

The main goal is coherence: the repository should remain a usable reference library for AI tools and development sessions.

---

7. Context Repository Pipeline Standard

Context repositories exist to support development and AI-assisted work. They are reference libraries, not runtime services.

A context repository pipeline should answer:

1. Does the repository still contain the expected documentation/reference structure?
2. Are required index, README, manifest, or source-summary files present where the repository standard requires them?
3. Do Markdown files parse well enough for use as reference material?
4. Are frontmatter fields present where the repository uses frontmatter?
5. Are obvious private secrets absent from tracked files?
6. Are links checked only when link checking is useful and not too noisy?
7. Are generated large files or vendor mirrors within expected limits?
8. Is deployment absent?

A context repository pipeline should normally not need protected production variables. It should not deploy to staging or production. It should not run runtime application tests. It should not attempt to verify whether the mirrored upstream documentation is current unless the repository has an explicit update job and the task scopes that check.

For the first validation-only context pipeline, use simple commands that are safe in a clean runner and do not depend on local-only state. When checking for Markdown files, prefer a bounded find -print -quit existence check rather than a find | grep -q pipe. When scanning for secrets, tune patterns for credential-style values and avoid treating ordinary documentation about secrets as an automatic failure.

The pipeline can validate the local reference library. It does not replace the separate process that updates a context repository from official sources.

---

8. Local Validation and Pipeline Validation

Local validation and CI/CD validation are different gates.

Local validation confirms the working tree behaves correctly in the developer’s local environment.

Pipeline validation confirms the remote repository can reproduce required checks in a clean, automated environment.

A branch should not be treated as fully validated merely because local checks passed. When a pipeline exists, pipeline status should be reviewed after push before treating the remote branch as validated.

A pipeline failure is not a nuisance to ignore. It is part of the repository’s safety system.

---

9. CI/CD Subsection of Architectural Impact Review Before Commit

Before recommending a Git commit, the session must include a pipeline impact review.

The review should answer:

Pipeline impact:
- Repository class: deployable application/server-infrastructure/context-reference/personal-utility/other.
- Pipeline file changed: yes/no.
- Pipeline update needed: yes/no/deferred.
- Supply-chain impact: yes/no/deferred, including job images, includes, downloaded scripts, SBOM tools, signing tools, and external pipeline components.
- Reason:
- Expected pipeline behavior after push:
- Deployment expected: yes/no.

If the repository has no pipeline yet, use:

Pipeline impact:
- Repository class:
- Pipeline file changed: no.
- Pipeline update needed: yes/no/deferred.
- Supply-chain impact: yes/no/deferred, including job images, includes, downloaded scripts, SBOM tools, signing tools, and external pipeline components.
- Reason: repository does/does not yet have a pipeline; change did/did not affect validation/build/deploy/reference-library expectations.
- Follow-up: create or update pipeline if required.
- Deployment expected: no.

This section may be brief, but it should not be skipped for repository sessions.

---

10. Pipeline Impact in Commit Messages

Commit messages should include CI/CD impact when the change affects the pipeline, validation, build, deployment, dependencies, runtime commands, repository automation, documentation validation, or context-library structure.

Use a section such as:

CI/CD impact:
- No pipeline configuration changed.
- Expected pipeline jobs: lint/test/build.
- No deployment job expected.

or:

CI/CD impact:
- Updated the pipeline validation job to run the new test command.
- No deployment job changed.
- Production deployment remains manual/out of scope.

For a context repository, use:

CI/CD impact:
- No deployment job exists or is expected.
- Expected pipeline jobs: documentation structure/no-secret checks.
- Pipeline update needed: no.

If there is no meaningful pipeline impact, the section may be omitted unless the Git commit-message standard requires it for the session.

---

11. Pipeline Configuration Change Rules

Pipeline configuration is high-impact repository code.

A pipeline file can run commands, consume secrets, publish artifacts, deploy services, modify infrastructure, run database migration commands, or mutate production environments.

Do not create or modify pipeline configuration casually.

Any task that changes pipeline configuration must specify:

repository path,
repository class,
branch,
pipeline file path,
allowed stages,
allowed jobs,
forbidden jobs,
whether deployment is allowed,
whether production is out of scope,
whether secrets or protected variables may be referenced,
expected runner environment,
validation method,
expected pipeline result after push.

If those details are missing, the task is not ready for implementation.

---

12. Deployment Gate Standard

Production deployment must not be automated casually.

The default standard is:

validation jobs may run automatically,
build jobs may run automatically once safe,
staging deployment may be automated after review,
production deployment requires a manual gate until a later standard approves otherwise.

A production deployment job should not be introduced unless the task explicitly authorizes it and defines:

environment,
approval rule,
protected branch,
protected variables,
rollback plan,
release record,
human confirmation point,
post-deploy validation.

If a production job exists, future sessions must not change it without explicit scope.

Context repositories should not have deployment jobs. If a context repository appears to need deployment, stop and reclassify the repository before proceeding.

---

13. Secrets and Protected Variables

Secrets must not be stored in pipeline configuration files.

Pipeline configuration may reference CI/CD variables, but secret values belong in the remote Git host’s protected variable system or another approved secret-management layer.

Pipeline work must consider:

protected branch restrictions,
protected environment restrictions,
masked variables,
variable scope,
staging versus production values,
least-privilege tokens,
token rotation,
whether a job truly needs the secret.

A validation-only pipeline should not receive production secrets.

A context repository pipeline should normally need no production secrets. If it needs credentials to update mirrored documentation from official sources, those update credentials should be treated separately from validation jobs and should not create deployment behavior.

---

14. Database and Migration Pipeline Rules

Database-related pipeline jobs require special care.

A pipeline may safely run:

schema syntax checks,
migration dry-run checks where supported,
test database migrations,
staging database checks,
no-mutation validation.

A pipeline must not mutate production databases unless there is an explicit approved production migration process.

Database migration jobs should identify:

target environment,
migration command,
dry-run support,
backup expectation,
rollback expectation,
approval gate,
post-migration validation.

If the repository change touches database models, schema files, migration files, database access code, runtime database commands, or environment variables, pipeline impact must be reviewed before commit.

Context repositories should not run database migration jobs.

---

15. Codex and AI-Agent Rules

Codex and AI agents must treat CI/CD configuration as high-risk automation.

A safe Codex task may:

inspect existing pipeline configuration,
draft a minimal validation-only pipeline,
add a documentation-structure job,
add a no-secret check,
add a lint job,
add a test job,
add a build job,
update documentation,
prepare a handoff describing required manual remote setup.

An unsafe Codex task asks for:

automatic production deployment,
secret creation,
protected variable changes,
infrastructure mutation,
database migration execution,
broad pipeline cleanup,
copying another repository’s pipeline without inspection,
changing deployment rules without explicit approval.

Codex cannot configure protected variables directly unless it has access to the remote Git host and the task explicitly authorizes that work. If protected variables are needed, the handoff must list the exact variable names and where they are required, without exposing secret values.

---

16. Pipeline Review After Push

When a repository has a configured pipeline and a branch is pushed, review the pipeline result before treating the branch as remotely validated.

The review should identify:

pipeline status,
failed job if any,
failure reason,
whether failure is caused by code, configuration, environment, missing variables, or runner setup,
whether deployment was triggered,
whether artifacts were produced,
whether manual action is pending.

A failed pipeline should be resolved or documented before merge or final handoff.

For context repositories, confirm that no deployment job ran or became pending.

---

17. Branch and Merge Rules

Pipeline behavior should support branch safety.

Protected branches should eventually require appropriate pipeline checks before merge.

For early adoption, the standard may be:

feature branches trigger validation,
main branch triggers validation,
deployment jobs are disabled or manual,
production deployment is not automatic.

For context repositories, the standard should normally be:

feature branches trigger documentation/reference validation,
main branch triggers documentation/reference validation,
deployment jobs do not exist,
production environment does not exist.

As the project matures, repository rules may require passing pipeline status before merge.

Do not tighten branch rules until the pipeline is reliable enough to avoid blocking normal work unnecessarily.

---

18. Artifact and Cache Rules

Pipeline artifacts and caches should be intentional.

Artifacts may include:

test reports,
coverage reports,
build outputs,
static site builds,
validation summaries,
package files,
deployment manifests,
documentation validation reports,
link-check reports,
reference-library inventory reports.

Do not retain large artifacts without a reason. Do not store secrets in artifacts. Do not treat pipeline artifacts as permanent records unless retention is explicitly defined.

Caches should speed up jobs without hiding broken dependencies or stale generated files.

For context repositories, avoid retaining copied upstream material as artifacts unless the artifact has a specific review purpose. The repository itself is already the durable reference library.

---

19. CI/CD Adoption Sequence

The recommended adoption sequence is:

1. Create this CI/CD pipeline standard.
2. Add Architectural Impact Review to normal Git commit readiness.
3. Inventory repositories and classify each as deployable application, server/infrastructure, context/reference, personal utility, or other.
4. Choose the first repository for a minimal validation-only pipeline.
5. Add the smallest useful pipeline configuration.
6. Push a branch and review pipeline behavior.
7. Fix runner, dependency, command, or file-pattern issues.
8. Expand validation jobs.
9. Add build jobs where needed.
10. Add artifact handling where useful.
11. Add staging deployment where useful and safe.
12. Add manual production deployment gates only after staging is reliable.
13. Add release and rollback automation later.

Do not begin with production deployment automation.

For context repositories, stop after minimal validation unless a specific need justifies additional checks.

---

20. Current Repository Classification

This section records current repository classification. It should be updated as repositories are added, renamed, repurposed, or retired.

Repository pattern or current repository	Current class	Expected CI/CD level
app	deployable application/backend repository	Full pipeline eventually: validation, tests, build/package, staging, manual production deployment
site	deployable public site repository	Full pipeline eventually: validation, build, preview/staging, manual production deployment
admin	deployable private admin/command-center repository	Full pipeline eventually: validation, build, staging, manual production deployment
server	server/infrastructure repository	Validation and dry-run first; staging/environment automation possible later; production mutation only with explicit approval
ctx-*	context/reference repository	Minimal documentation/reference validation only; no deployment
echo or personal utility repositories	personal utility repository	Repository-specific validation; no SaaS deployment unless repurposed

This table is current-state guidance, not a permanent limit on repository creation. Future repositories should be classified before pipeline design begins.

---

21. Session Handoff Requirements

When CI/CD is relevant, a session handoff should record:

repository class,
whether the repository has a pipeline,
pipeline file path,
pipeline jobs added or changed,
pipeline jobs not changed,
whether deployment jobs exist,
whether deployment was out of scope,
whether protected variables are needed,
expected pipeline behavior on push,
actual pipeline result if pushed,
follow-up CI/CD tasks.

If the pipeline was considered but not changed, say so.

For context repositories, the handoff should explicitly say that no deployment was expected.

---

22. Maintenance Requirements

Update this document when:

1. A repository adopts its first pipeline.
2. A repository is added, renamed, repurposed, or retired.
3. A repository changes class.
4. A repository adds deployment jobs.
5. Production deployment rules change.
6. Protected variable strategy changes.
7. Runner strategy changes.
8. Branch protection rules change.
9. Required pipeline jobs change.
10. Database migration automation is introduced.
11. Artifact retention rules change.
12. A pipeline incident reveals missing standards.
13. The remote Git host changes.

---

23. Summary

The CI/CD pipeline is part of the normal repository workflow.

The core rules are:

classify the repository before designing the pipeline,
start pipeline adoption early,
start with low-risk validation,
make each repository pipeline-specific,
keep context repository pipelines minimal,
do not automate production deployment casually,
do not expose secrets in pipeline files,
review pipeline impact before commit,
review pipeline status after push,
treat pipeline configuration as high-risk automation,
expand the pipeline as the project matures.

Every repository-related AI session should consider whether the pipeline should be created, updated, or explicitly left unchanged because of the work completed in that session.

24. Pilot-Proven Merge, Pipeline, and Commit-Record Rule

The ctx-obsidian pilot established an important CI/CD workflow rule: a pipeline can pass and the branch can be technically correct while the final merge record is still operationally defective. CI/CD adoption therefore includes both pipeline validation and commit-record validation.

The completed pilot showed the following facts:

1. A minimal context/reference pipeline can be safely introduced with one validation stage and no deployment.
2. The initial branch pipeline should be reviewed before merge.
3. A failed pipeline must be classified before code is changed. The failure may indicate a repository problem, a pipeline-command defect, a runner/environment issue, a missing variable, or a false positive in a validation rule.
4. A final main-branch pipeline must be reviewed after merge.
5. The merge commit message must preserve the operational record.

For context/reference repositories, avoid fragile shell patterns such as:

find . -type f -name "*.md" | grep -q .

That pattern can fail with exit code 141 when grep -q exits after the first match and closes the pipe while find is still writing. Use a bounded existence check instead:

test -n "$(find . -type f -name "*.md" -print -quit)"

Secret scanning for context/reference repositories must be useful without blocking legitimate documentation. A broad rule that flags every use of secret = ... is too noisy for repositories that mirror documentation about secret storage APIs. Prefer patterns that target credential-style values such as api_key, password, token, secret_key, secret_token, and bearer token assignments. If a documentation repository contains realistic example credentials, record the false positive and tune the rule carefully rather than disabling validation blindly.

GitLab UI pipeline review is acceptable. GitLab UI merge is not the preferred final merge mechanism when the merge commit message matters, because the default UI merge may create a shallow merge commit message even when the merge request description is detailed. Use local Git, GitLab CLI, or GitLab API with an explicit merge commit message when the final merge record will be consumed by the operations database or future automation.

Before pushing a local merge to main, verify the full merge commit body:

git show --no-patch --format=full HEAD

If the merge message is incomplete, corrupted, or generic and has not been pushed, amend it before push. If a defective merge has already been pushed, do not rewrite protected main without explicit instruction. Add a corrective documentation or audit commit and merge that correction with a controlled merge message.