Roadmap

Ionport already builds and publishes multiple static websites from Markdown. It supports themes, component overrides, tags, automatic internal links, redirects, feeds, sitemaps, live preview, validation, and SSH deployment.

Ionport is intended to be publicly available through GitHub. Anyone should be able to download it, use it, inspect how it works, and contribute to its development.

The next stage is not to make Ionport larger for its own sake. It is to make the existing publishing path safer, easier to install, and easier to trust. New features should remain understandable from the files in the repository.

The phases below describe priorities rather than fixed release dates. Completed items remain visible so the roadmap also records which foundations are already in place.

Phase 1: Publishing safety

The first priority is protecting the path from source files to the public site.

• [x] Run the checker automatically before publication.
• [x] Refuse publication when the checker finds errors.
• [x] Provide an explicit override for exceptional cases.
• [x] Detect route collisions across authored pages, generated tag archives, and redirects.
• [x] Detect redirect loops.
• [x] Preserve the last successful build if a replacement fails.
• [ ] Add more tests for filesystem-level build replacement failures.

This phase makes the existing workflow dependable before adding more ways to publish.

Phase 2: Configuration and validation

Ionport currently uses a deliberately small configuration and front-matter parser. A standards-compliant YAML parser would support the same simple authoring style while handling edge cases more reliably.

• Replace the handwritten YAML parsing with a maintained YAML library.
• Keep front matter portable and avoid Ionport-specific structures where ordinary YAML is sufficient.
• Validate required site settings and supported field types.
• Check URL fragments, image variants, CSS asset references, and duplicate HTML identifiers.
• Improve accessibility guidance for headings, link text, and image descriptions.
• Report configuration errors with exact file and line locations where possible.

Warnings should continue to guide authors without forcing stylistic rewrites.

Phase 3: Tests, packaging, and releases

Ionport should be usable as a tool rather than only as a checked-out repository.

• [ ] Add further regression tests for navigation, component overrides, tags, feeds, redirects, preview rebuilding, and publication settings.
• [x] Add a pyproject.toml and an installable ionport command.
• [x] Define supported Python versions and dependency policy.
• [x] Introduce project versioning and release notes.
• [x] Test installation and site builds in continuous integration.
• [x] Add source backup archives and document what they contain.
• [x] Provide a small example site that can be built independently of the project website.

The source repository should remain sufficient to understand how Ionport works, even when installation becomes more convenient.

Phase 4: Authoring workflow

Small commands can remove repetitive work without hiding the underlying files.

• [x] Create a new site with a minimal valid structure.
• [x] Create a page or article with valid front matter.
• [x] List authored, generated, scheduled, draft, and redirected routes.
• [x] Export a validated static build to a portable directory.
• [x] Schedule publication with a front-matter date.
• [ ] Add dedicated listings for sites and validation findings.
• Clean generated output safely.
• Add quiet and verbose output modes for automation and troubleshooting.
• Offer an optional post-publication check of the deployed website.

These commands should create and inspect ordinary files. They should not become a second content model.

Phase 5: Static search

Ionport can add search without introducing a server-side application.

• Generate a compact search index during the build.
• Provide a theme-level search page and interface.
• Index titles, descriptions, headings, tags, and selected body text.
• Allow individual pages or fields to opt out.
• Keep the generated index replaceable by another search implementation.

Search should remain optional so that small sites do not pay for a feature they do not need.

Git-based publishing

Ionport will provide documented GitHub Actions recipes for automatic builds and deployment after changes are pushed to GitHub. The recipes will use Ionport's normal build and check commands rather than introducing a separate publishing model.

Direct SSH publishing will remain available for authors who publish from their own computer. GitHub-specific authentication, triggers, and hosting integration will stay in workflow recipes instead of becoming dependencies of the Ionport core.

Later possibilities

The following ideas may be useful, but they require design decisions before they belong to the committed roadmap.

Extension interface

A plugin system would increase flexibility but also create a long-term compatibility burden. Before adding one, Ionport should identify concrete extensions that cannot be handled cleanly by themes, components, build hooks, or small external tools.

Deeper AI workflows

AI can help draft, review, classify, link, and maintain content. Any integration should preserve Markdown as the source of truth, show its proposed changes, and leave publication under the author's control.

Open decisions

The project has not yet committed to answers for these questions:

• What feature threshold should define the first stable release?
• Which real use cases, if any, justify a stable plugin API?
• Should authoring commands remain interactive, or only accept explicit command options?
• Which AI-assisted tasks belong in the core tool rather than in contributor instructions and external automation?

These decisions should be based on working publishing needs. Ionport should prefer a smaller stable core when an external tool can solve a problem clearly.