Roadmap¶

This roadmap describes Vanguard's intended direction after 0.1.15. It exists to make priorities, dependencies, and completion criteria visible without turning exploratory work into a release-date promise.

Release line

Current: Vanguard 0.1.15, network protocol 2
Next: Toolbox distribution, additional utilities, Studio tooling, and expanded examples

Status Legend¶

Status	Meaning
Current	Available in the latest Vanguard package
Next	Planned for the next package release
Planned	Accepted direction, sequenced after the next release
Exploring	Requirements and design are still being evaluated
Ongoing	Work continues across multiple releases

Roadmap status is not a publication date. Security fixes, Roblox platform changes, and compatibility work may change sequencing.

Release Overview¶

Milestone	Status	Primary outcome
`0.1.14`	Previous	Linked errors, Math, Switch, access-controlled classes, and protocol 1 documentation
`0.1.15`	Current	Plugin Developer API, replicators, protocol 2, and release model output
Toolbox distribution	Next	Verified non-Wally installation path
Additional utilities	Exploring	More production-focused, dependency-free helpers
Studio tooling	Exploring	Generation, validation, inspection, and diagnostics
Documentation expansion	Ongoing	Recipes, examples, architecture, and versioned guidance
Community contributions	Ongoing	Clear contribution, review, and RFC process

0.1.15: Plugin Developer API¶

Status: Current.

The Plugin Developer API lets extensions integrate with Vanguard through public contracts instead of requiring internal registries, private tables, or bootstrap implementation details.

Goals¶

Register named, versioned extensions with explicit runtime scope.
Give plugins deterministic initialization and startup hooks.
Resolve declared plugin dependencies before lifecycle execution.
Expose narrow capabilities for framework integration.
Keep service, controller, component, class, and network ownership explicit.
Produce linked errors and diagnostics for plugin failures.
Preserve Vanguard startup guarantees when one optional plugin fails.
Make plugin state inspectable by future Studio tooling.

Manifest Shape¶

Vanguard.CreatePlugin({
    Name = "ExamplePlugin",
    Version = "1.0.0",
    Runtime = "Shared",
    DependsOn = { "MetricsPlugin" },

    VanguardInit = function(self, context)
        -- Required setup before services/controllers initialize.
    end,

    VanguardStart = function(self, context)
        -- Runtime work after services/controllers initialize.
    end,
})

The released context includes the current runtime, plugin definition, Vanguard module reference, hook name, and logger.

Lifecycle Direction¶

discover plugin definitions
  -> validate names, versions, runtime, and dependencies
  -> build dependency order
  -> initialize plugins
  -> initialize Vanguard services/controllers
  -> run plugin start hooks
  -> schedule framework start hooks
  -> expose readiness and diagnostics

Circular dependencies and missing plugins fail with VG-PLUGIN-003.

Extension Boundaries¶

The API is intended to support:

reusable framework integrations;
custom diagnostics and metrics;
domain-specific registries and factories;
opt-in service, controller, component, or class discovery helpers;
future Studio tools that inspect public plugin metadata;
protocol-aware network extensions that declare compatibility explicitly.

The API is not intended to expose every internal Vanguard table. Plugins should receive capabilities they need rather than mutable access to framework state.

Non-Goals¶

A hosted plugin marketplace.
Downloading or executing remote code at runtime.
Automatic trust of third-party plugins.
Automatic trust of client-provided network data.
A complete visual Studio tool suite in the same release.

See Plugin Developer API and the 0.1.15 changelog.

Replicator Follow-Up¶

Status: Current foundation; future improvements exploring.

0.1.15 ships the first replicator system for server-owned structured state. Future releases may explore:

more granular path subscriptions;
optional client-side selectors or computed views;
stricter schema helpers for replicated state;
batching policies for high-frequency server updates;
diagnostics for large payloads and over-broad patches.

Any change that alters the replicated wire shape will require a protocol review.

Roblox Toolbox Release¶

Status: Next.

The Toolbox release will provide a supported installation route for projects that do not use Wally and Rojo.

Planned Work¶

Publish a clearly owned Vanguard model under the correct creator identity.
Keep Toolbox and Wally package versions visibly aligned.
Document manual installation and update procedures.
Preserve the same package-root require API where Roblox permits it.
Include a version and protocol diagnostic users can verify in Studio.
Document how to avoid duplicate Wally and Toolbox copies in one game.
Add release verification steps for model contents and unexpected scripts.

Acceptance Criteria¶

The model is reproducibly built from tagged source.
A clean baseplate can install and bootstrap without Wally.
Server and client use the same package copy.
Update and removal instructions are tested.
Toolbox-specific troubleshooting is published before announcement.

Additional Utility Modules¶

Status: Exploring.

New utilities must solve recurring production problems, remain dependency-free, have deterministic tests, and avoid duplicating simple Roblox APIs without a clear ergonomic or correctness gain.

Candidate areas include:

Candidate	Problem it may solve
`StateMachine`	Explicit states, guarded transitions, transition events, and history
`Queue` / `PriorityQueue`	Ordered jobs, matchmaking, task scheduling, and bounded work
`Observable` / `Computed`	Derived local state with deterministic subscriptions and cleanup
`Retry`	Backoff, attempt limits, jitter, and Promise integration
`Serializer`	Versioned application data transforms, not a replacement for Roblox transport
`Pool`	Reuse of expensive local objects with explicit reset and capacity behavior

Candidate names and APIs are not final. Each accepted utility needs:

a focused use case and non-goals;
typed public API;
cleanup and error behavior;
custom clock or scheduler injection when timing is involved;
unit tests for edge cases;
a complete guide and API table.

Expanded Documentation¶

Status: Ongoing.

Documentation work continues alongside every release rather than waiting for a single documentation milestone.

Planned improvements include:

task-oriented recipes for profiles, inventory, matchmaking, UI, and security;
complete sample server and client projects;
extension-author guidance for the 0.1.15 Plugin Developer API;
architecture diagrams for startup, registries, networking, and cleanup;
versioned migration notes and compatibility tables;
more copy-paste examples with expected output and failure cases;
release checklists that keep source, Wally, Toolbox, and docs aligned;
searchable error entries for every new public failure code.

Documentation is considered part of feature completion, not follow-up work.

Studio Tooling¶

Status: Exploring; expected to build on public plugin metadata.

Potential tools include:

service, controller, component, and class generators;
bootstrap and folder-layout validation;
duplicate-name and missing-module diagnostics;
service-priority and plugin-dependency visualization;
network rule and remote hierarchy inspection;
protocol and package-version mismatch diagnostics;
error-code lookup inside Studio;
safe project health checks that do not mutate game code automatically.

Studio tooling should consume public Vanguard and Plugin Developer APIs. It should not depend on unstable internals that force lockstep releases.

Before a tool changes project files, it should preview the affected paths and make ownership clear. Read-only inspection is the preferred first milestone.

Community Contributions¶

Status: Ongoing.

Vanguard will make contribution boundaries easier to understand so outside work can be reviewed consistently.

Planned repository support includes:

a contribution guide with local test and build commands;
issue templates for bugs, features, documentation, and security reports;
a lightweight RFC process for public API and protocol changes;
labeled starter issues with narrow ownership;
pull-request checklists for tests, types, docs, and changelog updates;
a code of conduct and maintainer response expectations;
explicit security-reporting instructions outside public issue threads.

Protocol, authentication, and serialization changes require deeper review than isolated utilities or documentation fixes.

Prioritization Rules¶

Roadmap items are ordered using these principles:

protect compatibility and server authority;
fix correctness and diagnostics before adding surface area;
stabilize public extension contracts before building tools on them;
require tests and documentation for every public API;
prefer narrow utilities over overlapping mini-frameworks;
keep Wally and future Toolbox distributions behaviorally aligned.

Suggesting Roadmap Work¶

Feature proposals should identify:

the production problem and affected users;
why existing Roblox or Vanguard APIs are insufficient;
the smallest useful public contract;
server/client and protocol implications;
cleanup, failure, and security behavior;
expected tests and documentation.

Community interest informs priority, but it does not override compatibility, security, or maintenance cost.

See the Changelog for shipped behavior and the API Reference for APIs available today.