[bpamiri]

Re-opens #2579 (which re-opened #2578) with the correct conventional-commits scope. Commitlint requires `web/blog`, not `blog`.

Summary

Recovery PR for today's scheduled blog post that failed to auto-deploy. Same pattern as #2551 (Multi-Tenancy recovery).

What happened

The publishing-admin scheduler ran at `2026-05-11 08:19:00`, successfully exported the markdown for this post, and then asked GitDeployer to commit + push it to `develop`. The deploy step failed:

```
2026-05-11 08:19:00 ok lucli-zero-docker-developer-experience
2026-05-11 08:19:00 deploy-fail lucli-zero-docker-developer-experience rebase-failed: Rebasing (1/1)
```

The rebase conflict was on a different file (`multi-tenancy-built-in.md`), not the lucli file. Root cause: GitDeployer naively runs `git rebase origin/develop` on whatever branch the wheels repo working tree happens to be on. At the time, that was `peter/bot-convergence-loop`, which carried already-merged commits — rebasing replayed them onto develop and hit add/add conflicts.

Article content

The post body was already up to date in SQLite (`posts.id=875`, body=12776 chars). After the failed deploy I made five follow-up edits today that the auto-deploy never had a chance to ship:

1. Removed dead `brew install lucli` install steps (the binary is shipped as `wheels` via Homebrew/Scoop — there is no `lucli` on a normal install).
2. Added Windows install via `scoop-wheels` bucket, including the `wheels-be` channel that resolves cleanly pre-GA.
3. Removed all Chocolatey references — that effort was abandoned after the package sat in moderation for ~3 months; added a paragraph explaining the pivot.
4. Added forward-looking note on `dnf` / `yum` / `apt` as the next packaging frontier.
5. Bumped `updatedAt` to reflect the editing pass.

Why this is safe to merge

• No code changes — single new file at `web/content/blog/posts/lucli-zero-docker-developer-experience.md`.
• SQLite (`posts.id=875`) and the .md body match byte-for-byte.
• The post is already `status=published` in SQLite, so the scheduler will not retry the deploy (idempotent by design — see `Post.scheduledDue()`).

Companion PR (already merged)

wheels-dev/wheels-publishing-admin#2 hardens `GitDeployer.cfc` to switch to develop before deploying, which is the structural fix that prevents tomorrow's launch article from hitting the same trap. Merged.

Test plan

• CI passes (commitlint should accept `docs(web/blog):` now, plus the LuCLI test suite + Visual regression)
• Cloudflare Pages picks up the merge and rebuilds blog.wheels.dev
• Article visible at https://blog.wheels.dev/posts/lucli-zero-docker-developer-experience/
• Post appears at top of /posts/ index ahead of multi-tenancy-built-in

🤖 Generated with Claude Code

[wheels-bot]

Wheels Bot — Reviewer A

TL;DR: This is a pure-docs recovery PR adding one new blog post file. The content is accurate, well-written, and honest about what is still in-progress. Commit message and frontmatter both follow established conventions. I have one factual inaccuracy in the CLI command list worth fixing before the post goes live.

Correctness

CLI command conflation in 'What ships in the 4.0 CLI'

File: web/content/blog/posts/lucli-zero-docker-developer-experience.md, around line 107

The post lists:

`wheels dbmigrate latest | up | down | info | diff` handles migrations, including auto-diff for model-versus-schema drift.

This conflates two separate commands into one pseudo-command:

• The standard migration runner in the LuCLI module (cli/lucli/Module.cfc) is wheels migrate latest|up|down|info. The module's migrate() function accepts those four actions and nothing else.
• The auto-diff is a separate CommandBox-era surface: wheels dbmigrate diff (cli/src/commands/wheels/dbmigrate/diff.cfc).

A reader trying wheels dbmigrate latest on a pure LuCLI install would reach the CommandBox command (if installed) or get an error, not the LuCLI migration runner. CLAUDE.md confirms the two surfaces separately: the Migrate row has wheels migrate latest|up|down|info, and the Auto-Migration Quick Reference separately documents wheels dbmigrate diff.

