Roadmap

This roadmap uses horizons instead of fake dates. The guiding product bet is:

Creators need a living lore graph with branchable continuities and audience-specific knowledge.

Status Legend

Horizon 0: Foundation

Status: Current

This horizon proves that the codebase, docs, and local workflow can support contributors.

Current repository behavior includes:

• separated domain, application, storage, HTTP, frontend, and xtask crates
• Axum REST API under /api/v1
• Leptos frontend served by Trunk
• in-memory development storage when Postgres is not configured
• optional Postgres storage with migrations and development seed data
• mdBook documentation under doc/src
• shared xtask commands for formatting, checking, testing, building, docs, and local dev

Meaningful completion looks like:

• README answers the project identity and contributor runway questions
• contribution and governance docs are short and accurate
• docs distinguish current behavior from planned behavior
• project-scoped routes and development data remain easy to run locally

Horizon 1: Lore Graph Local Preview

Status: Current

This horizon proves that TTRPG Forge is more than a note collection.

Current or near-current behavior includes:

• create, list, view, and update projects
• create, list, view, and update entities
• create, list, and view relationships
• search project content
• show project and entity detail pages in the frontend

Meaningful completion looks like:

• entity and relationship workflows are consistent across API, storage, and UI
• search is useful enough to be a primary retrieval path
• project and entity pages answer common creator questions quickly
• tests cover important domain, storage, query, and HTTP behavior

Horizon 2: Continuity and Change Tracking

Status: Next

This horizon proves that one project can support divergent campaign, story, or publication state.

Current or near-current behavior includes continuity resources, continuity-scoped events, chronology entries, and mutations. The work is not finished until the workflows are coherent in the UI and well covered by tests.

Meaningful completion looks like:

• create, list, view, and update continuities
• branch or derive a continuity from an existing continuity
• record continuity-scoped events
• attach events to chronology
• record mutations
• view current continuity state
• explain the continuity model clearly in user and contributor docs

Horizon 3: Secrets, Knowledge, and Visibility

Status: Next

This horizon proves that the project can track information boundaries.

Current behavior includes secret resources. Audience-specific visibility and knowledge workflows are still planned.

Planned: The items below describe intended behavior. They are not complete user-facing workflows yet.

Meaningful completion looks like:

• create hidden facts or secrets
• associate knowledge with players, characters, factions, readers, or audiences
• reveal information intentionally
• filter views by audience
• represent false or uncertain beliefs
• make visibility and permissions difficult to bypass accidentally

Horizon 4: Collaboration

Status: Later

This horizon makes the project useful for groups without losing control over sensitive information.

Planned: Collaboration design should follow the visibility model instead of preceding it.

Meaningful completion looks like:

• collaborator roles
• project permissions
• audit trail
• comments or review notes
• clear separation between owner, editor, viewer, and player-facing access

Horizon 5: Publication, Export, and Integrations

Status: Later

This horizon turns private project data into useful external outputs.

Planned: These features should not shape the core model until the lore graph, continuity, and visibility workflows are proven.

Meaningful completion looks like:

• player handouts
• public project or story pages
• markdown export
• JSON archive export
• optional rules adapters
• optional integrations with VTTs or campaign tools

Reserved Public-Facing Areas

Keep these reserved until there is real material:

• screenshots once the first workflows are visually coherent
• social links once public project channels exist
• email signup or waitlist once there is a specific preview, release, or hosted option to announce
• user-facing release notes once builds are useful outside development

Non-Goals For The First Preview

The first preview does not need:

• a rules engine
• graph visualization
• map tools
• dice rolling
• character sheet replacement
• hosted multi-tenant production deployment

Engineering Roadmap

The detailed engineering sequence remains in Implementation Roadmap. That page keeps the phase-by-phase technical checklist, while this page tracks what each horizon should make possible for users and collaborators.