Skip to content
Rymflux Documentation
Esc
↑↓navigate↵open⌘Jpreview
On this page

Roadmap & backlog tracking

Roadmap & backlog tracking

How the v1 roadmap and backlog are tracked, and how git and the Fibery planning layer stay in sync.
Purpose Define where the roadmap/backlog live, what each system is authoritative for, and how status is reconciled.
Audience All developers, Tech Lead, Product Owner
Typical owner Tech Lead
Phase 4
Stream Internal

Two systems, one source of truth

System Authoritative for Not authoritative for
Git (this repo) The plan itself: items, IDs, MoSCoW buckets, phases, FR/NFR refs, acceptance criteria Live operational status
Fibery (Rymflux space) Live operational state: status, owner, sprint/phase assignment The plan’s content
  • Git is the source of truth. If a backlog item is added, renamed, split, or re-bucketed, the change lands in backlog.md (and roadmap.md when the phases shift) via a PR. Fibery follows.
  • Fibery is the day-to-day working view. Team members move status and set owners there between gates. Fibery never drives changes back into the plan — its only write-back is operational status at phase gates.

The files

Item identity

  • Every backlog item has a stable ID: M1–M17, S1–S8, C1–C7, W1–W12. (S3 was skipped historically; do not renumber.)
  • The same ID exists in Fibery as the Rymflux/ID field. Match on ID, never on name.
  • Every item also carries a Rymflux/Docs link to its rendered page on https://rymflux-docs.pages.dev/... so Fibery rows deep-link to the spec.

Fibery planning layer

The Fibery Rymflux space mirrors the backlog:

  • Rymflux/Backlog Items — one row per item, keyed by Rymflux/ID.
    • Rymflux/Status (single-select): Not started / In progress / Done / Blocked / Deferred.
    • Rymflux/Owner (relation to user), Rymflux/Phase (relation to Roadmap Phases), Rymflux/FR-NFR (multi-select), Rymflux/Docs link (text).
  • Rymflux/Roadmap Phases — the five v1 phases (0 · Foundation … 4 · Hardening & release) with start/end dates.

Status vocabulary

Value Meaning
Not started Backlog item is not being worked
In progress Actively being worked; owner set in the planning layer
Done Acceptance criteria met and verified
Blocked Work stopped pending an external dependency or decision
Deferred Excluded from the current v1 phase path (default for Won’t)

Sync policy

  1. Plan changes → git first. New/renamed/split/re-bucketed items are edited in backlog.md / roadmap.md and merged before Fibery is touched.
  2. Fibery reflects plan changes. When a merged change alters an existing item (or adds one), update the matching Rymflux/ID row’s name, MoSCoW bucket, phase, FR/NFR refs, and docs link. Do not create a row without an ID that already exists in the repo (and vice versa).
  3. Operational status → Fibery, continuously. Owners and status changes are made in Fibery as work happens. No need to touch backlog.md mid-phase.
  4. Reconcile at phase gates. At each phase gate (and before a release), copy the Fibery status/owner snapshot into the Status column of backlog.md and review Must/Won’t (see Revisit cadence). This is the canonical snapshot.
  5. Inconsistencies are bugs. If Fibery and the repo disagree (a name, a bucket, a status after a gate), fix the repo first when it is a plan difference and reconcile Fibery; when it is purely operational, reconcile the repo at the next gate.

Working with Fibery (via the MCP tools)

The Fibery MCP server is configured in the user-level opencode config (no repo-scoped config); the workspace domain is rymflux-player.fibery.io. Common operations:

  • List spaces/types: schema, schema_detailed.
  • Find an item: query filtering on Rymflux/ID.
  • Change status: update_entities on Rymflux/Status (or the enum option ID).
  • Set owner: update_entities on Rymflux/Owner (relation to fibery/user).
  • Reconcile a gate: read all rows with query, then update the Status column in backlog.md and open a PR.

Was this page helpful?