A project harness for software teams

Your stack. One living project.

Drift is being built to connect specs, tickets, diagrams, and code into one live project model. Project integrations are still in development.

Join the pilot Explore example

Useful outputs

Product preview · Sample data

Live project model

Payment Platform

Ledger updates follow confirmed refund completion.

One project model above your existing tools

Requirement establishes completion order

Coordination

Your existing tools

Select an item to inspect its evidence.

Your workflow stays where it is.

Each connection contributes a different part of the project. Drift is the overlay; your tools keep their jobs.

Planned integrationsProvider names are illustrative

Linear / Jira

Tasks, ownership, scope, dependencies and dates.

Google Docs

Requirements, acceptance criteria and decisions recorded in specifications.

Miro

Journey steps, alternative paths and system relationships.

GitHub

Pull requests, diffs, reviews, merges and implementation evidence.

Slack

Relevant decisions, clarification and approved update destinations.

AI usage

Authorized usage records, allocation data and attributable sessions.

Production

Deployments, rollout evidence and approved runtime measurements.

Project integrations are in development. This website activates no connectors. Pilot access and scopes must be agreed before connecting a real project.

Why this change reaches Ben.

Ava’s proposed change separates the initial refund response from confirmed completion. The handoff needs to explain that timing, not just report a changed file.

Ava / PR #14 / Proposed

Two stages, one completion signal.

Stage 1 · Respond to the refund request

- return completedRefund;
+ return pendingRefund;

Stage 2 · Later, after provider confirmation

provider.on("confirmed", () => {
  emit("refund.completed");
});

Related workBen / PAY-23

The ledger consumer assumes immediate completion. Its owner needs to review the proposed event-based flow.

Ben · PAY-23Review context

Ownership identifies the recipient.

PAY-23 assigns the ledger consumer to Ben. Refund Spec v4 and Refund Flow v3 connect that consumer to the completion signal Ava proposes changing.

That link suggests an impact worth reviewing. It does not prove a runtime failure or notify Ben.

Follow-up, sources and uncertainty

PR #14 proposes asynchronous refund completion. PAY-23 still assumes immediate completion. Review the consumer before merge. Sources: PR #14, PAY-23, Refund Flow v3, Refund Spec v4.

Fictional excerpts from the local Payment Platform fixture. No tool is queried.

PAY-23 · Ben

Ledger consumer expects completed settlement in the refund response.

Refund Spec v4

Update the ledger only after the provider confirms refund completion.

Refund Flow v3

Refund requested → provider confirmation → ledger update.

PR #14 · Ava

Return pending; emit refund.completed after provider confirmation.

Confirmed in the fixture: spec and flow establish completion order; PAY-23 records Ben’s ownership and the consumer assumption.

Suggested: PR #14 may affect that consumer. Review is required; a diff alone does not prove a runtime failure.

Selected access.
Clear boundaries.

Demo access.

The preview runs on fixed sample data in your browser. It requests no repository, workspace, or messaging permissions.

Pilot permissions.

Access and action permissions must be agreed before connecting a real project. This website sends no messages and changes no project records.

Request data.

Pilot details stay in this site’s private database. Use your private receipt to delete your request.

Data access for this website

Demo: fixed sample data runs in your browser; no AI model is called.

The pilot form stores your email and optional company/project and team size in this site’s database. No CRM, model provider, or project connector receives those fields from this implementation.

Live-product scopes, processing, retention, and model-provider handling must be agreed before any real project is connected.

Pilot request privacy

Free pilot / one active project

Bring one real project.

Request pilot access for one active software project.

A request does not activate integrations or automated actions.