Skip to content

docs(gaps): register GT-623 — unenforced commit convention drives release versioning - #221

Merged
beyondnetPeru merged 2 commits into
developfrom
docs/gaps-component-assessment
Jul 27, 2026
Merged

docs(gaps): register GT-623 — unenforced commit convention drives release versioning#221
beyondnetPeru merged 2 commits into
developfrom
docs/gaps-component-assessment

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Pull Request Summary

Registers GT-623: the commit convention is mandated in three places, enforced by nothing, and release versions are derived from it.

Observed live, not inferred — .husky/commit-msg printed commitlint is not installed — skipping commit message lint and exited zero while merging develop into this branch. It did it again on the commit that registers the gap.

Verified rather than assumed. The hook runs npx --no -- commitlint --version and, when that fails, prints the message and succeeds. commitlint is in neither dependencies nor devDependencies of the root package.json; there is no commitlint.config.*, no .commitlintrc*, and no commitlint key. The else branch is the only branch that ever runs.

What depends on the convention it does not enforce. CONTRIBUTING.md and .github/pull_request_template.md mandate Conventional Commits in three places, and release-please derives version bumps from commit messages in sdk-cli-release.yml and sdk-cli-ci.yml.

It is already drifting, with a consequence. 2 of the last 60 non-merge commits use the type security(...), which is not a Conventional Commits type. release-please does not recognise it, so a commit announcing itself as a security change contributes nothing to the version bump — the same failure mode as GT-570, where a security wave sits unpublished. Two symptoms of one mechanism.

Broken out of GT-574's process picture into its own row because the consequence is concrete and measurable. The acceptance criteria keep all three options open on purpose: installing commitlint is not automatically the right one — failing open is worse than having no hook, because it manufactures the appearance of enforcement.

Board: 561/623 done · 9 in progress · 49 pending · 4 deferred.

Evolith Core Quality Gates

  • Bilingual Parity: row and catalog entry generated for .md and .es.md from a single data structure, so the pair cannot drift.
  • Validation Scripts: 01-validate-docs.mjs green (via ci-runner governance).
  • Bilingual Validation: 04-check-bilingual-parity.mjs green (via ci-runner governance).
  • Agnosticism: documentation only — no code, no dependency.

Verification

08-validate-tracking 623 gaps (ES 623), 599/599 EN/ES catalog sections, 543 closure records · ci-runner.mjs governance 17/17 exit 0.

Linked ADRs / Issues

  • Link to ADR: —
  • Link to Issue: GT-623 (related: GT-570, GT-574)

Conventional Commits

  • Title and commits follow Conventional Commits — verified by reading, since nothing enforces it. That is the point of this PR.

🤖 Generated with Claude Code

beyondnetPeru and others added 2 commits July 27, 2026 00:34
…forced, and drives versioning

Observed live while merging `develop` into a working branch: `.husky/commit-msg`
printed "commitlint is not installed — skipping commit message lint" and exited
zero.

Verified rather than assumed. The hook runs `npx --no -- commitlint --version`
and, when that fails, prints the message and succeeds. `commitlint` is in neither
`dependencies` nor `devDependencies` of the root package.json; there is no
`commitlint.config.*`, no `.commitlintrc*`, and no `commitlint` key. The else
branch is the only branch that ever runs.

What depends on the convention it does not enforce: CONTRIBUTING.md and the PR
template mandate Conventional Commits in three places, and release-please derives
version bumps from commit messages in `sdk-cli-release.yml` and `sdk-cli-ci.yml`.

It is already drifting, with a consequence worth naming: 2 of the last 60
non-merge commits use the type `security(...)`, which is not a Conventional
Commits type. release-please does not recognise it, so a commit announcing itself
as a security change contributes nothing to the version bump — the same failure
mode as GT-570, where a security wave sits unpublished.

Broken out of GT-574's process picture into its own row because the consequence
is concrete and measurable, not atmospheric. Filed as P2/S: failing open is worse
than having no hook, because it manufactures the appearance of enforcement.

Board: 561/623 done, 9 in progress, 49 pending, 4 deferred.

Verified: 08-validate-tracking 623 gaps (ES 623), 599/599 EN/ES catalog sections,
543 closure records; ci-runner governance 17/17 exit 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@beyondnetPeru
beyondnetPeru requested a review from a team as a code owner July 27, 2026 05:35
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 3
  • New EN files needing ES translation: 0

Repository Coverage

Metric Value
Total EN files 522
Total ES files 496
Paired files 0
Coverage 0%

Good: All EN changes have ES counterparts.


Generated by GitHub Actions

@beyondnetPeru
beyondnetPeru merged commit ed22d42 into develop Jul 27, 2026
30 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant