Repository tooling v0.7.3

Repository tooling 0.7.3

Automatic template updates now restore installed dependencies before committing through the real
shared Git hooks. Template regeneration removes node_modules; generating only the lockfile left
the hook without the CLI package and prevented all three templates from opening their update pull
requests.

The incoming template publication entry point also repairs already-installed v0.7.1 and v0.7.2
update drivers, which share the same template update implementation. It preserves the published
lockfile and installs the generated dependencies. Current drivers explicitly delegate installation
once, and an explicit install: false still performs no install. The pure template materialization
API continues to generate files without installing packages. When an update must leave workflow
files for a maintainer, its diagnostic preserves each exact repository path, including the first
modified workflow's opening dot.

All seven packages, root and example references, and contribution plugin metadata advance together.
Reusable workflow and attestation signer pins remain the reviewed merged v0.7.0 source commit. No
hook is bypassed or copied into a consumer. Release verification and production promotion gates are
unchanged.

Adopt this patch through the standard updater. The regression exercises both the actual published
v0.7.2 updater and the current caller against basic, Astro and Vite React templates. It regenerates
each template, runs its real formatting and filename hooks, commits normally, and proves the
resulting lockfile supports a frozen install.

Repository tooling v0.7.2

Repository tooling 0.7.2

The shared release runner now starts the CLI-owned TypeScript runtime using the current Node
executable. It no longer requires a second tsx dependency or a pnpm exec tsx executable in each
application root. This corrects the first Analytics staging build, whose existing package-local
runtime was unavailable from the repository root.

All seven packages, plugin manifests and generated template references advance together. Reusable
workflow and attestation signer pins remain the reviewed merged v0.7.0 source commit. Artifact
verification, protected staging, browser acceptance and explicit promotion are unchanged.

Adopt this patch with the standard updater. A real child-process regression runs the release entry
with no consumer executable on PATH, verifies its arguments, and proves that the CLI supplies its
runtime. The previous command fails that test before entering the release implementation.

The organization inventory also recognizes the canonical SHA-pinned shared audit workflow callers.
It previously warned about these correctly migrated workflows because it searched only for inline
audit commands. Actual generated callers are tested, including rejection of a moving branch ref.

Configuration inventory follows declared workspace package exports and relative imports at the same
verified commit. Repository wrappers that extend shared settings are accepted with source evidence;
independent settings continue to produce a diagnostic.

Repository tooling v0.7.1

Repository tooling 0.7.1

This patch corrects the immutable reusable workflow and attestation signer pins in generated
repositories. Use the actual merged v0.7.0 source commit rather than the reviewed PR commit that was
rewritten by the required rebase merge. GitHub Actions cannot resolve the latter after its branch is
deleted.

All seven shared packages and the generated templates advance together. The workflow implementations
are identical to the reviewed v0.7.0 merged tree; existing command, security, audit and release
contracts are unchanged.

Consumers should adopt v0.7.1 with the standard updater and set their shared workflow and signer
pins to 3567f0cb1345e8756eb5d84e0a3ea7b62695125a. A regression check requires generated workflow
pins to belong to the published merged release history. Validate Actions using the exact merged
source before closing a migration.

CI setup also installs the reviewed Gitleaks 8.30.1 native scanner from the official release using a
pinned archive checksum. Required secret scanning no longer depends on a runner's Docker daemon
being available. Installation fails before extraction when the checksum is wrong; the scan still
requires full Git history. The contribution marketplace version now agrees with both plugin
manifests.

Repository tooling 0.7.0

Repository tooling 0.7.0

Local bootstrap and preflight no longer require publishing credentials. Bootstrap validates the
toolchain before installing dependencies and preserves existing local environment files. Configure
local examples and optional integrations through the versioned tooling declaration. Production setup
remains explicit through --production. Documented future-only credentials are never provisioned or
rotated; generated secrets wait while another target cannot be observed.

lvbt check now verifies standard integrity and reports command-contract drift. Consumer root
commands match the templates, with product checks ordered by Turbo. New command rules warn in this
minor release and become required in 0.8.0. The updater adds shared Turbo cache inputs for the
standard fingerprint, tooling declarations and root workflows while preserving product globals and
tasks. Missing inputs warn in 0.7 and fail from adopted 0.8 releases. Template publication executes
the selected release's own updater, so repeated publication cannot inherit a different running
standard's policy.

Audited transitive overrides now come from the shared CLI catalog and update through the same
incoming updater, preserving application-only pins. Missing shared pins warn in 0.7 and become
required in 0.8. The security baseline selects Sharp 0.35.5 and an exact reviewed temporary Braces
depth-guard backport. See Dependency policy for provenance and replacement
criteria. Templates preserve their full dependency audit and full-history secret scan as uncached
parts of pnpm check.

lvbt audit runs shared link, Lighthouse, and dependency adapters. Trusted scheduled reports
maintain one readable issue per check and target through the contribution helper, including verified
recovery and regression handling. Errors and incomplete checks cannot close issues. The reporter
verifies the run attempt's successful prerequisites and retained evidence before reconciling.
Recurring product reports use the same contribution backend, with reviewed adoption of existing
automation issues and optional pinning.

The web-platform package now provides shared saved-release orchestration and lvbt promote. Main
updates staging; production promotion verifies a saved artifact without rebuilding. Signed
inventories verify the reviewed shared signer and source revision. Named staging supports Durable
Objects with separate credential environments and immutable same-run acceptance receipts. Draft
profiles cannot promote, and shared public R2 datasets expose only read capabilities in staging.
Previously retained website artifacts remain readable through exact reviewed run, commit, artifact
ID, and expiry declarations. The compatibility path independently downloads and verifies the
retained bytes; new artifacts always require signed proof. Consumers migrate their application-owned
workflows and configuration explicitly; updating the vendor snapshot alone does not complete
adoption.

