90-Day Roadmap
A staged, evidence-driven research and prototyping plan inside DreamGraph.
Three Questions, In Order
The roadmap is designed to answer these sequentially — each one gating the next.
Can DreamGraph represent reality?
Can the graph represent source/project reality well enough for NoFS to be credible?
Can it project usable artifacts?
Can DreamGraph project graph truth into usable artifacts deterministically and fast enough?
Can developers actually work this way?
Can developers work against projections without losing safety, compatibility, or trust?
Strategy
Phase the work from proof of representation → proof of projection → proof of safe interaction → proof of compatibility.
First validate the model, then validate materialization, then validate edit/reconcile loops, then validate developer usability.
Milestones
| Milestone | Timeline | Objective | Primary Output |
|---|---|---|---|
| M1 | Days 1–21 | Validate primitive mapping and define canonical model | Schema + validation report |
| M2 | Days 22–45 | Build deterministic projection prototype | Projector + determinism report |
| M3 | Days 46–68 | Prove constrained reconciliation | Reconciliation spec + report |
| M4 | Days 69–84 | Make NoFS tangible in VS Code and test compatibility | VS Code prototype + compatibility memo |
| M5 | Days 85–90 | Decide what NoFS becomes next | Assessment + Phase 2 proposal |
Milestone 1 — Canonical Model & Primitive Validation
Days 1–21 · If the primitive mapping fails, all later work is built on sand.
Goal
Validate that the NoFS primitive mapping — file→projection, folder→context, path→URI, save→mutation — is credible enough to invest in.
TDD Alignment
T-0.1, T-0.2, T-0.3, T-0.4 · partial T-2.1
Key Deliverables
Canonical source-of-truth model, projection/reconciliation lifecycle, identity rules, graph schema boundaries, explicit out-of-scope list.
Minimal graph schema for: module, function, class, interface, type, import/export/call/containment edges, annotation model.
Experiments against DreamGraph's own codebase: representability, query stability, context-based grouping, diff-to-mutation feasibility.
Exit Criteria
- A written schema exists
- At least 6 pilot artifacts were evaluated
- Primitive mapping has evidence
- One artifact family is chosen for Milestone 2
- A "do not attempt yet" list is documented
Milestone 2 — Projection Engine Prototype
Days 22–45 · Build the first deterministic graph→projection engine.
Two-Track Strategy
Use graph state to materialize implementation stories, roadmaps, ADR summaries, feature/workflow summaries, remediation reports.
Narrow TypeScript subset: config modules, registry files, type-only modules, simple utilities. Explicitly avoid large orchestrators.
TDD Alignment
T-1.1 · T-4.1 · T-5.1, T-5.2, partial T-6.1
Key Deliverables
Resolve artifact requests, gather graph entities, assemble output in stable order, emit projections with provenance metadata.
Run same projection repeatedly, compare output identity, record causes of variance.
Evaluate file/module, function-level, and concept-level projection quality.
Exit Criteria
- Projector generates repeatable outputs for the chosen artifact family
- Determinism is measured
- At least one constrained code projection exists
- Missing graph information is documented
Milestone 3 — Reconciliation & Controlled Editing
Days 46–68 · The first real confrontation with the hardest part of NoFS.
Goal
Prove that edits to materialized artifacts can be mapped back into graph mutations safely. Start with narrow, safe reconciliation classes only.
In Scope
✓ Start With
- Add entity
- Rename entity field/parameter
- Update description/metadata
- Delete import/edge in constrained modules
- Structured markdown section → graph updates
✗ Avoid Initially
- File splits/merges
- Deep refactors
- Arbitrary freeform source changes
- Ambiguous multi-entity edits
TDD Alignment
T-1.2 · T-3.1, T-3.2 · partial T-1.3, T-0.4
Key Deliverables
Diff classes, graph mutation mapping, ambiguity detection, conflict detection, rejection cases.
Simple/moderate/hard edit patterns with expected outcomes.
Real examples: success cases, ambiguous cases, rejected cases, graph consistency after application.
Exit Criteria
- At least 5 simple reconciliation cases work
- Ambiguous edits are detected, not silently misapplied
- Graph remains consistent after write-back
- One rejection policy exists for "unsafe to reconcile" edits
Milestone 4 — VS Code Experience & Compatibility
Days 69–84 · Where NoFS stops being a whitepaper and becomes a product experiment.
Goal
Make NoFS tangible in the developer experience. The existing DreamGraph VS Code extension makes VS Code the natural first NoFS shell.
TDD Alignment
T-7.2 · partial T-7.1 · T-8.1, partial T-8.2 · partial T-6.x
Key Deliverables
Virtual documents (nofs://), projection pane, graph-backed artifact browser, or projection diff/reconcile UI.
FileSystemProvider viability, projected artifact save hooks, git strategy evaluation, virtual FS vs extension-managed projections.
2–3 internal usability sessions to validate: Where does this come from? What happens when I save? How do I get back to normal files?
Exit Criteria
- At least one VS Code prototype exists
- At least one compatibility strategy looks viable
- Users can explain the model at a basic level
- At least one escape hatch is specified clearly
Days 85–90 — Assessment & Decision
Turn 90 days of evidence into a decision.
What passed, what failed, what remains unknown, what is worth scaling, what should be abandoned.
Proceed to production docs/plans NoFS · proceed to constrained code NoFS · continue research only · pause/invalidate major thesis components.
Decision Checkpoints
Each checkpoint is a go/no-go gate. Proceed only when evidence supports it.
End of Day 21
Should NoFS continue beyond conceptual validation? Proceed only if primitives are credible, schema is manageable, and first artifact family is clear.
End of Day 45
Is deterministic projection real enough? Proceed only if outputs are stable, graph coverage is sufficient, and at least one family feels natural.
End of Day 68
Is write-back viable? Proceed only if simple reconcile cases work, ambiguity is detectable, and corruption risk is controlled.
End of Day 84
Does NoFS feel better, not just look better? Proceed only if users understand it, the VS Code prototype shows value, and compatibility seems practical.
Cross-Cutting Workstreams
These run across all 90 days.
Graph Schema Evolution
Code entity schema, stable IDs, provenance model, projection recipe metadata. Required because the current graph is strongest at features and workflows — NoFS needs source-code-level entities.
Determinism Discipline
Canonical ordering, projection recipes, non-LLM default paths, deterministic serialization. NoFS will fail socially if outputs feel random.
Safety & Escape Hatches
Eject/export to regular files, reject unsafe reconciliation, build verification after projection cycles, explicit fallback modes. NoFS must never trap users.
Instance/Federation Design
Instance-as-drive semantics, namespaced IDs, cross-instance projection boundaries, pinned vs live reference design.
Artifact Family Sequencing
If NoFS begins with the hardest handwritten code, it will create premature negative evidence.
| Tier | Artifacts | Guidance |
|---|---|---|
| Tier 1 — Do first | Plans, living docs, ADR summaries, remediation artifacts, registry/config-like structured artifacts | Lowest risk, highest learning |
| Tier 2 — Do next | Type-only TS modules, simple utility modules, generated registration modules | Constrained code, manageable complexity |
| Tier 3 — Delay | Large orchestrators, UI-heavy files, mutable multi-responsibility modules, cross-cutting entrypoints | Highest risk, defer until proven |
Explicit Non-Goals
To protect the research program, these are explicitly out of scope for the 90-day window.
These may become later goals, but making them 90-day requirements would distort the program.
Weekly Cadence
| Weeks | Focus |
|---|---|
| 1–3 | Pilot corpus, core schema, primitive validation, first architecture note |
| 4–6 | Projection recipes, deterministic projection prototype, first reports, first constrained TS experiment |
| 7–9 | Reconciliation classes, write-back rules, ambiguity detection, discipline-backed mutation loop |
| 10–12 | VS Code prototype, compatibility memo, usability sessions, git/escape-hatch findings |
| Final | Assessment + Phase 2 proposal |
Success Criteria
Documented architecture spec exists. First-class code-entity graph for constrained TypeScript. Deterministic projector prototype. Constrained reconciliation loop. VS Code prototype. Evidence-based go/no-go decision.
Projection/reconciliation works for plans+docs plus one code domain. nofs:// virtual artifact access in VS Code. Git strategy validated. Federation implications designed and partially tested.
Built on DreamGraph
This roadmap builds on existing DreamGraph capabilities — graph storage, semantic extraction, query-driven retrieval, instance isolation, graph-to-document projection, VS Code surfaces, and controlled mutation workflows.