01 / Living plan workspace
Nexus
Change the plan once. See the impact before the work changes.
Decision flow
A plan change stays reviewable before it becomes delivery work.
Nexus is not another writing surface. Its product is the authority boundary between an accepted baseline and a proposed change.
- 01Accepted plan
- 02Proposed revision
- 03Impact analysis
- 04Human decision
- 05Audit trail
Signature flow / 01
The system finds the change. It never inherits authority.
Proposals remain visible, affected work stays traceable, and only the selected set is applied.
Requirement · Work · Test · Link
Plans change. Delivery systems rarely explain what that change breaks.
Product plans, requirements, and task boards usually drift in separate tools. A sentence changes in the plan; the related task remains stale; the reason disappears into chat history. Nexus treats that gap as a change-control problem rather than another writing problem.
The accepted plan becomes a versioned baseline with stable requirement identities. A revision never silently replaces it. Instead, the system compares versions, traces affected work, and prepares a proposal for review.
The decision boundary is the product.
AI can identify likely impact, but it does not get authority to rewrite the board. Creates, updates, archives, and relinks remain pending until a person selects them. Only the approved set is applied, and the decision stays in the workflow history.
This constraint shaped the interface: baseline and proposal are visually separate, impact is explicit, and approval is a real state rather than a decorative confirmation dialog.
One durable execution, from analysis to audit.
Temporal holds the workflow while a review is pending. PostgreSQL stores plans, stable requirements, task links, and audit events. Yjs supports the living document surface. The public demo uses server-managed AI access with quotas and honest unavailable states instead of asking visitors for their own key.
The result is intentionally narrow: one difficult workflow, implemented end to end and available to verify.
Product evidence
When the decision stays visible, the product becomes explainable.
Plans, workflow state, and delivery priorities remain in one workspace.
The public surface presents one difficult flow as a narrow, verifiable product demo.
System boundaries
A durable workflow and a visible decision are two halves of the same product.
- 01Next.js 16
- 02React 19
- 03TypeScript
- 04PostgreSQL + pgvector
- 05Drizzle
- 06Temporal
- 07Yjs
- 08Gemini
- 09Docker
- Engineering notes
- 31
- Unit test files
- 02
- End-to-end specs
- 01
- Approval gate
Boundary
Where the claim stops
Nexus is a focused portfolio demo, not a production-scale SaaS. The public workspace is isolated and deliberately limits external provider behavior.