Repositories declaring saved releases cannot bypass promotion through lvbt deploy; it permits
configuration dry runs and names the staging/promotion correction before any provider operation.
Shared pull-request previews preserve repository-owned browser acceptance and clean up only their
derived preview Worker. Initial production adoption or recovery can name an expected provider
version; a changed version stops publication before production writes.

See Developer workflow for the command contract and ownership boundaries.

Shared ESLint entry points ship declarations, so TypeScript consumer configurations need no local
module shims. Release build and publication checkouts include full Git history for the required
secret scanner and published-updater compatibility tests.

Repository tooling 0.6.3

Adds cf deployment support and lets production verify Cloudflare accounts and D1 databases without tracking their IDs.

What's Changed

• feat: support Cloudflare cf deployments by @WillieCubed in #65
• fix(tooling): recognize Resend Forge DNS by @WillieCubed in #66
• chore(tooling): default web templates to cf by @WillieCubed in #67
• fix(tooling): let production bootstrap continue without cf login by @WillieCubed in #68
• feat(tooling): resolve Cloudflare identifiers outside configs by @WillieCubed in #69

Full Changelog: v0.5.4...v0.6.3

v0.5.4

Repository tooling 0.5.4

Nothing changes in how your repository works. In a repository with a merge queue, the
Standard update pull request for a patch release now enters the queue by itself. Before, it asked
for a rebase auto-merge, which GitHub records but never adds to the queue, so someone had to queue
it by hand.

v0.5.3

Repository tooling 0.5.3

A repository that stores files with Git LFS no longer needs its own step in .githooks/pre-push.
The shared pre-push hook now uploads LFS objects with the push, as the hook git lfs install writes
would, once pnpm check passes. It does this only when git-lfs is installed and .gitattributes
has a filter=lfs rule, so nothing changes for a repository that doesn't use LFS.

If you added git lfs pre-push to your repository's .githooks/pre-push, remove it after updating;
the file then matches the standard's copy again and pnpm standards:check stops warning about it.

v0.5.2

Repository tooling 0.5.2

Nothing changes in how your repository works. This patch makes the Standard update workflow finish
its job on its own.

• The update commits and pushes with the repository's git hooks switched off. Installing
  dependencies turns those hooks on, so before this the push ran the full pre-push check, end-to-end
  tests included, and a template's regenerated tree left a hook pointing at deleted files.
• GitHub holds the workflow runs of a pull request that a workflow's own token opened until someone
  approves them. The update now approves the runs it started, so Validate runs and a patch update
  merges itself. If the token may not approve them, the run fails after opening the pull request and
  says so; a maintainer approves the runs on the pull request.
• ci.yml no longer needs a workflow_dispatch trigger for updates.

A repository on 0.5.0 or 0.5.1 whose own update failed for either reason needs this release applied
once by a maintainer with standards/propose.ts; after that it updates itself.

v0.5.1

Repository tooling 0.5.1

Nothing changes in how your repository works. This patch fixes the maintainer script that gives a
repository its first Standard update workflow, and makes a missing workflow_dispatch trigger
easy to spot.

• Rerunning standards/propose.ts from a checkout still on the update branch no longer closes that
  branch's own pull request. An unchanged run now closes a same-release pull request only when the
  default branch on GitHub already vendors the release.
• A tracking ref left from an update branch GitHub has deleted no longer makes the next push fail.
• When ci.yml has no workflow_dispatch trigger, the Standard update run now says so and fails
  after opening its pull request, instead of stopping with an unexplained error.

This is a patch release, so its update pull request merges itself once Validate passes. It is the
first release to reach repositories through their own Standard update workflow.

v0.5.0

Repository tooling 0.5.0

A repository now keeps itself on the standard. Updating to 0.5.0 adds a daily Standard update
workflow. When a newer release exists, it applies that release with the release's own updater and
opens a pull request. A patch release's pull request merges itself once Validate passes; a minor
release's waits for a maintainer, because a minor release can change how the repository works. The
workflow uses only its own token, so there is nothing to set up. It dispatches ci.yml to run
Validate on the pull request it opened, so ci.yml needs a workflow_dispatch trigger, as the
examples' has.

The update also points .claude/settings.json at the installed release, so the contribution plugin
matches the vendored standard.

Nothing else changes how your repository works yet. Three new rules only warn, and v0.6.0 will
enforce them. Fix what they report before then:

• pnpm standards:check warns about files the standard owns that your repository changed:
  .githooks/*, .codex/hooks.json, .agents/plugins/marketplace.json,
  .github/actions/setup-node-pnpm/action.yml, and .editorconfig, and about a .prettierrc file
  that replaces prettier.config.js. From v0.6.0 the check fails and the update restores the
  standard's copies. Make changes to those files in repository-tooling instead.
• lvbt check contract warns about a shared catalog entry in pnpm-workspace.yaml pinned to a
  different version than the standard's catalog. From v0.6.0 the update moves those entries and the
  check fails on any that differ. Entries only your repository uses stay yours.
• The commit hook warns about ci as a commit type or scope. It behaved exactly like chore in
  every changelog and release tool; use chore. From v0.6.0 the hook rejects ci, and the update
  removes it from .lvbt/commit-scopes.txt.