Rebuild the public face for v1.8.0: new demos, README cut to 139 lines

[xmpuspus]

The README led with a hero GIF from 2026-05-01. It showed init, cost, validate, export terraform and export pulumi-ts, and none of review, compliance, plan or integrate, which are the v1.5.0 to v1.7.0 differentiators. 134 of its 251 lines, 53%, were six stacked "What's new" sections going back to v1.3.0.

No version bump. This is docs and assets only, so 1.8.0 stays. Nothing is tagged and nothing goes to PyPI.

The four GIFs the README embeds all show 1.8.0, and total 5.7 MiB

GIF	State	Size	Length
cloudwright-hero.gif	re-recorded	300 KB	30s
cloudwright-review-demo.gif	re-recorded	328 KB	20s
cloudwright-controls-web-demo.gif	trimmed, not re-recorded	2.4 MB	27s
cloudwright-smart-canvas-demo.gif	current, unchanged	2.7 MB	19s

The hero runs init, cost, compliance and plan against the three_tier_web template, so it needs no LLM call and reproduces exactly. It ends on Verdict: DEPLOYABLE from terraform validate. The tape hides the 15s terraform wait and prints that duration on screen, so the GIF does not imply plan is instant.

The review demo is new. cloudwright review scores the patient-portal spec 39/100 with 15 findings and 8 blocking, then compliance --traceability maps each component and Terraform resource to a violated HIPAA control. Both commands unset the API keys first, because neither needs one.

The controls web demo was 39s, and 15 of those were a Running plan... spinner. I cut that segment with ffmpeg and held the final frame. That is post-processing, not a re-record, so the do-not-re-record constraint holds. 3.5 MB to 2.4 MB.

Verification: 4 frames extracted per GIF with ffmpeg and read back, 16 in total, against the final optimized bytes.

12 orphaned GIFs deleted, 17.2 MiB

Nine older recordings (databricks, demo, dryrun, schema, security, v035, v040, v100 at 9.3 MB alone, and v110), the two MCP recordings, and controls-demo. Summed from the blob sizes with git cat-file -s, not from du.

The debt list counted 11. controls-demo.gif is the twelfth: the new hero covers compliance and plan on the same spec, so it is redundant. Its recipe, scripts/controls_demo.tape, goes with it. scripts/review_demo.tape moves to examples/tapes/cloudwright-review.tape next to the hero tape.

I grepped every basename across the whole repo before deleting, not just README and docs/*.md. Two historical audit files under docs/audits/ mention cloudwright-demo.gif in prose. Those are records of a past state, so I left them.

A deliberate non-deletion: the README no longer embeds any of the 10 files in docs/screenshots/, which the task protected from re-recording. They are now referenced only by CHANGELOG.md and their generator, scripts/ui_screenshots.py --readme. I left all 10. They regenerate on demand and the changelog points at them, so they are not the same category as the 12 above. Flagging it as a decision, not an oversight.

The hero tape pointed into a worktree that could vanish

It hardcoded a path into .claude/worktrees/v1.3-audit-fixes and sourced that worktree's venv. That worktree still exists and resolves to 1.8.0 by luck. Prune it and vhs records a broken shell, exits 0, and overwrites the GIF with garbage.

My first fix replaced it with an absolute path to this machine's checkout, which is the same bug wearing a different hat: it would break in every clone. Both tapes now resolve the checkout with git rev-parse --show-toplevel, so neither names a machine path. I tested this by running the tape from outside the repo: it now fails visibly, with the error on screen, instead of recording a bare prompt.

The old tape also ran rm -rf demo relative to its cwd. Repointed at the repo root that would delete at the root, so the new tapes work inside the gitignored scratch area.

README: 251 lines to 139, and every heading states its finding

One What's new section, for v1.8.0. Earlier releases get one line and a CHANGELOG link. Zero em-dashes, down from 9. The version-stamped Smart Canvas + Module Catalog (v1.2) heading is gone.

Read only the headings and the story is there: a prompt produces a spec, a cost, a control-mapped report and Terraform; every finding carries the control ID it violates; the review needs no API key; canvas edits never call the model; one MCP server reaches 11 coding agents.

Three claims were wrong or unchecked, and all three are now verified from source:

• 114 service keys, not 112 (prompts.PROVIDER_SERVICES, summed per provider: aws 47, gcp 26, azure 29, databricks 12).
• 11 harnesses, confirmed against cloudwright integrate --list.
• 22 tools in 9 groups, confirmed by counting @mcp.tool decorators across the registry.

One heading claimed more than the section proved: "grade, lint and diff a spec" named diff, which is a real command but is not one of the nine listed. It now reads "grade, scan and compare".

All 14 links and 3 anchors in README.md resolve, checked with a loop over <img src=, ![]() and [](target), with GitHub's slug rule applied to the anchors.

docs/cli-reference.md documents integrate, the last of 25

Full options table, the three modes, all 11 harnesses, and the --write and --force behaviour. Its mcp --tools row also gained review, compliance and plan. Those three groups shipped in 1.7.0 and were never documented.

Verification

• ruff check packages/ clean. ruff format --check packages/ clean, 285 files.
• Full suite per package, root .env hidden and env -u ANTHROPIC_API_KEY -u OPENAI_API_KEY: core 1392 passed / 22 skipped, web 152 / 68 skipped, cli 137, mcp 35. Zero failures, matching the v1.8.0 baseline exactly.
• 16 GIF frames read back. Both re-rendered tapes verified again after the portability fix.

Three code bugs found and not fixed here

All three are code changes, and this PR is docs and assets only.

1. oscal.py:24 hardcodes _CW_VERSION = "1.6.0", so every OSCAL component-definition reports 1.6.0 while the tool is 1.8.0. I kept it out of the review GIF by showing the traceability table instead of the OSCAL metadata block.
2. mcp_cmd.py:13 still advertises six tool groups in its --help string. The server accepts all nine, since the value passes straight to create_server, so only the help text is stale.
3. cloudwright compliance --fail-on none prints Status: FAILED (fail-on=none), which reads as a contradiction. Dropping the flag gives the clearer Status: PASSED (fail-on=high).

Reviewed by Xavier Puspus