The Ithura Blog
Product5 min read

The specs that stop lying

Ithura wiki pages can now embed a live filtered issue block that auto-refreshes every 30s. Drop it in a PRD, a sprint retro doc, an onboarding page: it never rots. Notion's synced blocks are one-way and dumb; this is the two-way binding only a tool with both wiki AND tracker under one binary can ship.

A product spec is only useful for as long as it's true. In every tool that separates docs from the tracker, that half-life is measured in days. You write "3 open tasks for auth"; two weeks later, the tracker says 11; the doc still says 3; the doc has lied to you.

Ithura now solves this natively with the Live Task List block: a filtered view of the tracker embedded in a wiki page that refreshes on its own. Drop one in a PRD, a sprint retro, or an onboarding page and it never rots. Everyone reading the page sees the CURRENT state of the work, without anyone editing the page.

A wiki page with a live-issues block embedded
Q4 auth rework · PRD
Passwordless everywhere

The remaining scope for shipping the Q4 rework, tracked live so this page never has to be edited to stay current:

Open auth workLive
  • PAR-482SAML JIT provisioning gate for verified domainsIn progress
  • PAR-491Rate-limit passwordless magic-link requestsTodo
  • PAR-503Passkey re-enrolment on device changeTodo
  • PAR-517Deprecate the legacy /api/v1/auth pathIn review
4 shownAuto-refreshes every 30s

When someone closes an issue in the tracker, this list drops the row on the next refresh. When someone opens a new issue that matches the filter, it appears. The doc keeps telling the truth without anyone editing it.

Why only Ithura

Notion's synced blocks are one-way and dumb (they mirror one doc into another, not into live data). Everyone else who tried docs-plus-tracker either shipped separate products (Confluence + Jira) or a shallow integration where "linking to an issue" is the strongest tie. That's a copy-paste with a URL, not a binding.

Reactive documents work here because Ithura ships wiki and tracker in one binary. There is no integration boundary to cross, no OAuth to renew, no rate limit to negotiate. The wiki block just queries its neighbour and renders.

How to read the block

  • Header shows a title (you set it) and the "Live" indicator. A subtle spin means a refresh is in flight; click to force one.
  • Each row is one issue that matches the filter: state icon, project + sequence chip, title, priority chip (when non-none), first assignee.
  • Footer shows the shown-count and "auto-refreshes every 30s". Click any issue to jump to it.

The filter

The block's filter is a small JSON object with these keys: state_group, assignee_id (use "me" for the current viewer), project_id, priority, label_id, limit. Multi-valued keys accept a comma-string (state_group=unstarted,started).

API

Dashboards, reports, or your own automation can hit the same endpoint:

GET /workspaces/{slug}/reactive/issues/
  ?state_group=unstarted,started
  &assignee_id=me
  &priority=urgent,high
  &limit=20

Where reactive docs go next

  • Field-mirror block. Bind a heading or paragraph to an issue's title or status. Rename the heading, the issue updates. The "docs that don't rot" story becomes bidirectional.
  • Formula block. sum(sprint.42.issues.estimate), count(project.X.goals.open). Observable-style reactive expressions in prose.
  • WebSocket subscription. 30s polling is the "feels live" sweet spot for v1. v2 swaps to the workspace event bus for near-zero latency.

Related