Triage

Kept’s repository went public on 2026-10-07. This page has two parts: what is in the repository today, and what is planned. Anything in the second part is a plan, not a setting that exists yet.

Issues

Three templates live in .github/ISSUE_TEMPLATE/:

Template	Label it applies	What it asks for
Bug report (bug_report.md)	bug	what happened, what was expected, how to reproduce; the Kept version (from /version), how it runs (Compose, Helm) and on what machine, the browser or phone and whether Kept is installed, the language; the relevant docker compose logs kept lines with private details removed
Idea (feature_request.md)	idea	the situation rather than the solution, what gets in the way today, and what the person would like
Shape request (shape-request.yml, an issue form)	area: map, shape request	a shape the location map lacks: what it is, its size and a photo or link (required), what people call it in any of Kept’s languages, and where it goes; the shape picker’s Missing a shape? Request it opens it

The bug template opens with a reminder that a security problem is not an issue. When one arrives as an issue anyway, don’t discuss it there: point the reporter at private vulnerability reporting and handle it as in security reports.

The troubleshooting page lists the known configuration failures with their fixes; a report that matches one can be answered with a link. No written triage procedure exists beyond the templates.

There is no labels configuration in the repository: bug, idea, area: map and shape request come from the templates and are created on GitHub by hand, and Renovate’s pull requests carry dependencies (renovate.json) once Renovate is enabled.

Pull requests

The template (.github/pull_request_template.md) asks for what changes for the people who use or run Kept and why, with a linked issue, and a checklist:

• bash scripts/ci-local.sh passes (or --fast, saying which steps couldn’t run);
• tests first, on their own database; the leak test and route catalogue updated for a new table or route;
• migrations are additive (a drop or rename takes two releases);
• new strings in every catalogue, Arabic in the house style; logical CSS; works at 375 px and 1280;
• Conventional Commit messages, and no AI attribution in commits or the description (D173);
• the CLA signed, once, on the contributor’s first pull request (the CLA).

Checks that run on a pull request

These jobs are the gate (D222): each is a required check on main, and a release is refused for a commit that hasn’t passed ci. Each ci job runs a slice of bash scripts/ci-local.sh (runbooks and scripts), so a failure reproduces locally with the same --only list. Every job is gated on github.event.repository.private == false: nothing runs while the repository is private.

Workflow	Job	What it checks
ci	fast	pnpm install --frozen-lockfile, bash scripts/ci-local.sh --fast (lint, catalogues, typecheck, unit tests, the mock evaluation), then node scripts/check-licences.mjs
ci	db-test	ci-local.sh --only compose,test: the server’s tests on Postgres with pgvector and RustFS, in three shards
ci	db-ops	ci-local.sh --only compose,drift,prod-boot,portability,backup: migration drift, a production boot, portability and backup
ci	db	the required check: green exactly when both halves are
ci	e2e-shard	ci-local.sh --only compose,e2e with CI_E2E_SHARD=k/3 or audit: a third of the Playwright suite against the built server, or e2e/audit.spec.ts on its own; the results are a per-shard artifact when it fails
ci	e2e-update	ci-local.sh --only compose,e2e-update: the step-3 update migration spec on its own
ci	e2e	the required check: green exactly when every shard and the update spec are
ci	images-amd64, images-arm64	ci-local.sh --only images: the image built natively on that architecture’s runner and smoked in full
ci	helm	the pinned Helm and kubeconform, then ci-local.sh --only helm
ci	attribution	scripts/check-attribution.sh over the pull request’s commits and its description
docs	build	the configuration reference is current, then the docs site builds; a broken link fails it

ci also runs on pushes to main; docs also deploys to GitHub Pages from main. release.yml never runs on a pull request. perf.yml runs ci-local’s perf step nightly and on demand, as a report (its numbers are an artifact); it is not a required check.

What a hosted runner can’t do (the database tests, the leak test, e2e, the image builds) is in the full local gate only, so a reviewer should expect the contributor’s ci-local result in the description, or run it themselves before merging.

What is planned

None of this exists yet:

• Issue forms for bug, feature and question, with questions sent to GitHub Discussions; a CODEOWNERS file. The audit leans towards a .github/ISSUE_TEMPLATE/config.yml that turns off blank issues and links to Security advisories and Discussions.
• GitHub Discussions as the only community space (D88), and a public roadmap on GitHub Projects.
• A ruleset on main: changes only through pull requests; required checks (CI typecheck, lint and unit tests, the leak test, the docs build, gitleaks); linear history with squash merges; no force-pushes or deletion; conversations resolved before merging.
• Squash merge only, with the pull request’s title as the commit, so the title must be a Conventional Commit (it is what the changelog reads).
• Tag protection: only the maintainer creates v* tags, which start a release.
• gitleaks on every push and pull request, and GitHub secret scanning, push protection and Dependabot alerts after the flip.