Roadmap

StateBoard is evolving from visual status reporting into a shared assessment of what works, what it depends on, and why a team believes it is ready to release. Screenshots remain the visual view; reusable capabilities connect that view to backend dependencies, acceptance criteria, and verification evidence.

This page records the adopted product direction. 2026.10.0 ships the release-readiness MVP, including ordinary agent maintenance through REST and MCP. The usage guide explains the workflow; the MVP implementation plan records its contract and acceptance criteria.

GitHub milestones and the project board still contain the previous roadmap scope. Reconciliation of their stages and issues is pending; they have not been synchronized with this direction.

v0: the wedge · shipped

The smallest thing that proves the primitive works.

• Manual screenshot upload
• Region tagging on the image (click-and-drag)
• Three states: shipped / mock / missing
• Read-only public share link
• Single user, no auth

v1: team-ready · shipped (2026.5.0)

The cut you can deploy in a company.

• Multi-user via OIDC (Keycloak is documented; any IdP works)
• Workspace with owner / editor / viewer roles
• Revocable share-link tokens: multiple per board with audience labels; each currently shows the same board
• Append-only audit log (rows in Postgres; a read-only UI and per-board history arrived in 2026.7.0)
• Postgres-backed; multi-replica safe with a ReadWriteMany PVC
• One container + one Postgres. Zero outbound calls except to your IdP.

See the changelog for the full release notes.

v1.x: shipped additions

These additions are already available on top of the v1 foundation:

• Audit-log UI — shipped in 2026.7.0. /settings/audit for owners, with actor / action / resource / date filters and CSV export, plus per-board history at /boards/[id]/history visible to any board member.
• Agent access — shipped in 2026.8.0. Per-member API keys (hashed, role-capped, expiring) unlock the REST API and a built-in MCP server at /api/mcp. Agents can read and update boards and regions, with every edit audited and no outbound calls. See Agents & API.

The unshipped capture, custom-state, and integration work from the former v1.x scope remains in the reprioritized backlog.

v2: release-readiness MVP · shipped (2026.10.0)

The MVP is designed to let a product manager, backend developer, QA specialist, and release owner independently explain whether the same candidate is ready, what blocks it, who owns the resolution, and which evidence would unblock it.

• A defined release assessment. Keep a board as the product boundary. Assess an immutable candidate reference or artifact manifest against a validation environment, target deployment environment, audience, and configuration. A new candidate or assessment context requires its own assessment.
• Reusable capabilities. Describe outcomes such as "Export an invoice" or "Process a partner webhook," with owners and required acceptance checks. Link capabilities to screens and regions where useful; a capability can exist without a UI.
• Lightweight dependencies. Record components, owners, and meaningful relationships such as calls, consumes, or requires. Show the dependencies relevant to a capability and the capabilities affected by a component.
• Applicable evidence. Attach manual reviews and test results to versioned checks. Evidence is append-only and identifies its candidate, environment, audience/configuration, result, author/source, time, and freshness window. Agents and CI push observations through REST or MCP; human entry remains available.
• AI-maintained product context. Coding agents inspect the project, reconcile existing capabilities/components and declared dependencies, maintain scope/checks, and submit actual verification for the exact candidate. MCP and REST expose the same ordinary readiness operations; the packaged skill teaches this workflow. People review release intent, unresolved claims, and decisions rather than transcribing the repository.
• Explainable readiness. Calculate ready, blocked, or needs_evidence from required checks and applicable evidence. Show individual failures and unknowns; a percentage must never hide a critical blocker. Keep shipped / mock / missing as separate visual delivery states.
• Recorded human decisions. Preserve the assessed scope, applicable evidence, readiness result, actor, time, and rationale in a decision snapshot. Passing checks do not automatically approve a release. Exception waivers are outside the MVP.
• A direct human review path. Release reviews and Features provide the human-facing vocabulary. Overview, Checks, and Decision are the primary tasks; Screens and Architecture supply optional context. Feature rows hold their checks/results and contextual supporting links. Operational concerns filter the same checks. Known form context is reused, and manual observations receive a review reference automatically. No AI connection or architecture catalog is required; existing API names and role-view URLs remain compatible.
• A curated public projection. Explicitly select public-safe outcome summaries and visual media, retain the media needed by a published decision, and enforce an allowlist on the server. Raw internal dependencies, evidence references, and identities stay authenticated.

