Goal
Document how maintainers should think about harness adoption when a target repository uses GitLab CI instead of GitHub Actions.
Scope
- Add a concise note or example under
docs/.
- Explain that CI wiring should fit the target repository's existing provider.
- Show which generic checks can be run in GitLab CI without copying the GitHub Actions workflow blindly.
- Link from README or validation docs if useful.
Acceptance Criteria
- The note preserves prompt-first adoption and target-source-of-truth guidance.
- It does not introduce a mandatory
.gitlab-ci.yml template.
python scripts/check_docs_drift.py passes.
- Full local validation still passes.
References
ROADMAP.md
CONTRIBUTING.md
docs/adoption-workflow.md
Goal
Document how maintainers should think about harness adoption when a target repository uses GitLab CI instead of GitHub Actions.
Scope
docs/.Acceptance Criteria
.gitlab-ci.ymltemplate.python scripts/check_docs_drift.pypasses.References
ROADMAP.mdCONTRIBUTING.mddocs/adoption-workflow.md