Skip to content

feat: add standalone SVG delivery - #272

Open
user01010111 wants to merge 1 commit into
tt-a1i:mainfrom
user01010111:feat/standalone-svg-delivery
Open

feat: add standalone SVG delivery#272
user01010111 wants to merge 1 commit into
tt-a1i:mainfrom
user01010111:feat/standalone-svg-delivery

Conversation

@user01010111

Copy link
Copy Markdown

Problem and value

Fixes #241.

Archify can already export a good standalone SVG from the Viewer, but non-interactive documentation and CI pipelines have no supported way to request the same file. Their current workaround is to drive the HTML Viewer through a browser.

This extends the existing verified delivery command:

archify deliver architecture spec.json diagram.svg --format svg --theme auto

The CLI and Viewer use the same zero-dependency SVG finaliser. SVG delivery therefore keeps the existing frozen-input validation, safe-path and alias guards, repository-evidence checks, atomic replacement and structured receipt instead of introducing a second command with a separate delivery contract.

Scope

  • What changed:
    • Added deliver --format svg with --theme auto|light|dark.
    • Added standalone SVG checks for document shape, intrinsic size, background, themes, external resources, accessibility and transient Viewer state.
    • Shared one SVG finaliser between CLI delivery and Viewer export.
    • Documented the format and added coverage across all five diagram types, all four presets, brands, Unicode and repository evidence.
  • What deliberately did not change:
    • HTML remains the default and its output and receipt contracts are unchanged.
    • No second export command, speculative format framework, schema change or new dependency was added.
    • PNG, JPEG, WebP and WebM remain Viewer exports.
  • No unrelated changes: confirmed. The wider generated-file diff is the required refresh of HTML examples, Gallery artefacts, proof metadata and archify.zip after the shared Viewer template changed.

Stability impact

  • Compatibility and migration risk: low. Existing HTML calls remain byte-identical, explicit --format html matches the default, and ambient internal SVG variables cannot alter normal render, validate or HTML delivery.
  • Renderer, validator, package, or generated-artifact risk: the shared finaliser touches Viewer export, so it was checked through current Viewer/CLI structural and decoded-pixel parity, a pre-change Viewer baseline, raster/WebM regression tests, generated-artifact freshness and the packaged zero-install Skill.
  • Failure behaviour and rollback path: malformed options, unsafe paths, aliases, renderer failures and SVG-check failures exit non-zero and preserve the previous trusted output. The final replacement remains an atomic same-directory rename.
  • The SVG retains the existing Viewer export's CSS-variable theming. Chromium parity is exact. librsvg 2.62.3 does not reproduce those colours correctly, but the pre-change and staged exports produce identical librsvg raster output, so this is an existing consumer limitation rather than a regression in this change.

Tests run

  • ARCHIFY_CHROME=/usr/bin/chromium npm test: 1,034 tests; 1,026 passed, 0 failed and 8 environment/version-gated skips.
  • ARCHIFY_CHROME=/usr/bin/chromium npm run test:webm: WebM/export smoke passed; site-language integration passed 7/7 with no skips.
  • Node 18.20.8, verified against Node.js's published SHA-256: node --test test/svg-delivery.test.mjs passed 6/6, including the complete Viewer/CLI pixel matrix and packaged-Skill failure preservation.
  • Node 22.23.2, verified against Node.js's published SHA-256: node --test test/release-package-gates.test.mjs passed 18 tests with the intentional non-22 guard skipped; all five Node 22-only canonical ZIP gates passed.
  • Node 26.8.1: the inverse non-22 archive guard passed.
  • Current Viewer versus direct CLI SVG: 10 diagrams across auto, light and dark; identical normalised structure and zero differing RGBA channels.
  • Pre-change Viewer versus staged CLI SVG: identical normalised structure and zero differing RGBA channels in auto, light and dark. The only raw markup difference was removal of an inert empty style attribute.
  • Default HTML and explicit --format html: byte-identical, including the unchanged receipt shape.
  • Fixed light and dark SVG delivery: 9/9 HTML checks and 16/16 total SVG checks for each theme.
  • Extracted archify.zip: package smoke passed on Linux; all 78 packaged files and modes match the clean staged Skill exactly; unzip -t passed.
  • git diff --check, README parity, generated-artifact freshness and local-path leakage checks passed.
  • Upstream CI remains pending.

The broad-suite skips were five canonical ZIP checks rerun successfully under Node 22, two browser checks rerun successfully through the serial integration command, and the unrelated MCO fixture requiring a matching external repository checkout.

Visual evidence

Human before/after review passed. Automated comparison also found zero differing decoded RGBA channels between the pre-change Viewer export and this CLI output in all three theme modes. No screenshot is attached because the exact pixel comparison is reproducible in the test suite.

Generated artifacts

  • Rebuilt archify.zip with Node 22; SHA-256: f7e0c798282ab89bec7fd3c486d74061029f40bbfa310987ec62cae755a68aae.
  • Regenerated packaged examples and root examples from the shared template.
  • Regenerated Gallery artefacts and manifest.
  • Regenerated the README live proof and receipt.
  • Updated the Checkout comparison artefact and receipt.

Checklist

  • I used a minimal focused change and preserved existing typed JSON behaviour unless the issue requires a contract change.
  • I ran the relevant targeted tests and npm test in archify/.
  • I added or updated a regression test for behavioural changes.
  • I checked generated artefacts and package freshness when their sources changed.
  • I removed secrets, private repository content and customer data from fixtures and screenshots.

AI assistance

OpenAI Codex was used for planning, repository analysis, implementation, review, drafting and validation. The human contributor reviewed the output and remains responsible for the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No CLI path to an SVG — deliver produces the HTML viewer, and SVG export lives inside it

1 participant