distributor/docs/roadmap/implementation.md

Roadmap

This directory contains only future, deferred, or aspirational work for distributor. Implemented behavior is documented in the current user, operator, internal, policy, integration, and example documentation:

• README.md
• docs/cli.md
• docs/config.md
• docs/operations.md
• docs/troubleshooting.md
• docs/internal/
• docs/integrations/markdown.md
• docs/policy/
• examples/

distributor currently supports local, SSH/SFTP, and S3-compatible source and destination backends; producer bundle creation through pkg/bundle and distributor manifest create; configured source validation and inspection; Markdown sidecar and index.html publication; archive and fixed destination path mapping; destination link metadata; shared text/JSON CLI output; and managed destination replacement behavior.

Future Work

These items are not implemented. They should not be documented as current behavior outside docs/roadmap/ unless a future implementation adds them.

CLI And Status Output

• Add a root-global output flag only if the command parser is later refactored around shared root options.
• Add output formats beyond text and json only if a concrete consumer requires them.
• Add a versioned JSON schema reference after the first JSON-capable release.
• Add destination-state inspection behind an explicit flag such as --with-destinations if operators need fan-out status diagnostics from inspect.
• Add additional status or inspection presentation for destination primary links beyond the current run --format json result model.

Producer Workflows

• Add a no-write manifest creation mode, such as writing manifest JSON to stdout, if producer pipelines need to capture manifests directly.
• Add broader producer workflow helpers, such as richer ignore rules or template scaffolding, if real producer use cases require them.
• Add remote or storage-backed producer writers only if producer applications need to assemble bundles outside the local filesystem.

Publication And Transform Behavior

• Add a separate collection or site-index transform if distributor needs multi-page aggregation.
• Add richer transform metadata only if future state consumers need more than the transform name and output path.
• Add custom HTML index output names only if fixed index.html is too limiting for real deployments.
• Add richer fixed-destination source selection policies if deployments need something other than newest-by-created.
• Add stricter handling for equal latest timestamps if timestamp ties become common in producer workflows.
• Add higher-level status or approval workflows for fixed-root replacements if dry-run output is not enough operational protection.
• Add richer link policies only if auto, html, and source prove insufficient.

State And Compatibility

• Define a post-release destination state schema bump policy before introducing materially incompatible state changes.
• Add warning-only digest mismatch handling only if an operator workflow needs publication to continue after validation failures.
• Add compatibility parsing for legacy SSH URI config only if migration support is required.

Backends, Security, And Deployment

• Add authentication mechanisms beyond the implemented SSH agent/key and S3 credential paths only when a concrete backend workflow requires them.
• Add broad recursive destination deletion outside managed bundle paths only if a future design can preserve the current safety boundary.
• Add concurrent fan-out publishing only if runtime profiling shows it is needed.
• Add streaming, resumable, or multipart S3 uploads only if object sizes make the current write path insufficient.
• Add cloud-provider-specific IAM integration docs only when the repository includes tested provider-specific behavior.
• Add repository-managed packaging, release, and deployment automation when the release process is ready to be standardized.

Roadmap Maintenance

When adding future roadmap work:

• describe user-visible behavior and safety boundaries;
• define which current docs must change after implementation;
• keep examples secret-free and runnable or clearly environment-gated;
• keep workflow labels out of production code, tests, config fields, and user-facing documentation;
• run focused tests for the changed behavior and go test ./... for cross-package changes.