Governance without coordination
A Pulse card can reach done with no proof the handoff ever happened.
No atomic claim/handoff primitive. A coordination problem, not a spec problem.
Okto Pulse + Okto Nexus, together
No shared code, config, or service between them
One feature. Two agents, one handoff.
Pulse decides what's built and what "done" means. Nexus decides who gets to touch it and when. Run together, on a real forked codebase.
Target: makeplane/plane fork
Feature: filter-aware CSV export
4 agent roles, 1 shared checkout
Two products, one delivery thread
Okto Pulse
Ideation → spec → validation gate
Okto Nexus
Claim → handoff → complete
Two tools. Two half-answers.
Governance tracks work but not coordination. Coordination moves work but proves no "done." This run tests both gaps directly, not just describes them.
Coordination without a gated "done"
The frontend card's first submission: completeness 78, board threshold 80.
"The agent said it's done" isn't evidence.
Ambiguity absorbed into code
The sync/async threshold, CSV columns, signed-URL expiry: each resolved by Q&A before a line of code existed.
A first reading becomes a baked-in assumption, with no record of the alternatives.
Context dies with the session
The Nexus handoff's opened → claimed → completed trail.
A chat transcript isn't durable storage. Kill the process, lose the state.
Open the actual boards.
The real Pulse app and the real Nexus workspace, live-look and interactive, not screenshots.
Loading board snapshot…
What to build. Who builds it.
Wire Plane's Issues List to its own unused async CSV export pipeline. Pulse owns what; Nexus owns who.
Owns what to build
Okto Pulse
Investigated and refined against real code before a line is written.
Every spec clears five quality gates. Every card's "done" is independently validated.
Ideation → Refinement → Spec → Sprint → Cards → Task validation
Owns who's allowed to act
Okto Nexus
API contract created under session fallback local-agent and claimed/completed by frontend-agent.
A real, replayable event log, not a chat transcript that dies with the session.
handoff_create → handoff_claim → handoff_complete
Nine stages, start to finish.
Every stage a real MCP tool call touched, from the first ambiguity-killing question to the last regression fix.
Ideate, ambiguity-killed
Sync/async threshold, CSV columns, signed-URL expiry, resolved via Q&A first.
Refine against real code
An unused async export pipeline already exists: three assumptions superseded.
Spec, validated
19 evaluated requirements (8 functional + 5 technical + 6 acceptance criteria), 6 business rules, 1 API contract — gate passed across all 5 dimensions (Completeness 85 ≥ 70, Granularity 86 ≥ 80, Coherence 84 ≥ 80, Test Quality 85 ≥ 80, Ambiguity 18 ≤ 30).
Sprint, 4 cards
Backend, Frontend, and their two dependent test cards, made active.
Backend implementation
Real code, real pytest run (7/7 in test_export_issues_rich_filters_app.py), card reaches done.
Nexus handoff
handoff_create → handoff_claim → handoff_complete, contract refined on completion.
Frontend implementation
Real code against the delivered contract, verified by a clean typecheck.
Task validation
Every completion claim is checked against the board's own completeness threshold before it counts as done.
Extending test coverage
Playwright added, verified end-to-end, a real regression caught and fixed.
Real board. Real handoff.
The actual state behind this run: see demo-state/ for what each file is and how to view it.
Pulse · Ideation
Scope evaluated, done
The ambiguity-killer Q&A: sync/async threshold, CSV columns, signed-URL expiry, resolved before a spec is written.
Pulse · Refinement
Real code, investigated
The real codebase investigation that superseded three of the ideation's assumptions before implementation began.
Pulse · Spec
Validated, gate passed
Requirement Lint at 0 defects, decomposed into the active sprint's 4 cards.
Nexus · Coordination graph
Real handoff activity
Contract created under session fallback local-agent (due to an MCP session reconnect quirk) and claimed/completed by frontend-agent.
Nexus · Handoff detail
COMPLETED
The real API contract payload, refined and reported back on completion.
Every claim, backed by evidence.
No step in this run is "the agent said so." Every number below is a real test run, a real gate score, or a real, replayable result.
7/7
Backend pytest suite, passed
0
Requirement Lint defects across 19 evaluated requirements
1
Real Nexus handoff, create → claim → complete
4
Sprint cards, each traced back to the spec
- Every requirement traces to a real card, not a paraphrase.
- The spec passed all five validation dimensions before decomposition.
- Backend implementation verified by a real test run, not a claim.
- The Nexus handoff produced a replayable claim → complete event log.
- Frontend implementation verified by a clean workspace typecheck.
- The validation gate applies the same completeness threshold to every card, independent of reviewer opinion.
- Contract refinements are reported back through the handoff, not lost in a chat transcript.
- Test coverage was extended and verified against live infrastructure.
No shared code. One shared checkout.
No shared code, config, or service. Each is a precedent for the other, not a dependency. The only link: one agent client holding both MCP URLs, against the same plane/ checkout.
| Demo name | okto-plane-handoff-demo |
| Target app | Fork of makeplane/plane (Django API + React/Vite web, ~35k stars), branch feature/issue-csv-export |
| Feature | Filter-aware CSV export on the Issues List view, wired into Plane's own existing (previously unused) async export pipeline |
| Pulse board | My Board: 1 ideation, 1 refinement, 1 spec, 1 sprint, 4 cards |
| Nexus workspace | Agents spec-agent, backend-agent, frontend-agent, validator-agent, and local-agent (session fallback) registered (5 total) |
Four domain roles + session fallback identity
Role
Pulse preset
Nexus identity
Did
Spec Agent
Spec
spec-agent
Ideation, refinement, spec authoring and validation
Backend Agent
Executor
backend-agent
Implemented the export endpoint + Celery task, ran real tests
Frontend Agent
Executor
frontend-agent
Claimed the handoff, implemented the toolbar action against the contract
Validator Agent
Validator
validator-agent
Submitted task validations against Pulse's thresholds
Where it actually lives in plane/
apps/api/plane/app/views/exporter/base.py
ExportIssuesEndpoint now accepts an optional rich_filters payload, validated via the same ComplexFilterBackend the live Issues List endpoint already uses.
apps/api/plane/bgtasks/export_task.py
issue_export_task applies rich_filters as an additional constraint on the existing role-scoped queryset, via _apply_rich_filters.
apps/web/core/components/issues/export-csv-action.tsx
The toolbar action, wired into IssuesHeader's Header.RightItem, gated by the same permission check as the adjacent "Add work item" button.
apps/api/.../test_export_issues_rich_filters_app.py
The backend test suite: 7 passing contract and unit tests in test_export_issues_rich_filters_app.py, covering the queryset-construction path end to end.
apps/web/e2e/export-csv.spec.ts
The frontend Playwright suite: 3 scenarios, written and committed.
The plan changed. Here's why.
Four moments where real evidence overrode the original plan, each one written down with what triggered it and what it changed.
Three assumptions, refined by real code
Plane already shipped a complete async export pipeline: an unused rich_filters field, a stubbed filter-picker in the frontend. All three of the ideation's proposals (a new sync path, a 24h URL expiry, a new column set) were dropped for Plane's own existing conventions.
→ Less new code, more brownfield-correct, informed by what the codebase already had, not by assumption.
A contract refined mid-handoff
The backend's first pass assumed Plane's legacy flat filter-key vocabulary. Investigating the Issues List view's real filter store during frontend implementation found it already produces the JSON filter-tree shape the backend natively consumes.
→ The conversion step was removed; the frontend needs zero client-side mapping. The refinement was reported back through the real Nexus handoff result.
The threshold decides, not the reviewer
Pulse's task-validation gate requires estimated_completeness >= 80, enforced independently of the reviewer's own recommendation. The Frontend card was submitted at an honest 78, real evidence, not a rounded-up number, alongside a reviewer recommendation of "approve" on the implementation's own merits.
→ The gate applied its own arithmetic. This is the gate doing exactly what it's designed to do: a threshold a reviewer's opinion can't override.
A real end-to-end pass, scoped honestly
Closing the test-coverage gap meant standing up Playwright infrastructure that didn't exist yet. Along the way, running the export pipeline against live infrastructure, the real Celery worker, database, and object storage, verified the implementation more strongly than the unit suite alone.
→ The suite, the verified fix, and a new regression test shipped; one environment-tuning step is documented as the exact next move.
From clone to governed handoff.
Four commands stand up the whole stack: Plane, Pulse, and Nexus, wired together.
1
Install Pulse + Nexus
pip install okto-pulse
pip install "okto-nexus[serve]"
2
Clone & install deps
git clone github.com/Infrasity-Labs/
okto-plane-handoff-demo
pip install -r scripts/requirements.txt
3
Bring up the stack
./scripts/00_setup.sh
4
Seed the Pulse board
python3 scripts/01_seed_pulse_board.py \
--api-key dash_<your-key>localhost Plane itself, via the proxy
127.0.0.1:8100 Pulse dashboard
127.0.0.1:8202 Nexus dashboard
Honest answers, no hand-waving.
Is this a real run, or a mockup?
Real. The board export, spec export, sprint structure, handoff event log, and screenshots come straight from demo-state/ and docs/walkthrough.md in the repo. Note that score records exist across two places: the five-dimension validation gate is recorded in docs/walkthrough.md, while the spec evaluation breakdown is exported in demo-state/spec-export.json.
Why not just use Pulse or Nexus alone?
Either one answers half the question. Pulse alone can't structurally guarantee a handoff happened; Nexus alone has no gated proof of "done." Together, a spec-gated card gets handed off with an audit trail proving both.
Do Pulse and Nexus share any code or state?
No. They're architecturally independent: no shared code, config, or service. The only connection is one agent client holding both MCP server URLs, working against the same plane/ checkout.
What's the actual feature being built?
Filter-aware CSV export on Plane's Issues List view, wired into Plane's own existing (previously unused) async export pipeline, not a toy example.
Can I reproduce this myself?
Yes. See Run It Yourself below. Fork the repo, run the setup script against your own Pulse instance, and connect your own agents to your own Nexus instance.
What's the license?
This repo's own content (docs, scripts, demo-state) is Elastic License 2.0, matching Pulse and Nexus. The embedded plane/ fork retains its own AGPL-3.0 license.
Reproduce it yourself.
Fork the repo, run the setup script against your own Pulse, and connect your own agents to your own Nexus.