Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01You fixed a bug in the capability-grant parser. Which commit subject is a correctly-formed Conventional Commit?

   • fix(parser): reject empty capability grantCorrect. It follows <type>[scope]: <desc> - type fix for a bug, an optional scope in parentheses, and a short imperative summary. commitlint accepts it.
   • Fixed the parser so empty grants are rejectedIncorrect. There is no Conventional Commit type prefix, so commitlint rejects it in both the commit-msg hook and CI.
   • feature(parser)!: reject empty capability grantIncorrect on two counts: the type is feat, not feature, and a bug fix is not a breaking change, so the ! is wrong here. Both fail the check.
   • parser: reject empty capability grantIncorrect. parser is a scope, not a type. A valid message needs a type such as fix before the optional scope: fix(parser): ....

2. 02Your commit keeps getting rejected when you push. Which action is consistent with the estate's rules?

   • Configure SSH commit signing so the commit is Verified, because the org ruleset requires signed commits.Correct. SSH signing is mandatory and the branch ruleset requires signed commits; configuring signing is the fix, and it gives the commit non-repudiation lineage.
   • Disable signing with commit.gpgsign false to get the push through.Incorrect. Never disable signing - it is a non-negotiable floor rule, and the ruleset rejects the unsigned push anyway. This does not unblock you.
   • Pass --no-gpg-sign on this one commit as a temporary workaround.Incorrect. Bypassing signing, even once, violates the floor and still fails the ruleset. Fix the signing configuration instead.

3. 03A teammate skipped the local pre-commit hook with --no-verify and pushed. What is the effect on their pull request?

   • The same checks run again in CI and block the merge if they fail - the hook is a bypassable convenience, but CI is the real gate.Correct. Lefthook runs the same commands CI does; skipping the local hook only defers the checks. The PR still has to pass them, and the secret scan is deeper in CI.
   • Nothing is checked, because skipping the hook skips the checks entirely.Incorrect. The hook is a convenience; CI re-runs formatters, linters, commitlint, and secret scanning on the PR regardless of what ran locally.
   • The push is impossible - Git refuses to push when the hook was skipped.Incorrect. The push can succeed; the enforcement is at CI and the merge gate, not at push time for the hook itself.

4. 04Your pull request changes code but touches no documentation. What happens, and what is the intended response?

   • The docs-required CI gate fails; update docs/, a *.md file, or the CHANGELOG in the same PR, because if code changes, docs change.Correct. The gate fails a code-only PR by design. The intended fix is to add the doc change that a reader needs; a docs-exempt label exists only for genuine exceptions.
   • Nothing happens - documentation is a follow-up task after the code merges.Incorrect. Docs-as-code is enforced at the PR, not deferred. A code-only PR fails the docs-required gate before it can merge.
   • The PR is auto-merged because the code passed its tests.Incorrect. Nothing auto-merges here - merge is a human gate - and a failing docs-required check blocks it regardless of the tests.