Source

Code

• align.ts

  Brings repositories in line with the rules: pnpm align does craftz and every one in REPOS, and pnpm align markz does one. It's what writes, where drift.ts only reads, and it needs gh logged in as the owner.

• apply.ts

  One repository's settings outside its files, checked, written and read back. craftz settings runs it in a repository, and pnpm align runs it for each one it aligns, so both write the same way. The pieces that read and write each setting are in settings.ts.

• browsers.ts

  The browsers the rules' floors name, worked out from MDN's browser-compat-data. The date is the data's own, not today's, so the list moves only when pnpm align moves the package, and two runs on one version agree.

• cli.ts

  What a repository runs, and what an agent reads the rules with. Every subcommand works from the installed package, so the version that checks a repository is the version it reads, and nothing is fetched but what GitHub says about the repository.

• drift.ts

  Prints where each repository has drifted from the rules, and exits 1 when anything has. It only reads. align, which comes next, is what writes.

• gone.ts

  craftz gone deletes each local branch whose branch on GitHub is gone. GitHub deletes a branch once its pull request merges, so that's each one that merged. A repository runs it as pnpm gone, and it works where no git alias is set, like an agent's machine.

• index.ts

  The package's entry is craftz(), the Vite plugin a repository puts in its vite.config.ts. It sets what the rules ask of every Vite+ config, so a repository's config holds only what's its own.

• new.ts

  Starts a repository that follows the rules from its first commit. It writes the folder in the current one, installs, formats, runs verify and makes the first commit, so what it hands over already passes.

• pinned.ts

  The browsers and the Workers' date, as the rules use them, written in when the package is built.

• pr.ts

  craftz pr "<title>" takes what's in the working tree to a pull request that merges itself once CI passes, which is how every change reaches main. A repository runs it as pnpm pr, so a person and an agent take the same steps everywhere, from the version the repository installs.

• reference.ts

  What the other modules read as the rules: the files in reference/, laid out as a repository has them, their owner on GitHub, and its package.json, whose versions, engines and scripts are the rules'. root is craftz itself, for the tools it runs. It imports nothing of theirs, so any of them can import it.

• release.ts

  Opens the pull request that releases a package, like pnpm release sitez 0.5.0. Once CI passes it merges, and the package's release workflow does the rest.

• rules.ts

  Each rule in the rules that has an id, like scripts-verify. The doc states it, as a list item that opens with its id, and says why. Here is only what the words can't do: the check that finds where a repository has drifted from it, and the fix, where one can be automated.

• runtime.ts

  The compatibility date every Worker on cf runs at: the build date of the workerd that cf installs, through miniflare. workerd's version carries it, as in 1.20261012.1. It's the newest date the local runtime knows, so dev and tests run what production does, and it moves only when pnpm align moves cf.

• settings.ts

  What the rules set outside the repositories, where no file in one can hold it: each repository's merge settings, branch rules and labels on GitHub, and each Worker's build settings on Cloudflare. drift.ts reads them, and apply.ts writes them for craftz settings, align and new --push. Both go through the logins gh and cf already have, so there's no token to keep.

• stated.ts

  A rule is a list item in the rules on one line that opens with its id as a span, like - [`scripts-verify`]{#scripts-verify}: text. Its part is the second-level heading it's under, like Scripts. The doc is the one place a rule is worded, and the code holds only its check and its fix, under the same id.

• status.ts

  craftz status reads what a repository has out in the world, where check reads its files and settings its setup. Each line is one thing, marked ✓ or ✗, and it exits 1 when any is ✗, so it can be waited on after a merge or a release.

• survey.ts

  Reads every repository and checks it against the rules, returning what it found as data. pnpm drift prints it, and a page can show it as tables.

• worker.ts

  What a repository deploys, read from its Worker config. The survey, the command and craftz() all read it here, and it imports only Node's own modules, so the plugin stays small.