makes

This section explains how a maintainer command turns into repository work. It should help a reader move from make <target> to the owning fragment, the reused include stack, and the package or repository scope that target actually touches.

flowchart TB
    question["maintainer command question"]
    root["Makefile"]
    routing["root routing and include stack"]
    dispatch["shared or package dispatch"]
    proof["docs, tests, quality, api, security, release work"]

    question --> root
    root --> routing
    routing --> dispatch
    dispatch --> proof

This section should let a maintainer move from a command name to the owning fragment and then to the real proof surface. If it cannot do that, the make layer is still acting like shell folklore.

What This Surface Is For

• one command vocabulary for local work, CI, and release preparation
• explicit routing from the root entrypoint into shared and package-specific make logic
• reviewable command ownership instead of hidden shell glue

Start With

• open Root Entrypoints when the question starts from Makefile
• open Package Dispatch when the issue is how a target reaches one package or many
• open Make System Overview when you need the whole include stack and naming model
• open CI Targets when the command question starts from GitHub logs rather than a local shell

Read By Dispatch Problem

• Environment Model for the variables that shape command behavior
• Repository Layout and Package Contracts for understanding why dispatch lands where it does
• Release Surfaces and Authoring Rules for maintaining the command surface without turning it into ad hoc scripting

First Proof Check

• Makefile
• makes/root.mk, makes/packages.mk, and makes/publish.mk
• makes/bijux-py/ and makes/packages/

Design Pressure

The easy failure is to treat the make system as one convenience surface and lose the route from entrypoint to owner to proof.