Publaryn 1.1.0 Roadmap

This working plan captures the next product milestone after the 1.0 baseline. It is intentionally grounded in the current implementation state rather than in speculative greenfield ideas.

Current state snapshot

As of 2026-04-25, Publaryn already ships the documented 1.0 baseline with:

• mounted native adapters for npm/Bun, PyPI, Cargo, NuGet, Maven, RubyGems, Composer, and OCI
• a broad control-plane API for auth, packages, releases, organizations, invitations, teams, delegated access, audit, security findings, and trusted publishers
• a SvelteKit web portal for search, package detail, release detail, settings, MFA, token management, and dedicated organization workspaces
• quarantine-first publish flows, background jobs, operator queue visibility, and release-facing runtime health probes
• strong docs/code alignment across README.md, docs/1.0.md, docs/concept.md, docs/api-routes.md, and the ADR index

That means the next milestone should not try to reinvent the platform surface. 1.1.0 should make the shipped 1.0 contract smarter, more explainable, and more operable.

1.1.0 release theme

Operational and security intelligence on top of the stable 1.0 contract.

The focus for 1.1.0 is:

1. deepen security and package insight on already shipped package and release surfaces
2. improve search and operator experience without widening the architecture into new major product lines
3. keep the 1.0 contract truthful while adding additive, testable, low-drift capabilities

Completed 1.1.0 workstreams

1. Risk posture on package and release detail surfaces

Priority: highest Status: completed

Add a heuristic risk posture to the existing bundle-analysis model and detail pages.

Target outcomes:

• surface unresolved security finding severity directly on package and release detail pages
• combine shipped signals such as install lifecycle scripts, native build hints, and dependency surface into a simple heuristic posture
• keep the scoring additive and explainable instead of introducing opaque magic
• regression-cover the API payloads and the frontend rendering

Delivered scope:

• package and release bundle_analysis payloads include a risk summary with a bounded score, level, worst unresolved severity, finding count, and explanatory factors
• the web portal renders risk posture cards on package and release detail pages
• backend helper coverage and frontend route coverage exercise the scoring and UI

2. Search and discovery depth

Priority: high Status: completed

Build on the existing actor-aware search surface.

Target outcomes:

• keep the existing visibility-aware filters and add better result summaries
• expose package quality/risk/verification hints in search results
• improve default ranking with recent activity and meaningful package metadata
• keep visibility semantics identical to the shipped 1.0 model

Delivered scope:

• search results include discovery hints for risk, unresolved security findings, trusted publishing, latest release state, and freshness signals
• the search UI renders those hints without changing actor-aware visibility
• backend and frontend tests cover the added discovery payloads and rendering

3. Operator queue detail and recovery ergonomics

Priority: high Status: completed

Deepen the minimal 1.0 operator surface around GET /v1/admin/jobs.

Target outcomes:

• expose job-level failure details and richer queue diagnostics
• add targeted retry or rerun affordances for safe recovery workflows
• make recovery state visible without requiring ad hoc SQL inspection
• update operator runbooks alongside any recovery changes

Delivered scope:

• operator job responses now include retry eligibility, stale-lock status, and recovery hints
• safe failed-job retry and stale-lock recovery endpoints were added under /v1/admin/jobs*
• OpenAPI coverage and the queue recovery runbook document the recovery flows

4. Ecosystem metadata and dependency views

Priority: medium Status: completed

Expand the existing metadata and analysis surfaces instead of creating a second parallel model.

Target outcomes:

• improve dependency rendering for ecosystems that already store structured metadata
• keep package detail and release detail analysis consistent across ecosystems

Delivered scope:

• release detail pages render normalized dependency groups from stored Cargo, NuGet, RubyGems, Composer, and Maven metadata when available
• dependency counts and representative names are grouped consistently across ecosystems without introducing a parallel metadata store
• frontend helper coverage protects the normalization behavior

5. Compliance and delegated-access history

Priority: medium Status: completed

Add time-aware access visibility on top of the current audit foundation.

Target outcomes:

• answer “who had access when?” for package, repository, and namespace grants
• export access-history views for organization admins and auditors
• extend audit metadata only where it materially improves governance and compliance workflows

Delivered scope:

• organization admins can list delegated package, repository, and namespace access-history events from the immutable audit log
• the access-history API supports scope, team, target, date-range, and pagination filters plus CSV export
• organization workspaces render recent delegated access history and expose a CSV export affordance

Explicitly out of scope for 1.1.0

The following areas remain intentionally outside the 1.1.0 target:

• proxy, mirror, and virtual repositories
• Maven snapshot repositories and generic promotion pipelines
• SSO, SAML, and SCIM
• billing and commercial tiering
• federation, regional replication, and air-gapped synchronization
• deep attestation policy, signature UX, and broad Sigstore productization

Implemented execution order

1. risk posture on package and release detail surfaces
2. search and discovery depth
3. operator queue detail and recovery ergonomics
4. ecosystem metadata and dependency views
5. compliance and delegated-access history

Definition of done for 1.1.0

Publaryn 1.1.0 is considered implementation-complete when:

• every accepted slice lands with focused backend and/or frontend regression coverage
• changed UI or API behavior is documented in release-facing notes or product docs
• no new drift is introduced against the 1.0 contract and ADR guardrails
• the existing CI and smoke-build baselines still pass

At implementation completion, every accepted slice has targeted regression coverage and release-facing documentation. Full CI remains the release gate for tagging the version.