Roadmap

Roadmap

Status: draft. The milestone contents are a proposal for discussion, not a commitment. No dates are given on purpose — the ordering is the useful part, and it is driven by dependencies, not by calendar.

Ordering principle

Read-only before write, local before remote, and the config plus output plumbing first — because every later command depends on it and retrofitting a stable JSON envelope is painful.

M1 — Useful read-only core

The smallest set that makes the tool worth installing. Everything here is read-only, so a mistake cannot damage the network.

Item	Notes
Project skeleton	Maven build, picocli command tree, fat JAR, distribution archive.
Configuration	File discovery, network profiles, environment overrides, peppol config show.
Output plumbing	text and json renderers, the stable JSON envelope, exit code mapping, stdout/stderr split.
Identifiers	peppol id validate, peppol id inspect.
DNS / Discovery	peppol dns hash, peppol dns resolve with the step-by-step chain.
SMP read	peppol smp service-group, peppol smp metadata, peppol smp verify-signature, peppol smp can-receive.
Code lists	peppol codelist list, peppol codelist search, offline bundled data, and active/deprecated/removed state filtering.
Document type aliases	Resolving short names to full document type IDs, with ambiguity as an error. Needed early, because every other command's usability depends on it. Depends on Open Questions #9.
Shell completion	Generated scripts shipped in the archive.
Test tiers T1–T3	Unit, component and CLI integration tests, plus the golden-file JSON contract tests. Set up with the code, not after — see Testing Strategy.
Test tier T6	Packaging tests, which is also what catches the shaded-JAR SPI problem.

M1 is done when peppol smp can-receive gives a correct answer with a correct exit code for a real participant on both networks, and its JSON output is documented.

M2 — Diagnostics and trust

Turns the tool from a lookup client into a diagnostic one. The theme is why does it not work.

Item	Notes
Certificates / PKI	peppol cert verify, peppol cert info, expiry and revocation checking, Seat ID extraction.
Keystore helpers	Inspection, P12 conversion, CSR generation.
Directory	peppol dir search via the published phoss-directory-searchclient, peppol dir businesscard (fetched from the participant's SMP), and dir index / unindex / indexed via phoss-directory-client. No Directory protocol code in this project.
Endpoint diagnostics	peppol endpoint tls, peppol endpoint http. No AS4.
Registration conformance checks	Now concretely specifiable from the specs: U-NAPTR URI rules (https only, no userinfo, no query/fragment), the SMP port-443 and TLS requirement, the signature algorithm profile, and the redirect certificate cross-check. These turn "it seems to work" into a pass/fail verdict and are cheap once the read path exists.
Phorm validation	peppol validate file against a configured instance, with local document type auto-detection.
Deprecation flagging	Straightforward — the three-valued state comes from the enums. Note codelist diff and codelist update are rejected, so code lists are refreshed by upgrading the tool.
Test tier T4	Live read-only tests against the test network, nightly.

M2 is done when a failing exchange can be diagnosed end to end — registration, metadata, certificate trust, TLS, reachability — from one tool.

M3 — Write operations

First point at which the tool can change state, so it comes last among the core areas and needs the confirmation and dry-run conventions settled before it starts.

Item	Notes
SMP write	Create, update and delete participants and endpoints via the SMP management API. Scope depends on Open Questions #10 — the API is not standardised, so "which SMPs are supported" must be answered first.
SML	SMP record read/create/update/delete, participant add/remove (single and CreateList/DeleteList batch), List() paging, and the two-step migration with key generation. All authenticated via mTLS.
Combined onboarding	peppol participant onboard / offboard, doing the SMP and SML halves in the right order with clear half-state reporting. Arguably the single most useful M3 command.
Bulk	peppol bulk lookup over a CSV, plus SMP bulk import and export.
Safety rails	--dry-run, and an explicit confirmation or --yes for every destructive action. > TODO(decide): make --dry-run the default for write commands?
Test tier T5	Live write tests against project-owned test-network resources, manually approved. Blocked unless such resources exist — see Testing Strategy.

M3 is done when an SMP operator can do their routine participant maintenance without the web UI.

Upstream dependencies

Some milestone contents depend on gaps in the libraries rather than on work in this project. These should be scheduled upstream first, or the features move milestone. Full detail in Library Gaps.

Needed for	Gap	Milestone at risk
peppol id check-value (GLN)	GLN algorithm exists in ph-masterdata (GTINValidator.isValidGLN) but is not wired into the peppol-id-checks SPI	M1 — small upstream fix, no new dependency
peppol validate *	No reusable Phorm client	M2 — a private client works, but duplicates phoss-ap
SMP write commands	No standardised SMP management API (SMP 1.4.0 §3)	M3 — scope must be decided, not discovered
peppol cert seat-id	Only the certificate-field read is missing; SPIDHelper decodes the rest	M2 — low risk
Config discovery	ph-config has no XDG/%APPDATA% discovery	M1 — needed either way, better solved upstream

Later

Deliberately unscheduled; each needs its own decision first.

Item	Blocked on
MLS generation	Whether generating (as opposed to parsing) belongs in this tool — Open Questions #4. Parsing itself is a candidate for M2/M3 once the area is agreed.
GraalVM native image	Open Questions #1.
Package manager distribution	Homebrew, Scoop, distro packages — depends on the packaging outcome in Architecture.