Suggested fix — split the bullet into two:

- `wheels migrate latest | up | down | info` runs database migrations.
- `wheels dbmigrate diff` generates migrations from model-vs-schema diffs (auto-migration).

Docs

The forward link to /posts/wheels-deploy-kamal-port/ resolves -- wheels-deploy-kamal-port.md exists in the blog posts directory. No action needed.

Frontmatter shape and field set match the existing multi-tenancy-built-in.md exactly (title, slug, publishedAt, updatedAt, author, tags, categories, excerpt, coverImage). No issues.

Commits

Single commit:

docs(web/blog): LuCLI and the Zero-Docker Developer Experience (recover failed auto-deploy)

Type docs, scope web/blog -- both on the commitlint allow-list. Subject uses mixed-case proper nouns (LuCLI) which is permitted. Header is 91 characters, under the 100-char cap. Commitlint should accept this.

Security

No code, no secrets, no fixtures. Clean.

---

The wheels dbmigrate conflation is the only factual issue worth fixing before the post goes live -- it will actively mislead readers following along on a pure LuCLI install. Everything else is in good shape.

[wheels-bot]

Wheels Bot — Reviewer B (round 1)

A's review is largely solid -- the wheels dbmigrate conflation finding is accurate and well-sourced against CLAUDE.md. However, A declared it "the only factual issue" and that conclusion is wrong: the same CLI reference section contains a second command inconsistency that A did not flag.

Sycophancy

None detected. A's "well-written and honest" and "everything else is in good shape" are backed by concrete checks (commit message length, frontmatter shape, forward-link existence), not empty praise.

False positives

None detected. A's claim about wheels dbmigrate latest | up | down | info | diff conflating two separate surfaces is correct. CLAUDE.md documents:

• Migration runner: wheels migrate latest|up|down|info
• Auto-diff: wheels dbmigrate diff (separate CommandBox-era surface)

The article smashes them into a single pseudo-command. A read the lines and the reference; the finding stands.

Missed issues

wheels server start | stop | status vs wheels start|stop|status

File: web/content/blog/posts/lucli-zero-docker-developer-experience.md

The "What ships in the 4.0 CLI" section (diff line 117) reads:

wheels server start | stop | status wraps the LuCLI server lifecycle.

CLAUDE.md documents the server commands as top-level: wheels start|stop|status, not as subcommands under a server prefix. The blog post itself contradicts line 117 four paragraphs earlier (diff line 84):

scaffold a throwaway app with wheels new scratch && cd scratch && wheels start

A reader following the CLI reference section would try wheels server start and likely get an error on a standard install. Same failure mode as the wheels dbmigrate issue A caught -- factual inaccuracy in the CLI command table that actively misleads readers. A should have flagged this.

Suggested fix for that bullet:

- `wheels start | stop | status` wraps the LuCLI server lifecycle.

Verdict alignment

A used COMMENTED state without an explicit approve/request-changes verdict, which is appropriate given the presence of a factual issue. But A's conclusion ("the only factual issue") is inaccurate -- there are two.

Convergence

Not aligned. A needs to acknowledge the wheels server inconsistency as a second fix before the post goes live. Once A's review covers both command errors, the findings are concrete and actionable and we can converge on request-changes.

[wheels-bot]

Wheels Bot — Reviewer A response (round 1)

B is correct. I audited the CLI reference list in the diff sequentially, found the wheels dbmigrate conflation, and stopped looking. I did not scan the remaining bullets in the same list for the same class of error. The wheels server start | stop | status bullet is a second instance of the identical failure mode and I missed it.

Conceded points

• wheels server start | stop | status is factually wrong. Diff line ~117 (the CLI surface table, "What ships in the 4.0 CLI") reads:

  `wheels server start | stop | status` wraps the LuCLI server lifecycle.

  CLAUDE.md's Development Tools table documents the server commands as top-level: wheels start|stop|status (no server prefix). The blog post's own prose four paragraphs earlier (diff line ~84) also uses wheels start:

  scaffold a throwaway app with wheels new scratch && cd scratch && wheels start

  A reader following the CLI reference section and trying wheels server start on a standard LuCLI install would get an error. Same failure mode as the wheels dbmigrate issue I flagged. B was right to call this out, and I was wrong to conclude the conflation was "the only factual issue."

  Suggested fix:

  - `wheels start | stop | status` wraps the LuCLI server lifecycle.
  

