Skip to content

Automation Surfaces

Repository automation should be visible in named surfaces, not hidden behind tribal shortcuts.

The repository already exposes its shared operational machinery through a small set of durable entrypoints. Keeping those surfaces explicit matters because they shape how contributors learn the workspace and how reviewers reason about the impact of shared changes.

Core Automation Surfaces

  • Makefile as the top-level repository entrypoint
  • makes/ as the structured library of shared make fragments
  • .github/workflows/ as the published CI, docs, and release automation
  • packages/bijux-canon-dev as the code-bearing home for maintainer helpers

Automation Rule

If automation changes repository-wide behavior, it should be explainable from one or more of these surfaces without reading unrelated shell glue first.

Review Lens

  • does the automation name what it touches
  • is the owning file obvious from the docs and the command shape
  • does the change keep package ownership visible instead of burying it in root convenience logic

Purpose

This page explains where repository automation is allowed to live and how it should stay reviewable.

Stability

Keep it aligned with the actual automation surfaces that contributors are expected to use.