feat: add external CLI support for image upload/delete

[minodisk]

Summary

• Add support for external CLI commands for image upload and delete operations via -u and -d flags
• Introduce Storage interface to abstract image storage (Google Drive vs external CLI)
• Support template variables ({{mime}}, {{id}}, {{env.XXX}}) in upload/delete commands
• Environment variables DECK_UPLOAD_MIME and DECK_DELETE_ID are passed to external commands

Motivation

This provides a workaround for #372.

In restricted Google Workspace environments where public file sharing is prohibited, Google Drive cannot be used for image storage. This feature allows users to use alternative storage backends (e.g., GCS, S3) via external CLI tools.

Usage

deck apply -u "my-uploader upload --mime {{mime}}" -d "my-uploader delete --id {{id}}" slides.md

External CLI Protocol

Upload command:

• Receives image data via stdin
• Environment variable DECK_UPLOAD_MIME contains the MIME type
• Template variable {{mime}} is also available
• Must output: public URL (line 1) and uploaded ID (line 2)

Delete command:

• Environment variable DECK_DELETE_ID contains the uploaded ID
• Template variable {{id}} is also available

Example Implementation

reprint - A GCS-based image storage CLI that implements this protocol

deck apply -u "reprint-gcs upload --mime {{mime}}" -d "reprint-gcs delete --object-id {{id}}" slides.md

Test plan

• Tested with external storage CLI (reprint-gcs → GCS)
• Tested with Google Drive storage (default behavior)
• Verified both storage paths work correctly

🤖 Generated with Claude Code

[Songmu]

This is a good idea and a challenge we want to solve.
It's a clean design, but we need to discuss whether introducing this complexity is necessary and whether this protocol is the right approach.

[minodisk]

Thank you for the feedback!

On Complexity

The design intentionally keeps the default behavior unchanged — users who can use Google Drive don't need any additional configuration. The complexity only applies to users like me who face Google Workspace organizational restrictions and cannot attach images via Google Drive.

I also tried implementing GCS support directly inside deck, but it felt unclean to embed specific storage implementations. Delegating to external CLI keeps deck's core simple and allows users to choose their preferred storage backend.

On Protocol

For the input side, I referenced laminate's protocol — thank you for that elegant design!

For the output (which returns 2 values: public URL and uploaded ID), I went with a simple line-based format, but I'm honestly uncertain about this choice and thinking JSON might be better for extensibility. I'd appreciate any feedback on the protocol as a whole if you have suggestions for a better approach.

[github-actions]

Code Metrics Report

	main (25012a6)	main (25012a6)	+/-
Coverage	64.6%	64.6%	0.0%
Code to Test Ratio	1:0.9	1:0.9	0.0
Test Execution Time	5m49s	7m14s	+1m25s

Details

  |                     | main (25012a6) | main (25012a6) |  +/-   |
  |---------------------|----------------|----------------|--------|
  | Coverage            |          64.6% |          64.6% |   0.0% |
  |   Files             |             31 |             31 |      0 |
  |   Lines             |           3405 |           3405 |      0 |
  |   Covered           |           2203 |           2203 |      0 |
  | Code to Test Ratio  |          1:0.9 |          1:0.9 |    0.0 |
  |   Code              |           7020 |           7020 |      0 |
  |   Test              |           6581 |           6581 |      0 |
- | Test Execution Time |          5m49s |          7m14s | +1m25s |

Code coverage of files in pull request scope (66.3% → 66.3%)

Files	Coverage	+/-	Status
cmd/apply.go	19.4%	0.0%	modified
deck.go	73.5%	0.0%	modified
md/cel.go	45.5%	0.0%	modified
md/md.go	79.2%	0.0%	modified
preload.go	80.6%	0.0%	modified

---

Reported by octocov