Defended points

None. B raised no false positives against my review, and I have no new objections to B's analysis.

Updated verdict

Request changes. There are two confirmed factual CLI command errors in the "What ships in the 4.0 CLI" section: (1) wheels dbmigrate latest | up | down | info | diff conflating two separate surfaces, and (2) wheels server start | stop | status using a non-existent server subcommand prefix. Both should be fixed before the post goes live.

[wheels-bot]

Wheels Bot — Reviewer A

TL;DR: This is a follow-up commit on a pure-docs blog post that addresses both factual CLI command errors flagged in the previous review. Both fixes are correct. The remaining file is clean. One pre-existing minor nit on engine support language is worth a quick pass before the post goes live, but it does not block the merge.

Correctness

Previous findings resolved.

The two CLI errors flagged in the prior review have been correctly addressed in commit 6d6647e:

1. wheels dbmigrate latest | up | down | info | diff → split into two separate bullets:

   • wheels migrate latest | up | down | info (LuCLI module, matches CLAUDE.md Development Tools table)
   • wheels dbmigrate diff (auto-migration surface, matches CLAUDE.md Auto-Migration Quick Reference)

2. wheels server start | stop | status → wheels start | stop | status (top-level server commands, consistent with CLAUDE.md and with the post's own prose at line 84: wheels start).

Both fixes match the canonical surfaces documented in CLAUDE.md. The commit message attributes both changes explicitly and correctly.

Pre-existing minor nit: engine support claim (not introduced by this commit).

File: web/content/blog/posts/lucli-zero-docker-developer-experience.md, line 26

The framework supports Lucee 5, 6, 7, Adobe ColdFusion 2018, 2021, 2023, 2025, plus BoxLang, across seven databases.

CLAUDE.md states: "compose.yml also defines lucee5, adobe2018, adobe2021 services for historical reasons; they are NOT in the CI matrix and should be considered unsupported for new development." Framing all eight engine versions as uniformly "supported" may set false expectations for users targeting Lucee 5 or Adobe 2021. Consider tightening the sentence:

The framework targets Lucee 6, 7, Adobe ColdFusion 2023, 2025, and BoxLang across seven databases,
with legacy Compose definitions for Lucee 5, Adobe 2018, and Adobe 2021 that are not CI-gated.

Or simply drop the legacy engines from the sentence and add a parenthetical if needed.

Minor nit: "Wheels CLI installers" link targets macOS-only repo.

File: web/content/blog/posts/lucli-zero-docker-developer-experience.md, line 133

The "Wheels CLI installers" anchor points to github.com/wheels-dev/homebrew-wheels. A Windows user clicking "Wheels CLI installers" would land on the Homebrew tap, not Scoop. Consider pointing the anchor to a neutral landing page or dropping the outer anchor and letting the inline Homebrew tap / scoop-wheels links carry the platform-specific navigation.

Commits

Both commits conform to commitlint:

Commit	Type	Scope	Subject
66827a2	docs	web/blog	LuCLI and the Zero-Docker Developer Experience (recover failed auto-deploy)
6d6647e	docs	web/blog	correct CLI surfaces in LuCLI post

Both types and scopes are on the allow-list. Headers are under 100 characters. No ALL-CAPS subjects. Commit 6d6647e documents the "why" (bot review, specific error class, CLAUDE.md reference) in the body — good practice.

Security

No code, no secrets, no fixtures. Clean.

Tests

Not applicable — docs-only change.

---

The blocking issues from the previous review are resolved. The engine support nit and the installer link nit are worth a quick editorial pass but do not affect technical accuracy of the CLI surface being described. The post is safe to merge if the maintainer is comfortable with the current engine language.