Roadmap

What we’re building next, in order. This page is direction, not dates.

What we’re building next

1. Audit — impact analysis

The flagship feature of v0.6. Given an item, traverse typed edges (depends / blocks / supersedes / conflicts) and report the blast radius: every item reachable from the root within the five-hop ceiling, each annotated with the edge type that first reached it.

Surfaces on all three interfaces: lp impact <id>, the luplo_impact MCP tool, and GET /items/{id}/impact. Same structured answer in every case, so an LLM can cite a decision graph the same way a human reads the tree.

This is the feature that makes “what breaks if I change this?” a queryable question. Without it, luplo is an aliasing search over a decision log. With it, luplo is the only tool that answers the question by construction rather than by vibe.

2. Slack /archive

Ingestion vertical one. A Slack slash command that pulls a thread into a sync_job, which the worker structures into an item and hands back to the user as a draft — never a silent write. This preserves the augment-not-replace commitment while making decisions that happened in Slack actually findable later.

/archive ships after Audit, not before. A decision archiver without impact analysis is a crowded category. The loop that creates lock-in is archive-a-decision → six-months-later Audit shows you what depends on it. Ship the loop, not half of it.

3. Notion webhook

Ingestion vertical two. A Notion Public Integration plus a webhook receiver: page-updated events enqueue sync_jobs, the worker fetches current content, diffs against the previous version in items_history, and proposes an update — same draft-then-confirm pattern as /archive.

Shared infrastructure with /archive through a small ExternalSource protocol, so adding Confluence, Linear, and similar ingestion sources later is mechanical.

4. Rule pack

Declarative checks that run over the item graph. A rule is a function that returns findings; luplo ships five starter rules with v0.6 (missing rationale, undated retention, dangling edge, unresolved conflict, unlinked policy). Surfaces as lp check, luplo_check, and GET /checks — structured findings an LLM or a CI job can act on.

Rules are deterministic (SQL plus Python). There is no “LLM-powered compliance checker” on this roadmap. Hallucination plus regulatory context is not a product, it is a liability.

What we’re explicitly not building

See Philosophy for the five refusals in full. The short list of proposals that will be declined regardless of how they are framed:

  • A plugin runtime that loads third-party Python into luplo.

  • A vector-first search mode.

  • A traversal depth knob that exceeds five hops.

  • A PATCH /items that edits an existing row in place.

  • A “general memory” surface for non-engineering state.

None of these are rejected because they are hard to build. They are rejected because building them changes what luplo is.

How to influence the roadmap

  • Open an issue for a feature request or a bug report. Link to an existing decision in the repo if one already covers the ground.

  • Open a PR for bug fixes and small, well-scoped improvements (typos, doc fixes, test coverage).

  • Open an issue first for architectural PRs (new subsystems, new storage shapes, new surfaces). Large PRs without a prior discussion tend to be declined even when the code is good — the shape of luplo is a curated decision.

Version policy

luplo follows Semantic Versioning. While the version is 0.x, minor-version bumps (0.x → 0.(x+1)) may contain breaking changes; patch bumps are bug fixes only. Once 1.0.0 is tagged, the public CLI, MCP tool, and HTTP surface become a stability commitment.

Until 1.0, the roadmap above is the main source of intent. Changes to that intent happen on this page, in git history, and nowhere else.