Nekurama›Ways of working›Lifecycle guide
Working baseline
Company-wide reference · v0.1

One lifecycle for every kind of work.

From a business question to a shipped feature, a campaign, or a smoother operation: use the same shared stages and state rules. Each team adds the evidence and review that fits its work.

UNIVERSAL WORK FLOW8 connected stages · regression allowed
01Research
02Specification
03Planning
04Tasking
05Execution
06Review
07Delivery
08Operate
Stage = where the work isState = what is happening now
Shared contract

The rules that travel with the work

These rules apply to technical and non-technical work across Nekurama. No tool status can replace a human decision.

01
Shared source of truth

GitHub records shared scope, owner, criteria, dependencies, and lifecycle. Paperclip records local execution.

02
Sync ≠ permission

An assignment or sync event updates context. A human still authorizes the specific execution plan.

03
Evidence before gates

Every work item has verifiable acceptance criteria. Completion is based on evidence and delivery conditions.

04
Rework preserves history

Return to the earliest stage whose output is invalid. Keep earlier decisions and artifacts traceable.

Universal stages

Eight stages, from question to operation

Choose a stage to see its purpose and the kind of evidence that supports moving forward. Stage changes and state changes are separate.

Transition logic

Moving the work and managing its state

The exact roles and evidence gates are being formalized. This view shows the current shared baseline without pretending every edge is already approved policy.

Stage movement

Move forward when a stage has produced what the next stage needs.

Research→Specification→Planning→Tasking→Execution→Review→Delivery→Operate
Rework: If evidence invalidates earlier output, return to the earliest affected stage. Preserve the work and record why it changed.

State movement

State says what is happening to this work item now, regardless of stage.

DraftDefine the work; not executable yet.
ReadyClear owner, scope, criteria, prerequisites.
ActiveAuthorized work is underway.
BlockedWaiting on a dependency, resource, or decision.
InReviewDeliverable submitted for review.
AcceptedReview and acceptance checks passed.
CompletedDelivery and handover conditions met.
CancelledStopped with history preserved.
From → ToTypical triggerGuard / evidence
Draft → ReadyDefinition is usable for planning or execution.Owner, scope, acceptance criteria, dependencies and prerequisites are clear enough.
Ready → ActiveAuthorized work starts.Human selects the item, approves the plan and scope, and current assignment and permissions are revalidated. Ready alone is not permission.
Active → Blocked → ActiveA dependency prevents progress, then is resolved.Record the blocker, owner and resolution; recheck authorization if scope or context changed.
Active → InReviewDeliverable is submitted.Attach evidence mapped to the acceptance criteria and request the applicable review.
InReview → ActiveChanges requested or acceptance gap found.Record findings; return to Execution or the earliest earlier stage made invalid.
InReview → AcceptedApplicable review passes.Authorized reviewer records the decision and evidence. Agent completion is not acceptance.
Accepted → CompletedDelivery and handover finish.Record delivery destination, handover, and any required operational readiness evidence.
Any open state → CancelledWork is explicitly withdrawn or stopped.Authorized human records rationale and preserves history. Reopening rules remain part of the contract work.
!
Eligibility, authorization, acceptance, and completion are four different checks.

Local Paperclip run states do not force GitHub transitions. Reassignment, revoked permission, offline context, and sensitive actions require explicit revalidation.

Curated examples · BABAI

What the same lifecycle looks like by team

Pick a department, then step through the animated journey. The underlying stages stay the same; each example changes its deliverables, evidence, and handoffs.