Implementation Roadmap

This roadmap keeps the first version focused on the product’s core value:

A living lore graph with branchable continuities.

The codebase now uses Project for the root lore object and Continuity for a mutable continuity or branch.

Phase 1: Service Skeleton

• add domain crate
• add application crate
• add HTTP API crate
• add storage crate
• add Postgres storage crate
• add migrations
• add basic tracing
• add xtask check baseline

Phase 2: Accounts, Workspaces, and Projects

• account model
• workspace membership
• project model
• ownership
• project list for current user
• create and edit projects

Phase 3: Lore Graph

• entity model
• relationship model
• basic graph queries
• entity search
• relationship search
• tags and flexible properties
• route-scoped API

Start concrete with entity-to-entity relationships, but keep the long-term model open to resource-to-resource relationships. Events, facts, scenes, publications, and other future resources may need to participate in the graph.

Phase 4: Continuities and Mutable Continuity

• continuity model
• branch from an existing continuity
• events scoped to continuity
• chronology entries scoped to continuity
• mutation log scoped to continuity
• current continuity state views

Campaign can either become a kind of continuity or become a play workflow attached to a continuity. The important design move is that divergent state belongs to a continuity boundary, not directly to the base project.

Phase 5: Facts, Knowledge, and Disclosure

• fact model
• belief and knowledge model
• visibility and disclosure model
• reveal secret workflow
• player, reader, and point-of-view filtering
• false belief support

The current Secret and Knowledge types are a useful prototype. Long term, a secret should usually be a fact or disclosure state with restricted visibility, while knowledge should describe who believes or knows a fact and with what certainty.

Phase 6: Collaboration

• collaborator roles
• permissions
• audit trail
• comments or review notes

Phase 7: Rules Adapters

• rules adapter traits
• generic stat attachment
• D&D 5e proof of concept
• Pathfinder proof of concept

Phase 8: Publication and Export

• public project and story pages
• player handouts
• markdown export
• JSON archive export

Suggested MVP

The smallest useful MVP is:

login
create workspace
create project
create entities
link entities
search entities
create continuity
record continuity event
record mutation
filter by visibility

A slightly stronger MVP is:

login
create workspace
create project
create entities
link entities
search entities
create continuity
record event
attach event to chronology
record mutation
create hidden fact or secret
reveal fact or secret to an entity or audience
filter by visibility

Do not start with a full rules engine. The unique value is the living lore graph with branchable continuities.

Immediate Refactor Direction

Before adding every missing roadmap feature, keep the root concepts aligned:

1. Keep Project as the root lore container.
2. Keep Continuity as the continuity boundary.
3. Route-scope the API around the new root.
4. Move events, chronology entries, and mutations under continuities.
5. Keep entities and relationships project-scoped until divergent state is needed.

Frontend Direction

The first frontend should validate whether users can answer project and continuity questions quickly. Start with project list, project detail, and entity detail screens, then make search a primary workflow before investing in graph visualization.

See Frontend UX Roadmap for the user experience principles and initial screen scope.