The release includes all seven implementation slices, from product context to retained decisions, private media, public reviews, and ordinary readiness maintenance through MCP. English and German interfaces share the same records. Product Screens has its own gallery, with feature links and a direct return to a release review. Explore the permanent example at /share/demo/releases.

Upgrade with migrations 0008–0010 and the OIDC callback change. The implementation plan covers the schema, API, readiness rules, and acceptance criteria. Pilot one real release with roughly 5–10 critical capabilities before broadening the model; team usability validation remains pending.

The current clarity refinement also applies published UX guidance on familiar terms, recognition, progressive disclosure, and reduced form effort. Simulated product, engineering, and QA reviews identified repeated target selection, machine-oriented observation fields, and role tabs that obscured the next action. Independent human validation remains pending.

The local persona iteration uses StateBoard's own Codex-assisted delivery as a real case. It added candidate readiness to the overview, actionable verification findings, scoped architecture/checks, QA attention filters, and explicit verification/availability context. Six simulated professions and actual UI retests informed these changes; external human usability and production restoration remain unverified.

Connected agents can already reconcile the affected records after an authorized code change, and CI can push completed verification runs. StateBoard does not host an LLM, execute tests, or install a background scheduler. Source-derived wiring is declared context, while readiness depends on actual evidence; human owner decisions and curated publication remain session-only.

v2.x: extend evidence sources · planned after the pilot

• Additional evidence integration recipes for the CI, test, and internal systems observed in the pilot, building on the existing REST/MCP push workflow. StateBoard makes no new runtime outbound calls.
• Catalog and architecture imports that reuse existing component identities and owners rather than require a second catalog to be maintained by hand.
• Freshness and context comparison that make stale evidence and differences between assessed candidates, environments, audiences, or configuration visible.
• Capability flow views that connect visual steps and non-visual work into a complete user or business outcome.

Integration scope will follow the evidence sources used in the pilot. A connector's results support the claims it actually verifies; importing a test result or a runtime connection must not imply that the whole capability has passed.

v3: broader impact and overview · planned later

• Richer impact navigation across components, capabilities, and release assessments, with focused architecture slices and domain-level overview.
• Portfolio rollup across product boards, preserving candidate context, blockers, and evidence gaps instead of adding incomparable status counts.
• Declared and observed architecture shown distinctly if runtime evidence is imported; observed traffic is not proof of complete dependency coverage.
• Reusable assessment templates after the pilot establishes stable patterns. Built-in examples remain in code rather than being seeded into the user's database.

Reprioritized backlog

These previously planned features are retained, but are not prerequisites for the release-readiness MVP. Their original milestone placement is historical; sequence them after the pilot according to demonstrated value.

What we won't build

The repository's operating manual records the implementation boundaries. This direction does not turn StateBoard into:

• A ticket, sprint, or roadmap management tool
• A full developer portal, service catalog, or observability platform
• A replacement test runner or release deployment system
• An automatic release approver
• Real-time collaboration (yjs, presence), because async review is the use case
• Comment threads on regions, because we are not Figma
• Email-based invites, because OIDC handles identity
• Per-provider OAuth helpers, because Better Auth's generic OIDC accepts any discovery URL

Self-hosted, airgap-ready, MIT remains the distribution model. Except for the configured internal OIDC provider, the server makes no external network calls.

Want to influence it?

• File an issue on the repo. Reference a stage if you have a strong opinion.
• The project board tracks implementation issues; roadmap reconciliation is pending.
• Releases use CalVer. Stage names describe product scope and do not promise dates.