Future work

This page tracks product ideas that are intentionally not part of the current implementation contract. Items listed here are not discarded; they are held until real operating experience proves the right shape.

Secret handling hardening

Secret values are resolved on the controller and masked before persisted output. Future hardening can focus on rotation workflows, provider-specific diagnostics and optional policy rules that restrict which providers may be used in selected environments.

Additional schema and output formats

Automax exports JSON Schema and supports JSON output for plan/run/resume operator summaries. Future work may add additional formats without changing the command shape, for example:

automax schema export --format=yaml
automax run --format=yaml ...

Policy engine

A future policy layer may validate jobs before execution against local operating rules. Example use cases:

require approval for os.package.upgrade
forbid recursive fs.dir.remove on production
forbid shell execution for selected targets
require --lock on production deploy jobs

The policy engine should stay separate from the job DSL so teams can apply different guardrails to the same job definition in lab and production.

Risk or danger summary

plan or explain may eventually classify potentially dangerous operations:

low: fs.dir.check, fs.file.check, fs.symlink.check
medium: system.service.restart, fs.file.template, data.transfer.upload
high: os.package.upgrade, identity.user.remove, fs.dir.remove recursive=true

This would give operators a quick review surface before running jobs on real targets.

External plugin distribution

External plugin ZIP packages include Automax compatibility metadata and per-file SHA-256 checksums, can be verified with automax plugins verify-package, installed into locked local plugin directories with automax plugins install, updated with automax plugins update, removed with automax plugins uninstall, indexed with automax plugins index, and loaded directly or from installed plugin directories with --plugin-path. Local package management is intentionally lock-based. Optional signature workflows can be layered on top without changing the source-loading model.

Deploy plugins

Automax already has the primitives for release-style workflows:

data.transfer.upload
data.archive.tar.extract
fs.symlink.create
fs.symlink.remove
system.service.restart
network.http.check
network.http.wait

A future deploy.* plugin family may wrap these into higher-level release and rollback operations once the exact operational pattern is proven on real jobs.

Native cloud inventory providers

Dynamic inventory supports file, command and HTTP providers. Native cloud inventory providers may be added later if the command/HTTP model is not enough:

inventory.aws_ec2
inventory.azure_vm
inventory.gcp_compute
inventory.kubernetes

These should be inventory providers, not job-action plugins.

Operational completeness roadmap

The current plugin catalog already covers backup/restore operations, package install controls, explicit PAM hardening primitives and generated plugin metadata. Near-term work should therefore focus on evidence, consistency and operator trust rather than adding broad new plugin namespaces.

Runtime evidence packs

Automax should grow repeatable evidence packs for disposable Debian-like and Red Hat-like hosts. Each pack should capture the job, inventory, command line, run summary and selected artifacts for a bounded plugin family:

account access and sudo
package manager operations
systemd and service operations
firewall and network checks
storage and filesystem safeguards
database optional-driver smoke
backup and restore operations

These packs should stay outside normal unit tests when they need privileged hosts, but the commands and expected outputs should be documented and version-controlled.

Release guardrails

scripts/release-check.sh validates generated plugin documentation, plugin smoke runbook indexes, plugin coverage gates, tests, strict docs and package smoke. Future work in this area should focus on repository publishing policy and release evidence retention, not on another local release gate.

Plugin coverage and quality gates

automax plugins coverage now renders the registered plugin matrix, including category, remote-session, check-mode, dry-run, manual preview, diff preview and external tool coverage. --strict is the release gate for metadata and preview quality regressions. Future work in this area should focus on runtime evidence from disposable hosts rather than another static registry report.

PAM and account-access evidence

PAM hardening uses explicit, service-scoped plugins: security.pam.access, security.pam.faillock, security.pam.pwhistory, security.pam.succeed_if, security.pam.service_line, security.pam.validate, security.pam.stack.facts and security.authselect.check. Future PAM work should preserve the same model: no broad /etc/pam.d/* template rewriter, backups by default for mutating plugins, exact manual commands and read-only validation before authentication-affecting changes.