Kairo-Jinkendo/docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md
Lars 01b3c594a1
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Test Suite / pytest-backend (push) Successful in 43s
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Test Suite / playwright-smoke (push) Successful in 11s
AP0.R1: Product Reset Dokumente ins Repository aufgenommen
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-05 08:18:13 +02:00

1.6 KiB

CLAUDE.md Addendum

Kairo Product Direction Reset v0.1

Dieses Addendum ist in CLAUDE.md aufzunehmen oder dort zu referenzieren.


Current Product Direction

Kairo is not a task list.

Kairo is the operational Program Director of the Jinkendo product family.

The central question is:

Which next step moves an initiative forward most effectively now?


Do not reduce Kairo to

Initiative
  → Action

This is only the first technical slice.

The canonical operating model includes:

  • Initiative
  • Project optional
  • Milestone
  • BacklogItem
  • Action
  • Assignment to Actor
  • Blocker
  • Decision
  • Evidence
  • Review
  • RecurringElement
  • AttentionItem
  • NextActionCandidate

Current implementation state

Valid but incomplete:

  • Tenant
  • Actor
  • TenantContext
  • Capabilities
  • Entitlements
  • Initiative
  • Action
  • Assignment
  • Workspace UX

Missing MVP-critical concepts:

  • Data Layer
  • Actor Directory
  • Tenant Invariants
  • Backlog
  • Blocker
  • Milestone
  • Evidence
  • Review
  • Recurrence
  • Attention / Next Action

Implementation rule

Do not continue foundation work unless it directly supports MVP usability or prevents a documented refactoring trap.

Do not continue prompt/AI/workflow/MCP work until the operating model MVP is restored.


Gate for new tasks

Every new task must answer:

  1. Does it support the operational Program Director vision?
  2. Does it improve real initiative steering?
  3. Does it prevent a concrete refactoring trap?
  4. Is it a small verifiable slice?
  5. Are non-goals explicit?

If not, do not implement.