Skip to content

Standards

A standard is a requirement and its reason. botica lint runs rules, and the rule.toml of a rule names the standard it implements:

standard = "CES-71"

A standard belongs to a set, and a set is the folder of the standards of one author, named like the prefix of their ids: the standards of CES-71 live in standards/CES/. A rule names a standard of any set the same way.

Sets

  • CES, the Collective Engineering Standard.

Propose or change a standard

A standard is one file, standards/<set>/<number>-<slug>.md, written by hand. Its number is the next free one of the set, and it never changes.

  1. Open a pull request that adds or edits the file of one standard, with the template for standards (add ?template=standard.md to the address of the new pull request). A pull request touches one standard; the check of the repository fails a pull request that touches two.
  2. The same pull request carries the implementation: the folder of each rule that implements the standard.
  3. The same pull request updates the documentation that the change affects.
  4. The discussion happens in GitHub Discussions, linked from the pull request and shown at the end of the page of each rule and each standard.

All standards

Standard Title Rules Topics
CES-4 API schemas forbid extra fields api-schemas-extra-forbid api-schemas
CES-5 Layered import direction import-layers
CES-8 Separate orchestration from logic separate-orchestration
CES-16 Architectural vocabulary architecture-vocabulary
CES-17 API boundary layout api-schema-in-route-module, api-request-schema-name, api-response-schema-name
CES-18 Relational persistence is its own package database-package, db-no-create-all
CES-30 Respect the local repo respect-local-repo
CES-32 Keep non-code artifacts out of the package no-artifacts-in-package, no-notebooks, no-tests-in-package
CES-45 Get loggers from the house get_logger log-get-logger structured-logging
CES-46 Libraries log, they don't print log-no-print structured-logging
CES-58 One modern lint stack no-disabled-typecheck
CES-63 No catch-all modules no-utils
CES-64 Test against in-memory adapters test-in-memory-adapters in-memory-adapters
CES-65 Test through the interface test-through-interface
CES-66 Coverage gaps are a signal test-coverage-gap, no-coverage-pragma, no-coverage-exclusion, coverage-exclusion-reachable
CES-67 Typed, declarative command lines cli-typed-framework
CES-71 Keep files small file-size-guard
CES-74 The logger module structured-logging
CES-75 Conventional Commits conventional-commits
CES-76 One settings module per package settings-module, settings-base-class, settings-direct-instantiation, settings-env-schema settings-module
CES-77 The Python version is a suggestion
CES-79 No raw dict at a boundary no-dict-alias, no-dict-call-return, no-dict-literal-return, no-dict-return-annotation typed-boundaries
CES-91 No AI co-authorship in commits no-ai-coauthorship
CES-107 Track the skills manifest
CES-109 Dependency hygiene lockfile-committed
CES-110 Cognitive complexity cognitive-complexity
CES-111 Test order randomization
CES-113 Dependency review on pull requests
CES-114 Dockerfile lint
CES-118 Copy-paste duplication
CES-119 Dependency vulnerability scanning
CES-120 Language, documentation and comments plain-writing, minimal-comments, ubiquitous-language
CES-121 Credentials are verified on the server route-auth, jwt-verified, no-token-in-web-storage
CES-122 A pull request carries one intent pr-small-by-intent