# 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.